다중 보안 도메인
WebSphere® 보안 도메인(WSD)을 사용하면 WebSphere Application Server에서 다양한 보안 구성을 유연하게 사용할 수 있습니다. WSD를 다중 보안 도메인 또는 간단히 보안 도메인이라고도 합니다. 애플리케이션마다 UserRegistry와 같은 보안 속성을 서로 다르게 구성할 수 있습니다.
보안 도메인이 유용한 이유
WebSphere 보안 도메인은 두 가지 중요한 이점을 제공합니다.
- WebSphere Application Server 관리 애플리케이션을 사용자 애플리케이션의 다양한 보안 구성 세트로 구성할 수 있습니다.
- 하나의 애플리케이션 세트에 또 다른 애플리케이션 세트의 다른 보안 구성 세트가
포함되도록 할 수 있습니다.
예를 들어, WebSphere Application Server 관리는 RACF®의 사용자 레지스트리에 대해 구성되고 LDAP의 사용자 레지스트리에 대해서는 애플리케이션을 구성할 수 있습니다.
예를 들어, WebSphere Application Server 관리는 연합 저장소의 사용자 레지스트리에 대해 구성되고 LDAP의 사용자 레지스트리에 대해서는 애플리케이션을 구성할 수 있습니다.
WebSphere Application Server의 이전 버전에서 모든 관리 및 사용자 애플리케이션은 대부분의 보안 속성을 공유합니다. 기본적으로, WebSphere Application Server의 모든 관리 및 사용자 애플리케이션은 글로벌 보안 속성을 사용합니다. 예를 들어, 글로벌 보안에 정의된 사용자 레지스트리는 셀에 있는 모든 애플리케이션의 사용자를 인증하는 데 사용됩니다.
그러나 이 릴리스의 WebSphere Application Server에서는 사용자 애플리케이션에 대해 글로벌 보안 속성 외에 다중 보안 속성을 사용하고, 서로 달라야 하는 보안 속성에 대해 보안 도메인을 작성하며, 이를 해당 사용자 애플리케이션을 호스트하는 서버 및 클러스터와 연관시킬 수 있습니다. 또한 보안 도메인을 셀과 연관시킬 수 있습니다. 셀의 모든 사용자 애플리케이션은 이전에 연관시킨 도메인이 없는 경우 해당 보안 도메인을 사용합니다. 그러나 관리 콘솔, 네이밍 자원 및 MBeans 같은 관리 애플리케이션의 경우 글로벌 보안 속성이 계속 필수입니다.
이전 릴리스의 WebSphere Application Server에서 서버 레벨 보안을 사용한 경우, 다중 보안 도메인이 보다 유연하고 구성하기 쉬우므로 다중 보안 도메인을 사용하는 것이 좋습니다.
이 릴리스에서는 서버 레벨 보안이 사용되지 않습니다. 자세한 정보는 글로벌 보안 및 보안 도메인 사이의 관계의 내용을 읽으십시오.
글로벌 보안 및 보안 도메인 사이의 관계
글로벌 보안은 모든 관리 기능과 사용자 애플리케이션의 기본 보안 구성에 적용됩니다. 보안 도메인은 사용자 애플리케이션에 대해 사용자 정의 구성을 정의하는 데 사용될 수 있습니다.
보안 도메인을 작성하려면 먼저 글로벌 보안 구성이 정의되어 있어야 합니다. 글로벌 보안 구성은 관리 콘솔, 네이밍 자원 및 Mbeans 같은 모든 관리 애플리케이션에서 사용됩니다. 보안 도메인이 구성되지 않은 경우 애플리케이션은 모두 글로벌 보안 구성의 정보를 사용합니다. EJB(Enterprise JavaBeans), 서블릿, 관리 애플리케이션 같은 사용자 애플리케이션은 동일한 보안 구성을 사용합니다.
보안 도메인을 작성하여 범위와 연관시키는 경우 해당 범위에 있는 사용자 애플리케이션만 보안 도메인에 정의된 보안 속성을 사용합니다. 해당 범위에 있는 관리 애플리케이션 및 네이밍 조작은 글로벌 보안 구성을 사용합니다. 글로벌 레벨의 보안 특성과 달라야 하는 보안 특성을 도메인 레벨에서 정의하십시오. 정보가 공통인 경우 중복된 정보가 보안 도메인에 있을 필요는 없습니다. 도메인에서 누락된 모든 속성은 글로벌 구성에서 가져옵니다. 글로벌 보안 구성 데이터는 $WAS_HOME/profiles/$ProfileName/cells/$CellName 디렉토리에 있는 security.xml 파일에 저장됩니다.
다음 그림은 셀, 서버 및 클러스터가 서로 다른 보안 도메인과 연관되어 있는 보안 다중 도메인의 예를 제공합니다. 그림에 표시된 것처럼 S1.1 서버의 사용자 애플리케이션 및 클러스터는 각각 Domain2 및 Domain3에 정의된 보안 속성을 사용합니다. 이러한 범위가 해당 도메인과 연관되어 있기 때문입니다. S2.2 서버는 도메인과 연관되어 있지 않습니다. 따라서 S2.2에 있는 사용자 애플리케이션은 기본적으로 셀과 연관된 도메인(Domain1)을 사용합니다. 도메인 레벨에서 누락된 보안 속성은 글로벌 구성에서 가져옵니다.

다음 그림은 글로벌 보안 구성에서 정의하고 도메인 레벨에서 대체할 수 있는 다양한 상위 레벨 보안 속성을 보여 줍니다.

보안 도메인의 컨텐츠
보안 도메인은 두 개의 구성 파일에 의해 표시됩니다. 하나의 구성 파일에는 보안 도메인에 구성된 속성 목록이 있습니다. 다른 구성 파일에는 보안 도메인을 사용하는 범위가 있습니다. 보안 도메인 정보는 $WAS_HOME/profiles/$ProfileName/config/waspolicies/default/securitydomains/$SecurityDomainName 디렉토리에 저장됩니다. 구성된 모든 보안 도메인에 대해 $SecurityDomainName 디렉토리가 작성되며, 이 디렉토리에는 두 개의 파일 즉, 보안 도메인에 대해 구성된 보안 속성 목록이 있는 security-domain.xml 파일과 보안 도메인을 사용하는 범위가 있는 security-domain-map.xml 파일이 들어 있습니다.
다음 그림은 기본 보안 도메인 관련 파일의 위치 및 해당 파일의 컨텐츠를 보여줍니다.

보안 도메인 작성
보안 도메인을 작성하려면 관리 콘솔 태스크 또는 스크립트 명령을 사용하십시오. 관리 콘솔에서는
을 클릭하여 보안 도메인에 액세스하십시오. 각 관리 콘솔 패널에서는 도움말을 사용할 수 있습니다.관리 콘솔 태스크 및 스크립트 명령의 전체 목록은 이 문서의 맨 아래에 있는 "관련 태스크" 링크를 참조하십시오.
보안 도메인을 작성하는 경우 도메인의 고유 이름, 보안 도메인에 대해 구성하려는 보안 속성 그리고 보안 도메인을 사용해야 하는 범위를 제공해야 합니다. 구성된 후에는 보안 도메인을 사용할 서버를 다시 시작해야 합니다. 그러면 해당 범위에 있는 사용자 애플리케이션이 보안 도메인에 정의된 보안 속성을 사용합니다. 도메인 레벨에서 구성되지 않은 모든 속성은 글로벌 보안 구성에서 가져옵니다. 범위에 있는 관리 애플리케이션 및 네이밍 조작은 항상 글로벌 보안 구성의 보안 속성을 사용합니다. 사용자는 이러한 속성을 적극적으로 관리해야 합니다.
모든 새 보안 도메인 속성은 도메인에 지정된 사용자 애플리케이션에 의해 상속되는 해당 글로벌 보안 속성과 호환 가능해야 합니다.
JAAS 및 사용자 정의 특성 외에는 글로벌 속성이 도메인에 대해 사용자 정의되면 사용자 애플리케이션에서 더 이상 사용되지 않습니다.
관리 콘솔의 보안 도메인 패널에서는 자원을 지정하고 도메인에 적합한 보안 속성을 선택할 수 있습니다. 패널에는 글로벌 구성의 주요 보안 속성이 표시됩니다. 필요한 경우 도메인 레벨에서 해당 속성을 대체하도록 결정할 수 있습니다. 도메인 레벨에서 속성을 구성하고 저장하고 나면 해당 도메인에 사용자 정의된 값이 패널의 요약 값에 표시됩니다(검은색 텍스트에 "사용자 정의됨" 태그가 붙어 있음).
범위(서버, 클러스터, 서비스 통합 버스 또는 셀)는 하나의 도메인과만 연관될 수 있습니다. 예를 들어, 범위가 모두 셀인 도메인을 두 개 정의할 수 없습니다. 그러나 동일한 보안 도메인에서는 다중 범위가 정의될 수 있습니다. 예를 들어, 하나의 도메인이 해당 셀 내에서만 Server1 및 Server2로 범위 지정될 수 있습니다.
보안 도메인 패널의 지정된 범위 섹션에는 두 개의 보기가 표시됩니다. 하나는 도메인에 대해 범위를 선택하고 지정할 수 있는 보기이고 다른 하나는 현재 지정된 범위 목록을 볼 수 있는 보기입니다. 사용자의 편의를 위해 기존 보안 도메인 또는 글로벌 구성에서 새 보안 도메인으로 모든 보안 속성을 복사한 후 서로 달라야 하는 속성만 수정할 수 있는 유연성도 제공합니다. 그러나 계속해서 이러한 복사된 도메인에 범위를 연관시켜야 합니다.
스크립트 명령을 사용하여 보안 도메인을 작성, 복사 및 수정할 수도 있습니다. 도메인이 작성되면 적절한 명령을 실행하여 보안 속성 및 범위를 해당 도메인에 연관시켜야 합니다.
보안 도메인 속성 구성
WebSphere Application Server 버전 9.0의 도메인 레벨에서 구성할 수 있는 보안 속성은 다음과 같습니다.
- 애플리케이션 보안
- Java™ 2 보안
- 사용자 범주(레지스트리)
- 신뢰 연관
- SPNEGO(Simple and Protected GSS-API Negotiation) 웹 인증
- RMI/IIOP 보안(CSIv2)
- JAAS 로그인(애플리케이션, 시스템 및 J2C 인증 데이터)
- Java 인증 SPI
- 인증 메커니즘 속성
- 권한 제공자
- 연합 저장소
z/OS® 특성
- 사용자 정의 특성
관리 콘솔의 보안 도메인 패널에는 이러한 보안 속성이 모두 표시됩니다.
도메인 레벨에서 대체할 수 없는 잘 알려진 다른 속성 중 일부로 Kerberos, 감사, 웹 싱글 사인온(SSO) 및 TAM(Tivoli® Access Manager)을 들 수 있습니다. SSL(Secure Sockets Layer) 속성은 이미 다양한 범위를 지원하지만 도메인 구성의 일부가 아닙니다. 도메인 레벨에서 지원되지 않는 모든 속성의 경우 도메인에 있는 사용자 애플리케이션이 글로벌 레벨에서 해당 구성을 공유합니다.
모든 새 보안 도메인 속성은 도메인에 지정된 사용자 애플리케이션에 의해 상속되는 해당 글로벌 보안 속성과 호환 가능해야 합니다. 사용자는 이러한 속성을 적극적으로 관리해야 합니다. 예를 들어, 도메인 레벨에서 JAAS 구성만 사용자 정의하는 경우 글로벌 레벨에서 구성된 사용자 레지스트리와 작동하는지 확인해야 합니다(사용자 레지스트리가 도메인 레벨에서 사용자 정의되지 않은 경우).
JAAS 및 사용자 정의 특성 외에는 글로벌 속성이 도메인에 대해 사용자 정의되면 사용자 애플리케이션에서 더 이상 사용되지 않습니다.
TAM 서버에 접속하여 인증(TrustAssociationInterceptor 및 PDLoginModule) 및 권한(JACC에 사용됨)을 제공하는 데 Tivoli Access Manager 클라이언트 런타임을 사용합니다. 단 하나의 Tivoli Access Manager 런타임을 셀의 모든 서버가 공유합니다. 자세한 정보는 Tivoli Access Manager JACC 제공자 구성 주제를 참조하십시오.
보안 도메인 레벨에서 다른 Tivoli Access Manager 구성을 보유하여 셀 레벨의 구성을 대체할 수 없습니다. 그러나 어느 정도는 보안 도메인 레벨에서 TAI(Trust Association Interceptor) 및 JACC 구성을 지정할 수 있습니다. 예를 들면, 다른 TAI 또는 다른 권한 제공자를 사용할 수 있습니다. TAM 서버 연결은 글로벌 레벨에서만 정의할 수 있으므로 보안 도메인 레벨에서 다양한 TAI를 정의 및 구성할 수 있습니다. 이러한 TAI 중 일부는 다른 TAI가 수행 중에는 TAM 사용자 저장소를 사용하지 않습니다. TAM에 연결되어야 하는 TAI는 글로벌하게 정의된 TAM 서버에도 연결됩니다. 마찬가지로 권한의 경우에도 도메인 레벨에서 다양한 외부 권한 제공자를 구성할 수 있습니다. 그러나 이러한 외부 권한 제공자가 TAM에 연결되어야 하는 경우, 결국 이러한 제공자는 글로벌하게 구성된 하나의 TAM 서버에 연결됩니다.
보안 도메인에 범위 연관
보안 도메인이 클러스터의 일부가 아닌 서버와 연관되어 있는 경우 해당 서버의 모든 사용자 애플리케이션은 보안 도메인의 속성을 사용합니다. 모든 누락된 보안 속성은 글로벌 보안 구성에서 가져옵니다. 서버가 클러스터의 일부인 경우 보안 도메인을 클러스터와 연관시킬 수는 있으나 해당 클러스터의 개별 멤버와 연관시킬 수는 없습니다. 보안 작동은 모든 클러스터 멤버 간에 일관됩니다.
서버가 클러스터의 일부인 경우 클러스터를 먼저 작성하고 보안 도메인을 클러스터에 연관시키십시오. 서버가 클러스터의 멤버가 되기 전에 도메인을 서버에 연관시켰을 수 있습니다. 이 경우 도메인이 서버와 직접 연관되어 있어도 보안 런타임 코드에서 도메인을 찾지 않습니다. 서버가 클러스터 멤버인 경우 보안 런타임은 서버와 직접 연관된 모든 보안 도메인을 무시합니다. 보안 도메인에서 서버 범위를 제거하고 대신 클러스터 범위를 연관시키십시오.
보안 도메인은 셀에 연관될 수도 있습니다. 일반적으로, WebSphere Application Server의 모든 사용자 애플리케이션을 하나의 보안 도메인에 연관시키려는 경우에 수행됩니다. 이 시나리오에서는 모든 관리 애플리케이션 및 네이밍 조작이 글로벌 보안 구성을 사용하고 모든 사용자 애플리케이션이 도메인 레벨 구성을 사용합니다. 관리 및 사용자 애플리케이션의 보안 구성 정보를 분리하려면 이 방법을 사용하면 됩니다.
혼합 버전 환경이거나 향후 혼합 버전 환경을 계획하고 있으며 보안 도메인을 셀 레벨에서 연관시키려는 경우 자세한 정보는 혼합 버전 환경의 보안 도메인의 내용을 참조하십시오.
자체 보안 도메인이 정의되어 있고 배치 관리자에 연합된 기본 프로파일 서버에 있는 경우 셀 범위가 아닌 서버 범위를 보안 도메인에 연관시키십시오. 해당 노드가 연합되면 보안 도메인 정보가 배치 관리자로 전파됩니다. 셀 범위가 연관되어 있는 경우 Network Deployment 구성이 이러한 보안 구성을 사용하며 이는 기존 애플리케이션에 영향을 줄 수 있습니다. 연합 중 셀 범위는 연합되는 서버 범위로 변경됩니다. 서버 범위가 보안 도메인과 연관되어 있는 경우 연합 후 해당 서버만 이 보안 도메인을 사용합니다. 다른 서버 및 클러스터의 다른 애플리케이션은 영향을 받지 않습니다. 그러나 이 기본 프로파일 서버가 관리 에이전트 프로세스에 등록되는 경우 기본 프로파일의 모든 서버가 모든 해당 사용자 애플리케이션에 대해 동일한 보안 도메인을 사용하도록 하려면 셀 범위를 보안 도메인에 연관시킬 수 있습니다. 자세한 정보는 보안 도메인이 포함된 노드 연합의 내용을 참조하십시오.
하나의 보안 도메인은 셀 레벨에서 연관되고 다른 보안 도메인은 다양한 클러스터 또는 개별 서버(클러스터의 일부가 아닌 서버)에 연관되도록 할 수도 있습니다. 이 경우 보안 런타임은 먼저 보안 도메인이 서버 또는 클러스터와 연관되어 있는지 여부를 확인합니다. 보안 도메인이 서버 또는 클러스터와 연관되어 있는 경우 정의된 보안 속성이 해당 서버 또는 클러스터의 모든 애플리케이션에 대해 사용됩니다. 이 서버 또는 클러스터 도메인에서 누락된 보안 속성은 셀과 연관된 도메인 구성이 아닌 글로벌 보안 구성에서 가져옵니다.
서버 또는 클러스터에 자체 도메인이 정의되어 있지 않은 경우 보안 런타임 코드는 셀과 연관된 도메인의 보안 속성을 사용합니다(정의되어 있는 경우). 셀 도메인에서 누락된 보안 속성은 글로벌 보안 구성에서 상속됩니다.
이전 서버 레벨 보안과 새 보안 도메인 사이의 관계
WebSphere Application Server의 이전 릴리스에서는 소규모 보안 속성 세트를 서버 레벨에서 연관시킬 수 있습니다. 이러한 속성은 서버 레벨의 모든 애플리케이션에서 사용됩니다. 이전의 보안 속성 구성 방법은 WebSphere Application Server 7.0에서는 사용되지 않으며 향후 릴리스에서 제거됩니다.
WebSphere Application Server 7.0에서 시작하는 새 보안 도메인 지원을 사용해야 합니다. 이러한 새 보안 도메인은 더 쉽게 관리되고 더 유연합니다. 예를 들어, WebSphere Application Server의 이전 버전에서는 클러스터의 모든 서버에 대해 동일한 보안 속성을 구성하여 모든 클러스터 멤버에 동일한 보안 구성을 수동으로 연관시켜야 합니다.
마이그레이션 도구는 스크립트 호환성 모드가 false(-scriptCompatibility="false")인 경우 기존 서버 레벨 보안 구성 정보를 새 보안 도메인 구성으로 마이그레이션합니다. 클러스터의 일부가 아닌 경우 모든 서버 보안 구성에 대해 새 보안 도메인이 작성됩니다. 클러스터의 일부인 경우 보안 도메인이 해당 클러스터의 모든 서버가 아닌 해당 클러스터와 연관됩니다. 두 경우 모두 이전 릴리스의 서버 레벨에서 구성된 모든 보안 속성이 새 보안 도메인 구성으로 마이그레이션되고 적절한 범위가 보안 도메인에 지정됩니다.
스크립트 호환성 모드가 true로 설정되어 있는 경우 서버 레벨 보안 구성이 새 보안 도메인 구성으로 마이그레이션되지 않습니다. 이전 서버 보안 구성은 변경 없이 마이그레이션됩니다. 보안 런타임은 보안 도메인이 직접 또는 간접적으로 서버에 연관되어 있는 경우에도 이전 보안 구성이 존재하며 해당 정보를 사용함을 발견합니다. 스크립트 호환성 모드가 true로 설정되어 있는 경우 서버 레벨에서 보안 구성을 제거한 후 동일한 보안 속성 세트로 보안 도메인을 작성하십시오.
보안 런타임 및 애플리케이션에서 도메인 레벨 보안 속성을 사용하는 방식
이 섹션에서는 도메인 레벨의 개별 속성이 보안 런타임에서 사용되는 방법 및 이러한 사용이 사용자 애플리케이션 보안에 어떠한 영향을 주는지에 대해 설명합니다. 이러한 모든 보안 속성은 글로벌 레벨에서도 정의되므로 이러한 속성에 대한 자세한 정보는 어디에서나 얻을 수 있습니다. 이 섹션의 목적에 맞게 도메인 레벨 작동에 중점을 둡니다.
- 애플리케이션 보안:
애플리케이션 보안 사용 가능을 선택하면 사용자 애플리케이션에 대한 보안을 사용 가능 또는 사용 불가능으로 설정할 수 있습니다. 이 선택사항이 사용 불가능하게 설정되어 있는 경우 보안 도메인의 모든 EJB 및 웹 애플리케이션이 더 이상 보호되지 않습니다. 사용자 인증 없이 이러한 자원에 액세스가 부여됩니다. 이 선택사항이 사용 가능한 경우, 보안 도메인의 모든 EJB 및 웹 애플리케이션에 대해 J2EE 보안이 강제 실행됩니다. J2EE 보안은 글로벌 보안 구성에 글로벌 보안이 사용 가능으로 설정되어 있는 경우에만 강제 실행됩니다. 즉, 글로벌 레벨에서 글로벌 보안을 먼저 사용 가능하게 설정해야 애플리케이션 보안을 사용 가능하게 설정할 수 있습니다.
- Java 2 보안:
Java 2 보안 사용을 선택하면 도메인 레벨에서 Java 2 보안을 사용 가능 또는 사용 불가능으로 설정하거나, Java 2 보안과 관련된 특성을 지정하거나 추가할 수 있습니다. 이 선택사항은 모든 애플리케이션(관리 및 사용자 둘 다)이 Java 2 보안을 사용 가능 또는 사용 불가능으로 설정할 수 있도록 프로세스(JVM) 레벨에서 Java 2 보안을 사용 가능 또는 사용 불가능으로 설정합니다.
- 사용자 영역(사용자 레지스트리):
이 섹션에서는 보안 도메인에 대한 사용자 레지스트리를 구성할 수 있습니다. 도메인 레벨에서 사용되는 모든 레지스트리를 별도로 구성할 수 있습니다. 자세한 정보는 보안 도메인 속성 구성의 내용을 참조하십시오.
도메인 레벨에서 레지스트리를 구성하는 경우 레지스트리에 대해 자체 범주 이름을 정의하도록 선택할 수 있습니다. 범주 이름으로 하나의 사용자 레지스트리를 다른 사용자 레지스트리와 구별합니다. 영역 이름은 여러 위치에서 사용되며 다음과 같습니다. 사용자에게 프롬프트하기 위해 Java 클라이언트 로그인 패널, 인증 캐시, 기본 권한을 사용하는 경우입니다.
글로벌 구성 레벨에서 시스템은 사용자 레지스트리에 대해 범주를 작성합니다. WebSphere Application Server의 이전 릴리스에서는 시스템에 하나의 사용자 레지스트리만 구성됩니다. 다중 보안 도메인이 있는 경우 시스템에 여러 레지스트리를 구성할 수 있습니다. 이러한 도메인에서 고유한 범주에 대해 보안 도메인의 자체 범주 이름을 구성하십시오. 범주가 고유하다고 확신하는 경우 시스템에서 고유 범주 이름을 작성하도록 선택할 수도 있습니다. 후자의 경우 범주 이름은 사용되는 레지스트리를 기반으로 합니다.
LDAP 레지스트리의 경우 LDAP 서버의 host:port가 시스템 생성 범주 이름입니다. localOS의 경우 localOS 시스템 이름이 범주 이름입니다. 사용자 정의 사용자 레지스트리의 경우 범주는 사용자 정의 레지스트리 구현의 getRealm ( ) 메소드에서 리턴한 값입니다.
시스템 생성 범주 이름이 고유한 경우 시스템이 범주 이름을 생성하는 옵션을 선택할 수 있습니다. 고유하지 않은 경우 사용자 레지스트리가 구성된 각 보안 도메인에 대해 고유 범주 이름을 선택하십시오. 기본 사용자 저장소가 동일한 경우 다른 도메인에서 동일한 범주 이름을 사용하십시오. 보안 런타임 Perspective에서는 동일한 범주 이름에 동일한 사용자 및 그룹 정보 세트가 있습니다. 예를 들어, 사용자 및 그룹 정보가 범주에서 필수인 경우 범주가 일치하는 첫 번째 사용자 저장소가 사용됩니다.
중앙 집중화되지 않은 localOS 레지스트리가 도메인에 대해 구성되고 배치 관리자와 동일하지 않은 시스템의 노드에 있는 서버 또는 클러스터에 해당 도메인이 연관되어 있는 경우 범주 이름이 제공되어야 합니다. 범주 이름은 노드에서 생성된 것처럼 동일해야 합니다. 이 범주 이름은 해당 노드의 SecurityAdmin MBean에서 getRealm() 메소드를 호출하여 가져올 수 있습니다. 일반적으로 localOS 레지스트리의 범주 이름은 시스템의 호스트 이름입니다. 이 경우 시스템에서 범주 이름을 생성하지 않도록 하고 노드의 프로세스에서 사용하는 범주 이름을 가져오도록 해야 합니다.사용자 레지스트리 구성 시 시스템에서 localOS 레지스트리의 범주를 생성하도록 선택하는 경우 배치 관리자에서 사용하는 localOS 레지스트리를 선택합니다. 구성된 범주가 서버에서 사용하는 범주와 일치하지 않는 경우 권한 문제가 발생합니다. 또한 이 경우 해당 로컬 레지스트리를 사용하는 도메인은 동일한 시스템의 노드에 속하는 서버 및 클러스터와만 연관될 수 있습니다.
WebSphere Application Server 버전 7.0에서는 연합 저장소 사용자 레지스트리는 글로벌 레벨에서만 구성할 수 있으나 모든 도메인이 해당 레지스트리를 활성 레지스트리로 구성하여 사용할 수 있습니다. WebSphere Application Server 버전 8.0에서는 여러 보안 도메인 환경에서 도메인 레벨로 연합 저장소의 고유 인스턴스를 구성할 수 있습니다.
글로벌 레벨에서 보안 도메인이 복사되면, 글로벌 레벨에서 정의된 사용자 및 그룹도 보안 도메인에 복사됩니다. 기존 도메인에서 복사할 때도 마찬가지입니다. 파일 기반 VMM 저장소를 사용하는 새로 작성된 보안 도메인에서는 사용자가 사용자 및 그룹으로 저장소를 채워야 합니다.
이 릴리스의 WebSphere Application Server에서 새로운 기능인 영역 구성 설정 관리 콘솔 페이지의 새로운 선택란(모델에 글로벌 스키마 사용)은 여러 보안 도메인 환경에서 데이터 모델의 글로벌 스키마 옵션을 설정합니다. 글로벌 스키마는 관리 도메인의 스키마를 가리킵니다.
둘 이상의 사용자 레지스트리가 프로세스에 있는 경우 “UserRegistry”를 검색 이름으로 사용하는 이름 지정 검색은 사용자 애플리케이션에서 사용하는 사용자 레지스트리를 리턴합니다. 관리 애플리케이션에서 사용하는 사용자 레지스트리는 검색 이름 “AdminUserRegistry”에 의해 바인드됩니다.
교차 범주 통신에 설명된 것처럼 한 범주의 애플리케이션이 LTPA 토큰을 사용하여 다른 범주의 애플리케이션과 통신하는 경우 범주가 신뢰되어야 합니다. 신뢰 관계는 사용자 레지스트리 패널에 있는 신뢰 인증 영역 – – 인바운드 링크를 사용하거나 addTrustedRealms 명령을 사용하여 설정할 수 있습니다. 사용자는 여어 범주 사이에서 신뢰를 설정할 수 있습니다. 한 범주에 로그인된 사용자는 다른 범주의 자원에 액세스할 수 있습니다. 두 범주 사이에 신뢰가 설정되지 않은 경우 LTPA 토큰 유효성 검증이 실패합니다.
참고: web.xml 파일에 사용된 범주 이름은 사용자 레지스트리 범주와 관련이 없습니다. - 신뢰 연관:
도메인 레벨에서 TAI(Trust Association Interceptor)를 구성하는 경우 편의상 글로벌 레벨에서 구성된 인터셉터가 도메인 레벨로 복사됩니다. 필요에 따라 도메인 레벨에서 인터셉터 목록을 수정할 수 있습니다. 도메인 레벨에서 사용될 인터셉터만 구성하십시오.
Tivoli Access Manager의 TAI(Trust Association Interceptor)는 글로벌 레벨에서만 구성할 수 있습니다. 도메인 구성도 TAI를 사용할 수 있으나 TAI(Trust Association Interceptor)의 다른 버전을 보유할 수 없습니다. 한 개의 Tivoli Access Manager의 TAI(Trust Association Interceptor)만 셀에 있을 수 있습니다.
- SPNEGO 웹 인증:
웹 자원 인증을 위해 SPNEGO를 구성할 수 있는 SPNEGO 웹 인증은 도메인 레벨에서 구성할 수 있습니다.
참고: WebSphere Application Server 버전 6.1에서는 SPNEGO(Simple and Protected GSS-API Negotiation Mechanism)를 사용하여 보안 자원에 대한 HTTP 요청을 안전하게 조정 및 인증하는 TAI가 도입되었습니다. WebSphere Application Server 7.0에서는 이 기능이 더 이상 사용되지 않습니다. SPNEGO 웹 인증을 사용하면 SPNEGO 필터를 동적으로 다시 로드하고 애플리케이션 로그인 메소드로의 대체를 사용할 수 있습니다. - RMI/IIOP 보안(CSIv2):
RMI/IIOP 보안 속성은 CSIv2(Common Secure Interoperability version 2) 프로토콜 특성을 참조합니다. 도메인 레벨에서 이러한 속성을 구성하면 편의상 글로벌 레벨에서 RMI/IIOP 보안 구성이 복사됩니다.
도메인 레벨에서는 다르도록 속성을 변경할 수 있습니다. CSIv2 인바운드 통신에 대한 전송 계층 설정은 글로벌 레벨과 도메인 레벨에서 동일해야 합니다. 설정이 다른 경우 프로세스의 모든 애플리케이션에 도메인 레벨 속성이 적용됩니다.
프로세스가 범주가 다른 프로세스와 통신하는 경우 다운스트림 서버가 아웃바운드 신뢰 범주 목록에 나열되지 않는 경우 LTPA 인증 및 전파 토큰이 다운스트림 서버로 전파되지 않습니다. 이 작업은 CSIv2 – 아웃바운드 통신 패널에 있는 신뢰 인증 영역 – 아웃바운드 링크를 사용하거나 addTrustedRealms 명령 태스크를 사용하여 수행합니다. 자세한 정보는 교차 범주 통신의 내용을 참조하십시오.
- JAAS(Java Authentication
and Authorization Service):
JAAS 애플리케이션 로그인, JAAS 시스템 로그인 및 JAAS J2C 인증 데이터 별명은 모두 도메인 레벨에서 구성할 수 있습니다. 기본적으로 시스템의 모든 애플리케이션은 글로벌 레벨에 구성된 JAAS 로그인에 대한 액세스 권한이 있습니다. 보안 런타임은 도메인 레벨의 JAAS 로그인을 먼저 확인합니다. 찾지 못하는 경우 글로벌 보안 구성에서 확인합니다. 보안 도메인의 애플리케이션에 독점적으로 사용되는 로그인을 지정해야 하는 경우에만 도메인에서 이러한 JAAS 로그인을 구성하십시오.
JAAS 및 사용자 정의 특성만 글로벌 속성이 도메인에 대해 사용자 정의되어도 사용자 애플리케이션에서 계속 사용될 수 있습니다.
- JASPI(Java Authentication
SPI)
Java Authentication SPI(JASPI) 제공자에 대한 구성 설정과 도메인 레벨에서 적용되는 연관된 인증 모듈을 지정합니다.
JASPI 인증 제공자를 작성하거나 편집하려면 제공자를 선택하십시오.
참고: JASPI 인증 제공자는 도메인 레벨에서 구성된 제공자로 사용 가능하도록 설정할 수 있습니다. 기본적으로, 시스템의 모든 애플리케이션에는 글로벌 레벨에서 구성된 JASPI 인증 제공자에 대한 액세스 권한이 있습니다. 보안 런타임은 먼저 도메인 레벨에서 JASPI 인증 제공자를 확인합니다. 찾지 못하는 경우 글로벌 보안 구성에서 확인합니다. 해당 보안 도메인의 애플리케이션에서 제공자를 독점적으로 사용할 경우에만 도메인에서 JASPI 인증 제공자를 구성합니다. - 인증 메커니즘 속성:
도메인 레벨에 적용되어야 하는 다양한 캐시 설정을 지정합니다.
- 인증 캐시 설정 - 인증 캐시 설정을 지정하는 데 사용됩니다. 이 패널에서 지정된 구성은 이 도메인에만 적용됩니다.
- LTPA 제한시간 - 다른 LTPA 제한시간 값을 도메인 레벨에 구성할 수 있습니다. 기본 제한시간 값은 120분으로, 글로벌 레벨에서 설정되었습니다. LTPA 제한시간이 도메인 레벨에 설정되면 사용자 애플리케이션에 액세스할 때 보안 도메인에 작성되는 토큰이 모두 이 만기 시간으로 작성됩니다.
- 범주 규정 사용자 이름 사용 - 이 선택사항을 사용하는 경우 getUserPrincipal( ) 같은 메소드에서 리턴되는 사용자 이름은 보안 도메인의 애플리케이션에서 사용하는 보안 범주(사용자 레지스트리)로 규정됩니다.
- 권한 제공자:
외부 써드파티 JACC(Java Authorization Contract for Containers) 제공자는 도메인 레벨에서 구성할 수 있습니다. Tivoli Access Manager의 JACC 제공자는 글로벌 레벨에서만 구성할 수 있습니다. 보안 도메인은 권한 제공자를 다른 JACC 제공자로 대체하지 않은 경우에도 계속 사용할 수 있습니다.
JACC 속성(예: 정책 오브젝트)은 JVM 레벨에 기반합니다. 이것은 JVM 프로세스에는 한 개의 JACC 정책 오브젝트만 있을 수 있음을 의미합니다. 그러나 구성된 JACC 제공자가 여러 개이면 배치 관리자 프로세스는 애플리케이션 이름을 기준으로 애플리케이션의 권한 정책을 각 제공자에 전파해야 하므로 동일한 JVM에 있는 모든 제공자를 처리해야 합니다.
JACC 제공자가 권한 정책을 여러 제공자로 전파하는 작업을 처리할 수 있으면 JACC 제공자를 글로벌 레벨에 구성합니다. 이 경우, 애플리케이션을 설치할 때 배치 관리자 프로세스에서 이 JACC 제공자가 호출되며, 이 JACC 제공자가 contextID에 전달된 애플리케이션 이름을 기준으로 해당 정보를 JACC 제공자에 전파하는 작업을 책임집니다.
이러한 결과를 얻을 수 있는 또 다른 방법은 사용자 정의 특성 com.ibm.websphere.security.allowMultipleJaccProviders=true를 글로벌 보안 레벨에서 설정하는 것입니다. 이 특성이 설정되면, WebSphere Application Server가 애플리케이션이 설치된 대상 서버에 해당하는 도메인과 연관된 JACC 제공자에 권한 정책 정보를 전파합니다. 관리 서버는 여러 JACC 제공자를 호스팅하지 않으므로 이 특성은 배치 관리자 프로세스에만 사용됩니다.
보안 도메인 레벨에서 추가로 구성할 수 있는 SAF 권한 옵션은 다음과 같습니다.
- 인증되지 않은 사용자 ID
- SAF 프로파일 맵퍼
- SAF 위임 사용 여부
- APPL 프로파일을 사용한 WebSphere Application Server 액세스 제한 여부
- 권한 실패 메시지의 억제 여부
- SMF 감사 레코드 계획
- SAF 프로파일 접두부
CBIND 검사는 관리 조작으로 간주되므로, 검사할 CBIND 자원의 이름을 판별하는 경우 지정된 SAF 프로파일 접두부의 글로벌 레벨 값이 사용됩니다(예: CB.BIND.<cluster_name 또는 SAF_profile_prefix>).
SAF 권한 옵션에 대한 자세한 정보는 z/OS SAF(System Authorization Facility) 권한의 내용을 참조하십시오.
- 사용자 정의 특성:
사용자 정의 특성을 도메인 레벨에서 설정하십시오. 이때 이 특성은 새로운 특성이거나 글로벌 레벨의 특성과 다릅니다. 기본적으로 셀의 모든 애플리케이션이 글로벌 보안 구성의 모든 사용자 정의 특성에 액세스할 수 있습니다. 보안 런타임 코드는 도메인 레벨의 사용자 정의 특성을 먼저 확인합니다. 찾지 못하는 경우 글로벌 보안 구성에서 사용자 정의 특성을 가져오려고 시도합니다.
JAAS 및 사용자 정의 특성만 글로벌 속성이 도메인에 대해 사용자 정의되어도 사용자 애플리케이션에서 계속 사용될 수 있습니다.
보안 도메인을 사용하는 경우의 클라이언트 및 애플리케이션 보안 프로그래밍 모델
EJB에 액세스하는 클라이언트 역할을 수행하는 Java 클라이언트 또는 애플리케이션은 일반적으로 네이밍 검색을 먼저 수행합니다. 관리 및 사용자 애플리케이션 모두에서 사용하는 네이밍 자원은 관리 자원으로 간주됩니다. 글로벌 보안 구성 정보로 보호 설정되어 있습니다. 글로벌 보안이 하나의 범주(사용자 레지스트리)를 사용하고 도메인이 다른 범주를 사용하는 다중 도메인 설정에서는 Java 클라이언트가 두 개의 다른 범주에 대해 인증해야 합니다. 글로벌 보안 구성의 범주에 대한 첫 번째 인증은 네이밍 조작에 성공하는 데 필수이며 두 번째 인증은 다른 범주를 사용하는 EJB에 액세스하는 데 필수입니다.
CosNamingRead 역할은 모든 네이밍 읽기 조작을 보호합니다. 이 역할은 일반적으로 Everyone 특별 주제에 지정됩니다. 이는 유효한지 여부와 상관없이 모든 사용자가 네임스페이스를 검색할 수 있음을 의미합니다. 다중 도메인이 정의된 경우 CosNamingRead 역할에 Everyone 특별 주제가 포함되어 있으면 클라이언트 측 보안 런타임 코드가 로그인 요청 프롬프트를 표시하지 않습니다. 대신, UNAUTHENTICATED 주제를 사용하여 네이밍 조작에 액세스합니다. 네이밍 검색 조작이 완료되면 클라이언트가 EJB에 액세스하려고 시도하는 경우 로그인 패널이 포함된 프롬프트가 표시되며 해당 EJB 애플리케이션이 현재 사용하는 범주(즉, 도메인에서 사용되는 범주)를 나타냅니다. 그러면 클라이언트가 해당 범주에 적합한 사용자 신임 정보를 제공하고 EJB에 액세스할 수 있습니다. 이러한 로직은 로그인 소스가 prompt로 설정된 경우뿐만 아니라 properties 및 stdin를 비롯한 로그인 소스의 모든 변형에 적용됩니다.
Everyone 특별 주제가 CosNamingRead 역할에서 제거되면 프롬프트가 두 번 표시됩니다. 로그인 소스가 properties인 경우, $WAS_HOME/profiles/$ProfileName/properties/sas.client.props 파일의 com.ibm.CORBA.loginRealm 특성을 주석 해제하고 구분 기호로 “|”를 사용하여 해당 영역을 추가할 수 있습니다. com.ibm.CORBA.loginUserid 및 com.ibm.CORBA.loginPassword 특성에 각각 해당 사용자 및 비밀번호도 입력해야 합니다. Java 클라이언트 코드에서 프로그램 로그온을 사용하는 경우 다른 사용자 신임 정보를 사용하여 두 번 인증해야 합니다. 한 번은 EJB에 대해 네이밍 검색을 수행하기 전이며(사용자가 글로벌 영역에 있어야 함) 그 다음은 EJB에서 메소드를 호출하기 전입니다(사용자가 EJB 도메인의 영역에 있어야 함).
z/OS 보안 서버에 정의된
CosNamingRead 역할은 SAF 권한이 사용 가능한 경우에도 이름 지정 읽기 조작이 다중 보안 도메인 환경에서
보호되는지 여부를 판별하는 데 참조되지 않습니다. admin-authz.xml
파일에 있는 설정이 대신 사용됩니다. 또는 사용자 정의 특성 com.ibm.security.multiDomain.setNamingReadUnprotected를
사용하여 네이밍 읽기 조작이 보호되는지 여부를 제어할 수 있습니다. 이 특성은
사용되는 권한 제공자와 상관없이 CosNamingRead 역할에 지정된 사항을
대체합니다.
일반적으로 Java 클라이언트가 여러 다양한 범주에 인증해야 하는 경우 모든 해당 범주에 신임 정보를 제공해야 합니다. 로그인 소스가 prompt 또는 stdin인 경우 범주마다 한 번씩 여러 번 로그인 요청 프롬프트가 표시됩니다. 로그인 소스가 properties로 설정되어 있는 경우 sas.client.props 파일(또는 관련 파일)에 있는 해당 특성을 사용하여 다른 범주에 인증합니다.
특정 시나리오에서는 클라이언트가 동일한 범주에 대해 여러 번 호출를 수행할 수도 있습니다. 예를 들어, Java 클라이언트는 realm1을 사용하여 자원에 액세스한 후 realm2를 사용하여 자원에 액세스하고 realm1의 자원으로 다시 돌아와 액세스할 수 있습니다. 이 경우 클라이언트에 프롬프트가 세 번 표시됩니다. 첫 번째는 realm1에 대해, 두 번째는 realm2에 대해 그리고 마지막으로 realm1에 대해 다시 표시됩니다.
기본적으로 범주에서 로그인하는 데 사용되는 주제는 클라이언트 측 코드로 캐시되지 않습니다. 이러한 시나리오가 있고 클라이언트가 범주를 기반으로 주제(Subject)를 캐시하도록 하려면 sas.client.props 파일에 있는 com.ibm.CSI.isRealmSubjectLookupEnabled 특성을 true로 설정하십시오. com.ibm.CSI.isRealmSubjectLookupEnabled 특성이 설정되면 클라이언트 코드가 범주 이름을 기반으로 주제(Subject)를 캐시합니다. 다음 번 Java 클라이언트가 이 범주에 인증해야 하는 경우에는 해당 캐시를 찾아 주제를 가져오고 클라이언트에 프롬프트가 표시되지 않습니다. 또한 com.ibm.CSI.isRealmSubjectLookupEnabled 특성이 설정된 경우 처음 로그인된 동일한 주제(Subject)가 후속 로그인에 사용됩니다. 주제(Subject) 정보를 변경해야 하는 경우 이 특성이 설정되어 있지 않아야 합니다.
클라이언트가 프로그램 로그인을 수행하는 경우 인증해야 하는 사용자 및 비밀번호와 함께 범주를 전달할 수 있습니다. 이 경우 sas.client.props 파일에 있는 com.ibm.CORBA.validateBasicAuth 특성이 true(기본값)로 설정되면 범주 이름과 일치하는 레지스트리가 로그인에 사용됩니다. 해당 범주는 인증이 발생하는 프로세스에서 지원되어야 합니다.
WSLogin JAAS 구성을 사용하는 경우에도 범주 이름을 콜백 핸들러에 전달하려면 $WAS_HOME/profiles/$ProfileName/properties에 있는 wsjaas_client.config 파일의 use_realm_callback 옵션을 설정해야 합니다. 이름 서버에 다른 제공자 URL을 지정하려면 use_appcontext_callback 옵션을 설정하고 해시 맵의 제공자 URL 특성을 WSLogin에 전달하십시오.
범주 이름을 모르는 경우 <default>를 범주 이름으로 사용하십시오. 애플리케이션 범주에 대해 인증이 수행됩니다. 네이밍 읽기 조작에 Everyone 특수 주제(Subject)가 지정되지 않은 경우 검색 조작에 성공하려면 관리 애플리케이션이 사용하는 범주(글로벌 보안 구성에 사용된 레지스트리) 및 해당 레지스트리에 적합한 사용자와 비밀번호 정보를 제공해야 합니다.
검색 조작 성공 후 애플리케이션에 사용된 레지스트리에 애플리케이션 범주(또는 <default>)와 적절한 사용자의 사용자 및 비밀번호 정보를 제공하여 또 다른 프로그램 로그인을 수행하십시오. 로그인 소스가 prompt인 경우와 비슷합니다. 인증은 두 번 수행해야 합니다. 한 번은 글로벌 보안 구성에 사용된 레지스트리(네이밍 검색 조작의 경우)에 대해 수행하고 또 한번은 EJB에 액세스하는 애플리케이션에 사용된 레지스트리에 대해 수행합니다.
$WAS_HOME/profiles/$ProfileName/properties/sas.client.props 파일의 com.ibm.CORBA.validateBasicAuth가 false로 설정된 경우 프로그램 로그인에서는 검색 및 EJB 조작 모두에 대해 <default>를 범주 이름으로 사용할 수 있습니다. 자원이 서버 측에서 액세스되는 경우에만 실제 인증이 발생하며 이 경우 액세스되는 자원을 기반으로 범주가 계산됩니다.
WebSphere Application 버전 7.0에서 시작하는 새 보안 도메인 지원으로 현재 애플리케이션 보안 프로그래밍 모델이 변경되지는 않습니다. 그러나 다음과 같이 더 많은 기능 및 유연성을 제공합니다.
- 사용자 애플리케이션은 여전히 “UserRegistry”에 대한 이름 지정 검색을 사용하여 사용자 레지스트리 오브젝트를 찾을 수 있습니다. 관리 애플리케이션에서 사용되는 레지스트리 오브젝트의 경우 “AdminUserRegistry”에 대한 이름 지정 검색을 사용할 수 있습니다.
- 다중 도메인 설정에서 JAAS 로그인 구성의 애플리케이션 사용법이 변경되지 않습니다. 그러나 애플리케이션이 도메인 레벨에서 지정된 JAAS 구성을 참조해야 하는 경우 해당 애플리케이션의 관리자 및 배치자는 해당 애플리케이션에서 요구하는 JAAS 구성으로 이 도메인이 구성되어 있는지 확인해야 합니다.
- 애플리케이션이 다른 범주를 사용하는 다른 애플리케이션과 통신해야 하는 경우 LTPA 토큰을 사용할 때 인바운드 및 아웃바운드 통신 모두에 대해 신뢰 관계를 설정해야 합니다. 자세한 정보는 교차 범주 통신의 내용을 참조하십시오.
- 애플리케이션에 프로그램 로그인을 사용할 때 애플리케이션에 사용된 범주에 로그인하려는 경우 범주 이름으로 <default>를 사용하거나 애플리케이션이 사용하는 범주 이름을 제공하십시오. 글로벌 범주에 로그인해야 하는 경우 글로벌 범주 이름을 제공해야 합니다. 다른 범주를 제공하는 경우 기본 인증 주제만 작성됩니다. 요청이 실제로 해당 범주를 호스트하는 서버로 이동하는 경우 해당 서버가 범주를 호스트하면 사용자의 실제 인증이 발생합니다. 서버가 범주를 호스트하지 않으면 로그인이 실패합니다.
다중 도메인 구성의 애플리케이션 배치
다중 도메인 설정에서 애플리케이션을 배치하는 경우 애플리케이션의 모든 모듈이 동일한 보안 도메인에 속하는 서버 또는 클러스터에 설치되어야 합니다. 그렇지 않은 경우 이러한 보안 도메인에 구성된 보안 속성에 따라 불일치 작동이 발생할 수 있습니다. 예를 들어, 도메인에 다른 사용자 레지스트리가 포함되어 있는 경우 사용자 및 그룹 정보가 다를 수 있고 이로 인해 모듈에 액세스할 때 불일치 작동이 발생할 수 있습니다. 또 다른 예는 JAAS 데이터가 보안 도메인과 다른 경우입니다. JAAS 구성은 애플리케이션의 일부 모듈에서만 액세스됩니다. 사용자 레지스트리, JAAS 로그인 구성, J2C 인증 데이터 및 권한 같은 속성을 처리하는 경우 보안 런타임 코드 및 명령 태스크는 애플리케이션과 연관된 하나의 도메인에 종속됩니다.
애플리케이션이 여러 도메인에 배치되는 경우 대부분 애플리케이션 배치에 실패합니다. 그러나 서버 레벨에서 소수의 속성만 지원한 WebSphere Application Server의 이전 릴리스에서는 가능하므로, 배치 도구는 먼저 도메인에 구성된 속성에 대해 확인합니다. 도메인의 속성이 이전 릴리스에서 지원되는 속성과 동일한 경우 관리 콘솔은 다중 보안 도메인에서 애플리케이션 모듈을 배치할 것인지 사용자에게 확인을 요청합니다. 여러 도메인에서 애플리케이션을 배치하는 데 대한 절대 요구사항이 없는 경우 배치를 중지하고 동일한 보안 도메인의 서버 및 클러스터를 선택하십시오.
교차 범주 통신
애플리케이션이 RMI/IIOP 프로토콜을 사용하여 통신하며 LTPA가 인증 메커니즘인 경우 LTPA 토큰이 관련된 서버 사이에서 전달됩니다. LTPA 토큰에는 프론트 엔드 애플리케이션에 로그인된 사용자의 범주 규정 uniqueId(또는 accessId)가 포함되어 있습니다. 이 토큰이 다운스트림 서버에 수신되면 해당 토큰을 복호화하려고 시도합니다. LTPA 키가 두 개의 서버 사이에서 공유되는 경우 복호화에 성공하면 사용자의 accessId를 토큰에서 가져올 수 있습니다. accessId의 범주는 애플리케이션에서 사용되는 현재 범주를 사용하여 확인됩니다. 범주가 일치하면 LTPA 토큰 유효성 검증이 성공하고 권한 부여가 계속 진행됩니다. 범주가 일치하지 않으면 외부 범주의 사용자가 애플리케이션의 현재 범주에서 유효성 검증될 수 없으므로 토큰 유효성 검증이 실패합니다. RMI/IIOP 및 LTPA 인증 메커니즘을 사용하면 애플리케이션이 서로 통신하지 않는다고 알려져 있는 경우 더 이상 아무것도 수행할 필요가 없습니다.
RMI/IIOP 및 LTPA 토근을 사용하는 경우 교차 범주 통신이 성공하도록 하려면 먼저 인바운드 및 아웃바운드 통신 모두에 대해 관련 범주 사이에서 신뢰를 설정해야 합니다.
요청을 시작하는 서버의 경우 신뢰하여 토큰을 전송할 수 있는 범주가 해당 범주에 포함되어 있어야 합니다. outboundTrustedRealms라고 합니다. 요청을 수신하는 서버의 경우 해당 범주가 LTPA 토큰을 수신할 수 있는 범주를 신뢰해야 합니다. inboundTrustedRealms라고 합니다.
아웃바운드 신뢰 영역은 –communicationType 옵션이 outbound로 설정된 addTrustedRealms 명령을 사용하여 설정할 수 있습니다. 관리 콘솔에서 CSIv2 아웃바운드 통신 패널의 신뢰 인증 범주 - 아웃바운드를 클릭하여 설정할 수도 있습니다.
인바운드 신뢰 영역은 –communicationType 옵션이 inbound로 설정된 동일한 addTrustedRealms 명령 태스크를 사용하여 설정할 수 있습니다. 관리 콘솔을 사용하여 설정할 수도 있습니다.
아래 그림은 RMI/IIOP를 사용하는 다른 사용자 범주(레지스트리)가 사용되는 애플리케이션 사이의 통신을 보여 줍니다. 이 예제에서 애플리케이션 app1(예: 서블릿)은 realm1 사용자 레지스트리를 사용하도록 구성됩니다. app2 애플리케이션(예: EJB)은 realm2 사용자 레지스트리를 사용하도록 구성됩니다. 사용자(user1)가 처음에 app1의 서블릿에 로그인하면 app2의 EJB에 액세스하려고 시도합니다. 다음 사항을 설정해야 합니다.
- Domain1에서 realm1은 아웃바운드 통신에 대해 realm2를 신뢰해야 합니다.
- Domain2에서 realm2는 인바운드 통신에 대해 realm1을 신뢰해야 합니다.
- user1의 accessId가 app2의 권한 테이블에서 구성되어야 합니다.
user1의 accessId가 들어 있는 LTPA 토큰을 app2에서 수신하면 토큰을 복호화합니다. 두 서버 모두 동일한 LTPA 키를 공유합니다. 그런 다음, LTPA 토큰은 외부 범주가 신뢰 범주인지 확인하고 user1의 accessId를 기반으로 권한 부여를 수행합니다. 보안 속성 전파가 사용 불가능하게 설정되지 않은 경우 user1의 그룹 정보도 app2로 전파됩니다. 권한 테이블에 그룹 정보가 포함되어 있는 경우 그룹이 권한 검사에 사용될 수 있습니다. 개별 사용자 및 그룹을 권한 테이블에 추가하지 않고 특별 주제인 AllAuthenticatedInTrustedRealms를 역할에 연관시킬 수 있습니다.
이전 예에서 애플리케이션이 다른 셀에 전개되는 경우 사용자는 다음을 수행해야 합니다.
- LTPA 키를 셀 사이에서 공유하십시오.
- wsadmin 유틸리티를 사용하여 외부 사용자 및 그룹 accessId로 app2의 권한 테이블을 업데이트하십시오. 관리 콘솔에는 셀 범위 외부에 있는 범주에 대한 액세스 권한이 없습니다.

범주 사이에 신뢰가 설정되어 서버에서 LTPA 토큰을 수신하고 토큰이 복호화되면 외부 범주가 해당 인바운드 신뢰 범주 목록에 있는지 확인합니다. 범주가 신뢰되는 경우 인증이 성공합니다. 그러나 외부 범주이므로 사용자에 대한 정보를 수집하기 위해 사용자 레지스트리로 이동하여 검색하지 않습니다. LTPA 토큰에 있는 모든 정보가 사용자 권한 부여에 사용됩니다.
LTPA 토큰의 유일한 정보는 사용자의 고유 ID입니다. 사용자의 이러한 고유 ID는 이 애플리케이션의 권한 테이블에 있어야 합니다. 있는 경우 권한 부여에 성공합니다. 그러나 속성 전파를 사용하는 경우 사용자의 추가 권한 속성(이 사용자가 속한 그룹)이 시작 서버에서 수신 서버로 전송됩니다. 이러한 추가 속성은 액세스 결정을 내리는 데 사용됩니다. 그룹 정보가 전파 토큰에 있는 경우 권한 결정을 내리는 데 사용됩니다.
앞에 언급된 것처럼 신뢰 범주의 사용자 및/또는 그룹에 대한 정보는 수신 애플리케이션의 권한 테이블에 있어야 합니다. 특히, 사용자 및/또는 그룹의 accessId는 애플리케이션의 바인딩 파일에 있어야 합니다. 애플리케이션 배치 시의 상황은 이와 같아야 합니다. 관리 콘솔에서 애플리케이션이 도메인에 배치되는 경우 해당 신뢰 범주에서 권한 테이블로 사용자 및 그룹의 accessId를 추가할 수 있습니다.
개별 사용자 및 그룹을 추가하지 않고 특별 주제인 AllAuthenticatedInTrustedRealms를 역할에 연관시킬 수 있는 옵션이 사용자에게 제공됩니다. 이는 현재 지원되는 AllAuthenticated 특별 주제와 비슷합니다. 차이점은 AllAuthenticated 특별 주제는 애플리케이션과 동일한 범주에서 사용자를 참조하지만 AllAuthenticatedInTrustedRealms 특별 주제는 신뢰 범주 및 애플리케이션 범주의 모든 사용자에 적용된다는 점입니다.
$AdminApp 설치 스크립트를 사용하여 accessId를 연관시킬 수 있습니다. accessId는 고유 형식을 사용하므로 displayAccessIds가 true로 설정된 명령 태스크 listRegistryUsers를 사용하십시오. 이 필드에 유효하지 않은 이름이나 형식이 입력되면 권한 부여에 실패합니다.
신뢰 범주의 사용자 및 그룹 정보는 배치 관리자를 통해 가져옵니다. 모든 도메인의 모든 사용자 레지스트리 구성 모두에 대해 액세스 권한이 있기 때문입니다. 그러나 특정 상황에서는 사용자 및 그룹 정보를 가져오는 것이 불가능합니다.
예를 들어, 외부 노드에 호스트되는 서버가 localOS를 해당 도메인의 레지스트리로 사용하는 경우 동일한 운영 체제 설정에서 실행되지 않으면 배치 관리자가 사용자 및 그룹 정보를 가져올 수 없습니다. 이러한 정보를 가져오려면 외부 운영 체제에 연결되어 있어야 합니다. 이는 해당 도메인과 연관된 서버에서 레지스트리를 직접 호출하여 수행할 수 있습니다. 이 작업을 수행하려면 도메인과 연관된 서버가 시작되어야 합니다. 또한 최상위 레벨 보안 사용자 정의 특성에서 com.ibm.websphere.allowRegistryLookupOnProcess 특성을 true로 설정해야 합니다. 이 특성이 설정되면 배치 관리자 코드가 보안 도메인과 연관된 서버 중 하나를 검색하여 직접 사용자 및 그룹 정보를 가져옵니다. 서버 중 하나에서 MBean을 호출하여 수행할 수 있습니다.
해당 도메인을 사용하는 서버 중 하나에 있는 MBean에 액세스할 수 없는 경우 각 사용자 및 그룹에 대해 수동으로 사용자 및 accessId 정보를 입력할 수 있는 패널을 관리 콘솔에서 표시합니다. 이 필드에 올바른 accessId 형식을 입력하는 것이 중요합니다. 사용자의 accessId 형식은 user:realmName/userUniqueId입니다. realmName은 사용자가 있는 범주의 이름이며 userUniqueId는 사용되는 레지스트리에 따라 사용자를 나타내는 uniqueId입니다.
예를 들어, LDAP의 경우 uniqueUserId는 식별 이름(DN)이고, Windows localOS 레지스트리의 경우 사용자의 SID입니다. Unix 플랫폼의 경우 UID입니다. 사용자 정의 레지스트리의 경우 구현에 따라 다릅니다.
마찬가지로 그룹의 경우 accessId 형식은 group:realmName/groupUniqueId입니다. 앞에 언급된 것처럼 원하는 도메인 또는 영역의 올바른 형식을 가져오려면 –displayAccessIds 옵션이 true로 설정된 listRegistryUsers 및 listRegistryGroups 명령을 사용하십시오.
신뢰 범주의 사용자 및 그룹이나 AllAuthenticatedInTrustedRealms 특별 주제가 애플리케이션의 권한 테이블에 추가되면 해당 신뢰 범주를 사용하는 다른 애플리케이션의 요청을 수락할 수 있습니다. 수신 서버의 LTPA 토큰 유효성 검증에서는 먼저 범주가 신뢰되는지를 확인합니다. 그런 다음 권한 엔진에서 외부 사용자 및/또는 그룹이나 AllAuthenticatedInTrustedRealms 특별 주제에 자원 액세스에 필요한 역할로 액세스 권한이 부여되어 있는지 확인합니다. true인 경우 액세스 권한이 부여된 것입니다.
교차 범주 통신은 WebSphere 내장 권한을 사용하는 경우에만 적용 가능합니다. z/OS용 SAF를 비롯한 다른 권한 엔진을 사용하는 경우 외부 사용자를 자체 저장소의 사용자에 맵핑하는 사용자 정의 로그인 모듈을 구현하여 교차 범주 권한 부여를 완료할 수 있습니다.
보안 도메인이 포함된 노드 연합
보안 도메인이 기본 버전으로 구성되고 셀에 연합되면 기본 버전에서 구성된 보안 도메인도 셀의 해당 서버에 대해 구성됩니다. 연합 전후 서버에서 동일한 도메인 보안 구성을 사용할 수 있습니다. 기본 서버가 셀로 연합되는 경우 보안 도메인에 지정된 자원은 셀 범위가 아닌 서버 범위여야 합니다.
기본 서버가 관리 에이전트 프로세스에 등록될 예정인 경우 기본 프로파일의 모든 서버가 이 보안 도메인을 사용하도록 하려는 경우 셀 범위를 자원으로 사용하십시오.
연합 중 기본의 보안 도메인이 이미 셀 레벨에 있는 경우 addNode 명령이 실패합니다. –excludesecuritydomains 옵션을 사용하면 연합 중에 보안 도메인이 포함되지 않도록 할 수 있습니다.
연합 노드가 셀에서 제거되면 해당 노드의 자원이 보안 도메인에서 제거되어야 합니다. 여러 노드 범위에 속하는 연관된 클러스터가 보안 도메인에 있는 경우 해당 노드가 제거되지 않습니다. 스크립트 명령 또는 관리 콘솔을 사용하여 보안 도메인 또는 사용되지 않는 도메인에서 항상 자원을 제거할 수 있습니다.
혼합 버전 환경의 보안 도메인
모든 노드가 최신 버전으로 마이그레이션되면 보안 도메인을 작성해야 합니다. 셀을 도메인과 연관시켜야 하는 경우 특히 그렇습니다. 혼합 버전 환경에서 보안 도메인을 작성하는 경우 다음 사항에 유의해야 합니다.
- 혼합 버전 설정에서 셀 범위 도메인이 작성되는 경우
PassThroughToGlobalSecurity 도메인이 자동으로 작성됩니다.
셀 범위 도메인 작성 시 모든 혼합 클러스터가 이 도메인에 지정됩니다. 이 PassThroughToGlobalSecurity
도메인은 속성이 추가될 수 없고 자원만 지정될 수 있다는 점에서 특별합니다.
PassThroughToGlobalSecurity 도메인에 지정된 모든 자원은 글로벌 보안 구성 정보를 사용합니다. 혼합 버전 설정의 노드가 최신 버전으로 마이그레이션될 때마다 이러한 노드의 서버 및 클러스터가 이 도메인에 추가됩니다. 이러한 노드에 있는 모든 서버 및 클러스터의 애플리케이션은 셀 범위 도메인을 사용하지 않습니다. 대신 마이그레이션 전후에 글로벌 보안 구성을 사용합니다.
이러한 서버에서 셀 범위 도메인을 사용해야 하는 경우 이 PassThroughToGlobalSecurity 도메인에서 해당 자원을 제거해야 합니다. 마이그레이션된 노드에 작성된 새 서버 및 클러스터는 PassThroughToGlobalSecurity 도메인이 아닌 셀 범위 도메인을 사용합니다. 결과적으로 혼합 서버 및 클러스터를 보유하며 이들 중 일부는 글로벌 보안 구성을 사용하고 일부는 셀 범위 도메인을 사용합니다.
- 셀 범위 도메인이 작성되면, 이전 버전의 클러스터 멤버를 WebSphere Application Server 버전 9.0 클러스터에 추가하는 작업이 제한됩니다. 이 조치를 통해 혼합 클러스터가 작성되기 때문입니다. WebSphere Application Server 버전 9.0 클러스터가 도메인과 연관되는 경우에도 이 제한이 적용됩니다. 이전 버전 클러스터 멤버가 이 클러스터에 추가됩니다. 이러한 제한은 보안 도메인을 혼합 클러스터에 연관시키지 못하도록 하기 위해 필요합니다.
- 가능하면, 모든 노드를 마이그레이션한 후 셀 규모 도메인을 작성해야 합니다. 이 경우 셀 범위 도메인은 셀의 일부가 아닌 전체 셀에 적용 가능합니다. 또한 PassThroughToGlobalSecurity 도메인을 작성할 필요가 없고 보안 도메인이 혼합 클러스터와 연관되는 상황도 발생하지 않습니다.
보안 도메인 수정
보안 도메인을 수정하려면 관리 콘솔 태스크 또는 스크립트 명령을 사용하십시오. 관리 태스크 및 스크립트 명령의 전체 목록은 이 문서의 맨 아래에 있는 "관련 태스크" 링크를 참조하십시오.
보안 도메인이 작성되고 범위 세트에 연관되면 이러한 새 도메인과 연관된 서버를 다시 시작해야 합니다. 다시 시작 후 새 도메인과 연관된 범위의 애플리케이션이 도메인에 정의된 보안 속성을 사용합니다.
도메인 속성에 대한 변경사항은 지정된 모든 범위를 다시 시작해야 합니다. 새 범위가 추가되면 해당 범위도 다시 시작되어야 합니다. 도메인 구성에 대한 수정 즉, 보안 속성 또는 범위에 대한 수정은 도메인 구성을 사용하는 애플리케이션에 영향을 줍니다.
기존 도메인에 수정을 수행하기 전에 다음과 같은 잠재적 영향을 고려하십시오. 예를 들어, 도메인에 구성된 사용자 레지스트리가 제거되고 서버가 다시 시작되는 경우 셀 범위 도메인의 사용자 레지스트리(정의되어 있는 경우) 또는 글로벌 보안 구성이 사용됩니다. 이는 애플리케이션 인증 및 권한에 영향을 줄 수 있습니다. 애플리케이션과 연관된 사용자 및 그룹은 더 이상 새 레지스트리에서 유효하지 않습니다. 또 다른 고려사항의 예로는 JAAS 구성이 도메인에서 제거되는 경우를 들 수 있습니다. 이러한 구성에 종속된 애플리케이션은 더 이상 JAAS 구성을 사용할 수 없습니다. 보안 구성이 변경될 때마다 애플리케이션에 영향을 줄 수 있으므로 모든 보안 구성 변경은 최대한 주의를 기울여 수행되어야 합니다.
![[z/OS]](../images/ngzos.gif)
혼합 릴리스 환경에 필수인 허용 PTF
WebSphere Application Server for z/OS의 이전 버전 IIOP 클라이언트가 다중 보안 도메인을 호스트하는 WebSphere Application Server 버전 9.0 for z/OS 애플리케이션 서버와 상호 운용하는 혼합 릴리스 환경에서는 허용 PTF가 필수입니다.
버전 9.0 이전 IIOP 클라이언트는 버전 9.0 애플리케이션 서버의 보안 도메인에서 IIOP 찾기를 수행하는 IIOP 찾기 처리 코드 업데이트가 필요합니다.
WebSphere Application Server for z/OS 5.1: W510246
WebSphere Application Server for z/OS v6.0: 602.29
WebSphere Application Server for z/OS v6.1: 610.17
이러한 요구사항은 다중 보안 도메인이 구성되고 사용되는 WebSphere for z/OS 애플리케이션 서버에 대해 요청을 호출하는 WebSphere for z/OS IIOP 클라이언트에만 적용됩니다.