다른 영역에 있는 서버 간 권한 부여를 위해 ID 맵핑

ID 맵핑은 다운스트림 서버가 적절한 권한 부여 의사결정을 내릴 수 있도록 두 서버 간 사용자 ID의 일대일 맵핑입니다. ID 맵핑은 서버의 통합이 필요할 때 필요하지만 사용자 레지스트리는 다르고 시스템 간에 공유되지 않습니다.

이 태스크 정보

대부분의 경우에, 요청은 동일 보안 도메인의 일부인 두 서버 간에 다운스트림으로 플로우합니다. WebSphere® Application Server에서 동일 셀의 구성원인 두 개의 서버는 또한 동일 보안 도메인의 구성원입니다. 동일 셀에서 두 개의 서버에는 토큰 암호화를 위해 동일한 사용자 레지스트리 및 동일한 LTPA(e Lightweight Third Party Authentication) 키가 있습니다. 이러한 두 공통성으로 인해 두 서버 사이를 플로우하는 다른 속성 중에서도 LTPA 토큰은 복호화되고 유효성 검증될 수 있을 뿐만 아니라 토큰의 사용자 ID가 권한 부여 엔진에 의해 인식되는 속성으로 맵핑될 수 있습니다.

가장 안정적이고 권장되는 구성은 동일 셀 내의 두 개의 서버와 관련됩니다. 그러나 동일한 사용자 레지스트리를 사용할 수 없는 여러 시스템을 통합해야 할 때도 있습니다. 사용자 레지스트리가 두 서버 간 다르면 보안 도메인 또는 대상 서버의 영역은 전송 서버의 보안 도메인과 일치하지 않습니다.

WebSphere Application Server를 사용하면 요청을 아웃바운드로 전송하기 전이나 기존 보안 신임 정보가 대상 서버로 플로우할 수 있도록 설정하기 전에 맵핑이 발생할 수 있습니다. 신임 정보는 대상 영역이 신뢰되는 명세를 사용하여 인바운드로 맵핑됩니다.

맵핑 대안은 사용자 ID를 실제로 맵핑하지 않고 토큰이나 비밀번호 없이 대상 서버로 사용자 ID를 전송하는 것입니다. 사용자 ID의 사용은 두 서버 간의 신뢰를 기반으로 합니다. CSIv2(Common Secure Interoperability Version 2) ID 어설션을 사용하십시오. 사용 가능으로 설정되면 서버는 초기 인증을 수행하기 위해 원본 클라이언트가 사용했던 것을 기반으로 X.509 인증서, 프린시펄 이름 또는 식별 이름(DN)을 전송합니다. CSIv2 ID 어설션 동안 WebSphere Application Server 간에 신뢰가 설정됩니다.

ID 어설션이 작동하려면 사용자 ID는 대상 사용자 레지스트리에 있어야 합니다. 이 프로세스는 또한 다른 Java™ 2 Platform, Enterprise Edition(J2EE) 버전 1.4 및 이상 준수 Application Server 간의 상호 운용성을 가능하게 해줍니다. 전송 서버 및 대상 서버 둘 모두에 ID 어설션이 구성되어 있으면 두 서버가 모두 동일 보안 도메인에 있더라도 WebSphere Application Server는 항상 이 인증 방법을 사용합니다. CSIv2 ID 어설션에 대한 자세한 정보는 다운스트림 서버에 대한 ID 어설션의 내용을 참조하십시오.

사용자 ID가 대상 서버의 사용자 레지스트리에 없는 경우에는 요청이 아웃바운드로 전송되기 전이나 요청이 인바운드로 수신될 때 ID 맵핑이 발생되어야 합니다. 이 의사결정은 사용자의 환경과 요구사항에 따라 다릅니다. 그러나 다음과 같은 이유로 요청이 아웃바운드로 전송되기 전에 사용자 ID를 맵핑하는 것이 일반적으로 더 쉽습니다.
  • 기존 신임 정보의 사용자 ID가 전송 서버의 사용자 레지스트리로부터 나온 것으로 알고 있습니다.
  • ID를 LTPA 신임 정보에 맵핑하는 것이 아니므로 LTPA(Lightweight Third Party Authentication) 키를 다른 대상 영역과 공유하는 것에 대해서는 걱정할 필요가 없습니다. 일반적으로 ID를 대상 영역의 사용자 레지스트리에 있는 사용자 ID 및 비밀번호에 맵핑합니다.
대부분의 경우에 아웃바운드 맵핑을 수행할 때 네트워크를 통해 전송된 보안 정보의 무결성 및 기밀성을 보호하기 위해 SSL(Secure Sockets Layer)을 사용하는 것이 권장됩니다. LTPA 키가 서버 간에 공유되지 않으면 LTPA 토큰은 인바운드 서버에서 유효성 검증될 수 없습니다. 이 경우 사용자 ID는 인바운드 맵핑을 수행하기 위해 인바운드 서버에서 판별될 수 없으므로 아웃바운드 맵핑이 필요합니다. 자세한 정보는 다른 대상 영역에 아웃바운드 ID 맵핑 구성의 내용을 참조하십시오.

잠재적으로 인바운드 서버의 맵핑 기능으로 인해 인바운드 맵핑이 필요한 경우에는 사용자 ID에 액세스할 수 있기 위해서는 두 서버 모두에 동일한 LTPA 키가 있는지 확인해야 합니다. 일반적으로 서버 간의 보안 통신에서 LTPA 토큰은 클라이언트 인증을 위해 인바운드 JAAS 로그인 구성의 WSCredTokenCallback 콜백으로 전달됩니다. 유효한 경우 LTPA 토큰을 열 수 있고 맵핑을 수행할 수 있도록 사용자 고유 ID에 액세스할 수 있게 해주는 메소드를 사용할 수 있습니다. 자세한 정보는 인바운드 ID 맵핑 구성의 내용을 참조하십시오. ID 어설션과 같은 다른 경우에 ID를 맵핑할 수 있게 해주는 인바운드 로그인 구성의 NameCallback 콜백에서 사용자 이름을 수신할 수도 있습니다.

이 섹션에서는 다음 주제를 다룹니다.

프로시저


주제 유형을 표시하는 아이콘 태스크 주제



시간소인 아이콘 마지막 업데이트 날짜: last_date
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=tsec_perfidmap
파일 이름:tsec_perfidmap.html