다운스트림 서버에 대한 ID 어설션

클라이언트가 서버를 인증하면 수신된 신임 정보가 설정됩니다. 인증 엔진이 신임 정보를 확인하여 액세스 허용 여부를 판별하는 경우 호출 신임 정보로 설정합니다. ID 어설션은 다운스트림 서버에 어설션되는 호출 신임 정보입니다.

클라이언트가 서버를 인증하면 수신된 신임 정보가 설정됩니다. 권한 부여 엔진은 자격 증명을 확인하여 액세스가 허용되는지 여부를 결정할 때 다음과 같이 설정합니다. 기도 자격 증명을 사용하면 Enterprise JavaBeans (EJB) 메소드가 다른 서버에 있는 다른 EJB 메소드를 호출하는 경우 호출 신임 정보는 다운스트림 메소드를 시작하는 데 사용되는 ID일 수 있습니다. 엔터프라이즈 Bean에 대한 RunAs 모드에 따라 호출 신임 정보는 원래 클라이언트 ID, 서버 ID 또는 지정된 다른 ID로 설정됩니다. 설정된 ID에 상관없이 ID 어설션이 사용되면 다운스트림 서버에 어설션되는 호출 신임 정보입니다.

[AIX Solaris HP-UX Linux Windows]호출 신임 정보 ID는 ID 토큰으로 다운스트림 서버에 전송됩니다. 또한, 비밀번호나 토큰을 포함하는 전송 서버 ID는 기본 인증이 사용되는 경우에 클라이언트 인증 토큰으로 전송됩니다. 전송 서버 ID는 클라이언트 인증서 인증이 사용되는 경우 SSL(Secure Sockets Layer) 클라이언트 인증서 인증을 통해 전송됩니다. 기본 인증이 클라이언트 인증서 인증보다 우선적으로 사용됩니다.

두 ID 토큰 모두 어설션된 ID를 승인하기 위해 수신 서버에 필요합니다. 수신 서버는 다음 조치를 완료하여 어설션된 ID를 승인합니다.
  • 전송 서버가 수신 서버로 전송한 ID는 GSSUP 토큰(사용자 ID 및 비밀번호) 또는 SSL 클라이언트 인증서입니다. z/OS® 활성 사용자 레지스트리가 로컬 OS이고 SAF 인증이 활성화된 경우, GSSUP 토큰 대신 MVS 시작 작업 ID가 전송됩니다.
  • 신뢰는 전송되는 ID에 따라 전송 및 수신 서버 사이에서 설정됩니다.
    1. GSSUP 토큰이 전송되는 경우 신뢰는 전송 서버 ID가 수신 서버의 신뢰 프린시펄 목록에 있는지를 확인하여 설정됩니다.
    2. MVS 시작 작업 ID가 전송되면 이 ID에 대한 업데이트 권한이 있는지 확인하여 신뢰가 설정됩니다. CB.BIND.<servername> 프로필이 SAF 데이터베이스에 있습니다.
    3. SSL 클라이언트 인증서가 전송되면 z/OS 이 인증서는 SAF(Service Access Facility) 사용자 ID에 매핑됩니다. 신뢰는 이 사용자 ID가 CB.BIND.<servername> 프로파일에 대해 UPDATE 권한을 가지고 있는지를 확인하여 설정됩니다.
  • 전송 서버가 신뢰 목록에 있는지를 판별한 후에 서버는 해당 ID를 확인하기 위해 전송 서버를 인증합니다.
  • 서버는 전송 서버의 사용자 ID와 비밀번호를 수신 서버와 비교하여 인증됩니다. 전송 서버의 신임 정보가 인증되고 신뢰되면 서버는 ID 토큰 평가로 진행합니다.
  • 수신 서버가 권한 부여용으로 더 많은 신임 정보를 수집하기 위해 어설션된 사용자 ID 존재에 대해 정의된 해당 사용자 레지스트리를 검사합니다(예: 그룹 멤버십). 따라서 수신 서버의 사용자 레지스트리는 모든 어설션된 사용자 ID를 포함해야 합니다. 그렇지 않으면, ID 신뢰가 불가능합니다. stateful 서버에서 이 조치는 ID 토큰이 동일한 전송 서버 및 수신 서버 쌍에 대해 한 번만 발생합니다. 후속 요청은 세션 ID를 통해 수행됩니다.
    메모: 다운스트림 서버에 해당 저장소의 어설션된 사용자 ID에 대한 액세스 권한이 있는 사용자 레지스트리가 없는 경우 권한 확인이 실패하므로 ID 어설션을 사용하지 마십시오. ID 어설션이 사용되지 않도록 하여 수신 서버에서의 권한 검사는 필요하지 않습니다.
ID 토큰 평가는 다음과 같이 ID 토큰에 있는 4개의 ID 형식으로 구성됩니다.
  • 프린시펄 이름
  • 식별 이름
  • 인증서 체인
  • 익명 ID
인증 정보를 수신하는 제품 서버는 일반적으로 4개의 모든 ID 유형을 지원합니다. 전송 서버는 원래 클라이언트 인증 방법을 기반으로 선택할 하나를 결정합니다. 기존 유형은 클라이언트가 원래 전송 서버를 인증하는 방법에 따라 다릅니다. 예를 들어, 클라이언트가 SSL(Secure Sockets Layer) 클라이언트 인증을 사용하여 전송 서버를 인증하는 경우 다운스트림 서버에 전송되는 ID 토큰에는 인증서 체인이 포함됩니다. 이 정보를 사용하여 수신 서버는 자체 인증서 체인 맵핑을 수행할 수 있고 상호 운용성은 다른 벤더 또는 플랫폼을 사용하여 증가됩니다.

ID 형식이 이해되고 구문 분석된 후에 ID는 신임 정보에 맵핑됩니다. ITTPrincipal ID 토큰의 경우 이 ID는 사용자 필드와 1 대 1로 맵핑됩니다.

[AIX Solaris HP-UX Linux Windows]ITTDistinguishedName ID 토큰의 경우 맵핑은 사용자 레지스트리에 따라 다릅니다. LDAP(Lightweight Directory Access Protocol)의 경우, 구성된 검색 필터가 맵핑 발생 방법을 결정합니다. LocalOS의 경우, 일반적으로 공통 이름과 동일한 식별 이름(DN)의 첫 번째 속성은 레지스트리의 사용자 ID에 맵핑합니다.

[AIX Solaris HP-UX Linux Windows]ID 어설션은 CSIv2(Common Secure Interoperability Version 2) 프로토콜을 사용하는 경우에만 사용할 수 있습니다.

메모: KRB 토큰을 사용한 ID 어설션을 다운스트림으로 사용하는 데에는 제한이 있습니다. Kerberos가 사용되는 ID 어설션을 사용하는 경우 ID 어설션은 다운스트림 서버로 이동할 때 Kerberos 인증 토큰(KRBAuthnToken)을 포함하지 않습니다. 대신 인증에 LTPA를 사용합니다.