5.7. 데스크탑 SSO를 사용하여 Kerberos를 사용하여 웹 애플리케이션용 SSO 제공
이 시나리오에서는 Kerberos를 JBoss EAP와 함께 사용하여 웹 애플리케이션에 SSO를 제공하는 방법을 보여줍니다. JBoss EAP 인스턴스는 생성되었으며 독립 실행형 서버로 실행되고 있습니다. 두 개의 웹 애플리케이션( sampleAppA 및 sampleAppB )이 EAP1 에 배포되었습니다. 웹 애플리케이션과 EAP1 은 모두 Kerberos를 통해 데스크탑 기반 SSO를 사용하여 인증하도록 구성되었습니다.
5.7.1. 보안
JBoss EAP는 SPNEGO 및 JBoss 협상을 통해 웹 애플리케이션에서 SSO에 Kerberos 사용을 지원합니다. Kerberos 및 SPNEGO의 세부 사항에 대한 자세한 내용은 타사 SSO 구현 섹션을 참조하십시오. JBoss EAP와 배포된 웹 애플리케이션이 인증에 Kerberos를 사용하도록 활성화하려면 두 개의 보안 도메인을 만들어야 합니다. 첫 번째 보안 도메인인 host-domain 은 Kerberos 서버에 연결하도록 kerberos 로그인 모듈을 사용하여 구성됩니다. 이를 통해 JBoss EAP는 컨테이너 수준에서 인증할 수 있습니다. 두 번째 보안 도메인인 spnego-domain 은 두 개의 로그인 모듈을 사용하여 생성됩니다. spnego 로그인 모듈을 사용하여 host-domain 에 연결하여 사용자를 인증합니다. 두 번째 로그인 모듈을 사용하여 권한 부여 결정에 사용할 역할 정보를 로드할 수 있습니다. 예를 들어 속성 파일을 사용하여 사용자를 역할에 매핑합니다.
또한 이 두 로그인 모듈은 password-stacking 을 사용하여 인증 로그인 모듈의 사용자와 권한 부여 모듈의 사용자와 역할을 매핑합니다. EAP1 은 host-domain 과 spnego-domain 으로 구성됩니다. 애플리케이션은 spnego .xml을 통해 구성됩니다. 또한 보안 토큰을 운영 체제에서 브라우저로 전달할 수 없는 경우 FORM 인증을 대체 인증 메커니즘으로 구성할 수도 있습니다. FORM 인증이 대체로 구성된 경우 이를 지원하도록 추가 보안 도메인을 구성해야 합니다. 이 보안 도메인은 Kerberos 및 SPNEGO와 독립적이며 FORM 인증, 즉 사용자 이름 및 암호 유효성 검사 및 역할만 지원하면 됩니다. 각 애플리케이션은 -domain을 사용하여 인증을 수행하고 권한 부여를 위한 사용자의 역할을 가져오기 위해 webweb.xml 및 jboss -spnego-domain 을 사용하고 대체로 FORM 인증을 제공하도록 구성됩니다. 각 애플리케이션은 또한 경로 /secure/* 를 보안하도록 구성되며 권한 부여를 처리하기 위한 고유한 역할 목록을 제공합니다.
5.7.1.1. 작동 방식
Kerberos 서버에 다음 사용자가 생성되었습니다.
| 사용자 이름 | 암호 |
|---|---|
| B 실행되는 | samplePass |
| Andy | samplePass |
| Bill | samplePass |
| Ron | samplePass |
다음 역할은 FirstPass를 사용하도록 password-stacking 옵션을 설정하여 연결된 추가 모듈을 통해 사용자에게 매핑되었습니다.
| 사용자 이름 | 역할 |
|---|---|
| B 실행되는 | 모두 |
| Andy | A |
| Bill | B |
| Ron |
다음 역할도 각 애플리케이션에 구성되어 있습니다.
| 애플리케이션/SP | 허용된 역할 |
|---|---|
| sampleAppA | 모두, A |
| sampleAppB | all, B |
시작 시 EAP1 은 핵심 서비스를 로드한 다음 보안 및 기타 하위 시스템을 로드합니다. host-domain 은 Kerberos 서버에 대한 연결을 설정하고 spnego-domain은 host-domain 에 연결합니다.sampleAppA 및 sampleAppB 가 배포되어 인증을 위해 spnego-domain 에 연결됩니다.
Bitz는 Kerberos로 보호되는 컴퓨터에 로그인했습니다. 브라우저를 열고 sampleAppA/secure/hello.html 에 액세스를 시도합니다. 보안이 필요하므로 인증이 필요합니다. EAP1 은 브라우저에 키 요청을 Kerberos 서버, 특히 컴퓨터에 구성된 Kerberos 키 배포 센터로 보내도록 지시합니다. 브라우저가 키를 획득하면 simpleAppA 로 전송됩니다.simpleAppA 는 압축 해제되고 구성된 Kerberos 서버와 함께 host-domain 에서 인증을 수행합니다. 티켓이 인증되면 Brite의 역할은 simpleAppA 로 다시 전달되어 인증을 수행합니다. Brite는 all 역할이 있으므로 sampleAppA/secure/hello.html 에 액세스할 수 있습니다. Brite가 sampleAppB/secure/hello.html 에 액세스하려고 하면 동일한 프로세스가 수행됩니다. 모든 역할을 갖기 때문에 액세스 권한이 부여됩니다. Andy와 Bill은 동일한 프로세스를 따르지만 Andy는 sampleAppA/secure/hello.html 에만 액세스할 수 있고 sampleAppB/secure/hello.html 에만 액세스할 수 있습니다. Bill은 반대로, sampleAppA/secure/hello.html 에 액세스하고 sampleAppA/secure/hello.html 에 액세스할 수 없습니다. Ron은 sampleAppA/secure/hello.html 또는 sampleAppB/secure/hello.html 에 인증을 전달하지만 역할이 없기 때문에 액세스 권한이 부여되지 않습니다.
Andy가 Kerberos에 의해 보호되지 않은 컴퓨터에서 sampleAppA/secure/hello.html 에 액세스하려는 경우 예를 들어 사무실 네트워크에 연결된 개인 랩톱으로 대체 로그인 메커니즘으로 FORM 로그인 페이지로 이동합니다. 그런 다음 대체 보안 도메인을 통해 자격 증명이 인증되고 프로세스는 권한 부여를 계속합니다.
2024-02-09에 최종 업데이트된 문서
