Menu Close
Settings Close

Language and Page Formatting Options

보안 아키텍처

Red Hat JBoss Enterprise Application Platform 7.4

고급 Red Hat JBoss Enterprise Application Platform 보안 개념 및 기능에 대한 설명과 이를 지원하는 구성 요소.

초록

이 문서에서는 JBoss EAP 내의 높은 수준의 보안 개념과 이러한 개념을 구현하기 위한 구성 요소를 중점적으로 다룹니다. 이 문서에서는 특정 시나리오를 구성하는 방법에 대한 구체적인 사항이 무엇인지와 그 이유를 중점적으로 다룹니다. 이 문서를 마치면 독자는 JBoss EAP 내의 보안 구성 요소와 이러한 구성 요소가 어떻게 결합되는지에 대한 탄탄한 개념을 가지고 있어야 합니다.

Red Hat 문서에 대한 피드백 제공

문서에 대한 의견을 보내 주셔서 감사합니다. 피드백을 제공하기 위해 문서의 텍스트를 강조 표시하고 주석을 추가할 수 있습니다. Red Hat 설명서에 대한 피드백을 제출하는 방법을 알아보려면 절차의 단계를 따르십시오.

사전 요구 사항

  • Red Hat 고객 포털에 로그인합니다.
  • Red Hat 고객 포털에서 다중 페이지 HTML 형식으로 문서를 봅니다.

절차

  1. 피드백 (Fedback)을 클릭하여 기존 reader 주석을 확인합니다.

    참고

    피드백 기능은 다중 페이지 HTML 형식으로만 활성화됩니다.

  2. 피드백을 제공할 문서의 섹션을 강조 표시합니다.
  3. 선택한 텍스트 옆에 표시되는 프롬프트 메뉴에서 Add Feedback(피드백 추가 )을 클릭합니다.

    텍스트 상자가 페이지 오른쪽에 있는 피드백 섹션에 열립니다.

  4. 텍스트 상자에 피드백을 입력하고 Submit(제출 )을 클릭합니다.

    설명서 문제가 생성되어 있습니다.

  5. 이 문제를 보려면 피드백 보기에서 문제 추적기 링크를 클릭합니다.

보다 포괄적 수용을 위한 오픈 소스 용어 교체

Red Hat은 코드, 문서, 웹 속성에서 문제가 있는 용어를 교체하기 위해 최선을 다하고 있습니다. 먼저 마스터(master), 슬레이브(slave), 블랙리스트(blacklist), 화이트리스트(whitelist) 등 네 가지 용어를 교체하고 있습니다. 이러한 변경 작업은 작업 범위가 크므로 향후 여러 릴리스에 걸쳐 점차 구현할 예정입니다. 자세한 내용은 CTO Chris Wright의 메시지를 참조하십시오.

1장. 일반 보안 개념 개요

JBoss EAP가 보안을 처리하는 방법을 자세히 알아보기 전에 몇 가지 기본 보안 개념을 이해하는 것이 중요합니다.

1.1. 인증

인증은 대상을 식별하고 식별의 신뢰성을 확인하는 것을 의미합니다. 가장 일반적인 인증 메커니즘은 사용자 이름과 암호 조합이지만 공유 키, 스마트 카드 또는 지문과 같은 기타 메커니즘도 인증에 사용됩니다. Jakarta EE 선언적 보안과 관련하여 성공적인 인증의 결과를 주체라고 합니다.

1.2. 권한 부여

권한 부여는 액세스 권한을 지정하거나 액세스 정책을 정의하는 방법을 나타냅니다. 그런 다음 시스템은 해당 정책을 사용하여 요청자의 리소스에 대한 액세스를 허용하거나 거부하는 메커니즘을 구현할 수 있습니다. 대부분의 경우 이는 주체와 일치하는 작업 집합 또는 액세스할 수 있는 위치(역할이라고도 함)를 일치시켜 구현됩니다.

1.3. 실제 환경에서 인증 및 권한 부여

인증 및 권한 부여는 별개의 개념이지만 종종 연결됩니다. 인증을 처리하도록 작성된 많은 모듈은 권한 부여도 처리합니다.

예제

애플리케이션 MyPersonalSoapbox 는 메시지를 게시하고 볼 수 있는 기능을 제공합니다. 토픽 역할이 있는 주체는 메시지를 게시하고 다른 게시된 메시지를 볼 수 있습니다. 로그인하지 않은 사용자는 Listen 역할이 있으며 게시된 메시지를 볼 수 있습니다. Suzy,¢ 및 Bob은 애플리케이션을 사용합니다. Suzy 및 Bob은 사용자 이름과 암호로 인증할 수 있지만 사용자 이름과 암호가 아직 없습니다. Suzy는 토픽 역할을 가지고 있지만 Bob에는 talk 또는 Listen없는 역할도 없습니다. Suzy 인증 시 메시지를 게시하고 볼 수 있습니다. 실제로 MyPersonalSoapbox 를 사용하면 로그인할 수 없지만 게시된 메시지를 볼 수 있습니다. Bob이 로그인하면 메시지를 게시할 수 없으며, 게시된 다른 메시지를 볼 수도 없습니다.

Suzy는 인증되고 권한이 부여됩니다. iso는 인증을 받지 않았지만 메시지를 볼 수 있도록 Listen 역할과 함께 인증을 받았습니다. Bob이 인증되었지만 권한 부여가 없고 역할이 없습니다.

1.4. 암호화

암호화는 수학 알고리즘을 적용하여 중요한 정보를 인코딩하는 것을 나타냅니다. 데이터는 인코딩된 형식으로 변환하거나 암호화하여 보안을 설정합니다. 데이터를 다시 읽으려면 인코딩된 형식을 원래 형식으로 변환하거나 해독해야 합니다. 암호화는 파일 또는 데이터베이스의 간단한 문자열 데이터 또는 통신 스트림 간에 전송된 데이터에 적용할 수 있습니다.

암호화의 예로는 다음과 같은 시나리오가 포함됩니다.

  • LUKS는 Linux 파일 시스템 디스크를 암호화하는 데 사용할 수 있습니다.
  • fish 또는 AES 알고리즘을 사용하여 Postgres 데이터베이스에 저장된 데이터를 암호화할 수 있습니다.
  • HTTPS 프로토콜은 한 당사자에서 다른 당사자로 전송하기 전에 보안 소켓 계층/전송 계층 보안, SSL/TLS를 통해 모든 데이터를 암호화합니다.
  • 사용자가 Secure Shell을 사용하여 한 서버에서 다른 서버로 연결하면 SSH 프로토콜을 통해 모든 통신이 암호화된 터널로 전송됩니다.

1.5. SSL/TLS 및 인증서

SSL/TLS는 두 시스템에서만 알려진 대칭 키를 사용하여 두 시스템 간의 네트워크 트래픽을 암호화합니다. 대칭 키의 안전한 교환을 위해 SSL/TLS는 키 쌍을 사용하는 암호화 방법인 PKI(Public Key Infrastructure)를 사용합니다. 키 쌍은 별도의 두 개의 암호화 키, 즉 공개 키와 개인 키로 구성됩니다. 공개 키는 모든 당사자와 공유되며 데이터를 암호화하는 데 사용됩니다. 개인 키는 비밀로 유지되며 공개 키를 사용하여 암호화된 데이터를 해독하는 데 사용됩니다.

클라이언트에서 대칭 키를 교환하기 위해 보안 연결을 요청하면 안전한 통신을 시작하기 전에 핸드셰이크 단계가 수행됩니다. SSL/TLS 핸드셰이크 중에 서버는 인증서 형태로 공개 키를 클라이언트에 전달합니다. 인증서에는 서버의 ID, URL, 서버의 공개 키 및 인증서를 검증하는 디지털 서명이 포함됩니다. 클라이언트는 인증서의 유효성을 검사하고 인증서가 신뢰할 수 있는지 결정합니다. 인증서가 신뢰할 수 있는 경우 클라이언트는 SSL/TLS 연결에 사용할 대칭 키를 생성하고 서버의 공개 키를 사용하여 암호화한 다음 서버로 다시 전송합니다. 서버는 개인 키를 사용하여 대칭 키를 해독합니다. 이 연결을 통해 두 시스템 간의 추가 통신은 대칭 키를 사용하여 암호화됩니다.

자체 서명 인증서와 권한 서명 인증서의 두 가지 종류의 인증서가 있습니다. 자체 서명된 인증서는 개인 키를 사용하여 서명합니다. 해당 서명은 신뢰 체인에 연결되어 있지 않기 때문에 확인되지 않습니다. 기관 서명 인증서는 인증 기관, CA가 당사자에게 발급하고 해당 CA(예: VeriSign, CAcert 또는 RSA)에서 서명한 인증서입니다. CA는 인증서 소유자의 신뢰성을 확인합니다.

자체 서명된 인증서는 보다 빠르고 쉽게 생성하고 관리할 수 있는 인프라를 필요로 하지만 타사가 인증을 확인하지 않았기 때문에 클라이언트가 신뢰성을 확인하기 어려울 수 있습니다. 이렇게 하면 본질적으로 자체 서명된 인증서의 보안이 떨어집니다. 권한 서명된 인증서는 설정하는 데 더 많은 노력이 필요할 수 있지만 클라이언트가 인증을 쉽게 확인할 수 있습니다. 제3자가 인증 보유자의 신뢰성을 확인했기 때문에 신뢰도 체인이 만들어집니다.

주의

Red Hat은 영향을 받는 모든 패키지에서 TLSv1.1 또는 TLSv1.2를 기반으로 SSLv2, SSLv3 및 TLSv1.0을 명시적으로 비활성화하는 것이 좋습니다.

1.6. SSO(Single Sign-On)

SSO(Single Sign-On)를 사용하면 한 리소스에 인증된 주체가 다른 리소스에 대한 액세스를 암시적으로 인증할 수 있습니다. SSO에서 별도의 리소스 집합을 보호하는 경우 사용자는 보안 리소스에 처음 액세스할 때만 인증해야 합니다. 인증에 성공하면 사용자와 연결된 역할은 저장되어 기타 모든 관련 리소스의 권한 부여에 사용됩니다. 이를 통해 사용자는 인증 없이 추가 인증 리소스에 액세스할 수 있습니다.

사용자가 리소스에서 로그아웃하거나 리소스가 프로그래밍 방식으로 세션을 무효화하면 지속되는 모든 권한 부여 데이터가 제거되고 프로세스가 다시 시작됩니다. 리소스 세션 시간 초과의 경우 해당 사용자와 연결된 다른 유효한 리소스 세션이 있는 경우 SSO 세션이 무효화되지 않습니다. SSO는 웹 애플리케이션 및 데스크탑 애플리케이션에서 인증 및 권한 부여에 사용할 수 있습니다. 경우에 따라 SSO 구현이 두 가지와 통합될 수 있습니다.

SSO 내에는 시스템의 다른 개념과 일부를 설명하는 데 사용되는 몇 가지 일반적인 용어가 있습니다.

IdM (Identity Management)

ID 관리(IDM)는 하나 이상의 시스템 또는 도메인에서 주체 및 관련 인증, 권한 및 권한을 관리하는 개념을 나타냅니다. IAM(ID 및 액세스 관리)이라는 용어는 이와 같은 개념을 설명하는 데 사용됩니다.

ID 공급자

ID 공급자(IDP)는 최종 사용자를 인증하고 해당 사용자의 ID를 신뢰할 수 있는 파트너에게 어설션하는 권한 있는 엔터티입니다.

ID 저장소

ID 프로바이더는 인증 및 권한 부여 프로세스 중에 사용할 사용자의 정보를 검색하려면 ID 저장소가 필요합니다. ID 저장소는 데이터베이스, LDAP(Lightweight Directory Access Protocol), 속성 파일 등 모든 유형의 리포지토리가 될 수 있습니다.

서비스 공급자

서비스 공급자(SP)는 ID 공급자를 사용하여 전자 사용자 자격 증명을 통해 사용자에 대한 정보를 어설션하고, 서비스 공급자가 신뢰할 수 있는 사용자 자격 증명 어설션 세트에 따라 액세스 제어 및 보급을 관리할 수 있도록 합니다.

클러스터형 SSO 및 비클러스터형 SSO

클러스터되지 않은 SSO는 권한 부여 정보 공유를 동일한 가상 호스트의 애플리케이션으로 제한합니다. 또한 호스트 장애가 발생할 경우 복원력도 없습니다. 클러스터형 SSO 시나리오에서는 여러 가상 호스트의 애플리케이션 간에 데이터를 공유할 수 있으므로 오류가 발생할 수 있습니다. 또한 클러스터된 SSO는 로드 밸런서에서 요청을 받을 수 있습니다.

1.6.1. 타사 SSO 구현

Kerberos

Kerberos는 클라이언트-서버 애플리케이션을 위한 네트워크 인증 프로토콜입니다. 비밀 키 대칭 암호화를 사용하여 비보안 네트워크에서 보안 인증을 허용합니다.

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

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

SPNEGO

단순하고 보호되는 GSS_API 협상 메커니즘(SPNEGO)은 웹 애플리케이션에서 사용하기 위한 Kerberos 기반 SSO 환경 확장 메커니즘을 제공합니다.

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

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

Microsoft의 Active Directory

AD(Active Directory)는 Microsoft Windows 도메인에서 사용자와 컴퓨터를 인증하기 위해 Microsoft가 개발한 디렉터리 서비스입니다. Windows Server의 일부로 제공됩니다. 도메인을 제어하는 Windows Server를 실행하는 컴퓨터를 도메인 컨트롤러라고 합니다. Red Hat Enterprise Linux는 Red Hat Identity Management, Red Hat JBoss Enterprise Application Platform 및 기타 Red Hat 제품과 마찬가지로 Active Directory 도메인과 통합할 수 있습니다.

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

  1. 사용자, 컴퓨터, 암호 및 기타 리소스에 대한 정보를 저장하는 LDAP
  2. 네트워크를 통해 보안 인증을 제공하는 Kerberos
  3. 네트워크의 다른 장치와 IP 주소와 호스트 이름 간의 매핑을 제공하는 DNS(Domain Name Service)

1.6.2. 클레임 기반 ID

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

보안 토큰 서비스

STS(보안 토큰 서비스)는 보안 애플리케이션, 웹 서비스 또는 Jakarta Enterprise Bean에 대한 사용자를 인증하고 인증할 때 사용하기 위해 클라이언트에 보안 토큰을 발행하는 인증 서비스입니다. 서비스 프로바이더라고 하는 STS로 보안된 애플리케이션에 대해 인증을 시도하는 클라이언트는 중앙 집중식 STS 인증 도구로 리디렉션되고 토큰을 발행합니다. 성공하면 해당 클라이언트는 서비스 프로바이더에 액세스하여 원래 요청과 함께 토큰을 제공합니다. 해당 서비스 프로바이더는 STS를 사용하여 클라이언트의 토큰을 확인하고 적절하게 진행합니다. 이 토큰은 다른 웹 서비스 또는 STS에 연결된 Jakarta Enterprise Beans에 대해 클라이언트가 재사용할 수 있습니다. 보안 토큰을 발행, 취소, 갱신 및 검증할 수 있는 중앙 집중식 STS의 개념을 지정하고 보안 토큰 요청 및 응답 메시지 형식을 WS-Trust 라고 합니다.

브라우저 기반 SSO

브라우저 기반 SSO에서 서비스 프로바이더라고 하는 하나 이상의 웹 애플리케이션은 허브 및 대화 아키텍처의 중앙 집중식 ID 프로바이더에 연결합니다. IDP는 SAML 토큰의 청구 보고서를 서비스 공급자 또는 대화자에게 발행하여 ID 및 역할 정보에 대한 중앙 소스 또는 허브 역할을 합니다. 사용자가 서비스 공급자에 액세스하려고 할 때 또는 사용자가 ID 공급자로 직접 인증을 시도할 때 요청이 발생할 수 있습니다. 이러한 흐름은 각각 SP-initiated 및 IDP 시작 flows라고 하며 둘 다 동일한 claim 문을 발행합니다.

SAML

SAML(Security Assertion Markup Language)은 두 당사자(일반적으로 ID 프로바이더와 서비스 공급자)가 인증 및 권한 부여 정보를 교환할 수 있는 데이터 형식입니다. SAML 토큰은 STS 또는 IDP에서 발행한 토큰 유형입니다. SSO를 활성화하는 데 사용할 수 있습니다. SAML, SAML 서비스 프로바이더가 보안한 리소스는 사용자를 STS 또는 IDP 유형인 SAML ID 프로바이더로 리디렉션하여 해당 사용자를 인증하고 인증하기 전에 유효한 SAML 토큰을 가져옵니다.

데스크탑 기반 SSO

데스크탑 기반 SSO를 사용하면 서비스 공급자 및 데스크탑 도메인(예: Active Directory 또는 Kerberos)이 주체를 공유할 수 있습니다. 실제로 이를 통해 사용자는 도메인 자격 증명을 사용하여 컴퓨터에 로그인한 다음, 다시 인증하지 않고도 서비스 프로바이더가 인증 중에 해당 주체를 재사용하여 SSO를 제공할 수 있습니다.

1.7. LDAP

LDAP(Lightweight Directory Access Protocol)는 네트워크 간에 디렉터리 정보를 저장하고 배포하는 프로토콜입니다. 이 디렉터리 정보에는 사용자, 하드웨어 장치, 액세스 역할 및 제한 사항 및 기타 정보가 포함됩니다.

LDAP에서 DN(고유 이름)은 디렉터리에서 오브젝트를 고유하게 식별합니다. 각 고유 이름은 다른 모든 오브젝트의 고유한 이름과 위치가 있어야 하며, 다수의 AVP(속성-값 쌍)를 사용하여 달성할 수 있습니다. AVP는 공통 이름 및 조직 단위와 같은 정보를 정의합니다. 이러한 값을 조합하면 LDAP에 필요한 고유한 문자열이 생성됩니다.

LDAP의 일반적인 구현에는 Red Hat Directory Server, OpenLDAP, Active Directory, IBM Tivoli Directory Server, Oracle Internet Directory, 389 Directory Server가 있습니다.

2장. Red Hat JBoss Enterprise Application Platform에서 보안을 처리하는 방법

보안과 관련된 JBoss EAP와 함께 제공되는 세 가지 구성 요소가 있습니다.

이러한 구성 요소는 일반 보안 개념 의 개요에서 설명한 일반 보안 개념을 기반으로 하지만 일부 JBoss EAP 관련 개념도 구현에 통합합니다.

2.1. 핵심 서비스, 하위 시스템 및 프로필

JBoss EAP는 모듈식 클래스 로드의 개념을 기반으로 합니다. JBoss EAP에서 제공하는 각 API 또는 서비스는 필요에 따라 로드 및 언로드되는 모듈로 구현됩니다. 핵심 서비스는 항상 서버 시작 시 로드되며 추가 하위 시스템을 시작하기 전에 실행해야 하는 서비스입니다.

하위 시스템은 확장을 통해 코어 서버에 추가된 기능 집합입니다. 예를 들어, 다른 하위 시스템은 서블릿 처리를 처리하고 Jakarta Enterprise Beans 컨테이너를 관리하며 Jakarta 트랜잭션 지원을 제공합니다.

프로필은 각 하위 시스템의 구성 세부 정보와 함께 하위 시스템의 명명된 목록입니다. 하위 시스템이 많은 프로필으로 인해 많은 기능 세트가 있는 서버가 생성됩니다. 소규모의 집중적인 하위 시스템 세트가 있는 프로필에는 기능 수가 적지만 풋프린트가 더 작습니다. 기본적으로 JBoss EAP에는 사전 정의된 여러 프로필(예: default,full,ha, full -ha )이 있습니다. 이 프로필에서는 관리 인터페이스 및 관련 보안 영역이 핵심 서비스로 로드됩니다.

2.2. 관리 인터페이스

JBoss EAP는 구성과 상호 작용하고 편집하는 두 가지 기본 관리 인터페이스를 제공합니다. 즉, 관리 콘솔과 관리 CLI가 있습니다. 두 인터페이스 모두 JBoss EAP의 핵심 관리 기능을 제공합니다. 이러한 인터페이스는 동일한 핵심 관리 시스템에 액세스하는 두 가지 방법을 제공합니다.

관리 콘솔은 JBoss EAP용 웹 기반 관리 도구입니다. 서버를 시작 및 중지하고, 애플리케이션을 배포 및 배포 취소하고, 시스템 설정을 조정하며, 서버 구성을 영구적으로 수정하는 데 사용할 수 있습니다. 관리 콘솔에는 변경 시 서버 인스턴스를 다시 시작하거나 다시 로드해야 하는 경우 실시간 알림과 함께 관리 작업을 수행할 수 있는 기능도 있습니다. 관리형 도메인에서 동일한 도메인의 서버 인스턴스 및 서버 그룹은 도메인 컨트롤러의 관리 콘솔에서 중앙에서 관리할 수 있습니다.

관리 CLI는 JBoss EAP용 명령줄 관리 툴입니다. 관리 CLI를 사용하여 서버를 시작 및 중지하고, 애플리케이션을 배포 및 배포 취소하고, 시스템 설정을 구성하고, 다른 관리 작업을 수행할 수 있습니다. 배치 모드에서 작업을 수행할 수 있으므로 여러 작업을 그룹으로 실행할 수 있습니다. 관리 CLI는 관리형 도메인의 도메인 컨트롤러에 연결하여 도메인에서 관리 작업을 실행할 수도 있습니다. 관리 CLI는 웹 기반 관리 툴에서 수행할 수 있는 모든 작업뿐만 아니라 웹 기반 관리 도구에서 사용할 수 없는 기타 하위 수준 작업도 수행할 수 있습니다.

참고

JBoss EAP와 함께 제공되는 클라이언트 외에도 JBoss EAP에 포함된 API를 사용하여 HTTP 또는 기본 인터페이스에서 관리 인터페이스를 호출하도록 다른 클라이언트를 작성할 수 있습니다.

2.3. 자카르타 관리

Jakarta Management를 사용하면 JDK 및 애플리케이션 관리 작업을 원격으로 트리거할 수 있습니다. JBoss EAP의 관리 API는 Jakarta Management가 관리하는 빈으로 노출됩니다. 이러한 관리 빈을 핵심 MBean이라고 하며 이에 대한 액세스는 기본 관리 API 자체와 정확히 동일하게 제어 및 필터링됩니다.

Jakarta Management가 제공하는 빈은 관리 CLI 및 관리 콘솔 외에도 관리 작업에 액세스하고 수행할 수 있는 대체 메커니즘입니다.

2.4. 역할 기반 액세스 제어

RBAC(역할 기반 액세스 제어)는 관리 사용자에 대한 권한 집합을 지정하는 메커니즘입니다. 이를 통해 여러 사용자가 무제한 액세스 권한 없이도 JBoss EAP 서버를 관리하는 책임을 공유할 수 있습니다. JBoss EAP는 관리 사용자를 위한 업무 분리를 통해 조직이 불필요한 권한을 부여하지 않고도 개인 또는 그룹 간에 책임을 쉽게 분배할 수 있도록 합니다. 이렇게 하면 구성, 배포 및 관리에 대한 유연성을 제공하면서 서버 및 데이터의 최대한의 보안이 보장됩니다.

JBoss EAP의 RBAC는 역할 권한과 제약 조건의 조합을 통해 작동합니다. 사전 정의된 7개의 역할이 제공되며 모든 역할은 수정된 권한을 갖습니다. 각 관리 사용자에게는 서버를 관리할 때 사용자가 수행할 수 있는 작업을 지정하는 하나 이상의 역할이 할당됩니다.

JBoss EAP에 대해 RBAC는 기본적으로 비활성화되어 있습니다.

표준 역할

JBoss EAP는 사전 정의된 7가지 사용자 역할을 제공합니다. monitor,Operator,Maintainer,Deployer,Auditor,AdministratorSuperUser. 각 역할에는 다른 권한 집합이 있으며 특정 사용 사례에 맞게 설계되었습니다. Monitor,Operator,Maintainer,AdministratorSuperUser 역할은 상호 간에 성공적으로 빌드되며 각 역할은 이전보다 더 많은 권한이 있습니다. 감사자배포자 역할은 각각 Monitor 및 Maintainer 역할과 비슷하지만 몇 가지 특별 권한 및 제한이 있습니다.

모니터
Monitor 역할의 사용자는 가장 적은 권한이 있으며 서버의 현재 구성 및 상태만 읽을 수 있습니다. 이 역할은 서버 성능을 추적하고 보고해야 하는 사용자를 위한 것입니다. 모니터 는 서버 구성을 수정할 수 없으며 중요한 데이터 또는 작업에 액세스할 수 없습니다.
Operator
Operator 역할은 서버의 런타임 상태를 수정하는 기능을 추가하여 Monitor 역할을 확장합니다. 즉, Operator 는 서버를 다시 로드하고 종료하고 자카르타 메시징 대상을 일시 중지하고 다시 시작할 수 있습니다. Operator 역할은 애플리케이션 서버의 실제 또는 가상 호스트를 담당하는 사용자에게 이상적입니다. 따라서 필요한 경우 서버를 종료하고 올바르게 다시 시작할 수 있습니다. Operator 는 서버 구성을 수정하거나 중요한 데이터 또는 작업에 액세스할 수 없습니다.
유지 관리자
유지 관리 대상 역할에는 민감한 데이터 및 작업을 제외하고 런타임 상태 및 모든 구성을 보고 수정할 수 있습니다. 유지 관리 역할은 중요한 데이터 및 작업에 액세스할 수 없는 범용 역할입니다. 유지 관리 역할을 사용하면 사용자에게 암호 및 기타 중요한 정보에 대한 액세스 권한을 부여하지 않고 서버를 관리할 수 있는 거의 모든 액세스 권한이 부여될 수 있습니다. 유지 관리자는 중요한 데이터 또는 작업에 액세스할 수 없습니다.
관리자
Administrator 역할은 감사 로깅 시스템을 제외한 서버의 모든 리소스 및 작업에 대한 무제한 액세스 권한을 갖습니다. Administrator 역할은 중요한 데이터 및 작업에 액세스할 수 있습니다. 이 역할은 액세스 제어 시스템을 구성할 수도 있습니다. Administrator 역할은 중요한 데이터를 처리하거나 사용자 및 역할을 구성할 때만 필요합니다. 관리자는 감사 로깅 시스템에 액세스할 수 없으며 Auditor 또는 SuperUser 역할로 변경할 수 없습니다.
수퍼유저
SuperUser 역할에 제한이 없으며 감사 로깅 시스템을 포함하여 서버의 모든 리소스와 작업에 대한 전체 액세스 권한이 있습니다. RBAC가 비활성화되면 모든 관리 사용자에게 SuperUser 역할과 동일한 권한이 있습니다.
deployer
Deployer 역할에는 Monitor (모니터)와 동일한 권한이 있지만, 배포의 구성 및 상태와 애플리케이션 리소스로 활성화된 기타 리소스 유형을 수정할 수 있습니다.
감사자
Auditor 역할에는 Monitor 역할의 모든 권한이 있으며 중요한 데이터를 보고 수정할 수도 있습니다. 감사 로깅 시스템에 대한 전체 액세스 권한이 있습니다. Auditor 역할은 감사 로깅 시스템에 액세스할 수 있는 SuperUser 이외의 유일한 역할입니다. 감사 자는 중요한 데이터 또는 리소스를 수정할 수 없습니다. 읽기 액세스만 허용됩니다.

권한

권한은 각 역할에 수행할 수 있는 작업을 결정합니다. 모든 역할에 모든 권한이 있는 것은 아닙니다. 특히 SuperUser 에는 모든 권한이 있으며 Monitor 에 가장 적은 권한이 있습니다. 각 권한은 단일 리소스 범주에 대한 읽기 및/또는 쓰기 액세스 권한을 부여할 수 있습니다. 카테고리는 런타임 상태, 서버 구성, 중요한 데이터, 감사 로그 및 액세스 제어 시스템입니다.

표 2.1. 모니터, Operator, 유지 보수 및 배포자에 대한 각 역할의 권한

 모니터Operator유지 관리자deployer

설정 및 상태 읽기

중요한 데이터 2읽기

    

중요한 데이터 2수정

    

감사 로그 읽기/수정

    

런타임 상태 수정

 

1

영구 설정 수정

  

1

액세스 제어 읽기/수정

    

1 권한은 애플리케이션 리소스로 제한됩니다.

표 2.2. 감사자, 관리 및 SuperUser에 대한 각 역할의 권한

 감사자관리자수퍼유저

설정 및 상태 읽기

중요한 데이터 2읽기

중요한 데이터 2수정

 

감사 로그 읽기/수정

 

런타임 상태 수정

 

영구 설정 수정

 

액세스 제어 읽기/수정

 

2 민감도 데이터를 사용하여 구성하는 리소스는 무엇입니까.

Constraints

제약 조건은 지정된 리소스 목록에 대한 access-control 구성 세트로 지정됩니다. RBAC 시스템은 제약 조건과 역할 권한의 조합을 사용하여 특정 사용자가 관리 작업을 수행할 수 있는지 확인합니다.

제한 조건은 다음 세 가지 분류로 나뉩니다.

애플리케이션 제한
애플리케이션 제약 조건은 배포자 사용자가 액세스할 수 있는 리소스 및 속성 집합을 정의합니다. 기본적으로 활성화된 유일한 애플리케이션 제한 조건은 배포 및 배포 오버레이를 포함하는 core입니다. 또한 애플리케이션 제약 조건도 데이터 소스, 로깅, 메일, 메시징, 이름 지정, 리소스 어댑터 및 보안에 대해 기본적으로 활성화되어 있지 않습니다. 이러한 제약 조건을 통해 배포자 사용자는 애플리케이션을 배포할 뿐만 아니라 해당 애플리케이션에 필요한 리소스를 구성하고 유지 관리할 수 있습니다.
민감도 제한
민감도 제한 조건은 중요한 리소스 집합을 정의합니다. 일반적으로 중요한 리소스는 암호와 같은 비밀 또는 네트워킹, JVM 구성 또는 시스템 속성과 같이 서버 작동에 심각한 영향을 미치는 리소스입니다. 액세스 제어 시스템 자체도 중요한 것으로 간주됩니다. 중요한 리소스에 쓰기에 허용되는 유일한 역할은 Administrator 및 SuperUser입니다. Auditor 역할은 중요한 리소스만 읽을 수 있습니다. 다른 역할에는 액세스할 수 없습니다.
Vault 표현식 제한
vault 표현식 제약 조건은 자격 증명 모음 식을 읽고 쓰는 것이 중요한 작업으로 간주되는지를 정의합니다. 기본적으로 자격 증명 모음 표현식을 읽고 쓰는 것은 중요한 작업입니다.

2.4.1. RBAC 구성

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

절차

  1. 다음 명령을 사용하여 RBAC를 활성화합니다.

    /core-service=management/access=authorization:write-attribute(name=provider,value=rbac)
  2. SuperUser 또는 JBoss EAP의 관리자로 RBAC를 구성합니다.

    • 읽기 전용 액세스 권한이 있는 Monitor 역할과 같이 지원되는 역할 중 하나를 추가하려면 다음 명령을 사용합니다.

      /core-service=management/access=authorization/role-mapping=Monitor:add()
      참고

      Monitor 역할 및 추가할 수 있는 기타 지원되는 역할에 대한 자세한 내용은 역할 기반 액세스 제어를 참조하십시오.

    • Monitor 역할과 같은 사용자를 특정 역할에 추가하려면 다음 명령을 사용합니다.

      /core-service=management/access=authorization/role-mapping=Monitor/include=user-timRO:add(name=timRO,type=USER)
    • Monitor 역할과 같은 특정 역할에 그룹을 추가하려면 다음 명령을 사용합니다.

      /core-service=management/access=authorization/role-mapping=Monitor/include=group-LDAP_MONITORS:add(name=LDAP_MONITORS, type=GROUP)
    • 특정 역할에서 사용자 또는 그룹을 제외하려면 다음 명령을 사용하십시오.

      /core-service=management/access=authorization/role-mapping=Monitor/exclude=group-LDAP_MONITORS:add(name=LDAP_, type=GROUP)
  3. 서버 또는 호스트를 다시 시작하여 RBAC 구성으로 작동할 수 있습니다.

    • 호스트 시스템을 다시 시작하려면 다음 명령을 사용하십시오.

      reload --host=master
    • 독립 실행형 모드에서 서버를 다시 시작하려면 다음 명령을 사용하십시오.

      reload

2.5. 선언적 보안 및 자카르타 인증

선언적 보안은 컨테이너를 사용하여 보안을 관리하여 보안 문제를 애플리케이션 코드와 분리하는 방법입니다. 컨테이너에서는 파일 권한 또는 사용자, 그룹 및 역할을 기반으로 권한 부여 시스템을 제공합니다. 일반적으로 이 접근 방식은 프로그래밍 방식의 보안보다 뛰어납니다. 이를 통해 애플리케이션 자체는 보안에 대한 책임을 모두 얻을 수 있습니다. JBoss EAP는 보안 하위 시스템에서 보안 도메인을 사용하여 선언적 보안을 제공합니다.

Jakarta Authentication은 사용자 인증 및 권한 부여를 위해 설계된 Java 패키지 집합을 포함하는 선언적 보안 API입니다. API는 표준 PAM(Pluggable Authentication Modules) 프레임워크의 Java 구현입니다. 사용자 기반 권한을 지원하기 위해 Jakarta EE 액세스 제어 아키텍처를 확장합니다. JBoss EAP 보안 하위 시스템은 실제로 Jakarta Authentication API를 기반으로 합니다.

Jakarta Authentication은 보안 하위 시스템의 기반이므로 인증은 플러그 방식으로 수행됩니다. 이를 통해 Java 애플리케이션은 Kerberos 또는 LDAP와 같은 기본 인증 기술과 독립적으로 유지할 수 있으며 보안 관리자가 다양한 보안 인프라에서 작업할 수 있습니다. 보안 인프라와의 통합은 보안 관리자 구현을 변경하지 않고 수행할 수 있습니다. Jakarta Authentication이 사용하는 인증 스택의 구성만 변경하면 됩니다.

2.6. Elytron 하위 시스템

elytron 하위 시스템은 JBoss EAP 7.1에서 도입되었습니다. 전체 애플리케이션 서버에서 보안을 통합하는 데 사용되는 보안 프레임워크인 WildFly Elytron 프로젝트를 기반으로 합니다. elytron 하위 시스템을 사용하면 애플리케이션과 관리 인터페이스를 모두 보호할 수 있는 단일 구성 지점을 사용할 수 있습니다. WildFly Elytron은 기능 맞춤형 구현을 제공하고 elytron 하위 시스템과의 통합을 위한 API 및 SPI도 제공합니다.

또한 WildFly Elytron에는 몇 가지 중요한 기능이 있습니다.

  • HTTP 및 SASL 인증을 위한 인증 메커니즘 강화.
  • SecurityIdentities를 보안 도메인 전체에서 전파할 수 있는 향상된 아키텍처. 이렇게 하면 권한 부여에 사용할 수 있는 투명한 변환이 보장됩니다. 이 변환은 구성 가능한 역할 디코더, 역할 매퍼 및 권한 매퍼를 사용하여 수행됩니다.
  • 암호화 제품군 및 프로토콜을 포함한 SSL/TLS 구성을 위한 중앙 집중식 지점.
  • 빠른 SecureIdentity 구축 및 SSL/TLS 연결 구축에 대한 권한 부여와 같은 SSL/TLS 최적화. 빠른 SecureIdentity 구축으로 인해 요청별로 SecureIdentity 를 구축할 필요가 없습니다. SSL/TLS 연결을 설정하기 위한 인증을 긴밀하게 연결하면 첫 번째 요청을 수신하는 데 사용 권한 검사가 수행됩니다.
  • 이전 vault 구현을 대체하여 일반 텍스트 문자열을 저장하는 보안 자격 증명 저장소입니다.

elytron 하위 시스템은 레거시 보안 하위 시스템 및 레거시 코어 관리 인증과 동시에 존재합니다. 레거시 및 Elytron 방법 둘 다 관리 인터페이스를 보호하고 애플리케이션의 보안을 제공하는 데 사용할 수 있습니다.

중요

PicketBox를 기반으로 하는 Elytron의 아키텍처와 레거시 보안 하위 시스템은 매우 다릅니다. Elytron을 사용하면 현재 운영 중인 동일한 보안 환경에서 운영할 수 있는 솔루션을 만들려는 시도가 이루어졌습니다. 그러나 모든 PicketBox 구성 옵션이 Elytron에서 동등한 구성 옵션을 갖는 것은 아닙니다.

레거시 보안 구현을 사용할 때 보유하고 있는 Elytron을 사용하여 유사한 기능을 달성할 수 있도록 문서에서 정보를 찾을 수 없는 경우 다음 방법 중 하나로 도움을 얻을 수 있습니다.

2.6.1. 핵심 개념 및 구성 요소

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

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

2.6.1.1. 기능 및 요구 사항

기능은 JBoss EAP에서 사용되는 기능 중 하나이며 관리 계층을 사용하여 노출됩니다. 한 기능은 다른 기능에 따라 달라질 수 있으며 이러한 종속성은 관리 계층에 따라 조정됩니다. 일부 기능은 JBoss EAP에서 자동으로 제공되지만 런타임 시 사용 가능한 전체 기능 집합은 JBoss EAP 구성을 사용하여 결정됩니다. 관리 계층은 다른 기능에 필요한 모든 기능이 서버 시작 중에 그리고 구성을 변경할 때 표시되는지 확인합니다. 기능은 JBoss 모듈 및 확장 기능과 통합되지만 둘 다 고유한 개념입니다.

의존하는 다른 기능을 등록하는 것 외에도, 기능은 해당 기능과 관련된 일련의 요구 사항을 등록해야 합니다. 기능은 다음과 같은 유형의 요구 사항을 지정할 수 있습니다.

하드 요구 사항
기능은 다른 기능에 따라 작동하므로 항상 존재해야 합니다.
선택적 요구 사항
기능의 선택적인 측면은 활성화할 수 있거나 활성화할 수 없는 다른 기능에 따라 다릅니다. 따라서 구성을 분석할 때까지 요구 사항을 결정하거나 알 수 없습니다.
런타임 전용 요구 사항
기능은 런타임에 필요한 기능이 있는지 확인합니다. 필요한 기능이 있는 경우 이 기능이 사용됩니다. 필요한 기능이 없으면 사용되지 않습니다.

기능 및 요구 사항에 대한 자세한 내용은 WildFly 설명서에서 확인할 수 있습니다.

2.6.1.2. API, SPI 및 사용자 정의 구현

Elytron은 다른 하위 시스템과 소비자가 직접 사용할 수 있도록 보안 API 및 SPI 세트를 제공하므로 통합 오버헤드가 줄어듭니다. 대부분의 사용자는 제공된 JBoss EAP 기능을 사용하지만 맞춤형 구현에서는 Elytron API 및 SPI를 사용하여 Elytron 기능을 교체하거나 확장할 수도 있습니다.

2.6.1.3. 보안 도메인

보안 도메인은 하나 이상의 보안 영역과 변환을 수행하는 리소스 집합에서 지원하는 보안 정책을 나타냅니다. 보안 도메인은 SecurityIdentity 를 생성합니다. SecurityIdentity 는 애플리케이션과 같이 권한을 수행하는 다른 리소스에서 사용합니다. SecurityIdentity 는 원시 AuthorizationIdentity 및 관련 역할 및 권한을 기반으로 하는 현재 사용자의 표현입니다.

다른 보안 도메인에서 SecurityIdentity흐름을 허용하도록 보안 도메인을 구성할 수도 있습니다. ID가 유입되면 원래의 AuthorizationIdentity 가 유지되고 새 역할 및 권한 집합이 할당되어 새 SecurityIdentity 가 생성됩니다.

중요

배포는 배포당 하나의 Elytron 보안 도메인 사용으로 제한됩니다. 여러 레거시 보안 도메인이 필요한 시나리오는 이제 하나의 Elytron 보안 도메인을 사용하여 수행할 수 있습니다.

2.6.1.4. 보안 영역

보안 영역은 ID 저장소에 대한 액세스를 제공하며 자격 증명을 가져오는 데 사용됩니다. 이러한 자격 증명을 사용하면 인증 메커니즘이 인증을 수행하기 위한 원시 AuthorizationIdentity 를 얻을 수 있습니다. 또한 인증 메커니즘이 증거를 검증할 때 검증을 수행할 수 있습니다.

하나 이상의 보안 영역을 보안 도메인과 연결할 수 있습니다. 일부 보안 영역 구현에서는 수정을 위한 API도 노출하므로 보안 영역에서 기본 ID 저장소를 업데이트할 수 있습니다.

2.6.1.5. 역할 종료자

역할 디코더는 보안 도메인과 연결되며 현재 사용자의 역할을 디코딩하는 데 사용됩니다. 역할 디코더는 보안 영역에서 반환된 원시 AuthorizationIdentity 를 가져와서 속성을 역할로 변환합니다.

2.6.1.6. 역할 매퍼

역할 매퍼는 역할 수정을 ID에 적용합니다. 이는 역할의 형식을 정규화하는 것에서 특정 역할을 추가하거나 제거하는 데 이르기까지 다양합니다. 역할 매퍼는 보안 도메인뿐만 아니라 두 보안 영역과 연결할 수 있습니다. 역할 매퍼가 보안 영역과 연결된 경우, 역할 매핑을 보안 영역 수준에서 적용한 후 역할 디코딩 또는 추가 역할 매핑이 보안 도메인 수준에서 수행됩니다. 역할 매퍼와 역할 디코더와 같은 다른 변환이 보안 도메인에 구성된 경우 역할 매퍼를 적용하기 전에 다른 모든 변환이 수행됩니다.

2.6.1.7. 권한 매퍼

권한 매퍼는 보안 도메인과 연결되며 권한 집합을 SecurityIdentity 에 할당합니다.

2.6.1.8. 수석 혁신자

주요 변환기는 elytron 하위 시스템 내의 여러 위치에서 사용할 수 있습니다. 주요 변환기는 이름을 다른 이름으로 변환하거나 매핑할 수 있습니다.

2.6.1.9. Princders

주요 디코더는 elytron 하위 시스템 내의 여러 위치에서 사용할 수 있습니다. 주체 디코더는 주체 에서 이름의 문자열 표시로 ID를 변환합니다. 예를 들어 X500PrincipalDecoder 를 사용하면 X500Principal 을 인증서의 고유 이름에서 문자열 표시로 변환할 수 있습니다.

2.6.1.10. 영역 매퍼

영역 매퍼는 보안 도메인과 연결되며 보안 도메인에 여러 보안 영역이 구성된 경우 사용됩니다. 영역 매퍼는 http-authentication-factory 및 sasl -authentication-factory메커니즘 또는 메커니즘 과도 연결할 수 있습니다. 영역 매퍼는 인증 중에 제공된 이름을 사용하여 인증 및 원시 AuthorizationIdentity 를 가져올 보안 영역을 선택합니다.

2.6.1.11. 인증 정보

인증 팩토리는 인증 정책을 나타냅니다. 인증은 보안 도메인, 메커니즘 팩토리 및 메커니즘 선택기와 연결됩니다. 보안 도메인은 인증할 SecurityIdentity 를 제공하고, 메커니즘 팩토리는 서버 측 인증 메커니즘을 제공하며, 메커니즘 선택기는 선택한 메커니즘과 관련된 구성을 가져오는 데 사용됩니다. 메커니즘 선택기에는 원격 클라이언트에 있어야 하는 영역 이름에 대한 정보와 인증 프로세스 중에 사용할 추가 주요 변환기 및 영역 매퍼가 포함될 수 있습니다.

2.6.1.12. KeyStores

키 저장소 는 키 저장소 유형, 해당 위치 및 액세스하기 위한 자격 증명을 포함한 키 저장소 또는 신뢰 저장소의 정의입니다.

2.6.1.13. 키 관리자

key-manager키 저장소를 참조하며 SSL 컨텍스트와 함께 사용됩니다.

2.6.1.14. 신뢰 관리자

trust-manager키 저장소에 정의되어 있으며 일반적으로 양방향 SSL/TLS의 경우 SSL 컨텍스트와 함께 사용됩니다.

2.6.1.15. SSL 문맥

elytron 하위 시스템 내에 정의된 SSL 컨텍스트는 javax.net.ssl.SSLContext 이므로 SSL 컨텍스트를 직접 사용하는 모든 항목에서 사용할 수 있습니다. SSL 컨텍스트의 일반적인 구성 외에도 암호화 제품군 및 프로토콜과 같은 추가 항목을 구성할 수 있습니다. SSL 컨텍스트는 구성된 추가 항목을 래핑합니다.

2.6.1.16. 보안 인증 정보 저장소

일반 텍스트 문자열 암호화에 사용된 이전 vault 구현이 새로 설계된 자격 증명 저장소로 교체되었습니다. 자격 증명 저장소는 저장하는 자격 증명 보호 외에도 일반 텍스트 문자열을 저장하는 데 사용됩니다.

2.6.2. Elytron 인증 프로세스

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

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

  1. 적절한 메커니즘 구성을 결정하고 구성합니다.
  2. 들어오는 주체는 SecurityIdentity 에 매핑됩니다.
  3. SecurityIdentity 는 적절한 보안 영역을 결정하는 데 사용됩니다.
  4. 보안 영역을 식별하면 주체가 다시 변환됩니다.
  5. 메커니즘별 변환을 지원하는 최종 전환이 발생합니다.

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

그림 2.1. Elytron 인증 프로세스

Elytron 인증 프로세스
사전 영역 매핑

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

  1. mechanism Realm - pre-realm-principal-transformer
  2. 메커니즘 구성 - pre-realm-principal-transformer
  3. 보안 도메인 - principal-decoderpre-realm-principal-transformer

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

그림 2.2. 사전 영역 매핑

사전 영역 매핑
영역 이름 맵핑

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

  1. 메커니즘 영역 - realm-mapper
  2. 메커니즘 구성 - realm-mapper
  3. 보안 도메인 - realm-mapper

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

그림 2.3. 영역 이름 맵핑

영역 이름 맵핑
사후 영역 매핑

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

  1. mechanism Realm - post-realm-principal-transformer
  2. 메커니즘 구성 - post-realm-principal-transformer
  3. 보안 도메인 - post-realm-principal-transformer

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

그림 2.4. 사후 영역 매핑

사후 영역 매핑
최종 주체 전환

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

  1. mechanism Realm - 최종 주체 변환자
  2. 메커니즘 구성 - 최종 주체-트랜젝터
  3. realm Mapping - principal-transformer

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

그림 2.5. 최종 주체 전환

최종 주체 전환
Realm Identity 확보

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

2.6.3. HTTP 인증

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

HttpAuthenticationFactory 는 다음을 참조합니다.

SecurityDomain
메커니즘 인증이 수행되는 보안 도메인.
HttpServerAuthenticationMechanismFactory
서버 측 HTTP 인증 메커니즘을 위한 일반 팩토리입니다.
MechanismConfigurationSelector
이를 사용하여 인증 메커니즘에 대한 추가 구성을 제공할 수 있습니다. MechanismConfigurationSelector 의 목적은 선택한 메커니즘에 대한 특정 구성을 얻는 것입니다. 여기에는 원격 클라이언트에 메커니즘이 있어야 하는 영역 이름, 인증 프로세스 중에 사용할 추가 주요 변환기, 영역 매퍼에 대한 정보가 포함될 수 있습니다.

2.6.4. SASL 인증

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

SaslAuthenticationFactory 는 다음을 참조합니다.

SecurityDomain
메커니즘 인증이 수행되는 보안 도메인.
SaslServerFactory
서버측 SASL 인증 메커니즘을 위한 일반적인 팩토리.
MechanismConfigurationSelector
이를 사용하여 인증 메커니즘에 대한 추가 구성을 제공할 수 있습니다. MechanismConfigurationSelector 의 목적은 선택한 메커니즘에 대한 특정 구성을 얻는 것입니다. 여기에는 원격 클라이언트에 메커니즘이 있어야 하는 영역 이름, 인증 프로세스 중에 사용할 추가 주요 변환기, 영역 매퍼에 대한 정보가 포함될 수 있습니다.

2.6.5. Elytron Subsystem과 레거시 시스템 간의 상호 작용

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

2.6.6. Elytron Subsystem의 리소스

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

팩토리
aggregate-http-server-mechanism-factory
HTTP 서버 팩토리가 다른 HTTP 서버 팩토리의 집계인 HTTP 서버 팩토리 정의입니다.
aggregate-sasl-server-factory
SASL 서버 팩토리가 다른 SASL 서버 팩토리의 집계인 SASL 서버 팩토리 정의.
configurable-http-server-mechanism-factory
다른 HTTP 서버 팩토리를 래핑하고 지정된 구성 및 필터링을 적용하는 HTTP 서버 팩토리 정의입니다.
configurable-sasl-server-factory
다른 SASL 서버 팩토리를 래핑하고 지정된 구성 및 필터링을 적용하는 SASL 서버 팩토리 정의입니다.
custom-credential-security-factory
사용자 지정 자격 증명 SecurityFactory 정의.
http-authentication-factory

HttpServerAuthenticationMechanismFactory 와 보안 도메인의 연결을 포함하는 리소스입니다.

자세한 내용은 JBoss EAP ID 관리 구성 방법 의 인증서 구성을 참조하십시오.

kerberos-security-factory

인증 중에 사용하기 위한 보안 팩토리입니다.

자세한 내용은 JBoss EAP용 Kerberos로 SSO를 설정하는 방법에서 Elytron 하위 시스템 구성을 참조하십시오.

mechanism-provider-filtering-sasl-server-factory
공급업체를 사용하여 팩토리가 로드된 공급업체별 필터링을 활성화하는 SASL 서버 팩토리 정의입니다.
provider-http-server-mechanism-factory
HTTP 서버 팩토리가 프로바이더 목록에서 팩토리 집계인 HTTP 서버 팩토리 정의입니다.
provider-sasl-server-factory
SASL 서버 팩토리가 공급업체 목록에서 팩토리 집계인 SASL 서버 팩토리 정의.
sasl-authentication-factory

보안 도메인과 SASL 서버 팩토리를 연결하는 리소스.

자세한 내용은 JBoss EAP용 서버 보안 구성 방법에서 새 ID 저장소로 관리 인터페이스 보안 유지를 참조하십시오.

service-loader-http-server-mechanism-factory
HTTP 서버 팩토리가 ServiceLoader 를 사용하여 식별된 팩토리의 집계인 HTTP 서버 팩토리 정의입니다.
service-loader-sasl-server-factory
SASL 서버 팩토리가 ServiceLoader 를 사용하여 식별된 팩토리의 집계인 SASL 서버 팩토리 정의.
수석 혁신자
aggregate-principal-transformer
개별 변환기에서는 게스트가 아닌 주체를 반환할 때까지 원래 주체를 변환하려고 합니다.
chained-principal-transformer
주요 변환기가 다른 주요 변환기의 체인인 주요 변환기 정의.
constant-principal-transformer
주요 변환기는 항상 동일한 상수를 반환하는 주요 변환기 정의입니다.
custom-principal-transformer
사용자 지정 수석 변환기 정의.
regex-principal-transformer
정규 표현식 기반의 주체 변환기.
regex-validating-principal-transformer
정규 표현식을 사용하여 이름을 검증하는 정규 표현식 기반의 주체 변환기입니다.
Princders
aggregate-principal-decoder
주요 디코더가 다른 주요 디코더의 집계인 주요 디코더 정의입니다.
연결-principal-decoder
주요 디코더가 다른 주요 디코더의 연결인 주요 디코더 정의입니다.
constant-principal-decoder
항상 동일한 상수를 반환하는 주체 디코더의 정의.
custom-principal-decoder
사용자 지정 주체 디코더 정의.
x500-attribute-principal-decoder

X500 속성 기반 주요 디코더 정의.

자세한 내용은 JBoss EAP ID 관리 구성 방법 의 인증서 구성을 참조하십시오.

x509-subject-alternative-name-evidence-decoder

X.509 인증서에서 주체로 주체 대체 이름 확장을 사용하는 증거 디코더.

자세한 내용은 How to Configure Server Security for JBoss EAP에서 X.509 Certificate with Subject Alternative Name Extension의 Evidence compreviewder 구성을 참조하십시오.

영역 매퍼
constant-realm-mapper
항상 동일한 값을 반환하는 상수 영역 매퍼의 정의입니다.
custom-realm-mapper
사용자 지정 영역 매퍼 정의.
mapped-regex-realm-mapper
먼저 정규 표현식을 사용하여 영역 이름을 추출하는 영역 매퍼 구현에 대한 정의가 구성된 영역 이름 매핑을 사용하여 변환됩니다.
simple-regex-realm-mapper
정규 표현식에서 캡처 그룹을 사용하여 영역 이름을 추출하려고 시도하는 간단한 영역 매퍼의 정의가 일치 항목을 제공하지 않으면 대신 위임 영역 매퍼가 사용됩니다.
영역
aggregate-realm

두 영역의 집계인 영역 정의(인증 단계용 및 권한 부여 단계의 ID를 로드하기 위한 영역 정의).

참고

내보낸 레거시 보안 도메인은 aggregate-realm 의 권한 부여 단계에 대해 Elytron 보안 영역으로 사용할 수 없습니다.

caching-realm

다른 보안 영역에 캐싱을 활성화하는 영역 정의입니다. 캐싱 전략은 Least Recently Used 로, 최대 항목 수에 도달하면 가장 적게 액세스한 항목이 삭제됩니다.

자세한 내용은 JBoss EAP ID 관리 구성 방법의 보안 realms 에 대한 캐싱 설정을 참조하십시오.

custom-modifiable-realm
수정 가능한 것으로 구성된 사용자 지정 영역은 ModifiableSecurityRealm 인터페이스를 구현해야 합니다. 영역을 수정할 수 있는 관리 작업으로 구성하면 이 영역을 조작할 수 있습니다.
custom-realm
사용자 지정 영역 정의는 s SecurityRealm 인터페이스 또는 ModifiableSecurityRealm 인터페이스를 구현할 수 있습니다. 구현된 인터페이스와 상관없이 영역을 관리하기 위해 관리 작업을 노출하지 않습니다. 그러나 영역에 종속된 다른 서비스는 계속 유형 점검을 수행하고 수정 API에 액세스할 수 있습니다.
filesystem-realm

파일 시스템에서 지원하는 간단한 보안 영역 정의.

자세한 내용은 JBoss EAP용 ID 관리 구성 방법의 파일 시스템 기반 ID 저장소로 인증 구성을 참조하십시오.

identity-realm
ID가 관리 모델에 표시되는 보안 영역 정의.
jdbc-realm

JDBC를 사용하여 데이터베이스에서 지원하는 보안 영역 정의.

자세한 내용은 JBoss EAP용 ID 관리 구성 방법의 데이터베이스 기반 ID 저장소를 사용한 인증 구성을 참조하십시오.

key-store-realm

키 저장소에서 지원하는 보안 영역 정의.

자세한 내용은 JBoss EAP ID 관리 구성 방법 의 인증서 구성을 참조하십시오.

ldap-realm

LDAP에서 지원하는 보안 영역 정의.

자세한 내용은 JBoss EAP용 ID 관리 구성 방법의 LDAP 기반 ID 저장소로 인증 구성을 참조하십시오.

properties-realm

속성 파일에서 지원하는 보안 영역 정의.

JBoss EAP 의 ID 관리를 구성하는 방법의 속성 파일 기반 ID 저장소로 인증을 구성합니다 .

token-realm
보안 토큰에서 ID를 검증하고 추출할 수 있는 보안 영역 정의입니다.
권한 매퍼
custom-permission-mapper
사용자 지정 권한 매퍼 정의.
logical-permission-mapper
논리적 권한 매퍼의 정의.
simple-permission-mapper
단순하게 구성된 권한 매퍼의 정의.
constant-permission-mapper
항상 동일한 상수를 반환하는 권한 매퍼의 정의.
역할 종료자
custom-role-decoder
사용자 지정 RoleDecoder 정의.
simple-role-decoder
단일 특성을 사용하고 역할에 직접 매핑하는 간단한 RoleDecoder 정의.
source-address-role-decoder
클라이언트의 IP 주소를 기반으로 ID에 역할을 할당하는 source-address-role-decoder 의 정의입니다.
aggregate-role-decoder

두 개 이상의 역할 디코더에서 반환한 역할을 집계하는 aggregate-role-decoder 의 정의입니다.

자세한 내용은 JBoss EAP용 ID 관리 구성 방법의 파일 시스템 기반 ID 저장소로 인증 구성을 참조하십시오.

역할 매퍼
add-prefix-role-mapper
제공된 각 항목에 접두사를 추가하는 역할 매퍼의 역할 매퍼 정의입니다.
add-suffix-role-mapper
제공된 각 접미사를 추가하는 역할 매퍼 정의입니다.
aggregate-role-mapper
역할 매퍼가 다른 역할 매퍼의 집계인 역할 매퍼 정의입니다.
constant-role-mapper

일정한 역할 집합이 항상 반환되는 역할 매퍼 정의입니다.

자세한 내용은 JBoss EAP ID 관리 구성 방법 의 인증서 구성을 참조하십시오.

custom-role-mapper
사용자 지정 역할 매퍼 정의.
logical-role-mapper
참조된 역할 매퍼 2개를 사용하여 논리 작업을 수행하는 역할 매퍼의 역할 매퍼 정의.
mapped-role-mapper
역할 이름의 사전 구성된 매핑을 사용하는 역할 매퍼 정의입니다.
regex-role-mapper

정규식을 사용하여 역할을 변환하는 역할 매퍼의 역할 매퍼 정의 예를 들어 "app-admin", "app-operator"를 각각 "admin" 및 "operator"에 매핑할 수 있습니다.

자세한 내용은 regex-role-mapper 특성을 참조하십시오.

SSL 구성 요소
client-ssl-context

연결의 클라이언트 측에서 사용할 SSLContext입니다.

자세한 내용은 How to Configure Server Security for JBoss EAP에서 client-ssl-context 사용을 참조하십시오.

filtering-key-store

키 저장소를 필터링하여 키 저장소를 제공하는 키 저장소 정의 필터링.

자세한 내용은 How to Configure Server Security for JBoss EAP에서 filtering -key-store 사용을 참조하십시오.

key-manager

SSL 컨텍스트를 생성하는 데 사용되는 키 관리자 목록을 생성하기 위한 키 관리자 정의입니다.

자세한 내용은 JBoss EAP의 서버 보안 구성 방법에서 Elytron 하위 시스템을 사용하여 관리 인터페이스에 대한 일방향 SSL/TLS 활성화 를 참조하십시오.

key-store

키 저장소 정의입니다.

자세한 내용은 JBoss EAP의 서버 보안 구성 방법에서 Elytron 하위 시스템을 사용하여 관리 인터페이스에 대한 일방향 SSL/TLS 활성화 를 참조하십시오.

ldap-key-store

LDAP 서버에서 키 저장소를 로드하는 LDAP 키 저장소 정의입니다.

자세한 내용은 How to Configure Server Security for JBoss EAP에서 ldap-key-store 사용을 참조하십시오.

server-ssl-context

연결의 서버 측에서 사용할 SSL 컨텍스트입니다.

자세한 내용은 JBoss EAP의 서버 보안 구성 방법에서 Elytron 하위 시스템을 사용하여 관리 인터페이스에 대한 일방향 SSL/TLS 활성화 를 참조하십시오.

trust-manager

SSL 컨텍스트를 생성하는 데 사용되는 TrustManager 목록을 생성하기 위한 신뢰 관리자 정의입니다.

자세한 내용은 JBoss EAP 서버 보안 구성 방법에서 Elytron 하위 시스템을 사용하여 관리 인터페이스에 대한 양방향 SSL/TLS 사용을 참조하십시오.

기타
aggregate-providers
두 개 이상의 프로바이더 로더 리소스 집계.
authentication-configuration
JBoss EAP에 배포된 클라이언트 및 원격 연결을 만들 때 인증을 위해 기타 리소스에 사용되는 개별 인증 구성 정의입니다.
authentication-context
JBoss EAP 및 기타 리소스에 배포된 클라이언트가 원격 연결을 만들 ssl-context 및 인증 구성을 제공하는 데 사용되는 개별 인증 컨텍스트 정의입니다.
credentials-store

외부 서비스의 암호와 같은 중요한 정보에 대한 별칭을 유지하기 위한 자격 증명 저장소.

자세한 내용은 Create a Credential Store in How to Configure Server Security for JBoss EAP를 참조하십시오.

dir-context

디렉터리(LDAP) 서버에 연결할 구성입니다.

자세한 내용은 How to Configure Server Security for JBoss EAP에서 ldap-key-store 사용을 참조하십시오.

provider-loader
프로바이더 로더 정의.
security-domain

보안 도메인 정의.

자세한 내용은 JBoss EAP ID 관리 구성 방법 의 인증서 구성을 참조하십시오.

보안 속성
설정할 보안 속성 정의입니다.

2.7. 코어 관리 인증

코어 관리 인증은 ManagementRealm 을 사용하여 핵심 관리 기능에 대한 관리 인터페이스 HTTP 및 네이티브 보안을 담당합니다. 코어 관리에 구축되며 기본적으로 코어 서비스로 활성화 및 구성됩니다. 관리 인터페이스 보안만 담당합니다.

2.7.1. 보안 영역

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

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

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

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

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

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

2.7.2. 기본 보안

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

참고

기본적으로 관리 인터페이스는 역할을 사용하지 않는 간단한 액세스 제어를 사용하도록 구성됩니다. 따라서 기본적으로 모든 사용자는 단순한 액세스 제어를 사용할 때 SuperUser 역할과 동일한 권한을 갖습니다. 이 역할은 기본적으로 모든 항목에 액세스할 수 있습니다.

2.7.2.1. 네이티브 인터페이스를 사용한 로컬 및 원격 클라이언트 인증

기본 인터페이스 또는 관리 CLI는 실행 중인 JBoss EAP 인스턴스와 동일한 호스트에서 로컬로 호출하거나 다른 시스템에서 원격으로 호출할 수 있습니다. 기본 인터페이스를 사용하여 연결을 시도할 때 JBoss EAP는 클라이언트가 사용 가능한 SASL 인증 메커니즘(예: 로컬 jboss 사용자, BASIC 등) 목록을 클라이언트에 제공합니다. 클라이언트는 원하는 인증 메커니즘을 선택하고 JBoss EAP 인스턴스 인증을 시도합니다. 오류가 발생하면 나머지 메커니즘으로 다시 시도하거나 연결 시도를 중지합니다. 로컬 클라이언트에는 로컬 jboss 사용자 인증 메커니즘을 사용하는 옵션이 있습니다. 이 보안 메커니즘은 클라이언트의 로컬 파일 시스템에 액세스하는 기능을 기반으로 합니다. 로그인하려는 사용자가 실제로 JBoss EAP 인스턴스와 동일한 호스트의 로컬 파일 시스템에 액세스할 수 있는지 확인합니다.

이 인증 메커니즘은 4단계에서 수행됩니다.

  1. 클라이언트는 로컬 jboss 사용자를 사용하여 인증 요청을 포함하는 메시지를 서버로 전송합니다.
  2. 서버는 일회성 토큰을 생성하여 고유한 파일에 쓰고 전체 파일 경로를 사용하여 클라이언트에 메시지를 전송합니다.
  3. 클라이언트는 파일에서 토큰을 읽고 서버로 전송하여 파일 시스템에 대한 로컬 액세스 권한이 있는지 확인합니다.
  4. 서버에서 토큰을 확인한 다음 파일을 삭제합니다.

이러한 형태의 인증은 파일 시스템에 대한 물리적 액세스를 달성하는 경우 다른 보안 메커니즘이 적용되지 않는다는 원칙을 기반으로 합니다. 이유는 사용자에게 로컬 파일 시스템 액세스 권한이 있는 경우 사용자가 새 사용자를 만들 수 있는 충분한 액세스 권한이 있거나, 그렇지 않으면 다른 보안 메커니즘을 방해하기 때문입니다. 로컬 사용자가 사용자 이름 또는 암호 인증 없이 관리 CLI에 액세스할 수 있으므로 이를 자동 인증이라고 합니다.

이 기능은 편의를 위해 활성화되며 추가 인증 없이도 관리 CLI 스크립트를 실행하는 로컬 사용자를 지원합니다. 로컬 구성에 대한 액세스 권한은 일반적으로 사용자에게 고유한 사용자 세부 정보를 추가하거나 보안 검사를 비활성화하는 기능을 제공한다는 점에서 유용한 기능으로 간주됩니다.

네이티브 인터페이스는 다른 서버 또는 동일한 서버에서도 원격 클라이언트로 액세스할 수 있습니다. 네이티브 인터페이스에 원격 클라이언트로 액세스하는 경우 클라이언트는 로컬 jboss 사용자를 사용하여 인증할 수 없으며, DIGEST와 같은 다른 인증 메커니즘을 사용해야 합니다. 로컬 클라이언트가 로컬 jboss 사용자를 사용하여 인증에 실패하면 자동으로 대체되며 다른 메커니즘을 원격 클라이언트로 사용합니다.

참고

네이티브 인터페이스와 달리 HTTP 인터페이스를 사용하여 다른 서버 또는 동일한 서버에서 관리 CLI를 호출할 수 있습니다. CLI 또는 그 외의 모든 HTTP 연결은 원격로 간주되며 로컬 인터페이스 인증에서 다루지 않습니다.

중요

기본적으로 네이티브 인터페이스는 구성되지 않으며 모든 관리 CLI 트래픽은 HTTP 인터페이스에서 처리합니다. JBoss EAP 7은 HTTP 업그레이드를 지원합니다. 이 경우 클라이언트가 HTTP를 통해 초기 연결을 만들 수 있지만 해당 연결을 다른 프로토콜로 업그레이드하기 위한 요청을 보냅니다. 관리 CLI의 경우 HTTP에 대한 초기 요청이 HTTP 인터페이스에 대한 초기 요청이 생성되지만 연결이 네이티브 프로토콜로 업그레이드됩니다. 이 연결은 여전히 HTTP 인터페이스를 통해 처리되지만 HTTP가 아닌 통신에 네이티브 프로토콜을 사용합니다. 또는 필요한 경우 기본 인터페이스를 활성화하고 사용할 수 있습니다.

2.7.2.2. HTTP 인터페이스를 사용한 로컬 및 원격 클라이언트 인증

HTTP 인터페이스는 실행 중인 JBoss EAP 인스턴스와 동일한 호스트의 클라이언트가 로컬로 호출하거나 다른 시스템의 클라이언트에서 원격으로 호출할 수 있습니다. 로컬 및 원격 클라이언트가 HTTP 인터페이스에 액세스할 수 있도록 허용하지만 HTTP 인터페이스에 액세스하는 모든 클라이언트는 원격 연결로 간주됩니다.

클라이언트가 HTTP 관리 인터페이스에 연결하려고 하면 JBoss EAP는 401 Unauthorized 상태 코드와 지원되는 인증 메커니즘을 나열하는 일련의 헤더(예: Digest, GSSAPI 등)를 사용하여 HTTP 응답을 다시 보냅니다. Digest의 헤더에는 JBoss EAP에서 생성한 nonce도 포함되어 있습니다. 클라이언트는 헤더를 살펴보고 사용할 인증 방법을 선택하고 적절한 응답을 보냅니다. 클라이언트가 Digest를 선택하는 경우 사용자에게 사용자 이름과 암호를 입력하라는 메시지가 표시됩니다. 클라이언트는 사용자 이름 및 암호, nonce 및 기타 몇 가지 정보와 같은 제공된 필드를 사용하여 단방향 해시를 생성합니다. 그런 다음 클라이언트는 단방향 해시, 사용자 이름, nonce를 응답으로 JBoss EAP로 다시 전송합니다. JBoss EAP는 이러한 정보를 가져와서 또 다른 단방향 해시를 생성하고, 이 정보를 비교한 다음 결과를 기반으로 사용자를 인증합니다.

2.7.3. 고급 보안

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

2.7.3.1. 관리 인터페이스 업데이트

인증 및 권한 부여 메커니즘을 수정하는 것 외에도 JBoss EAP를 사용하면 관리자가 관리 인터페이스 자체의 구성을 업데이트할 수 있습니다. 다양한 옵션이 있습니다.

일방향 SSL/TLS를 사용하도록 관리 인터페이스 구성
일방향 SSL/TLS를 사용하는 통신 전용 JBoss EAP 관리 콘솔을 구성하면 향상된 보안이 제공됩니다. 클라이언트와 관리 콘솔 간의 모든 네트워크 트래픽이 암호화되므로 중간자 공격과 같은 보안 공격 위험이 줄어듭니다. JBoss EAP 인스턴스를 관리하는 모든 사용자는 권한이 없는 사용자보다 해당 인스턴스에 대해 더 많은 권한이 있으며 일방향 SSL/TLS를 사용하면 인스턴스의 무결성과 가용성을 보호할 수 있습니다. JBoss EAP를 사용하여 일방향 SSL/TLS를 구성할 때 신뢰할 수 있는 체인을 제공하므로 인증 서명된 인증서가 자체 서명된 인증서보다 선호됩니다. 자체 서명 인증서는 허용되지만 권장되지 않습니다.
양방향 SSL/TLS 사용
클라이언트 인증이라고도 하는 양방향 SSL/TLS 인증은 SSL/TLS 인증서를 사용하여 클라이언트와 서버를 인증합니다. 이렇게 하면 서버가 서버에 있다는 것은 물론 클라이언트가 말하는 내용이기도 합니다.
새 보안 영역 업데이트 또는 생성
기본 보안 영역은 새 보안 영역으로 업데이트하거나 바꿀 수 있습니다.

2.7.3.2. 아웃바운드 연결 추가

일부 보안 영역은 LDAP 서버와 같은 외부 인터페이스에 연결됩니다. 아웃바운드 연결은 이 연결을 만드는 방법을 정의합니다. 사전 정의된 연결 유형인 ldap-connection 은 LDAP 서버에 연결하고 자격 증명을 확인하는 필수 및 선택적 속성을 모두 설정합니다.

2.7.3.3. 관리 인터페이스에 RBAC 추가

기본적으로 RBAC 시스템은 비활성화되어 있습니다. provider 특성을 단순 에서 rbac 로 변경하여 활성화합니다. 이 작업은 관리 CLI를 사용하여 수행할 수 있습니다. 실행 중인 서버에서 RBAC를 비활성화하거나 활성화하면 적용되기 전에 서버 구성을 다시 로드해야 합니다.

관리 인터페이스에 대해 RBAC를 활성화하면 사용자에게 할당된 역할은 액세스 권한이 있는 리소스와 리소스의 특성을 사용하여 수행할 수 있는 작업을 결정합니다. Administrator 또는 SuperUser 역할의 사용자만 액세스 제어 시스템을 보고 변경할 수 있습니다.

주의

사용자와 역할이 올바르게 구성되지 않고 RBAC를 활성화하면 관리자가 관리 인터페이스에 로그인할 수 없습니다.

관리 콘솔에 대한 RBAC의 영향

관리 콘솔에서 일부 제어 및 보기가 비활성화되어 사용자가 할당한 역할의 권한에 따라 회색으로 표시되거나 전혀 표시되지 않습니다.

사용자가 리소스 속성에 대한 읽기 권한이 없는 경우 해당 속성은 콘솔에 비어 있습니다. 예를 들어 대부분의 역할은 데이터 소스의 사용자 이름 및 암호 필드를 읽을 수 없습니다.

사용자에게 읽기 권한이 있지만 리소스 속성에 대한 쓰기 권한이 없는 경우 해당 속성은 리소스의 편집 양식에서 비활성화됩니다. 사용자에게 리소스에 대한 쓰기 권한이 없는 경우 리소스에 대한 편집 버튼이 표시되지 않습니다.

사용자에게 리소스 또는 속성에 액세스할 수 있는 권한이 없습니다. 즉, 해당 역할에 대해 주소 지정이 불가능한 경우 해당 사용자의 콘솔에 표시되지 않습니다. 그 예는 기본적으로 몇 가지 역할에만 표시되는 액세스 제어 시스템 자체입니다.

관리 콘솔은 다음과 같은 일반적인 RBAC 작업에 대한 인터페이스도 제공합니다.

  • 각 사용자에게 할당되거나 제외되는 역할을 보고 구성합니다.
  • 각 그룹에 할당되거나 제외되는 역할을 보고 구성합니다.
  • 역할별로 그룹 및 사용자 멤버십을 확인합니다.
  • 역할당 기본 멤버십을 구성합니다.
  • 범위가 지정된 역할을 생성합니다.
참고

현재 관리 콘솔에서 제한 조건을 구성할 수 없습니다.

관리 CLI 또는 관리 API에서 RBAC의 영향

관리 CLI 또는 관리 API 사용자는 RBAC가 활성화되면 약간 다른 동작이 발생합니다.

읽을 수 없는 리소스 및 속성은 결과에서 필터링됩니다. 필터링된 항목이 역할에서 처리할 수 있는 경우 해당 이름은 결과의 response -headers 섹션에 filtered- attributes 로 나열됩니다. 역할에서 리소스 또는 특성을 처리할 수 없는 경우 나열되지 않습니다.

주소 지정 가능하지 않은 리소스에 액세스하려고 하면 Resource Not Found 오류가 발생합니다.

사용자가 처리할 수 있지만 적절한 쓰기 또는 읽기 권한이 없는 리소스를 작성하거나 읽으려는 경우 Permission Denied 오류가 반환됩니다.

관리 CLI는 관리 콘솔과 동일한 모든 RBAC 작업과 몇 가지 추가 작업을 수행할 수 있습니다.

  • RBAC 활성화 및 비활성화
  • 권한 조합 정책 변경
  • 애플리케이션 리소스 및 리소스 민감도 제한 조건 구성

자카르타 관리 빈에 대한 RBAC의 효과

역할 기반 액세스 제어는 다음 세 가지 방법으로 자카르타 관리에 적용됩니다.

  1. JBoss EAP의 관리 API는 Jakarta Management가 관리하는 빈으로 노출됩니다. 이러한 관리 빈은 코어 mbean이라고 하며 이에 대한 액세스는 기본 관리 API 자체와 정확히 동일하게 제어 및 필터링됩니다.
  2. jmx 하위 시스템은 민감한 쓰기 권한으로 구성됩니다. 즉, AdministratorSuperUser 역할의 사용자만 해당 하위 시스템을 변경할 수 있습니다. 감사자 역할의 사용자는 이 하위 시스템 구성을 읽을 수도 있습니다.
  3. 배포된 애플리케이션 및 서비스 또는 비코어 MBean에서 등록한 빈은 기본적으로 모든 관리 사용자가 액세스할 수 있지만 유지 관리자,Operator, 관리자 SuperUser 역할의 사용자만 쓸 수 있습니다.

RBAC 인증

RBAC는 JBoss EAP에 포함된 표준 인증 공급자와 함께 작동합니다.

사용자 이름/암호
사용자는 로컬 속성 파일 또는 LDAP를 사용할 수 있는 ManagementRealm 의 설정에 따라 확인되는 사용자 이름 및 암호 조합을 사용하여 인증됩니다.
클라이언트 인증서
신뢰 저장소는 클라이언트 인증서에 대한 인증 정보를 제공합니다.
로컬 jboss 사용자
jboss-cli 스크립트는 서버가 동일한 시스템에서 실행 중인 경우 로컬 jboss 사용자로 자동으로 인증됩니다. 기본적으로 로컬 jboss 사용자는 SuperUser 그룹의 멤버입니다.

사용되는 공급업체에 관계없이 JBoss EAP는 사용자에게 역할을 할당합니다. ManagementRealm 또는 LDAP 서버로 인증할 때 해당 시스템은 사용자 그룹 정보를 제공할 수 있습니다. 이 정보는 JBoss EAP에서 사용자에게 역할을 할당하는 데 사용할 수도 있습니다.

2.7.3.4. 관리 인터페이스로 LDAP 사용

JBoss EAP에는 LDAP 서버를 웹 및 Jakarta Enterprise Beans 애플리케이션의 인증 및 권한 부여 권한으로 사용할 수 있는 여러 인증 및 권한 부여 모듈이 포함되어 있습니다.

관리 콘솔, 관리 CLI 또는 관리 API의 인증 소스로 LDAP 디렉터리 서버를 사용하려면 다음 작업을 수행해야 합니다.

  1. LDAP 서버에 대한 아웃바운드 연결을 만듭니다.
  2. LDAP 사용 보안 영역을 생성하거나 LDAP를 사용하도록 기존 보안 영역을 업데이트합니다.
  3. 관리 인터페이스에서 새 보안 영역을 참조합니다.

LDAP 인증자는 먼저 원격 디렉터리 서버에 대한 연결을 설정하여 작동합니다. 그런 다음 사용자가 인증 시스템에 전달한 사용자 이름을 사용하여 LDAP 레코드의 정규화된 고유 이름(DN)을 찾습니다. 사용자의 DN을 사용자가 제공한 자격 증명 및 암호로 사용하여 LDAP 서버에 대한 새 연결을 설정합니다. LDAP 서버에 대한 이 인증이 성공하면 DN이 유효한 것으로 확인됩니다.

LDAP 사용 보안 영역을 만들고 나면 관리 인터페이스에서 참조할 수 있습니다. 관리 인터페이스는 인증에 보안 영역을 사용합니다. 관리 인터페이스 및 관리 CLI에서 인증에 양방향 SSL/TLS를 사용하여 LDAP 서버에 대한 아웃바운드 연결을 사용하도록 JBoss EAP를 구성할 수도 있습니다.

2.7.3.5. 자카르타 인증 및 관리 인터페이스

Jakarta Authentication을 사용하여 관리 인터페이스를 보호할 수 있습니다. 관리 인터페이스에 Jakarta Authentication을 사용하는 경우 보안 도메인을 사용하도록 보안 영역을 구성해야 합니다. 이로 인해 핵심 서비스와 하위 시스템 사이에 종속성이 발생합니다. SSL/TLS는 관리 인터페이스를 보호하기 위해 자카르타 인증을 사용하지 않아도 되지만 관리자는 SSL/TLS를 사용하여 보안되지 않은 방식으로 중요한 정보를 전송하지 않도록 하는 것이 좋습니다.

참고

JBoss EAP 인스턴스가 관리자 전용 모드에서 실행 중인 경우 Jakarta Authentication을 사용하여 관리 인터페이스를 보호하는 것은 지원되지 않습니다. 관리자 전용 모드에 대한 자세한 내용은 JBoss EAP 구성 가이드의 관리 전용 모드에서 JBoss EAP 실행을 참조하십시오.

2.8. 보안 하위 시스템

보안 하위 시스템은 애플리케이션에 대한 보안 인프라를 제공하며 Jakarta Authentication API를 기반으로 합니다. 하위 시스템은 현재 요청과 연결된 보안 컨텍스트를 사용하여 인증 관리자, 권한 부여 관리자, 감사 관리자 및 매핑 관리자의 기능을 관련 컨테이너에 노출합니다.

인증 및 권한 부여 관리자는 인증 및 권한 부여를 처리합니다. 매핑 관리자는 정보를 애플리케이션에 전달하기 전에 주체, 역할 또는 속성에서 정보를 추가, 수정 또는 삭제하는 작업을 처리합니다. 감사 관리자를 사용하면 사용자가 보안 이벤트를 보고하는 방법을 제어하도록 provider 모듈을 구성할 수 있습니다.

대부분의 경우 관리자는 보안 하위 시스템의 구성 업데이트와 관련하여 보안 도메인을 설정하고 구성하는 데만 중점을 두어야 합니다. 보안 도메인 외부에서 변경해야 하는 유일한 보안 요소는 deep-copy-subject-mode 입니다. 자세한 복사 제목 모드에 대한 자세한 내용은 보안 관리 섹션을 참조하십시오.

2.8.1. 보안 도메인

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

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

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

Elytron과 PicketBox 보안 도메인 간 비교

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

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

참고

PicketBox로 작업할 때 보안 도메인은 기본 ID 저장소에 대한 액세스와 권한 부여 결정을 위한 매핑을 모두 캡슐화합니다. 따라서 다양한 저장소를 사용하는 PicketBox 사용자는 서로 다른 소스에 대해 다양한 보안 도메인을 사용해야 합니다.

Elytron에서는 이 두 함수가 분리되어 있습니다. 저장소에 대한 액세스는 보안 영역에서 처리하고 권한 부여를 위한 매핑은 보안 도메인에서 처리합니다.

따라서 독립 PicketBox 보안 도메인이 필요한 배포에서 반드시 독립 Elytron 보안 도메인이 필요하지는 않습니다.

2.8.2. 보안 영역 및 보안 도메인 사용

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

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

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

2.8.3. 보안 감사

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

2.8.4. 보안 매핑

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

2.8.5. 암호 자격 증명 모음 시스템

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

2.8.6. 보안 도메인 구성

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

예제

이러한 유형의 구성 구조로 이점을 얻는 일반적인 시나리오 중 하나는 테스트 및 생산 환경 간에 애플리케이션을 이동하는 프로세스입니다. 애플리케이션에 개별적으로 보안이 구성된 경우(예: 테스트 환경에서 프로덕션 환경으로 승격) 새 환경으로 승격할 때마다 업데이트해야 할 수 있습니다. 해당 애플리케이션이 보안 도메인을 사용하는 경우 개별 환경의 JBoss EAP 인스턴스에 현재 환경에 맞게 올바르게 구성된 보안 도메인이 있어 애플리케이션이 보안 도메인을 사용하여 컨테이너에서 적절한 보안 구성을 제공할 수 있습니다.

2.8.6.1. 로그인 모듈

JBoss EAP에는 보안 도메인 내에 구성된 대부분의 사용자 관리 역할에 적합한 여러 개의 번들 로그인 모듈이 포함되어 있습니다. 보안 하위 시스템은 관계형 데이터베이스, LDAP 서버 또는 플랫 파일에서 사용자 정보를 읽을 수 있는 몇 가지 핵심 로그인 모듈을 제공합니다. 이러한 핵심 로그인 모듈 외에도 JBoss EAP는 사용자 지정 요구에 대한 사용자 정보와 기능을 제공하는 다른 로그인 모듈을 제공합니다.

일반적으로 사용되는 로그인 모듈 요약

LDAP 로그인 모듈
Ldap 로그인 모듈은 LDAP 서버에 대해 인증하는 로그인 모듈 구현입니다. 보안 하위 시스템은 Java Naming 및 Directory Interface 초기 컨텍스트를 사용하여 제공하는 사용자 및 역할에 대해 baseCtxDNrolesCtxDN 트리를 검색할 권한이 있는 bind DN인 연결 정보를 사용하여 LDAP 서버에 연결합니다. 사용자가 인증을 시도하면 LDAP 로그인 모듈이 LDAP 서버에 연결하고 사용자의 자격 증명을 LDAP 서버에 전달합니다. 인증에 성공하면 사용자의 역할로 채워진 JBoss EAP 내에 해당 사용자에 대해 InitialLDAPContext 가 생성됩니다.
LdapExtended 로그인 모듈
LdapExtended 로그인 모듈은 사용자와 인증에 바인딩할 관련 역할을 검색합니다. 역할 쿼리를 재귀적으로 지정하고 DN에 따라 계층적 역할 구조를 탐색합니다. 로그인 모듈 옵션에는 선택한 LDAP Java Naming 및 Directory Interface 공급자에서 지원하는 모든 옵션이 포함됩니다.
UsersRoles 로그인 모듈
UsersRoles 로그인 모듈은 Java 속성 파일에서 로드된 여러 사용자 및 사용자 역할을 지원하는 간단한 로그인 모듈입니다. 이 로그인 모듈의 주요 목적은 애플리케이션과 함께 배포된 속성 파일을 사용하여 여러 사용자와 역할의 보안 설정을 쉽게 테스트하는 것입니다.
데이터베이스 로그인 모듈
Database 로그인 모듈은 인증 및 역할 매핑을 지원하는 JDBC 로그인 모듈입니다. 이 로그인 모듈은 사용자 이름, 암호 및 역할 정보가 관계형 데이터베이스에 저장된 경우 사용됩니다. 이는 예상되는 형식의 주체 및 역할을 포함하는 논리 테이블에 대한 참조를 제공하여 작동합니다.
인증서 로그인 모듈
인증서 로그인 모듈은 X509 인증서를 기반으로 사용자를 인증합니다. 이 로그인 모듈의 일반적인 사용 사례는 웹 계층의 CLIENT-CERT 인증입니다. 이 로그인 모듈은 인증만 수행하고 보안 웹 또는 Jakarta Enterprise Beans 구성 요소에 대한 액세스를 완전히 정의하기 위해 권한 부여 역할을 획득할 수 있는 다른 로그인 모듈과 결합되어야 합니다. 이 로그인 모듈의 두 하위 클래스인 CertRolesLoginModule 및 DatabaseCertLoginModule 은 속성 파일 또는 데이터베이스에서 권한 부여 역할을 가져오도록 동작을 확장합니다.
ID 로그인 모듈
ID 로그인 모듈은 하드 코딩된 사용자 이름을 모듈에 대해 인증된 모든 주체에 연결하는 간단한 로그인 모듈입니다. 주체 옵션으로 지정한 이름을 사용하여 SimplePrincipal 인스턴스를 만듭니다. 이 로그인 모듈은 서비스에 고정 ID를 제공해야 하는 경우에 유용합니다. 이는 지정된 주체 및 관련 역할과 연결된 보안을 테스트하는 데 개발 환경에서도 사용할 수 있습니다.
RunAs 로그인 모듈
RunAs 로그인 모듈은 인증 기간 동안 run-as 역할을 스택에 푸시하는 도우미 모듈입니다. 그런 다음 스택에서 run-as 역할을 커밋 또는 중단 단계에서 시작합니다. 이 로그인 모듈의 목적은 인증을 수행하기 위해 보안 리소스에 액세스해야 하는 다른 로그인 모듈에 대한 역할을 제공하는 것입니다(예: 보안 Jakarta Enterprise Bean에 액세스하는 로그인 모듈). 설정된 역할로 실행해야 하는 로그인 모듈보다 RunAs 로그인 모듈을 구성해야 합니다.
클라이언트 로그인 모듈
Client 로그인 모듈은 호출자 ID 및 자격 증명을 설정할 때 JBoss 클라이언트에서 사용할 로그인 모듈 구현입니다. 이렇게 하면 새 SecurityContext 가 생성되고 주체 및 자격 증명을 할당하며 SecurityContextThreadLocal 보안 컨텍스트로 설정합니다. 클라이언트 로그인 모듈은 현재 스레드의 호출자를 설정하기 위해 클라이언트가 지원되는 유일한 메커니즘입니다. 독립 실행형 클라이언트 애플리케이션과 서버 환경 모두 보안 환경이 JBoss EAP 보안 하위 시스템을 투명하게 사용하도록 구성되지 않은 JBoss Jakarta Enterprise Beans 클라이언트 역할을 하며 클라이언트 로그인 모듈을 사용해야 합니다.
주의

이 로그인 모듈은 인증을 수행하지 않습니다. 서버에서 후속 인증을 위해 제공된 로그인 정보만 서버 Jakarta Enterprise Beans 호출 계층에 복사합니다. JBoss EAP 내에서 이는 in-JVM 호출의 사용자 ID를 전환하는 경우에만 지원됩니다. 원격 클라이언트가 ID를 설정하는 데 지원되지 않습니다.

SPNEGO 로그인 모듈
SPNEGO 로그인 모듈은 KDC를 사용하여 호출자 ID 및 자격 증명을 설정하는 로그인 모듈 구현입니다. 이 모듈은 SPNEGO를 구현하며 JBoss 협상 프로젝트의 일부입니다. 이 인증은 LDAP 서버와의 협력을 허용하기 위해 AdvancedLdap 로그인 모듈과 체인된 구성에서 사용할 수 있습니다. 이 로그인 모듈을 사용하려면 웹 애플리케이션에서 NegotiationAuthenticator 도 활성화해야 합니다.
RoleMapping 로그인 모듈
RoleMapping 로그인 모듈은 인증 프로세스의 최종 결과인 역할을 하나 이상의 선언적 역할에 매핑하는 기능을 지원합니다. 예를 들어 인증 프로세스가 John에게 ldapAdmin 및 testAdmin 역할이 있고, 액세스를 위해 web.xml 또는 ejb-jar.xml 파일에 정의된 선언적 역할이 admin 인 경우, 이 로그인 모듈은 ldapAdmin 및 testAdmin 역할을 John에 매핑합니다. RoleMapping 로그인 모듈은 이전에 매핑된 역할의 매핑을 변경할 때 로그인 모듈 구성에 선택적 모듈로 정의해야 합니다.
로그인 모듈 원격화
Remoting login 모듈은 현재 인증되고 있는 요청이 원격 연결을 통해 수신되었는지 확인합니다. 원격 인터페이스를 사용하여 요청이 수신된 경우 해당 요청은 인증 프로세스 중에 생성된 ID와 연결됩니다.
RealmDirect 로그인 모듈
RealmDirect 로그인 모듈을 사용하면 기존 보안 영역을 인증 및 권한 결정에 사용할 수 있습니다. 이 모듈에서는 인증 결정을 내리고 사용자 역할을 매핑하기 위해 참조된 영역을 사용하여 ID 정보를 조회합니다. 예를 들어 JBoss EAP와 함께 제공되는 사전 구성된 기타 보안 도메인에는 RealmDirect 로그인 모듈이 있습니다. 이 모듈에서 영역을 참조하지 않으면 기본적으로 ApplicationRealm 보안 영역이 사용됩니다.
사용자 지정 모듈
JBoss EAP 보안 프레임워크와 함께 번들된 로그인 모듈이 보안 환경의 요구 사항을 충족하지 못하는 경우 사용자 지정 로그인 모듈 구현이 작성될 수 있습니다. AuthenticationManager에는 주체 주체 집합의 특정 사용 패턴이 필요합니다. Jakarta Authentication Subject 클래스의 정보 스토리지 기능과 이러한 기능을 사용하여 AuthenticationManager와 호환되는 로그인 모듈을 작성하려면 필요한 기능을 완벽하게 이해해야 합니다.

인증되지 않은Identity 로그인 모듈 옵션도 일반적으로 사용됩니다. 요청이 인증된 형식으로 수신되지 않는 경우도 있습니다. 인증되지 않은 ID는 관련된 인증 정보가 없는 요청에 특정 ID(예: 게스트 )를 할당하는 로그인 모듈 구성 옵션입니다. 이를 통해 보호되지 않은 서블릿이 특정 역할이 필요하지 않은 Jakarta Enterprise Beans에서 메서드를 호출할 수 있습니다. 이러한 주체는 관련 역할이 없으며 선택되지 않은 권한 제한 조건과 연결된 보안되지 않은 Jakarta Enterprise Beans 메서드에만 액세스할 수 있습니다.

2.8.6.2. 암호 스택

인증 중에 자격 증명 확인 및 역할 할당을 제공하는 각 로그인 모듈에서 여러 로그인 모듈을 함께 스택에 연결할 수 있습니다. 이는 많은 사용 사례에서 작동하지만, 자격 증명 확인 및 역할 할당이 여러 사용자 관리 저장소로 분할되는 경우도 있습니다.

사용자가 중앙 LDAP 서버에서 관리되고 애플리케이션별 역할이 애플리케이션의 관계형 데이터베이스에 저장되는 경우를 고려하십시오. password-stacking 모듈 옵션은 이 관계를 캡처합니다.

암호 스태킹을 사용하려면 각 로그인 모듈에서 <module -option> 섹션에 있는 FirstPass를 사용하도록 password- stacking 특성을 설정해야 합니다. 암호 스택에 대해 구성된 이전 모듈이 사용자를 인증한 경우 다른 모든 stacking 모듈은 사용자를 인증된 것으로 간주하고 권한 부여 단계에 대한 역할 집합을 제공하려는 경우에만 시도합니다.

password-stacking 옵션이 useFirstPass 로 설정된 경우 이 모듈은 먼저 로그인 모듈 공유 상태 맵에서 javax.security.auth.login.namejavax.security.auth.login.password 속성 이름으로 공유 사용자 이름과 암호를 찾습니다.

발견되면 이러한 속성이 주체 이름과 암호로 사용됩니다. 찾을 수 없는 경우 이 로그인 모듈에서 주체 이름과 암호를 설정하고 속성 이름 javax.security.auth.login.name 및 javax. security.auth.login.password 에 각각 저장됩니다.

2.8.6.3. 암호 해싱

대부분의 로그인 모듈은 클라이언트가 제공한 암호를 사용자 관리 시스템에 저장된 암호와 비교해야 합니다. 이러한 모듈은 일반적으로 일반 텍스트 암호로 작동하지만 일반 텍스트 암호가 서버 측에 저장되지 않도록 해시된 암호를 지원하도록 구성할 수 있습니다. JBoss EAP는 해싱 알고리즘, 인코딩 및 문자 집합을 구성하는 기능을 지원합니다. 또한 사용자 암호 및 저장 암호가 해시되는 시기를 정의합니다.

중요

Red Hat JBoss Enterprise Application Platform Common Criteria 인증 구성은 SHA-256보다 약한 해시 알고리즘을 지원하지 않습니다.

2.8.7. 보안 관리

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

2.8.7.1. 깊은 복사 모드

기본적으로 심층 복사 제목 모드가 비활성화된 경우 보안 데이터 구조를 복사하면 전체 데이터 구조를 복사하는 대신 원본에 대한 참조가 됩니다. 이 동작은 더 효율적이지만 플러시 또는 로그아웃 작업을 통해 동일한 ID가 있는 여러 스레드가 주체를 지우는 경우 데이터 손상이 발생할 수 있습니다.

심층 복사 제목 모드가 활성화되면 데이터 구조의 전체 사본과 연결된 모든 데이터가 복제 가능으로 표시될 수 있습니다. 이 방법은 스레드 보안이 향상되지만 효율성이 떨어집니다.

2.8.8. 추가 구성 요소

2.8.8.1. 자카르타 인증

Jakarta Authentication은 Java 애플리케이션을 위한 플러그형 인터페이스이며 Jakarta Authentication 사양에 정의되어 있습니다. Jakarta Authentication 인증 외에도 JBoss EAP를 사용하면 Jakarta Authentication을 사용할 수 있습니다. Jakarta 인증 인증은 보안 도메인에서 로그인 모듈을 사용하여 구성되며 이러한 모듈이 스택될 수 있습니다. jaspitest 보안 도메인은 개발 목적으로 기본적으로 포함된 간단한 Jakarta Authentication 보안 도메인입니다.

웹 기반 관리 콘솔은 Jakarta 인증 모듈을 구성하기 위한 다음 작업을 제공합니다.

  • add
  • edit
  • 제거
  • reset

JBoss EAP에 배포된 애플리케이션에는 Jakarta Authentication 보안 도메인을 사용하도록 배포 설명자에 특수 인증기를 구성해야 합니다.

2.8.8.2. 자카르타 인증

Jakarta Authorization은 컨테이너와 권한 부여 서비스 공급자 간의 계약을 정의하는 표준으로, 컨테이너에서 사용할 공급자를 구현합니다. 사양에 대한 자세한 내용은 Jakarta Authorization 1.1 Specification 을 참조하십시오.

JBoss EAP는 보안 하위 시스템의 보안 기능 내에서 Jakarta Authorization에 대한 지원을 구현합니다.

2.8.8.3. 자카르타 보안

Jakarta Security는 인증 및 ID 저장소를 위한 이식 가능한 플러그인 인터페이스와 프로그래밍 방식의 보안에 대한 액세스 지점을 제공하는 새로운 주입형 SecurityContext 인터페이스를 정의합니다. 이러한 API의 기본 제공 구현을 사용하거나 사용자 지정 구현을 정의할 수 있습니다. 사양에 대한 자세한 내용은 Jakarta Security Specification 을 참조하십시오.

Jakarta Security API는 elytron 하위 시스템에서 사용할 수 있으며 관리 CLI에서 활성화할 수 있습니다. 자세한 내용은 개발 가이드의 자카르타 보안 API 정보를 참조하십시오.

2.8.8.4. system-grained Authorization 및 XACML 정보

관리자가 모듈 액세스 권한을 부여하는 의사 결정 프로세스와 관련된 여러 변수와 변화하는 요구 사항에 맞게 세분화된 권한을 조정할 수 있습니다. 따라서 세분화된 권한 부여가 복잡해질 수 있습니다.

참고

웹 또는 Jakarta Enterprise Bean의 XACML 바인딩은 JBoss EAP에서 지원되지 않습니다.

JBoss EAP는 XACML을 매체로 사용하여 세분화된 권한 부여를 달성합니다. XACML은 세밀한 인증을 획득하는 복잡한 특성에 표준 기반 솔루션을 제공합니다. XACML은 정책 언어와 의사 결정을 위한 아키텍처를 정의합니다. XACML 아키텍처에는 일반 프로그램 흐름에서 요청을 가로채고 PDP(Policy Decision Point)를 요청하는 PEP(Policy Enforcement Point)가 포함되어 있습니다. PDP는 PEP에서 생성한 XACML 요청을 평가하고 정책을 통해 실행되어 다음 액세스 결정 중 하나를 수행합니다.

허용
액세스가 승인되었습니다.
거부
액세스가 거부됩니다.
INDETERMINATE
PDP에 오류가 있습니다.
NOAPPLICABLE
요청에 누락된 속성이 있거나 정책 일치 항목이 없습니다.

XACML에는 다음과 같은 기능이 있습니다.

  • XACML v2.0 라이브러리
  • JAXB v2.0 기반 개체 모델
  • XACML 정책 및 속성 저장 및 검색을 위한 ExistDB 통합

2.8.8.5. SSO

JBoss EAP는 undertowinfinispan 하위 시스템을 사용하여 클러스터형 SSO와 비클러스터형 SSO에 대한 기본 지원을 제공합니다. 여기에는 다음이 필요합니다.

  • 인증 및 권한 부여를 처리하는 구성된 보안 도메인입니다.
  • SSO infinispan 복제 캐시. 관리형 도메인의 hafull-ha 프로필에 있거나 독립 실행형 서버에는 standalone-ha.xml 또는 standalone-full-ha.xml 구성 파일을 사용하여 존재합니다.
  • cache-container 및 SSO 복제 캐시가 있어야 합니다.
  • The undertow 하위 시스템은 SSO를 사용하도록 구성해야 합니다.
  • SSO 정보를 공유할 각 애플리케이션은 동일한 보안 도메인을 사용하도록 구성해야 합니다.

3장. Red Hat JBoss Enterprise Application Platform을 사용한 SSO의 추가 사용 사례

기본 제공 기능 외에도 JBoss EAP는 안전한 토큰 서비스를 통해 브라우저 기반 SSO, 데스크탑 기반 SSO, SSO를 포함한 SSO를 위한 추가 사용 사례를 지원합니다.

3.1. SAML을 사용하는 브라우저 기반 SSO

브라우저 기반 SSO 시나리오에서는 서비스 프로바이더라고 하는 하나 이상의 웹 애플리케이션이 허브 및 스포크 아키텍처의 중앙 집중식 ID 프로바이더에 연결됩니다. ID 공급자(IDP)는 모든 서비스 프로바이더 또는 대화 상자의 ID 및 역할 정보에 대한 중앙 소스 또는 허브 역할을 합니다. 인증되지 않은 사용자가 서비스 프로바이더 중 하나에 액세스하려고 하면 해당 사용자가 IDP로 리디렉션되어 인증을 수행합니다. IDP는 사용자를 인증하고 주체 역할을 지정하는 SAML 토큰을 발행한 다음 요청된 서비스 프로바이더로 리디렉션합니다. 여기에서 SAML 토큰은 연결된 모든 서비스 프로바이더에서 사용자의 ID 및 액세스를 결정하는 데 사용됩니다. 서비스 프로바이더에서 시작하는 SSO를 사용하는 이 특정 방법을 서비스 프로바이더 시작 flow라고 합니다.

여러 SSO 시스템과 마찬가지로 JBoss EAP는 IDP 및 SP를 사용합니다. 두 구성 요소는 모두 JBoss EAP 인스턴스 내에서 실행되고 JBoss EAP 보안 하위 시스템과 함께 작동합니다. SAML v2, FORM 기반 웹 애플리케이션 보안 및 HTTP/POST 및 HTTP/Redirect 바인딩도 SSO를 구현하는 데 사용됩니다.

ID 프로바이더를 생성하려면 인증 및 권한 부여 메커니즘을 정의하는 JBoss EAP 인스턴스(예: LDAP 또는 데이터베이스) 에서 ID 저장소 역할을 할 보안 도메인을 생성합니다. 웹 애플리케이션(예: IDP.war )은 IDP를 idp-domain 과 함께 실행하는 데 필요한 추가 모듈인 org.picketlink 를 사용하도록 구성되어 있으며 동일한 JBoss EAP 인스턴스에 배포됩니다. IDP.war는 ID 공급자 역할을 합니다. 서비스 프로바이더를 생성하기 위해 SAML2LoginModule 을 인증 메커니즘으로 사용하는 sp-domain 과 같은 보안 도메인이 생성됩니다. 웹 애플리케이션(예: SP.war )은 추가 모듈인 org.picketlink 를 사용하도록 구성되었으며 sp-domain 을 사용하는 서비스 프로바이더가 포함됩니다. s.warsp-domain 이 구성되어 있고 이제 서비스 프로바이더인 JBoss EAP 인스턴스에 배포됩니다. 하나 이상의 SP(예: SP 2.war,SP3.war 등)에 대해 이 프로세스를 하나 이상의 JBoss EAP 인스턴스에 복제할 수 있습니다.

3.1.1. ID 공급자 시작 워크플로우

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

워크스루

  1. 사용자가 IDP에 액세스합니다.
  2. IDP는 SAML 요청이나 응답이 없는 것을 확인하면 SAML을 사용하여 IDP 시작 흐름 시나리오가 있다고 가정합니다.
  3. IDP는 사용자가 인증해야 합니다.
  4. 인증 시 IDP에는 사용자가 모든 SP 애플리케이션에 연결되는 페이지를 가져오는 호스팅된 섹션이 표시됩니다.
  5. 사용자는 SP 애플리케이션을 선택합니다.
  6. IDP는 쿼리 매개 변수 SAML 응답에서 SAML 어설션을 사용하여 사용자를 SP로 리디렉션합니다.
  7. SP는 SAML 어설션을 확인하고 액세스를 제공합니다.

3.1.2. 글로벌 로그아웃

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

3.2. 데스크탑 기반 SSO

데스크탑 기반 SSO 시나리오를 사용하면 일반적으로 데스크탑 전반에서 주체를 공유하고 Active Directory 또는 Kerberos 서버에서 관리하는 주체와 SP인 웹 애플리케이션 집합을 공유할 수 있습니다. 이 경우 데스크탑 IDP는 웹 애플리케이션의 IDP 역할을 합니다.

일반적인 설정에서 사용자는 Active Directory 도메인에 의해 관리되는 데스크탑에 로그인합니다. 사용자는 JBoss 협상으로 구성되고 JBoss EAP에 호스팅된 웹 브라우저를 통해 웹 애플리케이션에 액세스합니다. 웹 브라우저는 사용자의 로컬 시스템에서 웹 애플리케이션으로 로그인 정보를 전송합니다. JBoss EAP는 Active Directory 또는 Kerberos Server와 함께 백그라운드 GSS 메시지를 사용하여 사용자를 검증합니다. 이를 통해 사용자는 웹 애플리케이션으로 원활하게 SSO를 수행할 수 있습니다.

웹 애플리케이션의 IDP로 데스크탑 기반 SSO를 설정하려면 IDP 서버에 연결하는 보안 도메인이 생성됩니다. NegotiationAuthenticator가 원하는 웹 애플리케이션에 기본적으로 추가되고, JBoss Negotiation이 SP 컨테이너의 클래스 경로에 추가됩니다. 또는 IDP를 브라우저 기반 SSO 시나리오와 유사하게 설정할 수 있지만 데스크탑 기반 SSO 공급자를 ID 저장소로 사용할 수 있습니다.

3.3. STS를 사용하는 SSO

JBoss EAP는 SP가 STS에 연결할 수 있는 여러 가지 로그인 모듈을 제공합니다. STS(PicketLinkSTS)도 실행할 수 있습니다. 보다 구체적으로, PicketLinkSTS 는 다른 보안 토큰 서비스에 대한 여러 인터페이스를 정의하고 확장 지점을 제공합니다. 구현은 구성을 사용하여 연결할 수 있으며 구성을 통해 일부 속성에 대해 기본값을 지정할 수 있습니다. 즉, PicketLinkSTS 는 보안 토큰을 생성하고 관리하지만 특정 유형의 토큰을 발행하지 않습니다. 대신 여러 토큰 프로바이더를 연결할 수 있는 일반 인터페이스를 정의합니다. 따라서 각 토큰 유형에 대한 토큰 프로바이더가 존재하는 한 다양한 유형의 토큰을 처리하도록 구성할 수 있습니다. 또한 보안 토큰 요청 및 응답 메시지의 형식을 지정합니다.

다음 단계는 JBoss EAP STS를 사용할 때 보안 토큰 요청을 처리하는 순서입니다.

  1. 클라이언트가 PicketLinkSTS 로 보안 토큰 요청을 보냅니다.
  2. PicketLinkSTS 는 요청 메시지를 구문 분석하고 자카르타 XML 바인딩 개체 모델을 생성합니다.
  3. PicketLinkSTS 는 구성 파일을 읽고 필요한 경우 STSConfiguration 개체를 만듭니다. 구성에서 WSTrustRequestHandler 에 대한 참조를 가져오고 요청 처리를 핸들러 인스턴스에 위임합니다.
  4. 요청 핸들러는 STSConfiguration 을 사용하여 필요할 때 기본값을 설정합니다(예: 토큰 수명 값을 지정하지 않는 경우).
  5. WSTrustRequestHandlerWSTrustRequestContext 를 생성하고 Jakarta XML 바인딩 요청 오브젝트와 PicketLinkSTS 에서 수신한 호출자 주체를 설정합니다.
  6. WSTrustRequestHandlerSTSConfiguration 을 사용하여 요청 중인 토큰 유형에 따라 요청을 처리하는 데 사용해야 하는 SecurityTokenProvider 를 가져옵니다. 프로바이더를 호출하고 구성된 WSTrustRequestContext 를 매개 변수로 전달합니다.
  7. SecurityTokenProvider 인스턴스는 토큰 요청을 처리하고 발급한 토큰을 요청 컨텍스트에 저장합니다.
  8. WSTrustRequestHandler 는 컨텍스트에서 토큰을 가져와 필요한 경우 암호화하고 보안 토큰을 포함하는 WS-Trust 응답 개체를 구성합니다.
  9. PicketLinkSTS 는 요청 핸들러에서 생성한 응답을 지정하여 클라이언트로 반환합니다.

STS 로그인 모듈(예: STSIssuingLoginModule, STSValidatingLoginModule, SAML2STSLoginModule 등)은 일반적으로 사용자 인증을 위해 STS를 사용하도록 JEE 컨테이너의 보안 설정의 일부로 구성됩니다. STS는 로그인 모듈과 동일한 컨테이너에 배치되거나 웹 서비스 호출 또는 다른 기술을 통해 원격으로 액세스할 수 있습니다.

4장. Elytron 하위 시스템 예제 시나리오

4.1. 바로 상자에서

기본적으로 JBoss EAP는 사전 구성된 다음 구성 요소를 제공합니다.

ApplicationDomain
ApplicationDomain 보안 도메인은 인증을 위해 ApplicationRealmgroups-to-roles 를 사용합니다. 또한 default-permission-mapper 를 사용하여 로그인 권한을 할당합니다.
ApplicationRealm
The ApplicationRealm 보안 영역은 application-users.properties를 사용하여 주체를 인증하고 application-roles.properties 를 사용하여 역할을 할당하는 속성 영역입니다. 이러한 파일은 기본적으로 EAP_HOME/standalone/configuration 에 매핑되는 jboss.server.config.dir 에 있습니다. 또한 레거시 보안 기본 구성에서 사용하는 파일과도 같습니다.
application-http-authentication
application-http-authentication http-authentication-factory는 HTTP를 통한 인증을 수행하는 데 사용할 수 있습니다. 글로벌 provider-http-server-mechanism-factory를 사용하여 인증 메커니즘을 필터링하고 주체를 인증하기 위해 ApplicationDomain 을 사용합니다. BASICFORM 인증 메커니즘을 허용하고 BASIC애플리케이션 Realm 으로 애플리케이션에 노출합니다.
application-sasl-authentication
application-sasl-authentication sasl-authentication-factory는 SASL을 사용한 인증에 사용할 수 있습니다. 구성된 sasl-server-factory를 사용하여 글로벌 provider-sasl-server-factory를 사용하여 공급자 이름별로 필터링하는 인증 메커니즘을 필터링합니다. application-sasl-authentication 은 주체 인증을 위해 ApplicationDomain 보안 도메인을 사용합니다.
구성(configurable-sasl-server-factory)
이는 메커니즘 이름을 기반으로 filterasl-authentication-factory 를 사용하는 데 사용됩니다. 이 경우 구성된JBOSS-LOCAL-USER 및 DIGEST- MD5 에서 일치합니다. 또한 wildfly.sasl.local-user.default-user$local 로 설정합니다.
default-permission-mapper

default-permission-mapperdefault-permissions 권한을 사용하여 서버의 서비스에 액세스하는 데 필요한 전체 권한 세트를 할당하는 간단한 권한 매퍼입니다.

예를 들어 default-permission-mapper 는 배치 작업에 대한 권한을 할당하도록 설정된 default-permissions 권한에서 지정하는 org.wildfly.extension.batch.deployment.BatchPermission s 권한을 사용합니다. 배치 권한은 javax.batch.operations.JobOperator와 일치하는 start, stop, restart, quit 및 read입니다.

default-permission-mapper 는 로그인 권한을 할당하도록 설정된 로그인 권한으로 지정된 org.wildfly.security.auth.permission.LoginPermission 도 사용합니다.

Elytron (mechanism-provider-filtering-sasl-server-factor)
이 매개 변수는 공급업체를 기반으로 사용되는 I sasl-authentication-factory 를 필터링하는 데 사용됩니다. 이 경우 elytronWildFlyElytron 공급업체 이름에 일치합니다.
global (provider-http-server-mechanism-factory)
HTTP 인증 팩토리를 만들 때 지원되는 인증 메커니즘을 나열하는 데 사용되는 HTTP 서버 팩토리 메커니즘 정의입니다.
글로벌(provider-sasl-server-factory)
이것은 SASL 인증 팩토리를 만드는 데 사용되는 SASL 서버 팩토리 정의입니다.
groups-to-roles
groups-to-roles 매퍼는 주체의 그룹 정보를 디코딩하고 역할 정보에 사용하는 간단한 역할 -디코더입니다.
로컬 (매퍼)
로컬 매퍼는 로컬 보안 영역에 매핑되는 상수 역할 매퍼입니다. 이는 인증을 로컬 보안 영역에 매핑하는 데 사용됩니다.
로컬 (보안 영역)
로컬 보안 영역은 인증을 수행하지 않으며 주체 ID를 $local 로 설정합니다.
ManagementDomain
ManagementDomain 보안 도메인은 인증을 위해 두 개의 보안 영역을 사용합니다. groups-to-roles 및 super- user-mapper 를 사용하여 local 이 있는 ManagementRealm. 또한 default-permission-mapper 를 사용하여 로그인 권한을 할당합니다.
ManagementRealm
ManagementRealm 보안 영역은 mgmt-users.properties를 사용하여 주체를 인증하고 mgmt-roles.properties 를 사용하여 역할을 할당하는 properties 영역입니다. 이러한 파일은 기본적으로 EAP_HOME/standalone/configuration 에 매핑되는 jboss.server.config.dir 에 있습니다. 또한 레거시 보안 기본 구성에서 사용하는 파일과도 같습니다.
management-http-authentication
management-http-authentication http-authentication-factory는 HTTP를 통한 인증을 수행하는 데 사용할 수 있습니다. 글로벌 provider-http-server-mechanism-factory를 사용하여 인증 메커니즘을 필터링하고 원칙을 인증하는 데 ManagementDomain 을 사용합니다. DIGEST 인증 메커니즘을 수락하고 애플리케이션에 ManagementRealm 으로 노출합니다.
management-sasl-authentication
management-sasl-authentication sasl-authentication-factory는 SASL을 사용한 인증에 사용할 수 있습니다. 구성된 sasl-server-factory를 사용하여 인증 메커니즘을 필터링합니다. 이 메커니즘은 글로벌 provider-sasl-server-factory를 사용하여 공급자 이름으로 필터링합니다. management-sasl-authentication 은 주체 인증을 위해 ManagementDomain 보안 도메인을 사용합니다. 또한 DIGEST -MD5를 사용하여 로컬 영역 매퍼 및 인증을 사용하여 JBOSS-LOCAL- USER 메커니즘을 사용하여 인증을 매핑합니다.
super-user-mapper
super-user-mapper 매퍼는 SuperUser 역할을 주체에 매핑하는 상수 역할 매퍼입니다.

4.1.1. 보안

애플리케이션 보안을 위해 JBoss EAP는 HTTP 및 SASL 사용에 대한 application-http -authentication 으로 사전 구성됩니다. application-http-authentication http-authentication-factory는 인증을 위해 ApplicationRealmgroups-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는 인증에 ManagementRealmgroups-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 을 사용합니다.

4.1.2. 작동 방식

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

표 4.1. 사용자

사용자 이름암호역할보안 영역

수전

Testing123!

 

ManagementRealm

Sarah

Testing123!

샘플

ApplicationRealm

임페어

Testing123!

 

ApplicationRealm

시작 시 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 보안 영역에 없습니다.

4.2. SSL/TLS를 사용하여 관리 인터페이스 및 애플리케이션 보호

이 시나리오에서는 관리 인터페이스 및 애플리케이션과 함께 SSL/TLS에 Elytron을 사용할 때 JBoss EAP를 보호하는 방법을 보여줍니다.

4.2.1. 보안

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-listenerserver-ssl-context 를 할당하여 애플리케이션에 대해 SSL/TLS가 활성화됩니다. SSL/TLS에 대한 자세한 내용은 고급 보안 섹션을 참조하십시오.

4.2.2. 작동 방식

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

4.3. 새 ID 저장소로 관리 인터페이스 및 애플리케이션 보안

이 시나리오는 Elytron의 새 ID 저장소로 JBoss EAP의 관리 인터페이스와 애플리케이션을 보호하는 방법을 보여줍니다. sampleApp2.war 애플리케이션은 JBoss EAP에 배포되며 basicExampleDomain 을 사용하도록 구성됩니다.

4.3.1. 보안

JBoss EAP는 관리 인터페이스와 ManagementRealmApplicationRealm 이외의 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.warBASIC 인증과 함께 basicExampleDomain 을 사용하도록 구성되어 있습니다.

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

4.3.2. 작동 방식

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

표 4.2. 예제Realm 사용자

사용자 이름암호역할

Vincent

samplePass

샘플

Issac

samplePass

게스트

시작 시 JBoss EAP는 핵심 서비스를 로드하고 undertowelytron 하위 시스템을 시작합니다. 이는 관리 인터페이스를 보호하고 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 에 액세스할 수 없습니다.

4.4. RBAC를 사용하여 관리 인터페이스 보호

이 시나리오에서는 JBoss EAP 관리 인터페이스가 RBAC 및 ID 저장소로 elytron 하위 시스템에서 보안되는 방법을 보여줍니다.

4.4.1. 보안

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

4.4.2. 작동 방식

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

표 4.3. 예제Realm 사용자

사용자 이름암호

Suzy

Testing123!

Tim

Testing123!

Emily

Testing123!

Zach

Testing123!

Natalie

Testing123!

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

표 4.4. RBAC 역할

사용자 이름RBAC 역할

Suzy

수퍼유저

Tim

관리자

Emily

유지 관리자

Zach

deployer

Natalie

모니터

시작 시 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 추가 섹션을 참조하십시오.

4.5. Kerberos를 사용하여 웹 애플리케이션에 SSO 제공

이 시나리오에서는 Kerberos를 JBoss EAP와 함께 사용하여 웹 애플리케이션에 SSO를 제공하는 방법을 보여줍니다. JBoss EAP 인스턴스는 생성되었으며 독립 실행형 서버로 실행되고 있습니다. 두 개의 웹 애플리케이션( sampleAppAsampleAppB )이 EAP1 에 배포되었습니다. 웹 애플리케이션과 EAP1 은 모두 Kerberos가 있는 데스크탑 기반 SSO를 사용하여 인증하도록 구성되었습니다.

4.5.1. 보안

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 를 사용하도록 구성됩니다.

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

4.5.2. 작동 방식

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

표 4.5. Kerberos 사용자

사용자 이름암호

Sande

samplePass

Andrea

samplePass

Betty

samplePass

Chuck

samplePass

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

표 4.6. 사용자 역할

사용자 이름역할

Sande

모두

Andrea

A

Betty

B

Chuck

 

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

표 4.7. 애플리케이션 역할

애플리케이션/SP허용된 역할

sampleAppA

모두, A

sampleAppB

all, B

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

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 로그인 페이지로 대체로 이동합니다. 그런 다음 대체 인증 메커니즘을 사용하여 자격 증명이 인증되고 프로세스는 권한 부여를 계속합니다.

5장. 레거시 코어 관리 및 보안 하위 시스템 예제 시나리오

JBoss EAP 보안과 해당 구성 요소가 어떻게 상호 작용하는지 이해하는 한 가지 방법은 실제 시나리오를 검토하는 것입니다. 다음 섹션에서는 다양한 JBoss EAP 보안 구성 요소 및 구성 옵션이 포함된 일반적인 몇 가지 현실 상황에 대해 설명합니다. 애플리케이션 또는 애플리케이션 집합이 보안되는 방법과 관리 인터페이스를 보호하는 방법에 중점을 둡니다.

5.1. Red Hat JBoss Enterprise Application Platform out out the Box

이 시나리오는 초기 설치 후 구성을 변경하지 않은 경우 JBoss EAP 및 샘플 애플리케이션을 보호하는 방법을 보여줍니다. 애플리케이션 sampleApp1.war 는 컨테이너 기반 보안을 사용하도록 배포 및 구성됩니다.

scenario1

5.1.1. 박스에서 코어 관리 인증

5.1.1.1. 보안

Core Management Authentication은 기본적으로 두 개의 사전 구성된 보안 영역을 제공합니다. ManagementRealmApplicationRealm. 이러한 영역은 속성 파일을 사용하여 사용자 이름, 암호 및 역할을 저장합니다. 인증 정보와 관리 API를 저장하는 데 사용되는 ManagementRealm 은 또한 JBoss EAP 인스턴스와 동일한 호스트에서 CLI를 사용하는 사용자에 대한 로컬 인증을 정의하고 활성화합니다. The ApplicationRealm 은 인증 및 권한 부여 정보를 저장하지만 관리 API 이외의 다른 애플리케이션과 사용하도록 사전 구성되어 있습니다. 또한 ApplicationRealm 은 로컬 인증이 활성화된 사전 구성되어 있지만 일반적으로 사용되지 않습니다.

5.1.1.2. 작동 방식

이 시나리오의 경우 다음 사용자가 JBoss EAP의 기본 설치에 추가되었습니다.

표 5.1. 사용자

사용자 이름암호역할보안 영역

수전

Testing123!

 

ManagementRealm

Sarah

Testing123!

샘플

ApplicationRealm

임페어

Testing123!

 

ApplicationRealm

시작 시 JBoss EAP 인스턴스는 ManagementRealmApplicationRealm 보안 영역을 로드합니다.

Susan이 관리 인터페이스(HTTP 또는 CLI) 중 하나에 액세스하려고 하면 인증이 필요합니다. 사용자 이름, 암호 및 역할은 ManagementRealm 보안 영역의 항목과 일치해야 합니다. 기본적으로 관리 API에 액세스하는 데 역할이 필요하지 않습니다. Sarah와 domain은 ManagementRealm 보안 영역에 있지 않기 때문에 관리 API에 액세스할 수 없습니다.

5.1.2. 박스에서 보안 하위 시스템

5.1.2.1. 보안

보안 하위 시스템은 other,jboss-web-policy, jboss-ejb-policy jaspitest 의 네 가지 보안 도메인으로 사전 구성됩니다. other 보안 도메인은 기본적으로 ApplicationRealm 을 사용하는 로그인 모듈에 지정된 영역에 위임하여 인증 및 권한 부여를 수행합니다.

기본 보안 영역 및 기본 보안 도메인에 대한 추가 정보는 Security Realms and Security Domains (보안 영역 및 보안 도메인) 섹션에서 확인할 수 있습니다.

5.1.2.2. 작동 방식

애플리케이션 sampleApp1.war 에는 /hello.html 및 /secure/hello. html 이라는 두 개의 HTML 파일이 있으며 기본 HTTP 인증을 사용하여 /secure/* 경로를 보호합니다. other 보안 도메인을 사용하며 샘플 의 역할이 필요합니다. 기타 보안 도메인은 인증 및 권한 부여 정보에 대해 ApplicationRealm 을 디스패처하므로 이전 섹션의 Users(사용자 ) 테이블에 있는 사용자를 참조하십시오.

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

5.2. 관리 인터페이스에 HTTPS 및 RBAC가 추가된 Red Hat JBoss Enterprise Application Platform

이 시나리오에서는 관리 인터페이스에 대해 HTTPS를 활성화하고 RBAC를 ManagementRealm 보안 영역에 추가하는 경우 JBoss EAP를 보호하는 방법을 보여줍니다.

scenario2

5.2.1. 보안

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

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

5.2.2. 작동 방식

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

표 5.2. 사용자 관리

사용자 이름암호보안 영역

Suzy

Testing123!

ManagementRealm

Tim

Testing123!

ManagementRealm

Emily

Testing123!

ManagementRealm

Zach

Testing123!

ManagementRealm

Natalie

Testing123!

ManagementRealm

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

표 5.3. RBAC 역할

사용자 이름RBAC 역할

Suzy

수퍼유저

Tim

관리자

Emily

유지 관리자

Zach

deployer

Natalie

모니터

시작 시 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 추가 섹션을 참조하십시오.

5.3. HTTPS를 포함한 보안 하위 시스템을 업데이트한 Red Hat JBoss Enterprise Application Platform

이 시나리오는 새 보안 도메인이 추가되고 HTTPS가 활성화된 경우 JBoss EAP에서 실행 중인 샘플 애플리케이션을 보호하는 방법을 보여줍니다. 컨테이너 기반 보안, sample -domain 및 HTTPS를 사용하도록 구성된 애플리케이션 sample App2.war 가 배포됩니다.

scenario3

5.3.1. 보안

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

5.3.2. 작동 방식

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

표 5.4. sample-domain 사용자

사용자 이름암호역할

Vincent

samplePass

샘플

시작 시 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를 통해 처리하는 모든 트래픽에도 적용됩니다.

5.4. Red Hat JBoss Enterprise Application Platform에서 웹 애플리케이션용 SSO

이 시나리오에서는 웹 애플리케이션이 JBoss EAP에서 클러스터형 SSO와 비클러스터형 SSO를 사용하는 방법을 보여줍니다. JBoss EAP 인스턴스 4개가 생성됩니다. EAP1,EAP2,EAP3, EAP4. EAP1EAP2 는 독립 실행형 서버로 작동하고 EAP3EAP4 는 2-노드 클러스터로 작동합니다. 두 개의 웹 애플리케이션( sampleAppAsampleAppB )이 4개의 JBoss EAP 인스턴스 각각에 배포되었습니다.

scenario4

5.4.1. 보안

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

표 5.5. SSO-domain 사용자

사용자 이름암호역할

Jane

samplePass

샘플

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

애플리케이션 클러스터링 및. 클러스터형 SSO

클러스터형 웹 애플리케이션과 클러스터된 SSO 간에는 뚜렷한 차이점이 있습니다. 클러스터된 웹 애플리케이션은 해당 애플리케이션 호스팅의 부하를 분산하기 위해 클러스터의 노드에 배포되는 웹 애플리케이션입니다. 배포 가능으로 표시된 클러스터된 애플리케이션에서는 모든 새 세션과 기존 세션에 대한 변경 사항이 클러스터의 다른 구성원에게 복제됩니다. 클러스터된 SSO를 사용하면 애플리케이션이 클러스터되었는지 여부에 관계없이 보안 컨텍스트 및 ID 정보를 복제할 수 있습니다. 이러한 기술을 함께 사용할 수도 있지만 상호 배타적이며 독립적으로 사용할 수 있습니다.

5.4.2. 작동 방식

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

Jane이 EAP1/sampleAppA/secure/hello.html 에 액세스하려고 하면 인증 메시지가 표시됩니다. 올바른 정보를 제공한 후 EAP1/sampleAppA/secure/hello.html 을 볼 수 있습니다. Jane의 세션은 the undertowinfinispan 하위 시스템에서 사용하는 SSO 캐시에 추가됩니다. EAP1/sampleAppB/secure/hello.html 에 액세스하려고 하면 다시 인증하라는 메시지가 표시되지 않습니다. EAP1 에서 실행 중인 sampleAppBinfinispan 하위 시스템과 함께 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의 세션이 무효화되면 캐시 전체에서 리플을 가져와서 클러스터에서 액세스하려는 애플리케이션이나 서버에 관계없이 다시 인증해야 합니다.

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

이 시나리오에서는 JBoss EAP의 여러 인스턴스가 보안되고 브라우저 기반 SSO를 추가하는 방법을 보여줍니다. 클러스터되지 않은 별도의 세 개의 JBoss EAP 인스턴스가 구성됩니다. EAP1,EAP2EAP3. 샘플 애플리케이션 세 개( sampleAppA.war,sampleAppB.war, sampleAppC.war )는 인증에 브라우저 기반 SSO를 사용하도록 구성됩니다.

scenario5

5.5.1. 보안

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,EAP2EAP3 는 각각 개별 SP, sampleAppA.war, sampleAppB.warsampleApp C 역할을 할 하나의 고유한 애플리케이션입니다. 각 JBoss EAP 인스턴스에는 SAML2LoginModule 을 인증 메커니즘으로 사용하도록 구성된 보안 도메인인 sso-domain 이 있습니다. 각 애플리케이션에는 SSO를 지원하고, ID 공급자로 IDP.war 를 사용하고, 인증에 HTTP/POST 바인딩을 사용하는 기능이 포함되어 있습니다. 또한 각 애플리케이션은 경로 /secure/* 를 보안하도록 usesso -domain 을 구성하고 권한 부여를 처리하기 위한 고유한 역할 목록을 제공합니다.

5.5.2. 작동 방식

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

표 5.6. DP-domain 사용자

사용자 이름암호역할

Eric

samplePass

모두

Amar

samplePass

AB

Brian

samplePass

C

Alan

samplePass

 

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.warsampleAppC.war가 포함됩니다. respectively. sso-domainSAML2LoginModule 로그인 모듈을 사용하도록 구성되어 있지만 애플리케이션을 사용하여 적절한 SAML 토큰을 제공합니다. 즉, SAML 토큰을 얻으려면 도메인을 사용하는 모든 애플리케이션이 IDP에 올바르게 연결되어야 합니다. 이 경우 sampleAppA,sampleAppBsampleAppC 는 각각 jboss-web.xml,web.xml, picketlink.xmljboss-deployment-structure.xml 을 통해 IDP, IDP.war 에서 SAML 토큰을 가져오기 위해 IDP의 로그인 양식을 사용합니다.

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

표 5.7. 애플리케이션/SP 역할

애플리케이션/SP허용된 역할

sampleAppA

모두, AB

sampleAppB

모두, AB

sampleAppC

all, C

인증되지 않은 사용자가 모든 애플리케이션의 /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 는 역할 allAB/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 를 사용하면 allAB 역할이 /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 을 보는 것에서 제한될 수 있습니다. ABEAP1/sampleAppA/secure/* 및 EAP2/sampleAppB/ secure/* 에만 액세스할 수 있기 때문입니다. Brian은 비슷한 상황에 있지만 EAP3/sampleAppC/secure/* 에만 액세스할 수 있습니다. Alan은 서비스 공급자의 보안 영역에 액세스하려고 하면 SAML 토큰을 보유하거나 취득해야 하지만 역할이 없으므로 아무것도 볼 수 없게 제한됩니다. 각 SP에는 인증된 모든 사용자가 SAML 토큰을 가져오지 않고도 볼 수 있는 보안되지 않은 영역이 있습니다.

5.6. ManagementRealm으로 LDAP 사용

이 시나리오에는 관리 인터페이스 보안을 위해 LDAP를 사용하여 ManagementRealm 이 표시됩니다. JBoss EAP 인스턴스는 생성되었으며 독립 실행형 서버로 실행되고 있습니다. EAP1ManagementRealm 도 인증 및 권한 부여 메커니즘으로 LDAP를 사용하도록 업데이트되었습니다.

scenario6

5.6.1. 보안

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

5.6.2. 작동 방식

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

표 5.8. 사용자 관리

사용자 이름암호역할

마케도니아

samplePass

수퍼유저

Sam

samplePass

 

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

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

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

5.7. 데스크탑 SSO를 사용하여 Kerberos를 사용하여 웹 애플리케이션용 SSO 제공

이 시나리오에서는 Kerberos를 JBoss EAP와 함께 사용하여 웹 애플리케이션에 SSO를 제공하는 방법을 보여줍니다. JBoss EAP 인스턴스는 생성되었으며 독립 실행형 서버로 실행되고 있습니다. 두 개의 웹 애플리케이션( sampleAppAsampleAppB )이 EAP1 에 배포되었습니다. 웹 애플리케이션과 EAP1 은 모두 Kerberos를 통해 데스크탑 기반 SSO를 사용하여 인증하도록 구성되었습니다.

scenario7

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

5.7.1.1. 작동 방식

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

표 5.9. Kerberos 사용자

사용자 이름암호

B 실행되는

samplePass

Andy

samplePass

Bill

samplePass

Ron

samplePass

다음 역할은 FirstPass를 사용하도록 password-stacking 옵션을 설정하여 연결된 추가 모듈을 통해 사용자에게 매핑되었습니다.

표 5.10. 사용자 역할

사용자 이름역할

B 실행되는

모두

Andy

A

Bill

B

Ron

 

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

표 5.11. 애플리케이션 역할

애플리케이션/SP허용된 역할

sampleAppA

모두, A

sampleAppB

all, B

시작 시 EAP1 은 핵심 서비스를 로드한 다음 보안 및 기타 하위 시스템을 로드합니다. host-domain 은 Kerberos 서버에 대한 연결을 설정하고 spnego-domain은 host-domain 에 연결합니다. sampleAppAsampleAppB 가 배포되어 인증을 위해 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 로그인 페이지로 이동합니다. 그런 다음 대체 보안 도메인을 통해 자격 증명이 인증되고 프로세스는 권한 부여를 계속합니다.





2022-07-02 18:10:02 +1000 수정