16.3. Elytron을 사용하여 자카르타 인증 보안 구성

JBoss EAP 7.3부터 elytron 하위 시스템은 Jakarta Authentication에서 서블릿 프로필 구현을 제공합니다. 이를 통해 Elytron에서 제공하는 보안 기능과 보다 긴밀하게 통합할 수 있습니다.

웹 애플리케이션에 대한 자카르타 인증 활성화

웹 애플리케이션에 대해 Jakarta Authentication 통합을 사용하려면 웹 애플리케이션을 Elytron http-authentication-factory 또는 security- domain 과 연결해야 합니다. 이렇게 하면 배포에 사용할 Elytron 보안 핸들러가 설치되고 배포에 대해 Elytron 보안 프레임워크가 활성화됩니다.

배포에 대해 Elytron 보안 프레임워크가 활성화되면 요청이 처리될 때 전역적으로 등록된 AuthConfigFactory 가 쿼리됩니다. 해당 배포에 사용해야 하는 AuthConfigProvider 가 등록되었는지 확인합니다. AuthConfigProvider 가 있는 경우 배포 인증 구성 대신 JASPI 인증이 사용됩니다. AuthConfigProvider 를 찾을 수 없는 경우 배포에 대한 인증 구성이 대신 사용됩니다. 이로 인해 다음과 같은 세 가지 가능성 중 하나가 발생할 수 있습니다.

  • http-authentication-factory 의 인증 메커니즘 사용.
  • web.xml 에 지정된 메커니즘 사용.
  • 애플리케이션에 정의된 메커니즘이 없는 경우 인증이 수행되지 않습니다.

AuthConfigFactory 에 수행된 업데이트는 즉시 사용할 수 있습니다. 즉 AuthConfigProvider 가 등록되고 기존 애플리케이션과 일치하는 경우 애플리케이션을 재배포할 필요 없이 즉시 사용할 수 있습니다.

JBoss EAP에 배포된 모든 웹 애플리케이션에는 보안 도메인이 있으며, 다음 순서로 해결됩니다.

  1. 배포 설명자 또는 주석에서 다음을 수행합니다.
  2. undertow 하위 시스템의 default-security-domain 특성에 정의된 값입니다.
  3. 기본값은 other 입니다.
참고

이 보안 도메인은 PicketBox 보안 도메인에 대한 참조라고 가정하므로 활성화의 최종 단계는 undertow 하위 시스템에서 application-security-domain 리소스를 사용하여 Elytron에 매핑되도록 합니다.

이 매핑은 다음 중 하나를 수행할 수 있습니다.

  • 예를 들면 다음과 같습니다.

    /subsystem=undertow/application-security-domain=MyAppSecurity:add(security-domain=ApplicationDomain)
  • 인증 메커니즘 인스턴스를 가져오려면 http-authentication-factory 리소스를 참조합니다. 예를 들면 다음과 같습니다.

    /subsystem=undertow/application-security-domain=MyAppSecurity:add(http-authentication-factory=application-http-authentication)

Jakarta Authentication 통합을 활성화하기 위한 최소 단계는 다음과 같습니다.

  1. default-security-domain 속성이 기본적으로 다른 사용자로 설정되도록 undertow 하위 시스템에서 정의되지 않은 상태로 둡니다.
  2. 다른 항목의 application-security-domain 매핑을 Elytron 보안 도메인에 추가합니다.

이러한 단계에서 배포와 연결된 보안 도메인은 인증에 사용되는 ServerAuthModule 인스턴스로 전달될 콜백Handler 로 래핑되는 보안 도메인입니다.

추가 옵션

Jakarta Authentication 동작을 추가로 제어할 수 있도록 두 개의 추가 특성이 application-security-domain 리소스에 추가되었습니다.

표 16.1. application-security-domain 리소스에 추가된 특성

속성설명

enable-jaspi

이 매핑을 사용하는 모든 배포에 대한 Jakarta Authentication 지원을 비활성화하려면 false로 설정할 수 있습니다.

integrated-jaspi

기본적으로 모든 ID는 보안 도메인에서 로드됩니다. false로 설정하면 대신 임시 ID가 생성됩니다.

하위 시스템 설정

배포에 AuthConfigProvider 가 반환되는 구성을 등록하는 한 가지 방법은 elytron 하위 시스템에 jaspi-configuration 을 등록하는 것입니다.

다음 명령은 두 개의 ServerAuthModule 정의가 포함된 구성을 추가하는 방법을 보여줍니다.

/subsystem=elytron/jaspi-configuration=simple-configuration:add(layer=HttpServlet, application-context="default-host /webctx", description="Elytron Test Configuration", server-auth-modules=[{class-name=org.wildfly.security.examples.jaspi.SimpleServerAuthModule, module=org.wildfly.security.examples.jaspi, flag=OPTIONAL, options={a=b, c=d}}, {class-name=org.wildfly.security.examples.jaspi.SecondServerAuthModule, module=org.wildfly.security.examples.jaspi}])

이렇게 하면 다음과 같은 구성이 지속됩니다.

<jaspi>
    <jaspi-configuration name="simple-configuration" layer="HttpServlet" application-context="default-host /webctx" description="Elytron Test Configuration">
        <server-auth-modules>
            <server-auth-module class-name="org.wildfly.security.examples.jaspi.SimpleServerAuthModule" module="org.wildfly.security.examples.jaspi" flag="OPTIONAL">
                <options>
                    <property name="a" value="b"/>
                    <property name="c" value="d"/>
                </options>
            </server-auth-module>
            <server-auth-module class-name="org.wildfly.security.examples.jaspi.SecondServerAuthModule" module="org.wildfly.security.examples.jaspi"/>
        </server-auth-modules>
    </jaspi-configuration>
</jaspi>
참고

name 특성은 관리 모델에서 리소스를 참조할 수 있는 이름일 뿐입니다.

이 구성을 AuthConfigFactory 에 등록할 때 계층application-context 속성이 사용됩니다. 두 속성 모두 와일드카드 일치를 생략할 수 있습니다. description 속성도 선택 사항이며 AuthConfigFactory 에 설명을 제공하는 데 사용됩니다.

구성 내에서 다음 특성을 사용하여 하나 이상의 server-auth-module 인스턴스를 정의할 수 있습니다.

  • class-name - ServerAuthModule 의 정규화된 클래스 이름입니다.
  • module - ServerAuthModule을 로드할 모듈 입니다.
  • flag - 이 모듈이 다른 모듈과 관련하여 작동하는 방식을 나타내는 제어 플래그입니다.
  • 옵션 - 초기화 시 ServerAuthModule 에 전달할 구성 옵션입니다.

이러한 방식으로 정의된 구성은 AuthConfigFactory 에 즉시 등록됩니다. 계층애플리케이션 컨텍스트 와 일치하는 Elytron 보안 프레임워크를 사용하는 기존 배포는 이 구성을 즉시 사용하기 시작합니다.

프로그래밍 방식 설정

Jakarta Authentication 사양에 정의된 API를 사용하면 애플리케이션이 사용자 지정 AuthConfigProvider 인스턴스를 동적으로 등록할 수 있습니다. 그러나 사양은 사용할 실제 구현 또는 구현 인스턴스를 생성하는 표준 방법을 제공하지 않습니다. Elytron 프로젝트에는 배포에서 이를 지원하는 데 사용할 수 있는 간단한 유틸리티가 포함되어 있습니다.

다음 코드 예제에서는 이 API를 사용하여 위의 하위 시스템 구성에 설명된 것과 유사한 구성을 등록하는 방법을 보여줍니다.

String registrationId = org.wildfly.security.auth.jaspi.JaspiConfigurationBuilder.builder("HttpServlet", servletContext.getVirtualServerName() + " " + servletContext.getContextPath())
    .addAuthModuleFactory(SimpleServerAuthModule::new, Flag.OPTIONAL, Collections.singletonMap("a", "b"))
    .addAuthModuleFactory(SecondServerAuthModule::new)
.register();

예를 들어 서블릿의 init() 메서드 내에서 이 코드를 실행하여 해당 배포에 고유한 AuthConfigProvider 를 등록할 수 있습니다. 이 코드 예제에서는 ServletContext 를 컨설팅하여 애플리케이션 컨텍스트도 어셈블했습니다.

register() 메서드는 AuthConfigFactory 에서 이 등록을 직접 제거하는 데 사용할 수도 있는 결과 등록 ID를 반환합니다.

하위 시스템 구성과 마찬가지로 이 호출은 Elytron 보안 프레임워크를 사용하는 모든 웹 애플리케이션에 즉시 적용됩니다.

인증 프로세스

undertow 하위 시스템에서 application-security-domain 리소스의 구성에 따라 ServerAuthModule 에 전달된 CallbackHandler 는 다음 모드 중 하나에서 작동할 수 있습니다.

통합 모드

통합 모드에서 작동하는 경우 ServerAuthModule 인스턴스가 실제 인증을 처리하지만 해당 SecurityDomain에서 참조하는 Security Realms를 사용하여 참조된 Security Domain 에서 생성된 ID가 로드됩니다 . 이 모드에서는 서블릿 컨테이너 내에서 할당할 역할을 재정의할 수 있습니다.

이 모드의 장점은 ServerAuthModule이 ID 로드를 위한 Elytron 구성을 활용하여 데이터베이스 및 LDAP와 같은 일반적인 위치에 저장된 ID를 로드할 수 있다는 것입니다. ServerAuthModule 은 이러한 위치를 인식할 필요가 없습니다. 또한 역할 및 권한 매핑과 같은 기타 Elytron 구성을 적용할 수 있습니다. 참조된 SecurityDomain 은 SASL 인증 또는 기타 비 JASPI 애플리케이션에 대해 참조할 수도 있으며, 모두 공통 ID 저장소에서 지원합니다.

표 16.2. 통합 모드에서 콜백Handlers 메서드의 작동.

작업설명

PasswordValidationCallback

사용자 이름과 암호는 인증을 수행하기 위해 SecurityDomain 과 함께 사용됩니다. 성공하면 인증된 ID가 있습니다.

CallerPrincipalCallback

콜백 은 요청이 웹 애플리케이션에 도달한 후 사용할 수 있는 인증된 ID 또는 ID를 설정하는 데 사용됩니다.

참고

PasswordValidationCallback 을 통해 인증된 ID가 이미 설정된 경우 이 콜백 은 런스 요청으로 해석됩니다. 이 경우 인증된 ID가 이 콜백 에 지정된 ID로 실행되도록 권한 부여 검사를 수행합니다. PasswordValidationCallback 에서 인증된 ID를 설정하지 않은 경우 ServerAuthModule 에서 인증 단계를 처리한 것으로 간주됩니다.

null 주체 및 이름을 사용하여 콜백 이 수신되면 다음을 수행합니다.

  • 인증된 ID가 이미 설정된 경우 권한 부여가 해당 ID로 수행됩니다.
  • ID를 설정하지 않은 경우 익명 ID에 대한 권한 부여가 수행됩니다.

익명 ID에 대한 권한 부여가 수행되는 경우 익명 ID에 LoginPermission 을 부여하도록 SecurityDomain 을 구성해야 합니다.

GroupPrincipalCallback

이 모드에서는 보안 도메인에 구성된 로드, 역할 디코딩 및 역할 매핑이 ID를 설정하는 데 사용됩니다. 이 콜백 이 수신되면 지정된 그룹을 사용하여 ID에 할당된 역할을 결정합니다. 요청은 서블릿 컨테이너에 있으며 이러한 역할은 서블릿 컨테이너에만 표시됩니다.

통합되지 않은 모드

통합되지 않은 모드에서 작동하는 경우 ServerAuthModule은 모든 인증 및 ID 관리를 완벽하게 담당합니다. 지정된 콜백을 사용하여 ID를 설정할 수 있습니다. 결과 ID는 SecurityDomain 에서 생성되지만 참조된 SecurityRealms 에 저장된 ID와 독립적입니다.

이 모드의 장점은 간단한 SecurityDomain 정의를 넘어 어떤 것도 요구하지 않고도 ID를 완전히 처리할 수 있는 JASPI 구성을 애플리케이션 서버에 배포할 수 있다는 점입니다. 이 SecurityDomain 에는 런타임 시 사용할 ID를 실제로 포함할 필요가 없습니다. 이 모드의 단점은 이제 ServerAuthModule 이 모든 ID 처리를 담당하므로 구현이 훨씬 더 복잡해질 수 있다는 것입니다.

표 16.3. 통합되지 않은 모드에서 콜백Handlers 메서드의 작업입니다.

작업설명

PasswordValidationCallback

이 모드에서는 콜백 이 지원되지 않습니다. 이 모드의 목적은 ServerAuthModule 이 참조된 SecurityDomain 과 독립적으로 작동하기 위한 것입니다. 암호를 검증하도록 요청하는 것은 적합하지 않습니다.

CallerPrincipalCallback

콜백 은 결과 ID의 주체를 설정하는 데 사용됩니다. ServerAuthModule 은 모든 ID 검사 요구 사항을 처리하므로 보안 도메인에 ID가 존재하고 권한 부여 확인이 수행되지 않는지 확인하기 위해 검사가 수행되지 않습니다.

콜백 이 null 주체 및 이름으로 수신되면 ID가 익명 ID로 설정됩니다. ServerAuthModule 이 결정을 내리기 때문에 권한 부여 확인은 SecurityDomain 을 사용하여 수행되지 않습니다.

GroupPrincipalCallback

SecurityDomain 에서 로드하지 않고 이 모드에서 ID가 생성되므로 기본적으로 역할이 할당되지 않습니다. 이 콜백 이 수신되면 요청이 서블릿 컨테이너에 있는 동안 그룹을 가져와 결과 ID에 할당합니다. 이러한 역할은 서블릿 컨테이너에만 표시됩니다.

validateRequest

ServerAuthContext 에서 validateRequest 를 호출하는 동안 개별 ServerAuthModule 인스턴스가 정의된 순서대로 호출됩니다. 각 모듈에 대해 컨트롤 플래그를 지정할 수도 있습니다. 이 플래그는 응답을 해석하는 방법과 처리가 다음 서버 인증 모듈로 계속 진행되어야 하는지 또는 즉시 반환해야 하는지 정의합니다.

컨트롤 플래그

구성이 elytron 하위 시스템 내에서 제공되거나 JaspiConfigurationBuilder API를 사용하는지 여부에 따라 컨트롤 플래그를 각 ServerAuthModule 과 연결할 수 있습니다. 지정하지 않으면 기본값은 REQUIRED 입니다. 플래그에는 결과에 따라 다음과 같은 의미가 있습니다.

플래그AuthStatus.SEND_SUCCESSAuthStatus.SEND_FAILURE, AuthStatus.SEND_CONTINUE

필수 항목

검증은 나머지 모듈로 계속됩니다. 나머지 모듈의 요구 사항이 충족되면 요청을 계속할 수 있습니다.

검증은 나머지 모듈로 계속됩니다. 그러나 결과에 관계없이 검증에 성공하지 않고 제어 권한이 클라이언트로 돌아갑니다.

필수 사항

검증은 나머지 모듈로 계속됩니다. 나머지 모듈의 요구 사항이 충족되면 요청을 계속할 수 있습니다.

요청은 즉시 클라이언트로 반환됩니다.

충분하지 않음

검증은 이전에 필수 또는 필수 모듈이 AuthStatus. SUCCESS 이외의 AuthStatus 를 반환하지 않은 경우 성공 및 완료로 간주됩니다. 요청이 보안 리소스의 권한 부여로 진행됩니다.

검증을 통해 나머지 모듈 목록이 계속 중단됩니다. 이 상태는 REQUIRED 또는 REQUISITE 모듈이 없는 경우에만 결정에 영향을 미칩니다.

선택 사항

검증은 필수 또는 필수 모듈이 SUCCESS 를 반환하지 않은 경우에도 나머지 모듈에 계속 유지됩니다. 이는 검증이 성공으로 간주되고 권한 부여 단계 및 보안 리소스로 진행하기 위한 요청을 진행하기에 충분합니다.

검증을 통해 나머지 모듈 목록이 계속 중단됩니다. 이 상태는 REQUIRED 또는 REQUISITE 모듈이 없는 경우에만 결정에 영향을 미칩니다.

참고

모든 ServerAuthModule 인스턴스의 경우 AuthException 이 발생하면 추가 모듈 호출 없이 클라이언트에 즉시 오류가 보고됩니다.

secureResponse

secureResponse 호출 중에 각 ServerAuthModule 이 호출되지만 이번에는 모듈이 secureResponse 에서 작업을 수행하는 역순으로 호출됩니다. 모듈이 validateResponse 에서 작업을 수행한 경우 이를 추적할 모듈의 책임이 있습니다.

control 플래그는 secureResponse 처리에 영향을 미치지 않습니다. 다음 중 하나가 true이면 처리가 종료됩니다.

  • 모든 ServerAuthModule 인스턴스가 호출되었습니다.
  • 모듈은 AuthStatus.SEND_FAILURE 를 반환합니다.
  • 모듈에서 AuthException 이 발생합니다.
보안 ID 생성

인증 프로세스가 완료되면 배포에 대한 org.wildfly.security.auth.server.SecurityIdentity Callbacks to the Callback Handler 의 결과로 생성됩니다. 콜백에 따라 SecurityDomain 에서 직접 로드된 ID이거나 콜백에서 설명하는 임시 ID가 됩니다. 이 SecurityIdentity 는 다른 인증 메커니즘에 대해 수행하는 것과 동일한 방식으로 요청과 연결됩니다.