5.5. SAML에서 브라우저 기반 SSO를 사용하는 여러 Red Hat JBoss Enterprise Application Platform 인스턴스 및 다중 애플리케이션

JBoss EAP는 SAML을 통해 웹 애플리케이션과 ID 프로바이더를 호스팅하는 브라우저 기반 SSO를 지원합니다. ID 프로바이더를 호스팅하려면 이 경우 idp-domain 이라는 보안 도메인을 정의된 인증 메커니즘으로 구성해야 합니다. 이 경우 idp-domain 은 인증 메커니즘으로 DatabaseLoginModule 을 사용하도록 구성됩니다. IDP 애플리케이션(예: IDP.war )은 해당 JBoss EAP 인스턴스(이 예에서는 EAP-IDP) 에 배포되고 idp-domain 을 ID 저장소로 사용하도록 구성됩니다. IDP.war 는 애플리케이션의 기능과 함께 ID 저장소를 사용하여 사용자를 인증하고 사용자의 ID 및 역할 정보를 포함하는 SAML 토큰을 발행합니다. 다음 세 가지 추가 JBoss EAP 인스턴스: EAP1,EAP2 및 EAP3 는 각각 개별 SP, sampleAppA.war, sampleAppB.war 및 sampleApp C 역할을 할 하나의 고유한 애플리케이션입니다. 각 JBoss EAP 인스턴스에는 SAML2LoginModule 을 인증 메커니즘으로 사용하도록 구성된 보안 도메인인 sso-domain 이 있습니다. 각 애플리케이션에는 SSO를 지원하고, ID 공급자로 IDP.war 를 사용하고, 인증에 HTTP/POST 바인딩을 사용하는 기능이 포함되어 있습니다. 또한 각 애플리케이션은 경로 /secure/* 를 보안하도록 usesso -domain 을 구성하고 권한 부여를 처리하기 위한 고유한 역할 목록을 제공합니다.

이 시나리오의 경우 다음 사용자가 idp-domain 보안 도메인의 DatabaseLoginModule 에서 사용하는 데이터베이스에 추가되었습니다.

EAP-IDP 를 시작할 때 관리 인터페이스가 시작되고 하위 시스템 및 배포된 애플리케이션이 시작됩니다(idp-domain 및 IDP.war. idp-domain 포함 ).idp-domain 은 데이터베이스에 연결하고 DatabaseLoginModule 로그인 모듈에 구성된 대로 사용자 이름, 암호 및 역할을 로드합니다. 중요한 정보가 DatabaseLoginModule 로그인 모듈 구성의 일반 텍스트에 저장되지 않도록 암호 해시는 데이터베이스의 암호와 같이 특정 필드를 모호하게 처리하도록 구성됩니다. iDP.war 는 인증 및 권한 부여에 idp-domain 을 사용합니다. 또한 인증된 사용자에게 SAML 토큰을 발행하고 사용자가 인증할 수 있는 간단한 로그인 양식을 제공하기 위해 jboss-web.xml,web.xml, picketlink .xml 및 jboss-deployment-structure.xml을 사용하여 구성되었습니다. 이렇게 하면 IDP 역할을 할 수 있습니다.

EAP1, EAP 2 및 EAP 3 의 시작 시 관리 인터페이스가 시작되고 하위 시스템 및 배포된 애플리케이션이 시작됩니다. 여기에는 각 인스턴스에서 sso-domain 을 포함하는 보안 하위 시스템, sampleAppA.war,sampleAppB.war 및 sampleAppC.war가 포함됩니다. respectively. sso-domain 은 SAML2LoginModule 로그인 모듈을 사용하도록 구성되어 있지만 애플리케이션을 사용하여 적절한 SAML 토큰을 제공합니다. 즉, SAML 토큰을 얻으려면 도메인을 사용하는 모든 애플리케이션이 IDP에 올바르게 연결되어야 합니다. 이 경우 sampleAppA,sampleAppB 및 sampleAppC 는 각각 jboss-web.xml,web.xml, picketlink.xml 및 jboss-deployment-structure.xml 을 통해 IDP, IDP.war 에서 SAML 토큰을 가져오기 위해 IDP의 로그인 양식을 사용합니다.

각 애플리케이션은 또한 허용된 고유한 역할 세트로 구성됩니다.

인증되지 않은 사용자가 모든 애플리케이션의 /secure/* 인 by sso-domain 보안 URL에 액세스하려고 하면 해당 사용자는 IDP.war 의 로그인 페이지로 리디렉션됩니다. 그런 다음 사용자가 양식을 사용하여 인증하고 해당 ID 및 역할 정보를 포함하는 SAML 토큰을 발행합니다. 사용자는 원래 URL로 리디렉션되고 해당 SAML 토큰이 애플리케이션 SP에 표시됩니다. 애플리케이션에서 SAML 토큰이 유효한지 확인한 다음 SAML 토큰에서 제공하는 역할과 애플리케이션에 구성된 역할을 기반으로 사용자에게 권한을 부여합니다. 사용자가 SAML 토큰을 발행하면 해당 토큰을 사용하여 동일한 IDP를 사용하여 SSO가 보안한 다른 애플리케이션에서 인증 및 인증됩니다. SAML 토큰이 만료되거나 무효화되면 사용자는 IDP에서 새 SAML 토큰을 가져와야 합니다.

이 예에서 Eric이 EAP1/sampleAppA/secure/hello.html 에 액세스하는 경우 EAP-IDP/IDP/login.html 로 리디렉션되어 로그인합니다. 성공적으로 로그인한 후 사용자 정보와 역할을 모두 포함하는 SAML 토큰이 발행되며 EAP1/sampleAppA/secure/hello.html 로 리디렉션됩니다. 샘플AppA 에 자신의 SAML 토큰을 확인하고 자신의 역할에 따라 권한을 부여합니다. sampleAppA 는 역할 all 및 AB 가 /secure/* 에 액세스할 수 있고 Eric의 역할이 모두 있으므로 EAP1/sampleAppA/secure/hello.html 에 액세스할 수 있습니다.

Eric이 해당 SP에 대해 아직 인증되지 않았으므로 EAP2/sampleAppB/secure/hello.html 에 액세스하려고 하면 인증 요청을 사용하여 IDP.war 로 리디렉션됩니다. Eric은 이미 IDP에 대해 인증을 받았기 때문에 다시 인증하지 않고도 해당 SP에 대한 새 SAML 토큰을 사용하여 IDP.war 에서 EAP2/sampleAppB/secure/hello.html 로 리디렉션됩니다. sampleAppB 는 새 SAML 토큰을 확인하고 자신의 역할에 따라 권한을 부여합니다. sampleAppB 를 사용하면 all 및 AB 역할이 /secure/* 에 액세스할 수 있고 Eric은 모두 역할을 가지므로 EAP2/sampleAppB/secure/hello.html 에 액세스할 수 있습니다. Eric이 EAP3/sampleAppC/secure/hello.html 에 액세스하려는 경우에도 동일한 사항이 적용됩니다.

Eric이 EAP1/sampleAppA/secure/hello.html 또는 EAP2/sampleAppB/secure/* 또는 EAP3/sampleAppC/secure/* 아래의 모든 URL로 돌아가 SAML 토큰이 전역 로그아웃을 통해 무효화된 후 EAP-IDP/IDP/login.html 로 리디렉션되어 다시 인증하고 새 SAML 토큰을 발행할 수 있습니다.

Amar가 EAP1/sampleAppA/secure/hello.html 또는 EAP2/sampleAppB/secure/hello.html 에 액세스하려고 하면 Eric과 동일한 흐름을 통해 안내됩니다. Amar에서 EAP3/sampleAppC/secure/hello.html 에 액세스하려고 하면 여전히 SAML 토큰을 가지고 있어야 하지만 EAP3/sampleAppC/secure/hello.html에서 EAP1/sampleAppA/secure/hello.html 을 보는 것에서 제한될 수 있습니다. AB 는 EAP1/sampleAppA/secure/* 및 EAP2/sampleAppB/ secure/* 에만 액세스할 수 있기 때문입니다. Brian은 비슷한 상황에 있지만 EAP3/sampleAppC/secure/* 에만 액세스할 수 있습니다. Alan은 서비스 공급자의 보안 영역에 액세스하려고 하면 SAML 토큰을 보유하거나 취득해야 하지만 역할이 없으므로 아무것도 볼 수 없게 제한됩니다. 각 SP에는 인증된 모든 사용자가 SAML 토큰을 가져오지 않고도 볼 수 있는 보안되지 않은 영역이 있습니다.