인증 교환.

주체가 먼저 네트워크에 액세스하거나 TGT( 티켓 부여 티켓) 없이 보안 서비스에 액세스하려고 하면 자격 증명을 사용하여 인증 서비스(AS)에 대해 인증해야 합니다. AS는 구성된 ID 저장소에 대해 사용자 제공 자격 증명을 검증하고 성공적인 인증을 받으면 클라이언트가 캐시하는 TGT를 발행합니다. 또한 TGT에는 몇 가지 세션 정보가 포함되어 클라이언트와 KDC 간의 향후 통신이 보호됩니다.

교환 또는 권한 부여, 티켓 부여.

주체가 TGT를 발행하면 보안 서비스 또는 리소스에 액세스를 시도할 수 있습니다. 주체는 티켓 부여 서비스(TGS)에 요청을 보내 KDC에서 발급한 TGT를 전달하고 특정 목적지에 대한 서비스 티켓(ST)을 요청합니다. TGS는 주체가 제공하는 TGT를 확인하고 요청된 리소스에 액세스할 수 있는 적절한 권한이 있는지 확인합니다. 성공하면 TGS는 주체가 특정 대상에 액세스하기 위해 ST를 발행합니다. 또한 TGS는 두 클라이언트와 대상 서버 모두에 대한 세션 정보를 생성하여 둘 사이의 안전한 통신을 허용합니다. 클라이언트와 서버가 KDC에서 각각 제공하는 장기 키를 사용하여 이전 트랜잭션에서 각각에 이르기까지 자체 세션 정보만 해독할 수 있도록 이 세션 정보는 별도로 암호화됩니다. TGS는 클라이언트와 서버 모두에 대한 세션 정보를 포함하는 ST를 사용하여 클라이언트에 응답합니다.

서버 액세스.

이제 주체는 보안 서비스의 ST와 해당 서버와의 보안 통신을 위한 메커니즘을 보유하므로 이제 클라이언트는 연결을 설정하고 보안 리소스에 액세스를 시도할 수 있습니다. 클라이언트는 ST를 대상 서버에 전달하여 시작합니다. 이 ST에는 해당 대상을 위해 TGS에서 수신한 세션 정보의 서버 구성 요소가 포함되어 있습니다. 서버는 KDC에서 장기 키를 사용하여 클라이언트가 전달하는 세션 정보를 암호 해독하려고 합니다. 성공하면 클라이언트가 서버에 성공적으로 인증되고 서버가 클라이언트에 인증된 것으로 간주됩니다. 이때 클라이언트와 서버 간에 신뢰가 설정되고 보안 통신을 진행할 수 있습니다.

kerberos-security-factory 구성.

/subsystem=elytron/kerberos-security-factory=krbSF:add(principal="HTTP/host@REALM", path="/path/to/http.keytab", mechanism-oids=[1.2.840.113554.1.2.2, 1.3.6.1.5.5.2])

Kerberos의 시스템 속성을 구성합니다.

환경을 구성하는 방법에 따라 아래의 일부 시스템 속성을 설정해야 합니다.

관리 CLI를 사용하여 JBoss EAP에서 시스템 속성을 구성하려면 다음을 수행합니다.

/system-property=java.security.krb5.conf:add(value="/path/to/krb5.conf")

역할을 할당하기 위한 Elytron 보안 영역을 구성합니다.

클라이언트의 Kerberos 토큰은 주체를 제공하지만 해당 주체를 애플리케이션의 역할에 매핑하는 방법이 필요합니다. 이 작업을 수행하는 방법에는 여러 가지가 있지만, 이 예제에서는 filesystem-realm 을 생성하고 Kerberos 토큰의 주체와 일치하는 영역에 사용자를 추가하고 해당 사용자에게 역할을 할당합니다.

simple-role-decoder 추가.

/subsystem=elytron/simple-role-decoder=from-roles-attribute:add(attribute=Roles)

이 simple-role-decoder 는 Roles 특성에서 주체 역할을 디코딩합니다. 역할이 다른 특성에 있는 경우 이 값을 변경할 수 있습니다.

security-domain 구성.

/subsystem=elytron/security-domain=exampleFsSD:add(realms=[{realm=exampleFsRealm, role-decoder=from-roles-attribute}], default-realm=exampleFsRealm, permission-mapper=default-permission-mapper)

kerberos -security-factory를 사용하는 http-authentication -factory 를 구성합니다.

/subsystem=elytron/http-authentication-factory=example-krb-http-auth:add(http-server-mechanism-factory=global, security-domain=exampleFsSD, mechanism-configurations=[{mechanism-name=SPNEGO, mechanism-realm-configurations=[{realm-name=exampleFsSD}], credential-security-factory=krbSF}])

undertow 하위 시스템에서 application-security-domain 을 구성합니다.

/subsystem=undertow/application-security-domain=app-spnego:add(http-authentication-factory=example-krb-http-auth)

서버 ID 또는 호스트 보안 도메인을 구성합니다.

이 보안 도메인은 컨테이너 자체를 KDC에 인증합니다. 실제 사용자가 이 연결에 참여하지 않으므로 정적 로그인 메커니즘을 허용하는 로그인 모듈을 사용해야 합니다. 다음 예제에서는 정적 주체를 사용하고 자격 증명을 포함하는 keytab 파일을 참조합니다.

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

/subsystem=security/security-domain=host/authentication=classic:add()

/subsystem=security/security-domain=host/authentication=classic/login-module=Kerberos:add(code=Kerberos, flag=required, module-options=[storeKey=true, refreshKrb5Config=true, useKeyTab=true, principal=host/testserver@MY_REALM, keyTab=/home/username/service.keytab, doNotPrompt=true, debug=false])

reload

IBM JDK를 사용하는 경우 Kerberos 모듈에 대한 옵션이 다릅니다. jboss.security.disable.secdomain.option 시스템 속성을 true 로 설정해야 합니다. 자세한 내용은 Configure 관련 시스템 속성 에서 참조하십시오. 또한 로그인 모듈은 다음과 같이 구성해야 합니다.

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

/subsystem=security/security-domain=host/authentication=classic:add()

/subsystem=security/security-domain=host/authentication=classic/login-module=Kerberos:add(code=Kerberos, flag=required, module-options=[principal=host/testserver@MY_REALM, keyTab="file:///root/keytab", credsType=acceptor])

reload

Kerberos 로그인 모듈 구성을 위한 전체 옵션 목록은 JBoss EAP 로그인 모듈 참조를 참조하십시오.

웹 애플리케이션 보안 도메인을 구성합니다.

웹 애플리케이션 보안 도메인은 개별 사용자를 KDC에 인증하는 데 사용됩니다. 사용자를 인증하려면 하나 이상의 로그인 모듈이 있어야 합니다. 또한 사용자에게 적용할 역할을 검색하는 방법도 있어야 합니다. 이 작업은 사용자를 역할에 수동으로 매핑하는 <mapping> 을 추가하고 사용자를 역할에 매핑하는 두 번째 로그인 모듈을 추가하는 등 다양한 방법으로 수행할 수 있습니다.

다음은 웹 애플리케이션 보안 도메인의 예를 보여줍니다.

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

/subsystem=security/security-domain=app-spnego/authentication=classic:add()

/subsystem=security/security-domain=app-spnego/authentication=classic/login-module=SPNEGO:add(code=SPNEGO, flag=required, module-options=[serverSecurityDomain=host])

reload

SPNEGO 로그인 모듈 구성을 위한 전체 옵션 목록은 JBoss EAP 로그인 모듈 참조를 참조하십시오.

관련 시스템 속성 구성.

JBoss EAP는 Kerberos 서버 연결과 관련된 시스템 속성을 구성하는 기능을 제공합니다. KDC, Kerberos 도메인 및 네트워크 구성에 따라 다음 시스템 속성이 필요할 수도 있고 그렇지 않을 수도 있습니다.

<system-properties>
  <property name="java.security.krb5.kdc" value="mykdc.mydomain"/>
  <property name="java.security.krb5.realm" value="MY_REALM"/>
  <property name="java.security.krb5.conf" value="/path/to/krb5.conf"/>
  <property name="jboss.security.disable.secdomain.option" value="true"/>
  <property name="sun.security.krb5.debug" value="false"/>
</system-properties>

시스템 속성 구성에 대한 자세한 내용은 JBoss EAP 관리 CLI 가이드를 참조하십시오.

기존 서비스 주체 매핑 지우기.

Microsoft Windows 네트워크에서 일부 매핑은 자동으로 생성됩니다. 자동으로 생성된 매핑을 삭제하여 서버의 ID를 서비스 주체에 매핑하여 협상을 올바르게 수행합니다. 매핑을 사용하면 클라이언트 컴퓨터에서 웹 브라우저가 서버를 신뢰하고 SPNEGO를 시도할 수 있습니다. 클라이언트 컴퓨터는 HTTP/HOST_NAME 형식으로 매핑에 대한 도메인 컨트롤러로 확인합니다.

다음은 기존 매핑을 삭제하는 단계입니다.

setspn -L MACHINE_NAME

setspn -D HTTP/HOST_NAME MACHINE_NAME

setspn -D host/HOST_NAME MACHINE_NAME

호스트 사용자 계정을 만듭니다.

섹션의 나머지 부분에서 호스트 사용자 이름을 USER_NAME 이라고 합니다.

USER_NAME과 HOST_NAME 간의 매핑을 정의합니다.

다음 명령을 실행하여 서비스 주체 매핑을 구성합니다.

ktpass -princ HTTP/HOST_NAME@REALM -pass * [-kvno 0] -mapuser DOMAIN\USER_NAME -out jboss.keytab -ptype KRB5_NT_PRINCIPAL -crypto all

메시지가 표시되면 사용자 이름의 암호를 입력합니다.

다음 명령을 실행하여 매핑을 확인합니다. setspn -L USER_NAME.

보안 도메인 내에서 주체를 정의합니다.

주체는 elytron 또는 legacy 보안 하위 시스템에서 HTTP/HOST_NAME@REALM 으로 정의하거나 업데이트할 수 있습니다.

Kerberos 및 SPNEGO를 사용하도록 JBoss EAP 및 웹 애플리케이션 구성.

인증 및 권한 부여를 위해 Kerberos 및 SPNEGO를 사용하도록 JBoss EAP와 웹 애플리케이션을 구성하는 데 필요한 단계는 JBoss EAP에 대한 SSO를 Kerberos로 설정하는 방법을 참조하십시오.

로그인 및 오류 페이지를 추가합니다.

FORM 로그인을 사용하려면 로그인 및 오류 페이지가 필요합니다. 이러한 파일은 웹 애플리케이션에 추가되며 인증 프로세스에서 사용됩니다.

<html>
  <head></head>
  <body>
    <form id="login_form" name="login_form" method="post" action="j_security_check" enctype="application/x-www-form-urlencoded">
      <center> <p>Please login to proceed.</p> </center>
      <div style="margin-left: 15px;">
        <p> <label for="username">Username</label> <br /> <input id="username" type="text" name="j_username"/> </p>
        <p> <label for="password">Password</label> <br /> <input id="password" type="password" name="j_password" value=""/> </p>
        <center> <input id="submit" type="submit" name="submit" value="Login"/> </center>
      </div>
    </form>
  </body>
</html>

<html>
  <head></head>
  <body>
    <p>Login failed, please go back and try again.</p>
  </body>
</html>

web.xml 을 수정합니다.

로그인 및 오류 페이지를 웹 애플리케이션에 추가한 후 FORM 로그인을 위해 이러한 파일을 사용하도록 web.xml 을 업데이트해야 합니다. 정확한 값 FORM 은 <auth-method> 요소에 추가해야 합니다. <auth-method> 에는 쉼표로 구분된 목록과 순서가 중요하므로 <auth-method> 의 정확한 값은 SPNEGO,FORM 으로 업데이트해야 합니다. 또한 <form-login-config> 요소를 <login-config>에 추가하고 < form- login-page> 및 <form- error-page> 요소로 지정된 로그인 및 오류 페이지의 경로를 추가해야 합니다.

<web-app>
  <display-name>App1</display-name>
  <description>App1</description>
  <!-- Define a security constraint that requires the Admin role to access resources -->
  <security-constraint>
    <display-name>Security Constraint on Conversation</display-name>
    <web-resource-collection>
      <web-resource-name>examplesWebApp</web-resource-name>
      <url-pattern>/*</url-pattern>
    </web-resource-collection>
    <auth-constraint>
        <role-name>Admin</role-name>
    </auth-constraint>
  </security-constraint>
  <!-- Define the Login Configuration for this Application -->
  <login-config>
    <auth-method>SPNEGO,FORM</auth-method>
    <realm-name>SPNEGO</realm-name>
    <form-login-config>
      <form-login-page>/login.jsp</form-login-page>
      <form-error-page>/error.jsp</form-error-page>
    </form-login-config>
  </login-config>
  <!-- Security roles referenced by this web application -->
  <security-role>
    <description> role required to log in to the Application</description>
    <role-name>Admin</role-name>
  </security-role>
</web-app>

http-authentication-factory 에 FORM 인증 메커니즘을 추가합니다.

kerberos 기반 인증에 대해 구성한 기존 http-authentication-factory 및 FORM 인증을 위한 추가 메커니즘을 사용할 수 있습니다.

/subsystem=elytron/http-authentication-factory=example-krb-http-auth:list-add(name=mechanism-configurations, value={mechanism-name=FORM})

대체 주체 추가.

kerberos 기반 인증에 대한 기존 구성에 kerberos 토큰의 주체를 애플리케이션의 역할로 매핑하기 위해 이미 보안 영역이 구성되어 있어야 합니다. 해당 영역에 대한 대체 인증을 위해 추가 사용자를 추가할 수 있습니다. 예를 들어 filesystem-realm 을 사용한 경우 적절한 역할을 사용하여 새 사용자를 생성할 수 있습니다.

애플리케이션에 대한 Kerberos 인증을 구성하는 것과 동일한 지침에 따라 Kerberos 인증을 수행하는 http-authentication-factory 를 생성합니다.

http-authentication-factory 를 사용하도록 관리 HTTP 인터페이스를 업데이트합니다.

/core-service=management/management-interface=http-interface:write-attribute(name=http-authentication-factory, value=example-krb-http-auth)

구성 가능-sasl-server-factory 에 GSSAPI 를 추가합니다.

/subsystem=elytron/configurable-sasl-server-factory=configured:list-add(name=filters, value={pattern-filter=GSSAPI})

보안 도메인 및 kerberos -security-factory를 사용하는 asasl-authentication -factory 를 생성합니다.

/subsystem=elytron/sasl-authentication-factory=example-sasl-auth:add(sasl-server-factory=configured, security-domain=exampleFsSD, mechanism-configurations=[{mechanism-name=GSSAPI, mechanism-realm-configurations=[{realm-name=exampleFsSD}], credential-security-factory=krbSF}])

the sasl-authentication-factory 를 사용하도록 관리 SASL 인터페이스를 업데이트합니다.

/core-service=management/management-interface=http-interface:write-attribute(name=http-upgrade.sasl-authentication-factory, value=example-sasl-auth)

reload

관련 시스템 속성을 활성화합니다.

이전 섹션에서 설명한 대로 Kerberos 서버 연결을 위해 필요한 모든 JBoss EAP 시스템 속성을 활성화합니다.

Kerberos 서버 ID를 보안 영역에 추가합니다.

보안 영역에서 Kerberos 인증을 사용하려면 Kerberos 서버에 대한 연결을 추가해야 합니다. 다음 예제에서는 Kerberos 서버 ID를 기존 Management Realm에 추가하는 방법을 보여줍니다. service-name,hostname, MY-REALM 을 적절한 값으로 교체해야 합니다.

/core-service=management/security-realm=ManagementRealm/server-identity=kerberos:add()

/core-service=management/security-realm=ManagementRealm/server-identity=kerberos/keytab=service-name\/hostname@MY-REALM:add(path=/home\/username\/service.keytab, debug=true)

reload

보안 영역에서 인증 방법을 업데이트합니다.

Kerberos 서버 ID를 올바르게 구성한 후 이를 사용하려면 보안 영역의 인증 방법을 업데이트해야 합니다.

/core-service=management/security-realm=ManagementRealm/authentication=kerberos:add()

reload

Kerberos를 사용하여 두 인터페이스의 보안을 모두 유지합니다.

Kerberos를 사용하여 웹 기반 관리 콘솔과 관리 CLI를 모두 보호하려면 각각에 대해 구성된 Kerberos 서버 ID가 필요합니다. 추가 ID를 추가하려면 다음 명령을 사용합니다.

/core-service=management/security-realm=ManagementRealm/server-identity=kerberos/keytab=remote\/hostname@MY-REALM:add(path=/home\/username\/remote.keytab, debug=true)

reload

원격 및 RealmDirect를 사용하여 보안 도메인 구성

원격 를 통해 액세스하는 서비스에서 사용할 보안 도메인을 구성해야 합니다. 이 보안 도메인은 Remoting 로그인 모듈과 RealmDirect 로그인 모듈(예: RealmDirect 또는 RealmUsersRoles )을 모두 사용해야 합니다. 기본적으로 기본적으로 제공된 other 보안 도메인과 매우 유사해야 합니다. 각 로그인 모듈의 특정 구성 옵션에 대한 자세한 내용은 JBoss EAP 로그인 모듈 참조를 참조하십시오.

/subsystem=security/security-domain=krb-remoting-domain:add()

/subsystem=security/security-domain=krb-remoting-domain/authentication=classic:add()

/subsystem=security/security-domain=krb-remoting-domain/authentication=classic/login-module=Remoting:add(code=Remoting, flag=optional, module-options=[password-stacking=useFirstPass])

/subsystem=security/security-domain=krb-remoting-domain/authentication=classic/login-module=RealmDirect:add(code=RealmDirect, flag=required, module-options=[password-stacking=useFirstPass, realm=krbRealm])

/subsystem=security/security-domain=krb-remoting-domain/mapping=classic:add()

/subsystem=security/security-domain=krb-remoting-domain/mapping=classic/mapping-module=SimpleRoles:add(code=SimpleRoles, type=role, module-options=["testUser"="testRole"])

reload

Kerberos 인증을 위한 보안 영역 구성.

Kerberos 인증을 사용하여 보안 영역 설정은 Kerberos로 관리 인터페이스 보안 섹션에서 설명합니다.

/core-service=management/security-realm=krbRealm:add()

/core-service=management/security-realm=krbRealm/server-identity=kerberos:add()

/core-service=management/security-realm=krbRealm/server-identity=kerberos/keytab=remote\/localhost@JBOSS.ORG:add(path=\/path\/to\/remote.keytab, debug=true)

/core-service=management/security-realm=krbRealm/authentication=kerberos:add(remove-realm=true)

reload

원격 하위 시스템에서 HTTP 커넥터를 구성합니다.

또한 원격 시스템에서 새로 만든 보안 영역을 사용하도록 HTTP 커넥터를 구성해야 합니다.

/subsystem=remoting/http-connector=http-remoting-connector:write-attribute(name=security-realm, value=krbRealm)

서비스의 보안을 구성합니다.

또한 원격 인터페이스를 사용하여 액세스한 서비스를 보호하도록 설정해야 합니다. 서비스에 따라 달라집니다. 예를 들어 Jakarta Enterprise Bean에서는 @SecurityDomain 및 @ RolesAllowed 주석을 사용할 수 있습니다.

ID를 로드할 보안 영역을 정의합니다. 역할을 할당하는 데 사용됩니다.

/path=kerberos:add(relative-to=user.home, path=src/kerberos)

/subsystem=elytron/properties-realm=kerberos-properties:add(users-properties={path=kerberos-users.properties, relative-to=kerberos, digest-realm-name=ELYTRON.ORG}, groups-properties={path=kerberos-groups.properties, relative-to=kerberos})

서버 ID에 대한 Kerberos 보안 팩토리를 정의합니다.

/subsystem=elytron/kerberos-security-factory=test-server:add(relative-to=kerberos, path=remote-test-server.keytab, principal=remote/test-server.elytron.org@ELYTRON.ORG)

보안 도메인을 정의하고 SASL 인증 팩토리를 함께 정의합니다.

/subsystem=elytron/security-domain=KerberosDomain:add(default-realm=kerberos-properties, realms=[{realm=kerberos-properties, role-decoder=groups-to-roles}], permission-mapper=default-permission-mapper)

/subsystem=elytron/sasl-authentication-factory=gssapi-authentication-factory:add(security-domain=KerberosDomain, sasl-server-factory=elytron, mechanism-configurations=[{mechanism-name=GSSAPI, credential-security-factory=test-server}])

원격 하위 시스템에서 created sasl-authentication-factory 를 사용하여 원격 작업을 활성화합니다.

/subsystem=remoting/http-connector=http-remoting-connector:write-attribute(name=sasl-authentication-factory, value=gssapi-authentication-factory)

서비스의 보안을 구성합니다.

Jakarta Enterprise Beans에서 보안 도메인을 참조하는 경우 Elytron 보안 도메인에 매핑되는 application-security-domain 을 지정해야 합니다. 예를 들어 Jakarta Enterprise Beans에서는 @SecurityDomain 주석을 사용할 수 있습니다.

/subsystem=ejb3/application-security-domain=KerberosDomain:add(security-domain=KerberosDomain)