KR100800345B1 - 이종 연합 환경에서 통합 사인오프하기 위한 방법 및시스템 - Google Patents

Abstract

본 발명은 연합 환경 내의 연합 도메인들이 상호동작하는 방법을 제공한다. 한 연합체 내의 도메인은 다른 연합 도메인의 사용자에 대해 연합 단일 서명 동작을 개시할 수 있다. 한 도메인 내의 접점 서버는 이 도메인 내의 신뢰 프록시에 의존하여 이 도메인과 해당 연합체 간의 신뢰 관계를 관리한다. 신뢰 프록시는 필요시 다른 연합 도메인으로부터의 주장을 해석한다. 신뢰 프록시는 하나 이상의 신뢰 중재자와 신뢰 관계를 가질 수 있으며, 신뢰 프록시는 주장을 해석할 때 신뢰 중재자에게 지원을 의존할 수 있다. 사용자가 다른 연합 도메인의 사용자에 대해 연합 단일 서명 동작을 개시한 도메인으로부터의 로그오프를 요청한 경우, 이 도메인은 이 다른 연합 도메인에서의 로그오프 동작을 요청함으로써 통합 로그오프 동작을 개시하고, 이것은 또한, 이 다른 연합 도메인이 연합 단일 서명 동작을 개시한 도메인에 대해 단계적으로 로그오프 동작을 개시할 수 있다.

Description

이종 연합 환경에서 통합 사인오프하기 위한 방법 및 시스템{METHOD AND SYSTEM FOR CONSOLIDATED SIGN-OFF IN A HETEROGENEOUS FEDERATED ENVIRONMENT}

본 발명은 개선된 데이터 처리 시스템에 관한 것으로서, 특히, 멀티컴퓨터 데이터 전송을 위한 방법 및 장치에 관한 것이다. 보다 구체적으로는, 본 발명은 네트워크 컴퓨터 시스템에 관한 것이다.

<관련 출원에 대한 상호 참조>

본 출원은 공동 양수인을 갖는 다음 출원에 관한 것이다.

발명의 명칭이 "Efficient browser-based identity management providing personal control and anonymity"이고 (TBD)에 출원된 미국 특허출원 일련번호(대리인 정리번호 CH920020006);

발명의 명칭이 "Method and System for Proof-of-Possession Operations Associated with Authentication Assertions in a Heterogeneous Federated Environment"이고 2002년 xx월 xx일에 출원된 미국 특허출원 일련번호(대리인 정리번호 AUS920020410US1);

발명의 명칭이 "Local Architecture for Federated Heterogeneous System"이고 2002년 xx월 xx일에 출원된 미국 특허출원 일련번호(대리인 정리번호 AUS920020411US1);

발명의 명칭이 "Method and System for Attribute Exchange in a Heterogeneous Federated Environment"이고 2002년 xx월 xx일에 출원된 미국 특허출원 일련번호(대리인 정리번호 AUS920020412US1);

발명의 명칭이 "Method and System for Authentication in a Heterogeneous Federated Environment"이고 2002년 xx월 xx일에 출원된 미국 특허출원 일련번호(대리인 정리번호 AUS920020413US1); 및

발명의 명칭이 "Method and System for Native Authentication Protocol in a Heterogeneous Federated Environment"이고 2002년 xx월 xx일에 출원된 미국 특허출원 일련번호(대리인 정리번호 AUS920020486US1).

통상, 기업들은 인터넷 등의 다양한 네트워크를 통해 사용자 친화적인 방법으로 보호 자원에 대한 보안 액세스를 인가된 사용자에게 제공하려 한다. 보안 인증 메커니즘을 제공하면 비인가 액세스가 보호 자원에 접속될 위험은 감소되지만, 이 동일 인증 메커니즘이 사용자의 보호 자원과의 상호동작에 장벽이 될 수 있다. 사용자는 통상, 애플리케이션들을 지원하는 각각의 특정 시스템을 보호하는 인증 장벽에 관계없이 하나의 애플리케이션과의 상호동작으로부터 다른 애플리케이션과의 상호동작으로 이동할 능력을 갖기를 원한다.

사용자가 보다 정교해짐에 따라, 사용자는 컴퓨터 시스템이 자신의 동작에 조화되어 사용자에게 부과되는 부담이 감소될 것을 기대한다. 또한, 이러한 기대의 유형은 인증 프로세스에도 적용된다. 사용자는 자신이 일부 컴퓨터 시스템에 의해 인증되면, 이 인증이 사용자의 작업 세션에 걸쳐, 또는 적어도 특정 기간동안 사용자에게 거의 보이지 않는 다양한 컴퓨터 아키텍처 경계에 관계없이 유효하여야 한다고 가정할 수 있다. 기업들은 사용자를 편리하게 하는 것 뿐만 아니라 사용자 효율이 종업원 생산성에 관한 것인지 또는 고객 만족도에 관한 것인지에 관계없이 사용자 효율을 증가시키는 것에 대하여 기업이 전개한 시스템의 동작 특성에서 사용자의 기대를 충족시키려고 노력한다.

보다 구체적으로는, 많은 애플리케이션이 공통 브라우저를 통해 액세스가능한 웹 기반 사용자 인터페이스를 갖는 현재의 컴퓨팅 환경에서, 사용자는 하나의 웹 기반 애플리케이션으로부터 다른 웹 기반 애플리케이션으로의 이동에 대한 보다 사용자 친화적이고 적거나 또는 빈번하지 않은 장벽을 기대한다. 이 경우, 사용자는 각 특정 도메인을 보호하는 인증 장벽에 관계없이 하나의 인터넷 도메인의 애플리케이션과의 상호 동작으로부터 다른 인터넷 도메인의 다른 애플리케이션으로 이동할 수 있는 능력을 기대하게 될 것이다. 그러나, 많은 시스템이 사용상 편리한 웹 기반의 인터페이스를 통해 보안 인증을 제공하는 경우에도, 사용자는 여전히 일련의 도메인에 걸친 사용자 액세스를 방해하는 다수의 인증 프로세스에 직면하게 될 수 있다. 사용자로 하여금 주어진 시간 프레임에 다수의 인증 프로세스를 경험하게 하는 것은 사용자의 효율성에 상당한 영향을 끼칠 수 있다.

사용자와 컴퓨터 시스템 관리자의 인증 부담을 경감시키는 다양한 기술이 사용되고 있다. 이 기술들은 통상, 사용자가 서명(sign-on) 동작을 완료한 후에, 즉 인증된 후에는 사용자가 다른 인증 동작을 수행할 필요가 없다고 하는 공통의 목적 을 갖고 있기 때문에 통상 "단일 서명(single-sign-on; SSO)"이라고 표현한다. 따라서, 목표는 사용자가 특정 사용자 세션 동안 단지 하나의 인증 프로세스를 완료할 것을 요구하는 것이다.

이러한 단일 서명 솔루션은 소정의 기업 내에 구현되는 경우에는 성공적이다. 그러나, 보다 많은 기업이 e-커머스 시장 또는 다른 인터넷에 의해 접속된 협동 작업(collaborative endeavor)에 참여함에 따라 다수의 인증 프로세스 또는 시스템에 의해 제공되는 장벽이 많아지고 있다. 이전의 기업들 간의 단일 서명 솔루션은 참여 기업들 간의 미리 확립된 사업 협정이 있는 동종 환경에 국한되었다. 이들 사업 협정은 신뢰를 확립하고 정보가 기업들 간에 보안 방식으로 전송되는 방식을 제한 및 한정하는데 일부 사용된다. 또한, 이들 사업 협정은 하나의 기업용으로부터 다른 기업용으로 사용자 아이덴티티를 번역 또는 매핑하는 방식 그리고 참여 기업들 간에 사용자를 보증하는데 사용되는 정보의 전송 방식에 대한 규칙의 기술적 협의를 포함한다.

다시 말하면, 이전의 단일 서명 솔루션은 미리 협상되거나 미리 구성된 협정에 기초하여 다른 기업에 의해 제작된 인증 주장(authentication assertion; 주장에서 제공된 사용자의 아이덴티티와 함께)을 한 기업이 신뢰할 수 있게 한다. 개별 기업 각각은 e-커머스 시장 내의 기업과 같이 유사한 협정을 교환한 다른 기업에 의해 이해될 수 있는 인증 주장을 생성 및 이해하는 방식을 인지하고 있다. 이들 동종 환경은 이들 시스템에 걸쳐 사용자 아이덴티티를 매핑하는 기업에 의해 알려진 결정적 관계가 있기 때문에 강하게 결합되어 있다. 이러한 강한 결합은 단일 서명 환경을 확립하는데 사용되는 사업 협정으로 인해 가능하다. 참여 기업이 이러한 이전의 단일 서명 솔루션을 사용하여 동종 환경 내에 협력할 수 있지만, 이들 환경은 다수의 동종 환경, 예를 들면, 직접 접속된 e-커머스 시장을 직접 접속하려는 필요 또는 요구의 관점에서는 제한적이다.

추가로, 시스템의 안전을 확보하는 최적 요소는 사용자가 시스템에 대한 자신의 아이덴티티를 증명하는 인증 동작을 완료하는 것을 요건으로 한다. 이 프로세스에서, 이에 못지 않게 중요한 요소는 사용자가 보안 세션을 종료시키는 로그오프 동작을 완료함으로써 다른 사용자들을 도용 또는 유효 세션에 대한 악의적인 방해로부터 보호하는 것을 요건으로 한다. 따라서, 참여 기업들 간의 미리 결정된 기업 및 기술적 번역 협정의 부재시에 기업이 사용자에게 유사한 단일 서명 및 유사한 단일 서명 경험을 제공할 수 있는 방법 및 시스템이 요구된다.

본 발명은 연합 환경 내의 연합 도메인(federated domain)들이 상호동작하는 방법, 장치, 시스템 및 컴퓨터 프로그램 제품을 제공한다. 한 연합체 내의 도메인은 다른 연합 도메인의 사용자에 대해 연합 단일 서명 동작을 개시할 수 있다. 한 도메인 내의 접점 서버는 이 도메인 내의 신뢰 프록시에 의존하여 이 도메인과 해당 연합체 간의 신뢰 관계를 관리한다. 신뢰 프록시는 필요시 다른 연합 도메인으로부터의 주장을 해석한다. 신뢰 프록시는 하나 이상의 신뢰 중재자와 신뢰 관계를 가질 수 있으며, 신뢰 프록시는 주장을 해석할 때 신뢰 중재자에게 지원을 의존할 수 있다. 사용자가 다른 연합 도메인의 사용자에 대해 연합 단일 서명 동작을 개시한 도메인으로부터의 로그오프를 요청한 경우, 이 도메인은 이 다른 연합 도메인에서의 로그오프 동작을 요청함으로써 통합 로그오프 동작을 개시하고, 이것은 또한, 이 다른 연합 도메인이 연합 단일 서명 동작을 개시한 도메인에 대해 단계적으로 로그오프 동작을 개시할 수 있다. 또한, 도메인이 특정 사용시에 로그오프 이벤트에 등록할 수 있는 발행/등록 모델(publish-and-subscribe model, 이것은 point-to-point model을 일대일 모델이라고 부르는 것에 대하여 다대다 모델이라고도 함)도 지원된다.

본 발명의 신규한 특성이 후술하는 청구항에 기재되어 있다. 본 발명 자체 및 이의 목적 및 이점은 첨부 도면과 함께 상세한 설명을 참조하여 가장 잘 이해될 수 있다.

도 1a는 각각이 본 발명을 구현할 수 있는 대표적인 데이터 처리 시스템 네트워크를 나타내는 도면이다.

도 1b는 본 발명이 구현될 수 있는 데이터 처리 시스템에 사용될 수 있는 대표적인 컴퓨터 아키텍처를 나타내는 도면이다.

도 1c는 클라이언트가 서버의 보호 자원에 액세스하려고 시도하는 경우에 사용될 수 있는 대표적인 인증 프로세스를 나타내는 데이터 흐름도이다.

도 1d는 본 발명이 구현될 수 있는 대표적인 웹 기반 환경을 나타내는 네트워크를 나타내는 도면이다.

도 1e는 사용자로부터 다수의 인증 동작을 요구할 수 있는 대표적인 온라인 트랜잭션의 일 예를 나타내는 블록도이다.

도 2a는 제1 연합 기업에 대하여 사용자에 의해 개시되어, 이에 응답하여 연합 환경 내의 다운스트림 엔티티의 동작을 호출하는 트랜잭션에 관한 연합 환경의 용어(terminology)를 나타내는 블록도이다.

도 2b는 본 발명의 일 실시예에 따른 본 발명의 연합 아키텍처 컴포넌트의 일부와 소정 도메인의 기존 시스템과의 통합을 나타내는 블록도이다.

도 2c는 본 발명의 구현에 따라 연합 아키텍처를 나타내는 블록도이다.

도 2d는 본 발명에 따른 신뢰 프록시와 신뢰 중재인을 사용하여 연합 도메인 간의 일련의 예시적인 신뢰 관계를 나타내는 블록도이다.

도 3a는 연합 환경 내에서 주장을 생성하는 발의 도메인(issuing domain)에서 일반화된 프로세스를 나타내는 흐름도이다.

도 3b는 주장을 분할하는 의존 도메인(relying domain)에서 일반화된 프로세스를 나타내는 흐름도이다.

도 3c는 발의 도메인에서 사용자 동작에 응답하여 발의 도메인으로부터 의존 도메인으로 주장을 푸시하는 특정 프로세스를 나타내는 흐름도이다.

도 3d는 발의 도메인이 의존 도메인으로의 아웃고잉 요청을 능동적으로 가로채는 것에 응답하여 발의 도메인으로부터 의존 도메인으로 주장을 푸시하는 특정 프로세스를 나타내는 흐름도이다.

도 3e는 의존 도메인이 발의 도메인으로부터 사용자에 대한 임의의 요청된 주장을 요청하면서 요청 사용자로부터 의존 도메인에 의해 수신된 자원 요청의 만 족을 시도하는 풀 모델(pull model)을 나타내는 흐름도이다.

도 4는 연합 단일 서명 동작을 지원하는 연합 환경을 나타내는 블록도이다.

도 5는 HTTP 재지정(redirection)을 통해 연합 도메인 중에서 통합 로그오프 동작을 실행하는 프로세스를 나타내는 흐름도이다.

도 6은 SOAP 백채널 방법을 이용하여 연합 도메인 중에서 통합 로그오프 동작을 실행하는 프로세스를 나타내는 흐름도이다.

도 7a 및 도 7b는 발행/등록 모델을 이용하여 SOAP 방식으로 연합 도메인 중에서 통합 로그오프 동작을 실행하는 한 쌍의 프로세스를 나타내는 한 쌍의 흐름도이다.

도 8a 및 도 8b는 하나의 연합체 안에서 통합 로그오프 동작으로부터의 상태 메시지를 포함하는 그래픽 사용자 인터페이스(GUI) 윈도우를 나타내는 도면이다.

통상, 본 발명을 포함하거나 이에 관련된 장치는 광범위한 데이터 처리 기술을 포함한다. 따라서, 배경 기술로서, 분산 데이터 처리 시스템 내의 하드웨어와 소프트웨어 컴포넌트의 종래 구조를 본 발명의 설명 이전에 상세히 설명한다.

이제 도면을 참조하면, 도 1a는 각각이 본 발명을 구현할 수 있는 대표적인 데이터 처리 시스템의 네트워크를 나타낸다. 분산 데이터 처리 시스템(100)은 분산 데이터 처리 시스템(100) 내에 함께 접속된 다수의 장치 및 컴퓨터 간의 통신 링크를 제공하는데 사용될 수 있는 매체인 네트워크(101)를 포함한다. 네트워크(101)는 유선 또는 광섬유 케이블과 같은 영구 접속, 또는 전화 또는 무선 통신을 통해 행해지는 일시 접속을 포함할 수 있다. 도시한 예에서, 서버(102)와 서버(103)는 저장부(104)와 함께 네트워크(101)에 접속된다. 또한, 클라이언트(105 내지 107)도 역시 네트워크(101)에 접속된다. 클라이언트(105 내지 107)와 서버(102 및 103)는 메인프레임, 개인용 컴퓨터, 개인용 휴대 단말(PDA) 등과 같은 다양한 컴퓨팅 장치로 나타낼 수 있다. 분산 데이터 처리 시스템(100)은 추가 서버, 클라이언트, 라우터, 다른 장치, 및 도시하지 않은 피어 대 피어 아키텍처를 포함할 수 있다.

도시한 예에서, 분산 데이터 처리 시스템(100)은 LDAP(경량 디렉토리 액세스 프로토콜), TCP/IP(전송 제어 프로토콜/인터넷 프로토콜), HTTP(하이퍼텍스트 전송 프로토콜) 등과 같이 다수의 프로토콜을 사용하여 서로 통신하는 전세계 네트워크와 게이트웨이 모음을 나타내는 네트워크(101)를 구비한 인터넷을 포함할 수 있다. 물론, 분산 데이터 처리 시스템(100)은 또한, 예를 들면, 인트라넷, 근거리 네트워크(LAN), 또는 광역 네트워크(WAN)와 같은 다수의 상이한 유형의 네트워크를 포함할 수 있다. 예를 들면, 서버(102)는 무선 통신 링크를 포함하는 네트워크(110)와 클라이언트(109)를 직접 지원한다. 네트워킹 가능한 무선 전화(111)는 무선 링크(112)를 통해 네트워크(110)에 접속하고, PDA(113)는 무선 링크(114)를 통해 네트워크(110)에 접속한다. 무선 전화(111)와 PDA(113)는 또한 블루투스^TM 무선 기술과 같은 적절한 기술을 사용하여 무선 링크(115)를 통해 상호간에 데이터를 직접 전송하여 이른바 개인 영역 네트워크(personal area network) 또는 개인용 임시 네트워 크를 생성할 수 있다. 유사한 방식으로, PDA(113)는 무선 통신 링크(116)를 통해 PDA(107)에 데이터를 전송할 수 있다.

본 발명은 다양한 하드웨어 플랫폼 및 소프트웨어 환경 상에서 구현될 수 있다. 도 1a는 이종 컴퓨팅 환경의 일 예를 나타내지만 본 발명을 구조적으로 제한하려는 것은 아니다.

이제 도 1b를 참조하면, 본 발명이 구현될 수 있는, 도 1a에 도시한 바와 같이, 종래 데이터 처리 시스템의 컴퓨터 아키텍처를 나타내는 도면이 도시되어 있다. 데이터 처리 시스템(120)은 프린터(130), 디스크 유닛(132) 또는 다른 오디오 출력 시스템과 같은 미도시한 다른 장치 등의 다수의 입출력 장치를 지원하는 입출력 어댑터(128), 랜덤 액세스 메모리(RAM; 124), 및 판독 전용 메모리(ROM; 126)를 직접 접속하는 내부 시스템 버스(123)에 접속된 하나 이상의 중앙 처리부(CPU; 122)를 포함한다. 또한, 시스템 버스(123)는 통신 링크(136)에의 액세스를 제공하는 통신 어댑터(134)를 접속한다. 사용자 인터페이스 어댑터(148)는 키보드(140)와 마우스(142), 터치 스크린, 스타일러스, 마이크로폰 등과 같은 미도시한 다른 장치 등의 다수의 사용자 장치를 접속한다. 디스플레이 어댑터(144)는 디스플레이 장치(146)에 시스템 버스(123)를 접속한다.

당업자는 도 1b의 하드웨어가 시스템 구현에 따라 변할 수 있음을 이해할 것이다. 예를 들면, 시스템은 Intel

펜티엄

기반 프로세스 및 디지털 신호 처리기(DSP)와 같은 하나 이상의 프로세스, 및 하나 이상의 유형의 휘발성 및 비휘발성 메모리를 가질 수 있다. 도 1b에 도시한 하드웨어에 더하여 또는 이를 대신하여 다른 주변 장치가 사용될 수도 있다. 도시한 예는 본 발명에 대한 구조적 제한을 암시하려는 것은 아니다.

본 발명은 다양한 하드웨어 플랫폼 상에서 구현될 수 있을 뿐만 아니라, 다양한 소프트웨어 환경에서도 구현될 수 있다. 종래 운영 체계는 각각의 데이터 처리 시스템 내의 프로그램 실행을 제어하는데 사용될 수 있다. 예를 들면, 한 장치가 유닉스

운영 체계를 동작할 수 있지만, 다른 장치는 단순 자바

런타임 환경을 포함한다. 대표적인 컴퓨터 플랫폼은 브라우저를 포함할 수 있으며, 이 브라우저는 그래픽 파일, 워드 프로세싱 파일, 확장형 마크업 언어(XML), 하이퍼텍스트 마크업 언어(HTML), 핸드헬드 장치 마크업 언어(HDML), 무선 마크업 언어(WML), 및 다양한 파일의 다른 포맷 및 유형과 같은 다수의 포맷으로 하이퍼텍스트 문서에 액세스하는 공지된 소프트웨어 애플리케이션이다. 또한, 도 1a에 도시한 분산 데이터 처리 시스템은 다양한 피어 대 피어 서브넷과 피어 대 피어 서비스를 완전히 지원할 수 있는 것으로서 고찰될 수 있다.

이제 도 1c를 참조하면, 클라이언트가 서버의 보호 자원에 액세스하려는 경우에 사용될 수 있는 종래 인증 프로세스를 나타내는 데이터 흐름도가 도시되어 있다. 도시한 바와 같이, 클라이언트 워크스테이션(150)의 사용자는 컴퓨터 네트워크를 통해서 클라이언트 워크스테이션에서 실행하는 사용자 웹 브라우저를 이용하여 서버(151)의 보호 자원에 대한 액세스를 시도한다. 보호 자원은 인증 및 인가된 사용자에 의해서만 액세스될 수 있는 범용 자원 위치입력기(URL), 또는 보다 일반적으로, 범용 자원 식별자(URI)에 의해 식별된다. 컴퓨터 네트워크는 도 1a 또 는 도 1b에 도시한 바와 같은 인터넷, 인트라넷, 또는 다른 네트워크일 수 있으며, 서버는 웹 애플리케이션 서버(WAS), 서버 애플리케이션, 서블릿 프로세스 등일 수 있다.

사용자가 도메인("ibm.com") 내의 웹 페이지와 같은 보호 자원을 요청하는 경우에 프로세스가 개시한다(단계 152). 웹 브라우저(또는 관련 애플리케이션 또는 애플릿)는 도메인 "ibm.com"을 호스팅하는 웹 서버에 전송되는 HTTP 요청 메시지를 생성한다(단계 153). 서버는 클라이언트에 대하여 활성 상태인 세션을 갖고 있지 않다고 판정하고(단계 154), 그에 따라서 서버는 클라이언트에게 일부 유형의 인증 시도를 전송하여 사용자가 인증 프로세스를 수행하도록 요청한다(단계 155). 인증 시도는 하이퍼텍스트 마크업 언어(HTML) 형태와 같은 다수의 형태일 수 있다. 그 후, 사용자는 사용자 식별자 및 관련 패스워드와 같은 요청 또는 요구 정보를 제공(단계 156)하거나, 특정 정보를 자동적으로 리턴할 수 있다.

예를 들면, 이전에 제출된 등록 정보를 검색하고 사용자의 저장된 정보와 제공된 인증 정보를 대조하여, 서버가 사용자 또는 클라이언트를 인증한 경우에(단계 158) 인증 응답 정보가 서버에 전송된다(단계 157). 인증이 성공적이라고 가정하면, 인증 사용자 또는 클라이언트에 대하여 활성 상태인 세션이 성립된다.

그 후, 서버는 요청된 웹 페이지를 검색하여 HTTP 응답 메시지를 클라이언트에 전송한다(단계 159). 이 때, 사용자는 하이퍼텍스트 링크를 클릭하여 브라우저 내의 "ibm.com"의 다른 페이지를 요청할 수 있으며(단계 160), 브라우저는 서버에 다른 HTTP 요청을 전송한다(단계 161). 이 때, 서버는 사용자가 활성 상태의 세션 을 갖고 있다는 것을 인식하고(단계 162), 서버는 요청된 웹 페이지를 다른 HTTP 응답 메시지로 클라이언트에게 전송한다(단계 163). 도 1c는 대표적인 종래의 프로세스를 나타내지만, 인증 증거를 제공하는데 사용되는 동일한 쿠키를 사용하는 것을 포함하여, 쿠키를 사용하여 활성 상태의 세션에 의해서 사용자를 식별하는 것과 같은, 다른 대체 세션 상태 관리 기술이 도시될 수 있음을 인식하여야 한다.

이제 도 1d를 참조하면, 네트워크도는 본 발명이 구현될 수 있는 대표적인 웹 기반 환경을 나타낸다. 이 환경에서, 클라이언트(171)의 브라우저(170)의 사용자는 DNS 도메인(173)의 웹 애플리케이션 서버(172)의 보호 자원 또는 DNS 도메인(175)의 웹 애플리케이션 서버(174)의 보호 자원에 액세스하기를 원한다.

도 1c에 나타낸 바와 유사한 방식으로, 사용자는 다수의 도메인 중 한 도메인의 보호 자원을 요청할 수 있다. 특정 도메인에서 서버를 1개만 나타낸 도 1c와 달리, 도 1d에서는 각 도메인이 서버를 다수개 갖는다. 특히, 각 도메인은 관련 인증 서버(176 및 177)를 가질 수 있다.

이 예에서, 클라이언트(171)가 도메인(173)의 보호 자원에 대한 요청을 발의한 후에, 웹 애플리케이션 서버(172)는 클라이언트(171)에 대하여 활성 상태인 세션을 갖고 있지 않다고 판정하고, 인증 서버(176)가 클라이언트(171)와의 적절한 인증 동작을 수행하도록 요청한다. 인증 서버(176)는 인증 동작의 결과를 웹 애플리케이션 서버(172)에 전송한다. 사용자[또는 사용자 대신에 브라우저(170) 또는 클라이언트(171)]가 성공적인 것으로 인증되면, 웹 애플리케이션 서버(172)는 클라이언트(171)에 대한 세션을 성립시켜, 상기 요청된 보호 자원을 리턴한다. 통상, 사용자가 인증 서버에 의해 인증되면, 쿠키가 브라우저 내의 쿠키 캐시에 설정 및 저장될 수 있다. 도 1d는 한 도메인의 처리 자원들이 다수의 서버 간에 공유되어, 특히 인증 동작을 수행할 수 있는 방법의 일 예에 불과하다.

유사하게, 클라이언트(171)가 도메인(175)의 보호 자원에 대한 요청을 발의하는 경우, 인증 서버(177)는 클라이언트(171)와의 적절한 인증 동작을 수행한 후, 웹 애플리케이션 서버(174)는 클라이언트(171)에 대한 세션을 성립시켜, 상기 요청된 보호 자원을 반환한다.

따라서, 도 1d는 클라이언트(171)가 상이한 도메인들에서 다수의 동시발생 세션을 갖지만 다수의 인증 동작을 완료하여 이들 동시발생 세션을 성립시키도록 요구되는 것을 나타낸다.

이제 도 1e를 참조하면, 한 명의 사용자로부터 다수의 인증 동작을 요구할 수 있는 대표적인 온라인 트랜잭션의 일 예를 나타내는 블록도가 도시되어 있다. 도 1c 및 도 1d를 참조하면, 사용자에게는 도 1c에 도시한 바와 같이 관리되고 잇는 자원에의 액세스를 얻기 전에 인증 동작을 완료할 것이 요구될 수 있다. 도 1c에는 도시하지 않았지만, 인증 관리자가 서버(151)에 배치되어 사용자를 인증하는데 필요한 사용자 정보를 검색 및 사용할 수 있다. 도 1d에 도시한 바와 같이, 사용자는 상이한 도메인(173 및 175)에 있는 다수의 현재 세션을 가질 수 있으며, 도 1d에 도시되지는 않았지만, 각 도메인은 인증 서버에 대신하여 또는 이에 더하여 인증 관리자를 사용할 수 있다. 유사한 방식으로, 도 1e는 또한 각각이 일부 유형의 인증 관리자를 지원하는 일련의 도메인을 나타낸다. 도 1e는 사용자가 각 도메 인마다 인증 동작을 완료할 것을 요구하는 다수의 도메인을 액세스할 때 사용자가 겪을 수 있는 일부 어려움을 나타낸다.

사용자(190)는 ISP(인터넷 서비스 제공자) 도메인(191)에 등록되어 있을 수 있으며, 이는 ISP 도메인(191)에 관한 트랜잭션을 완료할 목적으로 사용자(190)를 인증하는 인증 관리자(192)를 지원할 수 있다. ISP 도메인(191)은 인터넷 접속 서비스, 이메일 서비스 및 가능하게는 다른 e-커머스 서비스를 제공하는 인터넷 서비스 제공자(ISP)일 수 있다. 다르게는, ISP 도메인(191)은 사용자(190)에 의해 자주 액세스되는 인터넷 포털일 수 있다.

유사하게, 도메인(193, 195, 및 197)은 통상의 웹 서비스 제공자를 나타낸다. 정부 도메인(193)은 다양한 정부 관련 트랜잭션을 완료하기 위한 사용자를 인증하는 인증 관리자(194)를 지원한다. 은행 도메인(195)은 온라인 은행과의 트랜잭션을 완료하기 위한 사용자를 인증하는 인증 관리자(196)를 지원한다. e-커머스 도메인(197)은 온라인 구입을 완료하기 위한 사용자를 인증하는 인증 관리자(198)를 지원한다.

상술한 바와 같이, 사용자는 상이한 도메인들의 자원을 액세스하여 인터넷 또는 월드 와이드 웹 내에서 하나의 도메인으로부터 다른 도메인으로 이동하려는 경우, 사용자는 다수의 사용자 인증 요청 또는 요건을 제시받을 수 있어, 일련의 도메인에 걸치는 사용자의 진행을 상당히 지연시킬 수 있다. 도 1e를 예시적인 환경으로 사용하며, 사용자는 18살 이상이고 유효한 운전 면허증, 유효 신용 카드 및 미국 은행 계좌를 갖고 있는 사용자에게 한정된 온라인 서비스를 구입하려는, e-커 머스 도메인(197)과의 복잡한 온라인 트랜잭션에 관련될 수 있다. 이러한 온라인 트랜잭션에는 다수의 도메인(191, 193, 195 및 197)이 수반될 수 있다.

통상, 사용자는 대표적인 온라인 트랜잭션에 관여하고 있는 아이덴티티를 각 도메인에서 유지하지 못할 수도 있다. 이 예에서, 사용자(190)는 사용자 ISP에 자신의 아이덴티티를 등록하였을 수 있지만, 온라인 트랜잭션을 완료하기 위해서, 사용자는 도메인(193, 195 및 197)에 대해서도 인증을 요구받을 수 있다. 이들 각 도메인이 사용자에 대한 아이덴티티를 유지하고 있지 않은 경우, 사용자의 온라인 트랜잭션을 실패할 수 있다. 사용자가 각 도메인에 의해 인증될 수 있다고 하더라도, 이것이, 상이한 도메인들이 사용자 트랜잭션의 완료를 위해서 그들 사이에 정보를 전송할 수 있음을 보장하지는 않는다. 도 1e에 나타낸 사용자(190)의 경우에, 종래 기술의 환경에서는 사용자(190)가 제1 웹 사이트, 예를 들면, ISP 도메인(191)에 대하여 인증한 후, 단일 서명의 목적을 위해, 도메인(193, 195 및 197)과 같은 다른 웹 서비스 제공자에게 인증 토큰을 전송할 수 있는 것이 없다.

현재 기술 일부에 대한 간단한 설명을 전술하였지만, 나머지 도면에 대한 설명은 본 발명이 동작할 수 있는 연합 컴퓨터 환경에 관한 것이다. 그러나, 본 발명을 보다 상세히 설명하기 전에, 일부 용어에 대해 설명한다.

용어

"엔티티(entity)" 또는 "당사자(party)"라는 용어는 기관, 개인 또는 기관, 시스템에 대신하여 동작하는 기관, 개인 또느 다른 시스템을 통상 의미한다. "도메인(domain)"이라는 용어는 네트워크 환경 내의 추가 특성을 의미하지만, "엔티 티", "당사자", "도메인"은 교환가능하게 사용될 수 있다. 예를 들면, "도메인"이라는 용어는 또한 DNS(도메인 네임 시스템)을 나타낼 수 있으며, 보다 일반적으로는, 외부 엔티티에게 논리 유닛으로 보이는 다양한 장치 및 애플리케이션을 포함하는 데이터 처리 시스템을 의미할 수 있다.

"요청" 및 "응답"이라는 용어는 메시지, 통신 프로토콜 정보, 또는 다른 관련 정보와 같은 특정 동작에서 포함되는 정보의 전송에 적합한 데이터 포맷을 포함하는 것으로 이해되어야 한다. 보호 자원은 액세스가 제어되거나 제한되는 자원(애플리케이션, 객체, 문서, 페이지, 파일, 실행가능 코드, 또는 다른 계산용 자원, 통신용 자원 등)이다.

토큰은 성공 동작의 직접적 증거를 제공하고, 동작을 수행하는 엔티티, 예를 들면, 성공적 인증 동작 후에 발생하는 인증 토큰에 의해 생성된다. 커베로스 토큰(Kerberos token)은 본 발명에서 사용될 수 있는 인증 토큰의 일 예이다. 커베로스 상의 보다 많은 정보는 Kohl 등의 "The Kerberos Network Authentication Service (V5)", Internet Engineering Task Force (IETF) Request for Comments (RFC) 1510, 09/1993에서 발견될 수 있다.

주장(assertion)은 일부 동작의 간접 증거를 제공한다. 주장은 아이덴티티, 인증, 속성, 인증 결정 또는 다른 정보 및/또는 동작의 간접 증거를 제공할 수 있다. 인증 주장은, 인증 서비스는 아니지만 인증 서비스가 경청하는 엔티티에 의해 인증에 대한 간접 증거를 제공한다.

보안 주장 마크업 언어(SAML; Security Assertion Markup Language) 주장은 본 발명 내에 사용될 수 있는 가능한 주장 포맷의 일 예이다. SAML은 비영리 글로벌 컨소시엄인 차세대 정보표준기구(OASIS; Organization for the Advancement of Structured Information Standards)에 의해 공표되었다. SAML은 "Assertions and Protocol for the OASIS Security Assertion Markup Language(SAML)", Committee Specification 01,05/31/2002에 다음과 같이 기재되어 있다.

「보안 주장 마크업 언어(SAML)는 보안 정보를 교환하는 XML 기반의 프레임워크이다. 이 보안 정보는 대상에 대한 주장의 형태로 표현되며, 여기서 대상은 일부 보안 도메인에서 아이덴티티를 갖는 엔티티(사람 또는 컴퓨터)이다. 통상, 대상의 예는 사람이며, 특정 인터넷 DNS 도메인에서 자신의 주소로 식별된다. 주장은 대상에 의해 수행되는 인증 동작에 대한 정보, 대상의 속성, 및 대상이 특정 자원을 액세스할 수 있는지 여부에 대한 인가 결정을 전달할 수 있다. 주장은 XML 구조체로서 표현되고 중첩 구조를 가짐으로써, 단일 주장이 인증, 인가 및 속성에 대한 다수의 상이한 내부 문장을 포함할 수 있다. 인증 문장을 포함하는 주장은 이전에 발생한 인증 행위를 설명하는 것에 불과하다는 것이 이해되어야 한다. 주장은 SAML 기관, 즉 인증 기관, 속성 기관 및 정책 결정 포인트에 의해 발의된다. SAML은 클라이언트가 SAML 기관으로부터 주장을 요청하고 이로부터 응답을 얻을 수 있는 프로토콜을 정의한다. 이러한 프로토콜은 XML 기반 요청 및 응답 메시지 포맷으로 이루어지며, 많은 상이한 하부 통신 및 전송 프로토콜에 한정될 수 있다. 즉, SAML은 현재, HTTP를 통한 SOAP로의 하나의 결합을 정의한다. SAML 기관은 외부 정책 저장소와 같은 정보의 다양한 소스와 이들의 응답을 생성 시에 요청의 입 력으로서 수신되었던 주장을 사용할 수 있다. 따라서, 클라이언트는 항상 주장을 소비하는 입장이지만, SAML 기관은 주장의 생성자이자 소비자일 수 있다.」

SAML 사양은 주장이 발행자에 의해 행해진 하나 이상의 문장을 제공하는 정보 패키지임을 나타낸다. SAML은 발행자가 상이한 3종류의 주장 문장을 작성할 수 있게 한다. 즉, 첫째가 특정 대상이 특정 수단에 의해 특정 시간에 인증되는 인증이고, 둘째가 특정 대상이 특정 자원을 액세스할 수 있게 하는 요청이 승인 또는 거절되는 인가이며, 셋째가 특정 대상이 특정 속성에 관련되는 속성이다. 후술하는 바와 같이, 다양한 주장 포맷이 필요시 다른 주장 포맷으로 번역될 수 있다.

인증은 사용자에 의해 또는 사용자 대신에 제공되는 일련의 자격 증명을 확인하는 프로세스이다. 인증은 사용자가 알고 있는 것, 사용자가 갖고 있는 것, 또는 사용자의 현재 상태, 즉, 사용자에 대한 일부 물리적 특징을 검증함으로써 달성된다. 사용자가 알고 있는 것은 사용자의 패스워드와 같은 공유 비밀, 또는 특정 사용자에게만 알려진 것을 검증하는 사용자의 암호 키 등을 포함할 수 있다. 사용자가 갖고 있는 것은 스마트 카드 또는 하드웨어 토큰을 포함할 수 있다. 사용자에 대한 일부 물리적 특징은 지문 또는 홍채 맵과 같은 생체신호 입력을 포함할 수 있다.

인증 자격증명은 다양한 인증 프로토콜에서 사용되는 일련의 시도/응답 정보이다. 예를 들면, 사용자명과 패스워드 결합은 인증 자격증명의 가장 친숙한 형태이다. 다른 인증 자격증명 형태는 다수의 형태의 시도/응답 정보, 공개 키 기반구조(PKI) 인증서, 스마트 카드, 생체신호 등을 포함할 수 있다. 인증 자격증명은 인증 주장과 구별되며, 인증 자격증명은 인증 서버 또는 서비스를 갖는 인증 프로토콜 시퀀스의 일부로서 사용자에 의해 제공되며, 인증 주장은 필요시 엔티티 사이에 추후 전송되는 사용자의 인증 자격 증명의 성공적인 제시 및 확인에 대한 문장이다.

종래 기술의 단일 서명 솔루션과의 구별

상술한 바와 같이, 종래 기술의 단일 서명 솔루션은 참여 기업들 간에 사업 협정이 미리 설정되어 있는 동종 환경에 국한된다. 이들 사업 협정은 신뢰를 확립하고 기업들간의 안정된 전송을 규정한다. 또한, 이들 사업 협정은 한 기업으로부터 다른 기업으로 사용자 아이덴티티를 번역 또는 매핑하는 방식, 및 참여 기업 사이에 사용자를 보증하는데 사용되는 전송의 전송 방식에 대한 규칙에 대한 기술적 합의를 포함한다.

다시 말하면, 이전의 단일 서명 솔루션에 의해서, 하나의 기업은 미리 협상되거나 미리 구성된 협의에 기초하여 다른 기업에 의해 부여된 인증 주장을 (이 주장에서 제공된 사용자의 아이덴티티와 함께) 신뢰할 수 있는 것이다. 유사 협정을 교환하는 다른 기업, 예컨대 각각의 개별 기업은 e-커머스 시장 내의 어떤 기업에 의해 이해될 수 있는 인증 주장을 어떻게 생성 및 해석하는지를 인지하고 있다. 이들 동종 환경은 이들 시스템에 걸쳐 사용자 아이덴티티를 매핑하기 위한 기업에 의해 알려진 결정적 관계가 있기 때문에 매우 강하게 결합된다. 이러한 강력한 결합은 단일 서명 환경을 확립하는데 사용되는 사업 협정이 있기 때문에 가능하다.

본 발명의 연합 모델

월드 와이드 웹의 경우, 사용자는 각각의 특정 도메인 사이의 정보 장벽에 거의 관계없이 하나의 인터넷 도메인의 애플리케이션과의 상호 동작으로부터 다른 도메인의 다른 애플리케이션으로 이동할 수 있는 능력을 기대하게 된다. 사용자는 단일 트랜잭션에 대하여 다수의 도메인에 인증하게 함으로써 야기되는 좌절을 원하지 않는다. 다시 말하면, 사용자는 기관들이 협력하기를 기대하지만 사용자는 일반적으로 도메인들이 사용자의 프라이버시를 존중해줄 것을 원한다. 또한, 사용자는 개인 정보를 영구 저장하는 도메인을 제한하기를 선호할 수 있다. 사용자의 이러한 기대가, 많은 기업 및 기관이 경쟁적인 인증 기술을 발표하는 매우 급속히 발전하는 이종 환경에 존재한다.

종래 시스템과 달리, 본 발명은 특정 기업들 간의 구체적이고, 미리 설정된 사업 및 기술 협정의 부재 시에 기업이 사용자에게 단일 서명 경험을 제공할 수 있게 하는 연합 모델을 제공한다. 다시 말하면, 본 발명은 연합된 이종 환경을 지원한다. 본 발명의 목적의 일 예로서, 도 1e를 다시 참조하면, 사용자는 도메인(191)에 인증한 후 도메인(191)이 트랜잭션에 포함될 수 있는 각각의 다운스트림 도메인에 적절한 주장을 제공하게 할 수 있다. 이들 다운스트림 도메인은 도메인(191)과 다른 다운스트림 도메인 간의 미리 설정된 주장 포맷이 없는 경우에도 인증 주장 및/또는 다른 유형의 주장을 이해 및 신뢰할 수 있을 필요가 있다. 주장의 인식에 더하여, 다운스트림 도메인은 미리 설정된 아이덴티티 매핑 관계가 없는 경우에도, 그 주장 내에 포함된 아이덴티티를, 특정 도메인에서 사용자(190)를 나타내는 아이덴티티로 번역할 수 있어야 한다.

본 발명은 연합 환경에 관한 것이다. 통상, 기업은 기업 자신의 사용자 레지스트리를 가지며, 기업 자신의 사용자 집단과 관계를 유지하고 있다. 각 기업은 통상, 이 사용자들을 인증하는 기업 자신의 수단을 구비하고 있다. 그러나, 본 발명의 연합 방식에 의해서, 기업들은 한 기업 내의 사용자가 기업 연합에 참여함으로써 일련의 기업들과의 관계에 영향을 미칠 수 있도록 집단 방식으로 협력할 수 있는 것이다. 사용자는 마치 각 기업과 직접 관계가 있는 것처럼 연합 기업 중 오느 한 기업의 자원에 대한 액세스를 허가받을 수 있다. 사용자는 각 관심있는 기업마다 등록할 필요가 없으며, 사용자는 계속해서 자신을 식별 및 인증할 필요가 없다. 따라서, 이러한 연합 환경에서의 인증 방식은 정보 기술에서 급속하게 발전하는 이종 환경에서도 단일 서명 방식을 가능하게 한다.

본 발명에서, 연합은 사용자에게 단일 서명의 사용상 편리한 경험을 제공하도록 협동하는 기업, 기관, 기구 등과 같은 개별 엔티티의 집합체이다. 본 발명의 연합 환경은 두 기업이 사용자에 대한 정보의 전송 방식 및 대상을 정의하는 직접적이고 미리 설정된 관계를 가질 필요가 없다는 점에서 종래 단일 서명 환경과는 상이하다. 연합 환경 내의 엔티티는 사용자를 인증하는 것, 다른 엔티티에 의해 제공되는 인증 주장(예를 들면, 인증 토큰)을 수용하는 것, 및 보증 사용자의 아이덴티티를 로컬 엔티티에서 이해되는 것으로 번역하는 일부 번역 형태를 제공하는 것 등을 다루는 서비스를 제공한다.

연합은 서비스 제공자측의 관리 부담을 경감시킨다. 서비스 제공자는 전체적으로 연합에 대한 신뢰 관계를 의존할 수 있다. 즉, 서비스 제공자는 사용자 인 증 홈 도메인에 의해 달성된 인증을 의존할 수 있기 때문에 사용자 패스워드 정보와 같은 인증 정보를 관리할 필요가 없다.

또한, 본 발명은 약하게 결합된 인증, 사용자 등록, 사용자 프로필 관리 및/또는 인증 서버가 보안 도메인들에 걸쳐 협력하는 기초를 확립하는 연합 아이덴티티 관리 시스템에도 관련되어 있다. 연합 아이덴티티 관리는 부동등 보안 도메인들에 상주하는 서비스들이 이들 부동등 도메인들의 운영 시스템 플랫폼 및 기초 보안 메커니즘이 상이하더라도 안전하게 연동 및 협력할 수 있게 한다. 사용자가 연합 참여를 확립하면 단일 서명 경험이 확립된다.

홈 도메인, 발의 당사자, 및 의존 당사자

보다 상세히 후술하는 바와 같이, 본 발명은 중요한 사용자 이익을 제공한다. 본 발명은 사용자가 제1 엔티티에 인증할 수 있게 하며, 이하에서는 이 제1 엔티티를 사용자 홈 도메인 또는 인증 홈 도메인이라고도 부른다. 이러한 제1 엔티티는 발의 당사자로서 동작할 수 있으며, 이 발의 당사자는 제2 엔티티의 사용을 위해 사용자에 대한 인증 주장을 발의한다. 사용자는 그 후 의존 당사자로 불리는 제2 개별 엔티티의 보호 자원을 제2 엔티티에서 명시적으로 재인증할 필요없이 제1 엔티티에 의해 발의된 인증 주장을 제공함으로써 액세스할 수 있다. 발의 당사자로부터 의존 당사자에게 전달되는 정보는 주장의 형태이며, 이러한 주장은 문장(statement) 형태의 상이한 유형의 정보를 포함할 수 있다. 예를 들면, 주장은 사용자의 인증된 아이덴티티에 대한 문장일 수도 있고, 특정 사용자에 관련된 사용자 속성 정보에 관한 문장일 수도 있다.

이제 도 2a를 참조하면, 사용자가 제1 연합 기업에 대하여 개시하고, 이에 응답하여 연합 환경 내의 다운스트림 엔티티에서 동작을 야기시키는 트랜잭션에 관한 연합 환경의 용어를 나타내는 블록도가 도시되어 있다. 도 2a는 용어가 주어진 연합 동작에 대해 연합 내의 엔티티의 관점에 따라 상이할 수 있다는 것을 보여준다. 사용자(202)는 기업(204)의 보호 자원을 요청함으로써 트랜잭션을 개시한다. 그 후, 사용자(202)가 기업(204)에 의해 인증되었다면, 기업(204)은 이 연합 세션에 대한 사용자 홈 도메인이 된다. 트랜잭션이 기업(206)에 의한 일부 유형의 동작을 요구하고 기업(204)은 기업(204)에 주장을 전송한다고 가정하면, 기업(204)은 그 특정 동작에 대한 발의 도메인이 되고, 기업(206)은 그 동작에 대한 의존 도메인이 된다. 트랜잭션이 추가 동작을 요구하고 기업(206)이 어떤 주장을 기업(208)에 전송한다고 가정하면, 기업(206)은 그 요청 동작에 대한 발의 도메인이 되고, 기업(208)은 그 동작에 대한 의존 도메인이 된다.

본 발명의 연합 환경에서는 사용자가 인증하는 도메인이 사용자의 (인증)홈 도메인이다. 홈 도메인은 인증 자격증명 기능을 유지한다. 홈 도메인은 사용자의 고용주, 사용자의 ISP, 또는 다른 서비스 제공자일 수 있다. 사용자의 인증 자격증명을 생성 및 확인할 수 있는 능력을 갖는 기업이 다수 있을 수 있기 때문에 사용자 홈 도메인으로서 동작할 수 있는 연합 환경 내의 기업이 다수 있을 수 있다는 것이 가능하다.

인증의 관점에서 보면, 인증 주장의 발의 당사자는 통상, 사용자의 인증 홈 도메인이 된다. 사용자의 홈 도메인은 사용자에 대한 개인 정보 또는 프로필 정보 일 수도 있고 아닐 수도 있다. 따라서, 개인적으로 식별가능한 정보, 개인화 정보, 또는 다른 사용자 속성을 포함하는 속성의 관점에서 보면, 속성 주장의 발의 당사자는 사용자 인증 홈 도메인일 수도 있고 아닐 수도 있다. 혼동을 방지하기 위해서, 속성 홈 도메인과 인증 홈 도메인에 대하여 개별 용어가 사용될 수 있지만, "홈 도메인"이라는 용어는 이하 인증 홈 도메인을 가리키는 것으로서 해석될 수 있다.

그러나, 주어진 연합 세션의 범위 내에서는 사용자의 홈 도메인으로서 동작하는 도메인이 통상 하나 뿐이다. 사용자가 이 도메인에 인증한 경우에, 연합 내의 다른 모든 도메인 또는 기업은 이 세션 동안 의존 당사자로서 취급된다.

본 발명이, 기존 시스템에 추가될 수 있으면서 기존의 비연합 아키텍처에 대한 영향을 최소화하는 연합 기반구조를 제공하는 경우, 사용자 홈 도메인의 인증은 그 홈 도메인이 연합 환경에 동참할 수 있다는 사실에 의해 변경되지 않는다. 다시 말하면, 홈 도메인이 본 발명에 따라 구현되는 연합 환경에 통합될 수 있는 경우에도, 사용자는 사용자 홈 도메인에서 인증 동작을 수행하는 동안에는 동일한 최종 사용자 경험을 하여야 한다. 그러나, 주어진 기업의 사용자 모두가 반드시 연합 환경에 동참해야 하는 것은 아님을 인식하여야 한다.

더욱이, 사용자 등록, 예를 들면, 사용자 계정의 설정은 홈 도메인이 연합 환경에 동참할 수 있다는 사실에 의해 변경되지 않는다. 사용자는 연합 환경과는 별개인 등록 프로세스를 통해 도메인에 계좌를 설정한다. 즉, 홈 도메인에 사용자 계좌를 설정하는 것은 연합 전반에 걸쳐 유효한 계좌 정보, 예를 들면, 아이덴티티 번역 정보를 설정하는 것을 포함하지 않는다. 사용자를 인증할 수 있는 연합 도메인이 1개인 경우, 즉, 연합 내에서 사용자가 등록한 도메인이 1개뿐인 경우, 이 도메인은 항상 사용자의 홈 도메인으로서 동작할 것이고, 연합 환경 전반에 걸쳐 사용자 움직임을 지시할 수 있다.

사용자가 연합 환경 내에서 다수의 가능한 홈 도메인을 갖는 경우, 사용자는 하나 이상의 엔트리 포인트를 통해 연합에 진입할 수 있다. 즉, 사용자는 다수의 도메인에서 계좌를 가질 수 있으며, 이들 도메인은 다른 도메인에 대한 정보 또는 그 다른 도메인의 사용자 아이덴티티에 대한 정보를 반드시 가질 필요는 없다.

사용자가 인증한 도메인을 홈 도메인이라고 부르지만, 발의 도메인은 다른 도메인, 즉, 의존 도메인에 의한 사용을 위해 주장을 발의하는 연합 엔티티이다. 발의 도메인은 통상, 사용자 홈 도메인이지만 반드시 그러할 필요는 없다. 따라서, 발의 당사자는 상술한 바와 같이 대표적인 인증 프로토콜을 통해 사용자를 인증한 경우가 일반적인 것이다. 그러나, 발의 당사자가 이전에 의존 당사자로서 동작했고, 이것에 의해서 상이한 발의 당사자로부터의 주장을 수신한 것이 가능하다. 다시 말하면, 사용자 개시 트랜잭션은 연합 환경 내의 일련의 기업을 통해 종속 연결될 수 있기 때문에, 수신 당사자는 다운스트림 트랜잭션에 대한 발의 당사자로서 후속하여 동작할 수 있다. 통상, 사용자를 대신하여 인증 주장을 발의할 수 있는 능력을 보유한 도메인은 발의 도메인으로서 동작할 수 있다.

의존 도메인은 발의 당사자로부터의 주장을 수신하는 도메인이다. 의존 당사자는 사용자를 대신하는 제3자, 즉, 발의 도메인에 의해 발의되는 주장을 수용, 신뢰 및 이해할 수 있다. 통상, 적절한 인증 기관을 사용하여 인증 주장을 해석하는 것은 통상, 의존 당사자의 의무이다. 또한, 의존 당사자가 특정 사용자를 인증하는 것, 즉, 사용자의 홈 도메인으로서 동작하는 것을 가능하게 할 수도 있지만, 의존 당사자가 종래 방법을 통해 특정 사용자를 인증하는 것을못하게 할 수도 있다. 따라서, 의존 당사자는, 사용자와의 상호동작 세션의 일부로서 사용자의 인증 자격증명을 사용자에게 요구하는 대신에, 사용자에게 단일 서명 기능을 제공하고, 사용자가 제공하는 인증 주장에 의존하는 도메인 또는 기업이다.

연합 아키텍처- 레거시 시스템에 대한 연합 프런트 엔드

이제 도 2b를 참조하면, 본 발명의 일 실시예에 따라 본 발명의 연합 아키텍처 컴포넌트의 일부를 구비한 주어진 도메인에서의 기존 시스템의 통합을 나타내는 블록도가 도시되어 있다. 연합 환경은 사용자에게 다양한 서비스를 제공하는 연합 엔티티를 포함한다. 사용자(212)는 클라이언트 장치(214)와 상호동작하며, 이러한 클라이언트 장치(214)는 브라우저 애플리케이션(216)과 다양한 다른 클라이언트 애플리케이션(218)을 지원할 수 있다. 사용자(212)는 클라이언트 장치(214), 브라우저(216), 또는 사용자와 다른 장치 및 서비스 간의 인터페이스로서 동작하는 임의의 다른 소프트웨어와는 별개의 것이다. 일부의 경우에는, 후술하는 설명에 의해서, 클라이언트 애플리케이션 내에 명시적으로 동작하는 사용자와 그 사용자에 대신하여 동작하는 클라이언트 애플리케이션 간의 구별이 가능하다. 그러나, 요청자는 통상 사용자를 대신하여 동작하는 것으로 가정될 수 있는 클라이언트 기반 애플리케이션, 브라우저, SOAP 클라이언트 등과 같은 중개인이다.

브라우저 애플리케이션(216)은 HTTP 통신 컴포넌트(220)와 마크업 언어(ML) 인터프리터(222)와 같은 다수의 모듈을 포함하는 통상의 브라우저일 수 있다. 또한, 브라우저 애플리케이션(216)은 가상 머신 런타임 환경을 요구할 수도 있고 요구하지 않을 수도 있는 다운로드가능 애플릿 및/또는 웹 서비스 클라이언트(224)와 같은 플러그 인을 지원할 수 있다. 웹 서비스 클라이언트(224)는 단순 객체 액세스 프로토콜(SOAP)을 사용할 수 있으며, SOAP는 탈중심화의 분산 환경에서 구조화되고 유형화된 정보의 교환을 규정하는 경량 프로토콜이다. SOAP는 다음의 3부분으로 이루어진 XML 기반 프로토콜이다. 즉, 첫째 부분은 메시지 내에 무엇이 있고 이를 어떻게 처리하는지를 나타내는 프레임워크를 규정하는 엔벨로프이고, 둘째 부분은 애플리케이션 정의 데이터 타입의 인스턴스를 표현하는 인코딩 규칙 세트이며, 셋째 부분은 원격 절차 호출 및 응답을 나타내는 규약이다. 사용자(212)는 브라우저 애플리케이션(216)을 사용하여 웹 기반 서비스에 액세스할 수 있지만, 클라이언트 장치(214) 상의 다른 웹 서비스 클라이언트를 통해 웹 서비스에 액세스할 수도 있다. 다음의 도면들에 나타낸 본 발명의 일부 예는 사용자의 브라우저를 통한 HTTP 방향변경(redirection)을 이용하여 연합 환경 내의 엔티티들간의 정보를 교환한다. 그러나, 본 발명은 다양한 통신 프로토콜을 통해서 행해질 수 있으며 HTTP 기반 통신에 한정되는 것을 의미하는 것이 아님을 인식하여야 한다. 예를 들면, 연합 환경 내의 엔티티들은 필요시 직접 통신할 수 있다. 즉, 메시지는 사용자의 브라우저를 통해 방향변경될 필요가 없다.

본 발명은 연합 환경에 필요한 컴포넌트들이 기존 시스템과 통합될 수 있도 록 구현되어도 좋다. 도 2b는 이들 컴포넌트를 기존 시스템에 대한 프런트 엔드로서 구현하는 일 실시예를 나타낸다. 연합 도메인에서 기존 컴포넌트는, 도 2c에 도시한 바와 유사한 방식으로 인증 서비스 런타임(ASR) 서버(232)를 포함하는 레거시 애플리케이션 또는 백엔드 처리 컴포넌트(230)인 것으로 고려될 수 있다. ASR 서버(232)는 보호 자원을 생성, 검색 또는 다르게는 처리하도록 고려될 수 있는, 애플리케이션 서버(234)에의 액세스를 도메인이 제어하는 경우에 사용자 인증을 담당한다. 도메인은 계속해서 레거시 사용자 등록 애플리케이션(236)을 사용하여 애플리케이션 서버(234)에의 액세스를 위해 사용자를 등록할 수 있다. 등록 사용자를 인정하는데 필요한 정보는 레거시 사용자 레지스트리(238)에 저장된다.

연합 환경에 참여한 후에, 도메인은 연합 컴포넌트의 개입 없이 계속 동작할 수 있다. 다시 말하면, 도메인은 사용자가 접점 서버 또는 이러한 접점 서버 기능을 구현하는 다른 컴포넌트를 직접 통하지 않고서도 특정 애플리케이션 서버 또는 다른 보호 자원에 계속 액세스할 수 있도록 구성될 수 있다. 즉, 이러한 방식으로 시스템에 액세스하는 사용자는 통상의 인증 흐름과 통상의 액세스를 경험하게 될 것이다. 그러나, 이를 행함으로써, 레거시 시스템에 직접 액세스하는 사용자는 도메인의 접점 서버에게 알려진 연합 세션을 성립시킬 수는 없을 것이다.

도메인의 레거시 기능은 연합 프런트 엔드 처리부(240)를 사용함으로써 연합 환경에 통합될 수 있고, 연합 프런트 엔드 처리부(240)는 접점 서버(242)와, 보안 토큰 서비스(STS; 245)를 포함하는 신뢰 프록시 서버(244)[또는 신뢰 프록시(244)라고 약칭함]를 포함하며, 이들 모두에 대하여는 도 2c에서 상세히 후술한다. 연 합 구성 애플리케이션(246)은 관리 사용자로 하여금 연합 프런트 엔드 컴포넌트를 구성할 수 있게 하여, 이들 연합 프런트 엔드 컴포넌트들이 연합 인터페이스 유닛(248)을 통해 레거시 백엔드 컴포넌트와 인터페이스할 수 있게 한다.

주어진 기업에서의 레거시 또는 기존 인증 서비스는 사용자명/패스워드 또는 스마트카드 토큰 기반 정보와 같은 다양하고 공지된 인증 방법 또는 토큰을 사용할 수 있다. 그러나, 본 발명에서는, 레거시 인증 서비스의 기능은 접점 서버를 사용함으로써 연합 환경에서 사용될 수 있다. 이러한 방식으로 시스템에 액세스하는 사용자가 통상의 인증 흐름 및 통상의 액세스를 경험하더라도, 사용자는 접점 서버를 직접 통하지 않고서도 레거시 인증 서버에 계속 액세스할 수 있으며, 레거시 인증 시스템에 직접 액세스하는 사용자는 본 발명에 따른 아이덴티티의 증거로서 연합 인증 주장을 생성할 수 없을 것이다. 연합 프런트 엔드의 규칙 중 하나는 레거시 인증 서비스에 의해 이해되는 포맷으로 접점 서버에서 수신된 연합 인증 토큰을 변역하는 것이다. 따라서, 접점 서버를 통해 연합 환경에 액세스하는 사용자는 반드시 레거시 인증 서비스에 대하여 재인증할 필요는 없을 것이다. 바람직하게는, 사용자는 마치 사용자가 인증 대화에 참여한 것과 같이 나타나도록 접점 서버와 신뢰 프록시의 조합에 의해 레거시 인증 서비스에 대하여 인증될 수 있다.

연합 아키텍처 - 접점 서버, 신뢰 프록시, 및 신뢰 중재자

이제 도 2c를 참조하면, 본 발명의 일 구현예에 따른 연합 아키텍처를 나타내는 블록도가 도시되어 있다. 연합 환경은 사용자에게 다양한 서비스를 제공하는 연합 기업 또는 유사한 엔티티를 포함한다. 클라이언트 장치의 애플리케이션을 통 해 사용자는 기업(250)과 같이 다양한 엔티티에서 자원 액세스를 시도할 수 있다. 기업(250)의 접점(POC) 서버(252)와 같이, 각각의 연합 기업의 접점 서버는 연합 환경으로의 사용자 진입 포인트이다. 접점 서버가 다수의 연합 요건을 처리하기 때문에, 접점 서버는 기존의 비연합 아키텍처 내의 기존 컴포넌트, 예를 들면, 레거시 시스템에 대한 영향을 최소화시킨다. 접점 서버는 세션 관리, 프로토콜 변환을 제공하고, 가능하게는 인증 주장 변환을 개시한다. 예를 들면, 접점 서버는 HTTP 또는 HTTPS 메시지를 SOAP으로 번역할 수도 있고 그의 역으로 번역할 수도 있다. 보다 상세히 후술하는 바와 같이, 접점 서버는 인증 주장을 번역하는 신뢰 프록시를 호출하는데에도 사용될 수 있다. 예를 들면, 발의 당사자로부터 수신된 SAML 토큰은 수신 당사자에 의해 이해되는 커베로스 토큰으로 번역될 수 있다.

기업(250)의 신뢰 프록시(TP)(254)와 같은 신뢰 프록시 또는 신뢰 프록시 서버는 하나의 연합체 내의 두 엔티티 간의 신뢰 관계를 성립시키고 유지한다. 통상, 신뢰 프록시는 발의 당사자에 의해 사용되는 포맷으로부터 수신 당사자에 의해 이해되는 것으로 인증 토큰 포맷 번역을 (보다 상세히 후술되는 보안 토큰 서비스를 통해) 처리하는 능력을 갖는다.

또한, 접점 서버와 신뢰 프록시를 함께 사용하면 기존의 비연합 시스템 집합에 관하여 연합 아키텍처를 구현하는 것에 따른 영향이 최소화된다. 따라서, 본 발명의 연합 아키텍처는 엔티티가 기업, 도메인 또는 다른 논리적 또는 물리적 엔티티에 관계없이 연합 엔티티당 적어도 하나의 접점 서버와 적어도 하나의 신뢰 프록시를 요구한다. 그러나, 본 발명의 연합 아키텍처는 기존의 비연합 시스템 집합 으로의 임의의 변경을 반드시 요구하는 것은 아니다. 바람직하게는, 주어진 연합 엔티티에 대한 신뢰 프록시는 1개이지만, 다수의 이용 목적에 맞도록 다수의 신뢰 프록시가 있어도 좋고, 연합 엔티티 내의 다양한 보다 작은 엔티티, 예를 들면, 하나의 기업 내의 개별 자회사들에 맞도록 다수의 신뢰 프록시가 있어도 좋다. 이러한 시나리오는 단일의 신뢰 프록시로도 다수의 연합체 내의 신뢰 관계들을 관리할 수 있기 때문에 신뢰 프록시가 반드시 다수이어야 할 필요는 없지만, 주어진 하나의 엔티티가 하나 이상의 연합체에 속할 수 있는 가능성은 있다.

신뢰 프록시의 역할 중 하나는 다른 도메인 및/또는 그 도메인의 신뢰 프록시에 의해 요구되는 토큰의 유형을 결정하는 것이다. 신뢰 프록시는 발의 당사자가 사용하는 포맷으로부터 수신 당사자가 이해하는 포맷으로 인증 토큰 포맷 번역을 처리할 수 있는 기능을 갖는다. 또한, 신뢰 프록시(254)는 기업(250)에 대하여 발생하는 임의의 사용자 아이덴티티 번역 또는 속성 번역을 담당한다. 그러나, 신뢰 프록시는 후술하는 바와 같이 지원하는 신뢰 중재자를 호출할 수 있다. 아이덴티티 번역은 발의 당사자가 알고 있는 사용자의 아이덴티티와 속성을 수신 당사자에게 의미있는 것에 매핑하도록 요구될 수 있다. 이러한 번역은 발의 도메인의 신뢰 프록시에 의해 호출될 수도 있고, 수신 도메인의 신뢰 프록시에 의해 호출될 수도 있다.

신뢰 프록시(254)는, 토큰 번역 기능을 제공하고 인증 서비스 런타임(ASR; 256)을 호출하여 토큰을 확인 및 생성하는 보안 토큰 서비스(STS) 컴포넌트(255)와 같은 내부화된 컴포넌트를 포함할 수 있다. 보안 토큰 서비스는 신뢰 프록시에 의 해 요구되는 토큰 발행과 확인 서비스를 제공한다. 따라서, 보안 토큰 서비스는 기존 인증 서비스 런타임 컴포넌트에 대한 인터페이스를 포함하거나, 인증 서비스 런타임 컴포넌트를 서비스 자체에 내장한다. 신뢰 프록시 내에 내부화하는 대신, 보안 토큰 서비스 컴포넌트는 또한, 예를 들면, 신뢰 프록시에 의해 호출되는 단독 컴포넌트로서 구현될 수 있으며, 예를 들면, 애플리케이션 서버의 일부로서 트랜잭션 서버 내에 내부화될 수 있다.

예를 들면, STS 컴포넌트는 커베로스 토큰의 발행(발의) 요청을 수신할 수 있다. 토큰이 생성될 사용자의 인증 정보의 일부로서, 이 요청은 사용자명과 패스워드를 포함하는 바이너리 토큰을 포함할 수 있다. STS 컴포넌트는 예를 들면 LDAP 런타임(통상 인증)에 대하여 사용자명과 패스워드를 확인하고, 또 커베로스 KDC(주요 분산 센터)를 호출하여 이 사용자에 대한 커베로스 티켓을 생성할 것이다. 이 토큰은 기업 내의 사용을 위해 신뢰 프록시에 리턴되지만, 이러한 사용은 연합체 내의 다른 도메인으로의 전송을 위한 토큰 외부화(externalizing)를 포함할 수 있다.

도 1d에 대하여 설명한 것과 유사한 방식으로, 사용자는 기업(250) 및 기업(260)과 같이 연합 환경 내의 다수의 기업의 자원에 액세스하려 할 수 있다. 기업(250)에 대하여 상술한 바와 유사한 방식으로, 기업(260)은 접점 서버(262), 신뢰 프록시(264), 보안 토큰 서비스(265), 및 인증 서비스 런타임(266)을 포함한다. 사용자는 각 기업과 개별 트랜잭션을 직접 개시할 수 있지만, 사용자는 연합 환경을 통해 중첩하는 기업(250)과의 트랜잭션을 개시하여도 좋다. 기업(250)은 연합 환경 내의 다수의 다른 기업, 예컨대 기업(260)과의 협력을 요구하여 특정 트랜잭션을 완료할 수 있지만, 사용자는 트랜잭션을 개시한 때에 이러한 필수 사항을 인식하지 못하였을 수도 있다. 기업(260)은 다운스트림 도메인으로서 포함되어지게 되므로, 본 발명은 기업(250)이 필요시 사용자의 트랜잭션을 촉진할 수 있도록 연합화된 주장(또는 연합 주장)을 기업(260)에 제공할 수 있게 한다.

신뢰 프록시는 관련 접점 서버에 의해 수신되는 인증 토큰의 해석 방식 및/또는 주어진 사용자 아이덴티티 및 속성을 번역하는 방식을 인식하지 않을 수 있다. 이러한 경우, 신뢰 프록시는 신뢰 중재자(268)와 같은 신뢰 중재자 컴포넌트에서 기능 호출을 선택할 수 있다. 신뢰 중재자는 개별 신뢰 프록시와의 관계를 유지함으로써, 신뢰 프록시 간의 이행성 신뢰(transitive trust)를 제공한다. 신뢰 중재자의 사용은, 연합 환경에서 각 도메인과의 다수의 개별 신뢰 관계를 설정하는 대신, 기업(250 및 260)과 같은 연합 환경 내의 각 엔티티가 신뢰 중재자와의 신뢰 관계를 성립할 수 있게 한다. 예를 들면, 기업(260)은 기업(250)에서 사용자에 의해 개시되는 트랜잭션에 대한 다운스트림 도메인으로서 호출되는 경우, 기업(250)에서 신뢰 프록시(254)는 기업(260)에서의 신뢰 프록시(264)가 필요시 신뢰 중재자(268)의 지원을 호출하여 신뢰 프록시(254)로부터의 주장을 이해할 수 있다. 도 2c는 단일 신뢰 중재자를 갖는 연합 환경을 나타내고 있지만, 연합 환경은 다수의 신뢰 중재자를 가져도 좋다.

도 2c는 접점 서버(252), 신뢰 프록시(254), 보안 토큰 서비스 컴포넌트(255), 및 인증 서비스 런타임(256)을 고유 엔티티로서 나타내고 있지만, 이들 컴 포넌트가 개별 장치로서 구현되어야 하는 것은 아니라는 것이 인식되어야 한다. 예를 들면, 이들 개별 컴포넌트의 기능은 단일 물리 장치에서 다수의 애플리케이션으로서 구현될 수도 있고 단일 애플리케이션으로 조합될 수도 있다. 또한, 도 2c는 하나의 기업에 대하여 단일 접점 서버, 단일 신뢰 프록시 및 단일 보안 토큰 서버를 나타내고 있지만, 다른 구성은 다수의 기업에 대하여 다수의 접점 서버, 다수의 신뢰 프록시 및 다수의 보안 토큰 서버를 포함하여도 좋다. 접점 서버, 신뢰 프록시, 신뢰 토큰 서비스 및 다른 연합 엔티티는 소프트웨어 애플리케이션, 객체, 모듈, 소프트웨어 라이브러리 등과 같은 다수의 형태로 구현될 수 있다.

신뢰 프록시/STS는 사용자명과 패스워드 조합과 같은 종래의 자격증명, 커베로스 티켓, 및 제3자에 의해 생성된 애플리케이션 토큰 등의 연합 자격증명 토큰 포맷 등의 많은 상이한 인증 자격증명을 허용하여 확인할 수 있다. 신뢰 프록시/STS는 다른 곳의 인증의 증거로서 인증 토큰의 허용을 가능하게 할 수 있다. 인증 토큰은 발의 당사자에 의해 생성되어 사용자가 이미 발의 당사자에게 인증되었음을 나타내도록 사용된다. 발의 당사자는 사용자의 인증된 아이덴티티를 주장하는 수단으로서 인증 토큰을 생성한다.

보안 토큰 서비스는 필요시 인증 서비스 런타임을 호출한다. 인증 서비스 런타임은 사용자를 인증할 수 있는 인증 서비스를 지원한다. 인증 서비스는 인증 응답을 통해 성공 또는 실패한 인증 시도의 표시를 제공하는 인증 기관으로서 동작한다. 신뢰 프록시/STS는 인증 서비스, 예를 들면, 기존 레거시 기반구조와 상호동작할 필요가 없는 웹 서비스의 새로운 설치가 있는 시나리오를 내부화할 수 있 다. 다르게는, STS 컴포넌트는 인증 토큰의 확인을 위해 외부 인증 서비스를 호출할 수 있다. 예를 들면, STS 컴포넌트는 사용자명/패스워드를 포함하는 바이너리 토큰을 "언팩(unpack)"하여 그 후 LDAP 서비스를 사용하여 사용자 레지스트리에 액세스하고 제공된 자격증명을 확인한다.

애플리케이션 서버와 같은 다른 컴포넌트에 의해 사용되는 경우, STS 컴포넌트는 레거시 인증 시스템에 대한 단일 서명에 필요한 토큰을 생성하는데 사용될 수 있다. 따라서, STS 컴포넌트는 내부 목적으로, 즉 기업 내에서, 그리고 외부 목적으로, 즉, 연합 기업에 걸쳐 토큰 번역을 위해 사용될 수 있다. 내부 목적의 일 예로서, 웹 애플리케이션 서버는 IBM CICS(고객 정보 제어 시스템) 트랜잭션 게이트웨이를 통해 메인프레임에 인터페이스할 수 있으며; CICS는 기업 수준의 온라인 트랜잭션 관리 및 미션 위주의 애플리케이션을 제공하는 애플리케이션 서버 및 커넥터의 패밀리이다. 웹 애플리케이션 서버는 STS 컴포넌트를 호출하여 커베로스 티켓(웹 애플리케이션 서버에 의해 내부 사용되는 바와 같이)을 CICS 트랜잭션 게이트웨이에 의해 필요한 IBM RACF

패스티켓으로 번역할 수 있다.

도 2c에 도시한 엔티티는 상술한 용어, 예를 들면, "발의 당사자"와 "의존 당사자"를 사용하여 설명될 수 있다. 신뢰 관계를 설정 및 유지하는 일부로서, 발의 당사자의 신뢰 프록시는 어느 토큰 유형이 의존 당사자의 신뢰 프록시에 의해 필요/허용되는지를 결정할 수 있다. 따라서, 신뢰 프록시는 보안 토큰 서비스로부터의 토큰 서비스를 언제 호출할 때 이 정보를 사용한다. 발의 도메인의 신뢰 프록시가 의존 당사자에 대한 인증 주장을 생성할 필요가 있는 경우, 신뢰 프록시는 필요한 토큰 유형을 결정하고 보안 토큰 서비스로부터 적절한 토큰을 요청한다.

의존 도메인의 신뢰 프록시가 발의 당사자로부터 인증 주장을 수신하는 경우, 신뢰 프록시는 예측된 주장 유형이 무엇인지 그리고 의존 도메인 내의 내부 사용에 필요한 유형이 무엇인지를 인식한다. 따라서, 의존 도메인의 신뢰 프록시는 보안 토큰 서비스가 수신된 인증 주장의 토큰에 따라 필요한 내부 사용 토큰을 생성하도록 요청한다.

신뢰 프록시와 신뢰 중재자는 모두 의존 당사자에 의해 이해되는 포맷으로 발의 당사자로부터 수신된 주장을 번역할 능력을 가진다. 신뢰 중재자는 직접 신뢰 관계가 있는 신뢰 프록시 각각에 대하여 주장 포맷(포맷들)을 해석을 능력을 가지기 때문에, 신뢰 중재자가 발의 당사자와 의존 당사자 간의 주장 번역을 제공할 수 있게 한다. 이러한 번역은 로컬 신뢰 프록시를 통해 어느 한 당사자에 의해 요청될 수 있다. 따라서, 발의 당사자의 신뢰 프록시는 의존 당사자에 전송되기 전에 주장의 번역을 요청할 수 있다. 유사하게, 의존 당사자의 신뢰 프록시는 발의 당사자로부터 수신된 주장의 번역을 요청할 수 있다.

주장 번역은 사용자 엔티티 번역, 인증 주장 번역, 속성 주장 번역 또는 다른 형태의 주장 번역을 포함한다. 상술한 포인트를 반복하여, 주장 번역은 연합 내의 신뢰 컴포넌트, 즉, 신뢰 프록시와 신뢰 중재자에 의해 처리된다. 신뢰 프록시는 발의 도메인 또는 의존 도메인에서 국부적으로 번역을 수행할 수 있으며, 또는 신뢰 프록시는 신뢰 중재자로부터 지원을 호출할 수 있다.

발의 당사자와 신뢰 당사자가 이미 신뢰 중재자와의 개별 신뢰 관계를 갖는 다고 가정하면, 신뢰 중재자는 동적으로 중재자, 즉, 필요시 발의 당사자와 의존 당사자 간의 새로운 신뢰 관계를 동적으로 생성한다. 신뢰 중재자에 의해 제공되는 초기 신뢰 관계 중재 동작 후에, 발의 당사자와 의존 당사자는 관계를 직접 유지할 수 있기 때문에, 신뢰 중재자는 추후 번역 요건에 호출될 필요는 없다. 인증 토큰의 번역은 3개의 가능한 장소: 발의 당사자의 신뢰 프록시, 의존 당사자의 신뢰 프록시, 및 신뢰 중재자에서 발생할 수 있음이 이해되어야 한다. 바람직하게는, 발의 당사자의 신뢰 프록시는 신뢰 중재자에 의해 이해되는 인증 주장을 생성하여 의존 당사자에게 전송한다. 그 후, 의존 당사자는 이러한 신뢰 중재자로부터 의존 당사자에 의해 인식가능한 포맷으로의 토큰의 번역을 요청한다. 토큰 번역은 전송 전에, 전송 후에, 또는 인증 주장의 번역 전후에 발생할 수 있다.

연합 아키텍처 내의 신뢰 관계

본 발명에 따라 구현되는 연합 환경 내에서, 관리되어야할 두가지 유형의 "신뢰 도메인"이 있다: 기업 신뢰 도메인 및 연합 신뢰 도메인. 이들 두 신뢰 도메인 유형 간의 차이는 신뢰 도메인과의 신뢰 관계와 신뢰를 설정하는데 사용되는 기술에 대한 사업 협정에 일부 기초한다. 기업 신뢰 도메인은 기업에 의해 관리되는 이들 컴포넌트를 포함한다: 신뢰 도메인 내의 모든 컴포넌트는 서로 신뢰한다. 통상, 구성 기술은 예를 들면 컴포넌트 간의 상호 인증된 SSL 세션을 요구함으로써 기업 내의 내재 신뢰를 생성하기 때문에 기업 내의 신뢰를 설정하는데 필요한 사업 협정이 없다. 도 2b를 참조하면, 레거시 애플리케이션 및 백엔드 프로세싱 시스템은 기업 신뢰 도메인을 나타낼 수 있다.

연합 신뢰 도메인은 기업 경계를 가로지르는 것으로서, 하나의 관점에서, 연합 신뢰 도메인은 고유 기업 신뢰 도메인 간의 신뢰 관계를 나타낼 수 있다. 연합 신뢰 도메인은 기업 경계에 걸쳐 신뢰 프록시를 통해 설정된다. 연합 신뢰 관계는 초기 신뢰가 신뢰 프록시 사이에 설정되는 일부 부트스트랩 프로세스 유형을 포함한다. 이러한 부트스트랩 프로세스의 일부는 예측 및/또는 허용된 토큰 유형 및 식별자 번역을 한정하는 공유 비밀 키 및 규칙의 설정을 포함할 수 있다. 통상, 이러한 부트스트랩 프로세스는 이 프로세스가 연합 내의 기업 참가와 참여에 관련된 의무를 관리하는 사업 협정의 설정을 또한 포함하기 때문에 외대역으로서 구현된다.

연합 사업 모델 내에 신뢰를 설정하는 다수의 메커니즘이 있다. 연합 모델에서, 연합 참가자들 간의 신뢰의 기본 개념은 참가자들 사이에 전송된 주장(토큰 및 속성 정보를 포함)이 확인의 확신 정보를 제공하기 위해서 사업상의 이유로 필요하다. 어떤 신뢰 관계도 없는 경우, 의존 도메인은 발의 도메인으로부터 수신된 주장에 의존하지 않을 수 있으며, 발의 당사자로부터 수신된 임의의 정보를 해석하는 방식을 결정하기 위해 의존 도메인에 의해 사용될 수는 없다.

예를 들면, 큰 기업은 다수의 글로벌 고객을 연결하기를 원할 수 있으며, 이 기업은 종래 기술의 솔루션을 사용할 수 있다. 제1 예로서, 이 기업은 글로벌 고유이 상용 인증 기관으로부터의 디지털 인증서를 사용하여 상호 신뢰를 설정하기를 요청할 수 있다. 상용 신뢰 기관은 기업에서 서버가 글로벌 고객 각각에 위치한 서버를 신뢰할 수 있게 한다. 제2 예로서, 기업은 커베로스를 사용하는 제3 자 신 뢰를 구현할 수 있다; 기업과 이의 글로벌 고객은 공유 비밀 기반 신뢰를 구현하는 신뢰 제3 자 커베로스 도메인 서비스를 구현할 수 있다. 제3 예로서, 기업은 이의 글로벌 고객의 서버에 의해 상호 신뢰되는 전용 보안 메시지 토큰을 사용하여 사설 방식을 설정할 수 있다.

이들 접근법 중 임의의 하나는 기업이 보다 작은 수의 글로벌 고개고가의 신뢰 관계를 관리할 필요가 있으면 허용될 수 있지만, 수백 또는 수천의 가능한 연합 파트너가 있는 경우에는 관리가능하게 되지 않을 수 있다. 예를 들면, 기업이 보다 적은 파트너가 사설 방식을 구현하게 할 수는 있지만, 기업이 많은 파트너에 대한 많은 요건을 부과할 수 있을 것 같지는 않다.

본 발명에 따라, 기업은 신뢰 프록시와 가능하게는 신뢰 중재자를 통해 설정되고 유지되는 신뢰 관계를 사용할 수 있다. 본 발명의 연합 아키텍처의 이점은 기업의 현재 기반구조와 이의 가능한 연합 파트너 이상의 추가 요건을 부과하지 않는다는 점이다.

그러나, 본 발명은 사업을 확립하는데 필요한 예비 작업과 연합의 참가에 필요한 의무 협정으로부터 기업과 이의 가능한 연합 파트너를 경감하지는 않는다. 또한, 참가자는 신뢰 관계의 기술적 부트스트램을 무시할 수 없다. 본 발명은 부트스트랩이 플렉서블할 수 있게 하고, 예를 들면, 제1 연합 파트너는 특정 정보를 갖는 커베로스 티켓을 발행할 수 있지만, 제2 연합 파트너는 특정 정보를 갖는 SAML 인증 주장을 발행할 수 있다.

본 발명에서, 신뢰 관계는 연합 신뢰 프록시에 의해 관리되며, 이는 두 신뢰 프록시 간의 미리 설정된 관계에 기초하여 발의 당사자로부터 수신된 토큰을 확인 및 번역하는 보안 토큰 서비스를 포함할 수 있다. 연합 기업이 다른 연합 기업과의 신뢰 관계(및 토큰 번역)를 설정할 수 없는 경우, 신뢰 중재자가 호출될 수 있다. 그러나, 연합 기업은 신뢰 중재자와의 관계를 여전히 설정하여야 한다.

이제 도 2d를 참조하면, 본 발명에 따른 신뢰 프록시와 신뢰 중재자를 사용하여 연합 도메인 간의 신뢰 관계의 예시적인 집합을 도시하는 블록도가 도시되어 있다. 도 2c는 신뢰 중재자를 도입하지만, 도 2d는 본 발명의 연합 아키텍처 내의 이행성 신뢰(transitive trust) 관계의 중요성을 나타낸다.

연합 도메인(271 내지 273)은 신뢰 프록시(274 내지 276)를 각각 포함한다. 신뢰 프록시(274)는 신뢰 프록시(275)와 직접 신뢰 관계(277)를 갖는다. 신뢰 중재자(280)는 신뢰 프록시(275)와 직접 신뢰 관계(278)을 가지며, 신뢰 중재자(280)는 신뢰 프록시(276)와 직접 신뢰 관계(279)를 갖는다. 신뢰 중재자(280)는 연합 참가자를 대신하여, 다른 연합 파트너와의 이행성 신뢰에 기초한 신뢰 관계를 설정하는데 사용된다. 이행성 신뢰의 원리는 신뢰 프록시(275)와 신뢰 프록시(276)가 신뢰 중재자(280)를 통해 중재된 신뢰 관계(281)를 갖게 할 수 있다. 신뢰 프록시(275)와 신뢰 프록시(276)는 모두 다른 주장을 번역 또는 확인하는 방식을 인지할 필요가 없으며, 신뢰 중재자는 다른 신뢰 프록시에서 유효, 신뢰 및 이해되는 것으로 주장을 번역하도록 호출될 수 있다.

연합 기업 간의 신뢰 관계에 대한 계약 의무와 책임을 규정하는 사업 협정은 ebXML(XML을 사용하는 전자 사업)의 사용을 통해 XML에 표현될 수 있다. 예를 들 면, 직접 신뢰 관계는 ebXML 문서에 표현될 수 있으며, 직접 신뢰 관계를 고유하는 각 연합 도메인은 ebXML 문서로서 표현되는 계약 복사본을 가질 수 있다. 연합 내의 다양한 엔티티에 대한 동작 특성은 ebXML 안무(choreography) 내에 규정되고 ebXML 레지스트리 내에 발표될 수 있으며, 특정 연합 내에 참가하려 하는, 예를 들면, 신뢰 프록시 또는 신뢰 중재자를 운영하는 임의의 기업은 연합 내의 모든 신뢰 프록시 또는 신뢰 중재자에 대한 특정 연합에 의해 규정된 발표된 요건에 부응할 필요가 있다. 보안 토큰 서비스는 다른 도메인으로부터의 토큰을 번역할 필요가 있는 방식으로 동작 세부사항에 대하여 이들 ebXML 문서를 파싱할 수 있다. 그러나, 다른 표준 및 메커니즘은 연합 내의 신뢰 관계가 구현되는 방식에 대한 세부사항을 규정하기 위해 본 발명에 의해 사용될 수 있다.

연합 아키텍처 내의 주장 처리

상술한 바와 같이, 연합 내의 사용자의 경험은 도메인에 걸쳐 전송되는 사용자에 관한 또는 사용자를 위한 주장에 의해 일부 관리된다. 주장은 사용자의 인증 상태, 속성 정보 및 다른 정보에 대한 정보를 제공한다. 인증 을 사용하여, 주장은 사용자가 방문하는 모든 사이트에서 사용자가 재인증할 필요를 제거할 수 있다. 연합 환경 내에서, 발의 당사자로부터 의존 당사자로의 주장을 획득하는 두가지 모델, 즉, 푸시 모델(push model)과 풀 모델(pull model)이 있다. 푸시 모델에서, 사용자의 주장은 발의 당사자에 대한 사용자의 요청으로 이동한다. 풀 모델에서, 사용자의 요청은 임의의 정보없이 의존 당사자에서 수신되고, 그 후, 의존 당사자는 발의 당사자로부터 관련 또는 필요 주장을 요청한다.

연합 환경 내의 주장을 사용하는 이들 모델의 경우, 본 발명의 설명은 이하 본 발명의 연합 환경 내의 주장을 생성 및 사용하는 일련의 프로세스를 설명하는 일련의 도면을 나타낸다. 도 3a는 연합 환경 내의 주장을 생성하는 발의 도메인에서 일반화된 프로세스를 나타내는 반면, 도 3b는 주장을 "분할(tearing down)"하는, 즉, 이 정보를 발췌 및 분석하여 이의 기본 정보로 주장을 참조하는 의존 도메인에서 일반화된 프로세스를 나타낸다. 도 3c 및 도 3d는 주장이 발의 도메인 내에서 생성된 후 사용자의 요청에 따라 의존 도메인에 전달되는 푸시 모델의 두 변형을 도시함으로써 도 3a에 도시한 일반화된 프로세스에 대한 보다 상세한 프로세스를 나타낸다. 도 3e는 의존 도메인이 발의 도메인으로부터 사용자에 대한 임의의 필요 주장을 요청하면서 요청 사용자로부터 의존 도메인에 의해 수신되는 자원 요청을 충족하려 하는 풀 모델을 나타낸다.

이제 도 3a를 참조하면, 연합 환경 내의 주장을 생성하는 발의 도메인에서의 일반화된 프로세스를 나타내는 흐름도가 도시되어 있다. 이 프로세스는 발의 도메인의 접점 서버가 주장을 위해 트리거될 때 개시한다(단계 302). 접점 서버는 의존 도메인으로부터 주어진 사용자에게 특정 주장의 요청을 수신할 수 있고, 또는 주장을 촉구하는 기지의 의존 도메인에 아웃고잉 요청을 가로챌 수 있으며, 이들 시나리오는 각각 도 3c 및 도 3d에 대하여 이하 상세히 설명한다. 주장의 트리거에 응답하여, 발의 도메인의 접점 서버는 발의 도메인의 신뢰 프록시(단계 304)로부터 주장을 요청하며, 발의 도메인의 신뢰 프록시는 주장을 생성하며(단계 306), 발의 도메인의 신뢰 프록시는 필요시 요청된 주장을 생성하도록 신뢰 중재자로부터 지원을 요청할 수 있다. 주장을 생성한 후에, 발의 도메인의 신뢰 프록시는 그 후 발의 도메인의 접점 서버에 주장을 리턴하고(단계 308), 이는 그 후 예를 들면 아웃고잉 HTTP 또는 SOAP 메시지에 주장을 삽입함으로써 프로세스를 완료하는 적절한 방식으로 출력 데이터스트림에 주장을 주입한다(단계 310).

도 3a는 "로컬 지갑(local wallet)"의 사용없이 발의 도메인에서 주장을 생성하는 프로세스를 나타낸다. 그러나, 본 발명은 로컬 지갑 기능을 포함할 수 있다. 통상, 로컬 지갑은 트랜잭션을 용이하게 하는 사용자 속성 정보 또는 다른 정보에 대한 보안 데이터장소로서 동작할 수 있는 클라이언트측 코드이며, 클라이언트측 코드는 또한 주장 전송의 푸시 및/또는 풀 모델에 참가할 수 있다. 로컬 지갑이 프로토콜 내에 적극적으로 참가한 경우, 이는 프로토콜 흐름으로 주장을 생성 및 삽입하는 점에서 접점 서버 기능 중 일부 기능을 구현한다. 로컬 지갑의 사용은 로컬 지갑이 접점 서버와 신뢰 프록시 간에 생성되는 신뢰 기반 상호동작을 구현할 수 있게 한다. 추가 신뢰 관계가 획득되는 경우에는, 접점 서버가 호출되어야 한다.

이제 도 3b를 참조하면, 주장을 분할하는 의존 도메인에서의 일반화된 프로세스를 나타낸 흐름도가 도시되어 있다. 이 프로세스는 의존 도메인의 접점 서버가 관련 주장을 갖는 메시지를 수신할 때 개시한 후(단계 322), 이 주장을 발췌하여 의존 도메인의 신뢰 프록시에 전달한다(단계 324). 의존 도메인의 신뢰 프록시는 발의 도메인으로부터 수신된 토큰 등의 주장으로부터 정보를 발췌하며(단계 326), 의존 도메인의 신뢰 프록시는 보안 토큰 서비스를 호출하여 이 토큰을 확인 하며, 적절한 경우 사용자에 대한 로컬 유효 토큰을 리턴할 수 있다(단계 328).

단계 326의 일부로서, 신뢰 프록시는 소스, 즉 주장의 발의 당사자를 결정할 수 있다. 신뢰 프록시가 발의 도메인으로부터 수신된 신뢰 주장을 이해할 수 있으면, 신뢰 프록시는 내부적으로 단계 328을 수행할 수 있다. 신뢰 프록시가 발의 도메인으로부터 수신된 주장을 이해/신뢰할 수 없으면, 신뢰 프록시는 신뢰 중재자로부터 지원을 호출할 수 있다. 주장이 확인될 수 없으면, 적절한 에러 응답이 생성될 수 있다.

주장이 확인된 것으로 가정하면, 의존 도메인의 신뢰 프록시는 사용자에 필요한 로컬 정보를 구축한다(단계 330). 예를 들면, 로컬 정보는 백엔드 레거시 애플리케이션에 의해 요구되는 인증 자격증명을 포함할 수 있다. 의존 도메인의 신뢰 프록시는 사용자에 대한 로컬 세션을 구축하는 의존 도메인의 접점 서버에 요청된 정보를 리턴한다(단계 302).

접점 서버가 사용자에 대한 세션을 구축한 후에, 사용자는 인증 사용자로서 나타난다. 접점 서버는 이러한 세션을 사용하여 사용자가 갖는 임의의 트랜잭션을 로그아웃 또는 타임아웃 이벤트가 개시될 때까지의 도메인을 사용하여 더 관리할 수 있다. 접점 서버가 사용자에 대한 인증 아이덴티티인 경우, 접점 서버는 필요시 이러한 특정 사용자 아이덴티티와 특정 사용자에 관련된 인증 정책에 기초한 요청에 대한 인증을 획득할 수 있다. 그 후, 접점 서버는 임의의 관련 정보를 갖는 사용자 요청을 요청된 백엔드 애플리케이션 또는 서비스에 전달하여(단계 334), 프로세스를 완료한다.

접점 서버와 신뢰 프록시 사이에 전송된 데이터 항목과 이들 데이터 항목의 포맷은 변할 수 있음을 인식하여야 한다. 메시지에서 주장을 발췌하고 단지 이 주장만을 신뢰 프록시에 전달하는 대신, 접점 서버는 전체 메시지를 신뢰 프록시에 전달할 수 있다. 예를 들면, 신뢰 프록시에서 프로세싱은 전체 SOAP 엔벨로프를 요구할 수 있는 SOAP 메시지에 대한 서명 확인과 같은 단계를 포함할 수 있다.

이제 도 3c를 참조하면, 발의 도메인에서의 사용자 동작에 응답하여 발의 도메인으로부터의 주장을 의존 도메인에 푸시하는 특정 프로세스를 나타내는 흐름도가 도시되어 있다. 이 프로세스는 발의 도메인 내의 웹 페이지 또는 유사 자원으로부터 의존 도메인으로의 링크에 액세스할 때 개시하며(단계 342), 이에 의해 CGI형 (공통 게이트웨이 인터페이스) 프로세싱의 일부 형태를 호출하여 특정 주장을 구축한다. 의존 도메인에 의한 주장의 필요성을 인식하는 발의 도메인의 능력은 본 발명의 연합 기반구조가 구현되는 기존 레거시 시스템과의 강력한 통합을 암시한다. 또한, 이는 발의 당사자가 신뢰 프록시를 호출하여 필요한 주장을 구축할 필요가 없도록 발의 당사자와 의존 당사 간의 강한 결합을 암시하며, 이러한 강한 결합은 신뢰 관계를 잘 설정한 특정 유형의 연합 엔티티 사이에 적절할 수 있다.

발의 도메인에서의 백엔드 프로세싱은 로컬 신뢰 프록시에서의 기능 호출을 포함할 수 있는, 요청된 주장을 구축하도록 호출된다(단계 344). 그 후, 요청된 주장 등 발의 도메인에 대한 사용자 요청이 구축되고(단계 346), 발의 도메인은 의존 도메인에 대한 사용자 요청과 함께 이 주장을 전달하며(단계 348), 프로세스를 완료한다. 의존 도메인이 요청과 이의 관련 주장을 수신한 경우, 의존 도메인은 그 후 도 3b에 도시한 방식으로 주장을 확인할 수 있다.

이제 도 3d를 참조하면, 발의 도메인이 의존 도메인에 대한 아웃고잉 요청을 적극적으로 가로채는 것에 응답하여 발의 도메인으로부터 의존 도메인으로의 주장을 푸시하는 특정 프로세스를 나타내는 흐름도가 도시되어 있다. 이 프로세스는 의존 도메인에서 보호 자원을 사용자가 요청하는 때에 개시한다(단계 352). 접점 서버는 예를 들면 소정의 범용 자원 식별자(URI)에 대한 아웃고잉 메시지, 특정 유형의 메시지, 특정 유형의 메시지 컨텐츠를 필터링하여 또는 일부 다른 방식으로 아웃고잉 요청을 가로챈다(단계 354). 발의 도메인의 접점 서버는 그 후 발의 도메인의 신뢰 프록시로부터 적절한 주장의 생성을 요청하며(단계 356), 이는 필요시 신뢰 중재자로부터 지원을 갖는 주장을 생성한다(단계 358). 그 후, 발의 도메인은 의존 도메인에 대하여 생성된 주장과 함께 사용자 요청을 전달함으로써(단계 360), 이 프로세스를 완료한다. 의존 도메인이 이 요청과 관련 주장을 수신하는 경우, 의존 도메인은 도 3b에 도시한 방식으로 주장을 확인할 수 있다.

이제 도 3e를 참조하면, 의존 도메인이 발의 도메인으로부터 사용자에 대한 임의의 요청된 주장을 요구하면서 요청 사용자로부터 의존 도메인에 의해 수신된 자원 요청을 충족하려 하는 풀 모델을 나타내는 흐름도가 도시되어 있다. 이 프로세스는 보호 자원에 대한 사용자 요청을 의존 도메인이 수신할 때 개시한다(단계 372). 도 3c 또는 도 3d에 도시한 예와는 달리, 도 3e에 도시한 예는 사용자에 대한 임의의 요청된 주장의 부재시에 의존 도메인에서 수신되는 사용자 요청에 관련된 프로세싱을 나타낸다. 이 경우, 발의 도메인은 사용자 요청에서 필요한 주장을 삽입하기 위해서 사용자 요청을 가로채거나 처리할 능력을 갖지 않는다. 예를 들면, 사용자는 아웃고잉 요청이 발의 당사자의 접점 서버에 의해 가로채지 않도록 범용 자원 위치입력기(URL)를 입력하거나 자원에 북마크 참조를 사용할 수 있다. 따라서, 의존 도메인은 발의 도메인으로부터의 주장을 요청한다.

그 후, 의존 도메인은 사용자 홈 도메인, 즉, 관련 발의 도메인을 결정한다(단계 374). HTTP 기반 구현예에서, 사용자는 사용자의 클라이언트 장치에서 의존 도메인에 의해 설정되는 영구 쿠키를 생성하는 의존 도메인과의 관계를 미리 설정할 수 있다. 영구 쿠키는 사용자 홈 도메인, 즉, 발의 도메인의 아이덴티티를 포함할 수 있다. 사용자가 일부 방식으로 웹 서비스 클라이언트를 운영하는 SOAP 기반 구현예에서, 의존 도메인에서의 웹 서비스는 토큰 요청 등의 WSDL(웹 서비스 기술 언어)를 통해 서비스 요건을 광고할 수 있다. 그 후, 이는 사용자의 웹 서비스 클라이언트/SOAP 구현예가 요청된 토큰 유형을 제공하도록 요구한다. 이 요건이 충족되지 않으면, 웹 서비스는 기술적으로 에러를 리턴할 수 있다. 일부 경우, 사용자의 웹 서비스 클라이언트가 인증 정보에 대하여 촉구될 수 있게 하는 에러 코드를 리턴할 수 있기 때문에, 요청이 적절한 토큰으로 반복될 수 있다.

의존 도메인의 접점 서버는 의존 도메인의 신뢰 프록시에 의해 주장 요청을 개시하며(단계 376), 의존 도메인의 신뢰 프록시는 발의 도메인의 신뢰 프록시로부터 사용자에 대하여 주장을 요청한다(단계 378). 실시예가 HTTP 기반 통신을 사용하는 경우라면, 의존 도메인의 신뢰 프록시로부터 발의 도메인의 신뢰 프록시로의 주장 요청은, 의존 도메인의 접점 서버에 의해 사용자의 브라우저 애플리케이션을 통한 방향 변경에 의해서 발의 도메인의 접촉 서버에 전송되고, 발의 도메인의 접촉 서버는 그 주장 요청을 발의 도메인의 신뢰 프록시에 전달할 수 있다.

실시예가 SOAP 기반 구현예를 사용하는 경우라면, 의존 당사자는 사용자의 웹 서비스 클라이언트에 에러 코드를 리턴할 수 있다. 이 에러 코드는 사용자가 이들의 웹 서비스 클라이언트에 의해 인증 정보에 촉구될 수 있게 한다. 그 후, 웹 서비스 클라이언트는 요청된 토큰을 생성한다. 사용자의 웹 서비스 클라이언트는 의존 도메인의 신뢰 프록시가 UDDI(범용 기술, 발견 및 통합) 레지스트리에 광고되었다면, 신뢰 프록시를 직접 호출하여, 사용자의 웹 서비스 클라이언트가 신뢰 프록시를 발견할 수 있게 한다. 통상, 이러한 시나리오는 내부 사용자에게만 유효하며, 이 경우, 신뢰 프록시는 연합 밖에서 통상 액세스가능하거나 인터넷 상의 공용 UDDI에 광고되지는 않을 것이기 때문에 기업 내의 사설 UDDI에 광고한다.

발의 도메인의 신뢰 프록시는 주장 요청이 수신된 방식을 반영하는 방식으로 요청된 주장을 생성한 후(단계 380) 리턴한다(단계 382). 의존 도메인의 신뢰 프록시가 요청 주장을 수신한 후에(단계 384), 의존 도메인의 신뢰 프록시는 주장에서 정보를 발췌하여(단계 386) 주장을 해석 및/또는 확인하려 하며(단계 388), 신뢰 프록시는 주장의 번역을 위해 필요시 신뢰 중재자로부터 지원을 호출할 수 있다. 주장이 확인될 수 없으면, 적절한 에러 응답이 생성될 수 있다. 주장이 확인되면, 의존 도메인의 신뢰 프록시는 보호 자원에 대한 사용자 요청을 충족하려 할 수 있는 백엔드 서비스의 사용에 필요한 적절한 포맷으로 로컬 정보를 구축한다(단계 390). 예를 들면, 로컬 정보는 백엔드 레거시 애플리케이션에 의해 필요한 인 증 자격증명을 포함할 수 있다. 의존 도메인의 신뢰 프록시는 의존 도메인의 접점 서버에 필요 정보를 리턴하고(단계 392), 그 후, 의존 도메인의 접점 서버는 사용자에 대한 로컬 세션을 구축하여 요청된 백엔드 애플리케이션 또는 서비스에 임의의 관련 정보를 구비한 사용자의 요청을 전달함으로써(단계 394), 프로세스를 완료한다.

연합 아키텍처 내의 단일 서명

도 2a 내지 도 2d의 설명은 본 발명에 따른 연합 데이터 처리 환경 내에서 엔티티의 동작 특성에 집중하지만, 도 3a 내지 도 3e는 이들 엔티티 사이에 발생하는 일부 프로세스에 집중한다. 이 설명과는 달리, 사용자에 대한 트랜잭션을 완료하면서 사용자에게 단일 서명 경험을 제공하는 본 발명의 설명을 도 4를 참조하여 행해진다.

다시 말하면, 후술하는 설명은 상술한 엔티티와 프로세스를 설명하지만, 후술하는 설명은 사용자가 사용자 세션 내에서 단일 서명 경험을 가질 수 있는 방식에 대하여 본 발명의 전반적인 관점에 보다 초점을 맞춘다. 세션은 초기 사용자 인증, 즉, 로그온으로부터 (그리고 이를 포함하는) 트랜잭션 집합으로서 정의될 수 있다. 세션 내에서, 사용자의 동작은 이 세션에 대하여 사용자에게 부여된 특권에 의해 일부 관리될 수 있다. 사용자는, 연합 내에서, 사용자가 단일 인증 동작을 완료하고, 이러한 인증 동작은 세션 기간 동안 방문한 연합 파트너에 관계없이 이 세션 동안 만족시키는 단일 서명 경험을 기대한다.

사용자의 세션 동안, 사용자는 많은 연합 도메인을 방분하여 도메인에 의해 제공된 웹 서비스를 사용할 수 있다. 도메인은 공통 데이터 포맷으로서 XML을 사용하는 UDDI 및 WDSM과 같은 표준 사양을 사용하여 제공하는 서비스의 설명을 공개할 수 있다. 사용자는 가용 서비스와 서비스 제공자를 이들 표준 사양에 부착한 애플리케이션을 통해 발견한다. SOAP는 XML로 표현된 요청 및 응답을 통신하는 패러다임을 제공한다. 연합 환경 내의 엔티티는 무엇보다 이들 표준을 사용할 수 있다.

단일 서명 경험을 용이하게 하기 위해서, 연합 환경을 지원하는 웹 서비스는 또한 제3자에 의해 생성된 인증 주장 또는 보안 토큰의 사용을 지원하여 사용자의 인증 증거를 제공할 수 있다. 이러한 주장은 발의 당사자에 대한 사용자의 성공적인 인증의 일부 증거 유형과 함께 이 사용자에 대한 식별자를 포함할 수 있다. 따라서, 사용자는 하나의 인증 파트너에 종재의 인증 자격증명, 예를 들면, 사용자명과 패스워드를 제공한 후 인증/발의 당사자에 의해 생성된 SAML 주장 인증을 상이한 연합 당사자에게 제공할 수 있다.

웹 서비스 환경에서 인증은 웹 서비스 요청의 요구된 아이덴티티를 검증하는 동작이기 때문에, 기업은 인가된 클라이언트에 대한 액세스를 제한할 수 있다. 웹 서비스를 요청하거나 호출하는 사용자는 거의 항상 인증될 수 있으므로, 본 발명의 연합 환경 내의 인증에 대한 요구는 사용자 인증을 위한 웹 서비스의 현재 요건과 다르지 않다. 또한, 연합 환경은 웹 서비스 또는 다른 애플리케이션이 웹 서비스를 요청할 수 있게 하며, 이들 웹 서비스는 또한 인증될 수 있다.

연합 세션에 참가하지 않은 사용자의 인증은 본 발명의 연합 아키텍처에 의 해 영향을 받지 않는다. 예를 들면, HTTP에 대한 형태 기반 인증 메커니즘에 인증하여 특정 도메인에서 비연합 자원을 액세스하는 기존 사용자는 연합 환경 도메인에서 지지의 도입에 영향을 받지 않는다. 인증은 접점 서버에 의해 일부 처리되고, 이에 따라 개별 신뢰 프록시 컴포넌트를 호출할 수 있다. 접점 서버의 사용은 기존 도메인의 기반주조에 대한 영향을 최소화한다. 예를 들면, 접점 서버는 모든 비연합 요청에 걸쳐 이 도메인에서 백엔드 또는 레거시 애플리케이션 및 시스템에 의해 처리되도록 구성될 수 있다.

접점 서버는 기본 인증, 형태 기반 인증, 또는 일부 다른 인증 방법 등의 HTTP 기반 인증 방법의 호출을 선택할 수 있다. 접점 서버는 또한 SAML 인증 주장과 같은 인증의 증거로서 사용자에 의해 제공된 인증을 인식함으로써 연합 신뢰 도메인을 지원하며, 이 주장은 기업 신뢰 도메인 사이에 교차할 수 있다. 접점 서버는 신뢰 프록시를 호출할 수 있으며, 이는 인증 자격증명/보안 토큰의 확인을 위한 보안 토큰 서비스를 호출할 수 있다.

웹 서비스 또는 다른 애플리케이션의 인증은 사용자의 인증과 동일한 프로세스를 포함한다. 웹 서비스로부터의 요청은 인증 주장을 포함하는 보안 토큰을 반송하며, 이러한 보안 토큰은 사용자에 의해 제공된 토큰과 동일한 방식으로 시뢰 프록시/보안 토큰 서비스에 의해 확인될 수 있다. 웹 서비스로부터의 요청은, 어느 인증 주장/보안 토큰이 UDDI에서 광고된 바와 같이 요청된 서비스에 의해 필요한 지를 웹 서비스가 발견할 수 있기 때문에, 이를 구비한 토큰을 반송한다.

이제 도 4를 참조하면, 연합 단일 서명 동작을 지원하는 연합 환경을 나타낸 블록도가 도시되어 있다. 사용자(400)는 브라우저와 같은 적절한 클라이언트 애플리케이션과 클라이언트 장치를 통해, 연합 환경 내의 연합 도메인으로서 동작하는 데이터 처리 시스템을 지원하는 기업/도메인(410)에 의해 제공된 웹 서비스의 액세스를 원한다. 도메인(410)은 접점 서버(412)와 신뢰 프록시(414)를 지원하며, 유사하게, 도메인(420)은 접점 서버(422)와 신뢰 프록시(424)를 지원하고 도메인(430)은 접점 서버(432)와 신뢰 프록시(434)를 지원한다. 신뢰 프록시는 상술한 바와 같이 지원을 위한 신뢰 중재자(450)에 의존한다. 추가 도메인 및 신뢰 프록시가 연합 환경 내에 참가할 수 있다. 도 4는 도메인(410)과 도메인(420) 간의 연합 단일 서명 동작을 나타내며, 유사한 동작이 도메인(410)과 도메인(430) 간에 발생할 수 있다.

사용자는 도메인(410)에 대한 인증 동작을 완료하며, 이러한 인증 동작은 접점 서버(412)에 의해 처리된다. 이 인증 동작은, 예를 들면, 개인화 목적을 위해 또는 액세스 제어 목적을 위해, 사용자가 인증 엔티티를 요하는 일부 자원으에의 액세스를 요구할 때 트리거된다. 접점 서버(412)는 레거시 인증 서비스를 호출할 수 있으며, 또는, 신뢰 프록시(414)를 호출하여 사용자의 제공된 인증 자격증명을 확인할 수 있다. 도메인(410)은 사용자의 연합 세션의 기간 동안 사용자의 홈 도메인이 된다.

시간 상 얼마 후에, 사용자는 연합 도메인을 또한 지원하는 기업(420) 등의 연합 파트너에서 트랜잭션을 개시함으로써, 연합의 단일 서명 동작을 트리거한다. 예를 들면, 사용자는 도메인(420)에서 새로운 트랜잭션을 개시할 수 있으며, 또는 사용자의 원래 트랜잭션이 다른 도메인에서 하나 이상의 추가 트랜잭션으로 중복될 수 있다. 다른 예로서, 사용자는 도메인(410) 내에 호스팅되는 웹 페이지 상에 특별 링크를 선택함으로써, 또는 도메인(410) 내에 호스팅되지만 도메인(420) 내에 호스팅되는 자원을 디스플레이하는 포털 페이지를 요청함으로써 접점 서버(412)를 통해 도메인(420) 내의 자원에 연합 단일 서명 동작을 호출할 수 있다. 접점 서버(412)는 도메인(420)에 의해 이해되거나 신뢰받도록 포맷된 사용자에 대하여 생성된 연합 단일 서명 토큰에 신뢰 프록시(414)에 대한 요청을 전송한다. 신뢰 프록시(414)는 접점 서버(412)에 이 토큰을 리턴하며, 접점 서버(412)는 도메인 내의 접점 서버(422)에 이 토큰을 전송한다. 도메인(410)은 의존 당사자로서 동작하는 도메인(420)에서 사용자에 대한 발의 당사자로서 동작한다. 사용자의 토큰은 사용자의 요청으로 도메인(420)에 전송될 수 있으며, 이 토큰은 브라우저를 통해 HTTP 방향변경을 사용하여 전송되거나 신뢰 프록시(414)에 의해 제공된 토큰에서 식별된 사용자를 대신하여 접적 서버(422)의 요청을 (HTTP 또는 SOAP-over-HTTP 상으로) 직접 호출하여 전송될 수 있다.

접점 서버(422)는 연합 단일 서명 토큰과 함께 이 요청을 수신하여 신뢰 프록시(424)를 호출한다. 신뢰 프록시(424)는 연합 단일 서명 토큰을 수신하고, 이 토큰을 확인하며, 토큰이 유효하고 신뢰받는 경우, 사용자에 대한 국부 유효의 토큰을 생성한다. 신뢰 프록시(424)는 도메인 내의 사용자에 대한 세션을 성립시키는 접점 서버(422)에 국부 유효 토큰을 리턴한다. 필요시, 접점 서버(422)는 다른 연합 파트너에서 연합 단일 서명을 개시할 수 있다.

도메인(420)에서 토큰의 확인은, 가능하게는 보안 토큰 서비스로부터 지원하는, 신뢰 프록시(424)에 의해 처리된다. 도메인(410)에 의해 제공되는 토큰 유형에 따라, 보안 토큰 서비스는 도메인(420)에서 사용자 레지스트리에 액세스할 필요가 있을 수 있다. 예를 들면, 도메인(420)은 사용자명과 패스워드를 포함하는 바이너리 보안 토큰을 제공하여 도메인(420)에서 사용자 레지스트리에 대하여 확인될 수 있다. 따라서, 이 예에서, 기업은 연합 파트너로부터 보안 토큰을 단순히 확인한다. 도메인(410 및 420) 간의 신뢰 관계는 도메인(420)이 사용자에 대신하여 도메인(410)에 의해 제공된 보안 토큰을 이해 및 신뢰할 수 있게 보장한다.

연합 단일 서명은 사용자를 대신하여 의존 도메인에 제공되는 보안 토큰의 확인 뿐만 아니라 보안 토큰에 포함된 정보에 따라 의존 도메인에서 국부 유효한 사용자 식별자의 판단을 요구한다. 직접 신뢰 관계와 이러한 관계를 설정하는데 필요한 사업 협정의 결과 중 하나는, 발의 도메인 또는 의존 도메인 중 적어도 하나의 당사자 또는 둘 모두가 발의 도메인에 의해 제공되는 정보를 의존 도메인에서 유효한 식별자로 어떻게 번역하는지를 인식할 수 있다는 점이다. 상기 간략한 예에서, 발의 도메인, 즉, 도메인(410)은 의존 도메인, 즉, 도메인(420)에 도메인(420)에서 유효한 사용자 식별자를 제공할 수 있다. 이 시나리오에서, 의존 도메인은 임의의 아이덴티티 매핑 기능을 호출할 필요는 없다. 신뢰 프록시(424)는 도메인(420)에서 이러한 사용자를 보증할 수 있는 사용자에 대한 보안 토큰을 생성할 수 있다. 허용되는 토큰 유형, 토큰 상에 필요한 서명, 및 다른 요건은 모두 연합 사업 협정의 일부로서 미리 설정된다. 또한, 식별자 번역을 지배하는 규칙 및 알 고리즘은 연합의 사업 협정의 일부로서 미리 설정된다. 두 참여자 간의 직접적인 신뢰 관계의 경우, 식별자 번역 알고리즘은 이들 두 당사자에 대하여 설정될 수 있으며, 연합에서 임의의 다른 당사자에 대하여 관련되지 않을 수 있다.

그러나, 발의 도메인이 항상 도메인(410)에 대한 로컬 식별자로부터의 사용자를 도메인(420)에 대한 로컬 식별자에 매핑하는 방식을 인식할 수 있는 것은 아니다. 일부 경우에는, 의존 도메인이 이러한 매핑을 어떻게 행하는지를 인식할 수 있지만, 다른 경우에는, 어느 당사자도 이러한 번역을 어떻게 하는지를 인식하지 못할 수 있으며, 후장의 경우, 제3자 신뢰 중재자가 호출될 필요가 있을 수 있다. 즉, 중재 신뢰 관계의 경우, 발의 및 의존 도메인은 서로 직접 신뢰 관계를 갖지 않는다. 그러나, 이들은 신뢰 중재자(450)와 같은 신뢰 중재자와 직접 신뢰 관계를 가질 수 있다. 식별자 매핑 규칙 및 알고리즘은 이러한 관계의 일부로서 설정될 수 있으며, 신뢰 관계는 이러한 정보를 사용하여 중재된 신뢰 관계에 필요한 식별 번역을 지원할 수 있다.

도메인(420)은 접점 서버(422)에서 도메인(410)에 의해 발행된 토큰을 수신하며, 접점 서버(422)는 신뢰 프록시(424)를 호출하여 토큰을 확인하고 아이덴티티 매핑을 수행한다. 이 경우, 신뢰 프록시(424)는 도메인(410)에 대한 로컬 식별자에서의 사용자를 도메인(420)에 대한 로컬 식별자에 매핑할 수 없기 때문에, 신뢰 프록시(424)는 토큰을 확인하고 식별자 매핑을 수행하는 신뢰 중재자(450)를 호출한다. 사용자에 대한 로컬 식별자를 획득한 후에, 신뢰 프록시(424)는 가능하게는 이의 보안 토큰 서비스를 통해 도메인(420)에서 백엔드 애플리케이션에 의해 필요 한 임의의 로컬 토큰을 생성할 수 있으며, 예를 들면, 커베로스 토큰은 접적 서버로부터 애플리케이션 서버로의 단일 서명을 용이하게 하는데 필요할 수 있다. 국부적으로 유효한 토큰을 획득한 후에, 필요시, 접점 서버는 사용자에 대한 로컬 세션을 구축할 수 있다. 접점 서버는 또한 사용자 요청의 대략적인(coarse-grained) 인증을 처리하여 이 인가된 요청을 도메인(420) 내의 적절한 애플리케이션 서버에 전송할 수 있다.

연합 아키텍처 내의 통합 로그오프

전술한 연합 환경에서, 사용자의 인증 정보는 다수의 도메인 및 이종 환경에 걸쳐 전달된다. 사용자는 홈 도메인을 가지며, 이 홈 도메인은 사용자의 인증 자격증명을 확인하는 도메인이다. 따라서, 이 홈 도메인은 의존측이 다른 도메인에서 신뢰하고 이용할 수 있는 사용자 관련 주장을 발행하는 발의측으로서의 역할을 할 수 있다. 이 주장이 발의측에서 의존측으로 전송되는 경우, 이 주장은 사용자의 개입 없이 실행되어, 사용자에게 이종 도메인에 걸친 단일 서명 경험을 제공한다.

그러나, 시스템의 안전을 확보하는 최적 요소는 사용자가 시스템에 대한 자신의 아이덴티티를 증명하는 인증 동작, 즉 로그온 또는 로그인 동작을 완료하는 것을 요건으로 한다. 이 프로세스에서, 이에 못지 않게 중요한 요소는 사용자가 보안 세션을 종료시키는 로그오프 동작, 즉 사인오프(sign-off) 또는 사인아웃(sign-out) 동작을 완료함으로써 다른 사용자들을 도용 또는 유효 세션에 대한 악의적인 방해로부터 보호하는 것을 요건으로 한다.

로그오프 동작에서 어려운 문제 중 하나는 사용자가 로그오프를 결정할 위치를 예측할 수 없다는 것이다. 다시 말하면, 사용자는 연합 단일 세션 내에서 다수의 도메인과 상호동작할 수 있고, 사용자가 로그오프를 결정할 때 사용자가 상호동작할 도메인에 어느 도메인인지를 예측하는 것이 불가능하다. 일례로서, 사용자가 사용자의 홈 도메인에서 로그오프하기를 원할 수 있다. 그러나, 만일 사용자가 홈 도메인이 다른 도메인들의 단일 서명 동작들을 실행하도록 트랜잭션을 호출한 후, 이들 의존 도메인 중 하나의 의존 도메인이 발의 도메인으로서 기능을 하였다면, 사용자의 홈 도메인은 이들 도메인들을 인지하지 못하여, 사용자 대신에 이들 도메인에서 로그오프 동작을 실시할 수 없을 것이다.

본 발명은 연합 환경 내의 통합 로그오프 동작에 대한 다양한 방법을 제공한다. 본 발명은 통합 로그오프 동작에 대하여 2가지의 일반적 방법, 즉 HTTP에 기초하는 방법과 SOAP에 기초하는 방법을 따른다. HTTP 방법은 사용자의 브라우저를 통한 HTTP 재지정을 이용하여 "프런트 엔드(front-end)" 방식으로 실행될 수도 있고, 또는 사용자의 브라우저를 호출하지 않고 로그오프 통지가 연합 도메인의 접점 서버에 직접 전송되는 "백채널(back-channel)" 방식으로 실행될 수도 있다.

SOAP 방법은 사용자 또는 사용자의 SOAP 클라이언트를 호출하지 않고, 연합체의 구성요소들간에 직접 통신을 하는 "백채널" 방식으로 실행된다. 또한, SOAP 방법은 의존 도메인이 발생가능 로그오프 이벤트에 등록하는 것을 허용하는 발행/등록 모델을 이용할 수 있다. 따라서, 사용자의 홈 도메인은 사용자에게 로그오프 이벤트를 발행할 것이다. 이 이벤트는 이러한 로그오프 이벤트에 등록한 모든 도 메인에 의해 수신될 것이다. 다음에, 의존 도메인은 로그오프 이벤트가 특정 사용자와 관련있는 지를 판정할 수 있고, 만일 로그오프 이벤트가 특정 사용자와 관련이 있다면, 의존 도메인은 사용자의 로그오프 또는 세션 탈퇴를 시행한다. 이 로그오프에 대해 "최적화된" 방법은 의존 도메인이 보다 세밀하게 로그오프 이벤트, 즉 특정 사용자를 지정하는 로그오프 이벤트에 등록하는 것을 허용하여, 의존 도메인이 그 특정 사용자에 대한 로그오프 이벤트에 대해서만은 모든 로그오프 이벤트에 예의주시하지 않아도 되게 하는 것이다. 이하에서는 나머지 도면을 참조하여 통합 로그오프 동작에 대한 몇 가지 바람직한 실시예를 설명한다.

이제 도 5를 참조하면, HTTP 재지정(redirection)을 통해 연합 도메인 중에서 통합 로그오프 동작을 실행하는 프로세스를 나타내는 흐름도이다. 도 5에 나타낸 통합 로그오프 동작은 사용자에 의한 로그오프 동작 호출시에(단계 502) 또는 사용자에 의한 로그오프 자원에의 액세스시에, 예컨대 웹 페이지 상의 로그오프 버튼을 선택함으로써 사용자의 홈 도메인에서 시작된다. 이와 달리, 로그오프 동작은 미사용 시간만료 등과 같은 다양한 이유로 홈 도메인에 의해 개시될 수도 있다.

홈 도메인은 다른 연합 도메인들의 세트에 대한 발의 도메인으로서 기능했을 수도 있다. 따라서, 홈 도메인은 프로세스 내에서 발의 도메인으로 불리울 수 있다. 발의 도메인은 사용자에 대한 연합 단일 서명 동작 동안 인증 주장을 전송한 의존 도메인의 리스트를 획득한다(단계 504). 발의 도메인은 리스트로부터 다음의 의존 도메인을 식별하고(단계 506), 발의 도메인의 접점 서버는 이 식별된 의존 도메인의 사용자에 대한 로그오프 요청 메시지를 (발의 도메인의 신뢰 프록시의 도움 으로) 생성한다(단계 508). 계속해서, 발의 도메인의 접점 서버는 사용자의 브라우저 애플리케이션을 이용하여 HTTP 재지정을 통해 식별된 의존 도메인의 접점 서버로부터 로그오프 상태 메시지를 수신하여 저장한다(단계 512).

의존 도메인 리스트에 다른 의존 도메인이 더 있는지 여부를 결정하고(단계 514), 다른 도메인이 더 있다면, 프로세스는 단계 506으로 되돌아가 다른 로그오프 요청을 생성한다. 다른 도메인이 없다면, 발의 도메인은 발의 도메인의 사용자를 로그오프시킨다(단계 516). 다음에, 발의 도메인의 접점 서버는 로그오프 상태 메시지를 작성하여 사용자에게 전송하고(단계 518), 로그오프 프로세스를 종료시킨다.

전술한 바와 같이, 홈 도메인은 다른 다운스트림 도메인에 대해 스스로가 발의 도메인으로서 기능할 수 있는 의존 도메인에 대해 발의 도메인으로서 기능할 수 있다. 따라서, 의존 도메인이 로그오프 요청을 획득한 경우, 도 5에 나타낸 프로세스를 실행할 수 있다. 이 시점에서, 의존 도메인은 단계 504~516에서 발의 도메인으로서 간주될 수 있다. 그러나, 프로세스는 상이하게 시작하고 종료할 것이다. 그의 로그오프 프로세스를 개시하기 위해, 의존 도메인은 발의 도메인으로부터 로그오프 요청 메시지를 수신한다(단계 520). 그의 로그오프 동작을 종결짓기 위해, 의존 도메인은 로그오프 응답 메시지를 생성하여, 로그오프 요청 메시지를 수신한 발의 도메인에게 리턴시킨다(단계 522).

대안의 실시예에서, 발의 도메인의 접점 서버는 사용자에 대한 로그오프 요청 메시지에 의해 HTTP 메시지를 의존 도메인의 접점 서버에 직접 전송할 수 있다. 이것은 의존 도메인의 접점 서버가 이 요청 메시지를 수신하고, 요청 메시지에 포함되어 있는 사용자 식별자를 유효 사용자 세션에 사상(매핑)시킬 수 있는 것을 필요로 한다. 즉, 이것은 사용자가 의존 도메인, 예컨대 로그오프 요청을 수반하는 HTTP 쿠키와 상호동작하는 경우에 사용자의 세션 정보는 사용자와 "동행"하기 때문에 이전의 예에서 "투명하게" 처리된다. 이 대안의 시나리오는 사용자의 세션을 식별하는데 이용되는 클라이언트측 쿠키와 같이, 사용되고 있는 클라이언트측 기술이 있는 경우에는 사용자를 완전히 로그아웃시키지 못한다. 사용자의 세션은 서버측에서 종료될 것이다. 즉, 사용자가 서버에 대한 액세스를 시도하는 다음 시기에(클라이언트측 세션 토큰은 스스로 만료되지 않은 것으로 가정함), 서버는 이 토큰을 명백하게 만료시킬 필요가 있을 것이다. 예컨대, 서버가 서버에 매칭 세션이 없는 클라이언트측 세션 쿠키를 수신한 경우, 서버는 오류를 발생시킬 것이고, 또한 쿠키를 무효인 것으로 리셋시킬 것이다. 어느 경우든, 발의 도메인의 접점 서버에 리턴된 상태 메시지는 단계 522에 대해 개시된 것과 같고, 사용자에게 리턴된 상태 페이지는 단계 518에 대해 개시된 것과 같다.

다른 대체 실시예에서, 로그오프 요청 동작은 SOAP-over-HTTP를 이용한다. 이 시나리오에서, 발의 도메인의 접점 서버로부터 의존 도메인의 접점 서버로의 요청은 SOAP-over-HTTP를 이용하지만, 사용자의 브라우저를 통한 재지정(redirection)을 호출하지 않는다. 그러나, 발의 도메인의 접점 서버로부터 수신된 로그오프 요청 및 보안 토큰을 의존 도메인의 접점 서버의 사용자에 대한 적절한 세션 정보에 매칭시키기 위해 의존 도메인의 접점 서버가 처리하는 양은 많아질 것이다. 로그오프 상태 메시지와 응답은 도 5에 개시한 것과 유사할 것이다.

이제 도 6을 참조하면, SOAP 백채널 방법을 이용하여 연합 도메인 중에서 통합 로그오프 동작을 실행하는 프로세스를 나타내는 흐름도이다. 도 6에 나타낸 통합 로그오프 동작은 사용자가 로그오프 프로세스를 호출할 때(단계 602) 또는 사용자가 로그오프 자원에 액세스할 때, 예컨대 웹 페이지 상의 로그오프 버튼을 선택함으로써 사용자의 홈 도메인에서 시작한다. 이와 달리, 로그오프 동작은 미사용 시간만료 등과 같은 다양한 이유로 홈 도메인에 의해 개시될 수도 있다. 홈 도메인은 다른 연합 도메인들의 세트에 대한 발의 도메인으로서 기능했을 수도 있다. 따라서, 홈 도메인은 프로세스 내에서 발의 도메인으로 불리울 수 있다.

발의 도메인의 접점 서버는 발의 도메인의 신뢰 프록시에게 로그오프 시도 사실을 통지한다(단계 604). 신뢰 프록시는 사용자의 세션 동안에 이 특정 사용자에 대해 연합 단일 서명 토큰을 작성한 모든 도메인의 기록을 유지한다. 발의 도메인의 신뢰 프록시는 사용자에 대한 연합 단일 서명 동작 동안 인증 주장을 전송한 의존 도메인의 리스트를 획득한다(단계 606). 발의 도메인의 신뢰 프록시는 리스트로부터 다음의 의존 도메인을 식별하고(단계 608), 발의 도메인의 신뢰 프록시 서버는 이 식별된 의존 도메인의 사용자에 대한 로그오프 요청 메시지를 생성한다(단계 610). 다음에, 발의 도메인의 신뢰 프록시 서버는 로그오프 요청을 식별된 의존 도메인의 신뢰 프록시에 전송한다(단계 612). 계속해서, 발의 도메인의 신뢰 프록시는 식별된 의존 도메인의 신뢰 프록시로부터 로그오프 상태 메시지를 수신하여 저장한다(단계 614).

의존 도메인 리스트에 다른 의존 도메인이 더 있는지 여부를 결정하고(단계 616), 다른 도메인이 더 있다면, 프로세스는 단계 608로 되돌아가 다른 로그오프 요청을 생성한다. 다른 도메인이 없다면, 발의 도메인의 신뢰 프록시는 발의 도메인의 사용자를 로그오프시킨다(단계 618). 다음에, 발의 도메인의 신뢰 프록시는 로그오프 상태 메시지를 작성하여 접점 서버를 통해 사용자에게 전송하고(단계 620), 로그오프 프로세스를 종료시킨다. 서버가 사용자 세션 관리를 실행함에 따라, 신뢰 프록시는 로컬 사용자 토큰을 작성하고, 사용자에 대한 접점 서버에서 로그오프 프로세스를 개시하여 사용자의 세션을 종료시킬 필요가 있을 수 있다는 점을 주목하여야 한다.

전술한 바와 같이, 홈 도메인은 다른 다운스트림 도메인에 대해 스스로가 발의 도메인으로서 기능할 수 있는 의존 도메인에 대해 발의 도메인으로서 기능할 수 있다. 따라서, 의존 도메인이 로그오프 요청을 획득한 경우, 도 6에 나타낸 프로세스를 실행할 수 있다. 이 시점에서, 의존 도메인은 단계 604~618에서 발의 도메인으로서 간주될 수 있다. 그러나, 프로세스는 상이하게 시작하고 종료할 것이다. 그의 로그오프 프로세스를 개시하기 위해, 의존 도메인은 발의 도메인으로부터 로그오프 요청 메시지를 수신한다(단계 622). 그의 로그오프 동작을 종결짓기 위해, 의존 도메인은 로그오프 응답 메시지를 생성하여, 로그오프 요청 메시지를 수신한 발의 도메인에게 리턴시킨다(단계 624). 로그오프 상태 메시지 및 응답은 도 6에 개시한 것과 유사할 것이다.

또한, SOAP 방법은 발행/등록 모델을 이용할 수 있다. 본 발명은 발행/등록 기술을 이용하여, 로그오프 이벤트 핸들러가 사용자에 의해 이전에 로그온된 모든 서버와 통신하여 로그오프 이벤트 발생 사실을 그들 서버에 통지하는 것을 허용한다. 전술한 방법과는 대조적으로, 발행/등록 모델의 경우, 사용자가 로그인한 모든 시스템에 대한 기록, 또는 그들 시스템과의 통신로를 갖는 엔티티는 1개 있다.

대표적인 발행/등록 환경에서, 발행자와 등록자간의 관계는 통상 장기(長期)이고, 주어진 "클래스"의 모든 이벤트, 예컨대 모든 로그오프 이벤트 또는 모든 로그온 이벤트에 적용된다. 본 발명은 단기(短期) 콘텍스트 지정 등록자 관계의 개념을 개시하고 있다. 연합 환경의 동적인 성질 때문에, 축소/확대 가능한 토폴로지는 단기 콘텍스트 지정 이벤트와 장기 관계를 모두 지원한다.

본 발명에서, 웹 서비스는 임의의 타입의 이벤트, 예컨대 모든 로그온 통지에 등록할 수 있고, 계속해서, 웹 서비스는 로그온된 세션이 종료된 시기를 판정하기 위해 모든 로그오프 이벤트에 등록할 필요가 있을 것이다. 따라서, 웹 서비스는 특정한 서브세트의 로그오프 이벤트에만 관심있다고 하더라도 모든 로그오프 이벤트에 등록할 것이다. 이것은 웹 서비스가, 관심있는 로그온 이벤트가 어느 로그온 이벤트인지를 미리 예측하는 것이 불가능하기 때문에 모든 이벤트에 등록하여야 하는 로그온 이벤트와 비교된다.

또한, 본 발명에서, 발행/등록 규칙은 웹 서비스가 콘텍스트 지정 이벤트에 등록할 수 있는 능력을 보유하도록 개량될 수 있다. 따라서, 일례의 시나리오에서, 특정 웹 서비스는 해당 사용자가 인증되었다는 사실을 통지받을 것이다. 만일 웹 서비스가 이 로그인 이벤트를 반영하도록 그의 상태를 업데이트시키는 것을 선 택한다면, 웹 서비스는 이제, 사용자가 로그오프되었는지를 판정하기 위해 로그오프 이벤트에 등록하는 것에 관심이 있을 것이다. 웹 서비스가 모든 로그오프 이벤트에 등록하게 하는 것보다, 본 발명은 웹 서비스가 콘텍스트 지정 이벤트, 즉 해당 사용자에 의해 이벤트를 로그오프하도록 하는 모든 로그오프 이벤트의 개량에 등록하는 것을 허용한다. 이 상황에서, 웹 서비스, 즉 의존측과, 발의 도메인의 신뢰 프록시, 즉 발행측간의 등록자 관계는 단명(短命), 즉 해당 사용자의 인증된 세션의 지속 기간 동안이다.

요약하면, 발의 도메인은 발행자로서 기능하고, 의존 도메인은 의존 도메인이 발의 도메인에서 발생할 수 있는 로그오프 이벤트에 등록하는 것을 허용한다. 사용자의 홈 도메인은 사용자에 대한 로그오프 이벤트를 발행할 것이고, 이 이벤트는 이러한 로그오프 이벤트에 등록된 모든 도메인에 의해 수신될 것이다. 따라서, 의존 도메인은 로그오프 이벤트가 특정 사용자와 관련있는지를 판정할 수 있고, 만일 로그오프 이벤트가 특정 사용자와 관련있다면, 의존 도메인은 사용자의 로그오프 또는 세션 탈퇴를 시행한다. 이 로그오프에 대한 최적의 방법은 의존 도메인이 특정 사용자에 대한 로그오프 이벤트에 대해서만 모든 로그오프 이벤트에 예의주시하지 않아도 되도록 더욱 정제된 로그오프 이벤트, 즉 그 특정 사용자를 지정하는 로그오프 이벤트에 등록하는 것을 허용하는 것이다.

이제 도 7a 및 도 7b를 참조하면, 한 쌍의 흐름도는 발행/등록 모델을 이용하는 SOAP 방법에 의해 연합 도메인에서 통합 로그오프 동작을 실행하는 한 쌍의 프로세스를 나타내고 있다. 도 7a 및 도 7b에 나타낸 프로세스는 연합 단일 서명 동작이 의존 도메인의 사용자 대신에 이미 완료되었다는 것과, 의존 도메인이 사용자에 대한 로그오프 이벤트에 등록하였다는 것을 가정하고 있다. 예컨대, 의존 도메인의 접점 서버는 의존 도메인의 인커밍 요청과 함께 발의 도메인의 접점 서버로부터 인증 주장을 수신한다. 의존 도메인에서 발생하는 프로세싱의 일부로서, 의존 도메인의 신뢰 프록시는 사용자에 대한 로그오프 이벤트에 등록할 것이다. 도 3b의 단계 332를 참조하면, 의존 도메인의 신뢰 프록시가 발의 도메인으로부터의 주장을 확인한 후, 신뢰 프록시는 등록 동작을 개시할 것이다. 즉, 신뢰 프록시는 로그오프 이벤트에 포함될 식별자가 발의 도메인에 의해 발행되는 식별자이기 때문에, 의존 도메인에서의 로컬 유효 식별자가 아닌, 발의 도메인으로부터 수신된 사용자 식별자를 이용할 것이다.

도 7a에 나타낸 프로세스는 발의 도메인에서 발생하고, 도 7b에 나타낸 프로세스는 의존 도메인에서 발생한다. 이제 도 7a를 참조하면, 프로세스는 사용자가 사용자의 홈 도메인과 같은 발의 도메인에서 로그오프 이벤트를 개시하는 것에서부터 시작한다(단계 702). 발의 도메인의 접점 서버는 발의 도메인의 신뢰 프록시에 통지하고(단계 702), 신뢰 프록시는 발의 도메인의 사용자 세션 동안 사용자에 대해 발행된 모든 토큰을 결정한다(단계 706). 발행된 각 토큰마다, 발의 도메인의 신뢰 프록시는 발행된 각 토큰마다 로그오프 통지정보를 갖는 SOAP 발행 메시지를 발생시켜(단계 708), 프로세스는 완료된다.

이제 도 7b를 참조하면, 프로세스는 의존 도메인의 신뢰 프록시가 사용자에 대한 로그오프 메시지를 수신하는 것에서부터 시작한다(단계 712). 의존 도메인의 신뢰 프록시는 로그오프 메시지 내의 수신 토큰에 기초하여 사용자에 대한 로컬 보안 토큰을 생성한다(단계 714). 다음에, 의존 도메인의 신뢰 프록시는 의존 도메인의 접점 서버로부터 사용자 대신에 로그오프 동작을 개시하고(단계 716), 프로세스는 완료된다. 이와 달리, 의존 도메인의 신뢰 프록시가 세션 관리를 실행하는 경우에는, 의존 도메인의 신뢰 프록시는 사용자의 세션을 적절한 방식으로 종료시켜 로그오프 동작을 완료시킬 것이다.

다시 도 4를 참조하면, 연합 환경의 일례는 사용자가 통합 로그오프 동작을 실행하는 방식을 설명하는데 이용된다. 도 4에 대한 상기 개시내용은 사용자(400)가 도메인(420 및 430)의 세션을 확립하는 연합 단일 서명 동작을 완료시키는 방식을 설명한다. 이 예에서, 도메인(410)은 홈 도메인으로서 기능하고, 도메인(420 및 430)은 의존 도메인으로서 기능한다. 이하에서 이 예는 도 4의 개시내용의 후미에 이어 계속된다. 다시 말하면, 다음의 예는 사용자가 연합 단일 서명 동작을 이미 완료하여 통합 로그오프 동작의 완료를 진행한다고 가정한다.

이 시나리오에서, 사용자의 브라우저는 웹 서비스가 구동되지 않는, 즉 웹 서비스 클라이언트로서 기능하지 않는 것으로 가정될 수 있다. 이것은 사용자가 HTTP를 이용하여 연합체에 액세스하는 것을 암시한다. 연합체의 구성요소는 SOAP 또는 SOAP-over-HTTP를 이용하여 통신할 수 있다. 접점 서버와 신뢰 프록시간의 통신은 내부적으로, 즉 API를 이용하여 또는 SOAP를 통해 이루어질 수 있다.

다음의 시나리오는 도 5에 나타낸 프로세스를 따른다. 사용자(400)는 도메인(410)으로부터 로그아웃한다. 접점 서버(412)는 사용자(400) 대신에 단일 서명 토큰을 전송하는 모든 도메인 리스트를 유지한다. 도메인(410)의 사용자 세션을 종료하기 전에, 접점 서버(412)는 도메인(420)에서 사용자에 대한 로그오프 요청을 생성한다. 이와 같이 하기 위해, 접점 서버(412)는 신뢰 프록시(414)로부터 도메인(420)에서 유효한 사용자(400)에 대한 보안 토큰을 요청한다. 접점 서버(412)는 신뢰 프록시(414)로부터 수신된 토큰을 포함하는 도메인(420)의 로그오프 사용자(400)에 대한 요청을 작성하고, 이 토큰은 로그오프 요청을 사용자에게 사상시키는데 이용될 수 있다. 이것은 HTTP 시나리오에서는, 이러한 연결처리(binding)가 접점 서버(422)와의 사용자 세션의 일부이기도 할 것이므로, 덜 중요하다. 즉, 이것은 사용자에 대한 요청의 연결처리를 가능하게 하므로, SOAP 시나리오에서는 더욱 중요하다.

접점 서버(412)는 이 요청을 사용자의 브라우저를 통해 도메인(420)의 접점 서버(422)에 재지정한다. 접점 서버(422)는 요청을 수신하고, 도메인(420)에서 사용자에 대한 로그오프의 호출을 시도한다. 이것의 결과는 성공(사용자가 인증되었고, 이제, 모든 세션 정보가 삭제되도록 로그오프된다) 또는 실패(사용자가 유효 세션을 갖지 않았다) 또는 에러(사용자가 세션을 갖고 있지만, 경우에 따라서는 로그오프를 완료시킬 수 없다)가 있다. 접점 서버(422)는 상태 메시지를 사용자의 브라우저를 이용하여 HTTP 재지정을 통해 접점 서버(412)에 리턴시킨다. 다음에, 접점 서버(412)는 도메인(430)에서 사용자에 대한 로그오프 요청을 작성한다. 접점 서버(412)는 사용자의 브라우저를 통해 이 요청을 도메인(430)의 접점 서버(432)로 재지정한다. 접점 서버(432)는 요청을 수신하고 도메인(430)에서 사용자 에 대한 로그오프의 호출을 시도한다. 즉, 이것의 결과는 성공, 실패 또는 에러 중 하나가 될 것이다. 접점 서버(432)는 상태 메시지를 사용자의 브라우저를 이용하여 HTTP 재지정을 통해 접점 서버(412)에 리턴시킬 것이다.

사용자의 홈 도메인의 접점 서버(412)는 사용자의 브라우저에 리턴되는 로그오프 상태 메시지를 작성한다. 만일 도메인(420)과 도메인(430) 모두가 성공적인 상태 표시자를 리턴시키면, 접점 서버(412)는 도메인(410)에서 사용자에 대한 로그오프를 실행하고, 도 8a에 나타낸 메시지를 리턴시킨다. 연합 도메인들 중 하나 또는 그 이상이 성공적인 상태 표시자를 리턴시키지 않으면, 일실시예에서, 접점 서버(412)는 도메인(410)에서 사용자에 대한 로그오프를 실행하지 않는다. 그 대신에, 접점 서버(412)는 도 8b에 나타낸 메시지를 리턴시킨다.

이제 도 8a 및 도 8b를 참조하면, 하나의 연합체에서 통합 로그오프 동작으로부터의 상태 동작을 포함하는 그래픽 사용자 인터페이스(GUI) 윈도우가 나타나 있다. 도 8a를 참조하면, 윈도우(810)는 각 연합 도메인에 대해 통합 로그오프 도작의 상태를 나타낸다. 네임(812)은 사용자가 성공적으로 로그아웃된 도메인들을 나타낸다. 네임(814)은 사용자가 활성 세션을 갖지 않은 도메인들을 나타낸다. 예컨대, 홈 도메인은 한 도메인에서 사용자에 대한 연합 단일 서명 동작을 실행하였을 수도 있지만, 사용자는 계속해서 그 도메인으로부터 직접 로그아웃하였거나, 또는 미사용으로 인해 로그아웃됨으로써, 홈 도메인에, 사용자가 그 도메인에서 아직 활성 세션을 가질 것이라는 부정확한 표시를 남기게 된다. 네임(816)은 로그아웃 동작 동안 에러가 발생한 도메인들을 나타낸다.

통합 로그아웃 동작의 상태를 검토한 후, 사용자가 통합 로그오프 동작을 종결짓는 것에 대해 발생시켜야 할 것을 선택할 수 있도록 사용자에게 옵션이 제공된다. 이 예에서, 계속해서 사용자는 사용자가 홈 도메인으로부터 로그오프하고 싶어한다는 것을 나타내는 옵션(818)을 선택할 수 있다. 또한, 사용자는 통합 로그오프 동작 동안 에러와 마주치는 도메인으로 진행하는 옵션(820)을 선택할 수 있다.

다시 도 4를 참조하면, 연합 환경의 일례는 사용자가 도 6에 나타내는 프로세스에 따라 통합 로그오프 동작을 실행하는 방식을 설명하는데 이용된다. 사용자(400)는 로그오프 요청을 접점 서버(412)에 전송한다[또는 신뢰 프록시가 사용자가 사용자의 상태 정보를 전달하거나 유지하는 구성요소인 경우에는 신뢰 프록시(414)에 직접 전송한다]. 접점 서버(412)는 로그오프 요청을 작성하고, 이 세션에서 이 사용자에 대해 연합 단일 서명 토큰을 작성한 모든 도메인의 리스트 중 일부 분류를 유지하고 있는 신뢰 프록시(414)로부터 사용자에 대한 보안 토큰을 요청한다. 신뢰 프록시(414)는 이들 도메인의 각각에서 사용자에 대한 로그오프 요청을 작성하고, 이 요청을 도메인(420)의 신뢰 프록시(424)와 도메인(430)의 신뢰 프록시(434)에 전송한다. 수신측 신뢰 프록시, 예컨대 신뢰 프록시(424)는 로그오프 요청을 수신하고, 사용자 토큰을 확인하며, 로컬 사용자 토큰을 작성하고, 사용자에 대한 접점 서버(422)에서 로그오프 요청을 개시한다[또는 어느 구성요소가 세션 관리를 실행하는가에 따라 신뢰 프록시(424)에서 사용자의 세션을 종료한다].

다시 도 4를 참조하면, 연합 환경의 일례는 사용자가 도 7a 및 도 7b에 나타 내는 프로세스에 따라 통합 로그오프 동작을 실행하는 방식을 설명하는데 이용된다. 이 시나리오에서, 접점 서버(422)[또는 신뢰 프록시(424)]가 도메인(410)으로부터 사용자(400)에 대한 로그오프 요청을 수신한 경우, 신뢰 프록시(424)는 "로그오프 이벤트에의 등록"/"사용자(400)에 대한 로그오프 이벤트에의 등록"을 개시한다. 사용자가 도메인(410)에서 로그오프 이벤트를 개시한 경우, 접점 서버(412)는 로그오프 통지정보를 작성하여 신뢰 프록시(414)에 전송하고, 신뢰 프록시(414)는 이 세션 동안 사용자에 대해 발행한 모든 토큰을 결정하여 발행 토큰마다 로그오프 통지정보를 갖는 SOAP 발행 메시지를 작성한다.

예컨대, 연합 단일 서명 동작 동안 접점 서버(422)에서 수신된 토큰은 "토큰 A"라고 불리우고, 다른 연합 단일 서명 동작 동안 접점 서버(432)에서 수신된 토큰은 "토큰 B"라고 불리울 수 있다. 신뢰 프록시(414)는 로그오프 이벤트 및 "토큰 A"와 함께 SOAP 발행 메시지를, 그리고 로그오프 이벤트 및 "토큰 B"와 함께 SOAP 발행 메시지를 작성한다. 신뢰 프록시(424)는 "토큰 A"와 관련된 SOAP 로그오프 메시지에 등록하였을 것이고, 따라서 제1 메시지를 수신할 것이다. 신뢰 프록시(434)는 "토큰 B"와 관련된 SOAP 로그오프 메시지에 등록하였을 것이고, 따라서 제2 메시지를 수신할 것이다.

신뢰 프록시(424)가 로그오프 메시지를 수신한 경우, 신뢰 프록시(424)는 수신된 토큰에 기초하여 사용자에 대한 로컬 보안 토큰을 생성한다. 다음에, 신뢰 프록시(424)는 접점 서버(422)로부터 사용자 대신에 로그오프를 요청한다(또는, 세션이 신뢰 프록시에 유지되어 있다면 사용자에 대한 로컬 유지 세션으로부터의 오 르오프를 시도한다).

본 발명의 이점은 상술한 본 발명의 상세한 설명을 참조하여 명확해질 것이다. 종래 솔루션은 도메인이 강력한 신뢰 관계 및 내재적으로 호환가능한 기술을 요구하는 계층 구조로 도메인 보안 서비스를 구성한다. 다른 접근법은 인증 주장에 대하여 균일 포맷을 부과하거나 인증 주장의 전송이 가능하게 하며, 로컬 주장이 구축되는 인증 아이덴티티를 종종 전달한다.

본 발명의 이점 중에서, 신뢰 프록시는 주어진 도메인에서 기존의 보안 서비스가 동일한 신뢰 기반에 등록하거나 동일 신뢰 설정 기술을 사용할 필요없이 다른 도메인과의 신뢰 관계를 설정할 수 있게 한다. 따라서, 본 발명의 연합 아키텍처는 엔티티의 약한 결합을 제공한다. 홈 도메인은 인증을 관리하며, 각 도메인은 단지 자신의 등록 사용자의 인증을 관리한다. 각 도메인은 사용자 아이덴티티와 속성에 대한 임의의 다른 도메인의 문장을 자유롭게 허용, 거절 또는 변형한다. 의존 도메인은 아이덴티티와 속성의 발의 도메인의(궁극적으로는, 홈 도메인의) 주장에 의존하지만, 각 도메인은 임의의 인증 프로토콜을 구현할 수 있으며, 주어진 도메인 내의 애플리케이션은 이 도메인이 연합에 참가하기 위해서 이전에 지원하지 않은 프로토콜을 구현하도록 변형될 필요가 없다. 이 연합은 특정 신뢰 모델을 요구하지 않으며, 참여 엔티티가 이미 설정된 신뢰 모델에 부합하는 연합을 일련의 엔티티가 형성할 수 있다. 주장 번역은 신뢰 프록시 및/또는 신뢰 중재자에서만 발생하며, 연합 아키텍처는 기존 레거시 시스템에 최소한의 영향으로 구현될 수 있는 프런트 엔드 기반구조로서 동작한다.

연합은 사용자가 단일 서명 방식의 주어진 연합 내에서 상이한 사이트를 흠없이 횡단한다. 연합 참가자 사이에 설정된 신뢰 관계로 인해, 하나의 참가자는 사용자를 인증한 후 이 사용자에 대한 발의 당사자로서 동작할 수 있다. 다른 연합 파트너는 의존 당사자가 됨으로써, 이들은 사용자의 직접 관여 없이 발의 당사자에 의해 사용자에 대하여 제공된 정보에 의존한다. 사용자가 한 도메인으로부터 로그오프를 원하고, 그 도메인이 사용자에 대한 발의 도메인으로서 기능한 경우, 발의 도메인은, 사용자에 대한 활성 연합 단일 서명 세션을 갖는 모든 도메인이 로그오프 동작에 대해 통지받고 의존 도메인 내의 사용자 세션을 종료시킬 수 있도록 이들 의존 도메인에서 통합 로그오프 동작을 개시한다.

본 발명은 완전하게 동작하는 데이터 처리 시스템에 대하여 설명하지만, 당업자가 본 발명의 프로세스는 배치를 수행하는데 실제 사용되는 특정 유형의 신호 포함 매체에 관계없이 컴퓨터 판독가능 매체의 명령과 다양한 다른 형태로 배치될 수 있음을 이해할 것이라는 점을 주목하는 것은 중요하다. 컴퓨터 판독가능 매체의 예는, EPROM, ROM, 테이프, 페이퍼, 플로피 디스크, 하드 디스크 드라이브, RAM, 및 CD-ROM과 같은 매체와 디지털 및 아날로그 통신 링크와 같은 전송 유형의 매체를 포함한다.

원하는 결과를 야기하는 일관적인 단계 시퀀스의 방법으로 통상 고찰된다. 이들 단계는 물리적 양의 물리적 조작을 요구한다. 통상, 반드시 그렇지는 않지만, 이들 양은 저장, 전송, 조합, 비교, 및 조작될 수 있는 전기 또는 자기 신호의 형태를 취한다. 종종, 주로 일반 사용의 이유로 인해, 이들 신호를 비트, 값, 파 라미터, 아이템, 요소, 객체, 심볼, 캐릭터, 용어, 수치 등으로 불린다. 그러나, 모든 이 용어들 및 유사 용어들은 적절한 물리양에 관련되어야 하며 이들 양에 적용된 단지 편리한 라벨임을 인식하여야 한다.

본 발명의 설명은 단지 예시의 목적으로 제공되었으며 개시된 실시예에 한정적인 것은 아니다. 많은 변형 및 변경이 당업자에게 명백할 것이다. 이 실시예들은 본 발명의 원리와 이 실제 애플리케이션을 설명하고 당업자가 다른 고찰된 사용에 적합할 수 있는 다양한 변형으로 다양한 실시예를 구현하기 위해서 본 발명을 이해할 수 있게 한다.

Claims (36)

1. 분산 데이터 처리 시스템에서 사용자 세션을 관리하는 방법으로서,

   제1 도메인의 시스템에 대해 사용자를 로그오프시키는 결정에 응답하여, 인증 주장(authentication assertion)을 제공함으로써 상기 제1 도메인이 상기 사용자에 대한 로그온 동작을 개시한 도메인 리스트를 획득하는 단계와;

   상기 제1 도메인의 시스템에서 상기 도메인 리스트의 도메인마다, 상기 사용자에 대한 인증 주장을 포함하는 로그오프 요청 메시지를 생성하는 단계와;

   로그오프 요청 메시지를 상기 도메인 리스트의 각 도메인에 전송하는 단계

   를 포함하는 분산 데이터 처리 시스템에서의 사용자 세션 관리 방법.
2. 제1항에 있어서, 상기 사용자가 동작시키는 클라이언트로부터의 요청을 상기 제1 도메인의 시스템에서 수신하여 로그오프 동작을 개시하는 단계와;

   상기 사용자로부터의 요청에 기초하여 상기 사용자의 로그오프를 결정하는 단계를 더 포함하는 것인 분산 데이터 처리 시스템에서의 사용자 세션 관리 방법.
3. 제1항에 있어서, 상기 사용자는 상기 제1 도메인의 시스템에 있는 로그오프 자원에 액세스하는 것인 분산 데이터 처리 시스템에서의 사용자 세션 관리 방법.
4. 제1항에 있어서, 제2 도메인의 시스템으로부터의 로그오프 요청 메시지를 상 기 제1 도메인의 시스템에서 수신하여 상기 사용자에 대한 로그오프 동작을 개시하는 단계와;

   상기 제2 도메인의 시스템으로부터의 요청에 기초하여 상기 사용자에 대한 로그오프를 결정하는 단계를 더 포함하는 것인 분산 데이터 처리 시스템에서의 사용자 세션 관리 방법.
5. 청구항 5은(는) 설정등록료 납부시 포기되었습니다.

   제4항에 있어서, 로그오프 요청 메시지는 SOAP(Simple Object Access Protocol) 발행 메시지인 것인 분산 데이터 처리 시스템에서의 사용자 세션 관리 방법.
6. 청구항 6은(는) 설정등록료 납부시 포기되었습니다.

   제5항에 있어서, 상기 제1 도메인의 시스템은 로그오프 이벤트에 등록한 것인 분산 데이터 처리 시스템에서의 사용자 세션 관리 방법.
7. 청구항 7은(는) 설정등록료 납부시 포기되었습니다.

   제5항에 있어서, 상기 제1 도메인의 시스템은 상기 사용자에게 특정된 로그오프 이벤트에 등록한 것인 분산 데이터 처리 시스템에서의 사용자 세션 관리 방법.
8. 청구항 8은(는) 설정등록료 납부시 포기되었습니다.

   제1항에 있어서, 로그오프 요청 메시지는 연합 도메인의 접점 서버에 의해 생성되는 것인 분산 데이터 처리 시스템에서의 사용자 세션 관리 방법.
9. 제1항에 있어서, 로그오프 요청 메시지는 연합 도메인의 신뢰 프록시 서버에 의해 생성되는 것인 분산 데이터 처리 시스템에서의 사용자 세션 관리 방법.
10. 제1항에 있어서, 상기 제1 도메인의 접점 서버에서 로그오프 요청 메시지로부터 인증 주장을 추출하는 단계와;

    상기 추출된 인증 주장을 상기 제1 도메인의 신뢰 프록시에 전달하는 단계를 더 포함하는 것인 분산 데이터 처리 시스템에서의 사용자 세션 관리 방법.
11. 제10항에 있어서, 상기 추출된 인증 주장의 확인에 응답하여, 상기 제1 도메인에서 유효한 로컬 보안 토큰을 상기 접점 서버에 리턴시키는 단계를 더 포함하는 것인 분산 데이터 처리 시스템에서의 사용자 세션 관리 방법.
12. 제11항에 있어서, 상기 신뢰 프록시에서 상기 추출된 인증 주장을 확인 불능으로 결정하는 것에 응답하여, 신뢰 중재자에게 상기 추출된 인증 주장의 확인을 요청하는 단계를 더 포함하는 것인 분산 데이터 처리 시스템에서의 사용자 세션 관리 방법.
13. 제1항 내지 제12항 중 어느 한 항에 따른 방법의 각 단계를 수행하는 수단을 구비하는 사용자 세션 관리용 데이터 처리 시스템.
14. 데이터 처리 시스템에서, 제1항 내지 제12항 중 어느 한 항에 따른 방법의 각 단계를 수행하는 프로그램 코드를 포함하는 사용자 세션 관리용 프로그램을 기록한 컴퓨터 판독가능한 기록 매체.
15. 삭제
16. 삭제
17. 삭제
18. 삭제
19. 삭제
20. 삭제
21. 삭제
22. 삭제
23. 삭제
24. 삭제
25. 삭제
26. 삭제
27. 삭제
28. 삭제
29. 삭제
30. 삭제
31. 삭제
32. 삭제
33. 삭제
34. 삭제
35. 삭제
36. 삭제

Images