집계 영역으로 하나의 보안 영역과 다른 보안 영역 또는 여러 보안 영역을 사용하여 Elytron에서 권한을 부여할 수 있습니다. 예를 들어 인증에 properties 영역을 사용하고 권한 부여에 JDBC 영역을 사용하도록 집계 영역을 구성할 수 있습니다.

여러 권한 영역을 집계하도록 구성된 집계 영역에서 다음과 같이 ID가 생성됩니다.

다음 예제에서는 여러 권한 부여 영역에 동일한 ID 속성에 대한 정의가 포함된 경우 ID를 생성하는 방법을 보여줍니다.

authentication-realm=properties-realm,
authorization-realms=[jdbc-realm,ldap-realm]

집계 영역에서 얻은 ID 결과:

e-mail: user@example.com
groups: Supervisor, User
phone: 0000 0000 0000

이 예제에서는 전자 메일 속성이 권한 부여 영역 모두에서 정의됩니다. 집계 영역이 권한 부여 영역을 authorization- realms=[jdbc -realm,ldap-realm] 로 집계하도록 구성되었으므로 JDBC 영역에 정의된 값은 결과 집계 영역에서 특성 전자 메일에 사용됩니다.

집계 영역을 사용하여 인증 및 권한 부여를 구성하려면 집계 영역을 생성하고 집계 영역을 사용하도록 보안 도메인과 애플리케이션 보안 도메인을 구성합니다.

다음 영역을 사전 구성해야 합니다.

다음 명령을 실행하면 집계 영역을 생성합니다.

/subsystem=elytron/aggregate-realm:exampleSimpleAggregateRealm:add(authentication-realm=examplPropertiesRealm,authorization-realm=exampleJdbcRealm)

다음 영역을 사전 구성해야 합니다.

다음 명령을 실행하면 집계 영역을 생성합니다.

/subsystem=elytron/aggregate-realm:exampleSimpleAggregateRealm:add(authentication-realm=examplPropertiesRealm,authorization-realms=[exampleJdbcRealm,exampleLdapRealm])

BEARER_TOKEN 인증 메커니즘을 사용하여 애플리케이션에 전송된 HTTP 요청을 인증할 수 있습니다. 클라이언트(예: 웹 브라우저)가 HTTP 요청을 애플리케이션에 전송한 후 BEARER_TOKEN 메커니즘은 요청의 인증 HTTP 헤더에 전달자 토큰이 있는지 확인합니다.

Elytron은 OpenID Connect ID 토큰과 같은 JWT 형식으로 전달자 토큰을 사용하거나 OAuth2 호환 인증 서버에서 발급한 불투명 토큰을 사용하여 인증을 지원합니다. 추가 리소스 섹션을 참조하십시오.

다음 예제에서는 Authorization HTTP 헤더에 mF_9.B5f-4.1JqM 전달자 토큰이 포함되어 있음을 보여줍니다.

GET /resource HTTP/1.1
Host: server.example.com
Authorization: Bearer mF_9.B5f-4.1JqM

BEARER_TOKEN 메커니즘은 이제 전달자 토큰 문자열을 추출하여 유효성 검사를 위해 token-realm 구현에 전달할 수 있습니다. 구현이 전달자 토큰의 유효성을 검증하는 경우 Elytron은 토큰으로 표시되는 정보를 기반으로 보안 컨텍스트를 생성합니다. 애플리케이션에서 이 보안 컨텍스트를 사용하여 요청자에 대한 정보를 얻을 수 있습니다. 그런 다음 HTTP 리소스에 대한 요청자 액세스 권한을 제공하여 요청을 이행할지 여부를 결정할 수 있습니다.

요청자가 전달자 토큰을 제공하지 않는 경우 BEARER_TOKEN 메커니즘은 401 HTTP 상태 코드를 반환합니다. 예를 들면 다음과 같습니다.

HTTP/1.1 401 Unauthorized
WWW-Authenticate: Bearer realm="example"

요청자가 리소스에 액세스할 권한이 없는 경우 BEARER_TOKEN 메커니즘은 403 HTTP 상태 코드를 반환합니다.

HTTP/1.1 403 Forbidden

elytron 하위 시스템에서 token-realm 을 지정하여 JWT에 대한 지원을 활성화할 수 있습니다.

token-realm 내에서 특성 및 jwt 토큰 유효성 검사기를 지정할 수 있습니다. Elytron은 다음 검사를 완료합니다.

다음 예제에서는 token-realm 을 보안 영역으로, principal-claim 을 특성으로 보여줍니다. principal-claim 특성은 elytron 에서 주체 이름을 가져오는 데 사용하는 클레임 이름을 정의합니다. jwt 요소는 토큰을 JWT로 검증해야 함을 지정합니다.

<token-realm name="${token_realm_name}" principal-claim="${principal_claim_key}">
    <jwt issuer="${issuer_name}"
         audience="${audience_name}"
         <public-key="${public_key_in_PEM_format}"/>
 </token-realm>

token-realm 의 키 맵을 정의할 수 있습니다. 그런 다음 서로 다른 키 쌍을 서명 확인을 위해 사용할 수 있으며 이러한 키 쌍을 쉽게 회전할 수 있습니다. Elytron은 토큰 에서 청구를 가져와 검증을 위해 해당 공개 키를 사용합니다.

<token-realm name="${token_realm_name}" principal-claim="${principal_claim_key}">
    <jwt issuer="${issuer_name}" audience="${audience_name}">
        <key kid="${key_ID_from_kid_claim}" public-key="${public_key_in_PEM_format}"/>
        <key kid="${another_key_ID_from_kid_claim}" public-key="${public_key_in_PEM_format}"/>
    </jwt>
</token-realm>

Elytron은 OAuth2 호환 권한 부여 서버에서 발행한 전달자 토큰을 지원합니다. 사전 정의된 oauth2-introspection 엔드포인트에 대해 토큰의 유효성을 검사하도록 토큰 영역을 구성할 수 있습니다.

OpenID Connect ID 토큰과 같은 JWT 형식으로 전달자 토큰을 사용하거나 OAuth2 호환 인증 서버에서 발급한 불투명 토큰을 사용하여 애플리케이션에 대한 인증을 구성할 수 있습니다.

LdapExtended(또는.jboss.security.auth.spi.LdapExtLoginModule)는 검색을 사용하여 LDAP 서버에서 바인드 사용자 및 관련 역할을 찾는 로그인 모듈 구현입니다. 역할 쿼리는 DN을 재귀적으로 따라 계층적 역할 구조를 탐색합니다. 보안 도메인과 LDAP를 사용할 경우 대부분의 경우 LdapExtended 로그인 모듈(특히 Active Directory가 아닌 LDAP 구현)을 사용해야 합니다. LdapExtended 로그인 모듈에 대한 구성 옵션 전체 목록은 JBoss EAP 로그인 모듈 참조의 LdapExtended 로그인 모듈섹션을 참조하십시오.

인증은 다음과 같이 수행됩니다.

dn: uid=jduke,ou=Users,dc=jboss,dc=org
objectClass: inetOrgPerson
objectClass: person
objectClass: top
cn: Java Duke
sn: duke
uid: jduke
userPassword: theduke
# =============================
dn: uid=hnelson,ou=Users,dc=jboss,dc=org
objectClass: inetOrgPerson
objectClass: person
objectClass: top
cn: Horatio Nelson
sn: Nelson
uid: hnelson
userPassword: secret
# =============================
dn: ou=groups,dc=jboss,dc=org
objectClass: top
objectClass: organizationalUnit
ou: groups
# =============================
dn: uid=ldap,ou=Users,dc=jboss,dc=org
objectClass: inetOrgPerson
objectClass: person
objectClass: top
cn: LDAP
sn: Service
uid: ldap
userPassword: randall
# =============================
dn: ou=Users,dc=jboss,dc=org
objectClass: top
objectClass: organizationalUnit
ou: Users
# =============================
dn: dc=jboss,dc=org
objectclass: top
objectclass: domain
dc: jboss
# =============================
dn: uid=GroupTwo,ou=groups,dc=jboss,dc=org
objectClass: top
objectClass: groupOfNames
objectClass: uidObject
cn: GroupTwo
member: uid=jduke,ou=Users,dc=jboss,dc=org
uid: GroupTwo
# =============================
dn: uid=GroupThree,ou=groups,dc=jboss,dc=org
objectClass: top
objectClass: groupOfUniqueNames
objectClass: uidObject
cn: GroupThree
uid: GroupThree
uniqueMember: uid=GroupOne,ou=groups,dc=jboss,dc=org
# =============================
dn: uid=HTTP,ou=Users,dc=jboss,dc=org
objectClass: inetOrgPerson
objectClass: person
objectClass: top
cn: HTTP
sn: Service
uid: HTTP
userPassword: httppwd
# =============================
dn: uid=GroupOne,ou=groups,dc=jboss,dc=org
objectClass: top
objectClass: groupOfUniqueNames
objectClass: uidObject
cn: GroupOne
uid: GroupOne
uniqueMember: uid=jduke,ou=Users,dc=jboss,dc=org
uniqueMember: uid=hnelson,ou=Users,dc=jboss,dc=org

/subsystem=security/security-domain=testLdapExtendedExample:add(cache-type=default)

/subsystem=security/security-domain=testLdapExtendedExample/authentication=classic:add

/subsystem=security/security-domain=testLdapExtendedExample/authentication=classic/login-module=LdapExtended:add(code=LdapExtended, flag=required, module-options=[ ("java.naming.factory.initial"=>"com.sun.jndi.ldap.LdapCtxFactory"),     ("java.naming.provider.url"=>"ldap://localhost:10389"), ("java.naming.security.authentication"=>"simple"),     ("bindDN"=>"uid=ldap,ou=Users,dc=jboss,dc=org"), ("bindCredential"=>"randall"),     ("baseCtxDN"=>"ou=Users,dc=jboss,dc=org"), ("baseFilter"=>"(uid={0})"), ("rolesCtxDN"=>"ou=groups,dc=jboss,dc=org"),     ("roleFilter"=>"(uniqueMember={1})"), ("roleAttributeID"=>"uid")])

reload

/subsystem=security/security-domain=AD_Default:add(cache-type=default)

/subsystem=security/security-domain=AD_Default/authentication=classic:add

/subsystem=security/security-domain=AD_Default/authentication=classic/login-module=LdapExtended:add(code=LdapExtended,flag=required,module-options=[ ("java.naming.provider.url"=>"ldap://ldaphost.jboss.org"),("bindDN"=>"JBOSSsearchuser"), ("bindCredential"=>"password"), ("baseCtxDN"=>"CN=Users,DC=jboss,DC=org"), ("baseFilter"=>"(sAMAccountName={0})"), ("rolesCtxDN"=>"CN=Users,DC=jboss,DC=org"), ("roleFilter"=>"(sAMAccountName={0})"), ("roleAttributeID"=>"memberOf"), ("roleAttributeIsDN"=>"true"), ("roleNameAttributeID"=>"cn"), ("searchScope"=>"ONELEVEL_SCOPE"), ("allowEmptyPasswords"=>"false")])

reload

/subsystem=security/security-domain=AD_Recursive:add(cache-type=default)

/subsystem=security/security-domain=AD_Recursive/authentication=classic:add

/subsystem=security/security-domain=AD_Recursive/authentication=classic/login-module=LdapExtended:add(code=LdapExtended,flag=required,module-options=[("java.naming.provider.url"=>"ldap://ldaphost.jboss.org"), ("java.naming.referral"=>"follow"), ("bindDN"=>"JBOSSsearchuser"), ("bindCredential"=>"password"), ("baseCtxDN"=>"CN=Users,DC=jboss,DC=org"), ("baseFilter"=>"(sAMAccountName={0})"), ("rolesCtxDN"=>"CN=Users,DC=jboss,DC=org"), ("roleFilter"=>"(member={1})"), ("roleAttributeID"=>"cn"), ("roleAttributeIsDN"=>"false"), ("roleRecursion"=>"2"), ("searchScope"=>"ONELEVEL_SCOPE"), ("allowEmptyPasswords"=>"false")])

reload

Database 로그인 모듈은 인증 및 역할 매핑을 지원하는 JDBC 로그인 모듈입니다. 이 로그인 모듈은 사용자 이름, 암호 및 역할 정보가 관계형 데이터베이스에 저장된 경우 사용됩니다.

이는 예상되는 형식의 주체 및 역할을 포함하는 논리 테이블에 대한 참조를 제공하여 작동합니다. 예를 들면 다음과 같습니다.

Table Principals(PrincipalID text, Password text) Table Roles(PrincipalID text, Role text, RoleGroup text)

Principals 테이블은 사용자 PrincipalID 를 유효한 암호와 연결하고 Roles 테이블은 사용자 PrincipalID 를 해당 역할 집합과 연결합니다. 사용자 권한에 사용되는 역할은 Roles (역할)의 RoleGroup 열 값이 있는 행에 포함되어야 합니다.

테이블은 사용자가 로그인 모듈에서 사용하는 SQL 쿼리를 지정할 수 있는 논리적입니다. 유일한 요구 사항은 java.sql.ResultSet 에 이전에 설명된 주체 및 역할 테이블과 동일한 논리 구조가 있다는 것입니다. 테이블 및 열의 실제 이름은 결과가 열 색인에 따라 액세스되므로 관련이 없습니다.

이 개념을 명확히 설명하려면 이미 선언된 대로 두 개의 테이블, 주체 및 역할이 있는 데이터베이스를 고려하십시오. 다음 설명은 다음 데이터로 테이블을 채웁니다.

Database 로그인 모듈에 대한 전체 구성 옵션 목록은 JBoss EAP 로그인 모듈 참조의 Database 로그인 모듈섹션을 참조하십시오.

CREATE TABLE Users(username VARCHAR(64) PRIMARY KEY, passwd VARCHAR(64))
CREATE TABLE UserRoles(username VARCHAR(64), role VARCHAR(32))

/subsystem=security/security-domain=testDB:add

/subsystem=security/security-domain=testDB/authentication=classic:add

/subsystem=security/security-domain=testDB/authentication=classic/login-module=Database:add(code=Database,flag=required,module-options=[("dsJndiName"=>"java:/MyDatabaseDS"),("principalsQuery"=>"select passwd from Users where username=?"),("rolesQuery"=>"select role, 'Roles' from UserRoles where username=?")])

reload

UsersRoles는 Java 속성 파일에서 로드된 여러 사용자 및 사용자 역할을 지원하는 간단한 로그인 모듈입니다. 이 로그인 모듈의 주요 목적은 애플리케이션과 함께 배포된 속성 파일을 사용하여 여러 사용자와 역할의 보안 설정을 쉽게 테스트하는 것입니다. 기본 username-to-password 매핑 filename은 users.properties 이며 기본 username-to-roles 매핑 filename은 roles.properties 입니다.

속성 파일은 초기화 메서드 스레드 컨텍스트 클래스 로더를 사용하여 초기화 중에 로드됩니다. 즉, 이러한 파일을 Jakarta EE 배포의 클래스 경로(예: WAR 아카이브의 WEB-INF/classes 폴더)에 배치하거나 서버 클래스 경로의 모든 디렉토리에 배치할 수 있습니다.

UsersRoles 로그인 모듈에 대한 전체 구성 옵션 목록은 JBoss EAP 로그인 모듈 참조의 UsersRoles 로그인 모듈섹션을 참조하십시오.

/subsystem=security/security-domain=sampleapp:add

/subsystem=security/security-domain=sampleapp/authentication=classic:add

/subsystem=security/security-domain=sampleapp/authentication=classic/login-module=UsersRoles:add(code=UsersRoles,flag=required,module-options=[("usersProperties"=>"sampleapp-users.properties"),("rolesProperties"=>"sampleapp-roles.properties")])

reload

인증서 기반 인증을 사용하는 보안 도메인을 생성하려면 신뢰할 수 있는 저장소와 인증서 로그인 모듈 또는 하위 클래스 중 하나를 지정해야 합니다.

신뢰 저장소에는 인증에 사용되는 신뢰할 수 있는 클라이언트 인증서가 포함되어야 합니다. 그렇지 않으면 클라이언트 인증서에 서명하는 데 사용되는 인증 기관의 인증서가 포함되어야 합니다. 로그인 모듈은 구성된 신뢰 저장소를 사용하여 클라이언트에서 제공하는 인증서를 인증하는 데 사용됩니다. 보안 도메인 전체도 인증되고 나면 역할을 주체에 매핑하는 방법을 제공해야 합니다. 인증서 로그인 모듈 자체는 역할 정보를 주체에 매핑하지 않지만 다른 로그인 모듈과 결합될 수 있습니다. 또는 Certificate login 모듈의 두 하위 클래스인 CertificateRoles 및 DatabaseCertificate 는 인증 후 역할을 주체에 매핑하는 방법을 제공합니다. 아래 예제에서는 CertificateRoles 로그인 모듈을 사용하여 인증서 기반 인증으로 보안 도메인을 구성하는 방법을 보여줍니다.

/subsystem=security/security-domain=cert-roles-domain:add

/subsystem=security/security-domain=cert-roles-domain/jsse=classic:add(truststore={password=secret, url="/path/to/server.truststore.jks"}, keystore={password=secret, url="/path/to/server.keystore.jks"}, client-auth=true)

/subsystem=security/security-domain=cert-roles-domain/authentication=classic:add

/subsystem=security/security-domain=cert-roles-domain/authentication=classic/login-module=CertificateRoles:add(code=CertificateRoles, flag=required, module-options=[ securityDomain="cert-roles-domain", rolesProperties="${jboss.server.config.dir}/cert-roles.properties",password-stacking="useFirstPass", verifier="org.jboss.security.auth.certs.AnyCertVerifier"])

user1=roleA
user2=roleB,roleC
user3=

CN\=valid-client,\ OU\=JBoss,\ O\=Red\ Hat,\ L\=Raleigh,\ ST\=NC,\ C\=US=Admin

$ keytool -printcert -file valid-client.crt
Owner: CN=valid-client, OU=JBoss, O=Red Hat, L=Raleigh, ST=NC, C=US
...

다른 형태의 인증과 함께 보안 도메인을 사용하도록 애플리케이션을 구성하는 것과 유사하게 jboss-web.xml 및 web.xml 파일을 적절하게 구성해야 합니다.

jboss-web.xml 의 경우 인증서 기반 인증을 위해 구성한 보안 도메인에 참조를 추가합니다.

<jboss-web>
  <security-domain>cert-roles-domain</security-domain>
</jboss-web>

web.xml 의 경우 < login-config>에서 <auth-method > 속성을 CLIENT-CERT 로 설정합니다. 또한 <security-constraint> 및 <security-roles> 를 정의해야 합니다.

<web-app>
  <!-- URL for secured portion of application-->
  <security-constraint>
    <web-resource-collection>
      <web-resource-name>secure</web-resource-name>
      <url-pattern>/secure/*</url-pattern>
    </web-resource-collection>
    <auth-constraint>
      <role-name>All</role-name>
    </auth-constraint>
  </security-constraint>

  <!-- Security roles referenced by this web application -->
  <security-role>
    <description>The role that is required to log in to the application</description>
    <role-name>All</role-name>
  </security-role>

  <login-config>
    <auth-method>CLIENT-CERT</auth-method>
    <realm-name>cert-roles-domain</realm-name>
  </login-config>
</web-app>

클라이언트가 인증서 기반 인증으로 보안된 애플리케이션에 대해 인증하려면 클라이언트는 JBoss EAP 인스턴스의 신뢰 저장소에 포함된 클라이언트 인증서에 액세스해야 합니다. 예를 들어 브라우저를 사용하여 애플리케이션에 액세스하는 경우 클라이언트는 신뢰할 수 있는 인증서를 브라우저의 신뢰 저장소로 가져와야 합니다.

관리 콘솔 또는 관리 CLI를 사용하여 보안 도메인의 캐시 유형을 설정할 수 있습니다.

/subsystem=security/security-domain=SECURITY_DOMAIN_NAME:list-cached-principals

관리 콘솔 또는 관리 CLI를 사용하여 보안 도메인의 캐싱을 비활성화할 수 있습니다.

구성 파일 접근 방식은 인증 구성, 인증 컨텍스트 및 일치 규칙을 사용하여 XML 파일을 생성해야 합니다.

<configuration>
    <authentication-client xmlns="urn:elytron:client:1.2">
        <authentication-rules>
            <rule use-configuration="monitor">
                <match-host name="127.0.0.1" />
            </rule>
            <rule use-configuration="administrator">
                <match-host name="localhost" />
            </rule>
        </authentication-rules>
        <authentication-configurations>
            <configuration name="monitor">
                <sasl-mechanism-selector selector="DIGEST-MD5" />
                <providers>
                  <use-service-loader />
                </providers>
                <set-user-name name="monitor" />
                <credentials>
                    <clear-password password="password1!" />
                </credentials>
                <set-mechanism-realm name="ManagementRealm" />
             </configuration>

             <configuration name="administrator">
                <sasl-mechanism-selector selector="DIGEST-MD5" />
                <providers>
                  <use-service-loader />
                </providers>
                <set-user-name name="administrator" />
                <credentials>
                    <clear-password password="password1!" />
                </credentials>
                <set-mechanism-realm name="ManagementRealm" />
             </configuration>
        </authentication-configurations>
    </authentication-client>
</configuration>

그런 다음 클라이언트를 실행할 때 시스템 속성을 설정하여 클라이언트 코드에서 해당 파일을 참조할 수 있습니다.

$ java -Dwildfly.config.url=/path/to/custom-config.xml ...

규칙을 만들 때 호스트 이름,포트,프로토콜 또는 사용자 이름과 같은 다양한 매개 변수에서 일치 항목을 찾을 수 있습니다. MatchRule 의 전체 옵션 목록은 Javadocs에서 확인할 수 있습니다. 규칙은 구성된 순서대로 평가합니다.

규칙에 일치하는 설정이 포함되지 않은 경우 전체 규칙이 일치하고 인증 구성이 선택됩니다. 규칙에 둘 이상의 일치 설정이 포함된 경우 인증 구성을 선택하려면 모두 일치해야 합니다.

wildfly-config.xml 파일은 Example wildfly-config.xml 에서 찾을 수 있습니다. wildfly-config.xml 파일을 구성하는 방법에 대한 자세한 내용은 wildfly -config.xml 파일을 사용하여 클라이언트 구성을 참조하십시오.

프로그래밍 방식의 접근 방식은 클라이언트의 코드에서 모든 Elytron 클라이언트 구성을 구성합니다.

//create your authentication configuration
AuthenticationConfiguration adminConfig =
    AuthenticationConfiguration.empty()
      .useProviders(() -> new Provider[] { new WildFlyElytronProvider() })
      .setSaslMechanismSelector(SaslMechanismSelector.NONE.addMechanism("DIGEST-MD5"))
      .useRealm("ManagementRealm")
      .useName("administrator")
      .usePassword("password1!");

//create your authentication context
AuthenticationContext context = AuthenticationContext.empty();
context = context.with(MatchRule.ALL.matchHost("127.0.0.1"), adminConfig);


//create your runnable for establishing a connection
Runnable runnable =
    new Runnable() {
      public void run() {
        try {
           //Establish your connection and do some work
        } catch (Exception e) {
          e.printStackTrace();
        }
      }
    };

//use your authentication context to run your client
context.run(runnable);

AuthenticationConfiguration 및 Authentication Context 에 구성 세부 정보를 추가하면 각 메서드 호출에서 해당 오브젝트의 새 인스턴스를 반환합니다. 예를 들어 다른 호스트 이름으로 연결할 때 별도의 구성을 원하는 경우 다음을 수행할 수 있습니다.

//create your authentication configuration
AuthenticationConfiguration commonConfig =
    AuthenticationConfiguration.empty()
      .useProviders(() -> new Provider[] { new WildFlyElytronProvider() })
      .setSaslMechanismSelector(SaslMechanismSelector.NONE.addMechanism("DIGEST-MD5"))
      .useRealm("ManagementRealm");

AuthenticationConfiguration administrator =
    commonConfig
      .useName("administrator")
      .usePassword("password1!");


AuthenticationConfiguration monitor =
    commonConfig
      .useName("monitor")
      .usePassword("password1!");


//create your authentication context
AuthenticationContext context = AuthenticationContext.empty();
context = context.with(MatchRule.ALL.matchHost("127.0.0.1"), administrator);
context = context.with(MatchRule.ALL.matchHost("localhost"), monitor);

또한 비어 있는 인증 구성을 시작하는 대신, captureCurrite() 를 사용하여 현재 구성된 인증 구성을 시작할 수 있습니다.

//create your authentication configuration
AuthenticationConfiguration commonConfig = AuthenticationConfiguration.captureCurrent();

captureCurrite() 를 사용하면 이전에 설정된 인증 컨텍스트를 캡처하고 새 기본 구성으로 사용합니다. 인증 컨텍스트는 run()을 호출하여 활성화되면 설정됩니다. captureCurrite() 를 호출하고 컨텍스트가 현재 활성 상태가 아닌 경우 사용 가능한 경우 기본 인증을 사용하려고 합니다. 이에 대한 자세한 내용은 다음 섹션에서 확인할 수 있습니다.

AuthenticationConfiguration.empty() 는 구성을 빌드하는 데 기본으로만 사용해야 하며 자체적으로 사용해서는 안 됩니다. JVM 전체의 등록된 공급업체를 사용하고 익명 인증을 활성화하는 구성을 제공합니다.

AuthenticationConfiguration.empty() 구성 상단에 공급자를 지정하는 경우 사용자 지정 목록을 지정할 수 있지만, 대부분의 사용자는 WildFlyElytronProvider() 공급자를 사용해야 합니다.

인증 컨텍스트를 생성할 때 context.with(…​) 는 현재 컨텍스트에서 제공된 규칙 및 인증 구성과 규칙 및 인증 구성을 병합하는 새 컨텍스트를 생성합니다. 제공된 규칙 및 인증 구성은 현재 컨텍스트의 뒤에 표시됩니다.

기본 구성 방법은 Elytron 클라이언트가 제공하는 구성에 완전히 의존합니다.

//create your runnable for establishing a connection
Runnable runnable =
    new Runnable() {
      public void run() {
        try {
           //Establish your connection and do some work
        } catch (Exception e) {
          e.printStackTrace();
        }
      }
    };

// run runnable directly
runnable.run();

기본 구성을 제공하기 위해 Elytron Client는 파일 시스템에서 a wildfly-config.xml 파일을 자동 검색합니다. 다음과 같은 위치가 표시됩니다.

다음 예제를 client wildfly-config.xml 파일의 기본 구성으로 사용할 수 있습니다.

<configuration>
  <authentication-client xmlns="urn:elytron:client:1.2">
    <authentication-rules>
      <rule use-configuration="default" />
    </authentication-rules>
    <authentication-configurations>
      <configuration name="default">
        <sasl-mechanism-selector selector="#ALL" />
        <set-mechanism-properties>
          <property key="wildfly.sasl.local-user.quiet-auth" value="true" />
        </set-mechanism-properties>
        <providers>
          <use-service-loader/>
        </providers>
      </configuration>
    </authentication-configurations>
  </authentication-client>
</configuration>

JBoss EAP에 배포된 클라이언트는 Elytron Client도 사용할 수 있습니다. AuthenticationContext 는 JBoss EAP 구성의 default-authentication-context 설정에서 자동으로 구문 분석되고 생성됩니다. default-authentication-context 가 구성되지 않았지만 배포에 포함되거나 the wildfly.config. url 시스템 속성을 사용하여 설정된 awildfly-config. xml 파일이 있는 경우 AuthenticationContext 는 해당 파일에서 자동으로 구문 분석하고 생성됩니다.

/subsystem=elytron/authentication-context=AUTH_CONTEXT:add
/subsystem=elytron:write-attribute(name=default-authentication-context,value=AUTH_CONTEXT)

배포 외부에서 구성 파일을 로드하려면 parseAuthenticationClientConfiguration(URI) 메서드를 사용할 수 있습니다. 이 메서드는 프로그래밍 방식을 사용하여 클라이언트 코드에서 사용할 수 있는 AuthenticationContext 를 반환합니다.

또한 클라이언트는 elytron 하위 시스템에서 제공하는 클라이언트 구성에서 AuthenticationContext 를 자동으로 구문 분석하고 생성합니다. elytron 하위 시스템의 클라이언트 구성은 자격 증명 저장소와 같이 elytron 하위 시스템에 정의된 다른 구성 요소를 활용할 수도 있습니다. 배포 및 elytron 하위 시스템에서 클라이언트 구성을 모두 제공하는 경우 elytron 하위 시스템의 구성이 사용됩니다.

JBoss EAP 7.1부터 JConsole을 포함한 Jakarta Management 클라이언트는 the wildfly-config.xml 파일을 사용하여 구성할 수 있습니다. Jakarta Management 클라이언트를 시작할 때 -Dwildfly.config.url 시스템 속성을 사용하여 구성 파일의 파일 경로를 지정합니다.

-Dwildfly.config.url=path/to/wildfly-config.xml

-J-Dwildfly.config.url=path/to/wildfly-config.xml

자세한 내용은 JBoss EAP 개발 가이드 의 the wildfly-config.xml 파일을 사용한 클라이언트 구성을 참조하십시오.

JBoss EAP 7.1은 현재 보안 컨텍스트를 사용하여 인증을 수행하는 ElytronAuthenticator 클래스를 도입했습니다. org.wildfly.security.auth.util.ElytronAuthenticator 클래스는 java.net.Authenticator 의 구현입니다.

다음은 ElytronAuthenticator 클래스를 생성하고 사용하여 ID를 서버에 전파하는 클라이언트 코드의 예입니다.

// Create the authentication configuration
AuthenticationConfiguration httpConfig = AuthenticationConfiguration.empty().useName("bob");

// Create the authentication context
AuthenticationContext context = AuthenticationContext.captureCurrent().with(MatchRule.ALL, httpConfig.usePassword(createPassword(httpConfig, "secret")));

String response = context.run((PrivilegedExceptionAction<String>) () -> {
    Authenticator.setDefault(new ElytronAuthenticator());
    HttpURLConnection connection = HttpURLConnection.class.cast(new URL("http://localhost:" + SERVER_PORT).openConnection());
    try (InputStream inputStream = connection.getInputStream()) {
        return new BufferedReader(new InputStreamReader(inputStream)).lines().findFirst().orElse(null);
    }
});

LDAP를 사용하여 관리 인터페이스를 보호하는 경우 양방향 SSL/TLS를 사용하도록 아웃바운드 LDAP 연결을 구성할 수 있습니다. 이렇게 하려면 ssl-context 를 만들고 ldap-realm 에서 사용하는 dir-context 에 추가합니다. 양방향 SSL/TLS ssl-context 생성에 대해서는 서버 보안 구성 방법의 Elytron 하위 시스템 섹션에서 애플리케이션의 Enable Two-way SSL/TLS를 참조하십시오.

다음 단계에 따라 SSL/TLS로 보호되는 아웃바운드 LDAP 연결을 생성합니다.

JBoss EAP를 사용하면 보안 영역에서 인증 및 권한 부여를 독립적으로 구성할 수 있습니다. 이를 통해 LDAP를 인증 메커니즘으로 구성하고 RBAC를 권한 부여 메커니즘으로 구성할 수 있습니다. 이러한 방식으로 구성된 경우 사용자가 관리 인터페이스에 액세스하려고 하면 먼저 구성된 LDAP 서버를 사용하여 인증됩니다. 성공하면 사용자의 역할에 따라 LDAP 서버에 있는 그룹 정보와 독립적으로 RBAC만 사용하여 결정됩니다.

관리 인터페이스의 권한 부여 메커니즘으로 RBAC를 사용하는 방법에 대한 자세한 내용은 JBoss EAP의 서버 보안 구성 방법을 참조하십시오. 관리 인터페이스를 사용한 인증을 위한 LDAP 구성에 대한 자세한 내용은 이전 섹션 을 참조하십시오.

LDAP 서버를 사용하여 인증했거나 속성 파일을 사용하는 사용자는 사용자 그룹의 멤버가 될 수 있습니다. 사용자 그룹은 하나 이상의 사용자에게 할당할 수 있는 임의 레이블입니다. 이 그룹 정보를 사용하여 사용자에게 역할을 자동으로 할당하거나 역할에서 사용자를 제외하도록 RBAC를 구성할 수 있습니다.

LDAP 디렉터리에는 속성으로 참조된 교차 사용자 계정 및 그룹 항목이 포함되어 있습니다. LDAP 서버 구성에 따라 사용자 엔터티는 memberOf 속성을 통해 사용자가 속한 그룹을 매핑할 수 있습니다. 그룹 엔터티는 uniqueMember 속성을 통해 사용자가 속한 그룹을 매핑할 수 있습니다. 또는 이 둘의 조합을 사용할 수 있습니다. 사용자가 LDAP 서버에 성공적으로 인증되면 그룹 검색을 수행하여 해당 사용자의 그룹 정보를 로드합니다. 사용 중인 디렉터리 서버에 따라 SN(일반적으로 인증에 사용되는 사용자 이름)을 사용하거나 디렉터리에서 사용자 항목의 DN을 사용하여 그룹 검색을 수행할 수 있습니다. 보안 영역에서 LDAP를 권한 부여 메커니즘으로 설정할 때 그룹검색(그룹 검색) 및 사용자 이름과 고유 이름(username-to-dn) 간 매핑이 구성됩니다.

LDAP 서버에서 사용자의 그룹 구성원 정보를 결정하면 RBAC 구성 내의 매핑을 사용하여 사용자가 보유한 역할을 결정합니다. 이 매핑은 개별 사용자와 그룹을 명시적으로 포함하거나 제외하도록 구성됩니다.

/core-service=management/security-realm=ldap-security-realm:add

batch

/core-service=management/security-realm=ldap-security-realm/authorization=ldap:add(connection=ldap-connection)

/core-service=management/security-realm=ldap-security-realm/authorization=ldap/group-search=principal-to-group:add(group-attribute="memberOf",iterative=true,group-dn-attribute="dn", group-name="SIMPLE",group-name-attribute="cn")

run-batch

/core-service=management/security-realm=ldap-security-realm:add

batch

/core-service=management/security-realm=ldap-security-realm/authorization=ldap:add(connection=ldap-connection)

/core-service=management/security-realm=ldap-security-realm/authorization=ldap/group-search=group-to-principal:add(iterative=true, group-dn-attribute="dn", group-name="SIMPLE", group-name-attribute="uid", base-dn="ou=groups,dc=group-to-principal,dc=example,dc=org", principal-attribute="uniqueMember", search-by="DISTINGUISHED_NAME")

run-batch

/core-service=management/access=authorization:read-attribute(name=provider)

{ "outcome" => "success", "result" => "rbac" }

/core-service=management/access=authorization:read-children-names(child-type=role-mapping)

{
  "outcome" => "success",
  "result" =>
    [ "Administrator", "Deployer", "Maintainer", "Monitor", "Operator", "SuperUser" ]
}

/core-service=management/access=authorization/role-mapping=Administrator:read-resource(recursive=true)

{
  "outcome" => "success",
  "result" =>
  {
    "include-all" => false,
    "exclude" => undefined,
    "include" => {
      "user-theboss" => {
        "name" => "theboss",
        "realm" => undefined,
        "type" => "USER"
      },
      "user-harold" => {
        "name" => "harold",
        "realm" => undefined,
        "type" => "USER"
      },
      "group-SysOps" => {
        "name" => "SysOps",
        "realm" => undefined,
        "type" => "GROUP"
      }
    }
  }
}

/core-service=management/access=authorization/role-mapping=Auditor:read-resource()

{
  "outcome" => "failed",
  "failure-description" => "WFLYCTL0216: Management resource '[ (\"core-service\" => \"management\"), (\"access\" => \"authorization\"), (\"role-mapping\" => \"Auditor\") ]' not found"
}

/core-service=management/access=authorization/role-mapping=Auditor:add()

{
  "outcome" => "success"
}

/core-service=management/access=authorization/role-mapping=Auditor:read-resource()

{
  "outcome" => "success",
  "result" => {
    "include-all" => false,
    "exclude" => undefined,
    "include" => undefined
  }
}

/core-service=management/access=authorization/role-mapping=Auditor/include=group-GroupToInclude:add(name=GroupToInclude, type=GROUP)

/core-service=management/access=authorization/role-mapping=Auditor/exclude=group-GroupToExclude:add(name=GroupToExclude, type=GROUP)

/core-service=management/access=authorization/role-mapping=Auditor:read-resource(recursive=true)

{
  "outcome" => "success",
  "result" => {
    "include-all" => false,
    "exclude" => {
      "group-GroupToExclude" => {
        "name" => "GroupToExclude",
        "realm" => undefined,
        "type" => "GROUP"
      }
    },
    "include" => {
      "group-GroupToInclude" => {
        "name" => "GroupToInclude",
        "realm" => undefined,
        "type" => "GROUP"
      }
    }
  }
}

/core-service=management/access=authorization/role-mapping=Auditor/include=group-GroupToInclude:remove

/core-service=management/access=authorization/role-mapping=Auditor/exclude=group-GroupToExclude:remove

캐시는 서로 독립적이지만 모두 동일한 방식으로 구성됩니다. 각 캐시는 다음과 같은 구성 옵션을 제공합니다.

"core-service" : { ​
  "management" : { ​
    "security-realm" : { ​
      "LDAPRealm" : { ​
        "authentication" : {
          "ldap" : {
            "allow-empty-passwords" : false,
            "base-dn" : "...", ​
            "connection" : "MyLdapConnection", ​
            "recursive" : false, ​
            "user-dn" : "dn", ​
            "username-attribute" : "uid", ​
            "cache" : null
          }
        },
        "authorization" : {
          "ldap" : {
            "connection" : "MyLdapConnection", ​
            "group-search" : {
              "group-to-principal" : { ​
                "base-dn" : "...", ​
                "group-dn-attribute" : "dn", ​
                "group-name" : "SIMPLE", ​
                "group-name-attribute" : "uid", ​
                "iterative" : true, ​
                "principal-attribute" : "uniqueMember", ​
                "search-by" : "DISTINGUISHED_NAME", ​
                "cache" : null ​
              }
            }, ​
            "username-to-dn" : {
              "username-filter" : { ​
                "attribute" : "uid", ​
                "base-dn" : "...", ​
                "force" : false, ​
                "recursive" : false, ​
                "user-dn-attribute" : "dn", ​
                "cache" : null ​
                }
              } ​
            }
          }, ​
        } ​
      } ​
  }
}

"cache" : null 이 표시되는 모든 영역에서 캐시를 구성할 수 있습니다.

/core-service=management/security-realm=LDAPRealm:read-resource(recursive=true)

{ ​
  "outcome" => "success", ​
  "result" => { ​
    "map-groups-to-roles" => true, ​
    "authentication" => {
      "ldap" => { ​
        "advanced-filter" => undefined, ​
        "allow-empty-passwords" => false, ​
        "base-dn" => "dc=example,dc=com", ​
         "connection" => "ldapConnection", ​
         "recursive" => true, ​
         "user-dn" => "dn", ​
         "username-attribute" => "uid",
         "cache" => undefined ​
        }
      }, ​
      "authorization" => {
        "ldap" => { ​
          "connection" => "ldapConnection", ​
          "group-search" => {
            "principal-to-group" => { ​
              "group-attribute" => "description", ​
              "group-dn-attribute" => "dn", ​
              "group-name" => "SIMPLE", ​
              "group-name-attribute" => "cn", ​
              "iterative" => false, ​
              "prefer-original-connection" => true, ​
              "skip-missing-groups" => false, ​
              "cache" => undefined ​
            }
          }, ​
          "username-to-dn" => {
            "username-filter" => { ​
              "attribute" => "uid", ​
              "base-dn" => "ou=Users,dc=jboss,dc=org", ​
              "force" => true, ​
              "recursive" => false, ​
              "user-dn-attribute" => "dn", ​
              "cache" => undefined ​
            }
          } ​
        }
      }, ​
      "plug-in" => undefined, ​
      "server-identity" => undefined ​
    }
  ​}

/core-service=management/security-realm=LDAPRealm/authentication=ldap/cache=by-access-time:add(eviction-time=300, cache-failures=true, max-cache-size=100)

/core-service=management/security-realm=LDAPRealm/authentication=ldap/cache=by-search-time:add(eviction-time=300, cache-failures=true, max-cache-size=100)

/core-service=management/security-realm=LDAPRealm/authentication=ldap/cache=by-access-time:read-resource(include-runtime=true)

{
  "outcome" => "success",
  "result" => {
    "cache-failures" => true,
    "cache-size" => 1,
    "eviction-time" => 300,
    "max-cache-size" => 100
  }
}

/core-service=management/security-realm=LDAPRealm/authentication=ldap/cache=by-access-time:contains(name=TestUserOne)

{
  "outcome" => "success",
  "result" => true
}

/core-service=management/security-realm=LDAPRealm/authentication=ldap/cache=by-access-time:flush-cache(name=TestUserOne)

/core-service=management/security-realm=LDAPRealm/authentication=ldap/cache=by-access-time:flush-cache()

/core-service=management/security-realm=LDAPRealm/authentication=ldap/cache=by-access-time:remove()

reload