KR101063368B1 - 연합 환경에서 신원 제공자를 위한 디지털 권리 관리(ｄｒｍ) 강화 정책 관리 - Google Patents

Abstract

신원 제공자에서 실시되는 방법은 소정의 콘텐츠와 연관된 디지털 권리 관리(DRM) 방식을 실시한다. 신원 제공자는 예컨대 서비스 제공자(예컨대, 콘텐츠 제공자), DRM 특권 제공자, 및 DRM 폴리시 제공자를 포함하는 하나 이상의 다른 실체와 함께 "연합(federation)"에 참여하는 실체이다. 일 실시예에서 본 방법은 신원 제공자가 DRM 폴리시에 대해 소정의 콘텐츠에의 접근을 요구하는 최종 사용자와 연관된 DRM 특권 세트를 얻고 평가하도록 함으로써 개시한다. 평가에 기초하여, 신원 제공자는 DRM 특권 세트에 대한 참조를 포함하는 싱글 사인 온(SSO) 메시지를 발생한다. 그런 다음에 메시지는 서비스 제공자 실체에 전송되고, 서비스 제공자 실체는 최종 사용자에게 응답을 제공한다.

디지털 권리 관리(DRM), 연합 환경, DRM 특권, DRM 폴리시, 싱글 사인 온(SSO)

Description

연합 환경에서 신원 제공자를 위한 디지털 권리 관리(ＤＲＭ) 강화 정책 관리{DIGITAL RIGHTS MANAGEMENT(DRM)-ENABLED POLICY MANAGEMENT FOR AN IDENTITY PROVIDER IN A FEDERATED ENVIRONMENT}

본 발명은 일반적으로 연합 환경에서 사용자 세션의 관리에 관한 것이다.

연합 환경(federated environments)은 본 기술분야에서 잘 알려져 있다. 미국 특허공개 제2006/0021018호(출원일: 2004년 7월 21일)가 대표적이다. 연합(federation)이란 사용자에게 싱글 사인 온(single-sign-on), 사용 편의성(ease-of-use experience)을 제공하도록 협력하는 기업, 조직, 기관 등과 같은 독립적인 실체들(entities)의 집합을 말하며, 연합 환경은 2개의 기업이 사용자에게 어떤 정보를 어떻게 전달할 것인지에 대해 정의하는 미리 설정된 직접적인 관계를 가질 필요가 없다는 점에서 통상의 싱글 사인 온 환경과는 다르다. 연합 환경 내에서 실체들은 사용자 인증, 다른 실체들이 제시한 인증 주장(authentication assertion)(예컨대 인증 토큰)의 승인, 사용자 보증자의 신원의 로컬 실체 내에서 이해되는 것으로의 일정 형태의 변환 제공을 처리하는 서비스를 제공한다. 연합은 서비스 제공업자가 지는 관리 부담을 덜어준다. 서비스 제공업자는 연합에 대한 그 신뢰 관계에 전적으로 의존할 수 있으며, 서비스 제공업자는, 사용자 인증 홈 도메인이나 신원 제공자에 의해 달성되는 인증에 의존할 수 있기 때문에, 사용자 패스워드 정보와 같은 인증 증보를 관리할 필요가 없다.

연합된 실체는 연합된 사용자들에 대한 신원 정보와 속성 정보를 제공하는 사용자 홈 도메인으로서 기능할 수 있다. 신원 정보, 신원 또는 인증 주장, 또는 신원 서비스를 제공하는 연합 컴퓨팅 환경 내의 실체는 신원 제공자라고 부른다. 동일 연합 내의 다른 실체나 연합 파트너들은 사용자 인증 신임장(credentials)의 1차적 관리, 예컨대 사용자 신원 제공자가 제공하는 싱글 사인 온 토큰의 승인에 의존할 수 있으며, 사용자가 인증하는 도메인은 사용자 (인증) 홈 도메인이라고 부를 수 있다. 신원 제공자는 신원 정보를 연합 컴퓨팅 환경 내의 다른 실체에 대한 서비스로서 제공하는 특정 형태의 서비스이다. 대부분의 연합 거래에서 대해서는, 통상적으로 인증 주장 발행측이 신원 제공자가 될 수 있으며, 다른 실체는 그 신원 제공자와 구별될 수 있다. 연합 컴퓨팅 환경 내에서 서비스를 제공하는 다른 실체는 서비스 제공자로 분류될 수 있다. 어떤 사용자다 신원 제공자에게 인증되고 나면, 그 연합 내의 다른 실체나 기업은 주어진 연합 세션이나 주어진 연합 거래의 지속 기간 중에는 서비스 제공자로만 간주될 수 있다.

디지털 권리 관리(DRM)는 디지털 콘텐츠를 안전하게 지키는 주지의 기술이다. DRM은 콘텐츠를 배포 전에 암호화하고, 그 콘텐츠를 이용할 진정한 라이센스를 취득한 최종 사용자에게만 접근을 허용한다. 통상적으로 DRM 라이센스 시행은 이용자/클라이언트 측에서 이루어진다. 완전한 DRM 시스템은 통상적으로 암호화, 비지니스 로직 및 라이센스-배송이라고 하는 몇 개의 파트로 구성된다. DRM은 콘텐츠를 암호화하는 것부터 시작한다. 콘텐츠가 암호화되고 나면 키가 크 콘텐츠의 암호를 풀어야(암호해독) 할 필요가 있다. 암호화된 콘텐츠는 주지의 전달 방법을 통해 최종 사용자에게 전달된다. 통상적으로 콘텐츠를 얻고자 하는 최종 사용자는 통상적으로 등록, 로그인 및/또는 지불 중 어느 하나와 관련된 비지니스 로직 프로세스와 거래하며, 이것이 완료되면 최종 사용자에게 그 콘텐츠를 이용할 라이센스가 발행된다. 발행된 라이센스는 통상적으로 (i) (콘텐츠를 해독하는) 키, (ii) 권리 집합(예컨대 한번만 이용, 30일 이용 등), 및 (iii) 라이센스가 발행된 최종 사용자 기계에만 유효하다는 속성을 포함한다. 최종 사용자가 DRM 보호 콘텐츠 이용을 시도하면 이용자는 먼저 라이센스가 로컬 기계 상에 존재하는지 여부를 체크하고, 만일 존재한다면 그 콘텐츠를 해독하여 구동이 시작된다. 라이센스가 없다면 이용자는 통상적으로 콘텐츠에 내장된 스토어프론트(storefront) URL로부터 라이센스 취득을 시도한다.

연합 환경에서 사용자 세션의 관리를 제공할 필요성이 있다.

신원 제공자에서 실시되는 방법은 소정의 콘텐츠와 연관된 디지털 권리 관리(DRM) 방식을 실시한다. 서비스 제공자는 통상적으로 콘텐츠 제공자이다. 신원 제공자는 예컨대 서비스 제공자(예컨대, 콘텐츠 제공자), DRM 특권 제공자, 및 DRM 폴리시 제공자를 포함하는 하나 이상의 다른 실체와 함께 "연합(federation)"에 참여하는 실체이다. 일 실시예에서 본 방법은 신원 제공자가 DRM 폴리시에 대해 소정의 콘텐츠에의 접근을 요구하는 최종 사용자와 연관된 DRM 특권 세트를 얻고 평가하도록 함으로써 개시한다. 평가에 기초하여, 신원 제공자는 DRM 특권 세트에 대한 참조를 포함하는 싱글 사인 온(SSO) 메시지를 발생한다. 그런 다음에 메시지는 서비스 제공자 실체에 전송되고, 서비스 제공자 실체는 최종 사용자에게 응답을 제공한다.

신원 제공자, 서비스 제공자, DRM 특권 제공자 및 DRM 폴리시 제공자 기능은 DRM 폴리시 작동가능 연합을 용이하게 한다. DRM 특권 제공자와 DRM 폴리시 제공자의 기능들 중 하나 또는 그 이상은 신원 제공자 및/또는 서비스 제공자와 통합될 수 있다.

상기 설명은 본 발명의 관계되는 특성들 중 일부를 약술한 것이다. 이러한 특성들은 예시적인 것으로만 해석되어야 한다. 다른 많은 유익한 결과는 하기에 설명되는 바와 같이 본 발명을 여러 가지로 적용하거나 변형함으로써 얻을 수 있다.

이제 도면을 참조하면 도 1A는 본 명세서에서 설명된 청구 대상을 구현할 수 있는 데이터 처리 시스템의 대표적인 네트워크를 도시한 도이다. 분산형 데이터 처리 시스템(100)은 이 분산형 데이터 처리 시스템(100) 내에서 서로 연결된 여러 가지 디바이스와 컴퓨터들 간의 통신 링크를 제공하는데 이용될 수 있는 매체인 네 트워크(101)를 포함한다. 네트워크(101)는 와어어나 광 파이버 케이블와 같은 영구적인 접속부, 또는 전화나 무선 통신을 통해 이루어지는 임시 접속부를 포함할 수 있다. 도시된 예에서 서버(102)와 서버(103)는 저장 유닛(104)과 함께 네트워크(101)에 연결된다. 그 외에도 클라이언트(105-107)도 네트워크(101)에 연결된다. 클라이언트(105-107)와 서버(102, 103)는 메인 프레임, 개인용 컴퓨터, PDA(personal digital assistance) 등과 같은 여러 가지 컴퓨팅 장치로 나타낼 수 있다. 분산형 데이터 처리 시스템(100)은 추가적인 서버, 클라이언트, 라우터, 다른 디바이스, 및 피어 투 피어(peer-to-peer) 구조(미도시)를 포함할 수 있다.

도시된 예에서 분산형 데이터 처리 시스템(100)은 LDAP(Lightweight Directory Access Protocol), TCP/IP(Transport Control Protocol/Internet Protocol), HTTP(HyperText Transport Protocol) 등과 같은 각종 프로토콜을 이용하여 서로 통신하는 전세계적 네트워크 및 게이트웨이 집단을 나타내는 네트워크(101)를 가진 인터넷을 포함할 수 있다. 물론 분산형 데이터 처리 시스템(100)은 예컨대 인트라넷, LAN(local area network) 또는 WAN(wide area network)과 같은 여러 가지 종류의 네트워크도 포함할 수 있다. 예컨대 서버(102)는 클라이언트(109)와 무선 통신 링크를 내장한 네트워크(110)를 직접 지원한다. 네트워크 작동 폰(111)은 무선 링크(112)를 통해 네트워크에 연결되며, PDA(113)는 무선 링크(114)를 통해 네트워크(110)에 연결된다. 폰(111)과 PDA(113)는 블루투쓰(Bluetooth™)나 무선 기술과 같이 소위 개인 영역 네트워크나 개인 애드훅 네트워크를 만들어내는 적당한 기술을 이용하여 무선 링크(115)를 통해 그들 자신들 간 에 데이터를 직접적으로 전달할 수도 있다. 유사하게 PDA(113)는 무선 통신 링크(116)를 통해 PDA(107)에 데이터를 전달할 수 있다.

여기서 청구 대상은 여러 가지 하드웨어 플랫폼과 소프트웨어 환경에서 구현될 수 있다. 도 1A는 본 발명의 구조적 한정으로서가 아니라 이종 컴퓨팅 환경의 예를 보여주기 위한 것이다.

이제 도 1B를 참조하면, 이 도는 도 1A에 도시된 것과 같이 본 발명이 구현될 수 있는 데이터 처리 시스템의 대표적인 컴퓨터 구조를 도시한 것이다. 데이터 처리 시스템(120)은 RAM(random access memory)(124), ROM(read-only memory)(126), 그리고 프린터(130)나 디스크 유닛(132)과 같은 각종 I/O 장치나, 또는 오디오 출력 시스템과 같은 다른 장치(미도시)를 지원하는 입/출력 어댑터(128)를 서로 연결하는 내부 시스템 버스(123)에 연결된 하나 또는 그 이상의 중앙 처리 장치(CPU)(122)를 포함한다. 시스템 버스(123)는 통신 링크(136)에의 액세스를 제공하는 통신 어댑터(134)에도 연결된다. 사용자 인터페이스 어댑터(148)는 키보드(140)와 마우스(142)와 같은 각종 사용자 장치니, 또는 터치 스크린, 첨필, 마이크로폰 등과 같은 다른 장치(미도시)를 연결한다. 디스플레이 어댑터(144)는 시스템 버스(123)를 디스플레이 장치(146)에 연결한다.

당업자라면 도 1B의 하드웨어가 시스템 구현에 따라 달라질 수 있음을 잘 알 것이다. 예컨대 이 시스템은 Intel®Pentium® 기반 프로세서나 디지털 신호 프로세서(DSP)와 같은 하나 또는 그 이상의 프로세서와 하나 또는 그 이상 종류의 휘발성 및 불휘발성 메모리를 가질 수 있다. 도 1B에 도시된 하드웨어에 부가하여 또 는 이 대신에 다른 주변 장치가 사용될 수 있다.

본 발명은 여러 가지 하드웨어 플랫폼 상에 구현될 수 있는 것 이외에도 여러 가지 소프트웨어 환경에서 구현될 수 있다. 통상적인 운영 체제를 이용하여 각 데이터 처리 시스템 내의 프로그램 실행을 제어할 수 있다. 예컨대 어떤 장치는 Unix® 운영 체제를 실행할 수 있고, 다른 장치는 간단한 Java® 런타임 환경을 포함할 수 있다. 대표적인 컴퓨터 플랫폼은 그래픽 파일, 워드 프로세싱 파일, XML(Extensible Markup Language), HTML(Hypertext Markup Language), HDML(Handhel Device Markup Language), WML(Wireless Markup Language) 및 기타 다른 여러 가지 포맷과 타입의 파일과 같은 여러 가지 포맷의 하이퍼텍스트 문서에 액세스하기 위한 주지의 소프트웨어 애플리케이션인 브라우저를 포함할 수 있다. 또한 도 1A에 도시된 분산형 데이터 처리 시스템은 여러 가지 피어 투 피어 서브네트와 피어 투 피어 서비스를 완전히 지원할 수 있음에 유의해야 한다.

몇 가지 현재 기술에 대한 상기 간략한 설명이 주어지면, 나머지 도면의 설명은 본 발명이 동작할 수 있는 연합 컴퓨터 환경에 관한 것이다. 그러나 본 발명을 더 자세히 설명하기 전에 몇 가지 기술용어에 대해 설명한다.

여기서 사용된 용어 "실체" 또는 "측"은 일반적으로 조직, 개인, 또는 조직, 개인 또는 다른 시스템을 대신하여 동작하는 시스템을 말한다. 용어 "도메인"은 네트워크 환경 내의 부가적은 특징을 의미하나, 용어 "실체", "측" 및 "도메인"은 호환적으로 사용될 수 있다. 예컨대 용어 "도메인"은 DNS(Domain Name System) 도메인, 또는 더 일반적으로는 외부 실체에게 논리적 유닛으로 보여지는 여러 가지 장치와 애플리케이션을 포함하는 데이터 처리 시스템을 말할 수도 있다.

용어 "요구"와 "응답"은 메시지, 통신 프로토콜 정보 또는 다른 관련 정보와 같이 특정 동작과 관련된 정보의 전달에 적합한 데이터 포맷팅을 포함하는 것으로 이해되어야 한다. 보호되는 자원은 액세스가 제어 또는 제한되는 자원(애플리케이션, 오브젝트, 문서, 페이지, 파일, 실행 코드, 또는 기타 다른 연산 자원, 통신 타입 자원 등)이다.

토큰은 성공적인 동작의 직접적인 증거를 제공하며 그 동작을 수행하는 실체에 의해 생성되는 것으로, 예컨대 성공적인 인증 동작 후에 발생되는 인증 토큰이다. 케르베로스(Kerberos) 토큰은 본 발명에서 사용될 수 있는 인증 토큰의 일례이다. 케르베로스에 대한 더 자세한 정보는 Kohl 등의 "The Kerberos Network Authentication Service(V5)"(Internet Engineering Task Force (IETF) Request for Comments(RFC) 1510, 09/1993)에서 볼 수 있다.

주장은 어떤 동작의 간접적인 증거를 제공한다. 주장은 신원, 인증, 속성, 인증 판단, 또는 기타 다른 정보 및/또는 동작의 간접적인 증거를 제공할 수 있다. 인증 주장은 인증 서비스는 아니지만 이 인증 서비스를 경청한 실체에 의한 인증의 간접적인 증거를 제공한다.

SAML(Security Assertion Markup Language) 주장은 본 발명에서 사용될 수 있는 가능한 주장의 일례이다. SAML은 비영리 글로벌 컨소시움인 OASIS(Organization for the Advancement of Structured Information Standards)에 의해 발표되었다. SAML은 다음과 같이 "Assertion and Protocol for the OASIS Security Assertion Markup Language(SAML)"(Committe Specification 01, 05/31/2002)에 기재되어 있다:

SAML(Security Assertion Markup Language)는 보안 정보 교환을 위한 XML 기반 프레임워크이다. 이 보안 정보는 주체(subject)에 대한 주장의 형태로 표현되며, 이 경우에 주체는 어떤 보안 도메인에서 어떤 신원을 가진 실체(인간 또는 컴퓨터)이다. 주체의 대표적인 예는 특정 인터넷 DNS 도메인에서 자신의 이메일 주소에 의해 식별되는 사람이다. 주장은 주체에 의해 수행되는 인증 행위, 주체의 속성, 및 주체가 특정 자원에 액세스하도록 허용되는지 여부에 대한 인증 판단에 대한 정보를 전달할 수 있다. 주장은 XML이 구성됨에 따라 표현되며 내포 구조(nested structure)를 가지며, 하나의 주장은 인증, 권한 부여 및 속성에 대한 몇 가지 서로 다른 내부 명령문을 포함할 수 있다. 인증 명령문을 포함하는 주장은 단순히 이미 발생한 인증 행위를 기술함에 유의한다. 주장은 SAML 기관, 즉 인증 기관, 속성 기관 및 폴리시 판단 포인트에 의해 발행된다. SAML은 클라이언트가 SAML 기관들로부터 주장을 요구하여 그들로부터 응답을 받을 수 있는 프로토콜을 정의한다. 이 프로토콜은 XML 기반 요구와 응답 메시지 포맷으로 구성되며, 여러 가지 많은 기본적인 통신 및 전송 프로토콜에 구속될 수 있으며, SAML은 현재로는 HTTP를 SOAP에 구속되는 것을 정의한다. SAML 기관은 그 응답을 작성하는데 있어 요구 시에 입력으로서 수신된 외부 폴리시 저장과 주장과 같은 여러 가지 정보원을 이용할 수 있다. 따라서 클라이언트가 항상 주장을 소모하는 동안에 SAML 기관은 주장의 제작자와 소비자 양자가 될 수 있다.

SAML 사양에 따르면 주장은 발행자가 작성한 하나 또는 그 이상의 명령문을 공급하는 정보 패키지이다. SAML에 따라서 발행자는 3가지 종류의 주장 명령문, 즉 특정 주체가 특정 시각에 특정 수단에 의해 인증된 인증; 특정 주체가 특정 자원에 액세스할 수 있도록 하는 요구가 승인 또는 거부된 인증; 및 특정 주체가 공급된 속성과 연관된 속성을 만들 수 있다. 뒤에 더 자세히 설명하겠지만 여러 가지 주장 포맷은 필요 시에 다른 주장 포맷으로 변환될 수 있다.

인증은 사용자가 또는 사용자를 대신하여 제공한 신용장 세트를 인가하는 프로세스이다. 인증은 사용자가 알고 있는 어떤 것, 사용자가 갖고 있는 어떤 것, 또는 사용자가 누구라고 밝혀주는 어떤 것, 즉 사용자에 대한 어떤 물리적 특징을 검증함으로써 달성된다. 사용자가 알고 있는 어떤 것은 사용자 패스워드와 같은 공유 비밀키, 또는 사용자 암호키와 같은 특정 사용자에게만 알려진 어떤 것을 검증하는 것을 포함할 수 있다. 사용자가 갖고 있는 어떤 것은 스마트카드나 하드웨어 토큰을 포함할 수 있다. 사용자에 대한 어떤 물리적 특징은 지문이나 망막 지도와 같은 생체 인식 입력을 포함할 수 있다. 사용자는 통상적으로는 자연인이나 반드시 그런 것은 아니고 기계, 컴퓨팅 장치, 또는 연산 자원을 사용하는 임의 형태의 데이터 처리 시스템일 수도 있음에 유의해야 한다. 또한 사용자는 통상적으로 단일의 고유 식별자를 처리하나 반드시 그런 것은 아니고, 어떤 시나리오에서는 복수의 고유 식별자가 단일 사용자와 연관될 수도 있음에 유의한다.

인증 신용장은 각종 인증 프로토콜에서 사용되는 챌린지(challenge)/응답 정보 세트이다. 예컨대 사용자명과 패스워드 조합은 가장 익숙한 형태의 인증 신용 장이다. 다른 형태의 인증 신용장으로는 여러 가지 형태의 챌린지/응답 정보, 공개 키 기반(PKI) 인증서, 스마트카드, 생체 인식 등을 포함한다. 인증 신용장은 인증 주장과는 구별되는데, 인증 신용장은 사용자가 인증 서버 또는 서비스와의 인증 프로토콜 시퀀스의 일부로서 제시하는 것이고, 인증 주장은 사용자의 인증 신용장에 대한 성공적인 제시와 검증에 대한 명령문으로서 뒤에 필요에 따라 실체들 간에 전송되는 것이다.

월드 와이드 웹에서는 사용자는 특정 도메인들 간의 정보 장벽에는 거의 상관없이 한 인터넷 도메인 상의 애플리케이션과 대화 중에 다른 도메인 상의 다른 애플리케이션으로 점프할 수 있을 것을 기대하고 들어온다. 즉, 사용자는 조직들이 상호연동해야 한다고 예상하지만 사용자는 도메인이 자신의 프라이버시를 침해하지 않기를 바란다. 이러한 사용자 예상은 많은 기업과 조직이 경쟁적인 인증 기술을 발표하고 있는 급속히 진화하는 이종 환경에서 존재한다.

본 발명의 청구 대상은 기업이 싱글 사인 온 경험을 사용자에게 제공할 수 있도록 하는 연합 모델 내에서 지원된다. 즉, 본 발명은 연합 이종 환경 내에서 구현될 수 있다. 연합 이종 환경으로부터 이익을 얻을 수 있는 거래의 일례로서, 사용자는 도메인에 인증되어 그 도메인이 거래와 관련될 수 있는 각 다운스트림 도메인에 적당한 주장을 제공하게 할 수 있다. 이러한 다운스트림 도메인은, 그 도메인과 이들 다른 다운스트림 도메인 간에 미리 설정된 주장 포맷이 없더라도, 인증 주장 및/또는 다른 형태의 주장을 이해하고 신뢰할 수 있을 필요가 있다. 주장을 인식하는 것 이외에도, 다운스트림 도메인은, 미리 설정된 신원 맵핑 관계가 없 더라도, 주장 내에 포함된 신원을 특정 도메인 내의 사용자를 나타내는 신원으로 변환할 수 있을 필요가 있다.

본 발명의 청구 대상은 연합 환경 내에서 지원된다. 일반적으로 기업은 자신의 사용자 레지스트리를 갖고 있으며, 자신의 사용자 세트와 관계를 유지한다. 각 기업은 통상적으로 이들 사용자를 인증하는 자신만의 고유한 수단을 갖고 있다. 그러나 본 발명에서 사용하는 연합 방식에 따르면 기업들은 한 기업 내의 사용자들이 기업 연합에의 기업 참여를 통해 가업 세트와의 관계에 영향을 줄 수 있도록 공동적으로 협력할 수 있다. 사용자에게는 마치 각 기업과 직접적인 관계가 있었던 것처런 연합 기업들의 자원에의 접근이 허용될 수 있다. 사용자들은 목적하는 각 비지니스에 등록할 필요가 없으며, 항상 그들 자신의 신원을 밝혀 인증받을 필요는 없다. 그러므로 이러한 연합 환경 내에서는 인증 방식은 정보 기술 분야에서 급속히 진화하는 이종 환경 내에서 싱글 사인 온 경험을 가능하게 한다.

본 발명에서 연합은 사용자에게 싱글 사인 온, 사용 편의성을 제공하도록 협력하는 기업과 같은 독립적인 실체나, 기업, 조직, 기관 등 내의 논리 유닛들의 집합을 말하며, 연합 환경은 2개의 기업이 사용자에게 어떤 정보를 어떻게 전달할 것인지에 대해 정의하는 미리 설정된 직접적인 관계를 가질 필요가 없다는 점에서 통상의 싱글 사인 온 환경과는 다르다. 연합 환경 내에서 실체들은 사용자 인증, 다른 실체들이 제시한 인증 주장(예컨대 인증 토큰)의 승인, 사용자 보증자의 신원의 로컬 실체 내에서 이해되는 것으로의 일정 형태의 변환 제공을 처리하는 서비스를 제공한다.

연합은 서비스 제공업자가 지는 관리 부담을 덜어준다. 서비스 제공업자는 연합에 대한 그 신뢰 관계에 전적으로 의존할 수 있으며, 서비스 제공업자는, 사용자 인증 홈 도메인이나 신원 제공자에 의해 달성되는 인증에 의존할 수 있기 때문에, 사용자 패스워드 정보와 같은 인증 증보를 관리할 필요가 없다.

본 발명을 지원하는 시스템은 느슨하게 결합된 인증, 사용자 등록, 사용자 프로파일 관리 및/또는 인정 서비스가 보안 도메인에 걸쳐 협력하는 토대를 구축하는 연합 신원 관리 시스템에도 관계한다. 연합 신원 관리에 따라서 이종 보안 도메인에 있는 서비스들은, 이들 이종 도메인에서의 기본 보안 메카니즘과 운영 체제 플랫폼에서 차이가 있을지는 몰라도, 안전하게 상호 연동하고 협력할 수 있다.

전술한 바와 같이, 그리고 뒤에 더 자세히 설명하겠지만, 연합 환경은 중요한 사용자 이익을 제공한다. 연합 환경 하에서는 사용자는 제2 실체에서 사영하기 위한 사용자에 대한 인증 주장을 발행하는 발행측 역할을 할 수 있는 제1 실체에서 인증될 수 있다. 그러면 사용자는 제1 실체가 발행한 인증 주장을 제2 실체에서 명시적으로 재인증할 필요없이 제시함으로써, 신뢰측(relying party)이라 불리는 제2의 독립적인 실체에서 보호되는 자원에 접근할 수 있다. 발행측으로부터 신뢰측으로 보내진 정보는 주장 형태로 되어 있으며, 이 주장은 명령문 형태의 각종 정보를 포함할 수 있다. 예컨대 주장은 사용자의 인증된 신원에 대한 명령문이거나, 특정 사용자와 연관된 사용자 속성 정보에 대한 명령문일 수 있다. 더욱이 이 정보는 신뢰측에 의해 사용되어, 신뢰측의 접근 제오 규칙, 신원 맵핑 규칙, 및 신뢰측에 의해 유지되는 사용자 속성에 기초하여 신뢰측 자원에의 접근권을 제공할 수 있다.

이제 도 2를 참조로 설명하면, 도 2의 블록도는 응답시 연합 환경 내의 다운스트림 실체에서 동작을 유발하는 제1 연합 기업에 대해 사용자가 개시한 거래에 관한 연합 환경의 전문 용어를 나타낸다. 도 2는 주어진 연합 동작에 대한 연합 내의 실체의 관점에 따라서 전문 용어가 다를 수 있음을 보여준다. 특히 도 2는 본 발명을 지원하는 컴퓨팅 환경이 신뢰의 이행성(transitivity)과 인증 주장 프로세스의 이행성을 지원하고, 도메인 또는 실체가 다른 도메인 또는 다른 실체가 주장한 신원에 대한 신뢰를 바탕으로 어떤 주장을 발행할 수 있음을 보여준다.

사용자(202)는 기업(204)의 보호 자원에 대한 요구를 통해 거래를 개시한다. 사용자(202)가 기업(204)에 의해 인증되었거나 거래 과정에서 기업(204)에 의해 결국 인증될 것이라면, 기업(204)은 이 연합 세션 동안에는 사용자 홈 도메인이라 불릴 수 있다. 이 거래가 기업(206)에 의한 어떤 형태의 동작을 필요로 하고 기업(204)이 기업(206)에게 어떤 주장을 전달한다고 가정하면, 기업(204)은 그 특정 동작에 관한 발행 실체이고, 기업(206)은 그 동작에 대한 신뢰 실체이다.

발행 실체는 신뢰 도메인이 사용할 주장을 발행하는데, 발행 실체는 반드시는 아니지만 보통은 사용자 홈 도메인 또는 사용자 신원 제공자이다. 그러므로 통상적으로는 발행측이 통상적인 인증 동작을 이용하여 사용자를 인증하였을 것이다. 그러나 발행측이 이전에 다른 발행측으로부터 주장을 수신한 신뢰측으로 역할했을 수도 있다. 즉, 사용자 개시 거래는 연합 환경 내의 일련의 기업을 통해 단계적으로 행해질 수 있기 때문에 수신측은 다운스트림 거래에 대한 발행측으로 역할할 수 있다. 일반적으로 사용자 대신에 인증 주장을 발행할 수 있는 실체는 발행측으로 역할할 수 있다.

신뢰 실체는 발행 실체로부터 주장을 수신하는 실체이다. 신뢰측은 사용자를 대신한 제3 측, 즉 발행 실체에 의해 발행된 주장을 승인하고, 신뢰하고 이해할 수 있으며, 이것은 일반적으로 적당한 인증 기관을 이용하여 인증 주장을 해석할 신뢰 실체의 의무이다. 신뢰측은 사용자 또는 다른 실체를 대신하여 제시된 주장에 의존하는 실체이다. 이런 식으로, 신뢰 실체에게 사용자와의 대화 세션의 일부로서 사용자 인증 신용장을 사용자에게 촉구할 것을 요구하는 대신에, 신뢰 실체에서의 싱글 사인 온 경험이 사용자에게 주어질 수 있다.

다시 도 2를 참조로 설명하면, 거래가 기업(206)이 기업(208)에 어떤 주장을 전달하게 하는 동작을 더 요구한다고 가정하면, 기업(206)은 후속 또는 2차 거래 동작에 대한 발행 실체로 역할하는 업스트림 실체이고, 기업(208)은 그 동작에 대한 신뢰 실체로 역할하는 다운스트림 실체이다. 이 경우에는, 후속 거래가 단 2개의 실체에 대해 설명될 수도 있지만, 기업(208)은 원 거래에 대한 다른 다운스트림 실체로 간주될 수 있다.

도 2에 도시된 바와 같이, 연합 실체는 연합 사용자에 대한 신원 정보와 속성 정보를 제공하는 사용자 홈 도메인으로 역할할 수 있다. 신원 정보, 신원 또는 인증 주장, 또는 신원 서비스를 제공하는 연합 컴퓨팅 환경 내의 실체는 신원 제공자라고 부를 수 있다. 이 연합 내의 다른 실체나 연합 파트너는 사용자 인증 신용장의 1차적 관리, 예컨대 사용자 신원 제공자가 제공한 싱글 사이 온 토큰의 승인 을 위해 신원 제공자를 신뢰할 수 있으며, 사용자가 인증되는 도메인은 사용자 (인증) 홈 도메인이라 부를 수 있다. 신원 제공자는 사용자 고용주, 사용자 ISP 또는 기타 다른 상업 실체에 의해 물리적으로 지원될 수 있다.

신원 제공자는 신원 정보를 서비스로서 연합 컴퓨팅 환경 내의 다른 실체에 제공하는 특정 형태의 서비스이다. 대부분의 거래에 대해서 인증 주장을 위한 발행측은 보통은 신원 제공자이며, 다른 실체는 이 신원 제공자와 구별될 수 있다. 연합 컴퓨팅 환경 내에서 서비스를 제공하는 다른 실체는 서비스 제공자로서 분류될 수 있다. 사용자가 신원 제공자에게 인증되고 나면, 그 연합 내의 다른 실체나 기업은 주어진 연합 세션 또는 주어진 연합 거래의 지속 기간 중에 단순히 서비스 제공자로서 간주될 수 있다.

어떤 상황에서는 사용에 대한 신원 제공자로서 역할할 수 있는 연합 환경 내의 복수의 실체가 있을 수 있다. 예컨대 사용자는 각각이 사용자에 대한 신원 제공자로서 역할할 수 있는 복수의 연합 도메인에서 계정을 가질 수 있으며, 이들 도메인은 반드시 다른 도메인에 대한 정보나 다른 도메인에서의 사용자 신원에 대한 정보를 가지는 것은 아니다.

예컨대, 사용자 인증 신용장을 생성하고 검증할 수 있는 기업이 복수개 있을 수 있기 때문에 하나의 연합 환경 내에는 신원 제공자로서 역할할 수 있는 복수의 기업이 있을 수 있겠지만, 연합 거래는 보통은 단 하나의 신원 제공자와만 관련된다. 만일, 예컨대, 연합 내에 사용자가 연합 등록 동작을 수행한 실체가 단 하나만 있기 때문에 사용자를 인증할 수 있는 연합 실체가 단 하나라면, 이 실체는 연 합 환경 전체에 걸쳐 사용자 거래를 지원하기 위하여 사용자 신원 제공자로서 역할할 수 있을 것으로 예상할 수 있다.

복수의 서비스 제공자의 상호 연동을 필요로 하는 어떤 연합 거래 내에서는 다운스트림 서비스 제공자는 업스트림 서비스 제공자로부터의 어떤 주장을 승인할 수 있으며, 업스트림 서비스 제공자가 신뢰측으로 역할하고 있는 다운스트림 서비스 제공자에 대한 발행 실체로서 역할할 수 있는 조건은 서비스 제공자들 간의 신뢰 관계 종류와 서비스 제공자들 간의 거래 종류에 따라 달라질 수 있다. 그러나 간단한 연합 거래의 범위 내에서는 발행 실체로 역할하는 실체는 단 하나뿐이다.

본 발명은 기존의 비연합 구조에 미치는 영향을 최소화하면서 기존 시스템에 연합 기반구조가 추가될 수 있는 주어진 컴퓨팅 환경 냉에서 지원될 수 있다. 그러므로 주어진 기업이나 서비스 제공자에서의 인증 동작을 포함한 동작들은 어떤 실체가 연합 환경 내에 참여할 수도 있다는 사실에 의해 반드시 변경되는 것은 아니다. 즉, 어떤 실체의 컴퓨팅 시스템이 연합 환경 내로 통합될 수 있을지라도 사용자는 기업과 비연합 방식으로 직접적으로 인증 동작을 포함하여 여러 가지 동작을 계속해서 수행할 수 있다. 그러나 사용자는 마치 주어진 실체와 비연합 방식으로 유사한 동작을 수행했던 것처럼 주어진 실체에 대해 연합 동작을 수행하면서 동일한 최종 사용자 경험을 가질 수 있다. 그러므로 주어진 기업이 연합에 참여할 때에 주어진 기업의 사용자 전부가 반드시 연합 거래에 참여하는 것은 아니며, 기업의 사용자들 중 일부는 연합 거래를 수행하지 않고 그 기업의 컴퓨팅 시스템과 대화할 수 있음에 유의해야 한다.

더욱이, 주어진 기업의 컴퓨팅 환경 내의 사용자 등록, 예컨대 컴퓨터 시스템 내의 사용자 계정 설정은 그 기업이 연합 환경에 참여할 수도 있다는 사실에 의해 반드시 바뀌는 것은 아니다. 예컨대 사용자는 여전히 연합 환경과 무관한 레거시 또는 이미 존재하는 등록 프로세스를 통해 도메인에 계정을 설정할 수 있다. 그러므로 어떤 경우에는 기업에서의 사용자 계정 설정은 기업이 연합 컴퓨팅 환경 내에 참여할 때에 연합에 걸쳐 유효한 계정 정보의 설정을 포함할 수도 하지 않을 수도 있다.

이제 도 3을 참조로 설명하면, 도 3의 블록도는 본 발명의 실시예를 지원하는데 이용될 수 있는 몇 가지 연합 구조 성분을 가진 주어진 도메인에서의 기존 데이터 처리 시스템의 통합을 나타낸다. 연합 환경은 사용자에게 여러 가지 서비스를 제공하는 연합 실체를 포함한다. 사용자(312)는 브라우저 애플리케이션(316)과 여러 가지 다른 클라이언트 애플리케이션(318)을 지원할 수 있는 클라이언트 장치(314)와 대화한다. 사용자(312)는 클라이언트 장치(314), 브라우저(316), 또는 사용자와 기타 다른 장치 및 서비스 간의 인터페이스로서 역할하는 기타 다른 소프트웨어와는 별개이다. 어떤 경우에는 하기의 설명에 따라, 클라이언트 애플리케이션 내에서 명시적으로 활동하는 사용자와 그 사용자를 대신하여 활동하는 클라이언트 애플리케이션 간을 구별할 수 있다. 그러나, 일반적으로는 요구자는 사용자를 대신하여 활동하는 것으로 볼 수 있는 클라이언트 기반 애플리케이션, 브라우저, SOAP 클라이언트 등과 같은 중개자이다.

브라우저 애플리케이션(316)은 HTTP 통신 성분(320)이나 마크업 랭귀지(ML) 해석기(322)와 같은 여러 가지 모듈을 포함하는, 이동 장치에서나 볼 수 있는 것 같은 통상의 브라우저일 수 있다. 브라우저 애플리케이션(316)은 플러그 인, 및/또는 웹 서비스 클라이언트(324)와 같은 가상 기계 런타임 환경을 필요로 할 수도 하지 않을 수도 있는 다운로드가능한 애플릿을 지원할 수도 있다. 웹 서비스 클라이언트(324)는 분산 환경에서 구조화되고 분류된 정보의 교환을 정의하기 위한 라이트웨이트(lightweight) 프로토콜인 SOAP(Simple Object Access Protocol)을 이용할 수 있다. SOAP는 3개의 파트, 즉 메시지 내에 무엇이 있고 이것을 어떻게 처리할 것인지를 기술하기 위한 프레임워크를 정의하는 엔벨로프(envelope); 애플리케이션 정의 데이터타입의 인스턴스를 표현하기 위한 인코딩 규칙 세트; 및 원격 프로시저 호 및 응답을 나타내기 위한 협약(convention)으로 이루어진 XML 기반 프로토콜이다. 사용자(312)는 브라우저 애플리케이션(316)을 이용하여 웹 기반 서비스에 접근할 수 있으나, 사용자(312)는 클라이언트 장치(314) 상의 다른 웹 서비스 클라이언트를 통해 웹 서비스에 접근할 수도 있다. 연합 동작들 중 일부는 연합 환경 내의 실체들 간에 정보를 교환하기 위해 사용자 브라우저를 통한 HTTP 리다이렉션(redirection)을 채용할 수 있다. 그러나 본 발명은 여러 가지 통신 프로토콜을 통해 지원될 수 있으며, HTTP 기반 통신에 한정되는 것은 의미하는 것은 아님에 유의해야 한다. 예컨대 연합 환경 내의 실체들은 필요 시에 직접 통신할 수 있으며, 메시지는 사용자의 브라우저를 통해 방향이 재설정될 필요는 없다.

본 발명의 청구 대상은 연합 환경을 위해 요구되는 성분들이 기존 시스템과 통합될 수 있게끔 지원될 수 있다. 도 3은 이들 성분을 기존 시스템에 대한 프론 트 엔드로서 구현하기 위한 일 실시예를 도시한 것이다. 연합 도메인에서의 기존 성분들은 도 4에 도시된 것과 유사한 방식으로 인증 서비스 런타임(ASR) 서버(332)를 포함하는 레거시 애플리케이션 또는 백 엔드 처리 성분(330)로 간주될 수 있다. ASR 서버(332)는 도메인이 애플리케이션 서버(334)에의 접근을 제어할 때에 사용자 인증을 담당하며, 애플리케이션 서버(334)는 보호 자원(335)을 생성, 검색 또는 지원하거나 처리하는 것으로 생각할 수 있다. 도메인은 애플리케이션 서버(334)에의 접근을 위해 사용자를 등록시키는 레거시 사용자 등록 애플리케이션(336)을 계속해서 사용할 수 있다. 레거시 동작에 대해 등록된 사용자를 인증하는데 필요한 정보는 기업 사용자 레지스트리(338)에 저장되며, 기업 사용자 레지스트리(338)는 마찬가지로 연합 성분에 접근할 수 있다.

연합 환경에 가입한 후에는 도메인은 연합 성분의 개입없이도 계속해 동작할 수 있다. 즉, 도메인은 사용자가 접점 서버 또는 접점 서버 기능을 구현하는 다른 성분을 통과하지 않고 특정 애플리케이션 서버나 다른 보호 자원에 직접적으로 계속해서 접근할 수 있도록 구성될 수 있으며, 이런 식으로 시스템에 접근하는 사용자는 통상적인 인증 흐름과 통상적인 접근을 경험할 것이다. 그러나 그렇게 하는데 있어 레거시 시스템에 직접 접근하는 사용자는 도메인의 접점 서버에 알려진 연합 세션을 설정할 수 없을 것이다.

도메인의 레거시 기능은 접점 서버(342)와, 그 자신이 보안 토큰 서비스(STS)(346)와 대화하는 신뢰 프록시 서버(344)(또는 더 간단하게, 신뢰 프록시(344) 또는 신뢰 서비스(344))(이들 서버는 뒤에 도 4를 참조로 더 자세히 설명 함)를 포함하는 연합 프론트 엔드 프로세싱(340)을 이용하여 연합 환경에 통합될 수 있다. 연합 구성 애플리케이션에 의해서 관리 사용자는 연합 프론트 엔드 성분이 연합 인터페이스 유닛(350)을 통해 레거시 백 엔드 성분과 대화할 수 있도록 연합 프론트 엔드 성분을 구성할 수 있다. 연합 기능은 독립적인 시스템 성분 또는 모듈에서 구현될 수 있다. 바람직한 실시예에서 연합 동작을 수행하기 위한 기능의 대부분은 하나의 연합 애플리케이션 내의 논리 성분 집합에 의해 구현될 수 있으며, 연합 사용자 라이프사이클 관리 애플리케이션(352)은 싱글 사인 온 프로토콜 서비스(SPS)(354)와 함께 신뢰 서비스(344)를 포함한다. 신뢰 서비스(344)는 연합 기능의 일부로서 신원 맵핑 동작, 속성 검색 등을 담당하는 신원 및 속성 서비스(IAS)(356)를 포함할 수 있다. 신원 및 속성 서비스(356)는 싱글 사인 온 동작 중에 싱글 사인 온 프로토콜 서비스(354)에 의해 채용될 수도 있다. 연합 사용자 레지스트리(358)는 연합 특정 목적을 위한 사용자 관련 정보를 유지하는 특정 상황에서 채용될 수 있다.

주어진 기업에서의 레거시 또는 기존 인증 서비스는 사용자명/패스워드나 스마트카드 토큰 기반 정보와 같은 여러 가지 잘 알려진 인증 방법이나 토큰을 이용할 수 있다. 그러나 본 발명을 지원하기 위한 바람직한 연합 컴퓨팅 시스템에서는 레거시 인증 서비스의 기능은 접점 서버를 이용하여 연합 환경에서 이용될 수 있다. 사용자는 접점 서버를 통과하지 않고 레거시 인증 서버에 직접적으로 계속해서 접근할 수 있으며, 이런 식으로 시스템에 접근하는 사용자는 통상적인 인증 흐름과 통상적인 접근을 경험할 것이며, 레거시 인증 시스템에 직접 접근하는 사용자 는 본 발명에 따라서 신원 증거로서 연합 인증 주장을 생성할 수 없을 것이다. 연합 프론트 엔드의 역할 중 하나는 접점 서버에서 수신된 연합 인증 토큰을 레거시 인증 서비스가 이해하는 포맷으로 변환하는 것이다. 그러므로 접점 서버를 통해 연합 환경에 접근하는 사용자는 반드시 레거시 인증 서버에게 다시 인증될 필요는 없을 것이다. 바람직하게는 사용자는 마치 인증 대화에 관여했던 것처럼 보이도록 접점 서버와 신뢰 프록시의 조합에 의해 레거시 인증 서비스에게 인증될 수 있다.

이제 도 4를 참조로 설명하면, 도 4의 블록도는 연합 구조 내의 몇 가지 성분이 신뢰 관계를 구축하는데 이용될 수 있는 방식의 예를 나타낸다. 연합 환경은 사용자에게 여러 가지 서비스를 제공하는 연합 기업 또는 그와 유사한 실체를 포함한다. 사용자는 클라이언트 자이 상의 애플리케이션을 통해 기업(410)과 같은 여러 실체에 있는 자원에의 접근을 시도할 수 있다. 기업(410)에서의 접점(POC) 서버(412)와 같은 각 연합 기업에서의 접점 서버는 기업(410)에 의해 지원되고 이용가능하게 되는 자원에 접근하려는 클라이언트로부터의 요구에 대한 연합 환경으로의 엔트리 포인트이다. 접점 서버는 기존의 비연합 구조, 예컨대 레거시 시스템 내의 기존 성분에 미치는 영향을 최소화하는데, 이는 접점 서버가 많은 연합 요구사항을 처리하기 때문이다. 접점 서버는 세션 관리와 프로토콜 변환을 제공하며, 인증 및/또는 속성 주장 변환을 개시할 수도 있다. 예컨대 접점 서버는 HTTP나 HTTPS 메시지를 SOAP로 또는 그 반대로 변환할 수 있다. 뒤에 더 자세히 설명하겠지만, 접점 서버는 주장을 변환하는 신뢰 프록시를 불러내는데도 이용될 수 있다. 예컨대 발행측으로부터 수신된 SAML 토큰은 수신측이 이해하는 케르베로스 토큰으 로 변환될 수 있다.

기업(410)의 신뢰 프록시(TP)(414)와 같은 신뢰 서비스(신뢰 프록시, 신뢰 프록시 서버라고도 함)는 연합 내의 2개의 실체 간에 신뢰 관계를 구축하고 유지한다. 신뢰 서비스는 일반적으로 발행측이 사용하는 포맷으로부터 수신측이 이해하는 포맷으로의 (뒤에 더 자세히 설명되는 보안 토큰 서비스를 통한) 인증 토큰 포맷 변환을 처리할 능력을 갖고 있다.

접점 서버와 신뢰 서비스를 함께 사용하면 연합 구조를 구현하는 것이 시스템의 기존의 비연합 세트에 영향을 미치는 것을 최소화한다. 그러므로 이 예시적인 연합 구조는 연합 실체가 기업, 도메인 또는 다른 논리적 또는 물리적 실체인지에 관계없이 연합 실체 당 적어도 하나의 접점 서버와 적어도 하나의 신뢰 서비스의 구현을 필요로 한다. 그러나 이 예시적인 연합 구조는 반드시 시스템의 기존의 비연합 세트에 대한 변경을 필요로 하는 것은 아니다. 바람직하게는 주어진 연합 실체에 대해서 하나의 신뢰 서비스가 있지만, 효용성을 위해 신뢰 서비스 성분의 복수의 인스턴스가 있을 수 있고, 또는 연합 실체 내의 여러 가지 더 작은 실체, 예컨대 기업 내의 독립적인 자회사에 대한 복수의 신뢰 서비스가 있을 수 있다. 주어진 실체는 하나 이상의 연합에 속할 수 있지만, 이 시나리오는 하나의 신뢰 서비스가 복수의 연합 내의 신뢰 관계를 관리할 수 있으므로 반드시 복수의 신뢰 서비스를 필요로 하는 것은 아니다.

신뢰 서비스의 한 가지 역할은 다른 도메인에 의한 필요한 토큰 타입 및/또는 그 도메인 내의 신뢰 서비스를 결정하거나 그 결정에 대한 책임을 지는 것일 수 있다. 신뢰 서비스는 발행측이 사용하는 포맷으로부터 수신측이 이해하는 포맷으로의 인증 토큰 포맷 변환을 처리하는 능력이나 책임을 가진다. 신뢰 서비스(414)는 기업(410)에 대해 발생하는 사용자 신원 변환 또는 속성 변환을 담당할 수도 있으며, 또는 이러한 담당은 도 3에 도시된 예컨대 신원 및 속성 서비스(356)와 같은 별개의 신원 및 속성 서비스에 의해 지원될 수 있다. 게다가 신뢰 서비스는 사용자의 실제 신원에 대한 추가 정보 없이도 사용자를 일의적으로 식별하는 사용자 신원의 대표자로서의 가명(aliases)의 구현을 지원할 수 있다. 더욱이 신뢰 프록시는 접점 서버가 사용할 인증 및/또는 세션 신용장을 발행할 수 있다. 그러나 신뢰 서비스는 지원을 위해 뒤에 더 자세히 설명하는 신뢰 브로커를 불러낼 수 있다. 신원 변환은 발행측에 알려진 사용자의 신원과 속성을 수신측에 의미있는 것으로 맵핑하도록 요구될 수 있다. 이 변환은 발행측에서의 신뢰 서비스나 수신측에서의 신뢰 서비스 또는 이 양자에서 불러내어 질 수 있다.

신뢰 서비스(414) 또는 전술한 별개의 신원 및 속성 서비스는 토큰 변환을 제공하고 토큰을 검증하고 발생하는 인증 서비스 런타임(ASR)(418)을 불러낼 보안 토큰 서비스(STS) 성분(416)으로 나타낸 내부화된 성분을 포함(또는 이와 대화)할 수 있다. 보안 토큰 서비스는 신원 변환을 포함할 수 있는, 신뢰 서비스가 요구하는 토큰 발행 및 검증 서비스를 제공한다. 그러므로 보안 토큰 서비스는 기존의 인증 서비스 런타임과의 인터페이스를 포함하며, 또는 이것은 인증 서비스 런타임을 서비스 그 차체에 내장한다. 보안 토큰 서비스 성분은 신뢰 서비스 내에 내부화되는 것이 아니라 예컨대 신뢰 서비스에 의해 불러 내어질 독립 성분으로 구현될 수도 있으며, 또는 예컨대 애플리케이션 서버의 일부인 거래 서버 내에 내부화될 수도 있다.

예컨대 보안 토큰 서비스 성분은 케르베로스 토큰을 발행하라는 요구를 수신할 수 있다. 토큰이 생성될 사용자의 인증 정보의 일부로서, 이 요구는 사용자명과 패스워드를 포함하는 바이너리 토큰을 포함할 수 있다. 보안 토큰 서비스 성분은 예컨대 LDAP 런타임(통상적인 런타임)에 대해 사용자명과 패스워드를 검증하고, 이 사용자에 대한 케르베로스 티켓을 생성하기 위해 케르베로스 KDC(Key Distribution Center)를 불러낼 것이다. 이 토큰은 기업 내에서 사용하기 위해 신뢰 서비스로 되돌아 가지만, 이 사용은 연합 내의 다른 도메인으로의 이송을 위해 토큰을 외부화하는 것을 포함할 수 있다.

사용자는 기업(410)과 기업(420)과 같이 연합 환경 내의 복수의 기업에 있는 자원에 접근하고자 할 수 있다. 기업(410)에 대해 전술한 바와 유사한 방식으로 기업(420)은 접점 서버(422), 신뢰 서비스(424), 보안 토큰 서비스(STS)(426) 및 인증 서비스 런타임(428)을 포함한다. 사용자는 각 기업과의 독립적인 거래를 직접적으로 개시할 수 있지만, 사용자는 연합 환경 전체에 걸쳐 단계적으로 행해지는 기업(410)과의 거래를 개시할 수 있다. 기업(410)은 특정 거래를 완료하기 위하여 기업(420)과 같은 연합 환경 내의 복수의 다른 기업과의 협력을 필요로 할 수 있으며, 이 경우에 사용자는 거래 개시 시에 이러한 필요성을 알지 못했을 수가 있다. 기업(420)은 다운스트림 실체로서 관련되며, 기업(410)은 필요하다면 사용자의 연합 거래를 진행시키기 위해 어떤 주장을 기업(420)에 제시할 수 있다.

신뢰 서비스가 관련 접점 서버가 수신한 인증 토큰을 해석하는 방법 및/또는 주어진 사용자 신원과 속성을 변환하는 방법을 모르는 경우가 있을 수 있다. 이 경우에는 신뢰 서비스는 신뢰 브로커(430)와 같은 신뢰 브로커 성분에서의 기능을 불러내도록 선택할 수 있다. 신뢰 브로커는 개별적인 신뢰 프록시/서비스와의 관계를 유지하며, 이에 따라 신뢰 서비스들 간의 타동적 신뢰를 제공한다. 신뢰 브로커를 이용하면 기업(410, 420)과 같은 연합 환경 내의 각 실체는 연합 환경 내의 각 실체와 복수의 개별적인 신뢰 관계를 구축하는 것이 아니라 신뢰 브로커와 신뢰 관계를 구축할 수 있다. 예컨대 기업(420)이 기업(410)에서 사용자에게 의해 개시된 거래에 대한 다운스트림 실체로서 관련될 때에는 기업(410)의 신뢰 서비스(414)는 기업(420)의 신뢰 서비스(424)가 필요하다면 신뢰 브로커(430)에서 지원을 불러냄으로써 신뢰 서비스(414)로부터의 주장을 이해할 수 있다는 것을 확신할 수 있다. 도 4는 하나의 신뢰 브로커를 가진 연합 환경을 보여주지만, 연합 환경은 복수의 신뢰 브로커를 가질 수 있다.

도 4는 별개의 실체들로서 접점 서버(412), 신뢰 서비스(414), 보안 토큰 서비스 성분(416) 및 인증 서비스 런타임(418)을 보여주지만, 이들 성분들이 반드시 독립된 성분으로 구현될 필요는 없다. 예컨대 이들 독립된 성분의 기능은 하나의 애플리케이션으로, 하나의 물리적 장치 상의 애플리케이션으로, 또는 복수의 물리적 장치 상의 분산된 애플리케이션으로 구현되는 것도 가능하다. 그 외에도 도 4는 어떤 기업에 대한 하나의 접점 서버, 하나의 신뢰 서비스 및 하나의 보안 토큰 서버를 보여주지만, 다른 구성은 각 기업에 대한 복수의 접점 서버, 복수의 신뢰 서비스 및 복수의 보안 토큰 서버를 포함할 수 있다. 접점 서버, 신뢰 서비스, 보안 토큰 서버, 및 기타 다른 연합 실체는 소프트웨어 애플리케이션, 오브젝트, 모듈, 소프트웨어 라이브러리 등과 같이 여러 가지 형태로 구현될 수 있다.

신뢰 서비스/STS는 사용자명과 패스워드 조합과 케르베로스 티켓과 같은 전통적인 신용장을 포함하는 여러 가지 인증 신용장과, 제3측이 생성한 인증 토큰을 포함하는 연합 인증 토큰 포맷을 승인하고 검증할 수 있다. 신뢰 서비스/STS는 인증 토큰을 그 밖의 인증의 증거로서 승인할 수 있다. 인증 토큰은 발행측에 의해 생성되며 사용자가 그 발행측에서 이미 인증되었다는 것을 표시하는데 사용된다. 발행측은 인증 토큰을 사용자의 인증된 신원을 주장하는 수단으로서 생성한다. 신뢰 서비스/STS는 속성 토큰 또는 통신 세션 또는 대화를 안전하게 하는데 사용되는 토큰, 예컨대 SSL 세션 식별자와 유사한 방식으로 세션 정보를 관리하는데 사용되는 토큰을 처리할 수도 있다.

보안 토큰 서비스는 필요에 따라 인증 서비스 런타임을 불러낸다. 인증 서비스 런타임은 사용자를 인증할 수 있는 인증 서비스를 지원한다. 인증 서비스는인증 응답을 통해 성공한 또는 실패한 인증 시도의 표시를 제공하는 인증 기관으로서 역할한다. 신뢰 서비스/STS는 인증 서비스, 예컨대 기존의 레거시 기반구조와 대화할 필요가 없는 웹 서비스의 새로운 설치가 있는 시나리오를 내부화할 수 있다. 그러지 않으면, 보안 토큰 서비스 성분은 인증 토큰의 검증을 위해 외부 인증 서비스를 불러낼 것이다. 예컨대 보안 토큰 서비스 성분은 사용자명/패스워드를 포함하는 토큰을 "언팩(unpack)"하여, 제시된 신용장을 검증하기 위하여 LDAP 서비 스를 이용하여 사용자 레지스트리에 접근할 수 있다.

애플리케이션 서버와 같은 다른 성분에 의해 사용되는 경우에는, 보안 토큰 서비스 성분은 레거시 인증 시스템에 대한 싱글 사인 온에 요구되는 토큰을 생성하는데 사용될 수 있으며, 이러한 기능은 도 3에 도시된 SPS(354)와 같은 싱글 사인 온 프로토콜 서비스 내의 기능과 결합되거나 이에 의해 대체될 수 있다. 그러므로 보안 토큰 서비스 성분은 내부용으로, 즉 기업 내에서, 그리고 외부용으로, 즉 연합 내의 기업 전체에 걸쳐 토큰 변환을 위해 사용될 수 있다. 내부용의 예로서, 웹 애플리케이션 서버는 IBM CICS(Customer Information Control System) 거래 게이트웨이를 통해 메인프레임과 인터페이스할 수 있다. CICS는 미션 크리티컬(mission-critical) 애플리케이션에 기업 레벨 온라인 거래 관리 및 접속성을 제공하는 애플리케이션 서버 및 커넥터의 계열이다. 웹 애플리케이션 서버는 (웹 애플리케이션 서버에 의해 내부적으로 사용된) 케르베로스 티켓을 CICS 거래 게이트웨이가 필요로 하는 IBM RACF® 패스티켓으로 변환하는 보안 토큰 서비스 성분을 불러낼 수 있다.

도 4에 도시된 실체는 "신원 제공자"와 "서비스 제공자"라는 전문 용어를 사용하여 설명될 수 있다. 신뢰 관계를 구축하고 유지하는 것의 일부로서, 신원 제공자의 신뢰 서비스는 서비스 제공자의 신뢰 서비스에 의해 요구되거나 승인되는 토큰 타입이 어떤 것인지를 판단할 수 있다. 따라서 신뢰 서비스는 보안 토큰 서비스로부터 토큰 서비스를 불러낼 때에 이 정보를 이용한다. 신원 제공자의 신뢰 서비스가 서비스 제공자에 대한 인증 주장을 생성하도록 요구받으면, 신뢰 서비스 는 요구된 토큰 타입을 결정하고 보안 토큰 서비스로부터 적당한 토큰을 요구한다.

서비스 제공자의 신뢰 서비스가 신원 제공자로부터 인증 주장을 수신하면, 신뢰 서비스는 예상한 주장의 타입이 어떤 것인지 그리고 서비스 제공자 내의 내부 사용을 위해 어떤 타입의 주장이 필요한지를 알게 된다. 그러므로 서비스 제공자의 신뢰 서비스는 보안 토큰 서비스가 수신된 인증 주장 내의 토큰에 기초하여 요구되는 내부 사용 토큰을 생성할 것을 요구한다.

신뢰 서비스와 신뢰 브로커 모두는 신원 제공자로부터 수신된 주장을 서비스 제공자가 이해하는 포맷으로 변환할 수 있다. 신뢰 브로커는 직접 신뢰 관계가 있는 신뢰 서비스들 각각에 대한 주장 포맷(또는 포맷들)을 해석할 수 있으며, 이에 따라 신뢰 브로커는 신원 제공자와 서비스 제공자 간의 주장 변환을 제공할 수 있다. 이 변환은 각 측에 의해 그 로컬 신뢰 서비스를 통해 요구될 수 있다. 따라서 신원 제공자의 신뢰 서비스는 어떤 주장이 서비스 제공자에게 보내지기 전에 그 주장의 변환을 요구할 수 있다. 마찬가지로 서비스 제공자의 신뢰 서비스는 신원 제공자로부터 수신된 주장의 변환을 요구할 수 있다.

주장 변환은 사용자 신원 변환, 인증 주장 변환, 속성 주장 변환, 또는 기타 다른 형태의 주장 변환을 포함할 수 있다. 전술한 이점을 반복하면, 주장 변환은 연합 내의 신뢰 성분, 예컨대 신뢰 서비스와 신뢰 브로커에 의해 처리된다. 신뢰 서비스는 신원 제공자나 서비스 제공자에서 로컬 방식으로 변환을 수행할 수 있으며, 또는 신뢰 서비스는 신뢰 브로커로부터 지원을 불러낼 수 있다.

신원 제공자와 서비스 제공자가 이미 신뢰 브로커와 개별적인 신뢰 관계를 갖고 있다고 가정하면, 신뢰 브로커는 필요에 따라 발행측들과 신뢰측들 간에 새로운 신뢰 관계를 동적으로 생성, 즉 중개할 수 있다. 신뢰 브로커에 의해 제공된 초기 신뢰 관계 중개 동작 후에, 신원 제공자와 서비스 제공자는 신뢰 브로커가 장래의 변환 요구를 위해 불러 내어질 필요가 없도록 관계를 직접적으로 유지할 수 있다. 인증 토큰의 변환은 3가지 가능한 장소, 즉 신원 제공자의 신뢰 서비스, 서비스 제공자의 신뢰 서비스, 및 신뢰 브로커에서 발생될 수 있음에 유의해야 한다. 바람직하게는 신원 제공자의 신뢰 서비스는 신뢰 브로커가 이해하는 인증 주장을 생성하여 서비스 제공자에게 보낸다. 그러면 서비스 제공자는 신뢰 브로커로부터의 이 토큰을 서비스 제공자가 인식할 수 있는 포맷으로 변환할 것을 요구한다. 토큰 변환은 인증 주장의 전송 전, 전송 후, 또는 전송 전과 후에 일어날 수 있다.

통상적으로는 관리되어야 하는 "신뢰 도메인"에는 2종류, 즉 기업 신뢰 도메인과 연합 신뢰 도메인이 있다. 이 2종류의 신뢰 도메인 간의 차이는 신뢰 도메인과의 신뢰 관계를 규정하는 비지니스 계약과 신뢰 구축에 이용된 기술에 기초한다. 기업 신뢰 도메인은 기업이 관리하는 성분을 포함하는데, 그 신뢰 도메인 내의 모든 성분은 서로 무조건적으로 신뢰할 수 있다. 일반적으로는, 전개된 기술은 예컨대 성분들 간의 상호 인증 SSL 세션을 요구함으로써 또는 물리적 제어와 근접이 절대적인 신뢰를 실증하도록 하나의 타이트하게 제어된 데이터 센터 내에 성분들을 배치함으로써 기업 내에 본래적인 신뢰를 만들어내기 때문에, 기업 내에 신뢰를 구축하도록 요구되는 비지니스 계약은 없다. 도 2B를 참조 설명하면, 레거시 애플리케이션과 백 엔드 처리 시스템은 기업 신뢰 도메인을 나타낼 수 있으며, 이 도메인 에서 성분들은 안전한 내부 네트워크 상에서 통신한다.

연합 신뢰 도메인은 기업 경계를 넘는 도메인으로서, 일 관점에서 보면, 연합 신뢰 도메인은 별개의 기업 신뢰 도메인들 간의 신뢰 관계를 나타낼 수 있다. 연합 신뢰 도메인은 연합 파트너들 간의 기업 경계를 넘는 신뢰 프록시를 통해 구축된다. 신뢰 관계는 신뢰 프록시들 간에 초기 신뢰가 구축되는 어떤 종류의 부트스트랩핑(bootstrapping) 프로세스와 관련이 있다. 이 부트스트랩 프로세스의 일부는 예상된 및/또는 허용된 토큰 타입 및 식별자 변환을 정의하는 공유 비밀 키 및 규칙의 설정을 포함할 수 있다. 일반적으로, 이 부트스트랩핑 프로세스는 이 프로세스가 연합에의 기업 참여와 이 참여와 연관된 책임을 규정하는 비지니스 계약의 설정을 포함할 수도 있으므로 아웃 오브 밴드(out-of-band)로 구현될 수 있다.

이 예시적인 연합 구조에서 신뢰 관계는 2개의 신뢰 프록시들 간의 기설정된 관계에 기초하여 신원 제공자로부터 수신되는 토큰을 검증하고 변환하는 보안 토큰 서비스를 포함(또는 이와 대화)할 수 있는 신뢰 프록시에 의해 관리된다. 그러나 연합 기업이 다른 연합 기업과 신뢰 관계( 및 토큰 변환)를 설정할 수 없는 상황에서는 그 연합 기업은 신뢰 브로커와 어떤 관계를 설정할 필요가 있다.

이제 도 5를 참조로 설명하면, 도 5의 블록도는 예시적인 연합 구조에 따라서 신뢰 프록시와 신뢰 브로커를 이용하는 연합 도메인들 간의 예시적인 신뢰 관계 세트를 나타낸다. 도 4는 신뢰 브로커를 도입했지만, 도 5는 이 예시적인 연합 구조 내의 타동적인 신뢰 관계의 중요성을 보여준다.

연합 도메인(502-506)은 각각 신뢰 프록시(508-512)를 내포하고 있다. 신뢰 프록시(508)는 신뢰 프록시(510)와 직접적인 신뢰 관계(514)를 갖고 있다. 신뢰 브로커(520)는 신뢰 프록시(510)와 직접적인 신뢰 관계(516)를 갖고 있고, 신뢰 브로커(520)는 신뢰 프록시(512)와 직접적인 신뢰 관계(518)를 갖고 있다. 신뢰 브로커(520)는 연합 참여자를 대신하여 다른 연합 파트너와 타동적 신뢰에 기초하여 신뢰 관계를 설정하는데 사용된다. 타동적 신뢰의 원리에 따라서 신뢰 프록시(510)와 신뢰 프록시(512)는 신뢰 브로커(520)를 통해 중개된 신뢰 관계(522)를 가질 수 있다. 신뢰 프록시(510)와 신뢰 프록시(512)는 어느 것도 다른 프록시의 주장을 변환하거나 검증하는 방법을 알 필요가 없으며, 신뢰 브로커는 주장을 다른 신뢰 프록시에서 유효하고, 신뢰되고 이해되는 주장으로 변환하도록 불러내어질 수 있다.

연합 기업들 간의 신뢰 관계에 대한 계약상의 의무와 채무를 규정하는 비지니스 계약은 ebXML(Electronic Business XML) 표준을 이용하여 XML로 표현될 수 있다. 예컨대 직접적인 신뢰 관계는 ebXML 문서로 나타낼 수 있으며, 작접적인 신뢰 관계를 공유하는 각 연합 도메인은 ebXML 문서로 표현된 계약의 사본을 가질 것이다. 연합 내의 여러 실체에 대한 동작 특징은 ebXML 코레오그래피(choreographies) 내에서 특정되고 ebXML 레지스트리 내에 공시될 수 있으며, 예컨대 신뢰 프록시나 신뢰 브로커를 작동시키기 위해 특정 연합에 참여하기를 원하는 기업은 그 연합 내의 모든 신뢰 프록시나 신뢰 브로커에 대해 그 특정 연합에 의해 특정된 공시된 요구 사항에 따를 필요가 있다. 보안 토큰 서비스는 다른 도 메인으로부터의 토큰이 변환되어야 할 방식에 대한 동작 세부 사항을 위해 이들 ebXML 문서를 해석할 수 있다. 그러나 연합 내의 신뢰 관계가 구현되는 방식에 대한 세부 사항을 특정하기 위해 본 발명을 지원하는 데는 다른 표준과 메카니즘이 이용될 수 있음에 유의해야 한다.

주어진 사용자의 세션 중에 사용자는 많은 연합 도메인을 방문하여 이 도메인들이 제공하는 웹 서비스를 이용할 수 있다. 도메인은 XML을 공통의 데이터 포맷으로 사용하는 UDDI와 WSDL과 같은 표준 사양을 이용하여 제공하는 서비스의 설명을 공시할 수 있다. 사용자는 이들 표준 사양에 붙어있는 애플리케이션을 통해 가용 서비스와 서비스 제공자를 찾는다. SOAP는 XML로 표현된 요구와 응답을 전달하기 위한 패러다임을 제공한다. 연합 환경 내의 실체는 특히 이들 표준을 채용할 수 있다.

연합 내에서 사용자는 하나의 인증 동작을 완료하는 싱글 사인 온 경험을 갖기를 기대하며, 이 인증 동작은 그 세션 중에 방문한 연합 파트너와는 상관없이 사용자의 세션의 지속 기간 동안에는 충분하다. 세션은 초기 사용자 인증, 즉 로그온부터 로그아웃까지의 거래 집합으로 정의될 수 있다. 세션 내에서 사용자 행위는 그 세션 동안 사용자에게 부여된 특권에 의해 부분적으로 규율될 것이다.

전술한 연합 구조는 싱글 사인 온 동작을 지원한다. 싱글 사인 온 경험을 용하게 하기 위하여, 연합 환경을 지원하는 웹 서비스는 제3측이 생성한 인증 주장 또는 보안 토큰을 이용하여 사용자의 인증 증거를 제공하는 것도 지원할 것이다. 이 주장은 그 사용자에 대한 식별자와 함께 발행측에서의 성공적인 사용자 인증의 어떤 종류의 증거를 포함할 것이다. 예컨대 사용자는 예컨대 연합 파트너가 사용자를 위한 인증 신용장을 구축하는데 사용하는 사용자명과 패스워드를 제공함으로써 하나의 연합 파트너와의 전통적인 인증 동작을 완료할 수 있으며, 그러면, 연합 파트너는 인증/발행측에 의해 생성된 SAML 인증 주장을 다른 연합 파트너에게 제공할 수 있다.

또한 연합 환경에 의해서 웹 서비스 또는 다른 애플리케이션은 웹 서비스를 요구할 수 있으며, 이들 웹 서비스도 인증될 것이다. 웹 서비스 환경에서의 인증은 기업이 인가된 클라이언트에의 접근을 제한할 수 있도록 웹 서비스 요구의 주장된 신원을 검증하는 행위이다. 웹 서비스를 요구하거나 불러내는 사용자는 거의 항상 인증될 것이며, 따라서 본 발명을 지원하는 연합 환경 내의 인증 필요성은 사용자 인증을 위한 웹 서비스의 현재 요구 사항과는 전혀 다르지 않다.

연합 세션에 참여하지 않고 기업의 연산 자원에 접근하고 있는 사용자의 인증은 연합 기반구조의 존재에 의해 영향을 받지 않는다. 예컨대 특정 도메인에 있는 비연합 자원에 접근하기 위해 HTTP/S를 통해 폼 기반(forms-based) 인증 메카니즘으로 인증되는 기존 사용자는 연합 환경을 위한 도메인에서의 지원의 도입에 의해 영향을 받지 않는다. 인증은 접점 서버에 의해 부분적으로 처리되며, 이 서버는 별도의 신뢰 프록시나 신뢰 서비스 성분을 불러낼 수 있으며, 접점 서버의 이용은 기존 도메인의 기반구조에 미치는 영향을 최소화한다. 예컨대 접점 서버는 그 도메인에서의 백 엔드 또는 레거시 애플리케이션과 시스템에 의해 처리될 모든 비연합 요구를 통과하도록 구성될 수 있다.

접점 서버는 기본 인증, 폼 기반 인증 또는 기타 다른 인증 방법과 같은 HTTP 기반 인증 방법을 불러내도록 선택할 수 있다. 접점 서버는 기업 도메인들 간에 넘어갔던 SAML 인증 주장과 같이 사용자가 인증의 증거로서 제시한 주장의 처리를 지원함으로써 연합 도메인도 지원하며, 싱글 사인 온 프로토콜 서비스는 연합 프로토콜의 콘텍스트에서 수신될 때에 주장/아티팩트를 인식하는데 사용된다. 접점 서버는 신뢰 서비스를 불러낼 수 있으며, 이어서 인증 신용장/보안 토큰의 검증을 위해 그 보안 토큰 서비스를 불러낼 수 있다.

웹 서비스 또는 다른 애플리케이션의 인증은 사용자 인증과 동일한 프로세스를 포함한다. 웹 서비스로부터의 요구는 인증 주장을 포함하는 보안 토큰을 담고 있으며, 이 보안 토큰은 사용자가 제시한 토큰과 동일한 방식으로 신뢰 서비스에 의해 검증될 것이다. 웹 서비스로부터의 요구는, 웹 서비스가 UDDI 에서 광도된 요구된 서비스가 어떤 인증 주장/보안 토큰을 필요로 하는지를 알았을 것이므로, 이 토큰에 의해 달성되어야 한다.

이제 도 6을 참조로 설명하면, 도 6의 블록도는 연합 싱글 사인 온 동작을 지원하는 연합 환경을 나타낸다. 사용자(600)는, 클라이언트 장치와 브라우저와 같은 적당한 클라이언트 애플리케이션을 통해, 연합 환경 내에서 연합 도메인으로 역할하는 데이터 처리 시스템을 지원하는 기업/도메인(610)이 제공하는 웹 서비스에 접근하고자 한다. 도메인(610)은 접점 서버(612)와 신뢰 프록시 또는 신뢰 서비스(614)를 지원하며, 마찬가지로, 도메인(620)은 접점 서버(622)와 신뢰 프록시 또는 신뢰 서비스(624)를 지원하며, 도메인(630)은 접점 서버(632)와 신뢰 프록시 또는 신뢰 서비스(634)를 지원한다. 신뢰 프록시/서비스는 전술한 바와 같이 지원을 위한 신뢰 브로커(650)를 신뢰한다. 추가적인 도메인과 신뢰 프록시/서비스는 연합 환경에 참여할 수 있다. 도 6은 도메인(610)과 도메인(620) 간의 연합 싱글 사인 온 동작을 설명하는데 이용되며, 도메인(610)과 도메인(630) 간에는 유사한 동작이 일어날 수 있다.

사용자는 도메인(610)에 대한 인증 동작을 완료하며, 이 인증 동작은 접점 서버(612)에 의해 처리된다. 인증 동작은 사용자가 예컨대 접근 제어 목적으로 또는 개인화 목적으로 인증 신원을 요구하는 어떤 자원에의 접근을 요구할 때에 기동된다. 접점 서버(612)는 레거시 인증 서버를 불러낼 수 있으며, 또는 이것은 사용자가 제시한 인증 신용장을 검증하는 신뢰 프록시(614)를 불러낼 수 있다. 도메인(610)은 사용자의 연합 세션의 지속 기간 중에 사용자의 신원 제공자 또는 홈 도메인이 된다.

시간적으로 좀 더 뒤의 시점에서 사용자는 연합 도메인을 지원하기도 하는 연합 파트너에서 거래를 개시하여, 연합 싱글 사인 온 동작을 기동한다. 예컨대 사용자는 도메인(620)에서 새로운 거래를 개시할 수 있고, 또는 사용자의 원 거래는 다른 도메인에서 하나 또는 그 이상의 추가적인 거래로 단계적으로 행해질 수 있다. 다른 예로서, 사용자는 예컨대 도메인(610) 내에 호스트된 웹 페이지 상의 특별 링크를 선택함으로써 또는 도메인(610) 내에 호스트되나 도메인(620) 내에 호스트된 자원을 디스플레이하는 포털 페이지를 요구함으로써 접점 서버(612)를 통해 도메인(620) 내의 자원에 대한 연합 싱글 사인 온 동작을 불러낼 수 있다. 접점 서버(612)는 도메인(620)이 이해하거나 신뢰하도록 포맷된 사용자를 위한 연합 싱글 사인 온 토큰을 생성하는 신뢰 프록시(614)에 어떤 요구를 보낸다. 신뢰 프록시(614)는 이 토큰을 접점 서버(612)에 되돌려 보내고, 이 서버는 이 토큰을 도메인 내의 접점 서버(622)에 보낸다. 도메인(610)은 신뢰측으로 역할하는 도메인(620)에서 사용자를 위한 발행측으로 역할한다. 사용자의 토큰은 사용자의 요구를 가지고 도메인(620)에 전달되는데, 이 토큰은 사용자의 브라우저를 통해 HTTP 리다이렉션을 이용하여 보내질 수 있으며, 또는 이것은 신뢰 프록시(614)가 공급한 토큰에서 식별된 사용자를 대신하여 접점 서버(622)의 요구를 (HTTP 또는 SOAP-오버-HTTP를 통해) 바로 불러냄으로써 보내질 수 있다.

접점 서버(622)는 그 요구를 연합 싱글 사인 온 토큰과 함께 수신하여 신뢰 프록시(624)를 불러낸다. 신뢰 프록시(624)는 연합 싱글 사인 온 토큰을 수신하고, 그 토큰을 검증하고, 그리고 그 토큰이 유효하고 신뢰되는 것이라고 가정하면, 사용자를 위해 로컬적으로 유효한 토큰을 발생한다. 신뢰 프록시(624)는 로컬적으로 유효한 토큰을 접점 서버(622)에 돌려보내고, 이 서버는 도메인(620) 내에 사용자를 위한 세션을 설정한다. 필요하다면 접점 서버(622)는 다른 연합 파트너에서 연합 싱글 사인 온을 개시할 수 있다.

도메인(620)에서의 토큰의 검증은 어쩌면 보안 토큰 서비스로부터 지원을 받아 신뢰 프록시(624)에 의해 처리된다. 도메인(610)이 제시한 토큰의 종류에 따라서 보안 토큰 서비스는 도메인(620)에서 사용자 레지스트리에 접근할 필요가 있을 수 있다. 예컨대 도메인(620)은 도메인(620)에서 사용자 레지스트리에 대해 검증 될 사용자명과 패스워드를 포함하는 바이너리 보안 토큰을 제공할 수 있다. 그러므로 이 예에서 기업은 단순히 연합 파트너로부터의 보안 토큰을 검증한다. 도메인들(610, 620) 간의 신뢰 관계는 도메인(620)이 사용자를 대신하여 도메인(610)이 제시한 보안 토큰을 이해하고 신뢰할 수 있는 것을 보장한다.

연합 싱글 사인 온은 사용자를 대신하여 신뢰 도메인에 제시된 보안 토큰의 신뢰 도메인에서의 검증뿐만 아니라, 신뢰 토큰에 포함된 정보에 기초하여 로컬적으로 유효한 사용자 식별자와 이 식별자와 연관된 가능한 속성의 결정을 요구한다. 직접 신뢰 관계와 그와 같은 관계를 설정하는데 필요한 비지니스 계약의 한가지 결과는 적어도 일측, 즉 발행 도메인이나 신뢰 도메인, 또는 이 양자가 발행 도메인이 제공한 정보를 신뢰 도메인에서 유효한 식별자로 변환하는 방법을 알 것이라는 것인데, 신뢰 도메인에서의 이 식별자는 발행측이 주장한 신원의 1 대 1 맵핑의 결과 또는 다른 형태의 맵핑, 예컨대 신원의 어떤 역할에의 다 대 1 맵핑의 결과일 수 있다. 즉, 이것이 로컬 발행측 식별자에 대한 유일한 1 대 1 맵핑이어야 한다는 것은 필요 요건이 아니다. 위의 간단한 예에서는 발행 도메인, 즉 도메인(610)이 신뢰 도메인, 즉 도메인(620)에게 도메인(620)에서 유효한 사용자 식별자를 제공할 수 있는 것으로 가정하였다. 그 시나리오에서는 신뢰 도메인은 신원 맵핑 기능을 불러낼 필요가 없었다. 도메인(620)에서의 신뢰 프록시(624)는 이 사용자를 "보증"할 사용자에 대한 보안 토큰을 발생할 것이다. 승인되는 토큰의 종류, 토큰에 대해 요구되는 서명, 및 기타 다른 요구 사항은 모두 연합의 비지니스 계약의 일부로서 미리 설정된다. 식별자 변환을 규율하는 규칙과 알고리즘도 연합의 비지 니스 계약의 일부로서 미리 설정되며, 토큰 관리와 교환을 위한 합의된 폴리시에 의해 정해진다. 2 참여자들 간의 직접 신뢰 관계의 경우에는 식별자 변환 알고리즘은 이 양측에 대해 설정되었을 것이며 연합 내의 다른 측에는 적당하지 않을 수 있다.

그러나 발행 도메인이 도메인(610)에 대한 로컬 식별자로부터의 사용자를 도메인(620)에 대한 로컬 식별자에 맵핑하는 방법을 아는 것은 항상 있는 경우는 아닐 것이다. 어떤 경우에는 신뢰 도메인이 이러한 맵핑을 하는 방법을 알 수 있을 것이며, 또 다른 경우에는 어느 측도 이 변환을 하는 방법을 알지 못할 것인데 이 경우에는 제3측 신뢰 브로커가 불러 내어질 필요가 있을 수 있다. 즉, 중개된 신뢰 관계의 경우에는 발행 도메인과 신뢰 도메인은 서로 간에 직접 신뢰 관계를 갖지 않는다. 그러나 이들은 신뢰 브로커(650)와 같은 신뢰 브로커와는 직접 신뢰 관계를 가질 것이다. 식별자 맵핑 규칙과 알고리즘은 이 관계의 일부로서 설정되었을 것이며, 신뢰 브로커는 이 정보를 이용하여 중개된 신뢰 관계에 필요한 식별자 변환을 지원할 것이다.

도메인(620)은 도메인(610)이 접점 서버(622)에 발행한 토큰을 수신하며, 이 서버는 그 토큰을 검증하고 신원 맵핑을 수행하는 신뢰 프록시(624)를 불러낸다. 이 경우에는 신뢰 프록시(624)는 도메인(610)에 대한 로컬 식별자로부터의 사용자를 도메인(620)에 대한 로컬 식별자에 맵핑할 수 없기 때문에 신뢰 프록시(624)는 신뢰 프록시(650)를 불러내고, 이 프록시는 그 토큰을 검증하여 식별자 맵핑을 수행한다. 사용자에 대한 로컬 식별자를 얻은 후에는, 신뢰 프록시(624)는 아마도 그 보안 토큰 서비스를 통해 도메인(620)에서의 백 엔드 애플리케이션이 요구하는 로컬 토큰을 발생할 수 있다. 예컨대 케르베로스 토큰은 접점 서버로부터 애플리케이션 서버로의 싱글 사인 온을 용이하게 하도록 요구될 수 있다. 로컬적으로 유효한 토큰을 얻은 후에는, 필요하다면, 접점 서버는 사용자에 대한 로컬 세션을 구축할 수 있다. 접점 서버는 사용자 요구의 개략적인 인증을 처리하여 인가된 요구를 도메인(620) 내의 적당한 애플리케이션 서버에 전송할 수도 있다.

연합 사용자 라이프사이클 관리(FULM) 기능/서비스는 복수의 연합 도메인에서 주어진 사용자의 특정 사용자 계정이나 사용자 프로파일에 대한 연합 동작을 지원 또는 관리라는 기능을 포함한다. 대표적인 FULM 기능은 미국 특허공개 제20080010665호(발명의 명칭: "Method and system for policy-based initication of federation management", 그 내용은 여기에 인용으로 포함됨)에 설명되어 있다. 어떤 경우에는 이 기능 또는 동작은 사용자에 대한 주어진 연합 세션에 한정된다. 즉, 연합 사용자 라이프사이클 관리 기능은 아마도 연합 컴퓨팅 환경 내의 단일 사용자 세션의 라이프사이클 중에만 복수의 연합 파트너에 걸친 연합 동작의 관리를 가능하게 하는 기능을 말한다.

각 연합 도메인은 각자의 연합 도메인에서의 기능에 대한 어떤 종류의 사용자 계정, 사용자 프로파일 또는 사용자 세션을 관리했을 수 있다. 예컨대 특정 연합 도메인은 그 특정 연합 도메인 내의 로컬 사용자 계정이나 사용자 프로파일을 관리하지 않았을 수는 있으나, 그 연합 도메인은 연합 도메인에서 싱글 사인 온 동작의 성공적인 완료 후에는 연합 거래에 대한 로컬 사용자 세션을 관리했을 수도 있다. 그 특정 연합 도메인이 지원하는 연합 사용자 라이프사이클 관리 기능의 일부로서, 연합 도메인은 연합 도메인이 연합 거래가 완료된 후에 로컬 사용자 세션을 종료할 수 있도록 하는 싱글 사인 오프 동작에 참여할 수 있으며, 이에 따라 보안성이 향상되고 자원의 효율적인 이용이 증진된다.

연합 사용자 라이프사이클 관리 기능 이용의 다른 예로서, 사용자는 복수의 연합 도메인의 참여를 필요로 하는 온라인 거래에 참가할 수 있다. 연합 도메인은 연합 도메인과 관련한 사용자의 연합 세션 각각 중에 연합 도메인에 대해 사용자의 경험을 맞추기 위하여 사용자 프로파일을 로컬방식으로 관리했을 수 있다. 그 특정 연합 도메인이 지원하는 연합 사용자 라이프사이클 관리 기능의 일부로서, 연합 도메인의 로컬 사용자 프로파일 내의 정보는 주어진 연합 거래 중에 그 주어진 연합 거래에 참여하고 있는 다른 연합 도메인에서의 다른 프로파일로부터의 정보와 고르게 이용될 수 있다. 예컨대 사용자의 복수 로컬 사용자 프로파일로부터의 정보는 사용자가 사용자 정보의 여러 가지 기원이나 소스를 알지 못하게 하는 식으로 사용자 정보가 예컨대 웹 페이지 내에서 사용자에게 시각적으로 제시되도록 어떤 종류의 통합 동작에서 결합될 수 있다.

연합 사용자 라이프사이클 관리 기능은 계정 링크와 디링크 기능도 포함할 수 있다. 사용자에게는 연합 파트너 전체에 걸친 공통의 고유 사용자 식별자가 부여되는데, 이 식별자는 한 연합 파트너에서의 요구의 이행의 일부로서 사용자에 대한 싱글 사인 온과 (필요하다면) 속성 검색을 가능하게 한다. 더욱이 연합 파트너는 익명으로 사용자를 나타내는 공통 고유 사용자 식별자를 이용하여 신원 제공자 로부터 추가적인 속성을 요구할 수 있다.

이제 도 7A를 설명하면, 미국 특허공개 제20080010665호(츨원일: 2006년 7월 7일, 그 내용은 여기에 인용으로 포함된)에 기술되어 있는 바와 같이, 도 7A의 블록도는 연합 사용자 라이프사이클 관리 기능을 구현하기 위한 연합 도메인 내의 성분들의 추가적인 세부 사항을 보여준다. 도 7A는 하나의 연합 도메인에서의 요소들을 보여준다. 도 7A에서는 접점 서버(702)가 기업 도메인에 대한 전자적 또는 물리적 프론트 엔드를 구성하는 방화벽들(710, 712) 간의 DMZ 내에 있는 것으로 도시되어 있으며, 그 외에도, 연합 사용자 라이프사이클 관리 애플리케이션/서비스(708)는 전자적으로 방화벽(712) 뒤에 존재한다. 신뢰 서비스(714), 싱글 사인 온 프로토콜 서비스(716), 및 신원 및 속성 서비스(718)는 필요에 따라 기업 사용자 레지스트리(720)와 연합 사용자 레지스트리(722)를 채용하며, 사용자는 통상적으로는 자연인이나 연산 자원을 사용하는 데이터 처리 실체일 수도 있다.

다시 도 7A를 참조로 설명하면, 연합 사용자 라이프사이클 관리 애플리케이션(708)은 연합 사용자 라이프사이클 관리 플러그 인(724)과 인터페이싱, 대화 또는 상호 연동하기 위한 지원을 포함한다. 도 7A에 도시된 예시적인 구조에서 연합 프로토콜 런타임 플러그 인은 WS-페더레이션 패시브 클라이언트(Federation Passive Client), 리버티 앨리언스(Liberty Alliance) ID-FF 싱글 사인 온(B/A, B/P 및 LECP), 레지스터 네임 아덴티파이어(Register Name Identifier), 페더레이션 터미네이션 노티피케이션(Federation Termination Notification) 및 싱글 로그아웃과 같은 각종의 독립적으로 공시 또는 개발된 연합 사용자 라이프사이클 관리 표준 또는 프로파일을 위한 기능을 제공한다. 여러 가지 세트의 연합 프로토콜은 서로 다른 URI에서 접근될 수 있다. 이 방식에 따르면 연합 사용자 라이프사이클 프로토콜은 하나의 애플리케이션 내에서 연합 사용자 라이프사이클 관리의 복수의 표준 또는 사양, 예컨대 WS-페더레이션 웹 서비스 대 리버티 앨리언스 사양을 동시에 지원할 수 있으며, 이에 따라 여러 가지 연합 프로토콜을 지원하기 위한 전체 환경에 미치는 구성 영향을 최소화할 수 있다.

연합 사용자 라이프사이클 관리 기능은 사용자 요구를 적당한 연합 사용자 라이프사이클 관리 애플리케이션으로 다시 향하게 하고 그리고/또는 이에 전송함으로써 접점 서버에 의해 불러내어 진다. 다시 도 7A를 참조로 설명하면, 접점 서버(702)는 사용자 요구(730)를 수신하고, 그러면 이 요구는 분석되어 수신되었던 요구의 종류를 결정하며, 이 요구의 종류는 수신되었던 요구 메시지의 종류에 의해, 또는 전술한 바와 같이 요구 메시지 내의 목적지 URI를 결정함으로써 나타내어 졌을 수 있다. 보호 자원에 대한 요구(732)가 애플리케이션 서버(704)에 계속해서 전송되고 있는 동안에, 연합 사용자 라이프사이클 관리 기능에 대한 요구(734), 예컨대 싱글 사인 오프 동작을 불러내는 요구가 연합 사용자 라이프사이클 관리 애플리케이션(708)에 전송되며, 이 애플리케이션은 수신된 요구를 완수하기 위해 필요에 따라 적당한 연합 사용자 라이프사이클 관리 플러그 인을 불러낸다. 새로운 연합 프로토콜 또는 새로운 연합 기능이 정해지거나, 기존의 것이 약간 변경 또는 개량된 경우에는, 새로운 지원 모듈을 플러깅함으로써 지원이 가단하게 부가되거나 이전에 설치된 플러그 인을 변경함으로써 지원이 개량될 수 있다.

도 7A에서의 연합 사용자 라이프사이클 관리 애플리케이션의 예시적인 구현은 연합 사용자 라이프사이클 관리 애플리케이션이 "플러그 인" 기능을 제공하면서 복수의 동시적인 연합 사용자 라이프사이클 관리 기능을 지원할 수 있고, 이에 따라 기존의 기반구조에 변경을 가할 필요없이 필요 시에 새로운 기능이 플러그 인 형태로 연합 사용자 라이프사이클 관리 애플리케이션에 부가될 수 있음을 보여준다. 예컨대 전술한 청구 대상이 Java™ 기반 연합 사용자 라이프사이클 관리 애플리케이션을 이용하여 구현된다고 가정하면, 새로 개발된 Java™ 클래스를 연합 사용자 라이프사이클 관리 애플리케이션의 Java™ CLASSPATH에 구성함으로써 새로 공시된 싱글 사인 온 프로토콜과 같은 새로운 연합 프로토콜을 위한 지원이 부가될 수 있으며, 이 경우에 이들 새로운 클래스는 전술한 청구 대상을 지원하기 위한 프로토콜 인터페이스와 함께 새로운 표준을 지원한다. 따라서 이 예시적인 연합 구조는 연합 사용자 라이프사이클 관리 솔루션이 통합될 기존 환경에 영향을 준다. 연합 사용자 라이프사이클 관리 애플리케이션은 전체 기반구조에는 거의 변화를 주지 않으면서 진화하는 새로운 프로토콜/표준을 지원하도록 쉽게 변경될 수 있다. 새로운 연합 사용자 라이프사이클 관리 기능을 지원하는데 필요할 수 있는 변경은 연합 사용자 라이프사이클 관리 애플리케이션 내의 거의 배타적으로 정해지는데, 이는 부가된 기능을 이해하기 위해 연합 사용자 라이프사이클 관리 애플리케이션을 구성하는 것을 필요로 한다.

전체 기반구조가 기존의 연합 사용자 라이프사이클 관리 기능을 계속 지원하면서 새로운 연합 사용자 라이프사이클 관리 기능을 불러낼 수 있도록 하기 위해, 예컨대 접점 서버에서의 다른 연합 성분은 거의 변화되지 않을 수 있다. 그러나 연합 사용자 라이프사이클 관리 애플리케이션은 연합 사용자 라이프사이클 관리 애플리케이션이 연합 환경의 다른 연합 성분과 최소한의 대화만을 필요로 할 수 있다는 점에서 연합 성분의 나머지와는 기능으로 독립적이다. 예컨대 예시적인 실시예에서, 연합 사용자 라이프사이클 관리 기능은, (리버티 앨리언스 프로파일에 따른 NameIdentifier 값과 같은) 연합 사용자 라이프사이클 관리 정보가 외부 실체에 투명하거나 액세스될 수 없는 사설의 내부 연합 사용자 라이프사이클 관리 데이터 스토어가 아니라 외부적으로 액세스가능한 연합 사용자 라이프사이클 관리 데이터 스토어에 저장되어햐 하는 경우에는, 기업 기반 데이터 스토어, 예컨대 LDAP 데이터 스토어와 통합할 수 있다.

동작을 완료하기 위해서는 사용자와 최소한의 대화를 필요로 할 수 잇는 것과 같은 일부 연합 동작은 사용자에게 최소한으로만 부담이 되는 식으로 수행되어야 하겠지만, 이 동작들은 연합 기업을 위해, 특히 기업 내의 모든 사용자에게 필요할 수 있는 종류의 동작에 대해서 효율적으로 수행되어야 하기도 한다. 특정 연합 프로토콜을 지원하기 위하여 필요한 동작에 대해서는 연합 기업은 이들 동작이 구현되는 방식에 있어 많은 유연성을 가질 필요가 없으며 또는 사용자와 연합 기업의 연산 자원에 대한 부담을 가질 필요도 없다. 연합 기업은 이 연합 기업이 동의한 연합 명세에 따라서 특정 방식으로 특정 행위를 수행하도록 할 필요가 있을 수 있다. 즉, 연합 기업은 비지니스 계약에 의해서 동작의 연산 부담에 상관없이 특정 연합 연산을 구현하도록 할 필요가 있을 수 있다.

그러나 연합 환경 내의 많은 기능 양상은 연합 내의 하나 또는 그 이상의 기업이 원하는 하나 또는 그 이상의 비지니스 목표를 지원하는 동작으로서 분류될 수 있지만, 연합 프로토콜을 지원하는데 반드시 필요하거나 연합에 참여하는데 반드시 필요한 것은 아니다. 더욱이 이들 비지니스 목표를 완수하기 위한 동작의 구현은 참여하는 연합 파트너와의 대화로 나타나는 여러 가지 연합 동작의 실행을 개시할 수 있다. 기업이 정한 비지니스 목표를 지원하는 최종 행위는 연합 환경에서 세분화될 수 있으므로 지원하는 동작이 구현되는 방식은 연합 내의 수많은 사용자에 걸쳐 척도 변환될 수 있는 식으로 달성되어야 한다. 게다가 기업 내의 연합 기능을 관리할 책임이 있는 시스템 관리자는 기업의 원하는 비지니스 목표를 구현할 때에 편리하게 그 연산 자원을 구성할 수 있어야 한다.

이를 위해 미국 특허공개 제20080010665호(출원일: 2006년 7월 7일)는 원하는 비지니스 목표를 달성하기 위해 기반구조의 효율적이고 구성가능한 관리를 제공하는 폴리시 기반 메카니즘 및 관련 연산 기반구조를 제공한다. 거기서 설명된 기반구조에 의해서는 연합 동작은 폴리시 및 관련 폴리시 관리 메카니즘을 이용하여 스케일러블한 방식으로 관리될 수 있다. 이제 도 7B를 참조로 설명하면, 도 7B의 블록도는 연합 사용자 라이프사이클 관리 기능을 구현하면서 연합 사용자 라이프사이클 관리 기능을 채용할 수 있는 여러 가지 비지니스 목표를 달성하기 위한 폴리시 기반 메커니즘을 구현하기 위한 연합 도메인 내의 성분들 중 일부를 보여준다. 도 7B는 도 7A와는 양 도면이 연합 사용자 라이프사이클 관리 기능을 구현하기 위한 예시적인 성분 구성을 보여준다는 점에서 매우 유사하다. 도 7A와는 달리, 요 구/응답 메시지(730), 보호 자원 메시지(732) 및 FULM 메시지(734)가 기업의 데이터 처리 시스템에 대한 착신 및 발신 메시지로서 나타나 있는데, 이는 이 방식이 착신 및 발신 데이터 트래픽의 전처리 및 후처리 모두에 적용될 수 있음을 강조한다.

도 7B에 도시된 시스템은 최소한의 부담을 주면서 연합 사용자 라이프사이클 관리 기능의 폴리시 기반 개시를 지원하기 위한 추가 기능을 포함하도록 개량되었다. 도 7B에서 FULM 애플리케이션/서비스(708)는 폴리시 필터/엔진(736)을 포함한다. 착신 FULM 요구 메시지(734)가 접점 서버(702)로부터 FULM 애플리케이션/서비스(708)에 수신됨에 따라, 또는 발신 FULM 응답 메시지가 접점 서버(702)로의 전송을 위해 여러 가지 성분으로부터의 FULM 애플리케이션/서비스(708)에 의해 처리되고 있음에 따라, 메시지는 예컨대 폴리시 데이터베이스(738) 내에 저장된 바와 같은, 착신 또는 발신 메시지에 대한 추가적인 연합 관계 처리를 필요로 하는 폴리시가 구성되었는지 여부를 체크함으로써 폴리시 필터/엔진(736)에 의해 필터링된다. 예컨대 폴리시는 그 요구를 완수하기 전에 착신 요구 메시지의 추가적인 전처리를 필요로 할 수 있다. 마찬가지로 폴리시는 응답을 되돌려 주기 전에 발신 응답 메시지의 추가적인 후처리를 필요로 할 수 있다. 즉, 폴리시 필터/엔진(736)을 착신/발신 FULM 메시지를 위한 처리 스트림의 선두와 말단에 배치하면 추가적인 전처리 또는 후처리 단계가 FULM 메시지의 처리를 개시 또는 종결하기 전에, 즉 착신 FULM 요구의 처리를 개시하기 전에 또는 발신 FULM 응답의 처리를 종결하기 전에 확실하게 수행될 수 있다.

어떤 경우에는 폴리시의 평가는 추가적인 전처리 또는 후처리가 요구되는 것을 나타낼 수 있고, 다른 경우에는 폴리시의 평가가 추가적인 전처리 또는 후처리가 요구되지 않는 것을 나타낼 수 있다. 이 관점으로부터 폴리시 엔진(736)은 착신 및 발신 메시지를 필터링하는 것으로 볼 수 있다. 폴리시 엔진(736)에 의해서 어떤 착신 요구는 추가적인 전처리 단계가 수행될 수 있을 때까지 다른 요구를 다른 데로 돌리거나 보류하면서 추가적인 전처리 단계 없이 바로 달성될 수가 있을 것이다. 마찬가지로 폴리시 엔진(736)에 의해서 어떤 발신 응답은 추가적인 후처리 단계가 수행될 수 있을 때까지 다른 응답을 다른 데로 돌리거나 보류하면서 추가적인 후처리 단계 없이 바로 전송될 수가 있을 것이다.

다른 실시예에서, 폴리시 엔진/필터는 접점 서버(702)와 연관되거나 그리고/또는 하나 또는 그 이상의 애플리케이션 서버(704)와 연관될 수 있다. 그와 같은 실시예에서는, 뒤에 더 자세히 설명하겠지만, 하나 또는 그 이상의 FULM 플러그 인(724)은 디지털 권리 관리(DRM) 기능을 제공한다. 이들은 여기서는 때로는 DRAM플러그 인이라고 한다.

이제 도 7C를 참조로 설명하면, 도 7C의 블록도는 실시예에 따라서 FULM 메시지에 관하여 폴리시 엔진에 의한 폴리시 평가와 관련하여 처리되는 데이터 요소의 일부에 대한 추가적인 상세를 보여준다. 도 7C는 유사한 요소에 대해서는 동일한 도면번호를 병기한 것과 같이 도 7B에 도시된 것과 유사한 요소를 포함한다. 바람직하게는 폴리시 엔진의 기능은 FULM 요구가 수신될 때에 또는 FULM 응답이 리턴될 때에 폴리시가 시행될 수 있게 하는 식으로 연합 프로파일의 처리 내로 삽입 되고, 폴리시 내에 표시된 동작들은 FULM 요구를 더 처리하기 전에 또는 FULM 응답의 처리를 종결하기 전에 전처리 또는 후처리 단계로서 수행될 수 있다. 폴리시 기반 전처리 및 후처리는 FULM 메시지 내의 내용의 런타임 처리 내의 어떤 다른 곳에서 발생할 수 있는 폴리시의 이용을 배제하는 것은 아니다. 폴리시는 폴리시 데이터베이스(738)와 같은 하나 또는 그 이상의 데이터 스토어에 저장될 수 있다. 기업은 하나 이상의 연합에 참여할 수 있으므로, 즉 복수의 연합 컴퓨팅 환경을 위한 기능을 지원할 수 있으므로, FULM 메시지는 여러 가지 연합 프로파일에 대해 처리될 수 있고, 폴리시 데이터베이스(738)는 여러 가지 연합 프로파일에 대한 여러 가지 폴리시 세트를 포함할 수 있다. 본 예에서 폴리시 세트(740)는 제1 연합 내의 사용자에게 적용될 수 있고, 폴리시 세트(742)는 제2 연합 내의 사용자에게 적용될 수 있으며, 사용자는 복수의 연합 내에 등록될 수 있으며, 따라서 폴리시 세트(740)와 폴리시 세트(742)는 반드시 서로 배타적인 사용자 세트에만 적용될 수 있는 것은 아니다. 폴리시 세트(744)는 현재 기업, 즉 도 7A-7C에 도시된 데이터 처리 환경을 지원하는 기업 내의 모든 사용자에게 적용될 수 있다. 폴리시 세트(746)는 기업 내의 특정의 개별적인 사용자에게 적용될 수 있다.

도 7C에 도시된 여러 가지 종류의 폴리시는 단지 기업 내에서 적용될 수 있는 폴리시 일부의 시행가능성을 보여주며, 데이터베이스 내의 폴리시들은 반드시 도 7C에 도시된 바와 같은 분리된 세트로서 저장되어야 하는 것은 아니다. 폴리시는 XML 문서를 다른 XML 문서로 변환하는데 사용될 수 있는, XML(extensible Markup Language)로 정의되는 것과 XSLT(XSL Transformation 또는 eXtensible Stylesheet Language Transformation)로 표현되는 것과 같이 임의의 적당한 포맷으로 나타낼 수 있다. 폴리시 엔진(736)은 폴리시 내의 규칙이나 규칙들을 평가한다. 예컨대 XSLT 규칙 엔진은 착신 프로파일 요구가 이 프로파일 요구의 초기 처리 전에 수신될 때에 불러내어 질 수 있다. 평가된 폴리시(748)는 평가되고 있는 또는 평가되었던 폴리시를 나타낸다. 규칙(750)은 폴리시 내의 조건문을 나타내며, 이 조건문은 논리적 연산자들에 따라서 평가되는 파라미터 또는 데이터값 세트에 기초한 조건을 나타낸다. 만일 어떤 조건문이 논리적 또는 불(boolean) "참" 값으로 평가한다면, 이 규칙은 트리거 또는 활성화된다고 하고, 만일 조건문이 논리적 또는 불 "거짓" 값으로 평가한다면, 이 규칙은 트리거 또는 활성화되지 않는다고 한다. 일 관점으로부터, 폴리시의 규칙은 관련 조건이 참인 것으로 평가되거나 만족되는 것으로 평가될 때에만 특정 조건적 처리를 유발하는 "if-then" 조건문인 것으로 볼 수 있다. 조건문 내의 하나 또는 그 이상의 값은 사용자 레지스트(722) 내의 사용자 엔트리(754) 내의 사용자 속성(752)으로부터 얻을 수 있다. 이 예에서 사용자 엔트리(754)는 원래의 FULM 메시지사 수신되었던 것을 대신하여 사용자와 연관되는데, 예컨대 이 원래 수신된 FULM 메시지는 사용자 엔트리(722) 내의 사용자에 대한 정보를 탐색하는데 사용될 수 있는 사용자 식별자를 포함할 수 있다. 그러면 검색된 사용자 속성을 이용하여 원래의 FULM 메시지가 수신될 때에 시행될 수 있는 폴리시를 결정한다.

폴리시 내의 규칙이 트리거되면, 메시지가 발신 응답인지 착신 요구인지 여부에 따라서 원래 수신된 응답의 처리의 종결이 보류되거나 원래 수신된 요구의 추 가적인 처리가 보류된다. 이런 식으로 예컨대 도 7B에 도시된 FULM 애플리케이션/서비스(708)에 의해 이 수신된 메시지에 대해 수행되어야 했던 연합 프로토콜 동작이 시간적으로 후속되는 시점까지 연기된다. 이 보류 또는 연기 중에 도 7B에 도시된 FULM 메시지(734)는 보류 동작 캐시(756)와 같은 적당한 장소, 또는 사용자 레지스트리(722) 내의 사용자 엔트리(754)와 같은 다른 데이터 스토어, 또는 사용자를 위한 세션 관리에 대한 다른 정보를 포함하는 세션 캐시에 저장될 수 있다.

폴리시 내의 규칙이 추가적인 전처리 또는 후처리를 트리거 또는 활성화하도록 평가된 후에는 그 폴리시는 그 규칙이 트리거될 때에 수행되어야 하는 추가적인 전처리 또는 후처리의 종류에 대한, 그 폴리시에 포함된 정보에 대해 검사된다. 더 구체적으로, 착신 요구 메시지에 대해서는 폴리시는 보류되었던 원래의 FULM 요구와 연관될 수 있는 다른 연합 프로토콜 동작을 수행하기 전에 수행되어야 할 연합 프로토콜 동작을 나타낸다. 마찬가지로 발신 응답 메시지에 대해서는 폴리시는 보류되었던 발신 FULM 응답과 연관될 수 있는 다른 연합 프로토콜 동작을 수행하기 전에 수행되어야 할 연합 프로토콜 동작을 나타낸다. 도 7C는 폴리시(748)가 규칙(750)과 연관된 트리거된 연합 프로토콜 동작(758)에 대한 데이터를 식별하거나 표시하는 것을 포함하는 것을 보여준다.

폴리시(748)는 트리거된 연합 프로토콜 동작(758)의 종결 시에 수행되어야 할 프로세스를 나타내는 하나 또는 그 이상의 종결 절차에 대한 정보도 포함할 수 있다. 예컨대 트리거된 연합 프로토콜 동작(758)이 종결된 후에는, 특정 폴리시가 적용, 즉 시행되었던 것을 나타내는 적용된 폴리시 정보(762)가 사용자 엔트 리(754) 내에 설정될 수 있으며, 그와 같은 각 엔트리는 그 폴리시의 시행이 성공인지 실패인지에 대한 표시, 폴리시가 시행되었던 시기를 나타내는 하나 또는 그 이상의 타임스탬프, 및 기타 다른 관련 정보와 같은 추가 정보와 함께 그 관련 폴리시에 대한 참조 또는 그 관련 폴리시에 대한 식별자를 가질 수 있다. 어떤 경우에는 종결 절차(760)에 대한 정보는, 트리거된 연합 프로토콜 동작(758)이 실패했더라도, 예컨대 폴리시가 시간적으로 좀 더 뒤에 재실행될 수 있기 때문에 강제적이지 않은 또는 시간 임계적(time-critical)이지 않은 연합 프로토콜 동작을 나타내는 경우에도, 원래 수신된 FULM 메시지가 계속 처리될 수 있음을 나타낼 수 있다. 어떤 경우에는 종결 절차(760)에 대한 정보는, 트리거된 연합 프로토콜 동작(758)이 실패했다면, 예컨대 폴리시가 강제적이거나 시간 임계적인 연합 프로토콜 동작을 나타내는 경우에, 원래 수신된 FULM 메시지가 계속 처리될 수 없음을 나타낼 수 있다. 종결 절차(760)에 대한 정보에 따라서는 이 원래 수신된 FULM 메시지는 보류 동작 캐시(756)와 같은 적당한 데이터 스토어로부터 검색되어 더 처리되거나 거부된다.

디지털 권리 관리(DRM) 폴리시는 폴리시 시행의 일부로서 서비스 제공자를 위하여 DRM 폴리시 제공자에 의해 관리되고 동작되는 하나 또는 그 이상의 DRM 플러그 인에 의해 구현될 수 있다. DRM 플러그 인은 DRM 자원이 서비스 제공자 환경에 부가됨에 따라 부가될 수 있으며, 뒤에 보겠지만, 그와 같은 플러그 인은 필요에 따라 추가적인 DRM 속성(이하 DRM 특권이라 함)의 검색을 처리하는데 양호하게 이용된다.

여기서 사용된 "DRM 특권"은 DRM 폴리시에 의해 제어된 어떤 행위를 할 능력을 기술하는 정보(예컨대 속성)이다. 예컨대 주어진 DRM 특권은 사용자에게 (소정 비용을 내면) 임의의 장치에서 오디오북을 구동할 수 있는 주어진 웹 사이트(예컨대 audible.com)에의 종신 접근권을 제공할 수 있다.

여기서 사용된 "DRM 폴리시"는 사용자가 디지털 권리 관리 방식의 콘텍스트에서 소정 행위를 할 수 있기 전에 필요한 DRM 특권이 무엇인지를 기술하는 정보이다. 예컨대 사용자가 Audible에 가입하여 iTunes에서 다운로드받아 구동할 수 있는 경우에, DRM 폴리시는 사용자가 iPod나 GPS 모바일 장치에서 음악을 다운로드받아 구동할 수 있도록 해 줄 수 있다.

DRM 특권은 복수의 여러 가지 행위나 권리를 포함할 수 있으며, DRM 폴리시는 많은 여러 가지 DRM 특권 세트로 채워질 수 있다.

DRM-폴리시 작동가능 연합

전술한 것을 토대로 다음에서는 DRM-폴리시 작동가능 연합에 대해서 설명한다. 도 8에 도시된 바와 같이 연합 내의 참여자는 바람직하게는 제1 연합 파트너(800), 제2 연합 파트너(802), 제3 연합 파트너(804), 및 선택적으로 제4 연합 파트너(806)를 포함한다. 제1 연합 파트너(800)는 (FULM 기능면에서) 신원 제공자일 수 있으며, 또는 이것은 DRM-폴리시 순응(compliance)을 요구하는 서비스를 제공하는 서비스 제공자일 수 있다. 설명 목적상, 제1 연합 파트너(800)는 여기서는 신원 제공자라 한다. 제2 연합 파트너(802)는 (최종 사용자의 관점에서) DRM 콘텐츠를 제공하는 서비스 제공자이다. 제3 연합 파트너는 제2 연합 파트너(802)에 의 해 시행되어야 하는 최종 사용자 DRM 특권(808)과 선택적으로는 DRM 폴리시(810)를 관리하는 서비스 제공자이다. 제4 연합 파트너(806)는 (DRM 특권이 아닌) DRM 폴리시를 관리하는 DRM 폴리시 "오라클"이다. DRM 폴리시 오라클 기능은 제3 연합 파트너의 기능일 수 있는데, 이 경우에는 제4 연합 파트너는 필요하지 않다. 즉, 제3 및 제4 연합 파트너(804, 806)는 하나의 연합 파트너에 배치될 수 있다.

제1 연합 파트너(800)는 제3 연합 파트너(804)의 기능을 포함할 수 있으며, 따라서 연합에서 신원 제공자와 DRM 제공자로서 역할할 수 있다. 이것이 유용할 수 있는 시나리오의 예는 최종 사용자가 무제한 접근을 허용하는 (iTunes와 같은) 음악 다운로드 장치에 가입하는 경우이다.

대안으로서, 제2 연합 파트너(802)는 제3 연합 파트너(804)의 기능을 포함할 수 있다. 그와 같은 경우에는 제2 연합 파트너는 그 기능에 관련된 DRM 정보를 유지하고, 선택적으로는 요구 시에 이 정보를 다른 연합 파트너에 제공한다. 이것이 유용할 수 있는 시나리오의 예는 음악 다운로드 서비스가 사용자 별명이 이 서비스에 무제한적으로 가입한 것을 알고 있는 경우이다.

제1 연합 파트너(800)는 제4 연합 파트너(806)의 기능을 포함할 수 있다. 그와 같은 경우에는 제1 연합 파트너(800)는 신원 제공자와 DRM 폴리시 제공자로서 역할하겠지만, 통상적으로 그와 같은 폴리시는 조잡할 가능성이 클 것이다. 이것이 유용할 수 있는 시나리오의 예는 최종 사용자가 신원 제공자로부터 싱글 사인 온(SSO)을 통해 음악 다운로드 서비스에 접근하기를 원하고 이 서비스에 유효하게 가입한 것을 입증할 필요가 있는 경우이다.

제2 연합 파트너(802)는 제4 연합 파트너(806)의 기능을 포함할 수 있다. 그와 같은 경우에는 제2 연합 파트너(802)는 서비스 제공자와 DRM 폴리시 제공자로서 역할한다. 이것이 유용할 수 있는 시나리오의 예는 서비스 제공자가 음악 다운로드 서비스이고, 사용자가 이 서비스에 접근하기 위해서는 이 서비스에 적어도 1개월 시범 가입해야 한다는 것을 알고 있는 경우이다.

전술한 것과 마찬가지로, 제3 연합 파트너(804)는 제4 연합 파트너의 기능을 포함할 수 있다. 그와 같은 경우에는 제3 연합 파트너는 사용자의 DRM 특권과 서비스 제공자 DRM 폴리시에 대한 DRM 제공자로서 역할한다. 예컨대 사용자가 영화 서비스(예컨대 NetFlix)에 무제한으로 가입하고, 소정 기간(예컨대 7월달) 동안 모든 서비스 사용자가 음악 다운로드 서비스를 한달 간 무료로 시범이용한다고 가정하면, 이 폴리시를 적용함으로써 그 달 동안 사용자는 그 음악 다운로드 서비스를 1개월 시범이용할 DRM 특권을 가진다고 판단할 수 있다.

다음은 DRM 폴리시 작동가능 연합의 몇 가지 실례이다.

실례 1

도 9에 도시된 바와 같이, 제1 실례에서 사용자(901)는 제1 연합 파트너(900)에게 인증되고, 사용자의 관점으로부터 콘텐츠를 제공하는 제2 연합 파트너(902)에게 싱글 사인 온을 요구한다. 따라서 제2 연합 파트너(902)는 전술한 디지털 콘텐츠 제공자에 대응한다. 연합의 결과로서 제1 연합 파트너(900)는 제2 연합 파트너(902)에서 시행되는 DRM 폴리시(910)를 알고 있고(또는 이를 찾기 위해 제4 연합 파트너(906)에게 질의하고) 또 제1 연합 파트너(900)는 사용자의 DRM 특 권(908) 을 알고 있다고(또는 이를 찾기 위해 제3 연합 파트너(904)에게 질의하고 있다고) 가정된다. 그러면 제1 연합 파트너(900)는 사용자의 DRM 특권(908)을 참조하여 제2 연합 파트너(902)를 위한 싱글 사인 온 메시지를 만든다. 미국 특허공개 제2006/0021018호(출원일: 2004년 7월 21일)에 기재된 바와 같이, 이것을 달성하는 통상적인 방법은 사용자의 DRM 특권(908)을 포함하는 주장에 대한 포인터를 제1 연합 파트너(900)로부터 제2 연합 파트너(902)로 보내고(통상적으로 HTTP 302를 이용한 브라우저 기반 리다이렉트), 그에 응답하여 제2 연합 파트너(902)가 사용자의 DRM 특권(908)을 포함하는 주장에 대한 포인터(아티팩트라고도 함)의 교환을 요구하는 것이다.

제2 연합 파트너(902)가 시행해야 하는 폴리시를 이미 알고 있다면, 이 파트너는 주장된 DRM 특권(908)을 이용하여 (도 7C에서 전술한 바와 같이) 폴리시를 평가하고, 그 폴리시 평가에 따라서 접근을 허용 또는 불허한다. 그러나 제2 연합 파트너(902)가 시행해야 하는 폴리시를 이미 알고 있지 않다면(즉 폴리시에의 순응을 평가할 수 없다면), 제2 연합 파트너는 제4 연합 파트너(906)(또는 제3 연합 파트너도 DRM 폴리시 오라클이라면 이 제3 연합 파트너)에게 "DRM 폴리시 평가" 요구(912)를 발생한다. DRM 폴리시 평가 요구는 제4 연합 파트너(906)에게 DRM 특권을 제공하며, 이 파트너는 "예" 또는 "아니오" 대답을 제공한다. 제4 연합 파트너가 제공한 대답이 "예"라면 접근이 허용되고, "아니오"라면 접근은 불허된다.

제2 연합 파트너(902)가 그 DRM 폴리시를 알고 있을 뿐만 아니라 제1 연합 파트너가 제2 연합 파트너(902)가 폴리시를 평가할 수 있도록 하는데 필요한 정보 의 일부/전부를 제공하지 않았다는 것을 알고 있을 가능성이 있다. 이것은, 제1 연합 파트너가 불완전한 정보가 제2 연합 파트너에 보내지게끔 필요한 또는 관련 DRM 특권의 전부를 검색 또는 획득하도록 되어있지 않음에 따라 제1 연합 파트너가 제3 연합 파트너에 가서 DRM 특권에 대해 질의한 경우에도 적용될 수 있다. 이 경우에 제2 연합 파트너(902)는 제3 연합 파트너(904)에게 폴리시 평가를 가능하게 하기 위하여 사용자의 DRM 특권에 대한 추가 정보를 검색할 것을 요구할 수 있다.

앞 절에서 설명한 방식을 변형한 것으로서, 제2 연합 파트너(902)는 그 DRM 폴리시를 알고 있고 이것을 (로컬적으로) 사용자에 대한 DRM 정보로서 이용한다. 이 시나리오에서는 제2 연합 파트너 스스로가 접근 허용 여부를 판단하기 위하여 DRM 폴리시에 대해 평가하는데 필요한 소실된 DRM 특권을 공급한다. 다른 변형으로서, 제2 연합 파트너(902)가 그 DRM 폴리시를 알고 있고 이것을 (로컬적으로) 사용자에 대한 DRM 정보로서 이용하지만 DRM 특권을 잃어버리거나 (동의, 갱신 등과 같은) 구식 정보를 갖고 있다고 가정하면, 제2 연합 파트너는 사용자에게 DRM 폴리시에 대해 DRM 특권을 평가하기 전에 필요한 정보를 가질 것인지 질의한다.

실례 2

이제 도 10을 참조로 설명하면, 이 시나리오에서는 사용자(1001)는 제1 연합 파트너(1000)에게 인증되고, 제2 연합 파트너(1002)에게 싱글 사인 온을 요구한다. 연합 구성 등의 결과로서 제1 연합 파트너(1000)는 제2 연합 파트너(1002)에서 시행되는 DRM 폴리시(1010)를 이미 알고 있다고 가정한다. 이 시나리오에서는 제1 연합 파트너(1000)는 사용자의 DRM 특권(1008)을 알고 있다(또는 이를 찾기 위해 제3 연합 파트너(1004)에게 질의하고 있다. 그러나 이 실례에서는 제1 연합 파트너(1000)는 제4 연합 파트너(또는 제3 연합 파트너가 DRM 폴리시 오라클인 경우에는 이 제3 연합 파트너)로부터 DRM 폴리시(1010)을 검색하는 것을 알지 못하거나 검색할 권한이 없다. 따라서 제1 연합 파트너(1000)는 기지의 DRM 특권(1008)을 가지고 필수적인 아티팩트/주장을 만들어 그 주장을 전술한 DRM 폴리시 평가 요구를 통해 제4 연합 파트너에게 제공한다. 제4 연합 파트너(1008)는 "예" 또는 "아니오" 대답을 제공한다. 전처럼 제4 연합 파트너가 제공한 대답이 "예"라면 제1 연합 파트너에 의해 접근이 허용되고, "아니오"라면 접근은 불허된다.

상기 나타낸 실례는 신원 제공자 자신이 하나 또는 그 이상의 DRM 특권들의 세트에 대해 DRM 폴리시를 실시할 수 있는 능력을 갖는 대안의 실시예를 설명한 것이다. 이 대안의 실시예에 따르면, 신원 제공자는 DRM 폴리시를 알고 있거나 얻을 수 있고, 평가에 필요한 경우 DRM 특권을 알고 있거나 얻을 수 있다.

실례 3

이제 도 11을 참조로 설명하면, 이 시나리오에서는 사용자(1101)는 제1 연합 파트너(1100)에게 인증되고, 제2 연합 파트너(1102)에게 싱글 사인 온을 요구한다. 이 실례에서는 제1 연합 파트너(1100)는 제2 연합 파트너(1102)에서 시행되는 DRM 폴리시(1110)를 알고 있지 않다고 가정한다. 그와 같은 경우에 제1 연합 파트너(1100)는 DRM 특권을 포함할 수도 하지 않을 수도 있는 기지의 관련 속성을 가지고 아티팩트/주장을 만든다. 한편, 제2 연합 파트너(1102)는 요구가 DRM 특권을 필요로 하고 있다는 것을 알고 있으며, 그와 같은 특권은 제1 연합 파트너에 의해 제공되지 않을 것임을 알고 있다. 그러면 제2 연합 파트너(1102)는 DRM 특권을 얻어야 한다. 이렇게 하는 데는 3가지 옵션이 있다.

첫 번째 옵션은 제2 연합 파트너(1102)가 제3 연합 파트너(1104)에게 요구를 완수하기 위해 사용자의 DRM 특권(1108)을 검색할 것인지를 질의하는 것이다. 두 번째 옵션은 제2 연합 파트너가 사용자(1101)로부터 직접 사용자의 DRM 특권을 검색하는 것인데, 이를 위해서 제2 연합 파트너는 이 특권을 얻기 위해 사용자와 직접 대화한다. 제2 연합 파트너는 사용자와 직접 대화하는 대신에 이들 특권을 갖는 동의를 검색하고, 제3 연합 파트너에 대한 포인터를 검색하고, 제3 연합 파트너에게 사용자가 특권을 제2 연합 파트너에게 보내도록 트리거하게 함으로써 이들 특권을 간접적으로 얻을 수 있다. 어느 경우에서도 대화가 완료되고 DRM 특권이 얻어지면, 제2 연합 파트너는 수집된 DRM 특권 정보를 저장하거나 이 정보를 제3 연합 파트너에게 푸시한다. DRM 특권 정보는 DRM 서비스에의 사용자 가입의 갱신을 포함할 수 있다.

실례 4

DRM 폴리시 작동가능 연합의 (신원 제공자, 서비스 제공자, DRM 특권 제공자 또는 DRM 폴리시 제공자와 같은) 하나 또는 그 이상의 성분은 분산 방식으로 구현된다. 이제 도 12를 참조하여 설명하면, 도 12의 블록도는 제1 데이터 처리 시스템이 분산된 주장 검색을 지원하는 분산형 데이터 처리 시스템을 이용하여 구현되는 신원 제공자(예시적임) 내의 제2 데이터 처리 시스템으로부터 주장을 검색하는 시나리오를 보여준다. 이런 형태의 시스템은 미국 특허공개 제20090010288호(공개 일: 2008년 1월 10일)에 기재되어 있다. 이 실례에서 신원 제공자(1200)는 그 자신이 싱글 사인 온 서비스(SPS)(1204)와 주장 캐시(1206)를 포함하는 데이터 처리 시스템(1202)과 그 자신이 SPS(1210)와 주장 캐시(1212)를 포함하는 데이터 처리 시스템(1208)을 포함하는 분산형 데이터 처리 시스템이다. 어느 시점에 데이터 처리 시스템(1202)은 예컨대 도 8을 참조로 전술한 서비스 제공자로부터 주장 검색 요구를 수신한다. 데이터 처리 시스템(1202)은 수신된 주장 검색 요구로부터 이미 추출된 아티팩트를 이용하여 그 로컬 주장 캐시(1206)를 검색하는데, 이 아티팩트는 검색키로서 또는 검색키의 기초로서 이용될 수 있다. 이 실례에서는 데이터 처리 시스템(1202)은 그 로컬 데이터 스토어 내에 위치하거나 아티팩트와 연관된 주장을 캐시할 수 없다. 그 로컬 데이터 스토어 내에 주장이 있지 않으면, 데이터 처리 시스템(1202)은 에러를 리턴하는 대신에 신원 제공자를 포함하는 다른 데이터 처리 시스템으로부터 적당한 주장을 요구한다. SPS(1204)는 예컨대 주장 검색 요구(1214)를 데이터 처리 시스템(1208)의 SPS(1210)에 보냄으로써 신원 제공자 내의 다른 데이터 처리 시스템에게 주장 검색 요구를 발행한다. 데이터 처리 시스템(1208)이 그 수신된 요구를 완수할 수 있다고 가정하면, 데이터 처리 시스템(1208)은 그 주장을 검색하고, 이것을 재사용될 수 없도록 로컬 데이터 스토어(1212)로부터 제거하고, 그 주장을 데이터 처리 시스템(1202)에 리턴시킨다. 그러면 신원 제공자(1200)는 서비스 제공자에게 주장 검색 응답을 보냄으로써 서비스 제공자로부터 수신된 원래의 주장 검색 요구를 완수한다.

신원 제공자는 주장의 소스일 수 있는 복수의 데이터 센터를 가질 수 있으 며, 서비스 제공자로부터 주장 검색 요구를 수신하는 제1 데이터 처리 시스템은, 그 로컬 주장 캐시에서 그 요구된 주장을 찾지 못하면, 신원 제공자를 포함하는 다른 모든 데이터 처리 시스템 또는 데이터 센터의 검색을 개시한다. 검색이 성공하였다고 가정하면, 제1 데이터 처리 시스템은 신원 제공자 내의 다른 데이터 처리 시스템으로부터 그 요구된 주장을 검색할 수 있다.

제1 데이터 처리 시스템은 그 요구된 주장을 여러 가지 방식으로 검색할 수 있다. 예컨대, 요구된 주장이 찾아지지 않을 때에 데이터 처리 시스템이 그 검색을 전송하고, 그 요구된 주장이 찾아질 때까지 제1 데이터 센터는 제2 데이터 센터에 질의하고, 제2 데이터 센터는 제3 데이터 센터에 질의하고, 그 요구된 주장이 찾아지면 그 주장이 버블 또는 회귀 방식으로 제1 데이터 센터에 다시 리턴되는 연쇄적인 방식으로 검색이 수행될 수 있다. 검색이 진행됨에 따라 각 데이터 센터는 그 검색을 이미 수행한 데이터 센터가 어느 것인지를 나타내는 식별자를 부가 또는 첨부할 수 있다. 대안으로서, 미국 특허공개 제20080010288호에 기재된 바와 같이, 제1 데이터 처리 시스템이 데이터 처리 시스템들에 차례로 질의하는 직렬 또는 허브 앤 스포크(hub-and-spoke) 방식으로 검색이 수행될 수 있으며, 제1 데이터 센터는 허브로서 역할하며 각 데이터 센터(스포크)에 개별적으로 질의한다.

DRM 시나리오의 예에서는 서비스 제공자가 온라인 엔터테인먼트 스토어의 분산형 데이터 센터의 구현이고, DRM 폴리시 오라클과 같은 DRM 시행 실체의 하나의 인스턴스가 있다고 가정한다. 사용자는 통상적으로 방식으로 웹 브라우저를 이용하여 음악 스토어에 접근한다. 사용자가 그 스토어를 방문하여 많은 다운로드를 구매하였고, 기존의 세션 프로파일 때문에 사용자가 온라인 비디오에 무료로 접근할 수 있는 자격을 부여받았다고 가정한다. 사용자의 체크아웃 페이지 상에서 서비스 제공자는 사용자에게 그 비디오에 접근할 것을 유도하는 링크를 포함한다. 사용자는 그 링크를 클릭하고, 아티팩트 바운드(bound) 요구와 함께 온라인 비디오 스토어프론트로 리다이렉트된다. 비디오 스토어는 아티팩트 바운드 요구를 수신하고, 그 요구를 언바인드(unbind)하고, 그 아티팩트를 추출하고, 다시 온라인 음악 스토어에 직접(예컨대 HTTP/SOAP) 요구를 하여 사용자의 현재 온라인 음악 프로파일을 검색한다. 비디오 스토어는 이 아티팩트에 기초하여 주장 검색을 시도하고, 필요하다면, 그렇게 하기 위해 도 12에 도시된 (미국 특허공개 제20080010288호에 기재된) 기술을 이용한다. 사용자 검증에 필요한 정보를 얻은 후에는 비디오가 제공된다.

이제 도 13을 참조로 설명하면, 도 13의 블록도는 다른 대표적인 디지털 권리 관리 시나리오의 다른 예를 보여준다. 사용자/클라이언트(1302)는 디지털 콘텐츠 제공자인 기업 "A"(1306)에게 요구(1304)를 보내는 거래를 개시한다. 기업 "B"(1308)는 가입료나 연합(1310) 내의 파트너들 간의 저작권 계약에 대한 저작권 제한을 관리하는 가입 서비스와 같은 디지털 권리 관리 실체이다. 시스템 관리자는 폴리시 필터/엔진(1314)에 의해 시행될 DRM 폴리시(1312)를 설정할 수 있다. 연합 내의 사용자가 연합 프로토콜 동작/프로파일, 예컨대 요구(1304)로 나타낸 저작권이 있는 콘텐츠를 검색하는 요구를 시도하면, 폴리시 엔진이 불러 내어지고 그 때에 폴리시(1312)가 시행될 수 있을 것이다. 폴리시(1312)는 사용자가 저작권이 있는 콘텐츠에 대한 검색 거래를 완료하도록 허용되기 전에 현재 유효하게 가입할 것을 요구할 수 있다.

기업(1306)은 가입을 관리하지 못하지만 기업(1306)은 이전 거래 중에 기업(1308)으로부터의 사용자 가입의 만료 시간이나 날짜에 대한 정보를 이미 얻었을 수 있다. 이전 거래 중에 기업(1308)은 만료 시간을 사용자 속성으로서 저장했을 수도 있다. 그러므로 기업(1306)은 사용자(1302)의 사용자 속성을 이용하여 사용자가 저작권이 있는 콘텐츠를 수신하기 위해 연합 내에 유효하게 가입하였는지 여부를 판단한다. 만일 사용자 가입의 만료 시간이 이전 거래 중에 저장되지 않았거나, 어떤 이유로 가입 상태가 검증될 필요가 있다면, 요구(1304)의 처리는 사용자 가입의 명확한 상태로 응답하는 기업(1308)과의 싱글 사인 온 동작을 요구할 수 있고, 이에 따라 기업(1306)은 사용자가 요구된 콘텐츠를 검색할 수 있도록 할지 판단할 수 있다.

사용자 가입의 현재 상태에 따라서, 통신 폴리시(1318)의 시행이 요구하는 바와 같이, 요구(1304)가 완료될 수 있기 전에 사용자와의 추가적인 프로토콜 동작 및/또는 통신 대화(1316)가 요구될 수 있다. 예컨대 사용자는 통신 전에 기업(1306)과 기업(1308) 간의 통신/거래에 동의하도록 요구받을 수 있다. 대안으로서, 사용자는 기업(1308)으로부터 기업(1306)으로의 정보의 발행, 예컨대 사용자의 가입 상태에 대한 정보의 발행에 동의하도록 요구받을 수 있다. 다른 대안적인 실시예에서 기업(1306)은 사용자가 유효한 가입 계정을 가질 수 있는 기업(1308)이 아닌 다른 가입 서비스의 신원과 같은 사용자로부터의 다른 정보를 얻을 필요가 있 을 수 있다.

이들 여러 가지 추가적인 통신 요건들은 이들 통신이 수행되어야 하는 방식을 서술하는 통신 폴리시(1318)에 포함될 수 있다. 예컨대 기업(1306)과 기업(1308) 간의 통신(1320)은 직접 통신, 즉 사용자와 관계없는 백 채널 통신을 연합 파트너로서 이용하여 수행될 수 있다. 대안으로서, 기업(1306)과 기업(1308) 간의 통신(1322)은 간접 통신, 즉 사용자의 클라이언트를 통한 프론트 채널 통신을 연합 파트너로서 이용하여 수행될 수 있다.

더 구체적으로 설명하면, 여기서 설명된 청구 대상은 완전히 하드웨어 실시예, 완전히 소프트웨어 실시예 또는 하드웨어와 소프트웨어 요소를 포함하는 실시예 형태를 취할 수 있다. 바람직한 실시예에서 (클라이언트측 기능, 서버측 기능 또는 이 양 기능을 포함하는) 본 발명은 펌웨어, 상주 소프트웨어, 마이크로 코드 등(이에 한정되지 않은)을 포함하는 소프트웨어로 구현될 수 있다. 더욱이 전술한 바와 같이 본 발명은 컴퓨터 또는 임의의 명령어 실행 시스템이 이용하거나 이와 관련된 프로그램 코드를 제공하는 컴퓨터 이용가능 또는 컴퓨터 판독가능 매체로부터 액세스될 수 있는 컴퓨터 프로그램 제품의 형태를 취할 수 있다. 설명 목적상, 컴퓨터 이용가능 또는 컴퓨터 판독가능 매체는 명령어 실행 시스템, 장치 또는 디바이스가 이용하거나 이와 관련된 프로그램을 포함, 저장, 전달, 전파 또는 수송할 수 있는 임의의 장치일 수 있다. 이 매체는 전자적, 자기적, 광학적, 전자기적, 적외선, 또는 반도체 시스템(또는 장치나 디바이스) 또는 전파 매체일 수 있다. 컴퓨터 판독가능 매체의 예로는 반도체 또는 고체 상태 메모리, 자기 테이프, 착탈 식 컴퓨터 디스켓, RAM(random access memory), ROM(read-only memory), 강체 자기 디스크 및 광 디스크가 있다. 광 디스크의 현재 예로는 CD-ROM(compact disk read only memory), CD-R/W(compact disk-read/write) 및 DVD가 있다.

상기 설명된 기능들 중 하나 또는 그 이상은 호스트 방식으로 서비스로서 구현될 수도 있다.

지금까지 본 발명의 특정 실시예들에 의해 수행되는 특정 순서의 동작들에 대해 설명하였지만, 그와 같은 순서는 예시적인 것이며, 다른 실시예들은 다른 순서로 동작들을 수행하고, 특정 동작을 조합하고, 특정 동작을 중복하는 등을 할 수 있음을 알아야 한다. 주어진 실시예에 대한 설명은 설명된 실시예가 특정의 형상, 구조 또는 특징을 포함할 수 있는 것을 나타내나, 모든 실시예가 반드시 그 특정의 형상, 구조 또는 특징을 포함한다는 것은 아니다.

마지막으로 시스템의 주어진 성분들은 개별적으로 설명되었지만, 당업자라면 그 기능의 일부는 주어진 명령어, 프로그램 시퀀스, 코드 부분 등에서 조합 또는 공유될 수 있음을 잘 알 것이다.

본 발명의 청구범위는 하기와 같다.

본 발명과 그 이점을 보다 철저히 이해하기 위하여, 이제 본 발명을 첨부도면을 참조로 하기의 상세한 설명을 통해 설명한다.

도 1A는 본 명세서에서 설명된 청구 대상을 구현할 수 있는 데이터 처리 시스템의 대표적인 네트워크를 도시한 도.

도 1B는 개시된 청구 대상이 구현될 수 있는 데이터 처리 시스템 내에서 사용될 수 있는 대표적인 컴퓨터 구조를 도시한 도.

도 2는 연합 환경의 전문 용어를 나타내는 블록도.

도 3은 설명된 청구 대상의 실시예를 지원하는데 이용될 수 있는 몇 가지 연합 구조 성분을 가진 주어진 도메인에서의 기존 데이터 처리 시스템의 통합을 나타내는 블록도.

도 4는 연합 구조 내의 몇 가지 성분이 설명된 청구 대상의 구현을 지원하는 신뢰 관계를 구축하는데 이용될 수 있는 방식의 예를 나타내는 블록도.

도 5는 설명된 청구 대상을 지원할 수 있는 대표적인 연합 구조에 따라서 신뢰 프록시와 신뢰 브로커를 이용하는 연합 도메인들 간의 대표적인 신뢰 관계 세트를 나타내는 블록도.

도 6은 연합 싱글 사인 온 동작을 지원하는 연합 환경을 나타내는 블록도.

도 7A는 연합 사용자 라이프사이클 관리 기능을 구현하기 위한 종래 기술을 나타내는 도.

도 7B는 연합 사용자 라이프사이클 관리 기능을 구현하면서 그와 같은 기능 을 위한 폴리시 기반 메카니즘을 구현하기 위한 다른 공지 기술을 나타내는 도.

도 7C는 FULM 메시지에 관하여 도 7B의 폴리시 필터와 엔진과 관련하여 처리되는 데이터 요소의 일부에 대한 추가적인 상세를 보여주는 도.

도 8은 본 발명의 청구 대상에 따른 DRM 폴리시 강화 연합 내의 참여 실체 세트의 블록도.

도 9는 DRM 폴리시 강화 연합에서의 제1의 예시적인 시나리오를 나타내는 도.

도 10은 DRM 폴리시 강화 연합에서의 제2의 예시적인 시나리오를 나타내는 도.

도 11은 DRM 폴리시 강화 연합에서의 제3의 예시적인 시나리오를 나타내는 도.

도 12는 제1 데이터 처리 시스템이 분산된 주장 검색을 지원하는 분산형 데이터 처리 시스템을 이용하여 구현되는 신원 제공자 내의 제2 데이터 처리 시스템으로부터 주장을 검색하는 시나리오를 보여주는 블록도.

도 13은 다른 대표적인 디지털 권리 관리 시나리오를 보여주는 도.

Claims (15)

1. 삭제
2. 삭제
3. 삭제
4. 삭제
5. 삭제
6. 삭제
7. 서비스 제공자, 디지털 권리 관리(digital rights management; DRM) 특권 제공자, 및 DRM 폴리시 제공자도 포함하는 연합에 참여하는 신원 제공자에서 동작하는 방법으로서, 하나의(a piece of) 콘텐츠와 연관된 DRM 방식을 실시하는 방법에 있어서,

   발생(occurrence)시, 상기 하나의 콘텐츠에의 접근을 요구하는 최종 사용자와 연관된 하나 이상의 DRM 특권들 세트가 평가에 이용될 수 있는지 여부를 결정하고;

   상기 하나 이상의 DRM 특권들 세트가 평가에 이용될 수 없다면, 상기 DRM 특권 제공자로부터 상기 하나 이상의 DRM 특권들 세트를 검색하고;

   DRM 폴리시가 평가될 것인지의 여부와 이용가능한 것인지의 여부를 결정하고;

   상기 DRM 폴리시가 평가될 것이고 이용가능한 것이 아니라면, 상기 DRM 폴리시 제공자로부터 상기 DRM 폴리시를 검색하고;

   상기 DRM 폴리시에 대해 상기 하나 이상의 DRM 특권들 세트를 평가하고;

   상기 평가에 기초하여, 상기 하나의 콘텐츠에의 접근을 요구하는 최종 사용자와 연관된 하나 이상의 DRM 특권들 세트에 대한 참조를 포함하는 메시지를 발생하며;

   상기 서비스 제공자 실체에 상기 메시지를 전달하는 것을 포함하는 디지털 권리 관리 방식 실시 방법.
8. 하나의(a piece of) 콘텐츠와 연관된 디지털 권리 관리(digital rights management; DRM) 방식을 실시하는 데이터 처리 시스템에 있어서,

   프로세서;

   상기 프로세서에 의해 실행되며, 상기 하나의 콘텐츠에의 접근을 요구하는 최종 사용자와 연관된 하나 이상의 DRM 특권들 세트가 평가에 이용될 수 있는지 여부를 결정하는 코드;

   상기 프로세서에 의해 실행되며, 상기 하나 이상의 DRM 특권들 세트가 평가에 이용될 수 없다면, DRM 특권 제공자로부터 상기 하나 이상의 DRM 특권들 세트를 검색하는 코드;

   상기 프로세서에 의해 실행되며, DRM 폴리시가 평가될 것인지의 여부와 이용가능한 것인지의 여부를 결정하는 코드;

   상기 프로세서에 의해 실행되며, 상기 DRM 폴리시가 평가될 것이고 이용가능한 것이 아니라면, DRM 폴리시 제공자로부터 상기 DRM 폴리시를 검색하는 코드; 및

   상기 프로세서에 의해 실행되며, 상기 DRM 폴리시에 대해 상기 하나 이상의 DRM 특권들 세트를 평가하는 코드를 포함하는 데이터 처리 시스템.
9. 제8항에 있어서,

   상기 프로세서에 의해 실행되며, 상기 평가에 응답하여, 상기 하나의 콘텐츠에의 접근을 요구하는 최종 사용자와 연관된 하나 이상의 DRM 특권들 세트에 대한 참조를 포함하는 메시지를 발생하는 코드; 및

   상기 프로세서에 의해 실행되며, 서비스 제공자 실체에 상기 메시지를 전달하는 코드를 더 포함하는 데이터 처리 시스템.
10. 하나의(a piece of) 콘텐츠와 연관된 디지털 권리 관리(digital rights management; DRM) 방식을 실시하기 위해 프로세서에서 실행될 수 있는 컴퓨터 프로그램이 기록되어 있는 컴퓨터 판독가능한 기록매체에 있어서, 상기 컴퓨터 프로그램은,

    상기 프로세서에 의해 실행되며, 상기 하나의 콘텐츠에의 접근을 요구하는 최종 사용자와 연관된 하나 이상의 DRM 특권들 세트가 평가에 이용될 수 있는지 여부를 결정하는 코드;

    상기 프로세서에 의해 실행되며, 상기 하나 이상의 DRM 특권들 세트가 평가에 이용될 수 없다면, DRM 특권 제공자로부터 상기 하나 이상의 DRM 특권들 세트를 검색하는 코드;

    상기 프로세서에 의해 실행되며, DRM 폴리시가 평가될 것인지의 여부와 이용가능한 것인지의 여부를 결정하는 코드;

    상기 프로세서에 의해 실행되며, 상기 DRM 폴리시가 평가될 것이고 이용가능한 것이 아니라면, DRM 폴리시 제공자로부터 상기 DRM 폴리시를 검색하는 코드; 및

    상기 프로세서에 의해 실행되며, 상기 DRM 폴리시에 대해 상기 하나 이상의 DRM 특권들 세트를 평가하는 코드를 포함하는 것인, 컴퓨터 판독가능한 기록매체.
11. 제7항에 있어서, 상기 DRM 특권 제공자 및 상기 DRM 폴리시 제공자는 상기 연합 내의 싱글 서비스 제공자인 것인 디지털 권리 관리 방식 실시 방법.
12. 제7항에 있어서, 상기 신원 제공자 및 상기 DRM 특권 제공자는 상기 연합 내의 싱글 서비스 제공자인 것인 디지털 권리 관리 방식 실시 방법.
13. 제7항에 있어서, 상기 서비스 제공자 및 상기 DRM 특권 제공자는 상기 연합 내의 싱글 서비스 제공자인 것인 디지털 권리 관리 방식 실시 방법.
14. 제7항에 있어서, 상기 신원 제공자 및 상기 DRM 폴리시 제공자는 상기 연합 내의 싱글 서비스 제공자인 것인 디지털 권리 관리 방식 실시 방법.
15. 제7항에 있어서, 상기 서비스 제공자 및 상기 DRM 폴리시 제공자는 상기 연합 내의 싱글 서비스 제공자인 것인 디지털 권리 관리 방식 실시 방법.

Images