2017-01-04 11 views
0

섹션 8.3.7은 persistent nameID 포맷 프라이버시 보호를 위해 사용되는 것을 말한다 :왜 SAML 영구 식별자가 '개인 정보 보호 메커니즘'으로 사용됩니까? 인 SAML 사양의 핵심

영구 식별자 프라이버시 보호기구로서 의도된다; 그 (것)들은 공동 식별자를 설치 한 공급자 이외에 공급자와 가진 명백한 원본에서 공유되면 안된다. 또한 적절한 제어 및 보호 기능이 없으면 로그 파일이나 유사한 위치에 나타나서는 안됩니다.

영구 식별자를 개인 정보 보호 메커니즘으로 사용하려는 의도를 이해하지 못했습니다. 특히 다른 NameID 유형 (이메일, SN, 정규화 된 이름, 커브 교장 등)은 모든 SP에서 동일합니다.

SP 고유의 고유 한 NameID는 어떻게 '개인 정보 보호 메커니즘'입니까? 특히 persistent NameID 필드를 다른 유형보다 사용하여 어떤 공격 경로를 완화 할 수 있습니까 (특히 올바른 대상 제한 및 서명과 같은 보호 기능이있는 경우).

답변

-1

실제 식별자를 IdP에서 SP로 전송하지 않기 때문에 개인 정보 보호 메커니즘입니다. 한편 Email NameID 유형은 IdP에서 SP로 전자 메일을 전송합니다.

이 좋은 설명을 찾을 수있는 온라인 리소스는 http://docs.oasis-open.org/security/saml/Post2.0/sstc-saml-tech-overview-2.0.html입니다. 5.4.3 영구 가명 식별자를 사용하여 페더레이션하십시오. 다음

처리는 다음

  1. cars.example.co.uk 사용자의 자원 액세스를 시도. 사용자는이 사이트에서 현재 로그온 세션 (즉, 보안 컨텍스트)을 갖고 있지 않으며 알 수 없습니다. 사용자가 액세스를 시도한 리소스는 RelayState 정보로 저장됩니다.

  2. 서비스 공급자는 HTTP 리디렉션 바인딩을 사용하여 아이디 공급자 (airline.example.com)의 Single Sign-On Service로 사용자를 보냅니다. HTTP 리디렉션에는 ID 공급자가 사용자의 영구적 이름 식별자를 사용하여 어설 션을 제공하도록 요청하는 SAML 메시지가 포함됩니다. 서비스 공급자가 IdP가 사용자에게 새로운 식별자를 생성 할 수있는 유연성을 요구하기 때문에 SP는 NameIDPolicy 요소의 AllowCreate 특성을 'true'로 설정합니다.

  3. 사용자는 유효한 자격 증명을 제공해야합니다.
  4. 사용자는 자신을 john으로 식별하는 유효한 자격 증명을 제공하고 IdP에서 사용자에 대한 로컬 보안 컨텍스트가 만들어집니다.
  5. 싱글 사인온 서비스는 ID 저장소에서 사용자 john을 조회하고 AllowCreate 속성을 허용하여 서비스 공급자의 세션에 사용되는 영구 이름 식별자 (61611)를 만듭니다. 그런 다음 주체가 일시적인 이름 식별자 형식을 사용하는 서명 된 SAML 웹 SSO 어설 션을 작성합니다. 존이라는 이름은 어설 션의 어디에도 포함되어 있지 않습니다. 파트너 계약에 따라 사용자 (예 : 회원 등급)에 대한 신원 속성을 설명하는 속성 명세서가 주장에 포함될 수도 있습니다.
  6. 브라우저는 사용자 작업 또는 "자동 제출"스크립트의 실행으로 인해 HTTP POST 요청을 보내 양식을 서비스 제공 업체의 어설 션 소비자 서비스로 보냅니다.
  7. cars.example.co.uk 서비스 공급자의 어설 션 소비자 서비스는 SAML 응답의 디지털 서명의 유효성을 검사하고 SAML 어설 션의 유효성을 검사합니다. 제공된 이름 식별자는 이전 연합이 수립되었는지 여부를 결정하는 데 사용됩니다. 이전 연합이 성립 된 경우 (이름 식별자가 로컬 계정에 매핑되기 때문에) 9 단계로 진행합니다. 단언에서 영구 식별자에 대한 연합이 존재하지 않으면 SP는 자신이 있어야 할 로컬 ID를 결정해야합니다 할당 됨. 사용자는 SP에서 로컬 자격 증명을 제공해야합니다. 선택적으로 사용자는 먼저 두 계정을 연합할지 여부를 묻는 메시지를 표시 할 수 있습니다.
  8. 사용자는 유효한 자격 증명을 제공하고 SP에서 자신의 계정을 jdoe로 식별합니다. 영속 식별자 식별자는 jdoe 계정에 저장되고 이름 식별자를 생성 한 아이디 공급자의 이름과 함께 등록됩니다.
  9. 사용자 jdoe에 대해 로컬 로그온 세션이 생성되고 사용자 jdoe가 cars.example.co.uk 웹 사이트에서 원하는 리소스에 액세스 할 수있는 올바른 권한을 가지고 있는지 확인하기 위해 액세스 확인이 수행됩니다 (리소스 URL은 액세스 검사를 통과하면 RelayState 값 정보에 의해 식별되는 상태 정보에서 검색. , 원하는 자원이 브라우저에 반환됩니다. 그래도 난 5 단계에서 오타가 생각

. 그것은해야 할 " "일시적인 이름 식별자 형식 사용"대신 "영구적 이름 식별자 형식 사용"

+0

ok ... 이러한 식별자는 c (당신이 내게 준 예제에 따라) 연합 흐름 외부에서 사용될 수 있습니다. 그리고 흐름이 어떻게 작동하는지 실제로 묻지 않았습니다. 대신 보안 문제와 공격 경로에 대해 구체적으로 묻고있었습니다. 귀하의 응답에서 사양이 말하는 개인 정보 보호 메커니즘의 유일한 목적은 기밀성이라고 가정 한 것처럼 보입니다. 왜 이것이 중요한지에 대한 몇 가지 추론/예를 들려 줄 수 있습니까? 예를 들어, SP에서 공유 식별자를 사용할 때 공격 경로가 있습니까? – JoshC13

+0

나는 프라이버시를 보호하기 위해 그것을 사용하는 역할을 이해하는 것이 충분히 분명하기를 희망했기 때문에 그 흐름을 사용하여 대답했다. 어떻게 도움이됩니까? 예를 들어 StackOverflow를 신뢰하고 Josh라는 이름을 제공하십시오. 그런 다음 StackOverflow를 IdP로 사용하여 다른 SP에 로그인하려고합니다. 영구 식별자를 사용하면 몇 가지를 보증 할 수 있습니다. – Thuan

+0

1. SP로 반환되는 토큰에 실제 신원이 포함되지 않습니다. 토큰이 유출 된 경우 공격자는 자신이 보낸 토큰임을 알 수 없습니다. 2. SP가 귀하의 실제 신원을 알지 못합니다. 이렇게하면 SO 신원을 남용 할 수있는 기회가 줄어 듭니다. 3. SP 사이트가 손상되면 침입자가 SO 신원이 실제로 무엇인지 알 수 없게됩니다. 이 문제에 대한 내 경험에 기반하여 추가 할 수있는 것은이 모두입니다. – Thuan