다음을 통해 공유

웹 서비스 세계에서 ID 페더레이션

  • 아티클

저작권 고지

 

© 2001-2003 International Business Machines Corporation, Microsoft Corporation. 모든 권한이 예약되어 있습니다.

추상적인

이 문서에서는 페더레이션 ID 관리와 관련된 문제를 설명하고 WS-Security 로드맵 및 기타 관련 웹 서비스 사양에 설명된 웹 서비스 사양을 기반으로 하는 포괄적인 솔루션을 설명합니다.

WS-Federation 사양에 추가로 정의될 이 백서에 설명된 접근 방식은 ID 공급자를 보안 토큰 서비스의 클래스로 도입합니다. 따라서 WS-Trust 및 WS-Federation 메커니즘을 사용하여 페더레이션 내 및 전체에서 트러스트를 만들고 중개합니다. 또한 단일 로그인 및 로그아웃, 권한 부여 및 개인 정보 보호 정책에 따라 특성 공유, 가명 통합 처리(다른 사이트/페더레이션에서 사용되는 별칭)에 대한 메커니즘이 정의됩니다.

함께, 이 문서에서 식별된 사양은 다른 보안 및 웹 서비스 사양으로 구성하여 페더레이션 내 및 페더레이션 간에 신뢰할 수 있는 트랜잭션 메시지를 보호하기 위한 포괄적이고 통합된 프로토콜 집합을 제공합니다.

요약

지난 몇 년 동안 웹 애플리케이션은 간단한 콘텐츠 배달 애플리케이션에서 정교한 비즈니스 생산성 도구 및 기업 내 및 기업 간에 애플리케이션 통합을 위한 메커니즘으로 발전해 왔습니다. 웹 및 웹 서비스의 성장은 많은 기술 문제에 대한 개방형 및 상호 운용 가능한 솔루션의 필요성을 입증했습니다.

이 문서에서는 특정 보안 관련 문제 집합에 중점을 줍니다. 여기에는 다음이 포함되었습니다.

올바른 보안 ID 및 위치 웹 서비스결정하는 방법: 조직은 서비스 요청자(고객 및 파트너)가 지정된 비즈니스의 올바른 웹 서비스를 안전하게 비즈니스 서비스 공급자가 권한 있는 요청자에게만 올바른 웹 서비스를 안전하게 식별하고 노출할 수 있는 표준 방법이 필요합니다.

웹 서비스안전하게 호출할 수 있도록 자격 증명 집합을 결정하는 방법: 비즈니스 서비스 요청자가 올바른 인증, 권한 부여 및 권한 집합으로 웹 서비스를 안전하게 호출할 수 있는 표준화된 수단입니다.

웹 서비스안전하게 페더레이션하는 방법: 기업이 다른(파트너) 비즈니스 또는 기관에 등록된 고객에게 서비스를 직접 제공할 수 있도록 하는 표준 방법입니다. 서비스 페더레이션 내에서 비즈니스는 사용자의 홈 조직(또는 정보 제공 서비스)에서 사용자에 대한 신뢰할 수 있는 정보를 얻을 수 있습니다. 비즈니스는 해당 사용자의 ID를 등록하고 유지 관리할 필요가 없으며, 사용자는 비즈니스와 상호 작용하기 위해 새 로그인을 가져와서 기억할 필요가 없습니다.

엔터프라이즈 간 및 도메인 간 트러스트사용하도록 설정하는 방법: 조직 간의 신뢰를 설정하고 반영하는 표준 방법입니다. 페더레이션 서비스의 주요 문제입니다.

페더레이션 ID 및 특성 매핑사용하도록 설정하는 방법: 외국 사용자(예: 비즈니스 파트너의 사용자)에 대한 신뢰할 수 있는 정보를 기업의 기존 서비스에서 사용할 수 있는 인증 및 권한 부여 정보에 매핑하기 위한 잘 이해되는 메커니즘 및 절차입니다.

보안, 신뢰할 수 있는 트랜잭션사용하도록 설정하는 방법: 안전하고 신뢰할 수 있으며 트랜잭션된 컨텍스트에서 메시지를 교환하는 표준 방법입니다. 이전 사양(예: WS-ReliableMessaging 및 WS-Transaction)은 신뢰할 수 있는 메시지 교환 및 비즈니스 트랜잭션을 지원합니다. 이 문서에서는 페더레이션 보안 지원에 대해 설명합니다.

IBM, Microsoft 및 파트너는 고객, 파트너 및 표준 기관과 협력하여 여기에 설명된 사양을 발전시키고 이러한 사양이 웹 서비스 아키텍처의 다른 요소와 잘 구성되도록 할 계획입니다. 이 문서에서 설명하는 다양한 제안 사양의 상호 운용성과 일관된 구현을 보장하기 위해 IBM, Microsoft 및 파트너는 표준 조직, 개발자 커뮤니티 및 WS-I.org 같은 업계 조직과 긴밀히 협력하여 도구 공급업체에 지침을 제공하는 상호 운용성 프로필 및 테스트를 개발할 것입니다.

용어는 기술마다 다르기 때문에 이 문서에서는 다양한 보안 형식 및 메커니즘에 일관되게 적용될 수 있는 몇 가지 용어를 정의합니다. 따라서 여기서 사용되는 용어는 다른 사양과 다를 수 있으며 독자가 선호하는 어휘에 용어를 매핑할 수 있도록 정의됩니다. 다음을 참조하세요. 용어 섹션에서 이러한 용어와 해당 용어의 정의 및 사용 현황을 요약합니다.

1 소개 및 동기 부여

페더레이션 ID 관리는 개인과 기업 모두에게 중요한 과제입니다. 이 장에서는 문제를 탐색한 다음, 문제의 영향을 받는 당사자를 식별하고 실행 가능한 솔루션에 대한 주요 목표로 결론을 내립니다.

페더레이션 ID 관리 문제가란?

회사의 가치 네트워크는 많은 조직, 시스템, 애플리케이션 및 비즈니스 프로세스에 걸쳐 있습니다. 고객, 직원, 파트너, 공급업체 및 배포자를 포함하여 여러 다른 구성 요소가 이 가치 네트워크를 구성합니다. 이 엔드투엔드 값 네트워크에서 해당 구성 요소에 대한 ID 정보를 중앙에서 관리하거나 제어할 수 있는 단일 엔터티 또는 회사가 없습니다. 단일 회사 내에서도 사업부 내에서 독립적이고 자율적으로 관리해야 하는 ID 데이터의 여러 신뢰할 수 있는 원본이 있을 수 있습니다.

회사 간 협업의 기본 신조인 중앙 집중화에 대한 이 접근 방식은 전자 비즈니스 협업, 통합 및 자동화에 상당한 마찰을 야기하여 높은 ID 관리 비용과 효율성 저하를 초래합니다. 중앙 집중화를 사용하면 사용자 ID의 수명 주기를 관리하는 데 드는 비용이 매우 높습니다. 대부분의 기업은 직원, 비즈니스 파트너 및 고객 ID를 관리해야 합니다. 또한 비즈니스와 이러한 개인 간의 관계는 상당히 자주 변경되며 각 변경에는 관리 조치가 필요합니다.

경우에 따라 기업은 ID를 관리하는 당사자에게 일부 보안 기능을 아웃소싱하려고 하지만(현재와 마찬가지로 트랜잭션 컨텍스트에서 신용 카드 회사에) 두 가지 이유로 이 작업을 수행할 수 없습니다. 첫째, 소비자 금융 거래 이외의 시장에 서비스를 제공하는 타사 ID 공급자가 없고, 둘째, 타사 ID 공급자의 서비스에 안전하게 의존할 수 있는 비즈니스 및 책임 모델이 없습니다. 소비자 금융 거래.

다른 기업은 유지 관리하는 ID를 활용하여 추가 비즈니스 상호 작용을 가능하게 하고자 합니다. 그러나 비즈니스 경계를 넘어 엔터티를 페더레이션할 수 있도록 트러스트 메커니즘을 설정하는 것은 어렵습니다. 또한 ID 관리 작업이 개별 개인 정보 보호 권리와 충돌하는 방식으로 정보를 공개하거나 사용하는 경우 ID를 관리하는 기업은 점점 더 평판 손상 또는 규제 책임의 위험에 처해 있습니다. 이렇게 하면 ID 관리의 위험이 크게 증가합니다.

개인의 관점에서 볼 때 개인 및 전문가 모두에 대한 여러 ID가 존재합니다. 또한 개인은 ID를 다시 사용할 수 없기 때문에 발생하는 ID 관리 문제가 있습니다.

페더레이션 ID 관리는 회사 간 비즈니스 유연성을 제공하는 동시에 회사가 ID 관리 비용을 오프로드하고 간소화할 수 있도록 합니다. 이를 통해 기업은 비즈니스 모델, IT 정책, 보안 및 거버넌스 목표 및 요구 사항에 가장 잘 부합하는 비즈니스 통합 목표를 추구할 수 있습니다.

페더레이션 ID 관리 문제가 있는 사람은 누구인가요?

주요 통합 장벽은 보안 통신 모델의 부족으로 인해 회사 간 비즈니스 통합에 있습니다. 이 문제는 다음을 포함한 광범위한 회사에 영향을 미칩니다.

  • ID 정보를 사용하여 소비자에게 서비스를 제공하는 중간 및 대규모 조직(예: 웹 기반 여행 서비스 공급자).
  • 서로 비즈니스를 수행하고 개인의 신원에 대한 정보를 교환해야 하는 중대형 조직(예: 항공사 및 렌터카 기관, 병원 및 건강 보험 제공업체)
  • 기업 전체에 비즈니스 애플리케이션과 고객 및 공급업체의 가치 체인(예: 공급망)을 통합해야 하며 직원에게 조직을 대신하여 트랜잭션을 수행할 수 있는 권한을 부여해야 하는 조직입니다.
  • HR 및 복리후생과 같은 서비스를 제3자에게 아웃소싱하지만 이러한 아웃소싱 서비스에 자체 브랜드를 적용하는 조직(예: 직원에게 자체 내부 HR 포털을 통해 여러 은퇴 계획 또는 의료 계획 옵션을 제공하는 조직) 따라서 서비스 공급자와 직원 ID 정보를 공유해야 합니다.
  • 조직(중개자, 브로커, 집계자)은 비즈니스 모델이 "고객 환경 소유"를 통해 조정되지 않는 이유로 구동됩니다.
  • 여러 타사 공급자에 걸쳐 서비스를 집계하여 통합 브랜드의 전체 서비스 ID 기반 비즈니스 포털(금융 서비스, 보험 서비스, 구독 등)을 제공하는 조직

앞에서 설명한 것처럼 웹 기반 활동에 종사하는 개인은 일반적으로 만들고 관리해야 하는 많은 수의 독립 ID를 가지고 있기 때문에 이 문제를 겪습니다.

목표

페더레이션 ID 서비스의 주요 목표는 다음과 같습니다.

  • 노력의 중복을 줄여 ID 관리 비용을 줄입니다. 각 개인의 ID는 거의 항상 신뢰할 수 있는 조직(예: 개인의 은행, 고용주 또는 의사)에 의해 관리됩니다.
  • 이러한 기존 ID 관리자는 다른 당사자에게 관련 ID 정보에 대한 액세스 권한(필요에 따라 적절한 개인 정보 보호)을 제공하여 이미 수행한 작업을 활용합니다.
  • 모든 당사자의 자율성 유지 - ID 관리자가 선택한 인증 기술은 ID 정보에 의존하는 당사자에게 해당 기술을 적용해서는 안 됩니다. ID 관리자가 선택한 운영 체제 또는 네트워킹 프로토콜 또는 데이터베이스는 파트너에게 동일한 선택을 적용해서는 안 됩니다.
  • 비즈니스의 기존 신뢰 구조 및 계약을 존중합니다. ID 공급자로부터 ID 정보를 받기 위해 등록하는 경우 조직에서 ID 공급자가 아닌 다른 당사자와 트러스트 관계를 설정하도록 요구하지 않아야 하며 특정 사용자 인증 기술을 채택할 필요가 없습니다.
  • 개인 식별 정보의 사용을 제어하는 사용자 기본 설정을 존중하고 강력하게 적용하고, 정부 및 지역 개인 정보 보호 규칙을 준수하고, 새로운 사용에 대한 사용자의 동의를 구하고, 개인 정보 보호 관행을 준수할 수 있도록 강력한 기록 보관 및 책임 메커니즘을 구현하여 개인의 개인 정보를 보호합니다.
  • 개방형 표준을 기반으로 하여 기업 및 개인에게 안전한 신뢰할 수 있는 트랜잭션을 가능하게 합니다.

2. 페더레이션된 Single Sign-On 및 ID 관리

페더레이션 매력은 사용자가 지정된 페더레이션 내에서 다른 사이트를 원활하게 트래버스할 수 있도록 하기 위한 것입니다. 이 문서는 특히 페더레이션 ID 관리의 문제에 중점을 두고 있으며 일반 페더레이션의 더 큰 문제(보안 외에)에 중점을 둡니다. 페더레이션 참가자 간에 설정된 신뢰 관계 때문에 한 참가자가 사용자를 인증한 다음 해당 사용자에 대한 발급 당사자 역할을 할 수 있습니다. 다른 페더레이션 참가자는신뢰 당사자가 됩니다. 즉, 사용자가 직접 개입하지 않고 발급 당사자가 사용자에 대해 제공하는 정보에 의존합니다. 경우에 따라 사용자는 다른 인증 메커니즘 및 타사 인증 메커니즘의 사용으로 인해 신뢰 당사자에게 익명으로 처리될 수 있습니다.

웹 서비스 모델의 유연성과 매력은 기업이 파트너, 공급업체, 고객 및 직원과의 긴밀한 관계를 통해 혁신적인 비즈니스 모델을 제공하거나 가치 체인 네트워크를 보다 효율적으로 연결하기 위해 새로운 서비스를 쉽게 구축할 수 있는 빌딩 블록 기반입니다. 이러한 모델은 고객, 파트너 및 최종 사용자가 지속적으로 인증하거나 다양한 사이트에 자신을 식별하지 않고도 이러한 서비스를 지원하는 웹 사이트 간에 쉽게 탐색하거나 비즈니스 페더레이션 내의 각 구성원에서 개인 정보를 중복적으로 유지 관리할 수 있는 경우에만 성공할 수 있습니다.

불행히도 사용자를 인증하고 사용자 특성 정보(예: 신용 카드 정보)를 가져오기 위한 현재의 체계는 일반적으로 사용자가 관심 있는 각 비즈니스에 등록하도록 강요하고, 지속적으로 사용자가 자신을 식별하고 인증하도록 요구하고(일반적으로 사용자 이름 및 암호를 사용하여) 회사가 회사의 통제 하에 있지 않은 크고 빠르게 변화하는 ID 기반을 관리하도록 강요합니다. 이러한 모델은 웹 서비스 채택에 큰 장애가 되며 사용자와 기업 모두에게 골칫거리입니다.

널리 사용되는 모델의 또 다른 단점은 지정된 비즈니스가 고객 정보의 일부를 비즈니스 파트너에게 "제공"하기를 꺼릴 수 있다는 것입니다.

페더레이션은 파트너 조직에서 사용자를 식별하고 유효성을 검사하는 간단한 유연한 메커니즘을 제공하고 암호로 다시 인증할 필요 없이 신뢰할 수 있는 페더레이션 내에서 웹 사이트에 원활하게 액세스할 수 있도록 합니다. 또한 페더레이션 표준은 개인 정보 보호 및 비즈니스별 규칙을 허용하는 사용자(예: 역할 및 그룹 정보 포함)에 대한 신뢰할 수 있는 특성(예: X509 인증서, X509v3 특성 인증서, Kerberos 토큰, SAML 어설션)을 제공하는 문제도 처리합니다.

페더레이션된 Single Sign-On 및 ID의 개념과 개념은 간단한 예제를 사용하여 설명될 수 있습니다.

사용자 John Doe는 Pharma456.com;라는 제약 회사에서 일합니다. John은 Pharma456.com 계정이 있으며 리소스에 액세스하기 위해 Pharma456.com 인증해야 합니다. 직원으로서 John은 파트너 회사의 계정 및 서비스와 같은 회사에 특정 혜택을 제공합니다. 이 예제에서 회사의 저축 서비스는 RetireAccounts.com(서비스 공급자)라는 금융 서비스 회사에 의해 관리되고 투자 서비스는 InvestAccounts.com(서비스 공급자)라는 회사에서 관리됩니다. 파트너의 리소스(예: RetireAccounts.com 호스팅하는 저축 포털)에 액세스하려면 사용자가 RetireAccounts.com 인증해야 합니다. RetireAccounts.com 인증하려면 사용자가 SSN(사회 보장 번호), 직원 식별자(고용주가 발급한 고유 식별자- 이 경우 Pharma456.com) 및 개인 PIN 번호(RetireAccounts.com 관련)를 제공해야 합니다.

페더레이션 없이 John Doe는 이미 Pharma456.com 인증하고 Pharma456.com 직원 포털을 통해 RetireAcounts.com 웹 서비스에 액세스했음에도 불구하고 저축 계좌에 액세스하기 위해 RetireAccounts.com 사이트에 명시적으로 인증해야 합니다.

그러나 페더레이션된 Single Sign On을 사용하여 John Doe는 직원 포털에 로그온할 수 있으며, 포털 링크를 클릭하여 파트너 사이트(RetireAccounts.com)에서 저축 계좌 정보에 액세스하고 파트너 사이트에서 다시 인증하거나 추가 정보를 제공할 필요가 없습니다.

페더레이션은 또한 페더레이션 관리 기술을 사용하여 회사 간에 동일한 사용자에 대한 고유 ID를 두 회사 간에 안전하게 연결할 수 있도록 합니다. 페더레이션 참가자는 신뢰 회사가 도메인 내에서 사용자 ID의 유효성을 독립적으로 검사할 수 있도록 ID 정보를 교환할 수 있습니다.

발급 도메인(Pharma456.com)과 신뢰 도메인(페더레이션 서비스 공급자 RetireAccounts.com) 간에 페더레이션된 Single Sign-On은 사용자 식별자 및 기타 특성 관련 정보(예: 권한 부여 역할 및 그룹 멤버 자격, EmployeeID, SSN 및 PIN #과 같은 사용자 자격)의 안전하고 신뢰할 수 있는 전송을 용이하게 합니다. 페더레이션 ID 관리는 신뢰 당사자(RetireAccounts.com)가 발급자로부터 받은 (신뢰할 수 있는) 정보를 기반으로 사용자에 대해 로컬로 유효한 식별자를 확인할 수 있는 프로세스를 정의합니다. 전송 세부 정보에는 비즈니스와 사용자의 원본 엔터프라이즈(및 보조 서비스에 대한 메시지) 간에 여러 메시지가 포함될 수 있지만 이러한 메시지는 사용자에게 투명하게 처리됩니다.

페더레이션을 사용하도록 설정하기 위해 위의 그림에서 예시된 ID 공급자, 특성 서비스 및 가명 서비스를 소개합니다.

Pharma456.com, InvestAccounts.com 및 RetireAccounts.com ID 공급자는 로컬 매핑/인덱싱(예: 계정 정보)에 사용되는 ID를 제공합니다. 신뢰 및 페더레이션 메커니즘을 신뢰 정책과 함께 사용하면 이러한 ID를 통해 페더레이션이 ID를 자동으로 공유하고 매핑할 수 있습니다.

특성 서비스는 페더레이션 ID에 대한 권한 있는 특성에 대한 액세스를 페더레이션하는 방법을 제공합니다. 위의 예제에서 John Doe가 각 파트너의 포털을 방문할 때 포털 서비스는 필요한 정보를 얻고 환경을 개인 설정하기 위해 John의 특성(권한이 부여된 특성)에 액세스할 수 있습니다. 개인 정보를 보장하기 위해 John Doe는 어떤 특성이 어떤 서비스에 권한이 부여되는지 완전히 제어할 수 있습니다. 이러한 특성 액세스를 모니터링하고 기록하여 Pharma456.com 직원과 함께 설정된 명시된 개인 정보 보호 정책을 준수할 수 있습니다. 특정 유형의 특성 서비스를 의무화하지 않고 UDDI와 같은 다른 서비스를 사용하도록 허용합니다.

신뢰 메커니즘은 신뢰 당사자가 신뢰 수준을 기관 또는 ID와 연결하고 로컬 매핑에 사용할 수 있는 방법을 제공합니다. 그러나 개인 정보 보호 문제가 이 매핑이 대상 서비스에 불투명하게 되기를 바라는 상황이 있습니다. 즉, 대상은 John의 지역 페르소나를 기반으로 "John Doe"라는 것을 일관되게 알고 있지만 글로벌 정체성을 이해하거나 알지 못합니다. 가명 서비스는 개인 정보 보호 및 ID를 보호하기 위해 페더레이션 간에 신뢰할 수 있는 ID의 이 매핑을 용이하게 하는 데 사용할 수 있는 매핑 메커니즘을 제공합니다.

페더레이션 ID 관리(페더레이션 Single Sign-On 포함)는 웹 Single Sign On 솔루션보다 훨씬 광범위한 개념입니다. 이 예제에서는 웹 SSO가 중요한 기능인 B2C 시나리오의 사용 사례를 강조 표시하지만, 페더레이션된 Single Sign On은 기업이 보안 B2B 및 B2C 전자 비즈니스에 대한 완전한 프레임워크를 빌드할 수 있도록 하는 광범위한 개념입니다.

3. 페더레이션 ID 모델

페더레이션 ID 모델은 일관되고 확장 가능한 보안 모델을 형성하기 위해 웹 서비스 인프라 및 보안 사양을 기반으로 하고 통합할 있습니다. 페더레이션 모델은 WS-Trust 모델을 확장하여 ID 공급자가 보안 토큰 서비스 역할을 하는 방법과 특성 및 가명을 토큰 발급 메커니즘에 통합하여 페더레이션 ID 매핑 메커니즘을 제공하는 방법을 설명합니다.

요약하면 보안 주체는 ID 공급자(또는 보안 토큰 서비스)에서 로그인 및 로그아웃합니다. 이 작업은 명시적 메시지를 통해 또는 보안 주체가 토큰을 요청하는 암시적으로 수행할 수 있습니다. 보안 주체가 리소스/서비스에 대한 토큰을 요청하고 발급된 토큰은 보안 주체의 기본 ID 또는 범위에 적합한 일부 가명을 나타낼 수 있습니다. ID 공급자(또는 STS)는 관심 있는(및 권한 있는) 받는 사람에게 메시지를 발급합니다. 보안 주체는 특성/가명 서비스에 등록되고 특성 및 가명을 추가하고 사용합니다. 서비스는 제공된 ID를 사용하여 특성/가명 서비스를 쿼리할 수 있습니다(정보를 요청하는 당사자가 불투명 토큰을 가지고 있고 실제 ID를 인식하지 못했음을 의미하는 익명일 수 있습니다).

Web Services 보안 사양

이 문서에서 설명하는 모델 및 접근 방식은 백서에 설명된 사양, Web Services World의 보안: 제안된 아키텍처 및 로드맵활용합니다. 각 주요 사양은 아래에 요약되어 있습니다.

  • WS-Security SOAP 메시지에 서명 및 암호화 헤더를 연결하는 방법을 설명합니다. 또한 X.509 인증서 및 Kerberos 티켓과 같은 이진 보안 토큰을 포함한 보안 토큰을 메시지에 연결하는 방법을 설명합니다.
  • WS-Policy 중개자 및 엔드포인트(예: 필수 보안 토큰, 지원되는 암호화 알고리즘, 개인 정보 보호 규칙)에 대한 보안(및 기타 비즈니스) 정책의 기능 및 제약 조건과 정책을 서비스 및 엔드포인트와 연결하는 방법을 설명하는 일련의 사양을 나타냅니다.
  • WS-Trust 보안 토큰을 요청, 발급 및 교환하여 웹 서비스가 안전하게 상호 운용할 수 있도록 하는 신뢰 모델의 프레임워크를 설명합니다.
  • WS-Privacy 웹 서비스 및 요청자가 개인 정보 기본 설정 및 조직의 개인 정보 취급 방침을 명시하는 방법에 대한 모델을 설명합니다.
  • WS-SecureConversation 보안 컨텍스트 교환, 세션 키 설정 및 파생을 포함하여 당사자 간의 메시지 교환을 관리하고 인증하는 방법을 설명합니다.
  • WS-Federation 페더레이션 ID 지원, 특성 공유 및 가명 관리를 포함하여 다른 유형의 페더레이션 환경에서 트러스트 관계를 관리하고 중개하는 방법을 설명합니다.
  • WS-Authorization 권한 부여 데이터 및 권한 부여 정책을 관리하는 방법을 설명합니다.

또한 다른 몇 가지 주요 웹 서비스 사양은 사양의 기본 계층을 완료합니다.

  • WS-Addressing 메시지에 대한 식별 및 주소 지정 정보를 지정하는 방법을 설명합니다.
  • WS-MetadataExchange 서비스와 엔드포인트 간에 WS-Policy 정보 및 WSDL과 같은 메타데이터를 교환하는 방법을 설명합니다.
  • WS-ReliableMessaging 신뢰할 수 없는 네트워크가 있는 상태에서 신뢰할 수 있는 메시지 배달을 보장하는 방법을 설명합니다.
  • WS-Transactions 및 WS-Coordination 웹 서비스 메시지 교환의 일부로 트랜잭션된 작업을 사용하도록 설정하는 방법을 설명합니다.

위의 사양과 상호 운용성 프로필의 조합을 통해 고객은 페더레이션 및 보안 사양을 다른 웹 서비스 사양과 구성하여 페더레이션 내 및 페더레이션 간에 통합되는 상호 운용 가능한 신뢰할 수 있는 신뢰할 수 있는 트랜잭션 웹 서비스를 쉽게 빌드할 수 있습니다.

프로필

이 문서에서는 다양한 환경에서 사용할 수 있는 일반 모델을 설명합니다. 특히 이 모델은 웹 브라우저와 같은 수동 요청자 또는 SOAP 요청자와 같은 활성 요청자로 구성된 환경에서 사용할 수 있습니다.

페더레이션 사양은 일반 모델 및 프레임워크를 제공합니다. 프로필은 이러한 다양한 환경에서 모델이 적용되는 방법을 설명합니다. 모델을 다른 환경에 통합하기 위해 추가 프로필을 지정할 수 있습니다.

각 프로필 사양은 수동 또는 활성 요청자와 같은 지정된 환경에 WS-Federation 메커니즘이 적용되는 방법을 정의합니다.

따라서 이 문서에서 설명하는 메커니즘(ID 공급자, 로그인/로그아웃, 보안 토큰, 특성, 가명 등)은 수동 요청자(예: 웹 브라우저) 및 활성 요청자(예: 클라이언트 및 서비스 역할을 하는 웹 서비스)뿐만 아니라 나중에 정의될 수 있는 다른 프로필에도 적용됩니다.

ID 공급자

페더레이션은 ID의 개념으로 시작합니다. 즉, 요청자 또는 요청자의 대리자(해당 ID 데이터의 신뢰할 수 있는 소유자인 ID 공급자)는 ID를 어설션하고 ID 공급자는 이 어설션을 확인합니다. 그런 다음 페더레이션은 ID 공급자와 공급자의 ID 결정에 의존하는 공급자 간의 신뢰(직접, 조정 및 위임)의 함수가 됩니다. 때때로 신뢰 당사자는 여러 공급자의 ID(예: 수표, 신용 카드 및 운전 면허증의 ID 상관 관계)의 상관 관계를 지정하는 기능이 필요합니다.

STS(보안 토큰 서비스)는 일반적인 모델 및 메시지 집합을 사용하여 보안 토큰을 발급/교환하는 일반 서비스입니다. 따라서 모든 웹 서비스는 단순히 WS-Trust 사양을 지원하여 STS가 될 수 있습니다. 따라서 다양한 추가 서비스를 제공하는 다양한 유형의 보안 토큰 서비스가 있습니다. IP(ID 공급자) 최소한 피어 엔터티 인증을 수행하고 발급된 보안 토큰에서 ID 또는 소속 클레임을 만들 수 있는 특수한 유형의 보안 토큰 서비스입니다. 대부분의 경우 IP와 STS는 서로 교환할 수 있으며 이 문서 내의 많은 참조는 둘 다 식별합니다.

페더레이션 모델은 발급 및 페더레이션 ID를 포함하도록 토큰 발급 및 교환 메커니즘을 활용하여 WS-Trust 정의된 프레임워크를 기반으로 합니다.

다음 예제에서는 서비스에 액세스하기 위한 IP 및 STS의 가능한 조합을 보여 줍니다. 이 예제에서 (1) 요청자는 IP(Business456.com)에서 ID 보안 토큰을 가져온 다음 Fabrikam123용 STS에 어설션(보안 토큰)을 제공/제공합니다. Fabrikam123.com Business456.com 신뢰하고 권한 부여가 승인되면 STS는 요청자에게 액세스 토큰을 반환합니다. 그런 다음 요청자(3)는 요청에서 액세스 토큰을 사용하여 Fabrikam123.com.

이 예제에서 1단계의 응답은 Business456.com(신뢰할 수 있는 IP)로 서명되고 응답에서 반환된 보안 토큰은 Fabrikam123.com 상대적입니다(예: 발급).

아래에 설명된 대체 모델을 사용하면 서비스 Fabrikam123.com 가명 서비스에 보안 토큰을 등록하고 필요할 때 이 가명을 가져올 수 있습니다. 이렇게 하면 서비스에서 매핑을 관리하고 요청자에 대한 개인 정보 수준을 제공할 수 있습니다.

Single Sign-On 및 Sign-Out

이 문서 및 WS-Federation 사양에 설명된 모델은 서비스 관리 및 요청자 관리와 같은 사용자 세션 다양한 개념을 허용합니다. 서비스 관리 세션의 한 가지 예는 웹 브라우저 세션 내에서 쿠키를 만들고 관리하는 것입니다. 요청자 관리 세션의 예로는 토큰을 가져오고 일정 기간 동안 사용한 다음 만료 전에 토큰을 삭제하는 웹 서비스 요청자가 있습니다. 로그아웃 개념은 서로 다른 프로필에서 이러한 전환이 각 프로필에 적용되는 방식을 지정할 수 있도록 하기 위해 도입되었습니다.

Single Sign On 목적은 페더레이션된 도메인/영역의 웹 내에서 리소스에 액세스하는 데 필요한 보안 토큰을 설정하는 것입니다. 마찬가지로 페더레이션 로그아웃 페더레이션 내에 있을 수 있는 캐시된 상태 및 보안 토큰을 정리하는 데 사용됩니다. 이를 사용하려면 ID 공급자가 발급한 페더레이션 로그인 및 로그아웃 메시지를 로그인 및 로그아웃 작업의 권한 있는 당사자에게 제공하는 메커니즘이 필요합니다(따라서 필요한 설정/정리 작업을 수행할 수 있도록 허용).

특성 및 가명

앞에서 설명한 것처럼 ID(또는 페더레이션된 리소스)에 대한 정보를 얻을 수 있기를 원하며, 예를 들어 "hello" 인사말을 제공하거나 환경을 개인 설정하기 위해 요청자의 우편 번호를 가져오는 것과 같이 특성 서비스에서 제공할 수 있습니다. 이 사양을 사용하면 UDDI와 같은 다양한 유형의 특성 서비스를 사용할 수 있습니다.

이러한 정보는 권한 부여 규칙 및 개인 정보 의미 체계에 의해 제어되어야 합니다. 마찬가지로, 다른 특성이 다르게 공유되고 개인 정보 보호 및 보호 수준(예: 이름 및 성)이 다를 것으로 예상됩니다. 따라서 각 특성 식은 자체 액세스 제어 정책을 표현할 수 있어야 하며, 정책은 관련 범위 및 범위에 대해 말할 수 있는 보안 주체를 고려해야 합니다. 예를 들어 최종 사용자(사람)는 다음을 설정하려고 할 수 있습니다. "내 인트라넷의 내 서비스는 내 성을 액세스할 수 있는 반면 다른 서비스는 사용자의 명시적 권한 없이는 액세스할 수 없습니다."

특성 서비스는 기존 리포지토리를 활용할 수 있으며 일부 수준의 조직 또는 컨텍스트를 제공할 수 있습니다. 조직 네임스페이스 내에서 개별 보안 주체가 등록되고 XML에 표시되는 특성 속성 집합(기본적으로 이름이 문자열 속성 이름이고 값이 XML 요소인 이름/값 쌍)이 보안 주체와 연결됩니다.

각 특성에는 고유한 보안 권한 부여 규칙 및 개인 정보 보호 정책이 있을 수 있으므로 보안 주체가 정보 공개 대상과 방법을 제어할 수 있습니다.

다른 특성 서비스에는 정책 문서에 표현되는 다양한 기능이 있습니다.

특성 서비스 외에도 가명 서비스있을 수 있습니다. 가명 서비스를 사용하면 보안 주체가 다른 리소스/서비스 또는 다른 도메인/영역에서 서로 다른 별칭을 수 있습니다. 일부 ID 공급자는 보안 토큰에서 고정 ID를 사용합니다. 일부 시나리오에서는 토큰의 익명성을 보장하는 것이 바람직합니다. 가명에서는 이 익명성을 사용하도록 설정하는 메커니즘을 제공합니다. 보안 주체에 의해 결정되어야 하는 관리 효율성의 장단점이 있는 경우가 많습니다(즉, ID가 많을수록 관리 문제의 가능성이 커집니다).

경우에 따라 특성 및 가명 서비스가 결합되고 경우에 따라 별도의 서비스가 됩니다.

예를 들어 요청자는 자신의 기본 ID "Fred.Jones"를 사용하여 Business456.com 인증합니다. 그러나 Fabrikam123.com "Freddo"로 알려져 있습니다. 익명성을 유지하기 위해 Business456.com Fred.Jones가 로그인할 때마다 다른 ID를 발급할 수 있으므로 아래 그림의 3단계에서 설명한 대로 "익명"으로 표시됩니다. Fabrikam123.com Fabrikam123.com(4단계)에서 "Freddo"를 이 요청자의 로컬 이름으로 설정하고 익명 이름을 이해하는 가명 서비스가 "Freddo"에 대한 매핑을 제공하도록 할 수 있습니다.

다음에 요청자가 Business456.com IP에 로그인할 때(아래 1단계) "XYZ321@Business456.com"(아래 2단계)와 같은 새 식별자가 제공될 수 있습니다. Business456.com IP에 위에서 설명한 매핑이 있으므로 Fabrikam123.com 웹 서비스는 이제 Fabrikam123.com(아래 4단계)에서 XYZ321@Business456.com 대한 가명을 요청하고 이전에 설정한 내용을 다시 가져올 수 있습니다. 이 경우 "Freddo@Fabrikam123.com"(아래 5단계)입니다.

가명 서비스는 "XYZ321@Business456.com"을 Business456.com 알려진 ID로 백맵할 수 있기 때문에 이 작업을 수행할 수 있습니다. 이 백 매핑은 IP와 가명 서비스 간의 트러스트 관계에 따라 발생합니다. 마찬가지로 리소스와 가명 서비스(IP에 의해 부트스트랩될 수 있음) 간에는 리소스가 가명을 가져와서 설정할 수 있는 권한을 부여받을 수 있는 트러스트 관계가 있습니다.

또는 ID 공급자(또는 STS)가 가명 서비스와 함께 작동할 수 있습니다. 즉, 요청자는 ID 공급자(또는 STS)에게 지정된 신뢰 도메인/영역 또는 리소스/서비스에 대한 토큰을 요청합니다. STS는 가명을 찾고 아래 그림과 같이 지정된 리소스/서비스에서 사용할 수 있는 토큰을 발급합니다.

설명한 대로 이 페더레이션 ID 모델에서는 가명을 사용하여 개인 정보를 유지할 수 있는 다양한 접근 방식이 지원됩니다. 각 공급자와 보안 주체가 특정 요구 사항을 충족하는 적절한 솔루션을 선택할 수 있도록 관리 효율성과 개인 정보 보호의 특성이 다릅니다.

4 요약

이 문서에서는 당사자가 페더레이션의 다른 구성원의 정보를 발급하고 사용하고 개인 및 비즈니스 개인 정보를 유지하는 안전한 방식으로 페더레이션 간에 신뢰와 특성을 중개할 수 있도록 하는 통합 웹 서비스 페더레이션 모델을 제안합니다.

이 모델은 웹 서비스 보안 및 관련 사양과 통합되어 페더레이션 내 및 페더레이션 간에 요청자와 서비스 간에 안정적인 트랜잭션을 안전하게 수행할 수 있도록 합니다.

IBM과 Microsoft는 이것이 포괄적인 웹 서비스 보안 전략을 정의하는 중요한 단계라고 생각합니다.  그것은 우리가 지금까지 확인 한 도전과 솔루션을 반영합니다. 웹 서비스를 보호하기 위해 고객, 파트너 및 표준 조직과 계속 협력하면서 전략을 완료하는 데 필요한 추가 아이디어와 사양이 있을 것으로 기대합니다. 

용어

용어는 기술마다 다르기 때문에 이 문서에서는 다양한 보안 형식 및 메커니즘에 일관되게 적용될 수 있는 몇 가지 용어를 정의합니다. 따라서 여기서 사용되는 용어는 다른 사양과 다를 수 있으며 독자가 선호하는 어휘에 용어를 매핑할 수 있도록 정의됩니다.

수동 브라우저 - 수동 브라우저 광범위하게 지원되는 HTTP(예: HTTP/1.1)를 지원하는 HTTP 브라우저입니다.

활성 요청자 - 활성 요청자 WS-Security 및 WS-Trust에 설명된 것과 같은 웹 서비스 메시지를 발급할 수 있는 애플리케이션(웹 브라우저일 수 있음)입니다.

프로필 - 프로필 이 모델이 특정 요청자 클래스(예: 수동 또는 활성)에 적용되는 방법을 설명하는 문서입니다.

클레임 - 클레임은 엔터티(예: 이름, ID, 키, 그룹, 권한, 기능, 특성 등)에서 만든 선언입니다.

보안 토큰 - 보안 토큰 클레임 컬렉션을 나타냅니다.

서명된 보안 토큰 - 서명된 보안 토큰 특정 기관(예: X.509 인증서 또는 Kerberos 티켓)에서 어설션되고 암호화적으로 서명된 보안 토큰입니다.

소유 증명 - 소유 증명 메시지가 클레임된 ID에 의해 전송 및 생성되었음을 증명하는 메시지와 함께 제공되는 인증 데이터입니다.

소유 증명 토큰 - 소유 증명 토큰 전송 당사자가 소유 증명을 입증하는 데 사용할 수 있는 데이터를 포함하는 보안 토큰입니다. 일반적으로 단독으로는 아니지만 소유 증명 정보는 보낸 사람과 받는 사람 당사자에게만 알려진 키로 암호화됩니다.

다이제스트 - 다이제스트 옥텟 스트림의 암호화 체크섬입니다.

서명 - 서명 암호화 알고리즘으로 계산되고 데이터의 의도된 수신자가 서명을 사용하여 서명자가 서명한 이후 데이터가 변경되지 않은지 확인할 수 있는 방식으로 데이터에 바인딩된 값입니다.

STS(보안 토큰 서비스) - 보안 토큰 서비스 보안 토큰을 발급하는 웹 서비스입니다(WS-Security 및 WS-Trust참조). 즉, 신뢰할 수 있는 증거에 따라, 신뢰할 수 있는 사람에게 어설션을 만듭니다. 트러스트를 전달하기 위해 서비스에는 보안 토큰 또는 보안 토큰 집합과 같은 증명이 필요하며 자체 신뢰 문을 사용하여 보안 토큰을 발급합니다(일부 보안 토큰 형식의 경우 다시 발급 또는 공동 서명일 수 있음). 이는 신뢰 조정의 기초가 됩니다.

특성 서비스 - 특성 서비스 트러스트 영역 또는 페더레이션 내에서 보안 주체에 대한 정보(특성)를 유지하는 웹 서비스입니다. 이 컨텍스트에서 보안 주체라는 용어는 사람만이 아니라 모든 시스템 엔터티에 적용할 수 있습니다.

가명 서비스 - 가명 서비스 트러스트 영역 또는 페더레이션 내에서 보안 주체에 대한 대체 ID 정보를 유지하는 웹 서비스입니다. 이 컨텍스트에서 보안 주체라는 용어는 사람만이 아니라 모든 시스템 엔터티에 적용할 수 있습니다.

Trust - Trust는 한 엔터티가 두 번째 엔터티를 사용하여 작업 집합을 실행하거나 주체 및/또는 범위 집합에 대한 어설션 집합을 만들려는 특성을.

트러스트 도메인 - 트러스트 도메인 요청의 원본 및 대상이 원본의 특정 자격 증명 집합이 대상의 관련 보안 정책을 충족하는지 여부를 확인하고 합의할 수 있는 관리되는 보안 공간입니다. 대상은 트러스트 도메인에서 신뢰할 수 있는 제3자를 포함하여 타사에 대한 신뢰 결정을 연기할 수 있습니다.

유효성 검사 서비스 - 유효성 검사 서비스 WS-Trust 메커니즘을 사용하여 제공된 토큰의 유효성을 검사하고 신뢰 수준(예: 신뢰할 수 있는 클레임)을 평가하는 웹 서비스입니다.

직접 신뢰 - 직접 신뢰 신뢰 당사자가 요청자가 보낸 토큰의 클레임을 모두(또는 일부 하위 집합)로 수락하는 경우입니다.

직접 중개 신탁 - 직접 중개 신탁 한 당사자가 제 3 자의 클레임을 신뢰하거나 보증하는 제 2 자를 신뢰하는 경우입니다.

간접 중개 신탁 - 간접 중개 신탁 제 2 자가 제 1 자에 대한 제 3 자의 클레임의 유효성을 즉시 검사하고 제 3 자 또는 추가 당사자와 협상하여 클레임의 유효성을 검사하고 제 3 자의 신뢰를 평가할 수없는 직접 중개 신탁의 변형입니다.

메시지 인증 - 메시지 인증 받은 메시지가 보낸 메시지와 동일한지 확인하는 프로세스입니다.

보낸 사람 인증 - 보낸 사람 인증 웹 서비스 행위자/역할에서 웹 서비스 메시지의 보낸 사람(및 관련 데이터)을 나타내는 인증 증거를 확증합니다. 인증된 중개자가 있는 경우 메시지에 여러 보낸 사람이 있을 수 있습니다. 또한 메시지 발신자가 인증된 보낸 사람 뒤에 독립적이거나 숨겨질 수 있으므로 메시지를 처음 만든 사람을 결정하는 방법에 대한 애플리케이션 종속(및 범위 외)입니다.

영역 또는 도메인 - 영역 또는 도메인 보안 관리 또는 신뢰의 단일 단위를 나타냅니다.

페더레이션 - 페더레이션 트러스트를 설정한 영역/도메인의 컬렉션입니다. 신뢰 수준은 다를 수 있지만 일반적으로 인증을 포함하며 권한 부여를 포함할 수 있습니다.

ID 공급자 - ID 공급자 최종 사용자에게 피어 엔터티 인증 서비스 역할을 하고 서비스 공급자에 대한 데이터 원본 인증 서비스 역할을 하는 엔터티입니다(일반적으로 보안 토큰 서비스의 확장임).

SSO(Single Sign-On) - Single Sign-On 최종 사용자에게 적용된 반복 작업의 부담을 제거하기 위한 인증 시퀀스의 최적화입니다. SSO를 용이하게 하기 위해 ID 공급자라는 요소는 사용자를 대신하여 프록시 역할을 하여 사용자에 대한 정보를 요청하는 타사에 인증 이벤트의 증거를 제공할 수 있습니다. 이러한 ID 공급자는 신뢰할 수 있는 타사이며 사용자(이 정보가 손실되면 사용자 ID가 손상될 수 있으므로 사용자의 ID 정보를 유지 관리하기 위해) 및 IP에서 제공하는 ID 정보의 무결성에 따라 중요한 리소스 및 정보에 대한 액세스 권한을 부여할 수 있는 웹 서비스를 모두 신뢰할 수 있어야 합니다.

ID 매핑 - ID 매핑 ID 속성 간의 관계를 만드는 방법입니다. 일부 ID 공급자는 ID 매핑을 사용할 수 있습니다.

로그아웃 - 로그아웃 영역/도메인 또는 페더레이션에 대한 보안 토큰이 제거되는 프로세스입니다.

협회 - 협회 보안 주체가 트러스트 영역 또는 페더레이션과 연결되거나 관련되는 프로세스입니다.

참여자

이 문서는 IBM과 Microsoft가 공동으로 작성했습니다.

주요 기여는 포함 (사전순): 조반니 델라 - Libera, 마이크로 소프트; 브렌던 딕슨, Microsoft; Mike Dusche, Microsoft; 돈 퍼거슨, IBM; Praerit Garg, Microsoft; 팀 한, IBM; 헤더 힌튼, IBM; Maryann Hondo, IBM; Chris Kaler, Microsoft; 프랭크 레이만, IBM; Brad Lovering, Microsoft; 마루야마 히로시, IBM; 앤서니 나달린, IBM; 나타라즈 나가라트남, IBM; 벤카트 라가반, IBM; John Shewchuk, Microsoft

참조

© 2001-2003 International Business Machines Corporation. 모든 권한이 예약되어 있습니다.

이 문서는 예비 문서이며 시간이 지남에 따라 크게 변경될 수 있습니다. 이 문서에 포함된 정보는 발행일 기준으로 논의된 문제에 대한 International Business Machine 및 Microsoft Corporation의 현재 보기를 나타냅니다. IBM과 Microsoft는 변화하는 시장 상황에 대응해야 하므로 IBM과 Microsoft의 약정으로 해석되어서는 안 되며 IBM과 Microsoft는 게시 날짜 이후에 제시된 정보의 정확성을 보장할 수 없습니다.

이 문서에 포함된 정보의 프레젠테이션, 배포 또는 기타 보급은 IBM 또는 Microsoft 및 기타 타사에서 소유하거나 제어하는 지적 재산권에 대한 명시적 또는 묵시적 라이선스가 아닙니다.  IBM, Microsoft 및 기타 제3자는 이 문서의 주제를 다루는 특허, 특허 출원, 상표, 저작권 또는 기타 지적 재산권을 가질 수 있습니다.  이 문서의 제공은 IBM 또는 Microsoft 또는 다른 제3자의 특허, 상표, 저작권 또는 기타 지적 재산권에 대한 라이선스를 제공하지 않습니다. 예제 회사, 조직, 제품, 도메인 이름, 전자 메일 주소, 로고, 사람, 장소 및 여기에 설명된 이벤트는 가상입니다.  실제 회사, 조직, 제품, 도메인 이름, 전자 메일 주소, 로고, 사람, 장소 또는 이벤트와의 연결은 의도되거나 유추되어야 합니다.

본 문서와 여기에 포함된 정보는 "AS IS" 기준 및 관련 법률에서 허용하는 최대 범위까지 제공되며, IBM과 Microsoft는 AS IS 및 WITH ALL FAULTS 문서를 제공하며, 이에 따라 명시적, 묵시적 또는 법적 조건(명시적, 묵시적 또는 법적 보증을 포함하되 이에 국한되지 않음)을 부인합니다. 업무 또는 상품성 조건, 특정 목적에 대한 적합성, 응답의 정확성 또는 완전성, 결과, 장인 같은 노력, 바이러스 부족, 과실 부족 등 문서 관련 모든 것. 또한 문서와 관련하여 소유권, 조용한 즐거움, 조용한 소유, 설명에 대한 서신 또는 지적 재산권의 NON-INFRINGEMENT 보증 또는 조건이 없습니다.

어떠한 경우에도 IBM 또는 MICROSOFT는 계약, 불법 행위, 보증 또는 기타 계약 또는 이 문서와 관련된 다른 계약에서 발생하는 대체 상품 또는 서비스 조달 비용, 손실된 이익, 사용 손실, 데이터 손실 또는 부수적, 결과적, 직접적, 간접적 또는 특별 손해에 대해 다른 당사자에게 책임을 지지 않습니다. 그러한 당사자가 그러한 손해의 가능성에 대한 사전 통보를 했는지 여부.