보안 아키텍처

Kerberos는 티켓이라는 보안 토큰을 사용합니다. 보안 서비스를 사용하려면 사용자는 네트워크의 서버에서 실행되는 서비스인 티켓 부여 서비스(TGS)에서 티켓을 받아야 합니다. 사용자는 티켓을 획득한 후 동일한 네트워크에서 실행되는 다른 서비스인 인증 서비스(AS)에서 서비스 티켓(ST)을 요청합니다. 그런 다음 사용자는 ST를 사용하여 원하는 서비스에 인증합니다. TGS 및 AS는 KDC(키 배포 센터)라는 엔클로징 서비스 내에서 실행됩니다.

Kerberos는 클라이언트-서버 데스크탑 환경에서 사용하도록 설계되었으며 일반적으로 웹 애플리케이션 또는 씬 클라이언트 환경에서 사용되지 않습니다. 그러나 많은 조직에서 데스크탑 인증에 Kerberos 시스템을 사용하고 웹 애플리케이션에 대해 두 번째 시스템을 생성하는 대신 기존 시스템을 재사용하는 것을 선호합니다. Kerberos는 Microsoft의 Active Directory에 핵심적인 일부이며 여러 Red Hat Enterprise Linux 환경에서 사용됩니다.

웹 브라우저와 같은 클라이언트 컴퓨터에 있는 애플리케이션이 웹 서버에서 보호된 페이지에 액세스하려고 하면 서버에서 권한 부여가 필요한지 응답합니다. 그러면 애플리케이션이 KDC에서 ST를 요청합니다. 애플리케이션은 SPNEGO 형식이 지정된 요청으로 티켓을 래핑하고 브라우저를 통해 웹 애플리케이션으로 다시 보냅니다. 배포된 웹 애플리케이션을 실행하는 웹 컨테이너는 요청의 압축을 풀고 티켓을 인증합니다. 성공적인 인증에 따라 액세스가 부여됩니다.

SPNEGO는 Red Hat Enterprise Linux 및 Kerberos 서버 내의 Kerberos 서비스를 비롯한 모든 종류의 Kerberos 공급자와 함께 작동하며, 이는 Microsoft의 Active Directory에 핵심적인 부분입니다.

Active Directory는 함께 작동하는 세 가지 핵심 기술을 사용합니다.

SSO를 구현하는 한 가지 방법은 클레임 기반 ID 시스템을 사용하는 것입니다. 클레임 기반 ID 시스템을 사용하면 시스템에서 ID 정보를 전달할 수 있지만, 해당 정보는 클레임 및 발급자 또는 권한이라는 두 가지 구성 요소로 추상화됩니다. 클레임은 사용자, 그룹, 애플리케이션 또는 조직과 같은 한 주체가 다른 제목을 만들라는 설명입니다. 해당 클레임 또는 클레임 집합은 토큰 또는 토큰 집합으로 패키징되어 프로바이더가 발행합니다. 클레임 기반 ID를 사용하면 개별 보안 리소스가 사용자에 대해 모든 것을 알지 못해도 SSO를 구현할 수 있습니다.

RBAC가 이미 활성화되어 있는 경우 사용자 또는 그룹 수준에서 구성을 변경하려면 SuperUser 또는 Administrator 역할이 할당되어 있어야 합니다.

elytron 하위 시스템의 아키텍처 및 설계의 기본 개념은 더 작은 구성 요소를 사용하여 전체 보안 정책을 어셈블하는 것입니다. 기본적으로 JBoss EAP는 많은 구성 요소에 대한 구현을 제공하지만, elytron 하위 시스템에서는 특수 사용자 지정 구현을 제공할 수도 있습니다.

'elytron' 하위 시스템에서 구성 요소의 각 구현은 개별 기능으로 처리됩니다. 즉, 개별 리소스를 사용하여 서로 다른 구현을 혼합, 일치 및 모델링할 수 있습니다.

여러 주요 변환기, 영역 매퍼 및 주요 디코더를 elytron 하위 시스템 내에서 정의할 수 있습니다. 다음 섹션에서는 인증 프로세스 중에 이러한 구성 요소가 작동하는 방법과 주체가 적절한 보안 영역에 매핑되는 방법에 대해 설명합니다.

주체가 인증되면 다음 단계를 순서대로 수행합니다.

다음 이미지는 각 단계에서 사용되는 구성 요소를 표시하는 것과 함께 왼쪽 열에 강조 표시된 이러한 단계를 보여줍니다.

그림 2.1. Elytron 인증 프로세스

사전 영역 매핑

사전 영역 매핑 중에 인증된 주체는 사용할 보안 영역을 식별할 수 있으며 인증된 정보를 나타내는 단일 주체 를 포함할 수 있는 SecurityIdentity (보안 ID)에 매핑됩니다. 주요 변환기 및 주요 디코더는 다음 순서로 호출됩니다.

이 절차에서 null 주체가 발생하면 오류가 발생하고 인증이 종료됩니다.

그림 2.2. 사전 영역 매핑

영역 이름 맵핑

매핑된 주체를 획득하면 ID를 로드하는 데 사용할 보안 영역이 식별됩니다. 이 시점에서 영역 이름은 보안 도메인에서 참조한 대로 보안 영역에서 정의하는 이름이며 아직 메커니즘 영역 이름이 아닙니다. 구성은 다음 순서로 보안 영역 이름을 찾습니다.

RealmMapper 가 null을 반환하거나 사용 가능한 매퍼가 없는 경우 보안 도메인의 default-realm 이 사용됩니다.

그림 2.3. 영역 이름 맵핑

사후 영역 매핑

영역을 식별하고 나면 주체는 또 다른 변환 과정을 거칩니다. 변환기는 다음 순서로 호출됩니다.

이 절차에서 null 주체가 발생하면 오류가 발생하고 인증이 종료됩니다.

그림 2.4. 사후 영역 매핑

최종 주체 전환

마지막으로, 도메인별 변환 전후에 메커니즘별 변환을 적용할 수 있는 마지막 주 변환이 발생합니다. 이 단계가 필요하지 않은 경우 post-realm 매핑 단계에서 동일한 결과를 얻을 수 있습니다. 변환기는 다음 순서로 호출됩니다.

이 절차에서 null 주체가 발생하면 오류가 발생하고 인증이 종료됩니다.

그림 2.5. 최종 주체 전환

Realm Identity 확보

최종 주요 변환 후에 영역 이름 매핑에서 식별되는 보안 영역 은 인증을 계속하는 데 사용되는 영역 ID를 가져오기 위해 호출됩니다.

Elytron은 BASIC,FORM,DIGEST,SPNEGO 및 CLIENT_CERT 를 포함한 전체 HTTP 인증 메커니즘 세트를 제공합니다. HTTP 인증은 구성된 인증 메커니즘에 대한 팩토리뿐만 아니라 HTTP 인증 메커니즘을 사용하기 위한 인증 정책인 HttpAuthenticationFactory 를 사용하여 처리됩니다.

HttpAuthenticationFactory 는 다음을 참조합니다.

SASL은 인증 메커니즘 자체를 사용하는 프로토콜과 분리하는 인증을 위한 프레임워크입니다. 또한 DIGEST-MD5,GSSAPI,OTP 및 SCRAM 과 같은 추가 인증 메커니즘을 허용합니다. SASL 인증은 Jakarta EE 사양의 일부가 아닙니다. SASL 인증은 구성된 인증 메커니즘에 대한 팩토리뿐만 아니라 SASL 인증 메커니즘을 사용하기 위한 인증 정책인 SaslAuthenticationFactory 를 사용하여 처리됩니다.

SaslAuthenticationFactory 는 다음을 참조합니다.

레거시 보안 하위 시스템 구성 요소의 일부 주요 구성 요소와 레거시 코어 관리 인증을 Elytron 기능에 매핑할 수 있습니다. 이를 통해 레거시 구성 요소를 Elytron 기반 구성에서 사용할 수 있으며 레거시 구성 요소에서 점진적으로 마이그레이션할 수 있습니다.

JBoss EAP는 elytron 하위 시스템에서 리소스 세트를 제공합니다.

팩토리

수석 혁신자

Princders

영역 매퍼

영역

권한 매퍼

역할 종료자

역할 매퍼

SSL 구성 요소

기타

보안 영역은 자카르타 엔터프라이즈 빈, 웹 애플리케이션 및 관리 인터페이스에서 사용자를 인증할 때 사용할 수 있는 사용자 이름, 암호 및 그룹 멤버십 정보의 ID 저장소입니다. 초기에 JBoss EAP는 기본적으로 두 개의 보안 영역으로 사전 구성되어 있습니다. ManagementRealm 및 ApplicationRealm. 두 보안 영역 모두 파일 시스템을 사용하여 사용자와 암호, 사용자 및 그룹 멤버십 정보 간의 매핑을 저장합니다. 둘 다 인증할 때 기본적으로 다이제스트 메커니즘을 사용합니다.

다이제스트 메커니즘은 사용자 이름 및 암호 매핑 속성 파일에 저장된 정보를 포함하여 다양한 정보로 구성된 일회성 해시를 사용하여 사용자를 인증하는 인증 메커니즘입니다. 이를 통해 JBoss EAP는 네트워크를 통해 일반 텍스트로 암호를 전송하지 않고 사용자를 인증할 수 있습니다.

JBoss EAP 설치에는 관리자가 두 영역에 모두 사용자를 추가할 수 있는 스크립트가 포함되어 있습니다. 이러한 방식으로 사용자를 추가하면 사용자 이름과 해시된 암호가 해당 사용자 이름 및 암호 속성 파일에 저장됩니다. 사용자가 인증을 시도하면 JBoss EAP에서 일회성 사용 번호인 nonce를 클라이언트에 보냅니다. 그런 다음 클라이언트는 사용자 이름, 암호, nonce 및 기타 몇 가지 필드를 사용하여 단방향 해시를 생성하고 사용자 이름, nonce 및 단방향 해시를 JBoss EAP로 전송합니다. JBoss EAP는 미리 지정된 암호를 찾아 제공된 사용자 이름, nonce 및 기타 몇 개 필드와 함께 사용하여 동일한 방식으로 다른 단방향 해시를 생성합니다. 올바른 암호를 포함하여 동일한 정보를 모두 양쪽에서 사용하면 해시가 일치하고 사용자가 인증됩니다.

보안 영역은 기본적으로 다이제스트 메커니즘을 사용하지만 다른 인증 메커니즘을 사용하도록 재구성될 수 있습니다. 시작 시 관리 인터페이스는 ManagementRealm 에서 구성된 인증 메커니즘에 따라 활성화되는 인증 메커니즘을 결정합니다.

보안 영역은 권한 부여 결정에 관여하지 않지만, 나중에 권한 결정을 내리는 데 사용할 수 있는 사용자의 그룹 멤버십 정보를 로드하도록 구성할 수 있습니다. 사용자를 인증하고 나면 사용자 이름을 기반으로 그룹 멤버십 정보를 로드하는 두 번째 단계가 발생합니다.

기본적으로 ManagementRealm 은 관리 인터페이스에 대한 인증 및 권한 부여 중에 사용됩니다. The ApplicationRealm 은 웹 애플리케이션에서 사용할 수 있는 기본 영역이며 사용자를 인증하고 인증할 때 사용할 수 있는 Jakarta Enterprise Beans입니다.

기본적으로 핵심 관리 인증은 기본적으로 ManagementRealm 보안 영역을 사용하여 구성되는 로컬 클라이언트 및 원격 클라이언트의 두 가지 형식으로 각 관리 인터페이스(HTTP 및 네이티브)를 보호합니다. 이러한 기본값은 다르게 구성되거나 완전히 교체될 수 있습니다.

관리 인터페이스의 기본 구성뿐만 아니라 인증 및 권한 부여 메커니즘을 변경하여 보안 방식에 영향을 주는 여러 가지 방법이 있습니다.

보안 도메인은 하나 이상의 애플리케이션에서 인증, 권한 부여, 감사 및 매핑을 제어하는 데 사용하는 Jakarta Authentication 선언적 보안 구성 집합입니다. 기본적으로 4개의 보안 도메인, jboss-ejb-policy,jboss-web-policy,기타 및 jaspitest 가 포함되어 있습니다. jboss-ejb-policy 및 jboss-web-policy 보안 도메인은 JBoss EAP 인스턴스의 기본 권한 부여 메커니즘입니다. 애플리케이션의 구성된 보안 도메인이 인증 메커니즘을 정의하지 않는 경우 사용됩니다. 이러한 보안 도메인은 다른 항목과 함께 권한 부여를 위해 내부적으로 사용되며 올바른 작업에 필요합니다. jaspitest 보안 도메인은 개발 목적으로 포함된 간단한 Jakarta Authentication 보안 도메인입니다.

보안 도메인은 인증, 권한 부여, 보안 매핑 및 감사를 위한 구성으로 구성됩니다. 보안 도메인은 JBoss EAP 보안 하위 시스템의 일부이며 도메인 컨트롤러 또는 독립 실행형 서버에서 중앙에서 관리합니다. 사용자는 애플리케이션 요구 사항을 수용하는 데 필요한 만큼의 보안 도메인을 생성할 수 있습니다.

cache -type 특성을 사용하여 보안 도메인에서 사용할 인증 캐시 유형을 구성할 수도 있습니다. 이 속성이 제거되면 캐시가 사용되지 않습니다. 이 속성에 허용되는 값은 default 또는 infinispan 입니다.

Elytron과 PicketBox 보안 도메인 간 비교

배포는 하나의 Elytron 보안 도메인 또는 하나 이상의 레거시 PicketBox 보안 도메인과 연결되어야 합니다. 배포를 둘 다 연결하지 않아야 합니다. 구성이 올바르지 않습니다.

배포가 둘 이상의 Elytron 보안 도메인과 연결되어 있는 경우 예외가 발생하지만 배포를 여러 레거시 보안 도메인과 연결할 수 있습니다.

보안 영역 및 보안 도메인을 사용하여 JBoss EAP에 배포된 웹 애플리케이션을 보호할 수 있습니다. 둘 중 하나를 사용해야 하는지 결정할 때 둘 사이의 차이를 이해하는 것이 중요합니다.

웹 애플리케이션 및 Jakarta Enterprise Beans 배포는 보안 도메인만 직접 사용할 수 있습니다. ID 저장소에서 전달된 ID 정보를 사용하여 로그인 모듈을 사용하여 실제 인증 및 권한 부여를 수행합니다. ID 정보에 보안 영역을 사용하도록 보안 도메인을 구성할 수 있습니다. 예를 들어, 다른 경우 애플리케이션에서 인증 및 권한 부여 정보를 가져오는 데 사용할 보안 영역을 지정할 수 있습니다. 외부 ID 저장소를 사용하도록 구성할 수도 있습니다. 웹 애플리케이션 및 Jakarta Enterprise Beans 배포는 인증을 위해 보안 영역을 직접 사용하도록 구성할 수 없습니다. 보안 도메인은 보안 하위 시스템의 일부이기도 하며 핵심 서비스 이후에 로드됩니다.

핵심 관리(예: 관리 인터페이스 및 Jakarta Enterprise Beans 원격 엔드포인트)만 보안 영역을 직접 사용할 수 있습니다. 인증 및 권한 부여 정보를 제공하는 ID 저장소입니다. 또한 핵심 서비스이며 하위 시스템을 시작하기 전에 로드됩니다. 기본으로 제공되는 보안 영역인 ManagementRealm 및 ApplicationRealm 은 간단한 파일 기반 인증 메커니즘을 사용하지만 다른 메커니즘을 사용하도록 구성할 수 있습니다.

보안 감사는 보안 하위 시스템 내에서 발생하는 이벤트에 대한 응답으로 로그에 작성하는 등 이벤트 트리거를 나타냅니다. 감사 메커니즘은 인증, 권한 부여 및 보안 매핑 세부 정보와 함께 보안 도메인의 일부로 구성됩니다. 감사는 provider 모듈을 사용하여 보안 이벤트가 보고되는 방식을 제어합니다. JBoss EAP에는 여러 보안 감사 공급업체가 제공되지만 사용자 지정 제공자를 사용할 수 있습니다. JBoss EAP의 핵심 관리에는 별도로 구성되어 있으며 보안 하위 시스템의 일부가 아닌 자체 보안 감사 및 로깅 기능이 있습니다.

보안 매핑은 정보가 애플리케이션에 전달되기 전에 인증 또는 권한 부여가 발생한 후 인증 및 권한 부여 정보를 결합하는 기능을 추가합니다. 인증, 인증에 대한 주체 또는 주체 또는 역할이 아닌 속성인 자격 증명에 대한 역할은 모두 매핑될 수 있습니다. 역할 매핑은 인증 후 제목에 역할을 추가, 교체 또는 제거하는 데 사용됩니다. 주체 매핑은 인증 후 주체를 수정하는 데 사용됩니다. 자격 증명 매핑을 사용하여 애플리케이션에서 사용할 외부 시스템에서 속성을 변환할 수 있습니다. 자격 증명 매핑을 반대로 사용하여 외부 시스템에서 사용하도록 애플리케이션에서 속성을 변환할 수도 있습니다.

JBoss EAP에는 중요한 문자열을 암호화하고 암호화된 키 저장소에 저장하고 애플리케이션 및 확인 시스템에 대해 암호를 해독하는 암호 자격 증명 모음이 있습니다. XML 배포 설명자 등의 일반 텍스트 구성 파일에서 암호 및 기타 중요한 정보를 지정해야 하는 경우가 있습니다. JBoss EAP 암호 자격 증명 모음을 사용하여 일반 텍스트 파일에 사용할 중요한 문자열을 안전하게 저장할 수 있습니다.

보안 도메인은 도메인 컨트롤러 또는 독립 실행형 서버에서 중앙에서 구성됩니다. 보안 도메인을 사용하는 경우 개별적으로 보안을 구성하는 대신 애플리케이션이 보안 도메인을 사용하도록 구성할 수 있습니다. 이를 통해 사용자와 관리자는 선언 보안을 활용할 수 있습니다.

보안 하위 시스템의 보안 관리 부분은 보안 하위 시스템의 높은 수준의 동작을 재정의하는 데 사용됩니다 . 각 설정은 선택 사항입니다. 이러한 설정은 깊은 복사 제목 모드를 제외하고는 변경되지 않습니다.

대부분의 SSO 시나리오에서 SP는 유효한 어설션을 사용하여 SP에 SAML 응답을 전송하는 IDP에 인증 요청을 전송하여 흐름을 시작합니다. 이를 SP 시작 흐름이라고 합니다. SAML 2.0 사양은 IDP 시작 또는 거부된 응답 flow라는 또 다른 흐름을 정의합니다. 이 시나리오에서는 서비스 프로바이더가 IDP로부터 SAML 응답을 받기 위해 인증 흐름을 시작하지 않습니다. 흐름은 IDP 측에서 시작됩니다. 인증되고 나면 사용자는 목록에서 특정 SP를 선택하고 SP URL로 리디렉션될 수 있습니다. 이 흐름을 활성화하기 위해 특별한 구성이 필요하지 않습니다.

하나의 SP에서 시작된 글로벌 로그아웃은 IDP 및 모든 SP에서 사용자를 로그아웃합니다. 사용자가 글로벌 로그아웃을 수행한 후 SP 또는 IDP의 보안된 부분에 액세스하려고 하면 다시 인증해야 합니다.

애플리케이션 보안을 위해 JBoss EAP는 HTTP 및 SASL 사용에 대한 application-http -authentication 으로 사전 구성됩니다. application-http-authentication http-authentication-factory는 인증을 위해 ApplicationRealm 및 groups-to-roles 를 사용하는 ApplicationDomain 을 사용합니다. ApplicationRealm 은 사용자 이름, 암호 및 역할 정보에 대해 application-users.properties 및 application-roles.properties 에서 지원하는 속성입니다.

관리 인터페이스 보안을 위해 JBoss EAP는 HTTP 및 SASL의 management- sasl-authentication을 위한 management-http -authentication 으로 사전 구성되어 있습니다. management-http-authentication http-authentication-factory는 인증에 ManagementRealm 및 groups-to-roles 를 사용하는 ManagementDomain 을 사용합니다. ManagementRealm 은 사용자 이름, 암호 및 역할 정보에 대한 mgmt-users.properties 및mgmt-roles.properties 가 지원하는 속성입니다. management-sasl-authentication sasl-authentication-factory는 JBOSS-LOCAL-USER 인증에 local 을 사용하고 DIGEST- MD5 인증에 ManagementRealm 을 사용하는 Management Domain 을 사용합니다.

기본적으로 JBoss EAP용 사용자는 없지만 이 예제의 목적을 위해 다음 사용자가 추가되었습니다.

시작 시 JBoss EAP 인스턴스는 4개의 인증 팩토리와 관련 보안 도메인, 보안 영역 및 기타 구성된 구성 요소를 모두 로드합니다.

JBOSS-LOCAL-USER 를 사용하여 관리 CLI를 사용하여 관리 인터페이스에 액세스하려는 경우 JBoss EAP 인스턴스와 동일한 호스트에서 관리 CLI를 실행하는 경우 사용자는 로컬 보안 영역을 사용하여 ManagementDomain 으로 사용자를 인증하려고 할 management-sasl-authentication sasl-authentication-factory로 이동합니다.

Susan이 다른 호스트의 관리 CLI를 사용하여 관리 인터페이스에 액세스하려고 하면 SASL과 함께 DIGEST-MD5 인증 메커니즘을 사용합니다. Management Realm 보안 영역을 사용하여 ManagementDomain 으로 사용자를 인증하려는 management-sasl-authentication sasl-authentication-factory로 이동합니다.

Susan이 웹 기반 관리 콘솔을 사용하여 관리 인터페이스에 액세스하려고 하면 HTTP와 함께 DIGEST 인증 메커니즘을 사용합니다. Management Realm 보안 영역을 사용하여 ManagementDomain 을 사용하여 사용자를 인증하려고 할 management-http-authentication -factory로 이동합니다.

애플리케이션 sampleApp1.war 에는 /hello.html 및 /secure/hello.html 이라는 두 개의 HTML 파일이 있으며, BASIC HTTP 인증을 사용하여 /secure/* 경로를 보호합니다. Application Realm 을 사용하며 샘플 역할을 필요로 합니다. 사용자가 sampleApp1.war 에 액세스하려고 하면 application-http-authentication http-authentication -factory로 이동합니다. ApplicationRealm 보안 영역을 사용하여 ApplicationDomain 으로 사용자를 인증하려고 시도합니다.

Sarah가 /hello.html 을 요청하면 인증하지 않고 페이지를 볼 수 있습니다. Sarah가 /secure/hello.html 을 요청하려고 하면 사용자 이름과 암호를 입력하라는 메시지가 표시됩니다. 로그인 후 /secure/hello.html 을 볼 수 있습니다. redhat 및 Susan 또는 모든 사용자는 /hello.html 에 액세스할 수 있지만 /secure/hello.html 에 액세스할 수는 없습니다. 샘플 역할이 없으며 Susan은 ApplicationRealm 보안 영역에 없습니다.

JBoss EAP는 관리 인터페이스와 SSL/TLS를 사용하여 애플리케이션 모두를 보호하는 기능을 제공합니다. 이제 Elytron을 통해 이 구성이 통합되므로 이제 동일한 SSL/TLS 구성으로 관리 인터페이스와 애플리케이션을 보안할 수 있는 옵션이 제공됩니다. SSL/TLS는 키 저장소,키 관리자 및 server- ssl- context 를 만들어 Elytron에서 구성됩니다. http-interface에서 secure-socket-binding을 설정하고 server- ssl- context 를 관리 인터페이스에 할당하여 관리 인터페이스에 대해 SSL/TLS가 활성화됩니다. 이렇게 하면 관리 인터페이스가 HTTP 트래픽에 SSL/TLS를 사용할 수 있습니다. the undertow 하위 시스템의 https-listener 에 server-ssl-context 를 할당하여 애플리케이션에 대해 SSL/TLS가 활성화됩니다. SSL/TLS에 대한 자세한 내용은 고급 보안 섹션을 참조하십시오.

시작 시 JBoss EAP는 관리 인터페이스의 SSL/TLS에 대해 구성된 http-interface 도 시작하는 핵심 서비스의 일부로 관리 인터페이스를 로드합니다. 또한 애플리케이션의 SSL/TLS에 대해 구성된 undertow 하위 시스템과 server-ssl-context 를 통해 SSL/TLS 구성을 제공하는 elytron 하위 시스템을 시작합니다. 그런 다음 SSL/TLS가 활성화된 보안 포트를 통해 관리 인터페이스 및 애플리케이션에 액세스할 수 있습니다.

JBoss EAP는 관리 인터페이스와 ManagementRealm 및 ApplicationRealm 이외의 ID 저장소를 사용하는 애플리케이션 모두를 보호하는 기능을 제공합니다. Elytron에서는 동일한 ID 저장소를 사용하여 애플리케이션과 관리 인터페이스를 보호할 수 있지만 각각에 대해 별도의 ID 저장소를 설정할 수도 있습니다. ID 저장소는 보안 영역(예: filesystem-realm,jdbc-realm 또는 ldap-realm )으로 표시됩니다. 이 예제의 목적을 위해 exampleRealm 이라는 filesystem-realm 이 생성되었습니다. exampleDomain 이라는 보안 도메인도 생성되어 exampleRealm 을 ID 저장소, groups-to-roles 역할 매퍼를 사용하여 exampleRealm 에서 제공하는 그룹 정보를 역할로, default-permission-mapper 를 사용하여 권한을 매핑할 수 있습니다.

HTTP 인증의 경우 exampleHttpAuthFactory 라는 http-authentication-factory 가 생성되었습니다. 인증에 글로벌 HTTP 서버 팩토리 메커니즘과 exampleDomain 을 사용합니다. 또한 두 가지 메커니즘 구성이 있습니다. basicExampleDomain으로 노출된 BASIC 인증 방법과 다이제스트 ExampleDomain 으로 노출된 DIGEST 인증 방법을 사용하는 방법. exampleHttpAuthFactory 를 사용하도록 HTTP 관리 인터페이스가 구성되었습니다. 또한 The undertow 하위 시스템은 exampleHttpAuthFactory 를 사용하는 새 application-security-domain 으로 구성되었습니다. 애플리케이션 sampleApp2.war 는 BASIC 인증과 함께 basicExampleDomain 을 사용하도록 구성되어 있습니다.

exampleSaslAuthFactory 라는 SASL 인증 a sasl-authentication-factory 가 생성되었습니다. 인증에 구성된 SASL 서버 팩토리와 exampleDomain 을 사용합니다. 또한 다이제스트 MD5ExampleDomain으로 노출되는 DIGEST- MD5 인증 메커니즘이 있습니다. 관리 인터페이스의 SASL 구성은 exampleSaslAuthFactory 를 사용하도록 설정되었습니다.

다음 사용자가 exampleRealm 에 추가되었습니다.

시작 시 JBoss EAP는 핵심 서비스를 로드하고 undertow 및 elytron 하위 시스템을 시작합니다. 이는 관리 인터페이스를 보호하고 JBoss EAP에 배포된 애플리케이션에 대해 basic ExampleDomain, digestExampleDomain 및 digestMD5ExampleDomain 을 노출합니다.

sampleApp2.war 가 로드되면 basicExampleDomain 을 찾아 보안 URL에 대한 인증 및 권한 부여를 제공합니다. /hello.html 및 /secure/hello.html 이라는 두 개의 HTML 파일이 있으며, BASIC 인증을 사용하여 /secure/* 경로를 보호합니다. 보안 URL에 액세스하려면 샘플 역할이 필요합니다.

사용자가 인증하면 JBoss EAP에 액세스하는 방법에 따라 특정 메커니즘을 사용하여 자격 증명을 제출합니다. 예를 들어 사용자가 DIGEST 인증과 함께 HTTP를 사용하여 관리 콘솔에 액세스하려고 하면 다이제스트ExampleDomain 으로 노출된 DIGEST 인증 방법을 사용하여 인증됩니다. BASIC 인증으로 HTTP를 사용하여 sampleApp2.war 에 액세스하려는 경우 basicExampleDomain 으로 노출되는 BASIC 인증 방법을 사용하여 인증됩니다. DIGEST 인증과 함께 SASL을 사용하여 관리 CLI에 액세스하려고 하면 다이제스트MD5 ExampleDomain으로 노출된 DIGEST-MD5를 사용하여 인증됩니다. HTTP 인증 메커니즘은 exampleHttpAuthFactory 를 사용하며 SASL 인증 메커니즘은 exampleSaslAuthFactory 를 사용합니다. 두 인증 팩토리 모두 exampleDomain 을 사용하여 인증 및 역할 매핑을 처리합니다.

Vincent 또는 Issac에서 관리 인터페이스에 액세스하려고 하면 사용자 이름과 암호를 입력하라는 메시지가 표시됩니다. 성공적으로 로그인한 후에는 각각 관리 작업을 수행할 수 있습니다.

Vincent 또는 Issac이 /hello.html 을 요청할 때 인증 없이 페이지를 볼 수 있습니다. Vincent 또는 Issac에서 /secure/hello.html 을 요청하려고 하면 사용자 이름과 암호를 입력하라는 메시지가 표시됩니다. 로그인 후 Vincent는 샘플 역할이 있으므로 /secure/hello.html 을 볼 수 있지만 Issac은 게스트 역할을 하므로 /secure/hello.html 을 볼 수 없습니다. 다른 모든 사용자는 로그인하지 않고 /hello.html 에 액세스할 수 있지만 Vincent와 Issac이 exampleRealm 의 유일한 사용자이므로 /secure/hello.html 에 액세스할 수 없습니다.

JBoss EAP는 관리 인터페이스에서 RBAC를 사용할 수 있는 기능을 제공합니다. RBAC의 개념은 RBAC 섹션에서 설명합니다. 이 예에서는 exampleRealm 이라는 보안 영역을 사용합니다. 역할 디코더, 보안 도메인 및 인증 팩토리를 비롯한 나머지 보안 구성은 새 ID 저장소를 사용하여 관리 인터페이스 및 애플리케이션 보안 섹션과 동일합니다. RBAC는 관리 인터페이스의 공급자 특성을 to rbac 로 설정하고 원하는 사용자 및 역할로 exampleRealm 을 업데이트하여 활성화됩니다.

이 시나리오의 경우 다음 사용자가 기존 보안 영역에 추가되었습니다.

그룹 멤버십에 따라 사용자는 다음 RBAC 역할에 매핑되었습니다.

시작 시 JBoss EAP는 보안 구성과 RBAC 구성을 로드하는 핵심 서비스 및 elytron 하위 시스템을 로드합니다. RBAC가 활성화되지 않은 경우 exampleRealm 의 모든 사용자는 SuperUser 로 간주되며 무제한 액세스 권한이 있습니다. RBAC가 활성화되었으므로 각 사용자는 이제 보유한 역할에 따라 제한됩니다. Suzy, Tim, Emily, Zach 및 Natalie는 서로 다른 역할을 가지고 있으며, 이 역할은 위 표에 나와 있습니다. 예를 들어 Suzy 및 Tim만 액세스 제어 정보를 읽고 수정할 수 있습니다. Suzy, Tim 및 Emily는 런타임 상태 및 기타 영구 구성 정보를 수정할 수 있습니다. Zach 는 런타임 상태 및 기타 영구 구성 정보도 수정할 수 있지만 애플리케이션 리소스와만 관련이 있습니다. Suzy, Tim, Emily, Zach 및 Natalie는 구성 및 상태 정보를 읽을 수 있지만 Natalie는 아무것도 업데이트할 수 없습니다. 각 역할 및 JBoss EAP에서 RBAC를 처리하는 방법에 대한 자세한 내용은 역할 기반 액세스 제어 및 관리 인터페이스에 RBAC 추가 섹션을 참조하십시오.

JBoss EAP는 SPNEGO 인증 방법을 사용하여 Kerberos 인증을 제공합니다. Kerberos 및 SPNEGO의 세부 사항에 대한 자세한 내용은 타사 SSO 구현 섹션을 참조하십시오. JBoss EAP와 배포된 웹 애플리케이션이 인증에 Kerberos를 사용하도록 활성화하기 위해 Kerberos 서버에 연결하기 위해 kerberos-security-factory 가 생성됩니다. Kerberos 서버의 사용자에게 역할을 할당하기 위해 보안 영역, 역할 매퍼 및 보안 도메인도 생성됩니다. kerberos -security-factory를 사용하고 인증 및 역할 할당에 보안 도메인을 사용하는 http-authentication -factory 가 생성됩니다. 인증 메커니즘은 SPNEGO 인증 메커니즘을 사용하여 exampleSpnegoDomain 으로 노출됩니다. 또한 The undertow 하위 시스템은 인증에 http-authentication-factory 를 사용하도록 구성됩니다.

sampleAppA 및 sampleAppB 는 모두 exampleSpnegoDomain 을 사용하여 인증을 수행하고 권한 부여를 위한 사용자의 역할을 가져오도록 구성됩니다. 두 애플리케이션 모두 보안 토큰을 운영 체제에서 브라우저로 전달할 수 없는 경우 FORM 인증을 대체 인증 메커니즘으로 구성할 수도 있습니다. FORM 인증이 대체로 구성된 경우 지원 보안 도메인과 함께 추가 인증 메커니즘을 구성해야 합니다. 이 인증 메커니즘은 Kerberos 및 SPNEGO 와 독립적이며 FORM 인증을 지원하기만 하면 됩니다. 이 경우 FORM 인증을 위해 추가 메커니즘 및 지원 보안 도메인이 구성되어 exampleFormDomain 으로 노출되었습니다. 각 애플리케이션은 exampleFormDomain 을 사용하고 대체로 FORM 인증을 제공하도록 구성됩니다. 각 애플리케이션은 또한 경로 /secure/* 를 보안하도록 구성되며 권한 부여를 처리하기 위한 고유한 역할 목록을 제공합니다.

Kerberos 서버에 다음 사용자가 생성되었습니다.

다음 역할은 보안 도메인을 사용하여 사용자에게 매핑됩니다.

다음 역할도 각 애플리케이션에 구성되어 있습니다.

시작 시 EAP1 은 핵심 서비스를 로드한 다음 elytron 및 기타 하위 시스템을 로드합니다. kerberos-security-factory 는 Kerberos 서버에 대한 연결을 설정합니다. sampleAppA 및 sampleAppB 는 모두 배포되며 인증을 위해 exampleSpnegoDomain 및 exampleFormDomain 에 연결합니다.

Sande는 Kerberos로 보호되는 컴퓨터에 로그인했습니다. 브라우저를 열고 sampleAppA/secure/hello.html 에 액세스를 시도합니다. 보안이 필요하므로 인증이 필요합니다. EAP1 은 브라우저에서 키 요청을 Kerberos 서버, 특히 컴퓨터에 구성된 Kerberos 키 배포 센터로 보내도록 지시합니다. 브라우저가 키를 얻은 후 sampleAppA로 전송됩니다. sampleAppA 는 압축 해제되고 kerberos-security-factory 에서 구성된 Kerberos 서버와 함께 인증이 수행되는 exampleSpnegoDomain 을 JBoss EAP로 보냅니다. 티켓이 인증되면 Sande의 역할은 인증을 수행하기 위해 sampleAppA 로 다시 전달됩니다. Sande는 all 역할이 있으므로 sampleAppA/secure/hello.html 에 액세스할 수 있습니다. Sande가 sampleAppB/secure/hello.html 에 액세스하려고 하면 동일한 프로세스가 수행됩니다. 모든 역할을 갖기 때문에 액세스 권한이 부여됩니다. Andrea와 Betty는 동일한 프로세스를 따르지만 Andrea는 sampleAppA/secure/hello.html 에만 액세스할 수 있고 sampleAppB/secure/hello.html 에는 액세스할 수 없습니다. Betty는 반대로, sampleAppA/secure/hello.html 에 액세스하고 sampleAppA/secure/hello.html 에 액세스할 수 없습니다. Chuck은 sampleAppA/secure/hello.html 또는 sampleAppB/secure/hello.html 에 인증을 전달하지만 역할이 없으므로 액세스 권한이 부여되지 않습니다.

Sande가 Kerberos가 보안하지 않은 컴퓨터에서 sampleAppA/secure/hello.html 에 액세스하려는 경우(예: 사무실 네트워크에 연결된 개인 랩톱) FORM 로그인 페이지로 대체로 이동합니다. 그런 다음 대체 인증 메커니즘을 사용하여 자격 증명이 인증되고 프로세스는 권한 부여를 계속합니다.

JBoss EAP는 관리 콘솔을 포함하는 관리 인터페이스와 함께 HTTPS 사용을 지원합니다. HTTPS는 secure-interface 요소를 구성하고, 관리 인터페이스의 http -interface 섹션에 secure- port 를 추가하고, 원하는 설정(예: 서버 ID, 프로토콜, 키 저장소, 별칭 등)을 사용하여 기존 또는 새 보안 영역을 구성하여 활성화할 수 있습니다. 이렇게 하면 관리 인터페이스가 모든 HTTP 트래픽에 SSL/TLS를 사용할 수 있습니다. HTTPS 및 관리 인터페이스 보안에 대한 자세한 내용은 일반적으로 고급 보안 섹션을 참조하십시오.

또한 JBoss EAP는 몇 가지 다른 인증 체계를 사용하여 관리 인터페이스에서 RBAC 를 활성화하는 기능을 제공합니다. 이 예에서는 ManagementRealm 에 사용된 기존 속성 파일과 함께 사용자 이름 및 암호 인증을 사용합니다. RBAC는 관리 인터페이스의 공급자 특성을 to rbac 로 설정하고 원하는 사용자 및 역할로 ManagementRealm 을 업데이트하여 활성화됩니다.

이 시나리오의 경우 다음 사용자가 기존 보안 영역에 추가되었습니다.

그룹 멤버십에 따라 사용자는 다음 RBAC 역할에 매핑되었습니다.

시작 시 JBoss EAP는 RBAC 구성 및 관리 인터페이스의 일부로 ManagementRealm 을 로드합니다. 핵심 서비스의 일부로 관리 인터페이스의 HTTPS에 대해 구성된 http-interface 도 시작합니다. 이제 사용자는 HTTPS를 통해 관리 인터페이스에 액세스하고 RBAC도 활성화 및 구성했습니다. RBAC가 활성화되지 않은 경우 ManagementRealm 보안 영역의 모든 사용자는 SuperUser 로 간주되며 무제한 액세스 권한이 있습니다. RBAC가 활성화되었으므로 각 사용자는 이제 보유한 역할에 따라 제한됩니다. Suzy, Tim, Emily, Zach 및 Natalie는 서로 다른 역할을 가지고 있으며, 이 역할은 위 표에 나와 있습니다. 예를 들어 Suzy 및 Tim만 액세스 제어 정보를 읽고 수정할 수 있습니다. Suzy, Tim 및 Emily는 런타임 상태 및 기타 영구 구성 정보를 수정할 수 있습니다. Zach 는 런타임 상태 및 기타 영구 구성 정보도 수정할 수 있지만 애플리케이션 리소스와만 관련이 있습니다. Suzy, Tim, Emily, Zach 및 Natalie는 구성 및 상태 정보를 읽을 수 있지만 Natalie는 아무것도 업데이트할 수 없습니다. 각 역할 및 JBoss EAP에서 RBAC를 처리하는 방법에 대한 자세한 내용은 역할 기반 액세스 제어 및 관리 인터페이스에 RBAC 추가 섹션을 참조하십시오.

JBoss EAP는 the undertow 하위 시스템을 사용하여 처리하는 애플리케이션과 함께 사용할 HTTPS 사용을 지원합니다. HTTPS의 새 커넥터는 the undertow 하위 시스템에 추가되며 원하는 설정(예: 프로토콜, 포트, 키 저장소 등)으로 구성됩니다. 구성이 저장되면 웹 애플리케이션에서 구성된 포트에서 HTTPS 트래픽을 수락할 수 있습니다. sample-domain 이라는 새 보안 도메인이 추가되었으며 인증을 위해 IdentityLoginModule 을 사용합니다. sampleApp2.war 는 sample-domain 을 사용하여 사용자를 인증하도록 구성됩니다.

보안 도메인 sample-domain 이 IdentityLoginModule 을 사용하도록 생성 및 구성되었습니다. 다음 인증 정보는 로그인 모듈에 구성되어 있습니다.

시작 시 JBoss EAP는 핵심 서비스를 로드하고, 모든 웹 애플리케이션과 sample-domain 의 HTTPS 연결을 각각 관리하는 undertow 및 보안 하위 시스템을 시작합니다. sampleApp2.war 가 로드되고 보안 URL에 대한 인증 및 권한 부여를 제공하는 샘플 도메인을 찾습니다. sampleApp2.war 에는 두 개의 HTML 파일이 있습니다. /Hello.html 및 /secure/hello.html 은 기본 HTTP 인증을 사용하여 /secure/* 경로를 보호합니다. sample-domain 보안 도메인을 사용하며 샘플 의 역할이 필요합니다.

Vincent가 /hello.html 을 요청하면 인증하지 않고 페이지를 볼 수 있습니다. Vincent가 /secure/hello.html 을 요청하려고 하면 사용자 이름과 암호를 입력하라는 메시지가 표시됩니다. 성공적으로 로그인한 후 /secure/hello.html 을 볼 수 있습니다. 다른 모든 사용자는 로그인하지 않고 /hello.html 에 액세스할 수 있지만 Vincent는 sample-domain 에서 유일한 사용자이므로 /secure/hello.html 에 액세스할 수 없습니다. 이는 HTTPS를 통해 처리하는 모든 트래픽에도 적용됩니다.

JBoss EAP는 보안,undertow 및 infinispan 하위 시스템의 조합을 사용하여 웹 애플리케이션과 함께 클러스터되고 비클러스터형 SSO를 지원합니다. 보안 하위 시스템은 인증 및 권한 부여를 수행할 수 있는 보안 도메인을 제공하지만 infinispan and undertow 하위 시스템은 JBoss EAP 인스턴스 또는 JBoss EAP 클러스터 전체에서 SSO 정보를 캐싱하고 배포하는 데 도움이 됩니다. 4개의 EAP 인스턴스에는 IdentityLoginModule 을 사용하도록 구성된 보안 도메인인 sso-domain 이 있습니다.sampleAppA 및 sampleAppB 는 the sso-domain 보안 도메인을 사용하여 /secure/* 경로를 보안하고 해당 경로에 액세스하기 위해 샘플 의 역할이 필요하도록 구성되었습니다. 다음 인증 정보는 the sso-domain 로그인 모듈에 구성되어 있습니다.

또한 4개의 JBoss EAP 인스턴스는 모두 standalone-full-ha 또는 full-ha 프로필로 시작하도록 구성되었으며, 이 프로필은 infinispan 하위 시스템과 이 시나리오에서 SSO를 활성화하는 데 필요한 기타 기능을 추가합니다. 웹 cache-container 및 SSO replicad-cache도 추가되었으며, the undertow 하위 시스템은 둘 다 사용하도록 구성되었습니다. EAP1 및 EAP2 는 비클러스터형 SSO에 대한 해당 하위 시스템을 구성하고 EAP3 및 EAP 4 를 포함하는 클러스터는 클러스터된 SSO를 사용하도록 구성되었습니다.

시작 시 JBoss EAP는 핵심 서비스를 로드하고 SSO 정보를 위해so -domain 및 관련 캐싱을 관리하는 보안 , 언플레이스 및 infinispan 하위 시스템을 시작합니다. sampleAppA.war 및 sampleAppB.war 는 모두 4개의 JBoss EAP 인스턴스에 로드되며, 각각 인증 및 권한 부여를 위해 for sso-domain 을 찾습니다.

Jane이 EAP1/sampleAppA/secure/hello.html 에 액세스하려고 하면 인증 메시지가 표시됩니다. 올바른 정보를 제공한 후 EAP1/sampleAppA/secure/hello.html 을 볼 수 있습니다. Jane의 세션은 the undertow 및 infinispan 하위 시스템에서 사용하는 SSO 캐시에 추가됩니다. EAP1/sampleAppB/secure/hello.html 에 액세스하려고 하면 다시 인증하라는 메시지가 표시되지 않습니다. EAP1 에서 실행 중인 sampleAppB 는 infinispan 하위 시스템과 함께 the undertow 하위 시스템 캐시를 사용하여 세션을 찾아 이미 인증되었기 때문에 액세스 권한을 부여합니다. Jane이 EAP2/sampleAppA/secure/hello.html 또는 EAP2/sampleAppB/secure/hello.html 에 액세스하려고 하면 EAP1 및 EAP 2 에서 캐시를 공유하지 않기 때문에 다시 인증하라는 메시지가 표시됩니다.

Jane이 EAP3/sampleAppA/secure/hello.html 에 액세스하려고 하면 인증하라는 메시지가 표시되며 세션이 SSO 캐시에 저장됩니다. 이러한 캐시는 전체 클러스터에 저장되므로 Jane가 EAP3/sampleAppB/secure/hello.html,EAP4/sampleAppA/secure/hello.html 또는 EAP4/sampleAppB/secure/hello.html 에 로그인하려고 하면 다시 인증할 필요가 없습니다. EAP3 또는 EAP4 가 다시 시작되면 다른 JBoss EAP 인스턴스와 클러스터가 계속 실행되어 캐시를 유지하기 때문에 Jane의 SSO 정보는 캐시에 남아 있습니다. 이와 유사하게 Jane의 세션이 무효화되면 캐시 전체에서 리플을 가져와서 클러스터에서 액세스하려는 애플리케이션이나 서버에 관계없이 다시 인증해야 합니다.

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 토큰을 가져오지 않고도 볼 수 있는 보안되지 않은 영역이 있습니다.

JBoss EAP는 보안 영역의 인증을 위해 LDAP 및 Kerberos 사용을 지원합니다. 이 작업은 기존 ManagementRealm 을 업데이트하여 인증 유형으로 ldap 를 사용하고 LDAP 서버에 대한 아웃바운드 연결을 생성합니다. 이렇게 하면 인증 메커니즘이 다이제스트 에서 BASIC / Plain 으로 변경되고 기본적으로 네트워크에서 사용자 이름과 암호를 전송합니다.

다음 사용자가 LDAP 디렉터리에 추가되었습니다.

시작 시 EAP1 은 ManagementRealm 및 관리 인터페이스를 포함한 핵심 서비스를 로드합니다. ManagementRealm 은 LDAP 디렉터리 서버에 연결하고 필요에 따라 관리 인터페이스에 대한 인증을 제공합니다.

자신이 관리 인터페이스에 액세스하려고 하면 강제로 인증됩니다. 자격 증명은 인증에 LDAP 디렉터리 서버를 사용하는 ManagementRealm 보안 영역으로 전달됩니다. EAP1 은 인증 후 기본 단순 액세스 제어를 사용하므로, 플레이버의 역할은 확인되지 않으며 액세스 권한이 부여됩니다. Sam이 관리 인터페이스에 액세스를 시도하면 동일한 프로세스가 발생합니다.

RBAC가 인증된 후 RBAC가 활성화되면 인증을 위해 자신의 역할을 관리 인터페이스로 다시 전달합니다. jboss에는 SuperUser 역할이 있으므로 관리 인터페이스에 대한 액세스 권한이 부여됩니다. Sam이 RBAC를 활성화한 상태로 관리 인터페이스에 액세스하려고 하면 LDAP를 통해 인증되지만 적절한 역할이 없으므로 액세스가 거부됩니다.

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 -domain을 사용하여 인증을 수행하고 권한 부여를 위한 사용자의 역할을 가져오기 위해 web.xml 및 jboss - web.xml을 통해 구성됩니다. 또한 보안 토큰을 운영 체제에서 브라우저로 전달할 수 없는 경우 FORM 인증을 대체 인증 메커니즘으로 구성할 수도 있습니다. FORM 인증이 대체로 구성된 경우 이를 지원하도록 추가 보안 도메인을 구성해야 합니다. 이 보안 도메인은 Kerberos 및 SPNEGO와 독립적이며 FORM 인증, 즉 사용자 이름 및 암호 유효성 검사 및 역할만 지원하면 됩니다. 각 애플리케이션은 spnego-domain 을 사용하고 대체로 FORM 인증을 제공하도록 구성됩니다. 각 애플리케이션은 또한 경로 /secure/* 를 보안하도록 구성되며 권한 부여를 처리하기 위한 고유한 역할 목록을 제공합니다.