KR101572393B1 - 기존 브라우저 세션 내에서 리치 클라이언트 인증하기 - Google Patents

Abstract

사용자가 브라우저-기반 클라이언트로부터 웹-기판 또는 클라우드-기반 애플리케이션에 인증한다. 상기 브라우저-기반 클라이언트는 연관된 리치 클라이언트를 보유한다. 세션이 상기 브라우저-기반 클라이언트로부터 개시된 후 (그리고 크리덴셜이 획득된 후), 사용자는 상기 리치 클라이언트가 이용 가능한 것을 발견하고(discover) (상기 리치 클라이언트를 이용하여) 사용자를 상기 애플리케이션에 자동으로, 즉 추가적인 사용자 입력 없이, 인증하는 데 사용하기 위해 상기 크리덴셜(또는 새로운 크리덴셜)을 획득하게 할 수 있다. 애플리케이션 인터페이스는, 리치 클라이언트가 실행중인 것으로 감지되면 리치 클라이언트가 자동으로 인증되어야 하는지, 혹시라도 애플리케이션에 대한 리치 클라이언트의 액세스가 철회된다면 애플리케이션에 대한 리치 클라이언트의 액세스가 제한되어야 할지 그렇다면 어느 정도로 제한되어야 할지 등을 명시하는 것과 같은 리치 클라이언트 인증 동작(rich client authentication operation)을 사용자가 구성할 수 있는 디스플레이를 사용자에게 제공한다.

Description

기존 브라우저 세션 내에서 리치 클라이언트 인증하기{AUTHENTICATING A RICH CLIENT FROM WITHIN AN EXISTING BROWSER SESSION}

본 발명은 일반적으로 애플리케이션 보안에 관한 것이고, 구체적으로는 기존 웹 브라우저 세션 내에서 "리치 클라이언트(rich client)"를 위한 크리덴셜(credential)의 전달(passing) 또는 획득(obtaining)을 가능하게 하기 위한 방법에 관한 것이다.

웹-기반 또는 클라우드-기반 애플리케이션들과 소위 "리치(rich)" 클라이언트들을 통합하는 것은 선행 기술에서 알려져 있으며, 여기에서 "리치(rich)" 클라이언트는 (웹 애플리케이션 자체로부터 단지 웹 인터페이스를 내보내는 것(exporting)과는 대조적으로) 자신의 인터페이스를 지원하는 (클라이언트-서버 애플리케이션의) 클라이언트이다. "리치" 클라이언트는 통상적으로 브라우저-기반이 아니며, 때때로 "씩(thick)" (브라우저-기반 또는 "씬(thin)"과 비교하여) 클라이언트라 불린다. 리치 클라이언트의 예시로는 Lotus Notes®이 있으며, 이것은 이메일(email), 달력에 의한 일정관리(calendaring), 연락 관리(contact management), 및 인스턴트 메시징(instant messaging)을 제공한다. 리치 클라이언트는 사용자를 대신하여 액션들을 액세스하여 자동으로 수행하는 데 사용될 수 있다.

이런 종류의 많은 비-브라우저-기반(리치) 클라이언트 애플리케이션들은 또한 브라우저-기반(씬 클라이언트) 애플리케이션 대응물들(counterparts) 또는 특징들을 보유한다. 씬 클라이언트는 단순한 웹 브라우저와 로그인 페이지일 수 있다. 최종사용자가 단일 워크스테이션으로부터 이러한 다수 클라이언트들을 동시에 사용하기를 원할 경우 인증 서버에 따로따로 인증해야만 한다. 이러한 요건에 대한 보통의 접근법은 예를 들어 각 클라이언트마다 하나씩 다수 인터페이스들에 입력하는 암호(password)를 사용하는 것이다. 이러한 접근법은 사용자가 암호를 여러 번 입력해야 하기 때문에 사용자 친화적이지 않다. 더욱이, 사용자가 암호를 (각 클라이언트에) 로컬로 저장하는 경우, 다수의 복사본들이 저장된다는 점을 고려해볼 때 위해(compromise)의 위험이 증가한다. 또한, 사용자가 암호를 변경할 때, 다수의 장소들에서도 똑같이 변경돼야 한다. 물론, 사용자가 암호를 여러 번 입력해야 할 수밖에 없는 경우, 사용자가 취약한 암호를 선택할 가능성이 더 크다. 만일 웹-기반 또는 클라우드-기반 애플리케이션이 씬 클라이언트 접근법에 통상적인 암호-기반 인증을 지원하지 않는 (SAML 또는 OpenID와 같은) 단일 인증(single sign-on) 프로토콜을 사용하면 또 다른 문제가 발생한다. 그러한 경우에, 사용자는 씩 클라이언트와 씬 클라이언트 각각에 구별되는 종류의 인증 크리덴셜들과 기술들을 사용할 수밖에 없게 되고, 추가적인 비효율(inefficiencies)과 보안 위험이 대두된다.

사용자가 웹-기반 또는 클라우드-기반 애플리케이션의 세션 동안에 한 번만 인증을 하면 되는 기술을 제공할 수 있는 것이 바람직하며, 그렇지만 이 인증은 상기 사용자가 발견할(discover) 수 있는 연관된 리치 클라이언트에 전달되거나 달리 말하면 그 연관된 리치 클라이언트가 이용할 수 있게 만들어질 수 있다.

본 발명에 따르면, 사용자는 씬(브라우저-기반) 클라이언트로부터 웹-기반 또는 클라이드-기반 애플리케이션에 인증한다. 상기 클라이언트는 연관된 리치 클라이언트를 보유한다. 세션이 상기 브라우저-기반 클라이언트로부터 개시된 후 (그리고 크리덴셜이 획득된 후), 사용자는 상기 리치 클라이언트가 이용 가능한 것을 발견하고 (상기 리치 클라이언트를 이용하여) 사용자를 상기 애플리케이션에 자동으로, 즉 추가적인 사용자 입력 없이, 상기 애플리케이션에 인증하는 데 사용하기 위한 크리덴셜(또는 새로운 크리덴셜)을 획득하게 할 수 있다. 애플리케이션 인터페이스는, 리치 클라이언트가 실행중인 것으로 감지되면 리치 클라이언트가 자동으로 인증되어야 하는지, 혹시라도 애플리케이션에 대한 리치 클라이언트의 액세스가 철회된다면 애플리케이션에 대한 리치 클라이언트의 액세스가 제한되어야 할지 그렇다면 어느 정도로 제한되어야 할지 등을 명시하는 것과 같은 리치 클라이언트 인증 동작(rich client authentication operation)을 사용자가 구성할 수 있는 디스플레이를 사용자에게 제공한다.

한 실시 예에서, 상기 기술된 동작을 용이하게 하기 위해 제어 채널(a control channel)이 브라우저와 리치 클라이언트 사이에 설정되고, 리치 클라이언트는 HTTP 서버를 포함하도록 수정된다. HTTP 요청을 HTTP 서버에 대한 로컬호스트 접속상의 포트에 보냄으로써, 브라우저는 리치 클라이언트가 실행중인지를 결정하고 그렇다면 브라우저-기반 크리덴셜을 보낼 수 있다.

다른 실시 예에서, 제어 채널은 표준 운영체제 메커니즘들을 사용해서 구현된다. 구체적으로, 리치 클라이언트는 운영체제에 콘텐츠 유형(content type)을 등록하고 그 자체를 그 유형에 대한 핸들러(handler)로 설정한다. 리치 클라이언트 인증의 개시가 요구될 때, 브라우저는 애플리케이션에 HTTP 요청을 하여 새로운 크리덴셜을 요청한다. HTTP 응답은 등록된 콘텐츠 유형과 일치하는 마임 타입(mime type)을 갖는 크리덴셜을 포함한다. 그 다음에 새로운 크리덴셜이 운영체제를 통해 리치 클라이언트에 전해지고, 리치 클라이언트는 그것을 사용하여 애플리케이션에 인증한다.

위에 기술된 인증 방법은 장치(apparatus)에서 수행될 수 있다. 상기 장치는 프로세서, 및 실행될 때 상기 방법을 수행하는 컴퓨터 프로그램 명령들을 보유하는 컴퓨터 메모리를 포함한다.

또 다른 실시 예에서, 상기 인증 방법은 데이터 처리 시스템에서 사용하기 위한 컴퓨터 판독가능 매체 내 컴퓨터 프로그램 제품에 의해 수행된다. 상기 컴퓨터 프로그램 제품은 상기 데이터 처리 시스템에 의해 실행될 때 상기 방법을 수행하는 컴퓨터 프로그램 명령들을 보유한다.

앞에서 본 발명의 더 관련 있는 특징들의 일부를 개괄하였다. 이 특징들은 단지 예시적이라는 것을 이해해야 한다. 공개된 발명을 다른 방식으로 적용하거나 수정함으로써 기술될 바와 같이 다른 많은 이로운 결과들을 얻을 수 있다.

본 발명과 본 발명의 장점들의 더 완전한 이해를 위해, 다음과 같은 내용의 첨부하는 도면들과 함께 이어지는 기술들을 참조한다.
도 1은 예시적인 실시 예들의 예시적 특징들이 구현될 수 있는 분산 데이터 처리 환경의 예시적 블록도를 도시한다.
도 2는 예시적인 실시 예들의 예시적 특징들이 구현될 수 있는 데이터 처리 시스템의 예시적 블록도를 도시한다.
도 3은 본 발명의 기술이 구현되는 클라이언트 애플리케이션과 그것의 연관 웹-기반 또는 클라우드-기반 서버 애플리케이션을 예시한다.
도 4는 본 발명의 기본적인 동작 상황을 기술하는 프로세스 흐름도이다.
도 5는 본 발명에 따른 애플리케이션 인터페이스의 디스플레이 페이지이며 이 인터페이스로 사용자가 액세스 폴리시를 구성한다.
도 6은 애플리케이션 인터페이스의 디스플레이 페이지이며 이 인터페이스로 사용자가 리치 클라이언트 인증 동작을 개시하거나 또는 이전에 허가된 액세스를 철회한다.

이제 도면들을 참조하며 구체적으로 도 1과 도 2를 참조하면, 본 발명의 예시적 실시 예들이 구현될 수 있는 데이터 처리 환경들의 예시도들이 제공된다. 도 1과 도 2는 단지 예시일 뿐이며 본 발명의 요지의 특징들 또는 실시 예들이 구현될 수 있는 환경들과 관련하여 어떤 한정도 주장 또는 암시할 의도가 없다는 것을 인식해야 한다. 본 발명의 정신과 범위를 벗어나지 않고도 도시된 환경들에 대한 많은 수정들이 이루어질 수 있다.

이제 도면들을 참조하며, 도 1은 예시적 실시 예들의 특징들이 구현될 수 있는 예시적 분산 데이터 처리 시스템의 그림 표현을 도시한다. 분산 데이터 처리 시스템(100)은 예시적 실시 예들의 특징들이 구현될 수 있는 컴퓨터들의 네트워크를 포함한다. 분산 데이터 처리 시스템(100)은 적어도 하나의 네트워크(102)를 포함하며, 이것은 분산 데이터 처리 시스템(100) 내에서 함께 연결된 여러 디바이스들과 컴퓨터들 사이의 통신 링크들을 제공하는 데 사용되는 매체이다. 네트워크(102)는 유선(wire), 무선(wireless) 통신 링크들, 또는 광섬유 케이블들 같은 연결들을 포함할 수 있다.

도시된 예에서, 서버(104)와 서버(106)은 스토리지 유닛(108)과 함께 네트워크(102)에 연결된다. 또한, 클라이언트들(110, 112, 114)도 네트워크(102)에 연결된다. 이 클라이언트들(110, 112, 114)는 예를 들면 퍼스널 컴퓨터들, 네트워크 컴퓨터들, 또는 이와 유사한 것일 수 있다. 도시된 예에서, 서버(104)는 부트 파일들(boot files) 같은 데이터, 운영체제 이미지들(operating system images), 및 애플리케이션들을 클라이언트들(110, 112, 114)에 제공한다. 클라이언트들(110, 112, 114)는 도시된 예에서 서버(104)에 대한 클라이언트들이다. 분산 데이터 처리 시스템(100)은 추가 서버들, 클라이언트들, 및 도시되지 않은 기타 디바이스들을 포함할 수 있다.

도시된 예에서, 분산 데이터 처리 시스템(100)은 네트워크(102)를 갖는 인터넷이며, 서로 통신하기 위해 TCP/IP(Transmission Control Protocol/Internet Protocol) 묶음의 프로토콜들을 사용하는 네트워크들과 게이트웨이들의 전세계적 집합을 나타낸다. 인터넷의 중심에는 데이터와 메시지들을 라우트(route)하는 무수한 상업용, 정부용, 교육용 및 기타 컴퓨터 시스템들로 구성된, 주요 노드들 또는 호스트 컴퓨터들 사이의 고속 데이터 통신선들의 백본(backbone)이 있다. 물론, 분산 데이터 처리 시스템(100)은 예를 들어 인트라넷, 근거리 통신망(LAN), 광역 통신망(WAN), 또는 이와 비슷한 것과 같은 수많은 다른 종류의 네트워크들을 포함하도록 구현될 수도 있다. 위에서 말한 바와 같이, 도 1은 예시의 목적이 있을 뿐이며, 발명의 요지의 여러 실시 예들에 대한 아키텍처상의 한정을 의미하는 것은 아니며, 따라서, 도 1에 도시된 구체적인 엘리먼트들은 본 발명의 예시적 실시 예들이 구현될 수 있는 환경들과 관련하여 한정하는 것으로 간주되어서는 안 된다.

이제 도 2를 참조하면, 예시적 실시 예들의 특징들이 구현될 수 있는 예시적 데이터 처리 시스템의 블록도가 도시된다. 데이터 처리 시스템(200)은 도 1에 있는 클라이언트(110) 같은 컴퓨터의 예이며, 이 안에 본 발명의 예시적 실시 예들을 위한 프로세스들을 구현하는 컴퓨터 사용가능 코드 또는 명령들이 배치될 수 있다.

도 2를 참조하면, 예시적 실시 예들이 구현될 수 있는 데이터 처리 시스템의 블록도가 도시된다. 데이터 처리 시스템(200)은 도 1에 있는 서버(104) 또는 클라이언트(110) 같은 컴퓨터의 예이며, 이 안에 예시적 실시 예들을 위한 프로세스들을 구현하는 컴퓨터-사용가능 프로그램 코드 또는 명령들이 위치할 수 있다. 이 예시적 예에서, 데이터 처리 시스템(200)은 통신 패브릭(202)를 포함하며, 이것은 프로세서 유닛(204), 메모리(206), 지속성 스토리지(persistent storage)(208), 통신 유닛(210), 입력/출력(I/O) 유닛(212), 및 디스플레이(214) 사이에 통신을 제공한다.

프로세서 유닛(204)는 메모리(206)으로 로드될 수 있는 소프트웨어에 대한 명령들을 실행하는 역할을 한다. 프로세서 유닛(204)는 하나 또는 그 이상의 프로세서들의 세트일 수 있고 또는 구체적인 구현에 따라서는 멀티프로세서 코어일 수 있다. 또한, 프로세서 유닛(204)는 하나 또는 그 이상의 이종(heterogeneous) 프로세서 시스템들을 사용하여 구현될 수 있으며, 이 시스템들 내에서 메인 프로세서는 단일 칩(single chip)상에 2차 프로세서들이 있는 상태로 존재한다. 또 다른 예시로서, 프로세서 유닛(204)는 동일한 종류의 다중 프로세서들을 보유하는 대칭형 다중프로세서(SMP) 시스템일 수 있다.

메모리(206)과 지속성 스토리지(208)은 스토리지 디바이스들의 예이다. 스토리지 디바이스는 일시적인 기준(temporary basis) 및/또는 영구적인 기준(permanent basis)으로 정보를 저장하는 능력이 있는 하드웨어이다. 이 예들에서 메모리(206)은 예를 들어 랜덤 액세스 메모리 또는 기타 적합한 휘발성 또는 비휘발성 스토리지 디바이스일 수 있다. 지속성 스토리지(208)은 구체적인 구현에 따라서 여러 가지 형태를 취할 수 있다. 예를 들면, 지속성 스토리지(208)은 하나 또는 그 이상의 컴포넌트들 또는 디바이스들을 보유할 수 있다. 예를 들면, 지속성 스토리지(208)은 하드 드라이브, 플래시 메모리, 재기록가능 광 디스크, 재기록가능 자기 테이프, 또는 앞의 것들의 일부 조합일 수 있다. 지속성 스토리지(208)이 사용하는 매체(media)는 탈착형일 수 있다. 예를 들면, 지속성 스토리지(208)에 탈착형 하드 드라이브가 사용될 수 있다.

통신 유닛(210)은, 이 예들에서, 다른 데이터 처리 시스템들 또는 디바이스들과의 통신을 제공한다. 이 예들에서, 통신 유닛(210)은 네트워크 인터페이스 카드이다. 통신 유닛(210)은 물리적 통신 링크와 무선 통신 링크 중 하나 또는 둘 모두를 사용해서 통신을 제공할 수 있다.

입력/출력 유닛(212)는 데이터 처리 시스템(200)에 연결될 수 있는 다른 디바이스들과의 데이터 입력 및 출력을 가능하게 한다. 예를 들면, 입력/출력 유닛(212)는 키보드와 마우스를 통한 사용자 입력을 위한 연결을 제공할 수 있다. 또한, 입력/출력 유닛(212)는 프린터에 출력을 내보낼 수 있다. 디스플레이(214)는 정보를 사용자에게 디스플레이하는 메커니즘을 제공한다.

운영체제와 애플리케이션들 또는 프로그램들을 위한 명령들이 지속성 스토리지(208)에 배치될 수 있다. 이 명령들은 프로세서 유닛(204)에 의한 실행을 위해 메모리(206)으로 로드될 수 있다. 여러 실시 예들의 프로세스들은 컴퓨터 구현 명령들을 사용하여 프로세서 유닛(204)에 의해 수행될 수 있으며, 상기 컴퓨터 구현 명령들은 메모리(206) 같은 메모리에 배치될 수 있다. 이 명령들은 프로그램 코드, 컴퓨터-사용가능 프로그램 코드, 또는 컴퓨터-판독가능 프로그램 코드라 불리며 프로세서 유닛(204)에 있는 프로세서에 의해 판독 및 실행될 수 있다. 여러 실시 예들에 있는 프로그램 코드는 메모리(206) 또는 지속성 스토리지(208) 같은 여러 물리적 또는 유형의(tangible) 컴퓨터-판독가능 매체상에 구현될 수 있다.

프로그램 코드(216)은 선택적으로 탈착가능한 컴퓨터-판독가능 매체(218)상에 펑션 형태(functional form)로 배치되며, 프로세서 유닛(204)에 의한 실행을 위해 데이터 처리 시스템(200)으로 로드 또는 전송될 수 있다. 프로그램 코드(216)과 컴퓨터-판독가능 매체(218)은 이 예들에서 컴퓨터 프로그램 제품(220)을 형성한다. 한 예에서, 컴퓨터-판독가능 매체(218)은 지속성 스토리지(208)의 부분인 하드 드라이브 같은 스토리지 디바이스상에 전송을 위해서 지속성 스토리지(208)의 부분인 드라이브 또는 기타 디바이스로 삽입 또는 배치되는, 예를 들어, 광 디스크 또는 자기 디스크 같이 유형의(tangible) 형태일 수 있다. 유형의 형태로, 컴퓨터-판독가능 매체(218)은 데이터 처리 시스템(200)에 연결되는 하드 드라이브, 썸 드라이브, 또는 플래시 메모리 같은 지속성 스토리지의 형태를 취할 수도 있다. 유형의 형태의 컴퓨터-판독가능 매체(218)은 컴퓨터-기록가능 스토리지 매체로도 불린다. 일부 예들에서, 컴퓨터-기록가능 매체(218)은 탈착형이 아닐 수 있다.

이와는 달리, 프로그램 코드(216)은 컴퓨터-판독가능 매체(218)로부터 통신 링크를 통해서 통신 유닛(210)으로 및/또는 연결을 통해서 입력/출력 유닛(212)로 전송될 수 있다. 상기 통신 링크 및/또는 연결은 예시적 예들에서 물리적이거나 무선일 수 있다. 컴퓨터-판독가능 매체는 또한 프로그램 코드를 보유하는 통신 링크들 또는 무선 송신들 같은 무형의 매체 형태를 취할 수 있다. 데이터 처리 시스템(200)을 위해 예시된 여러 컴포넌트들은 여러 실시 예들이 구현될 수 있는 방식에 아키텍처상의 한정을 두는 것을 의도하지는 않는다. 여러 예시적 실시 예들은 데이터 처리 시스템(200)에 대하여 예시된 컴포넌트들에 더하여 또는 이들을 대신하는 컴포넌트들을 포함하는 데이터 처리 시스템에서 구현될 수 있다. 도 2에 도시된 다른 컴포넌트들은 도시된 예시적 예들로부터 다양할 수 있다. 한 예를 들자면, 데이터 처리 시스템(200)에 있는 스토리지 디바이스는 데이터를 저장할 수 있는 하드웨어 장치(apparatus)일 수 있다. 메모리(206), 지속성 스토리지(208), 및 컴퓨터-판독가능 매체(218)은 유형의 형태로 된 스토리지 디바이스들의 예이다.

또 다른 예에서, 버스 시스템은 통신 패브릭(202)를 구현하기 위해 사용될 수 있고 시스템 버스 또는 입력/출력 버스 같은 하나 또는 그 이상의 버스들로 구성될 수 있다. 물론, 버스 시스템은 적합한 종류의 아키텍처를 사용하여 구현될 수 있으며 상기 아키텍처는 이 버스 시스템에 접속된 여러 컴포넌트들 또는 디바이스들 사이의 데이터 전송을 제공한다. 또한, 통신 유닛은 모뎀 또는 네트워크 어댑터 같은, 데이터를 송신 및 수신하는 데 사용되는 하나 또는 그 이상의 디바이스들을 포함할 수 있다. 또한, 메모리는, 예를 들어, 통신 패브릭(202)에 존재할 수 있는 인터페이스 및 메모리 컨트롤러 허브에서 발견되는 것 같은 메모리(206) 또는 캐시일 수 있다.

본 발명의 동작들을 실행하기 위한 컴퓨터 프로그램 코드는 Java™, Smalltalk, C++이나 그와 유사한 것 같은 객체-지향 프로그래밍 언어와 "C" 프로그래밍 언어 또는 그와 유사한 언어들 같은 전통적 절차적 프로그래밍 언어들을 포함한 하나 또는 그 이상의 프로그래밍 언어들의 임의 조합으로 작성될 수 있다. 상기 프로그램 코드는 전적으로 사용자의 컴퓨터상에서, 부분적으로 사용자의 컴퓨터상에서, 독립형(stand-alone) 소프트웨어 패키지로, 부분적으로 사용자의 컴퓨터상에서 그리고 부분적으로 원격 컴퓨터상에서, 또는 전적으로 원격 컴퓨터나 서버상에서 실행될 수 있다. 마지막의 상황에, 원격 컴퓨터는 근거리 통신망(LAN) 또는 광역 통신망(WAN)을 포함한 모든 종류의 네트워크를 통해서 사용자의 컴퓨터에 연결될 수 있거나, 또는 상기 연결은 (예를 들어, 인터넷 서비스 제공자를 이용한 인터넷을 통해서) 외부 컴퓨터에 이루어질 수 있다.

이 기술분야에서 통상의 지식을 가진 자들은 도 1과 도2의 하드웨어가 구현에 따라서 변할 수 있다는 것을 인식할 수 있을 것이다. 플래시 메모리, 등가의 비휘발성 메모리, 또는 광 디스크 드라이브들 등 같은 다른 내부 하드웨어 또는 주변 디바이스들이 도 1과 도 2에 도시된 하드웨어에 더해서 또는 대신하여 사용될 수 있다. 또한, 예시적 실시 예들의 프로세스들은, 본 발명의 요지의 정신과 범위를 벗어나지 않고도, 앞서 언급한 SMP 시스템 외에 다중프로세서 데이터 처리 시스템에도 응용될 수 있다.

보면 알 수 있듯이, 본 출원에서 기술되는 기술들(techniques)은, 클라이언트 머신들이 일 세트의 하나 또는 그 이상의 머신들에서 실행되는 인터넷-접속가능 웹-기반 포털과 통신하는, 도 1에 예시된 것과 같은 표준 클라이언트-서버 패러다임과 협력하여 동작할 수 있다. 최종사용자들은 상기 포털과 접속하고 상호작용할 수 있는 인터넷-연결가능 디바이스들(예를 들어, 데스크탑 컴퓨터들, 노트북 컴퓨터들, 인터넷-가능 모바일 디바이스들 또는 이와 유사한 것)을 동작시킨다. 통상적으로, 각 클라이언트 또는 서버 머신은 하드웨어와 소프트웨어를 포함하는 도 2에 예시된 것 같은 데이터 처리 시스템이며, 이 엔티티들은 인터넷, 인트라넷, 엑스트라넷, 사설망, 또는 기타 모든 통신 매체 또는 링크를 통해서 서로 통신한다. 데이터 처리 시스템은 통상적으로 하나 또는 그 이상의 프로세서들, 운영체제, 하나 또는 그 이상의 애플리케이션들 및 하나 또는 그 이상의 유틸리티들을 포함한다. 상기 데이터 처리 시스템상의 애플리케이션들은, 무엇보다도 HTTP, SOAP, XML, WSDL, UDDI, 및 WSFL을 위한 지원을 포함하는(그러나 이에 한정되지 않음), 웹 서비스들을 위한 가본 지원(native support)을 제공한다. SOAP, WSDL, UDDI 및 WSFL에 관련된 정보는 이 표준들의 개발 및 유지관리를 담당하고 있는 월드 와이드 웹 컨소시엄(W3C)으로부터 얻을 수 있으며, HTTP와 XML에 관련된 추가 정보는 국제 인터넷 표준화 기구(IETF)로부터 얻을 수 있다. 이 표준들에 익숙한 것으로 전제한다.

잘 알려진 바와 같이, 그리고 추가적인 배경을 얘기하자면, 인증(authentication)은 사용자에 의해서 또는 사용자를 대신해서 제공되는 일 세트의 크리덴셜들을 검증하는 프로세스이다. 인증은 사용자가 알고 있는 어떤 것, 사용자가 가지고 있는 어떤 것, 또는 사용자가 누구인가 즉 사용자에 관한 어떤 물리적인 특성을 검증함으로써 달성된다. 사용자가 알고 있는 어떤 것은 사용자의 암호(password) 같은 공유 비밀(shared secret)을 포함하거나, 또는 사용자의 암호화 키(cryptographic key) 같은 특정한 사용자에게만 알려진 어떤 것을 포함할 수 있다. 사용자가 가지고 있는 어떤 것은 스마트카드나 하드웨어 토큰을 포함할 수 있다. 사용자에 관한 어떤 물리적인 특성은 지문(fingerprint)이나 망막의 맵(retinal map) 같은 생체 인증(biometric) 입력치를 포함할 수도 있다. 사용자는 통상적으로 자연인이라는 것에 유의해야 하지만(그러나 반드시 그렇지는 않음)), 사용자는 전산 자원(computational resource)을 사용하는 머신이나, 컴퓨팅 디바이스나, 또는 다른 종류의 데이터 처리 시스템일 수도 있다. 또한 사용자는 통상적으로 단일 고유 식별자를 소유한다는 것에 유의해야 하지만(반드시 그렇지는 않음), 어떤 경우들에는, 다수 고유 식별자들이 단일 사용자와 연관될 수 있다.

인증 크리덴셜은 여러 인증 프로토콜들에서 사용되는 일 세트의 시도/응답(challenge/response) 정보이다. 예를 들면, 사용자명(username)과 암호(password) 조합은 가장 익숙한 형태의 인증 크리덴셜들이다. 다른 형태의 인증 크리덴셜에는 여러 형태의 시도/응답 정보, 공개키 기반구조(PKI) 인증서(certificates), 스마트카드(smartcards), 생체 인증(biometrics) 등등이 포함된다. 통상적으로, 인증은 인증 서버나 서비스와의 인증 프로토콜 시퀀스의 일부로서 사용자에 의해 제출된다.

이제 기술되는 바와 같이, 도 3을 참조하면, 본 발명의 요지인 기술은 통상적으로 웹-기반 또는 클라우드-기반 애플리케이션이 클라이언트측 및 서버측 컴포넌트들을 포함하는 상황에서 구현된다. 클라이언트측 컴포넌트들은 이들과 연관된 웹 브라우저 또는 코드(예를 들어, 브라우저 플러그인, 애플릿, 또는 그와 유사한 것)(300), 비-브라우저-기반 클라이언트(302)를 포함하며, 이들 각각은 도 2와 관련하여 위에 기술된 바와 같이 클라이언트 머신(304)에서 실행된다. 예를 들면, 클라이언트 머신(304)는 프로세서(306), 컴퓨터 메모리(308), 및 운영체제(310)을 포함한다. 브라우저-기반 클라이언트는 본 출원에서 "씬" 클라이언트로 불릴 수도 있으며, 비-브라우저-기반 클라이언트는 "씩" 또는 "리치" 클라이언트라 불릴 수도 있다. 각각의 이러한 클라이언트 컴포넌트는 도 1에 도시된 바와 같이 서버 애플리케이션(312)를 포함하는 서버측 컴포넌트와 네트워크(314)를 통해서 상호 동작하도록 구성된다. 서버 애플리케이션(304)는 웹-기반 또는 클라우드-기반 중 하나일 수 있으며 또한 도 2에 도시된 바와 같이 하나 또는 그 이상의 머신들상에서 실행될 수 있다.

브라우저-기반 클라이언트(300)은 자신의 연관된 서버 애플리케이션(312)와의 설정된 인증 메커니즘을 보유한다. 이와 마찬가지로, 비-브라우저-기반 또는 "리치" 클라이언트(302)는 서버 애플리케이션(312)와의 설정된 인증 메커니즘을 보유한다. 이 인증 메커니즘들은 같거나 다를 수 있다. 위에 언급한 바와 같이, "리치" 클라이언트는 브라우저-기반이 아니다. 예시적 리치 클라이언트 애플리케이션은 Lotus Notes®이며, 이것은 이메일, 달력에 의한 일정관리, 연락 관리, 및 인스턴트 메시징을 제공하며, 그럼에도 리치 클라이언트들은 모든 클라이언트-서버 애플리케이션에서 구현될 수 있다. 이 예에서, 서버 애플리케이션(304)는 Domino® 데이터 서버이다. 물론, 이 예들은, 모든 웹-기반 또는 클라우드-기반 애플리케이션과 함께 구현될 수 있는, 발명의 요지를 한정할 의도가 있는 것은 아니다.

본 발명에 따르면, 제어 채널(316)은 한쪽에는 브라우저-기반 클라이언트(300)과 다른 한쪽에는 비-브라우저-기반 클라이언트(302) 사이에 설정된다. 제어 채널은 아래에 기술되는 바와 같이 이 컴포넌트들 사이에 정보를 보내는 데 사용된다. 한 실시 예에서, 제어 채널(316)은 로컬호스트 연결(318)을 사용해서 구현되며, 이 로컬호스트 연결을 통해서 브라우저-기반 클라이언트(300)이 리치 클라이언트와 연관된 HTTP 서버 인스턴스(320)과 통신한다. 이 실시 예에서 클라이언트(300)과 클라이언트(302) 사이의 통신은 통상적으로 HTTPS를 통해서 이루어지지만, 이것이 요건은 아니다. 다른 실시 예에서, 그리고 아래에 기술되는 바와 같이, 제어 채널은 운영체제(310) 그 자체를 사용하여, 예를 들어, 리치 클라이언트를 특정한 마임 타입에 대한 핸들러로서 등록하게 함으로써 구현된다. 제어 채널은 다른 방식들로도 구현될 수 있는데, 예를 들어, 공유 메모리 세그먼트로서, 프로세스 간 통신(IPC)으로, 네트워크 호출(network call)에 의해서, 파일(file)에 의해서, 또는 그와 유사한 것으로 구현될 수 있다. 제어 채널이 다른 클라이언트 프로세스들에 의해 관측이 되는 경우, 알려진 기술들을 사용하여 보안이 되어야 한다.

이제 도 4에 있는 프로세스 흐름과 관련하여 본 발명의 통상적인 동작 상황을 기술할 것이다. 단계(400)에서, 최종사용자는 브라우저(300)의 인스턴스를 열고, 통상적으로 상기 브라우저에서 제공된 SSL-보안 로그온 페이지에 사용자 식별자(UID)와 암호를 입력함으로써 서버 애플리케이션(312)에 인증한다. 그 결과, 브라우저는 상기 서버 애플리케이션에 의해 제공되는 연관된 크리덴셜(305)를 획득 및 저장한다. 이 동작은 단계(402)에 표시된 대로 사용자 세션 또는 "웹-기반 사용자 세션"을 설정한다. 그 결과, 사용자는 상기 웹-기반 또는 클라우드 기반 애플리케이션에 의해 허용된 바에 따라 하나 또는 그 이상의 액션들을 취할 수 있다. 본 발명에 따르면, 사용자 세션이 브라우저로부터 개시된 이후에(즉, 기존 웹 세션 동안에), 리치 클라이언트(302)가 발견되고 서버 애플리케이션(312)에 인증되며, 자동으로 그리고 최종사용자에게 추가적인 인증관련 정보를 입력할 것을 요구하지 않고 인증되는 것이 바람직하다. 다른 말로 하면, 리치 클라이언트 인증은 투명하게 ― 사실상 "비밀리에(under the covers)" ― 실행되지만, 상기 서버 애플리케이션이 기대하는 방식으로 실행된다. 그러나 최종사용자는 리치 클라이언트로부터 인증 동작과 연관된 일반적인 작업들을 수행할 필요는 없다. 최종사용자는 (브라우저-기반 접근법을 사용하여) 한 번 인증하고, 그 인증은 리치 클라이언트-기반 인증을 가능하게 하거나 용이하게 한다.

이 리치 클라이언트 자동적 로그온(자동-로그온) 동작은 다음과 같이 달성되는 것이 바람직하다. 사용자(또는 다른 것)가, 바람직하게는 아래에 기술되는 애플리케이션 인터페이스를 사용하여, 특정한 디스커버리 및 인증 동작들을 구성한다고 가정한다. 단계(404)에서, 리치 클라이언트를 이용하여 사용자가 서버 애플리케이션에 인증하기를 원하는지 결정하기 위한 검사가 수행된다. 만일 사용자가 서버 애플리케이션에 인증하기를 원하면, 디스커버리 단계(406)이 수행된다. 디스커버리 단계(406)은 어떤 리치 클라이언트(들)이 클라이언트 머신에서 실행 중인지 식별한다(그리고 그들 중 많은 수가 실행 중일 수 있다). 디스커버리 단계는 예를 들어 브라우저가 로컬호스트 연결을 통해서 하나 또는 그 이상의 요청들을 발행하게 하고 그 답으로 "상태(status)" 응답들을 수신하게 함으로써 능동적으로 수행되거나, 예를 들어 그러한 상태 정보를 브라우저가 이용 가능하게 하고 주문형으로(on-demand) 디스플레이 가능하게 함으로써 수동적으로 실행될 수 있다. 이와는 달리, 리치 클라이언트가 시작될 때, 이것의 실행 상태(state)는 사용자에게 어떤 방식으로, 예를 들어 청각적으로, 시각적으로 또는 그와 유사하게 단지 노출될 뿐이다. 디스커버리 프로세스의 성격은 구현에 달려있다. 사용될 수 있는 다른 디스커버리 기술들에는 리치 클라이언트가 HTTP 서버 인스턴스상에 포트를 열게 하는 것과 브라우저가 열린 포트(이것은 리치 클라이언트가 실행 중임을 나타냄)를 찾을 때까지 일 세트의 이용 가능한 포트들을 통해 반복하게 하는 것이 포함된다. IPC가 제어 채널로서 사용될 때, 운영체제 게시 메커니즘(operating system publish mechanism)을 사용하여 클라이언트가 실행 중이라는 통지(notification)를 제공할 수 있다. 이 예들은 한정의 의도가 없다.

디스커버리에 이어서, 루틴이 단계(408)에서 계속되고, 이 단계에서 리치 클라이언트는 서버 애플리케이션에 실제 인증을 수행하기 위한 크리덴셜을 획득한다. 한 실시 예에서, 이 크리덴셜은 애플리케이션 서버에 대한 브라우저-기반 인증 동안 획득한 크리덴셜(305)이다. 이 실시 예에서, 브라우저는 크리덴셜을 제어 채널을 통해서 리치 클라이언트로 단순히 보낸다. 다른 실시 예에서, 리치 클라이언트는 마임 콘텐츠 타입에 대하여 로컬 운영체제(예를 들어, x-application/rich-auth)에 핸들러로서 등록된다. 단계(408)에서, 브라우저는 HTTP 요청을 서버 애플리케이션에 발행하여 새로운 크리덴셜을 요청하며, 서버 애플리케이션으로부터의 HTTP 응답은 새로운 크리덴셜과, 연관된 마임 타입을 식별하는 헤더를 포함한다. 리치 클라이언트는 이 마임 타입에 대하여 핸들러로 등록되기 때문에, HTTP 응답(새로운 크리덴셜)은 운영체제 커널을 통해서 리치 클라이언트로 전달되고, 이 리치 클라이언트는, 명시적인 사용자 입력을 요구하지 않고 다시 한번, 인증하는 데 그것을 사용한다. 이 다른 실시 예에서, 제어 채널은 표준 OS 메커니즘들을 사용하고 그러므로 플랫폼-독립적이다. 단계(410)에서, 리치 클라이언트는 서버 애플리케이션에 인증을 완료하고 프로세스는 종료된다.

도 4에 도시된 하나 또는 그 이상의 단계들은 다른 순서로 실행될 수 있다. 하나 또는 그 이상의 단계들이 결합될 수도 있고, 대체 단계가 구현될 수도 있다.

리치 클라이언트가 서버 애플리케이션(312)에 인증하는 구체적인 방식은 본 발명의 특징이 아니다. 이 목적을 위해 알려진 기술들에는, 한정하지 않고, SAML-기반 인증(이 인증에서 서버는 SAML 표명(assertion)을 발행하고 이것은 그 다음에 리치 클라이언트로 전송되고, 이 리치 클라이언트는 상기 SAML 표명(assertion)으로 인증하거나 또는 그것을 다른 크리덴셜과 교환함), OAuth-기반 인증(이 인증에서 서버는 OAuth 토큰을 발행하고 이것이 리치 클라이언트에 의해 인증하는 데 사용됨), 일회성 토큰-기반 인증(이 인증에서 서버는 랜덤 임시값(random nonce)을 생성하고 이것은 서버측에 보관되고 사용자와 연관됨), 및 그와 유사한 인증이 포함된다.

제1 실시 예에서, 브라우저-기반 클라이언트(300)은 리치 클라이언트와 제어 채널을 통해서 직접 통신하고, 서버 애플리케이션과 로컬 HTTP 서버(리치 클라이언트와 제휴하여 실행함)는 다른 영역들에서 동작할 수 있다. 로컬 HTTP 서버는 리치 클라이언트에 부속물(adjunct)이거나, 리치 클라이언트와 통합될 수 있다. 따라서, 알려진 교차-영역(cross-domain) 통신 방법들(예를 들어, 스크립트 포함(script inclusion) 방법)을 사용하여 이 상호작용을 용이하게 해야 한다. 다른 변형 예에서는, 로컬 HTTP 서버를 사용하기보다는, 브라우저 플러그인 또는 서명된 애플릿(signed applet)을 사용하여 크리덴셜을 획득하고 리치 클라이언트 인증을 구현하기 위해 애플리케이션 서버와 상호작용할 수 있다.

도 5는 (도 3의) 대표적인 애플리케이션 인터페이스(322)를 예시하며 이 인터페이스로 사용자(또는 다른 사람이나 엔티티)가 동작을 구성할 수 있다. 이 인터페이스는 하나 또는 그 이상의 웹 페이지들로서 브라우저에 내보내질 수 있지만, 이것에 한정되지는 않는다. 대표적인 페이지(500)은 입력 필드(input fields), HTML 기입 폼(fill-in forms), 라디오 버튼(radio buttons), 및 그와 유사한 것 같은 일 세트의 구성 엘리먼트들을 노출한다. 그러므로, 예를 들면, 라디오 버튼(502)를 선택하면, 사용자는 웹 세션을 개시하자마자 모든 실행중인 리치 클라이언트들을 발견하도록 요청할 수 있다. 라디오 버튼(504)를 선택하면, 사용자는 요청에 따라 모든 실행중인 리치 클랑이언트들의 상태를 갱신하도록 선택할 수 있다. 사용자는 라디오 버튼을 선택함으로써 리치 클라이언트가 실행중인 것으로 감지될 때 자동으로 인증되도록 명시할 수 있다. 목록(506)에서 이용 가능한 옵션들을 사용하여, 사용자는 리치 클라이언트가 서버 애플리케이션과 어떻게 상호작용할 것인지에 대한 제약 또는 한정을 명시할 수 있다. 그러므로, 예를 들면, 상기 목록에는 하나 또는 그 이상의 옵션들이 노출될 수 있는데, 옵션의 예를 들면, 액세스는 "판독-전용(read-only)"임, 액세스는 명시되는 제한된 시간 동안 이용할 수 있음, 특정한 펑션들이나 애플리케이션 프로그래밍 인터페이스들(API들)만 이용 가능함, 등등이다. 이것들은 단지 대표적인 구성 옵션들이며, 이 기술 분야에서 통상의 지식을 가진 자는 다른 구성 옵션들도 원하는 대로 구현할 수 있다는 것을 인식할 수 있을 것이다. 상기 구성 인터페이스는 또한 일단 선택되면 사용자가 브라우저로부터 리치 클라이언트를 (만일 이 리치 클라이언트가 실행중이 아니라면) 직접 시작할 수 있게 하는 제어 기능을 제공할 수 있다. 이 인터페이스를 이용하여, 사용자는 리치 클라이언트가 서버 애플리케이션에 어떻게 인증되어야 하는가를 정의하는 "폴리시"를 구성한다. 이 옵션을 용이하기 하기 위해 일 세트의 디폴트 폴리시들이 사용자에게 노출될 수 있다. 상기 인터페이스의 실시 예가 기술되었지만, 하나 또는 그 이상의 다른 접근법들도 사용될 수 있으며, 예를 들어, 폴리시를 프로그램에 따라서 정의하는 커맨드 라인 인터페이스(command line interface) 등을 사용할 수 있다.

도 6은 상기 인터페이스의 디스커버리 페이지(600)을 예시한다. 이 페이지는 앞서 기술된 바와 같이 디스커버리 단계 후에 디스플레이 된다. 이 예에서, 디스커버리 동작(discovery operation)은 클라이언트 머신에서 실행중인 두 개의 리치 클라이언트(클라이언트1, 클라이언트2)를 식별하였고, 이 클라이언트들은 여기에서 아이콘들(602, 604)로 표현된다. 아이콘(602)는 그와 연관된 클라이언트1에 대하여 크리덴셜이 발행되었다는 표시(indication) 또는 시각 단서(visual cue)를 포함한다. 그 아이콘을 선택하면, 최종사용자는 클라이언트1의 인증을 무효화시킬 수 있는 기회를 (예를 들어, 개별적인 대화를 통해서) 부여 받을 수 있으며, 다른 예에서는, 아이콘(602)의 선택 자체가 리치 클라이언트 인증을 종료시킨다. 이 두 경우에, 리치 클라이언트로부터 서버 애플리케이션에 대한 액세스는 (크리덴셜을 무효화함으로써) 실질적으로 철회된다. 아이콘(604)를 선택하면, 최종사용자는 위에 기술된 바와 같이 크리덴셜을 획득하는 프로세스를 개시할 수 있으며, 따라서 클라이언트2는 서버 애플리케이션에/을 액세스하고 사용할 수 있다.

그러므로, 이 기술에 따르면, 사용자는 리치 클라이언트가 서버 애플리케이션에 자동으로, 그리고 상기 사용자에 의해 정의된 폴리시에 기초하여 인증하게 할 수 있다. 이 폴리시는 상기 크리덴셜이 특정한 시간 동안에만 발행되게 하거나, 또는 상기 애플리케이션의 일부에 액세스하는 데에만 사용되도록, 또는 그와 유사하게 명시할 수 있다. 사용자가 구성한 폴리시 하에서 다시 한번 액세스가 철회될 수 있다.

본 발명은 많은 장점이 있다. 주요 장점은 사용자가 웹-기반 또는 클라우드-기반 애플리케이션의 세션 동안에 (그리고 한 장소에서) 한 번만 인증하면 된다는 점이다. 기술된 기술을 사용하여, 이 인증은 사실상 연관된 리치 클라이언트가 애플리케이션에 액세스할 수 있게 하는 데 사용된다. 또 다른 장점은 리치 클라이언트에 의한 위와 같은 액세스가 사용자-구성(user-configured) 폴리시에 따라서 맞춤형으로 될 수 있고, 사용자는 원하면 리치 클라이언트에 의한 위와 같은 액세스를 철회할 수 있다. 디스커버리 특징을 사용하여, 사용자는 로컬에서 실행중인 리치 클라이언트들을 보고 서버 애플리케이션(또는 다른 엔티티)에 크리덴셜(또는 토큰, 또는 그와 유사한 것)을 발행하도록 요청함으로써 리치 클라이언트들을 인증하며, 이 크리덴셜은 리치 클라이언트에 의해 사용자를 상기 애플리케이션에 인증하는 데 사용된다. 상기 기술은 기존 브라우저-기반 크리덴셜을 리치 클라이언트에 전달하기 위한, 또는 리치 클라이언트가 새로운 크리덴셜을 획득할 수 있게 하기 위한, 몇 가지 로컬 메커니즘들을 제공한다.

상기 기술은 모든 리치 클라이언트에 사용될 수 있으며, 그 클라이언트가 서버 애플리케이션에 어떻게 인증하는가 하고는 관계가 없다.

한 기술된 실시 예에서, 상기 기술은 (브라우저-기반) 클라이언트 애플리케이션 크리덴셜을 브라우저 애플리케이션과 연관된 대응(counterpart) 비-브라우저 프로세스에 자동 및 직접 전달할 수 있게 해준다. 이 솔루션은 기존 웹-기반 사용자 세션 내에서 리치 클라이언트를 개시하기를 원할 경우 사용자가 그 리치 클라이언트에 로그온해야만 하는 것을 없애준다.

본 출원에서 사용될 때, "크리덴셜(credential)"은 서버 애플리케이션에 대한 액세스를 용이하게 하는 모든 크리덴셜, 토큰, 데이터 세트 또는 데이터를 나타낸다는 것으로 넓게 해석되어야 한다. 위에서 언급한 바와 같이, 클라이언트(브라우저-기반이든 또는 리치 클라이언트든)는 자신의 연관된 서버 애플리케이션과의 설정된 인증 메커니즘을 보유하며, 본 발명의 기술은 관련된 시맨틱스(semantics)와 통신 프로토콜들에 따른다.

본 발명의 자동-로그인 솔루션은 브라우저-기반 클라이언트와 그와 연관된 리치 클라이언트 사이에 고유한 상호작용을 제공하며, 이 둘은 웹-기반 또는 클라우드-기반 서버 애플리케이션과 연관되는 것이 바람직하다. 상기 솔루션은 브라우저-기반 클라이언트와 서버 애플리케이션 사이의 기존 사용자 세션이 설정된 것으로 가정하며, 다른 말로 하면, 최종 사용자가 서버 애플리케이션에 로그인할 때 크리덴셜이 사전에 생성되었다고 가정한다.

한정할 의도는 없지만, 대표적인 실시 예에서, 서버 애플리케이션은 (IBM® WebSphere® 서버 같은) 애플리케이션 서버를 실행하며, 이는 통상적으로 J2EE-준수 서블릿(servlets)의 형태로 하나 또는 그 이상의 서버-기반 코드 펑션들에 대한 지원을 포함한다.

위에서 기술된 기능들은 독립형(standalone) 접근법(예를 들어, 프로세서에 의해 실행되는 소프트웨어-기반 펑션)으로서 구현되거나, 또는 (SOAP/XML 인터페이스를 통한 웹 서비스를 포함한) 관리 서비스(managed service)로서 이용할 수도 있다. 본 출원에 기술된 구체적인 하드웨어 및 소프트웨어 구현 상세사항들은 단지 예시의 목적이며 기술된 발명의 요지의 범위를 한정할 의도가 있는 것은 아니다.

더 일반적으로, 본 발명의 요지의 맥락 내에 있는 컴퓨팅 디바이스들은 각각 하드웨어 및 소프트웨어를 포함하는 (도 2에 도시된 바와 같은) 데이터 처리 시스템이고, 이 엔티티들은 인터넷, 인트라넷, 엑스트라넷, 사설망, 또는 다른 통신 매체 또는 링크 같은 네트워크를 통해서 서로 통신한다. 데이터 처리 시스템상의 애플리케이션들은, 무엇보다도 HTTP, FTP, SMTP, SOAP, XML, WSDL, UDDI, 및 WSFL에 대한 지원을 포함한(그러나 이에 한정되지 않음), 웹(Web) 및 다른 알려진 서비스들과 프로토콜들에 대한 가본 지원(native support)을 제공한다. SOAP, WSDL, UDDI 및 WSFL에 관련된 정보는 이 표준들의 개발 및 유지관리를 담당하고 있는 월드 와이드 웹 컨소시엄(W3C)으로부터 얻을 수 있으며, HTTP, FTP, SMTP, 및 XML에 관련된 추가 정보는 국제 인터넷 표준화 기구(IETF)로부터 얻을 수 있다. 이 알려진 표준들과 프로토콜들에 익숙한 것으로 전제한다.

본 출원에 기술된 리치 클라이언트 자동-로그인 스킴은 단순 n-계층 아키텍처들, 웹 포털들, 연합 시스템들(federated systems), 및 그와 유사한 것을 포함하는 여러 서버측 아키텍처들에서 또는 이들과 협력하여 구현될 수 있다. 애플리케이션 서버 컴포넌트는 하나 또는 그 이상의 백-엔드(back-end) 애플리케이션들의 영역과는 과는 다른 영역에 배치될 수 있고, 그러므로, 본 출원의 기술들은 느슨한-결합 서버("클라우드"-기반을 포함) 환경에서 실시될 수 있다. 애플리케이션 서버 자체는 클라우드에 호스트될 수 있다.

좀 더 일반적으로, 본 출원에 기술된 발명의 요지는 전적으로 하드웨어 실시 예, 전적으로 소프트웨어 실시 예 또는 하드웨어와 소프트웨어 엘리먼트들을 보유한 실시 예의 형태를 취할 수 있다. 바람직한 실시 예에서, 펑션은 소프트웨어로 구현되며, 여기에는 펌웨어, 상주 소프트웨어, 마이크로 코드 및 그와 유사한 것이 포함되나 이에 한정되지는 않는다. 또한, 위에서 언급한 바와 같이, 자동-로그인 기능은 컴퓨터 또는 명령 실행 시스템에 의해 또는 이와 연결하여 사용하기 위한 프로그램 코드를 제공하는 컴퓨터-사용가능 혹은 컴퓨터-판독가능 매체로부터 액세스할 수 있는 컴퓨터 프로그램 제품의 형태를 취할 수 있다. 이 설명의 목적을 위해서, 컴퓨터-사용가능 혹은 컴퓨터-판독가능 매체는 명령 실행 시스템, 장치 혹은 디바이스에 의해 또는 이와 연결하여 사용하기 위한 프로그램을 보유 또는 저장하는 임의 장치(apparatus)일 수 있다. 상기 매체는 전자, 자기, 광(optical), 전자기, 적외선, 또는 반도체 시스템(또는 장치 혹은 디바이스)일 수 있다. 컴퓨터-판독가능 매체의 예로는 반도체 혹은 고체상태 메모리, 자기 테이프, 탈착형 컴퓨터 디스켓, 랜덤 액세스 메모리(RAM), 판독-전용 메모리(ROM), 강성 자기 디스크(rigid magnetic disk) 및 광 디스크(optical disk)가 포함된다. 현재의 광 디스크의 예로는 콤팩트 디스크-판독 전용 메모리(CD-ROM), 콤팩트 디스크-판독/기록(CD-R/W) 및 DVD가 포함된다. 컴퓨터-판독가능 매체는 유형의 물품이다.

컴퓨터 프로그램 제품은 하나 또는 그 이상의 기술된 펑션들을 구현하기 위한 프로그램 명령들(또는 프로그램 코드)을 보유한 제품일 수 있다. 상기 명령들 또는 코드는 원격 데이터 처리 시스템으로부터 네트워크를 통해서 다운로드된 후에 데이터 처리 시스템 내의 컴퓨터 판독가능 스토리지 매체에 저장될 수 있다. 또는, 상기 명령들 또는 코드는 서버 데이터 처리 시스템 내의 컴퓨터 판독가능 스토리지 매체에 저장되어 원격 데이터 처리 시스템 내의 컴퓨터 판독가능 스토리지 매체에서 사용하기 위해 상기 원격 데이터 처리 시스템에 네트워크를 통해서 다운로드 되도록 구성될 수 있다.

대표적인 실시 예에서, 클라이언트 및 서버 컴포넌트들은 기술된 바와 같이 특수 목적 컴퓨터에서 구현되며, 하나 또는 그 이상의 프로세서들에 의해 실행되는 소프트웨어에서 구현되는 것이 더 바람직하다. 상기 소프트웨어는 상기 하나 또는 그 이상의 프로세서들과 연관된 하나 또는 그 이상의 데이터 저장영역들(stores) 또는 메모리들에서 유지관리되며, 상기 소프트웨어는 하나 또는 그 이상의 컴퓨터 프로그램들로 구현될 수 있다. 종합적으로, 이 특수-목적 하드웨어 및 소프트웨어는 리치 컴포넌트 자동-로그인 기능들을 제공하는 컴포넌트들을 포함한다.

기술된 펑션(들)은 기존 애플리케이션 서버 펑션 또는 동작에 대한 부속 또는 확장 펑션(들)로 구현될 수 있다.

위에서는 본 발명의 특정 실시 예들에 의해 수행되는 동작들의 구체적인 순서를 기술하고 있지만, 그러한 순서는 예시일 뿐이며, 다른 실시 예들은 상기 동작들을 다른 순서로 수행하거나, 특정한 동작들을 결합하거나, 특정한 동작들을 중첩시키는 등의 방식으로 수행할 수 있다는 것을 이해해야 한다. 주어진 실시 예에 대한 명세서의 참조번호들은 기술된 실시 예가 구체적인 특징, 구조, 또는 특성을 포함할 수 있다는 것을 나타내지만, 모든 실시 예가 그 구체적인 특징, 구조, 또는 특성을 포함할 필요가 있는 것은 아니다.

마지막으로, 시스템의 주어진 컴포넌트들은 따로따로 기술되었지만, 이 기술분야에서 통상의 지식을 가진 자는 펑션들의 일부는 주어진 명령들, 프로그램 시퀀스들, 코드 부분들, 및 그와 유사한 것에서 결합 또는 공유될 수 있다는 것을 인식할 수 있을 것이다.

"브라우저"는 본 출원에서 사용될 때 특정한 브라우저(예를 들어, 인터넷 익스플로러, 사파리, 파이어폭스, 또는 그와 유사한 것)를 나타낼 의도가 있지 않으며, 인터넷-액세스 가능 리소스들을 액세스 및 디스플레이할 수 있는 모든 클라이언트측 렌더링 엔진(rendering engine)을 나타내는 것으로 넓게 해석되어야 한다. 또한, 통상적으로 클라이언트-서버 상호작용은 위에서 언급한 바와 같이 HTTP를 이용하여 이루어지며 이에 한정되지는 않는다. 클라이언트 서버 상호작용은 단순 객체 접근 프로토콜(SOAP)을 준수하고 HTTP를 통해서(공공 인터넷을 통해서) 이동하도록 포맷될 수 있고, FTP나 기타 다른 신뢰성 있는 전송 메커니즘(예를 들어, IBM® MQSeries® 기술과 기업용 인트라넷을 통한 전송을 위한 CORBA)이 사용될 수도 있다. 또한, "웹 사이트(web site)" 또는 "서비스 제공자"라는 말은 웹 사이트(일 세트의 링크된 웹 페이지들), 주어진 웹 사이트 또는 서버에 있는 도메인, 서버나 서버들의 세트들과 연관된 신뢰 도메인, 또는 그와 유사한 것을 포괄하는 것으로 넓게 해석되어야 한다. "서비스 제공자 도메인"은 웹 사이트 또는 웹 사이트의 일 부분을 포함할 수 있다. 본 출원에 기술된 애플리케이션 또는 기능들은 원시 코드(native code)로서 구현될 수 있는데, 그 방법은 또 다른 애플리케이션으로 후크(hook)들을 제공함으로써, 상기 메커니즘을 플러그-인으로 사용하도록 용이하게 함으로써, 상기 메커니즘에 링크시킴으로써, 및 그와 유사게 함으로써 구현될 수 있다.

언급된 바와 같이, 위에 기술된 리치 클라이언트 자동-로그인 펑션은 모든 시스템, 디바이스, 포털, 사이트, 또는 그와 유사한 것에서 사용될 수 있으며, 여기에서 비-브라우저 기반 클라이언트 애플리케이션 크리덴셜은 연관된 브라우저 프로세스에 전해져야 한다. 더 일반적으로, 상기 기술된 기술은 (크리덴셜 데이터를 포함한, 그러나 이에 한정되지 않는) 주어진 정보가 클라이언트 애플리케이션에서부터 연관된 브라우저 프로세스까지 자동화된 방식으로 지속되기를 원하는 모든 운영 환경에서 사용될 수 있도록 설계된다.

위에서 기술된 실시 예는 기존 브라우저 세션 내에서 리치 클라이언트를 인증하는 것을 제공하지만, 이 기본 기술은 또한 리치 클라이언트가 웹 애플리케이션에 인증되고 기존 크리덴셜을 씬 클라이언트에 보내길 원하는 상황에서도 구현 가능하다. 이 상황에서, 그리고 리치 클라이언트는 씬 클라이언트에 의한 (애플리케이션에 대한) 액세스가 허용되도록 보장할 방법을 가졌다면, 제어 채널은 리치 클라이언트와 이용 가능한 브라우저-기반 클라이언트 사이에서 인에이블 된다. 리치 클라이언트에 의해 획득된 크리덴셜은 그 다음에 브라우저-기반 클라이언트에 보내져서 사용자가 인증될 수 있게 해준다.

서버 애플리케이션은 서비스, 서버, 애플리케이션 프로그램, 프로세스, 페이지(예를 들어, 위키(wiki), 웹 페이지 등), 파일, 연결 객체(linked object), 디렉토리, 또는 그와 유사한 것에 대한 액세스를 가능하게 한다. 본 발명을 기술하였으며, 청구하는 내용은 다음과 같다.

Claims (28)

1. 서버 애플리케이션에 대한 인증된 사용자의 액세스 방법에 있어서, 상기 방법은:
   서버 애플리케이션으로 웹 세션(web-session)을 개시하기 위해(initiate) 브라우저-기반 클라이언트에서(in a browser-based client) 사용자 입력을 수신하는 단계;
   상기 브라우저-기반 클라이언트에서(at the browser-based client) 크리덴셜(a credential)을 수신하는 단계;
   상기 서버 애플리케이션과 상호작용할 수 있는 리치 클라이언트(rich client)를, 상기 웹 세션 내에서, 식별하는 단계;
   상기 리치 클라이언트에 크리덴셜(a credential)을, 상기 웹 세션 내에서, 제공하는 단계 ― 상기 크리덴셜은: 상기 브라우저-기반 클라이언트에서 수신된 크리덴셜, 및 상기 서버 애플리케이션으로부터 수신된 새로운 크리덴셜 중 하나임 ―; 및
   상기 리치 클라이언트를 사용하여 상기 서버 애플리케이션에 대해 상기 사용자를 인증하기 위해 상기 리치 클라이언트에 제공된 크리덴셜을, 상기 웹 세션 내에서, 사용하는 단계;를 포함하되,
   상기 수신하는 단계, 식별하는 단계, 제공하는 단계 및 사용하는 단계들 중 적어도 하나는 하드웨어 엘리멘트 내에서 실행하는 소프트웨어로 수행되는,
   방법.
2. 제1항에 있어서, 상기 리치 클라이언트를 식별하는 단계는 로컬에서 실행중인 하나 또는 그 이상의 리치 클라이언트들의 동작 상태(operating state)를 결정하기 위해 디스커버리 동작(discovery operation)을 개시하는 단계를 포함하는,
   방법.
3. 제2항에 있어서, 상기 방법은:
   로컬에서 실행중인 하나 또는 그 이상의 리치 클라이언트들을 표시하는 디스플레이를 상기 사용자에게 제공하는 단계; 및
   상기 크리덴셜을 제공받을 리치 클라이언트를 식별하는 선택을 상기 사용자로부터 수신하는 단계를 더 포함하는,
   방법.
4. 제1항에 있어서, 상기 브라우저-기반 클라이언트와 상기 리치 클라이언트 사이에 제어 채널을 설정하는 단계를 더 포함하는
   방법.
5. 제4항에 있어서, 상기 제어 채널을 사용하여 상기 리치 클라이언트에게 상기 크리덴셜을 제공하는 단계를 더 포함하는
   방법.
6. 제1항에 있어서, 상기 리치 클라이언트에 제공되는 크리덴셜은 상기 서버 애플리케이션과 관련하여 적어도 하나의 액세스 제한(access restriction)을 정의하는 폴리시와 연관되는,
   방법.
7. 삭제
8. 제1항에 있어서, 상기 리치 클라이언트에 제공된 크리덴셜을 무효화하는 단계를 더 포함하는
   방법.
9. 서버 애플리케이션에 대한 인증된 사용자의 액세스를 제공하는 장치(apparatus)에 있어서, 상기 장치는:
   프로세서; 및
   상기 프로세서에 의해 실행될 때 한 방법을 수행하는 컴퓨터 프로그램 명령들을 보유하는 컴퓨터 메모리를 포함하되, 상기 방법은:
   서버 애플리케이션의 웹 세션을 개시하기 위해 브라우저-기반 클라이언트에서(in a browser-based client) 사용자 입력을 수신하는 단계;
   상기 브라우저-기반 클라이언트에서 크리덴셜을 수신하는 단계;
   상기 서버 애플리케이션과 상호작용할 수 있는 리치 클라이언트를, 상기 웹 세션 내에서, 식별하는 단계;
   상기 리치 클라이언트에 크리덴셜(a credential)을, 상기 웹 세션 내에서, 제공하는 단계 ― 상기 크리덴셜은: 상기 브라우저-기반 클라이언트에 수신된 크리덴셜, 및 상기 서버 애플리케이션으로부터 수신되는 새로운 크리덴셜 중 하나임 ―; 및
   상기 리치 클라이언트를 사용하여 상기 서버 애플리케이션에 대해 상기 사용자를 인증하기 위해 상기 리치 클라이언트에 제공된 크리덴셜을, 상기 웹 세션 내에서, 사용하는 단계를 포함하는,
   장치.
10. 삭제
11. 삭제
12. 삭제
13. 삭제
14. 삭제
15. 삭제
16. 삭제
17. 서버 애플리케이션에 대한 인증된 사용자의 액세스를 제공하기 위해 데이터 처리 시스템에 의해 실행될 때 한 방법을 수행하는 컴퓨터 프로그램 명령들을 보유하고 상기 데이터 처리 시스템에서 사용하는 비-일시적인 컴퓨터 판독가능 매체에 있어서, 상기 방법은:
    서버 애플리케이션의 웹 세션을 개시하기 위해 브라우저-기반 클라이언트에서(in a browser-based client) 사용자 입력을 수신하는 단계;
    상기 브라우저-기반 클라이언트에서 크리덴셜을 수신하는 단계;
    상기 서버 애플리케이션과 상호작용할 수 있는 리치 클라이언트를, 상기 웹 세션 내에서, 식별하는 단계;
    상기 리치 클라이언트에 크리덴셜(a credential)을, 상기 웹 세션 내에서, 제공하는 단계 ― 상기 크리덴셜은: 상기 브라우저-기반 클라이언트에 수신된 크리덴셜, 및 상기 서버 애플리케이션으로부터 수신되는 새로운 크리덴셜 중 하나임 ―; 및
    상기 리치 클라이언트를 사용하여 상기 서버 애플리케이션에 대해 상기 사용자를 인증하기 위해 상기 리치 클라이언트에 제공된 크리덴셜을, 상기 웹 세션 내에서, 사용하는 단계를 포함하는,
    컴퓨터 판독가능 매체.
18. 삭제
19. 삭제
20. 삭제
21. 삭제
22. 삭제
23. 삭제
24. 삭제
25. 제1 클라이언트 및 제2 클라이언트가 같은 곳에 배치되며(co-located), 제1 클라이언트에 의해 개시되는 사용자 세션 내에서 제2 클라이언트에 의한 서버 애플리케이션에 대한 액세스를 용이하게 하기 위한 방법에 있어서, 상기 방법은:
    상기 클라이언트들 중 적어도 하나가 비-브라우저 기반의 클라이언트(non-browser-based client)인, 상기 제1 클라이언트와 제2 클라이언트 사이에 제어 채널을 설정하는 단계(establishing);
    상기 제2 클라이언트가 상기 서버 애플리케이션과 상호작용하는 것(interact)이 가능함을, 상기 사용자 세션이 계속 진행 중인 동안, 발견하는(discovering) 단계;
    상기 제2 클라이언트에 크리덴셜을 제공하는 단계; 및
    상기 제2 클라이언트를 사용하여 상기 사용자를 상기 서버 애플리케이션에 인증하기 위해 상기 크리덴셜을 사용하는 단계를 포함하되,
    상기 설정하는 단계, 발견하는 단계, 제공하는 단계 및 사용하는 단계들 중 적어도 하나는 하드웨어 엘리멘트 내에서 실행하는 소프트웨어로 수행되는,
    방법.
26. 삭제
27. 삭제
28. 삭제

Images