CSIV2(Common Secure Interoperability Version 2) 인바운드 통신 구성

인바운드 통신은 인바운드 요청이 승인된 인증 유형을 판별하는 구성을 참조합니다. 이 인증은 클라이언트가 이름 서버로부터 검색하는 상호 운용 가능한 오브젝트 참조(IOR)에서 광고됩니다.

프로시저

  1. 관리 콘솔을 시작하십시오.
  2. 보안 > 글로벌 보안을 클릭하십시오.
  3. RMI/IIOP 보안 아래에서 CSIv2 인바운드 통신을 클릭하십시오.
  4. 다음 보안 계층을 고려하십시오.
    • ID 어설션(속성 계층).

      선택되면 이 서버는 업스트림 서버로부터 ID 토큰을 승인합니다. 서버가 ID 토큰을 수신하면 ID는 발신 클라이언트로부터 가져옵니다. 예를 들어, ID는 발신 클라이언트가 첫 번째 서버에 제공한 것과 동일한 양식입니다. 업스트림 서버는 발신 클라이언트의 ID를 전송합니다. ID의 형식은 프린시펄 이름, 식별 이름 또는 인증서 체인일 수 있습니다. 일부 경우에는 ID가 익명입니다. ID는 이 서버에서 인증되므로 ID 토큰을 전송하는 업스트림 서버를 신뢰하는 것이 중요합니다. 업스트림 서버의 신뢰는 SSL(Secure Sockets Layer) 클라이언트 인증서 인증 또는 기본 인증을 사용하여 설정됩니다. ID 어설션을 선택할 때 인바운드 및 아웃바운드 인증 둘 모두에서 두 개의 인증 계층 중 하나를 선택해야 합니다.

      [AIX Solaris HP-UX Linux Windows][IBM i]서버 ID는 ID 토큰과 함께 클라이언트 인증 토큰에서 전송됩니다. 서버 ID는 신뢰받는 서버 ID 목록을 기준으로 검사됩니다. 서버 ID가 신뢰받는 서버 목록에 있으면 서버 ID가 인증됩니다. 서버 ID가 올바르면 ID 토큰은 신임 정보에 놓이고 요청의 권한 부여를 위해 사용됩니다.

      [z/OS]
      참고: 구성된 레지스트리가 로컬 OS인 경우, 신뢰는 CBIND 클래스, 프로파일 CB.BIND.<optionalSAFProfilePrefix>.<cluster_short_name>에 대한 UPDATE 권한으로 다운스트림 서버에서 업스트림 서버 ID가 권한 부여되었는지 여부를 확인함으로써 대신 설정됩니다. 업스트림 서버 ID는 SSL 클라이언트 인증서를 사용하여 전송됩니다. SSL이 사용되지 않으면 CBIND 확인이 업스트림 서버의 시작된 태스크 ID에 대해 수행됩니다.
      문제점 방지 문제점 방지: ID 어설션이 사용 가능하면 메시지 계층 또는 전송 계층 또한 사용 가능으로 설정되어야 합니다. 서버 대 서버 통신의 경우 전송 계층/클라이언트 인증을 사용 가능으로 설정하는 것 외에도 ID 어설션 또는 메시지 계층 또한 사용 가능으로 설정되어야 합니다. gotcha

      자세한 정보는 ID 어설션을 참조하십시오.

    • 메시지 계층:

      기본 인증(GSSUP):

      이 인증 유형은 가장 일반적입니다. 사용자 ID 및 비밀번호 또는 인증된 토큰은 순수한 클라이언트 또는 업스트림 서버로부터 전송됩니다. 서버에서 사용자 ID 및 비밀번호를 받으면 이들은 다운스트림 서버의 사용자 레지스트리를 사용하여 인증됩니다.

      LTPA(Lightweight Third Party Authentication):

      이 경우 LTPA 토큰은 업스트림 서버로부터 전송됩니다. LTPA를 선택하면 두 서버 모두 동일 LTPA 키를 공유해야 합니다.

      Kerberos(KRB5):

      Kerberos를 선택하려면 활성 인증 메커니즘이 Kerberos여야 합니다. 이 경우 Kerberos 토큰이 업스트림 서버로부터 전송됩니다.

      자세한 정보는 메시지 계층 인증에 대해 읽으십시오.

    • SSL(Secure Sockets Layer) 클라이언트 인증서 인증(전송 계층)

      SSL 클라이언트 인증서는 사용자 ID 및 비밀번호를 사용하는 대신에 인증하는 데 사용됩니다. 서버가 ID를 다운스트림 서버로 위임하면 ID는 클라이언트 인증서 인증을 통해 전송 계층으로부터가 아니라 메시지 계층(클라이언트 인증 토큰) 또는 속성 계층(ID 토큰)으로부터 나옵니다.

      [AIX Solaris HP-UX Linux Windows][IBM i]클라이언트에는 클라이언트 구성의 키 저장소 파일에 저장된 SSL 클라이언트 인증서가 있습니다. 이 서버에서 SSL 클라이언트 인증이 사용 가능하면 서버는 연결이 설정될 때 클라이언트가 SSL 클라이언트 인증서를 전송하도록 요청합니다. 인증서 체인은 요청이 서버에 전송될 때마다 소켓에서 사용 가능합니다. 서버는 인터셉터가 소켓으로부터 인증서 체인을 가져오고 이 인증서 체인을 사용자 레지스트리에 있는 사용자로 맵핑하도록 요청합니다. 이 인증 유형은 클라이언트에서 서버로 직접 통신하기 위해서 최적입니다. 그러나 다운스트림으로 가야 하는 경우에는 ID는 일반적으로 메시지 계층 또는 ID 어설션을 통해 흐릅니다.

      [z/OS]클라이언트에는 클라이언트 구성의 키 링 파일에 저장된 SSL 클라이언트 인증서가 있습니다. 이 서버에서 SSL 클라이언트 인증이 사용 가능하면 서버는 연결이 설정될 때 클라이언트가 SSL 클라이언트 인증서를 전송하도록 요청합니다. 인증서 체인은 요청이 서버에 전송될 때마다 소켓에서 사용 가능합니다. 서버는 인터셉터가 소켓으로부터 인증서 체인을 가져오고 이 인증서 체인을 사용자 레지스트리에 있는 사용자로 맵핑하도록 요청합니다. 이 인증 유형은 클라이언트에서 서버로 직접 통신하기 위해서 최적입니다. 그러나 다운스트림으로 가야 하는 경우에는 ID는 일반적으로 메시지 계층 또는 ID 어설션을 통해 흐릅니다.

  5. 어떤 유형의 인증을 승인할지를 결정할 때 다음 사항을 고려하십시오.
    • 서버는 여러 계층을 동시에 수신할 수 있으므로 서열 규칙의 순서는 사용할 ID를 결정합니다. ID 어설션 계층에는 최상위 우선순위가 있습니다. 메시지 계층이 뒤따르고 전송 계층은 가장 낮은 우선순위가 있습니다. SSL 클라이언트 인증서 인증은 이것이 제공된 유일한 계층인 경우에 사용됩니다. 메시지 계층 및 전송 계층이 제공된 경우에는 메시지 계층이 권한 ID를 설정하기 위해 사용됩니다. ID 어설션 계층이 제공되면 우선순위를 설정하는 데 사용됩니다.
    • 이 서버는 일반적으로 클라이언트 또는 서버 또는 둘 모두로부터 요청을 받습니까? 서버가 항상 클라이언트로부터 요청을 수신하면 ID 어설션은 필요하지 않습니다. 메시지 계층, 전송 계층 또는 둘 모두를 선택할 수 있습니다. 언제 인증이 필요하거나 지원되는지를 결정할 수도 있습니다. 계층을 필수로 선택하려면 전송 클라이언트는 이 계층을 제공해야 합니다. 그렇지 않으면 요청이 거부됩니다. 그러나 계층이 지원만 되는 경우에는 계층이 제공되지 않을 수도 있습니다.
    • 어떤 종류의 클라이언트 ID가 제공됩니까? 클라이언트 ID가 클라이언트 인증서 인증이고 인증서 체인이 다운스트림 서버 사용자 레지스트리로 맵핑될 수 있도록 다운스트림을 플로우하도록 하고 싶은 경우에는 ID 어설션이 적합한 선택입니다. ID 어설션은 시작 클라이언트의 형식을 보존합니다. 발신 클라이언트가 사용자 ID 및 비밀번호를 사용하여 인증되면 프린시펄 ID가 전송됩니다. 인증서를 사용하여 인증이 수행되면 인증서 체인이 전송됩니다.

      [AIX Solaris HP-UX Linux Windows][IBM i]일부 경우에 클라이언트가 토큰을 사용하여 인증되고 LDAP(Lightweight Directory Access Protocol) 서버가 사용자 레지스트리이면 식별 이름(DN)이 전송됩니다.

  6. 신뢰받는 서버 목록을 구성하십시오. 인바운드 요청을 위해 ID 어설션이 선택되면 이 서버가 ID 토큰 제출을 지원할 수 있는 서버 관리자 ID의 파이프로 구분된(|) 목록을 삽입하십시오. 이전 버전과의 호환성을 위해서 여전히 쉼표로 구분된 목록을 사용할 수 있습니다. 그러나 서버 ID가 식별 이름(DN)이면 쉼표 구분 기호는 작동하지 않으므로 파이프 구분(|) 목록을 사용해야 합니다. ID 토큰을 전송하는 모든 서버를 지원하기로 선택한 경우에는 이 필드에 별표(*)를 입력할 수 있습니다. 이 조치는 추정된 신뢰라고 불립니다. 이 경우 신뢰를 설정하기 위해 서버 간에 SSL 클라이언트 인증서 인증을 사용하십시오.
    지원된 구성 지원된 구성: 이 단계는 LDAP(Lightweight Directory Access Protocol) 또는 사용자 정의 사용자 레지스트리를 사용 중인 경우에 적용됩니다. 그러나 로컬 운영 체제 사용자 레지스트리 또는 SAF(System Authorization Facility) 사용자 레지스트리를 사용 중인 경우에는 적용되지 않습니다. sptcfg
  7. 세션 관리를 구성하십시오. stateful 또는 stateless 보안을 선택할 수 있습니다. stateful 세션을 선택할 때 성능이 최적입니다. 클라이언트와 서버 간의 첫 번째 메소드 요청이 인증됩니다. 모든 후속 요청(또는 신임 정보 토큰이 만료될 때까지)은 신임 정보를 포함하여 세션 정보를 재사용합니다. 클라이언트는 후속 요청을 위해 컨텍스트 ID를 전송합니다. 컨텍스트 ID는 고유성을 위해 연결로 범위가 지정됩니다.

결과

이 패널 구성을 완료하면 이 서버에 무엇을 보낼지를 결정할 때 클라이언트가 수집하는 정보의 대다수를 구성한 것입니다. 이 서버 인바운드 구성과 함께 클라이언트 또는 서버 아웃바운드 구성은 적용되는 보안을 판별합니다. 클라이언트가 무엇을 보내는지를 알면 구성은 단순합니다. 그러나 다양한 보안 요구사항이 있는 다양한 클라이언트 세트가 있는 경우에는 서버는 다양한 인증 계층을 고려합니다.

Java Platform, Enterprise Edition Application Server의 경우 인증 선택사항은 일반적으로 ID 어설션 또는 메시지 계층입니다. 사용자가 다운스트림을 위임한 발신 클라이언트의 ID를 원하기 때문입니다. SSL 연결을 사용하여 클라이언트 인증서를 쉽게 위임할 수 없습니다. 추가 서버 보안으로 인해 전송 계층을 사용 가능으로 설정할 수 있습니다. SSL 핸드쉐이크의 추가 클라이언트 인증서 부분이 전체 SSL 연결 설정에 약간의 오버헤드를 추가하기 때문입니다.

다음에 수행할 작업

이 서버가 어떤 인증 데이터 유형을 수신하는지를 판별한 후에는 아웃바운드 보안을 위해 무엇을 선택할지를 판별할 수 있습니다. 자세한 정보는 Common Secure Interoperability Version 2 아웃바운드 인증 구성을 참조하십시오.

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



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