다중 보안 도메인

보안 도메인이 유용한 이유

WebSphere 보안 도메인은 두 가지 주요 이점을 제공합니다.

이전 버전에서는 WebSphere Application Server, 모든 관리 및 사용자 애플리케이션은 대부분의 보안 속성을 공유합니다. 모든 관리 및 사용자 애플리케이션 WebSphere Application Server 기본적으로 전역 보안 속성을 사용합니다. 예를 들어, 글로벌 보안에 정의된 사용자 레지스트리는 셀에 있는 모든 애플리케이션의 사용자를 인증하는 데 사용됩니다.

이번 릴리스에서는 WebSphere Application Server 그러나 사용자 애플리케이션에 대해 글로벌 보안 속성이 아닌 여러 보안 속성을 사용하고, 달라야 하는 보안 속성에 대한 보안 도메인을 생성하고, 이를 해당 사용자 애플리케이션을 호스팅하는 서버 및 클러스터와 연결할 수 있습니다. 또한 보안 도메인을 셀과 연관시킬 수 있습니다. 셀의 모든 사용자 애플리케이션은 이전에 연관시킨 도메인이 없는 경우 해당 보안 도메인을 사용합니다. 그러나 관리 콘솔, 네이밍 자원 및 MBeans 같은 관리 애플리케이션의 경우 글로벌 보안 속성이 계속 필수입니다.

이전 릴리스에서 서버 수준 보안을 사용한 경우 WebSphere Application Server, 이제 더 유연하고 구성하기 쉽기 때문에 여러 보안 도메인을 사용해야 합니다.

이 릴리스에서는 서버 레벨 보안이 사용되지 않습니다. 읽다 글로벌 보안과 보안 도메인의 관계 자세한 내용은.

글로벌 보안 및 보안 도메인 사이의 관계

글로벌 보안은 모든 관리 기능과 사용자 애플리케이션의 기본 보안 구성에 적용됩니다. 보안 도메인은 사용자 애플리케이션에 대해 사용자 정의 구성을 정의하는 데 사용될 수 있습니다.

보안 도메인을 작성하려면 먼저 글로벌 보안 구성이 정의되어 있어야 합니다. 글로벌 보안 구성은 관리 콘솔, 네이밍 자원 및 Mbeans 같은 모든 관리 애플리케이션에서 사용됩니다. 보안 도메인이 구성되지 않은 경우 애플리케이션은 모두 글로벌 보안 구성의 정보를 사용합니다. Enterprise와 같은 사용자 애플리케이션 JavaBeans (EJB), 서블릿 및 관리 애플리케이션은 동일한 보안 구성을 사용합니다.

보안 도메인을 작성하여 범위와 연관시키는 경우 해당 범위에 있는 사용자 애플리케이션만 보안 도메인에 정의된 보안 속성을 사용합니다. 해당 범위에 있는 관리 애플리케이션 및 네이밍 조작은 글로벌 보안 구성을 사용합니다. 글로벌 레벨의 보안 특성과 달라야 하는 보안 특성을 도메인 레벨에서 정의하십시오. 정보가 공통인 경우 중복된 정보가 보안 도메인에 있을 필요는 없습니다. 도메인에서 누락된 모든 속성은 글로벌 구성에서 가져옵니다. 글로벌 보안 구성 데이터는 $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 버전 8.5 이다:

관리 콘솔의 보안 도메인 패널에는 이러한 보안 속성이 모두 표시됩니다.

도메인 수준에서 재정의할 수 없는 기타 잘 알려진 속성 중 일부는 다음과 같습니다. Kerberos, 감사, 웹 싱글 사인온(SSO) 및 TAM(Tivoli® Access Manager). SSL(Secure Sockets Layer) 속성은 이미 다양한 범위를 지원하지만 도메인 구성의 일부가 아닙니다. 도메인 레벨에서 지원되지 않는 모든 속성의 경우 도메인에 있는 사용자 애플리케이션이 글로벌 레벨에서 해당 구성을 공유합니다.

모든 새 보안 도메인 속성은 도메인에 지정된 사용자 애플리케이션에 의해 상속되는 해당 글로벌 보안 속성과 호환 가능해야 합니다. 사용자는 이러한 속성을 적극적으로 관리해야 합니다. 예를 들어, 도메인 레벨에서 JAAS 구성만 사용자 정의하는 경우 글로벌 레벨에서 구성된 사용자 레지스트리와 작동하는지 확인해야 합니다(사용자 레지스트리가 도메인 레벨에서 사용자 정의되지 않은 경우).

JAAS 및 사용자 정의 특성 외에는 글로벌 속성이 도메인에 대해 사용자 정의되면 사용자 애플리케이션에서 더 이상 사용되지 않습니다.

Tivoli Access Manager 클라이언트 런타임은 인증을 제공하는 데 사용됩니다(다음에서 사용). TrustAssociationInterceptor 그리고 PDLoginModule) 및 TAM 서버에 접속하여 인증(JACC에 사용됨)을 수행합니다. 셀의 모든 서버가 공유하는 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에 액세스하는 클라이언트 역할을 하는 Java 클라이언트 또는 애플리케이션은 일반적으로 이름 지정 조회를 먼저 수행합니다. 관리 및 사용자 애플리케이션 모두에서 사용하는 네이밍 자원은 관리 자원으로 간주됩니다. 글로벌 보안 구성 정보로 보호 설정되어 있습니다. 글로벌 보안이 하나의 영역(사용자 레지스트리)을 사용하고 도메인이 다른 영역을 사용하는 다중 도메인 설정에서 Java 클라이언트는 두 개의 다른 영역에 인증해야 합니다. 글로벌 보안 구성의 범주에 대한 첫 번째 인증은 네이밍 조작에 성공하는 데 필수이며 두 번째 인증은 다른 범주를 사용하는 EJB에 액세스하는 데 필수입니다.

CosNamingRead 역할은 모든 네이밍 읽기 조작을 보호합니다. 이 역할은 일반적으로 Everyone 특별 주제에 지정됩니다. 이는 유효한지 여부와 상관없이 모든 사용자가 네임스페이스를 검색할 수 있음을 의미합니다. 다중 도메인이 정의된 경우 CosNamingRead 역할에 Everyone 특별 주제가 포함되어 있으면 클라이언트 측 보안 런타임 코드가 로그인 요청 프롬프트를 표시하지 않습니다. 대신, UNAUTHENTICATED 주제를 사용하여 네이밍 조작에 액세스합니다. 네이밍 검색 조작이 완료되면 클라이언트가 EJB에 액세스하려고 시도하는 경우 로그인 패널이 포함된 프롬프트가 표시되며 해당 EJB 애플리케이션이 현재 사용하는 범주(즉, 도메인에서 사용되는 범주)를 나타냅니다. 그러면 클라이언트가 해당 범주에 적합한 사용자 신임 정보를 제공하고 EJB에 액세스할 수 있습니다. 이러한 로직은 로그인 소스가 prompt로 설정된 경우뿐만 아니라 properties 및 stdin를 비롯한 로그인 소스의 모든 변형에 적용됩니다.

Everyone 특별 주제가 CosNamingRead 역할에서 제거되면 프롬프트가 두 번 표시됩니다. 로그인 소스가 다음과 같은 경우properties , 주석 처리를 해제할 수 있습니다.com.ibm.CORBA.loginRealm 에 있는 재산$WAS_HOME/profiles/$ProfileName/properties/sas.client.props 파일을 만들고 "|"를 사용하여 적절한 영역을 추가합니다. 구분 기호로. com.ibm.CORBA.loginUserid 및 com.ibm.CORBA.loginPassword 특성에 각각 해당 사용자 및 비밀번호도 입력해야 합니다. Java 클라이언트 코드에서 프로그래밍 방식 로그온을 사용하는 경우 다른 사용자 자격 증명으로 두 번 인증해야 합니다. EJB에 대한 이름 지정 조회를 수행하기 전에 한 번(사용자는 전역 영역에 있어야 함), 나중에 EJB에서 메소드를 호출하기 전에(사용자는 EJB 도메인의 영역에 있어야 함)

일반적으로 Java 클라이언트가 여러 다른 영역에 인증해야 하는 경우 해당 모든 영역에 대한 자격 증명 정보를 제공해야 합니다. 로그인 소스가 prompt 또는 stdin인 경우 범주마다 한 번씩 여러 번 로그인 요청 프롬프트가 표시됩니다. 로그인 소스가 properties로 설정되어 있는 경우 sas.client.props 파일(또는 관련 파일)에 있는 해당 특성을 사용하여 다른 범주에 인증합니다.

특정 시나리오에서는 클라이언트가 동일한 범주에 대해 여러 번 호출를 수행할 수도 있습니다. 예를 들어, Java 클라이언트는 다음을 사용하여 리소스에 액세스할 수 있습니다.realm1 다음을 사용하여 리소스에 액세스합니다.realm2 , 그런 다음 다시 돌아와서 리소스에 액세스합니다.realm1 다시. 이 경우 클라이언트에 프롬프트가 세 번 표시됩니다. 첫 번째는 realm1에 대해, 두 번째는 realm2에 대해 그리고 마지막으로 realm1에 대해 다시 표시됩니다.

기본적으로 범주에서 로그인하는 데 사용되는 주제는 클라이언트 측 코드로 캐시되지 않습니다. 이 시나리오가 있고 클라이언트가 영역을 기반으로 주제를 캐시하도록 하려면com.ibm.CSI.isRealmSubjectLookupEnabled 재산 진실 에서sas.client.props 파일. com.ibm.CSI.isRealmSubjectLookupEnabled 특성이 설정되면 클라이언트 코드가 범주 이름을 기반으로 주제(Subject)를 캐시합니다. 다음 번에 Java 클라이언트가 이 영역에 인증해야 할 때 주제를 얻기 위해 캐시를 찾고 클라이언트에 메시지가 표시되지 않습니다. 또한 com.ibm.CSI.isRealmSubjectLookupEnabled 특성이 설정된 경우 처음 로그인된 동일한 주제(Subject)가 후속 로그인에 사용됩니다. 주제(Subject) 정보를 변경해야 하는 경우 이 특성이 설정되어 있지 않아야 합니다.

클라이언트가 프로그래밍 방식 로그인을 수행하는 경우 인증해야 하는 사용자 및 비밀번호와 함께 범주를 전달할 수 있습니다. 이 경우,com.ibm.CORBA.validateBasicAuth 속성은 다음과 같이 설정됩니다. 진실 (기본값)sas.client.props 파일에서 영역 이름과 일치하는 레지스트리가 로그인에 사용됩니다. 해당 범주는 인증이 발생하는 프로세스에서 지원되어야 합니다.

WSLogin을 사용하는 경우 JAAS 구성을 사용하려면 다음도 설정해야 합니다. use_realm_callback 옵션wsjaas_client.config 제출하다$WAS_HOME/profiles/$ProfileName/properties 콜백 핸들러에 전달될 영역 이름입니다. 이름 서버에 다른 제공자 URL을 지정하려면 use_appcontext_callback 옵션을 설정하고 해시 맵의 제공자 URL 특성을 WSLogin에 전달하십시오.

영역 이름을 모르는 경우 <를 사용하세요.default > 영역 이름으로. 애플리케이션 범주에 대해 인증이 수행됩니다. 네이밍 읽기 조작에 Everyone 특수 주제(Subject)가 지정되지 않은 경우 검색 조작에 성공하려면 관리 애플리케이션이 사용하는 범주(글로벌 보안 구성에 사용된 레지스트리) 및 해당 레지스트리에 적합한 사용자와 비밀번호 정보를 제공해야 합니다.

조회 작업이 성공하면 애플리케이션 영역(또는 <default >) 애플리케이션에서 사용하는 레지스트리의 해당 사용자에 대한 사용자 및 비밀번호 정보입니다. 로그인 소스가 prompt인 경우와 비슷합니다. 인증은 두 번 수행해야 합니다. 한 번은 글로벌 보안 구성에 사용된 레지스트리(네이밍 검색 조작의 경우)에 대해 수행하고 또 한번은 EJB에 액세스하는 애플리케이션에 사용된 레지스트리에 대해 수행합니다.

만약에com.ibm.CORBA.validateBasicAuth 로 설정되어 있습니다 거짓 에서$WAS_HOME/profiles/$ProfileName/properties/sas.client.props 파일을 삭제하면 프로그래밍 방식 로그인에서 <를 사용할 수 있습니다.default > 조회 및 EJB 작업 모두에 대한 영역 이름입니다. 자원이 서버 측에서 액세스되는 경우에만 실제 인증이 발생하며 이 경우 액세스되는 자원을 기반으로 범주가 계산됩니다.

새로운 보안 도메인 지원 시작 WebSphere 애플리케이션 버전 7.0 현재 애플리케이션 보안 프로그래밍 모델을 변경하지 않습니다. 그러나 다음과 같이 더 많은 기능 및 유연성을 제공합니다.

다중 도메인 구성의 애플리케이션 배치

다중 도메인 설정에서 애플리케이션을 배치하는 경우 애플리케이션의 모든 모듈이 동일한 보안 도메인에 속하는 서버 또는 클러스터에 설치되어야 합니다. 그렇지 않은 경우 이러한 보안 도메인에 구성된 보안 속성에 따라 불일치 작동이 발생할 수 있습니다. 예를 들어, 도메인에 다른 사용자 레지스트리가 포함되어 있는 경우 사용자 및 그룹 정보가 다를 수 있고 이로 인해 모듈에 액세스할 때 불일치 작동이 발생할 수 있습니다. 또 다른 예는 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 명령을 사용하여 설정할 수 있습니다. 다음을 클릭하여 관리 콘솔에서 설정할 수도 있습니다.Trusted authentication realms - outbound 에CSIv2 outbound communications 패널.

인바운드 신뢰 범주는 -communicationType 옵션이 inbound로 설정된 동일한 addTrustedRealms 명령 태스크를 사용하여 설정할 수 있습니다. 관리 콘솔을 사용하여 설정할 수도 있습니다.

아래 그림은 RMI/IIOP를 사용하는 다른 사용자 범주(레지스트리)가 사용되는 애플리케이션 사이의 통신을 보여 줍니다. 이 예에서는 애플리케이션app1 (예를 들어,servlet )는 다음을 사용하도록 구성됩니다.realm1 사용자 레지스트리. app2 애플리케이션(예: EJB)은 realm2 사용자 레지스트리를 사용하도록 구성됩니다. 사용자(user1)가 처음에 app1의 서블릿에 로그인하면 app2의 EJB에 액세스하려고 시도합니다. 다음 사항을 설정해야 합니다.

user1의 accessId가 들어 있는 LTPA 토큰을 app2에서 수신하면 토큰을 복호화합니다. 두 서버 모두 동일한 LTPA 키를 공유합니다. 그런 다음, LTPA 토큰은 외부 범주가 신뢰 범주인지 확인하고 user1의 accessId를 기반으로 권한 부여를 수행합니다. 보안 속성 전파가 사용 불가능하게 설정되지 않은 경우 user1의 그룹 정보도 app2로 전파됩니다. 권한 테이블에 그룹 정보가 포함되어 있는 경우 그룹이 권한 검사에 사용될 수 있습니다. 개별 사용자 및 그룹을 권한 테이블에 추가하지 않고 특별 주제인 AllAuthenticatedInTrustedRealms를 역할에 연관시킬 수 있습니다.

이전 예에서 애플리케이션이 다른 셀에 배치되는 경우 사용자는 다음을 수행해야 합니다.

범주 사이에 신뢰가 설정되어 서버에서 LTPA 토큰을 수신하고 토큰이 복호화되면 외부 범주가 해당 인바운드 신뢰 범주 목록에 있는지 확인합니다. 범주가 신뢰되는 경우 인증이 성공합니다. 그러나 외부 범주이므로 사용자에 대한 정보를 수집하기 위해 사용자 레지스트리로 이동하여 검색하지 않습니다. LTPA 토큰에 있는 모든 정보가 사용자 권한 부여에 사용됩니다.

LTPA 토큰의 유일한 정보는 사용자의 고유 ID입니다. 사용자의 이러한 고유 ID는 이 애플리케이션의 권한 테이블에 있어야 합니다. 있는 경우 권한 부여에 성공합니다. 그러나 속성 전파를 사용하는 경우 사용자의 추가 권한 속성(이 사용자가 속한 그룹)이 시작 서버에서 수신 서버로 전송됩니다. 이러한 추가 속성은 액세스 결정을 내리는 데 사용됩니다. 그룹 정보가 전파 토큰에 있는 경우 권한 결정을 내리는 데 사용됩니다.

앞에 언급된 것처럼 신뢰 범주의 사용자 및/또는 그룹에 대한 정보는 수신 애플리케이션의 권한 테이블에 있어야 합니다. 특히, 사용자 및/또는 그룹의 accessId는 애플리케이션의 바인딩 파일에 있어야 합니다. 애플리케이션 배치 시의 상황은 이와 같아야 합니다. 관리 콘솔에서 애플리케이션이 도메인에 배치되는 경우 해당 신뢰 범주에서 권한 테이블로 사용자 및 그룹의 accessId를 추가할 수 있습니다.

개별 사용자 및 그룹을 추가하지 않고 특별 주제인 AllAuthenticatedInTrustedRealms를 역할에 연관시킬 수 있는 옵션이 사용자에게 제공됩니다. 이는 현재 지원되는 AllAuthenticated 특별 주제와 비슷합니다. 차이점은 AllAuthenticated 특별 주제는 애플리케이션과 동일한 범주에서 사용자를 참조하지만 AllAuthenticatedInTrustedRealms 특별 주제는 신뢰 범주 및 애플리케이션 범주의 모든 사용자에 적용된다는 점입니다.

$AdminApp 설치 스크립트를 사용하여 accessId를 연관시킬 수 있습니다. 왜냐하면 accessId 고유한 형식을 사용하려면 명령 작업을 사용하세요.listRegistryUsers ~와 함께displayAccessIds 로 설정 진실. 이 필드에 유효하지 않은 이름이나 형식이 입력되면 권한 부여에 실패합니다.

신뢰 범주의 사용자 및 그룹 정보는 배치 관리자를 통해 가져옵니다. 모든 도메인의 모든 사용자 레지스트리 구성 모두에 대해 액세스 권한이 있기 때문입니다. 그러나 특정 상황에서는 사용자 및 그룹 정보를 가져오는 것이 불가능합니다.

예를 들어, 외부 노드에 호스트되는 서버가 localOS를 해당 도메인의 레지스트리로 사용하는 경우 동일한 운영 체제 설정에서 실행되지 않으면 배치 관리자가 사용자 및 그룹 정보를 가져올 수 없습니다. 이러한 정보를 가져오려면 외부 운영 체제에 연결되어 있어야 합니다. 이는 해당 도메인과 연관된 서버에서 레지스트리를 직접 호출하여 수행할 수 있습니다. 이 작업을 수행하려면 도메인과 연관된 서버가 시작되어야 합니다. 또한 최상위 레벨 보안 사용자 정의 특성에서 com.ibm.websphere.allowRegistryLookupOnProcess 특성을 true로 설정해야 합니다. 이 특성이 설정되면 배치 관리자 코드가 보안 도메인과 연관된 서버 중 하나를 검색하여 직접 사용자 및 그룹 정보를 가져옵니다. 서버 중 하나에서 MBean을 호출하여 수행할 수 있습니다.

해당 도메인을 사용하는 서버 중 하나에 있는 MBean에 액세스할 수 없는 경우 각 사용자 및 그룹에 대해 수동으로 사용자 및 accessId 정보를 입력할 수 있는 패널을 관리 콘솔에서 표시합니다. 이 필드에 올바른 accessId 형식을 입력하는 것이 중요합니다. 사용자의 accessId 형식은 user:realmName/userUniqueId입니다. realmName은 사용자가 있는 범주의 이름이며 userUniqueId는 사용되는 레지스트리에 따라 사용자를 나타내는 uniqueId입니다.

예를 들어, LDAP의 경우 uniqueUserId Windows의 경우 고유 이름(DN)입니다. localOS 레지스트리이며 사용자의 SID입니다. Unix 플랫폼의 경우 UID입니다. 사용자 정의 레지스트리의 경우 구현에 따라 다릅니다.

마찬가지로 그룹의 경우 accessId 형식은 group:realmName/groupUniqueId입니다. 앞에 언급된 것처럼 원하는 도메인 또는 범주의 올바른 형식을 가져오려면 -displayAccessIds 옵션이 true로 설정된 listRegistryUsers 및 listRegistryGroups 명령을 사용하십시오.

신뢰 범주의 사용자 및 그룹이나 AllAuthenticatedInTrustedRealms 특별 주제가 애플리케이션의 권한 테이블에 추가되면 해당 신뢰 범주를 사용하는 다른 애플리케이션의 요청을 수락할 수 있습니다. 수신 서버의 LTPA 토큰 유효성 검증에서는 먼저 범주가 신뢰되는지를 확인합니다. 그런 다음 권한 엔진에서 외부 사용자 및/또는 그룹이나 AllAuthenticatedInTrustedRealms 특별 주제에 자원 액세스에 필요한 역할로 액세스 권한이 부여되어 있는지 확인합니다. true인 경우 액세스 권한이 부여된 것입니다.

교차 영역 통신은 다음을 사용할 때만 적용 가능합니다. WebSphere 내장된 인증. SAF를 포함한 다른 인증 엔진을 사용하는 경우 z/OS®, 외부 사용자를 자체 저장소의 사용자에게 매핑하는 사용자 정의 로그인 모듈을 구현하여 모든 교차 영역 인증을 달성할 수 있습니다.

보안 도메인이 포함된 노드 연합

보안 도메인이 기본 버전으로 구성되고 셀에 연합되면 기본 버전에서 구성된 보안 도메인도 셀의 해당 서버에 대해 구성됩니다. 연합 전후 서버에서 동일한 도메인 보안 구성을 사용할 수 있습니다. 기본 서버가 셀로 연합되는 경우 보안 도메인에 지정된 자원은 셀 범위가 아닌 서버 범위여야 합니다.

기본 서버가 관리 에이전트 프로세스에 등록될 예정인 경우 기본 프로파일의 모든 서버가 이 보안 도메인을 사용하도록 하려는 경우 셀 범위를 자원으로 사용하십시오.

연합 중 기본의 보안 도메인이 이미 셀 레벨에 있는 경우 addNode 명령이 실패합니다. -excludesecuritydomains 옵션을 사용하면 연합 중 보안 도메인이 포함되지 않도록 할 수 있습니다.

연합 노드가 셀에서 제거되면 해당 노드의 자원이 보안 도메인에서 제거되어야 합니다. 여러 노드 범위에 속하는 연관된 클러스터가 보안 도메인에 있는 경우 해당 노드가 제거되지 않습니다. 스크립트 명령 또는 관리 콘솔을 사용하여 보안 도메인 또는 사용되지 않는 도메인에서 항상 자원을 제거할 수 있습니다.

혼합 버전 환경의 보안 도메인

모든 노드가 최신 버전으로 마이그레이션되면 보안 도메인을 작성해야 합니다. 셀을 도메인과 연관시켜야 하는 경우 특히 그렇습니다. 혼합 버전 환경에서 보안 도메인을 작성하는 경우 다음 사항에 유의해야 합니다.

보안 도메인 수정

보안 도메인을 수정하려면 관리 콘솔 태스크 또는 스크립트 명령을 사용하십시오. 관리 태스크 및 스크립트 명령의 전체 목록은 이 문서의 맨 아래에 있는 "관련 태스크" 링크를 참조하십시오.

보안 도메인이 작성되고 범위 세트에 연관되면 이러한 새 도메인과 연관된 서버를 다시 시작해야 합니다. 다시 시작 후 새 도메인과 연관된 범위의 애플리케이션이 도메인에 정의된 보안 속성을 사용합니다.

도메인 속성에 대한 변경사항은 지정된 모든 범위를 다시 시작해야 합니다. 새 범위가 추가되면 해당 범위도 다시 시작되어야 합니다. 도메인 구성에 대한 수정 즉, 보안 속성 또는 범위에 대한 수정은 도메인 구성을 사용하는 애플리케이션에 영향을 줍니다.

기존 도메인에 수정을 수행하기 전에 다음과 같은 잠재적 영향을 고려하십시오. 예를 들어, 도메인에 구성된 사용자 레지스트리가 제거되고 서버가 다시 시작되는 경우 셀 범위 도메인의 사용자 레지스트리(정의되어 있는 경우) 또는 글로벌 보안 구성이 사용됩니다. 이는 애플리케이션 인증 및 권한에 영향을 줄 수 있습니다. 애플리케이션과 연관된 사용자 및 그룹은 더 이상 새 레지스트리에서 유효하지 않습니다. 또 다른 고려사항의 예로는 JAAS 구성이 도메인에서 제거되는 경우를 들 수 있습니다. 이러한 구성에 종속된 애플리케이션은 더 이상 JAAS 구성을 사용할 수 없습니다. 보안 구성이 변경될 때마다 애플리케이션에 영향을 줄 수 있으므로 모든 보안 구성 변경은 최대한 주의를 기울여 수행되어야 합니다.