KR20130105714A - 웹 리소스들을 위한 유저 인터랙션 - Google Patents

웹 리소스들을 위한 유저 인터랙션 Download PDF

Info

Publication number
KR20130105714A
KR20130105714A KR1020137018758A KR20137018758A KR20130105714A KR 20130105714 A KR20130105714 A KR 20130105714A KR 1020137018758 A KR1020137018758 A KR 1020137018758A KR 20137018758 A KR20137018758 A KR 20137018758A KR 20130105714 A KR20130105714 A KR 20130105714A
Authority
KR
South Korea
Prior art keywords
user interaction
request
service request
service
resource
Prior art date
Application number
KR1020137018758A
Other languages
English (en)
Inventor
가보르 마르톤
가보르 게스츠테시
Original Assignee
노키아 지멘스 네트웍스 오와이
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 노키아 지멘스 네트웍스 오와이 filed Critical 노키아 지멘스 네트웍스 오와이
Publication of KR20130105714A publication Critical patent/KR20130105714A/ko

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00—Arrangements for monitoring or testing data switching networks
    • H04L43/08—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters
    • H04L43/0876—Network utilisation, e.g. volume of load or congestion level
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0815—Network architectures or network communication protocols for network security for authentication of entities providing single-sign-on or federations
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0884—Network architectures or network communication protocols for network security for authentication of entities by delegation of authentication, e.g. a proxy authenticates an entity to be authenticated on behalf of this entity vis-à-vis an authentication entity
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/40—Support for services or applications
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/02—Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/56—Provisioning of proxy services
    • H04L67/561—Adding application-functional data or data for application control, e.g. adding metadata
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/56—Provisioning of proxy services
    • H04L67/563—Data redirection of data network streams

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Hardware Design (AREA)
  • Computer Security & Cryptography (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Library & Information Science (AREA)
  • Environmental & Geological Engineering (AREA)
  • Multimedia (AREA)
  • Information Transfer Between Computers (AREA)

Abstract

제 1 파티(리소스 서버)로부터 서비스 요청을 수신하기 위한 제 1 수신 수단; 상기 서비스 요청에 따르기 위해 유저 인터랙션을 위한 요구를 검출하기 위한 검출 수단; 제 1 파티와 다른 제 2 파티(유저 인터랙션 프록시)로부터 상기 유저 인터랙션을 요청하기 위한 요청 수단; 그리고 상기 제 2 파티로부터 응답으로서 상기 유저 인터랙션을 수신하기 위한 제 2 수신 수단을 포함하는, 장치(AuthProxy)가 제공된다.

Description

웹 리소스들을 위한 유저 인터랙션{USER INTERACTION FOR WEB RESOURCES}
본 발명은 웹 리소스들에 관련된 장치들, 방법들, 시스템, 그리고 컴퓨터 프로그램 물건에 관한 것이다. 보다 구체적으로, 본 발명은 웹 리소스들에 액세스중일 때 유저 인터랙션(user interaction)을 위한 장치들, 방법들, 시스템, 그리고 컴퓨터 프로그램 물건에 관한 것이다.
점점 더 많은 웹 어플리케이션들이 상이한 파티들에 의해 동작된 보다 간단한 서비스들로부터 구성된다. 많은 기여 서비스들은 기여 서비스들의 본질에 의해 "UI-less"(UI :User interface) 서비스들이다, 즉, UI-less 서비스들은 UI-less 서비스들이 엔드-유저(예를 들어, : 기상 정보 서비스, 미디어 파일 스토어, 환율 변환기, 검색 엔진)와 직접 인터랙션 할 필요가 없기 때문에 유저 인터페이스를 갖지 않는다. 이와 같은 기여 서비스들을 당업자는 웹 리소스들이라고 부른다. 일반적인 세팅에서, 당업자는 서로에 연결된 서비스들의 웹을 가지며, 몇몇 웹들은 클라이언트의 역할을 하며, 다른 웹들은 리소스 서버들이며 그리고 또 다른 웹들은 두 역할들을 나타낸다.
이러한 어플리케이션의 맥락에서, 용어들 "서비스" 그리고 "리소스"는, 이들 두 용어들간의 차이가 명백히 이루어지는 경우를 제외하고, 같은 뜻으로 사용된다. 즉, 본 출원에 따른 "리소스"는 예를 들어 서비스 또는 리소스 일 수 있으며, 그리고 본 출원에 따른 "서비스"는 역시 예를 들어 리소스 또는 서비스일 수 있다.
보다 좁은 의미로, 본 발명은 아이덴티티 관리에 관련되는데, 이는 문제 발표가 크로스-서비스 허가(authorization)로 불리우는 관련된 이슈로부터 발생하기 때문이다. － 웹 API 허가로서 또한 불리우는 － 크로스-서비스 허가는 소비자 서비스가 유저(리소스 소유자)에 의해 소유된 자신의 리소스들 또는 오퍼레이션(operation)들 중 몇몇을 액세스하도록 허용되는 경우를 제공자 서비스가 결정하는 프로세스이다. 제공자 서비스는 리소스들 － 예를 들어, 유저들에 의해 업로드된 사진들 － 을 API(Application Programming Interface)를 통해 다른 서비스들에 노출한다. 소비자 서비스 － 예를 들어 프린팅 서비스 － 는 API를 통해 이와 같은 리소스를 액세스한다.
HTTP(Hypertext Transfer Protocol)은 분산, 공동, 하이퍼미디어 정보 시스템들을 위한 "어플리케이션-레벨 프로토콜"이다. HTTP는 월드 와이드 웹(World Wide Web)의 수립을 이끈 인터-링크된 리소스들을 검색하기 위해 사용된다.
HTTP는 "요청자(requester)가 요청을 수신하고 처리하는, 궁극적으로 응답으로 메시지를 리턴하는 응답기 시스템에 요청 메시지를 전송"하는 요청-응답 프로토콜이다.
OAuth는 HTTP에 기초하여 "데스크탑과 웹 어플리케이션들로부터 간단하고 표준인 방법으로 안전한 API 허가를 허용하도록 하는 오픈 프로토콜" (http://oauth.net/) 이다. 제공자 서비스들은 리소스 요청(HTTP 요청)시 유효한 OAuth 토큰의 존재를 요구한다. OAuth 2.0 용어에 대하여 말하자면, 클라이언트(소비자 서비스)는 우선 리소스 소유자로부터 액세스 승인을 획득하고, 그 다음 － 클라이언트 자체 인증 및 액세스 승인 제출의 교환시 － 클라이언트는 허가 서버로부터 액세스 토큰을 획득하며, 그리고 마지막으로 － 액세스 토큰 제출의 교환시 － 클라이언트는 리소스 서버로부터 리소스를 검색한다(도 1을 참조). (OAuth 2.0에서, 리소스 소유자, 허가 서버 및 리소스 서버의 기능들은 명백하게 분리되는 반면에, OAuth 1.0에서 이들 기능들은 3가지 타입들의 토큰 : 비허가 요청 토큰, 허가 요청 토큰 그리고 액세스 토큰에 의해 서비스 제공자에 모두 구속된다.)
OAuth 프록시는 OAuth 프로토콜의 세부사항들을 숨김으로써 OAuth-인에이블된 리소스 서버들(제공자 서비스들)에서 리소스들을 액세스할 때 OAuth 클라이언트들(소비자 서비스들)을 지원하는 유틸리티 컴포넌트이다. 모든 클라이언트는 검색될 리소스의 URL을 알고 있어야 하며; 나머지는 클라이언트와 리소스 서버 사이에 상주하는 OAuth 프록시에 의해 이루어진다(보다 세부사항들을 위해, 예로서, 이하 설명된 구글 OAuth 프록시를 참조).
상호연결된 서비스들의 웹인 서비스 "딥 인사이드(deep inside)"가 "갑자기" 엔드-유저 인터랙션을 요구할 때, 문제가 발생한다.
도 2는 이와 같은 상황의 예를 도시한다. 브라우저는 위치 추적기로부터 현재 환경의 지도를 요청한다(1.). 위치 추적기는 OAuth 프록시를 통해 위치 소스로부터 위치 정보를 요청한다(2., 3.). 즉, 요청자의 인증을 요구하도록 위치 소스가 구성된다. 인증 정보가 활용될 수 없기 때문에, 위치 소스는 OAuth 프록시로 401 비허가 응답을 리턴하는데(4.), 이는 요청(3.)이 유효한 액세스 토큰을 포함하고 있지 않았기 때문이다. 바로 이때, OAuth 프록시는 엔드-유저 인터랙션을 필요로 하지만(유저들의 개별 데이터에 대해 액세스를 허가하기 위해 위치 소스로 유저를 리다이렉트해야 하지만), OAuth 프록시는 엔드-유저와 직접적인 접촉이 없다.
하나의 옵션은 클라이언트 서비스(위치 추적기)를 포함하고 클라이언트 서비스가 필요한 UI를 리턴하도록 만드는 것이다. 그러나, 이러한 목적을 위해, 위치 추적기 서비스는 상황을 "이해"해야 한다, 즉, 또한 서비스 로직이 유저 인터랙션을 위해 준비되어야 하지만, 이러한 인터랙션 － 유저와 위치 소스 사이 － 은 전혀 위치 추적기의 업무가 아니다.
그래서 보다 나은 해결책은 클라이언트 서비스를 포함하지 않는 것일 수 있다.
도 3은 유저와 인터랙팅 서비스 간의 한 단계 위의 우회적인 행동(indirection) 또는 거리를 갖는 보다 복잡한 예를 도시한다. 이 경우에, 웹 어플리케이션("내 테스크탑")이 브라우저와 위치 추적기 사이에 삽입된다.
현재의 실행은 문제에 대한 포괄적인 해결책을 제공하지 못한다.
구글 OAuth 프록시
(http://code.google.com/intl/hu/apis/gadgets/docs/oauth.html)은 － 클라이언트-측 소프트웨어(JavaScript)와 조합으로 － iGoogle상에서 구동되고 OAuth 프로토콜을 지원하는 임의의 웹사이트로부터 유저의 개인 데이터를 액세스하는 "기록 가젯들"에서 개발자들을 지원하며 "가젯들이 OAuth 표준을 보다 쉽게 사용하도록 설계되는" 서비스이다. 구글에 의해 제공된 샘플 가젯 코드 (http://gadget- doc - examples . googlecode . com / svn / trunk / opensocial - gadgets / yahoo - presence . xml)는 Yahoo의 API를 액세스하며 OAuth-관련 구성은
<OAuth>
<Service name="yahoo">
<Request param_location="uri-query" url="https://api.login.yahoo.com/oauth/v2/get_request_token" />
<Access param_location="uri-query" url="https://api.login.yahoo.com/oauth/v2/get_token" />
<Authorization url="https://api.login.yahoo.com/oauth/v2/request_auth" />
</Service>
</OAuth>
와 같이 간단하다:
유저의 상태 메시지를 액세스하는 것 － 즉, OAuth-인에이블된 API 방법을 호출하는 것 － 은 다음의 함수에 의해 이루어진다:
var url = getPresenceUrl();
var params = getDefaultParams();
gadgets.io.makeRequest(url, function(response) {
makeRequestCallback(fetchStatusDone, response);
}, params);
여기서 makeRequestCallback 함수는, 예를 들어
function makeRequestCallback(nextCallback, response) {
if (response.oauthApprovalUrl) {
var onOpen = function() {
showOneSection('waiting');
};
var onClose = function() {
completeAuthorization();
};
var popup = new gadgets.oauth.Popup(
response.oauthApprovalUrl,
"width=800,height=600",
onOpen,
onClose
);
...
}
}
와 같이, 허가를 위해 필요한 단계들을 수행 － 즉 유저로 하여금 서비스 제공자에서 허가 페이지로 지향 － 하게 하기 위해 가젯에 의해 구현된다.
즉, 구글 OAuth 프록시는 유저 인터랙션을 처리하기 위해 자신의 인접 클라이언트에 의존한다. 구글 OAuth 프록시는 도 3에 도시된 상황에 대처할 수 없다.
사이트마인더(SiteMinder)(http://www.ca.com/us/collateral/product-briefs/na/ca-siteminder.aspx)는 "유저들로 하여금 단 한차례만 인증하도록 할 수 있으며 CA 사이트마인더 WAM[Web Access Management]에 의해 보호된 웹 어플리케이션들과 CA SSO[Single Sign-On]에 의해 컨트롤된 액세스를 갖는 비-웹 어플리케이션들 둘 다에 액세스할 수 있도록 한다". 해결책은 유저들이 보호된 서비스에 액세스하기에 앞서 유저를 인증한다. 해결책은 서비스가 호출된 후 유저 인터랙션을 위한 필요성이 일어나는 상황에 대처할 수 없다.
종속 포털(captive portal) 기법(http://en.wikipedia.org/wiki/Captive portal) － 예를 들어 호텔들에서 WiFi 액세스를 컨트롤하기 위해 사용된 － 은 네트워크상의 HTTP 클라이언트로 하여금 인터넷을 정상적으로 사용하기 전에 (통상적으로 인증 목적들을 위해) 특별한 웹 페이지를 보도록 강제한다. 종속 포털은 웹 브라우저가 인증 디바이스가 되도록 한다. 이것은 유저가 브라우저를 오픈하고 인터넷에 액세스하려고 시도할 때까지, 어드레스 또는 포트에 관계없이, 모든 패킷들을 가로챔으로써 이루어진다. 그때에 브라우저는 인증 및/또는 지불을 요구할 수 있거나, 또는 수용가능한 사용 정책을 단순히 디스플레이하고 유저에게 동의를 요구할 수 있는 웹 페이지로 리다이렉트 된다. 이전의 2개의 예들과 유사하게, 이러한 기법은 "뒤 늦게 일어나는" 유저 인터랙션 요청들에 대처할 수 없다.
WS-코디네이션(coordination)(https ://www.ibm.com/developerworks/webservices/library/ws-transita/)는 "분산된 참여자들이 참여자들의 개별적인 행위들에 걸쳐 범용적인 결과에 동의할 수 있도록 하는 코디네이션 프레임워크이다". 본질적으로 이는 제어된 방식으로 달리 완료할 수 없을 분산된 참여자들(예를 들어 상이한 머신들에 대한 2개의 어플리케이션 서버들)이 각각의 참여자의 행동들을 함께 그룹화하고, 그리고 참여자들이 이러한 코디네이션 맥락하에 개별적으로 수행한 모든 행동들에 대해 참여자 모두가 단일 결과에 동의한다는 것을 보장함으로써 참여자들을 더 관리하기 위해 WS-코디네이션을 사용할 수 있을 것이라는 것을 의미한다.
기본적인 WS-코디네이션 흐름은 도 4에 의해 예시된다.
"1. App 1은 코디네이터에 대한 활성화 서비스를 요청한다.
2. 코디네이터는 새로운 활동을 시작하며 자신의 CoordinationContext(코디네이터의 XML 정보)로 App 1에 응답한다.
3. App 1은 코디네이션 프로토콜 X를 사용하기 위해 레지스터에 등록 서비스를 요청한다.
4. App 1은 App 1이 원하는 무슨 방식으로든 App 2를 호출하며, 코디네이터를 위해 CoordinationContext를 전달한다.
5. App 2는 코디네이션 프로토콜 Y를 사용하기 위해 레지스터에 (App 1에 의해 건네진 CoordinationContext에서 발견된 포트 정보와 같은 파라미터들을 이용해) 등록 서비스를 요청한다.
6. App 2는 자신의 작업을 끝내고 제어가 App 1로 리턴하며 활동은 완료된 것으로 불리운다.
7. 코디네이터는 프로토콜 X 스타일 메시지들을 이용해 App 1에 응답한다.
8. 코디네이터는 프로토콜 Y 스타일 메시지들을 이용해 App 2에 응답한다".
본 발명에 대한 WS-코디네이션의 관계는 거리가 있다: WS-코디네이션은 인터셉팅 프록시의 개념을 전혀 포함하지 않는다.
본 발명의 목적은 종래 기술을 개선하는 데 있다.
본 발명의 제 1 양상에 따르면, 제 1 파티로부터 서비스 요청을 수신하기 위한 제 1 수신 수단; 상기 서비스 요청에 따르기 위해 유저 인터랙션을 위한 요구를 검출하기 위한 검출 수단; 제 1 파티와 다른 제 2 파티로부터 상기 유저 인터랙션을 요청하기 위한 요청 수단; 그리고 상기 제 2 파티로부터의 응답으로서 상기 유저 인터랙션을 수신하기 위한 제 2 수신 수단을 포함하는 장치가 제공된다.
장치에서, 유저 인터랙션을 위한 상기 요청은 상기 유저 인터랙션을 실행하기 위한 유저 인터페이스를 제공하기 위해 정보 엘리먼트를 포함할 수 있다.
장치는 상기 서비스 요청에 따르기 위해 리소스 디바이스로부터 제 2 리소스를 요청하기 위한 리소스 요청 수단을 더 포함할 수 있다; 그리고 검출 수단은 리소스에 대한 요청에 응답하여 리소스 디바이스로부터 수신된 예외 정보에 기초하여 유저 인터랙션을 위한 요구를 검출하도록 적응될 수 있다.
장치에서, 유저 인터랙션은 서비스 요청이 제 1 파티로부터 수신되도록 야기한 유저로부터 요청될 수 있다.
장치에서, 유저 인터랙션을 위한 상기 요청은 상기 서비스 요청의 식별을 포함할 수 있다.
장치에서, 요청 수단은, 상기 유저 인터랙션을 위한 상기 요청과 함께, 트랜잭션 식별자를 제공하도록 적응될 수 있으며, 여기서 트랜잭션 식별자는 제 1 파티로부터 수신된 서비스 요청에 포함된다.
장치는 제 1 파티에 응답하기 위한 응답 수단을 더 포함할 수 있으며, 여기서 응답은, 서비스 요청에 순응하여, 제 1 파티내 서비스 실행을 중단하기 위한 트리거를 포함할 수 있다.
장치는 제 1 파티로부터 수신된 서비스 요청에 관련되는 핸들(handle)(그리고 여기서, 핸들은 장치의 영역에서 고유하다)을 발생하기 위한 핸들 발생 수단; 핸들을 포함하는 핸들 메시지가 제 2 파티로부터 장치에 의해 수신되는지를 검출하기 위한 핸들 검출 수단을 더 포함할 수 있으며, 그리고 상기 요청 수단은 핸들 메시지가 검출되면 유저 인터랙션을 요청하도록 적응될 수 있다.
장치는 핸들 메시지에 기초하여 제 2 파티를 식별하기 위한 식별 수단을 더 포함할 수 있다.
장치에서, 서비스 요청은 제 1 유저 식별을 포함할 수 있으며, 그리고 장치는 제 2 서비스 요청에 포함된 제 2 식별에 기초하여 제 1 파티로부터의 제 2 서비스 요청을 수신된 유저 인터랙션과 상관시키기 위한 상관 수단을 더 포함할 수 있다.
본 발명의 제 2 양상에 따르면, 제 1 파티로부터 서비스 요청을 수신하기 위한 제 1 수신 프로세서; 상기 서비스 요청에 따르기 위해 유저 인터랙션을 위한 요구를 검출하기 위한 검출 프로세서; 제 1 파티와 다른 제 2 파티로부터 상기 유저 인터랙션을 요청하기 위한 요청 프로세서; 그리고 상기 제 2 파티로부터 응답으로서 상기 유저 인터랙션을 수신하기 위한 제 2 수신 프로세서를 포함하는 장치가 제공된다.
장치에서, 유저 인터랙션을 위한 상기 요청은 상기 유저 인터랙션을 실행하기 위해 유저 인터페이스를 제공하기 위한 정보 엘리먼트를 포함할 수 있다.
장치는 상기 서비스 요청에 따르기 위해 리소스 디바이스로부터 제 2 리소스를 요청하기 위한 리소스 요청 프로세서를 더 포함할 수 있고; 그리고 검출 프로세서는 리소스에 대한 요청에 응답하여 리소스 디바이스로부터 수신된 예외 정보에 기초하여 유저 인터랙션을 위한 요구를 검출하도록 적응될 수 있다.
장치에서, 유저 인터랙션은 서비스 요청이 제 1 파티로부터 수신되도록 야기한 유저로부터 요청될 수 있다.
장치에서, 유저 인터랙션을 위한 상기 요청은 상기 서비스 요청의 식별을 포함할 수 있다.
장치에서, 요청 프로세서는, 상기 유저 인터랙션을 위한 상기 요청과 함께, 트랜잭션 식별자를 제공하도록 적응될 수 있으며, 여기서 트랜잭션 식별자는 제 1 파티로부터 수신된 서비스 요청에 포함된다.
장치는 제 1 파티에 응답하기 위한 응답 프로세서를 더 포함할 수 있으며, 여기서 응답은, 서비스 요청에 순응하여, 제 1 파티내 서비스 실행을 중단하기 위한 트리거를 포함할 수 있다.
장치는 제 1 파티로부터 수신된 서비스 요청에 관련되는 핸들(그리고 여기서, 핸들은 장치의 영역에서 고유하다)을 발생하기 위한 핸들 발생 프로세서; 핸들을 포함하는 핸들 메시지가 제 2 파티로부터 장치에 의해 수신되는지를 검출하기 위한 핸들 검출 프로세서를 더 포함할 수 있으며, 그리고 상기 요청 프로세서는 핸들 메시지가 검출되면 유저 인터랙션을 요청하도록 적응될 수 있다.
장치는 핸들 메시지에 기초하여 제 2 파티를 식별하기 위한 식별 프로세서를 더 포함할 수 있다.
장치에서, 서비스 요청은 제 1 유저 식별을 포함할 수 있으며, 그리고 장치는 제 2 서비스 요청에 포함된 제 2 식별에 기초하여 제 1 파티로부터의 제 2 서비스 요청을 수신된 유저 인터랙션과 상관시키기 위한 상관 프로세서를 더 포함할 수 있다.
본 발명의 제 3 양상에 따르면, 제 1 양상과 제 2 양상 중 임의의 양상에 따른 장치를 포함하는 리소스 액세스 프록시가 제공된다.
본 발명의 제 4 양상에 따르면, 서비스 요청을 제 1 디바이스로 전송하기 위한 전송 수단; 상기 서비스 요청에 따르기 위해 제 1 디바이스와 다른 제 2 디바이스로부터 유저 인터랙션을 위한 요청을 수신하기 위한 제 1 수신 수단; 유저 인터랙션 디바이스로부터 상기 유저 인터랙션을 요청하기 위한 요청 수단; 상기 유저 인터랙션 디바이스로부터 상기 유저 인터랙션을 수신하기 위한 제 2 수신 수단; 그리고 유저 인터랙션을 위한 상기 요청에 대해, 상기 유저 인터랙션 디바이스로부터 수신된 상기 유저 인터랙션에 기초하여 응답하기 위한 응답 수단을 포함하는 장치가 제공된다.
장치에서, 상기 서비스 요청은 상기 서비스 요청을 전송하는 디바이스의 식별을 포함할 수 있다.
장치는 상기 유저 인터페이스로부터 서비스 요청을 수신하기 위한 제 3 수신수단을 더 포함할 수 있다.
장치에서, 유저 인터랙션을 위한 상기 요청에 대한 상기 응답은 상기 제 1 디바이스로 상기 서비스 요청의 제 2 전송을 트리거하도록 적응될 수 있다.
장치는 서비스 요청에 응답하여 핸들을 포함하는 재시도 메시지를 수신하기 위한 제 4 수신 수단; 제 2 디바이스로 핸들을 포함하는 핸들 메시지를 제공하기 위한 핸들 메시지 제공 수단을 더 포함할 수 있으며, 그리고 제 2 수신 수단은 핸들 메시지의 제공에 응답하여 유저 인터랙션을 위한 요청을 수신하도록 적응될 수 있다.
장치는 핸들을 포함하는 수신된 재시도 메시지에 기초하여 제 2 디바이스를 식별하기 위한 식별 수단을 더 포함할 수 있다.
장치에서, 유저 인터랙션을 위한 상기 요청은 상기 서비스 요청의 식별을 포함할 수 있다.
장치는 서비스 요청을 위해 식별자를 발생하기 위한 식별자 발생 수단을 더 포함할 수 있으며, 여기서 유저 인터랙션을 위한 상기 요청에 대한 상기 응답은 상기 서비스 요청의 상기 식별자를 포함할 수 있다.
장치는 서비스 요청에 응답하여 에러 메시지를 수신하기 위한 제 5 수신 수단; 상기 식별자에 기초하여 에러 메시지를 유저 인터랙션을 위한 요청과 상관시키기 위한 상관 수단을 더 포함할 수 있다.
본 발명의 제 5 양상에 따르면, 서비스 요청을 제 1 디바이스로 전송하기 위한 전송 프로세서; 상기 서비스 요청에 따르기 위해 제 1 디바이스와 다른 제 2 디바이스로부터 유저 인터랙션을 위한 요청을 수신하기 위한 제 1 수신 프로세서; 유저 인터랙션 디바이스로부터 상기 유저 인터랙션을 요청하기 위한 요청 프로세서; 상기 유저 인터랙션 디바이스로부터 상기 유저 인터랙션을 수신하기 위한 제 2 수신 프로세서; 그리고 유저 인터랙션을 위한 상기 요청에 대하여, 상기 유저 인터랙션 디바이스로부터 수신된 상기 유저 인터랙션에 기초하여 응답하기 위한 응답 프로세서를 포함하는 장치가 제공된다.
장치에서, 상기 서비스 요청은 상기 서비스 요청을 전송하는 디바이스의 식별을 포함할 수 있다.
장치는 상기 유저 인터페이스로부터 서비스 요청을 수신하기 위한 제 3 수신 프로세서를 더 포함할 수 있다.
장치에서, 유저 인터랙션을 위한 상기 요청에 대한 상기 응답은 상기 제 1 디바이스로 상기 서비스 요청의 제 2 전송을 트리거 하도록 적응될 수 있다.
장치는 서비스 요청에 응답하여 핸들을 포함하는 재시도 메시지를 수신하기 위한 제 4 수신 프로세서; 제 2 디바이스로 핸들을 포함하는 핸들 메시지를 제공하기 위한 핸들 메시지 제공 프로세서를 더 포함할 수 있으며, 그리고 제 2 수신 프로세서는 핸들 메시지의 제공에 응답하여 유저 인터랙션을 위한 요청을 수신하도록 적응될 수 있다.
장치는 핸들을 포함하는 수신된 재시도 메시지에 기초하여 제 2 디바이스를 식별하기 위한 식별 프로세서를 더 포함할 수 있다.
장치에서, 유저 인터랙션을 위한 상기 요청은 상기 서비스 요청의 식별을 포함할 수 있다.
장치는 서비스 요청을 위한 식별자를 발생하기 위해 식별자 발생 프로세서를 더 포함할 수 있으며, 여기서 유저 인터랙션을 위한 상기 요청에 대한 상기 응답은 상기 서비스 요청의 상기 식별자를 포함할 수 있다.
장치는 서비스 요청에 응답하여 에러 메시지를 수신하기 위한 제 5 수신 프로세서; 상기 식별자에 기초하여 에러 메시지를 유저 인터랙션을 위한 요청과 상관시키기 위한 상관 프로세서를 더 포함할 수 있다.
본 발명의 제 6 양상에 따르면, 제 4 양상과 제 5 양상 중 임의의 양상에 따른 장치를 포함하는 유저 인터랙션 프록시가 제공된다.
본 발명의 제 7 양상에 따르면, 제 1 파티로부터 서비스 요청을 수신하기 위한 제 1 수신 수단; 서비스 요청을 충족시키기 위해, 제 2 파티로부터 리소스를 요청하기 위한 요청 수단; 리소스를 위한 요청에 대한 응답을 수신하기 위한 제 2 수신 수단; 리소스를 위한 요청에 순응하여, 응답이 핸들과 서비스 실행을 중단하기 위한 트리거를 포함하는 제 1 재시도 메시지를 포함하는지를 검출하기 위한 검출 수단; 서비스 요청에 순응하여, 응답이 제 1 재시도 메시지인 것을 검출 수단이 검출하면 핸들과 서비스 실행을 중단하기 위한 트리거를 포함하는 제 2 재시도 메시지에 의한 서비스 요청에 응답하기 위한 응답 수단을 포함하는 장치가 제공된다.
본 발명의 제 8 양상에 따르면, 제 1 파티로부터 서비스 요청을 수신하기 위한 수신 수단; 서비스 요청을 충족시키기 위해, 제 2 파티로부터 리소스를 요청하기 위한 요청 수단을 포함하는 장치가 제공되며; 여기서 서비스 요청은 식별자를 포함하고; 그리고 리소스를 위한 요청은 식별자를 포함한다.
본 발명의 제 9 양상에 따르면, 제 1 파티로부터 서비스 요청을 수신하기 위한 제 1 수신 프로세서; 서비스 요청을 충족시키기 위해, 제 2 파티로부터 리소스를 요청하기 위한 요청 프로세서; 리소스를 위한 요청에 대한 응답을 수신하기 위한 제 2 수신 프로세서; 리소스를 위한 요청에 순응하여, 응답이 핸들과 서비스 실행을 중단하기 위한 트리거를 포함하는 제 1 재시도 메시지를 포함하는지를 검출하기 위한 검출 프로세서; 서비스 요청에 순응하여, 응답이 제 1 재시도 메시지인 것을 검출 수단이 검출하면 핸들과 서비스 실행을 중단하기 위한 트리거를 포함하는 제 2 재시도 메시지에 의한 서비스 요청에 응답하기 위한 응답 프로세서를 포함하는 장치가 제공된다.
본 발명의 제 10 양상에 따르면, 제 1 파티로부터 서비스 요청을 수신하기 위한 수신 프로세서; 서비스 요청을 충족시키기 위해, 제 2 파티로부터 리소스를 요청하기 위한 요청 프로세서를 포함하는 장치가 제공되며; 여기서 서비스 요청은 식별자를 포함하고; 그리고 리소스를 위한 요청은 식별자를 포함한다.
본 발명의 제 11 양상에 따르면, 제 7 양상 내지 제 10 양상들 중 임의의 양상에 따른 장치를 포함하는 리소스 서버가 제공된다.
본 발명의 제 12 양상에 따르면, 제 1 양상 내지 제 3 양상들 중 임의의 양상에 따른 제 1 리소스 장치; 그리고 제 4 양상 내지 제 6 양상들 중 임의의 양상에 따른 유저 인터랙션 장치를 포함하는 시스템이 제공되며; 여기서 제 1 리소스 장치의 제 2 파티는 유저 인터랙션 장치를 포함하고; 유저 인터랙션 장치의 제 2 디바이스는 제 1 리소스 장치를 포함하며; 제 1 리소스 장치의 상기 유저 인터랙션을 위한 요청은 유저 인터랙션 장치의 유저 인터랙션을 위해 수신된 요청이고; 그리고 유저 인터랙션 장치의 유저 인터랙션을 위한 상기 유저 요청에 대한 응답은 제 1 리소스 장치에 의해 수신된 유저 인터랙션이다.
시스템은 제 7 양상 내지 제 11 양상들 중 임의의 양상에 따른 제 2 리소스 장치를 더 포함할 수 있으며; 여기서 제 1 리소스 장치의 제 1 파티는 제 2 리소스 장치를 포함할 수 있고; 유저 인터랙션 장치의 제 1 디바이스는 제 2 리소스 장치를 포함할 수 있으며; 유저 인터랙션 장치에 의해 전송된 서비스 요청은 제 2 리소스 장치에 의해 수신된 서비스 요청일 수 있고; 그리고 제 2 리소스 장치의 리소스를 위한 요청은 제 1 리소스 장치에 의해 수신된 서비스 요청일 수 있다.
본 발명의 제 13 양상에 따르면, 제 1 파티로부터 서비스 요청을 수신하는 단계; 상기 서비스 요청에 따르기 위해 유저 인터랙션을 위한 요구를 검출하는 단계; 제 1 파티와 다른 제 2 파티로부터 상기 유저 인터랙션을 요청하는 단계; 그리고 상기 제 2 파티로부터 응답으로서 상기 유저 인터랙션을 수신하는 단계를 포함하는 방법이 제공된다.
방법은 유저 인터랙션의 방법일 수 있다.
방법에서, 유저 인터랙션을 위한 상기 요청은 상기 유저 인터랙션을 실행하기 위해 유저 인터페이스를 제공하기 위한 정보 엘리먼트를 포함할 수 있다.
방법은 상기 서비스 요청에 따르기 위해 리소스 디바이스로부터 제 2 리소스를 요청하는 단계를 더 포함할 수 있다; 그리고 검출 단계는 리소스를 위한 요청에 응답하여 리소스 디바이스로부터 수신된 예외 정보에 기초하여 유저 인터랙션을 위한 요구를 검출하도록 적응될 수 있다.
방법에서, 유저 인터랙션은 서비스 요청이 제 1 파티로부터 수신되도록 야기한 유저로부터 요청될 수 있다.
방법에서, 유저 인터랙션을 위한 상기 요청은 상기 서비스 요청의 식별을 포함할 수 있다.
방법에서, 요청 단계는, 상기 유저 인터랙션을 위한 상기 요청과 함께, 트랜잭션 식별자를 제공하도록 적응될 수 있으며, 여기서 트랜잭션 식별자는 제 1 파티로부터 수신된 서비스 요청에 포함될 수 있다.
방법은 제 1 파티에 대해 응답 단계를 더 포함할 수 있으며, 여기서 응답은, 서비스 요청에 순응하여, 제 1 파티내 서비스 실행을 중단하기 위한 트리거를 포함할 수 있다.
방법은 제 1 파티로부터 수신된 서비스 요청에 관련되는 핸들(그리고 핸들은 방법을 수행하는 장치의 영역에서 고유하다)을 발생하는 단계; 핸들을 포함하는 핸들 메시지가 제 2 파티로부터 장치에 의해 수신되는지를 검출하는 단계를 더 포함할 수 있으며, 그리고 요청 단계는 핸들 메시지가 검출되면 유저 인터랙션을 요청하도록 적응될 수 있다.
방법은 핸들 메시지에 기초하여 제 2 파티를 식별하는 단계를 더 포함할 수 있다.
방법에서, 서비스 요청은 제 1 유저 식별을 포함할 수 있으며, 방법은 제 2 서비스 요청에 포함된 제 2 식별에 기초하여 제 1 파티로부터의 제 2 서비스 요청을 수신된 유저 인터랙션과 상관시키는 단계를 더 포함할 수 있다.
본 발명의 제 14 양상에 따르면, 제 1 디바이스로 서비스 요청을 전송하는 단계; 상기 서비스 요청에 따르기 위해 제 1 디바이스와 다른 제 2 디바이스로부터 유저 인터랙션을 위한 요청을 수신하는 단계; 유저 인터랙션 디바이스로부터 상기 유저 인터랙션을 요청하는 단계; 상기 유저 인터랙션 디바이스로부터 상기 유저 인터랙션을 수신하는 단계; 그리고 유저 인터랙션을 위한 상기 요청에 대해, 상기 유저 인터랙션 디바이스로부터 수신된 상기 유저 인터랙션에 기초하여 응답하는 단계를 포함하는 방법이 제공된다.
방법은 유저 인터랙션의 방법일 수 있다.
방법에서, 상기 서비스 요청은 상기 서비스 요청을 전송하는 디바이스의 식별을 포함할 수 있다.
방법은 상기 유저 인터페이스로부터 서비스 요청을 수신하는 단계를 더 포함할 수 있다.
방법에서, 유저 인터랙션을 위한 상기 요청에 대한 상기 응답은 상기 제 1 디바이스로 상기 서비스 요청의 제 2 전송을 트리거할 수 있다.
방법은 서비스 요청에 응답하여 핸들을 포함하는 재시도 메시지를 수신하는 단계; 제 2 디바이스로 핸들을 포함하는 핸들 메시지를 제공하는 단계를 더 포함할 수 있으며, 그리고 유저 인터랙션을 위한 요청은 핸들 메시지의 제공에 응답하여 수신될 수 있다.
방법은 핸들을 포함하는 수신된 재시도 메시지에 기초하여 제 2 디바이스를 식별하는 단계를 더 포함할 수 있다.
방법에서, 유저 인터랙션을 위한 상기 요청은 상기 서비스 요청의 식별을 포함할 수 있다.
방법은 서비스 요청을 위한 식별자를 발생하는 단계를 더 포함할 수 있으며, 여기서 유저 인터랙션을 위한 상기 요청에 대한 상기 응답은 상기 서비스 요청의 상기 식별자를 포함할 수 있다.
방법은 서비스 요청에 응답하여 에러 메시지를 수신하는 단계; 상기 식별자에 기초하여 에러 메시지를 유저 인터랙션을 위한 요청과 상관시키는 단계를 더 포함할 수 있다.
본 발명의 제 15 양상에 따르면, 제 1 파티로부터 서비스 요청을 수신하기 위한 제 1 수신 수단; 서비스 요청을 충족시키기 위해, 제 2 파티로부터 리소스를 요청하기 위한 요청 수단; 리소스를 위한 요청에 대한 응답을 수신하기 위한 제 2 수신 수단; 리소스를 위한 요청에 순응하여, 응답이 핸들과 서비스 실행을 중단하기 위한 트리거를 포함하는 제 1 재시도 메시지를 포함하는지를 검출하기 위한 검출 수단; 서비스 요청에 순응하여, 응답이 제 1 재시도 메시지인 것을 검출 수단이 검출하면, 핸들과 서비스 실행을 중단하기 위한 트리거를 포함하는 제 2 재시도 메시지에 의한 서비스 요청에 대해 응답하기 위한 응답 수단을 포함하는 방법이 제공된다.
본 발명의 제 16 양상에 따르면, 제 1 파티로부터 서비스 요청을 수신하기 위한 수신 수단; 서비스 요청을 충족시키기 위해, 제 2 파티로부터 리소스를 요청하기 위한 요청 수단을 포함하는 방법이 제공되며; 여기서 서비스 요청은 식별자를 포함하고; 그리고 리소스를 위한 요청은 식별자를 포함한다.
제 15 양상과 제 16 양상 중 임의의 양상에 따른 방법은 서비스 요청의 방법일 수 있다.
본 발명의 제 17 양상에 따르면, 장치의 프로세서상에서 구동될 때, 제 13 양상 내지 제 16 양상들 중 어느 하나의 양상에 따른 방법을 수행하기 위해 정렬되는 소프트웨어 코드 부분들을 포함하는 프로그램을 포함하는 컴퓨터 프로그램 물건이 제공된다.
컴퓨터 프로그램 물건은 소프트웨어 코드 부분들이 저장되고/되거나, 프로그램이 프로세서의 메모리 내로 직접 로드할 수 있는 컴퓨터-판독가능 매체를 포함할 수 있다.
장치들, 방법들, 시스템, 그리고 컴퓨터 프로그램 물건에 의해, 보안을 포함하지 않는 순조로운 유저 경험이 제공될 수 있는데 이는 브라우저(또는 관련된 유저 인터랙션 프록시)와 유저 정보(또는 관련된 인증 프록시)를 요청하는 리소스로부터 체인의 도중에 서비스들이 유저 증명서들의 송신에 포함되는 것이 회피되기 때문이다. 즉, 증명서들은 브라우저(또는 브라우저의 관련된 유저 인터랙션 프록시)와 당해 서비스(또는 서비스의 관련된 인증 프록시) 간에 비밀로서 유지되며, 그리고 서비스 세션에 참여하고 있는 모든 다른 파티들에게 비밀로 된다.
상기 변경들이 대안들을 배제하는 것으로서 명시적으로 기술되지 않는 한, 상기 변경들 중 임의의 변경들이 이들이 참조하는 각각의 양상들에 대해 단독으로 또는 조합으로 적용될 수 있다는 것이 이해될 것이다.
게다가 세부내용들, 특징들, 목적들, 그리고 장점들은 첨부된 도면들과 함께 취해지게 될 본 발명의 바람직한 실시예의 이하 상세한 설명으로부터 명백하다.
도 1은 OAuth 시퀀스를 도시한다.
도 2는 OAuth 프록시를 포함하는 시스템의 간단한 예를 도시한다.
도 3은 OAuth 프록시를 포함하는 시스템의 보다 복잡한 예를 도시한다.
도 4는 기본적인 WS-코디네이션 흐름을 도시한다.
도 5는 본 발명의 실시예들이 기초하는 워크플로우를 갖는 예시적인 시스템을 도시한다.
도 6은 본 발명의 실시예에 따른 워크플로우를 갖는 시스템을 도시한다.
도 7은 본 발명의 실시예에 따른 워크플로우를 갖는 시스템을 도시한다.
도 8은 본 발명의 실시예에 따른 워크플로우를 갖는 시스템을 도시한다.
도 9는 본 발명의 실시예에 따른 장치를 도시한다.
도 10은 본 발명의 실시예에 따른 방법을 도시한다.
도 11은 본 발명의 실시예에 따른 장치를 도시한다.
도 12는 본 발명의 실시예에 따른 방법을 도시한다.
도 13은 본 발명의 실시예에 따른 장치를 도시한다.
도 14는 본 발명의 실시예에 따른 방법을 도시한다.
도 15는 본 발명의 실시예에 따른 시스템을 도시한다.
도 16은 본 발명의 실시예에 따른 시스템을 도시한다.
이하 본 명세서에서, 본 발명의 특정한 실시예들은 첨부 도면들을 참조하여 상세히 기술되며, 여기서 실시예들의 특징들은 달리 기술되지 않는 한 서로 자유롭게 조합될 수 있다. 그러나, 특정한 실시예들의 상세한 설명은 단지 예로서 제공되며, 특정한 실시예들의 상세한 설명은 개시된 세부내용들로 본 발명을 제한하는 것으로서 이해되도록 결코 의도하기 위함이 아니라는 것이 분명히 이해될 것이다.
더욱이, 비록 몇몇 경우들에서 장치만이 또는 방법만이 기술된다고 하더라도, 장치는 대응하는 방법을 수행하도록 구성된다는 것이 이해될 것이다.
도 5는 본 발명의 실시예들이 기초할 수 있는 워크플로우를 갖는 시스템을 도시한다. 시스템은 본 발명을 제한하지 않으며, 그리고, 예를 들어, 다소간의 서버들을 포함하는 기타 시스템들, 그리고 기타 워크플로우들이 본 발명의 범주내에 존재한다. 도 5에 따른 시스템은 본 발명을 설명하기 위해 이후 본 명세서에서 예시적으로 사용된다.
시스템은 브라우저를 포함한다. 브라우저는 유저 인터랙션을 허용하는 MS 인터넷 익스플로러, 모질라 파이어폭스, 오페라(Opera) 등과 같은 임의의 브라우저일 수 있다.
예를 들어, 유저 인터랙션에 기초하여, 브라우저는 서비스 1 로부터 몇몇 컨텐트를 요청한다(1.). 서비스 1은 iGoogle과 같은 웹 어플리케이션일 수 있다.
요청을 충족시키기 위해, 서비스 1은 서비스 2와 서비스 3 으로부터 리소스들을 검색해야 할 수 있다(2., 4.). 서비스 2는 특정한 데이터와 같은 요청된 리소스를 제공함으로써 응답할 수 있다(3.).
서비스 1의 요청을 충족시키기 위해, 서비스 3은 OAuth 프록시일 수 있는 서비스 4 로부터 리소스를 요청해야 할 수 있다(5.).
서비스 3의 요청을 충족시키기 위해, 서비스 4는 서비스 5 로부터 리소스를 요청해야 할 수 있다(6.). 서비스 5는 요청된 리소스를 제공하기 위해 (유효 OAuth 액세스 토큰과 같은) 추가 정보를 요구한다. 정보가 활용될 수 없기 때문에, 정보는 예외 메시지로 서비스 4에 응답한다(7.). 서비스 4 (OAuth 프록시)는 요구된 정보를 얻는 방법을 찾을 필요가 있다. 요구된 정보를 얻는 것은 엔드-유저와 인터랙션(예를 들어, OAuth 토큰을 허가하기 위해 서비스 5로 브라우저를 리다이렉트)을 요구한다. 일반적으로, 이를 달성하기 위해 2개의 잠재적인 접근법들이 존재한다(8.): 서비스 4는 서비스 3과 서비스 1을 통해 브라우저로 귀로를 따르는 요구된 정보를 요청할 수 있거나, 또는 서비스 4가 브라우저를 직접적으로 접촉할 수 있다. 종래 기술은 이러한 문제에 대한 해결책을 제공하지 않는다.
본 발명의 실시예들에 따르면, 아키텍처와 워크플로우는 다음과 같다:
● 유저 인터랙션 프록시(UIP)는 브라우저(유저 에이전트)와 협력 서
비스들의 영역 사이에 상주한다. 서비스들에 대해 브라우저 사이의
모든 통신 － 요청들과 응답들 － 은 프록시를 통해 흐른다.
● 도 5의 서비스 4와 같은 서비스가 유저 인터랙션을 요구(또는 보다
상세히, 유저 인터랙션에 의해 잠재적으로 획득될 수 있는 유저로부
터 정보를 요구)할 때, 서비스는 대화(유저 인터페이스, UI)를 통신
흐름내에 삽입하기 위해 프록시를 요청한다. 대화를 삽입하기 위해
서비스가 프록시를 요청하는 방법은 변할 수 있다. 몇몇 예시적인
실시예들은 이하 더 서술된다.
● UIP가 브라우저로부터 서비스들로 모든 계류중인 요청들을 인식하
고 있기 때문에, UI를 서비스들의 협력이 초기에 트리거된 계류중인
요청에 대해 응답으로서 통신 흐름내로 삽입할 수 있다.
주목해야 할 것은 － 오픈 인터넷과는 대조적으로 － 프록시에 의존하는 개념은 외부 세계로부터 서비스들에 대한 액세스가 몇몇 컨트롤된 방법으로 일어나는 "컨트롤된" 서비스 운반 환경들에 자연스럽게 적합하다는 것이다. 일례는 서비스들에 대해 액세스가 시장에서 서비스들에 싱글 엔트리 포인트(single entry point)인 게이트웨이에 의해 컨트롤되는 SERVERY 프로젝트(http://www.celtic-initiative.org/projects/servery/)에 있어서의 서비스 시장이다. 다른 예는 모든 서비스들이 엔드-유저 인증 및 액세스 허가를 책임지고 있는 HTTP 리버스 프록시 뒤에 상주하는 컴퓨팅 클라우드에 활용된 서비스 컴포넌트들의 그룹이다. 이러한 경우들에서, 유저 인터랙션 프록시는 달리 이미 존재하는 서비스 액세스 게이트웨이의 추가적인 기능이다.
이어서, 도 5에 서술된 예시적인 아키텍처를 참조하여, 본 발명의 몇몇 실시예들이 보다 더 상세히 기술되며, 여기서 상기 본 명세서에 기술된 바와 같이 유저 인터랙션 프록시(UIP)는 브라우저와 서비스 1 사이에 삽입된다.
A) 동기 변형:
본 변형에서, 유저 인터랙션을 필요로 하는 서비스는 유저 인터랙션 프록시를 동기적으로 접촉하고 유저 인터랙션이 완료될 때까지 대기한다.
도 6은 HTTP 메시지 교환들에 의한 실시예를 예시한다. 단계 1 내지 단계 8은 도 5의 단계 1 내지 단계 7과 동일하며, 여기서 UIP의 삽입 때문에 도 5의 단계 1은 도 6의 단계 1 과 단계 2로 분할된다. 단계 8은 단계 7에서 응답 요청에 응답하여 (도 2와 도 3의 위치 소스에 대응하는) 서비스 5에 의해 리턴된 401 비허가 메시지의 운반을 표시한다.
서비스 4는 엔드-유저 인터랙션을 "갑자기" 필요로 하며, 따라서 서비스 4는 유저 인터랙션 프록시(UIP)를 접촉하고(9) UI를 유저 인터랙션 프록시(UIP)로 건네준다. UIP는 UI를 브라우저로 리턴하며(10), 유저는 요구된 데이터를 입력하고, 브라우저는 프록시로 응답을 제출하고(11), 그리고 궁극적으로 프록시는 요청된 입력, 즉, 유저 증명서들과 같은 유저 정보와 함께 서비스 4로 리턴한다(12).
유저 입력을 수신한 후, 서비스 4는 유저 입력을 이용해 서비스 5로부터 리소스를 다시 요청한다(13.). 그 다음, 서비스 5는 서비스 4로 요청된 리소스를 제공한다(14.). 그 후에, 서비스들(4, 3 및 1)은 통상의 방식으로 (UIP를 통해) 브라우저로 다시 각각의 리소스들을 전파한다(15.-18.).
인증 프록시(서비스 4)가 UIP의 어드레스를 어떻게 알 수 있는지 두 가지 옵션들이 존재할 수 있다: UIP의 어드레스는 인증 프록시내에 사전구성될 수 있거나, 또는 어드레스가 서비스 체인을 통해 요청과 함께 운반된다. 이것은 UIP가 자신 소유의 어드레스를 이야기하는 포워드된 HTTP 요청내에 특별한 HTTP 헤더를 삽입한다는 점에서 달성될 수 있다. 예를 들어 :
GET .../my-desktop HTTP/1.1
X-User-Interaction-Proxy : http://. ../ uip
Host : ...
이러한 변형에서, 서비스 1도 서비스 2 또는 서비스 3 어느 서비스도 유저와 인터랙션이 요구되며 진행중이라는 것을 인식하지 못한다. 특히, 유저 정보는 서비스들 1 내지 3을 통해 건네지지 않으며, 잠재적인 보안 위협이 방지된다.
이러한 해결책은 서비스 4로부터 유저 인터랙션 프록시로 콜(9)의 동기 성질로부터 이어지는 문제를 야기할 수 있다. － 서비스 4 자신을 포함하는 － 프록시로부터 서비스 4로 콜 체인(2, 5, 6) 내 모든 서비스들은 유저 인터랙션이 완료되기를 대기중이다. 즉, 체인 내 요청들에 할당된 실행의 스레드들이 차단된다. 실제 활용들에서, 웹 서버들과 서브렛 컨테이너들은 고정된 수의 스레드들을 갖는 스레드 풀들을 이용할 수 있으며, 수는 전형적으로 수백의 범위 내에 속한다(200-800; 예를 들어, http://www.springsource.com/flies/uploads/tomcat/tomcatx- performance-tuning.pdf,를 참조). 그래서, － 엔드-유저 응답을 기다리는 － 수백의 계류중인 요청들이 서버를 차단할 수 있다("스레드 풀 소진"). (유저 인터랙션없는) 웹 서버들의 응답 시간은 대략 밀리초들(milliseconds)인 반면에, 유저들의 응답 시간은 최상의 경우에 대략 초(second)이다. 그러나, (예를 들어, 무엇인가를 하거나 컴퓨터로부터 떨어져 있는) 유저들은 때때로 설사 있다고 하더라도 즉시 답하지 못한다.
이러한 문제는 이하 서술된 바와 같이 본 발명의 실시예들의 비동기 변형들에 의해 극복될 수 있다:
B) 재시도 핸들을 갖는 비동기 변형:
이러한 변형에서, － 유저 인터랙션을 필요로 하는 － 서비스로부터 유저 인터랙션 프록시로의 동기 콜(또는 도 5의 서비스 4와 같은 자신의 관련된 인증 프록시)은 재시도와 콜백(서비스를 호출하는 프록시)으로 교체된다.
이러한 변형의 실시예는 도 7에 도시된다. 단계 1 내지 단계 8은 도 6의 대응하는 단계들과 동일하다.
이제 서비스 4는 특별한 응답과 함께 서비스 3으로 즉시 리턴하며(9.), 그리고 이러한 특별한 응답은 콜 체인내 서비스들(예에서 : 서비스 1과 서비스 3)에 의해 유저 인터랙션 프록시로 다시 전파된다(10, 11). 특별한 응답은 또한 서비스 4의 영역내 경우를 고유하게 식별하는 핸들을 포함한다.
프록시는 특별한 응답을 인식하며 특별한 응답을 브라우저로 다시 전파하지 않는다; 대신에, 프록시는 필요한 UI를 검색하기 위해(13.), 핸들을 추출하고 서비스 4를 직접 접촉하여(12.), 핸들을 건넨다. 그 다음 프록시는 UI를 브라우저로 전송하고(14.), 입력을 수신하며(15.), 그리고 서비스 4로 입력(유저 정보)을 전송한다(16.). 그 다음 유저 인터랙션 프록시는 오리지널 요청(즉, 단계 2의 요청)을 반복하여(18.), 앞서와 같이 유사한 콜 체인을 유발한다(19.-22.).
유저 정보(16.)와 반복된 요청(22.)이 수신된 후, 서비스 4는 유저 입력(23.)을 이용해 서비스 5로부터 리소스를 다시 요청한다. 그 다음, 서비스 5는 요청된 리소스를 서비스 4로 제공한다(24.). 그 후에, 서비스들(4, 3, 및 1)은 통상적인 방식으로 (UIP를 통해) 각각의 리소스들을 브라우저로 다시 전파한다(25,-28).
이러한 변형에서, UIP는 특별한 응답(예를 들어, 특별한 HTTP 401 응답)시 인증 프록시에 의해 리턴된 www-인증 헤더로부터 인증 프록시의 어드레스를 취하는 인증 프록시를 접촉할 수 있다. 따라서, 인증 프록시는 UIP의 어드레스를 알 필요가 없다.
유저 식별이 UIP로부터 서비스들(서비스들 1 내지 4)의 체인을 통해 운반되며, 그리고 유저 식별이 유저 정보내에 포함되면, 서비스 4는 예를 들어 유저 식별에 의해 수신된 유저 정보와 반복된 요청을 상관시킬 수 있다.
이러한 방식으로, 유저 정보는 서비스 1 내지 서비스 3을 통해 건네지지 않으며, 잠재적인 보안 위협이 회피된다. 게다가, 제 1 요청 체인(단계 2. 내지 단계 7.)의 오픈 스레드들은 웹서비스들을 위한 통상적인 응답 시간, 즉, 밀리초들내에 종료되어, 서버들이 차단되지 않는다.
유저 정보가 충분히 긴 수명을 가지면, 유저 정보는 동일한 유저의 여러 요청들을 위해 사용될 수 있다. 따라서, 인증 프록시(서비스 4)가 안전하면, 유저는 각각의 요청에 대해 자신의 유저 정보를 한 번도 입력할 필요가 없으며, 유저 편의가 보안을 손상하지 않고 달성된다. 다른 면에서, 유저 정보가 하나의 요청에 대해서만 유효이면, 유저 정보는 UIP로부터 인증 프록시로의 메시지 내에 대응적으로 마크될 수 있다.
몇몇 실시예들에서, 인증 프록시(도 7의 서비스 4)에서 수신된 유저 정보와 서비스 3으로부터 반복된 요청 간의 비동기 변형들을 위해 요구된 상관은 바람직하게는 인증 프록시의 영역 내에 유일해야 하는 식별자에 기초할 수 있다. 예를 들어, 핸들은 반복된 요청들(도 7의 단계 18. 내지 단계 25.)내에 포함될 수 있다. 그러나 핸들은 존재할 수 있지만 UIP로부터 인증 프록시(도 7의 단계 16.)로 유저 정보를 전송하는 메시지에 포함될 필요가 없을 수 있는데, 이는 UIP와 인증 프록시간의 이러한 대화가 단계(12)에서 핸들의 송신에 의해 트리거되기 때문이다.
따라서, 반복된 요청과 유저 정보의 모호하지 않은 상관이 달성될 수 있다. 그러나, 서비스 체인은 UIP로부터 인증 프록시로 식별자의 송신을 지원해야 한다.
이어지는 시퀀스는 HTTP 메시지들에 의해 변형 B의 하나의 가능한 구현을 예시한다. 시퀀스는 변형 B(도 7)가 OAuth 프록시 문제(도 3)에 적용되며; 단계들의 넘버링은 도 7의 메시지 넘버링과 일치하는 실시예를 도시한다. 도 7의 서비스들의 대응과 시퀀스에서 표기법들은 다음과 같다:
- 유저 인터랙션 프록시: 내 데스크탑;
- 서비스 1 : 내 데스크탑
- 서비스 3 : 위치추적기
- 서비스 5 : 위치소스
1. 브라우저는 내 데스크탑에 HTTP 요청을 발행한다. 그러나 유저 인터랙션 프록시가 브라우저와 서비스 사이에 상주하기 때문에, 유저 인터랙션 프록시는 실제로 프록시에 의해 수신된다:
GET .../my-desktop HTTP/1.1
Host: ...
2. 유저 인터랙션 프록시는 요청을 내 데스크탑으로 포워드한다:
GET .../my-desktop HTTP/1.1
Host: ...
3. ... (의도적으로 도 7의 라인에 머무르도록 공란을 남겨둠)
4. ...
5. 내 데스크탑이 위치 추적기로부터 맵을 요청한다:
GET .../location-tracker HTTP/1.1
Host: ...
6. 위치 추적기 → OAuth 프록시:
GET .../location-source?id=userl234 HTTP/1.1
Host: ...
7. OAuthProxy → 위치소스:
GET .../location-source?id=userl234 HTTP/1.1
Host: ...
8. 위치소스 --> OAuthProxy (요청이 유효 액세스 토큰을 포함하지 않았기 때문에; 토큰 인증 체계가 OAuth 사양에 의해 정의된다):
HTTP/1.1 401 Unauthorized
WWW-Authenticate: Token realm="..." error="..."
...
9. OAuthProxy → 위치추적기 :
HTTP/1.1 401 Unauthorized
WWW-Authenticate: Proxy realm="..." url="http://.../oauth-proxy/case2345"
...
방금 예로서 제공된, 허구의 체계인 프록시 인증 체계; 401 응답 코드와 조합으로, 프록시 인증 체계는 도 7에 도시된 "재시도" 응답을 구현한다; url 필드 내 케이스2345 식별자는 도 7에 도시된 "핸들"을 구현한다는 것을 주목하라.
10. 위치 추적기 → (방금 비허가 응답을 전파하는) 내 데스크탑:
HTTP/1.1 401 Unauthorized
WWW-Authenticate: Proxy realm="..."
url="http ://.../oauth-proxy/case2345"
...
11. 내 데스크탑 → 유저 인터랙션 프록시:
HTTP/1.1 401 Unauthorized
WWW-Authenticate: Proxy realm="..."
url="http :// .../oauth-proxy/case2345"
...
12. 유저 인터랙션 프록시는 프록시 인증 체계를 인식하고, WWW-인증 필드로부터 OAuth 프록시의 URL을 검색하며, 그리고 OAuth 프록시를 접촉한다:
GET .../oauth-proxy/case2345 HTTP/1.1
Host: ...
13. OAuth 프록시 → 유저 인터랙션 프록시:
HTTP/1.1 200 OK
Content-Type: text/plain
Content-Length: ...
HTTP/1.1 302 Found
Location: https ://... /location-
source/authorize? type=web_server&client_id=client 34
56&redirect_uri=https%3A%2F%2F. ..%2Foauth-
proxy/case2345
HTTP 응답(200)이 자신의 바디에 다른 HTTP 응답(302)을 포함한다는 것을 주목하라. 이런 후자의 HTTP 응답은 사실 도 7에 표시된 "ui"의 구현이다.
14. 유저 인터랙션 프록시는 수신된 메시지로부터 리다이렉션(302) 응답을 추출하고 브라우저로 리다이렉션(302) 응답을 리턴한다:
HTTP/1.1 302 Found
Location: https ://... /location-
source/authorize? type=web_server&client_id=client 34
56&redirect_uri=https%3A%2F%2F. ..%2Foauth-
proxy/case2345
...
이제 유저 인터랙션이 일어날 것이며, － OAuth 프로토콜의 성질로 인해 － 이는 도 7에 표시된 단순 "입력"보다 복잡한 형태를 취한다.
a. 브라우저 → 유저 인터랙션 프록시 → 위치 소스(요청은 또한 유저 인터랙션 프록시에 의해 프록시되지만, 여기에 별도의 단계들로 도시되지 않는다):
GET .../location-
source/authorize?type=web_server&client_id=client 34
56&redirect_uri=https%3A%2F%2F...%2Foauthproxy/
case2345 HTTP/1.1
Host : ...
b. ...
c. (OAuth에 따르면, 위치 소스는 우선 유저를 인증한다; 단계들이 도시되지 않음)
d. ...
e. 브라우저 → 유저 인터랙션 프록시 → 위치 소스 (유저는 액세스를 승인한다):
POST .../location-
source/authorize?type=web_server&client_id=client 34
56&redirect_uri=https%3A%2F%2F...%2Foauth-
proxy/case2345 HTTP/1.1
Host: ...
f. 위치 소스 → 유저 인터랙션 프록시 → 브라우저 :
HTTP/1.1 302 Found
Location: https ://.../oauth-
proxy/case2345?code=code4567
...
15. 브라우저 → 유저 인터랙션 프록시:
GET .../oauth-proxy/case2345?code=code4567 HTTP/1.1
Host: ...
16. 유저 인터랙션 프록시 → OAuth 프록시:
GET .../oauth-proxy/case2345?code=code4567 HTTP/1.1
Host: ...
둘을 초과하는 OAuth-특정한 단계들이 일어난다; OAuth 프록시는 액세스 코드(code4567)에 대한 교환으로 위치 소스로부터 액세스 토큰을 획득한다:
a. OAuth 프록시 → 위치 소스:
POST .../location-source/token HTTP/1.1
Host: ...
Content-Type: application/x-www-form-urlencoded
Content-Length: ...
grant_type=authorization_code&client_id= ...&client_
secret=...&code=code4567&redirect_uri=https%3A%2F%2
F...%2Foauth-proxy/case2345
b . 위치 소스 → OAuth 프록시:
HTTP/1.1 200 OK
Content-Type: application/json
Content-Length: ...
Cache-Control: no-store
{
"access_token":"token56789",
"expires_in":3600
}
OAuth 프록시는 나중에 사용하기 위해 수신된 액세스 토큰을 캐시한다(단계 23).
17. OAuth 프록시 → 유저 인터랙션 프록시:
HTTP/1.1 200 OK
...
18. 유저 인터랙션 프록시 → 내 데스크탑(단계 2의 요청을 반복):
GET .../my-desktop HTTP/1.1
Host: ...
19. ... (단계 3의 요청을 반복; 의도적으로 도 7의 라인에 머무르도록 공간을 남겨둠)
20. ...
21. 내 데스크탑 → 위치 추적기(단계 5의 요청을 반복) :
GET .../location-tracker HTTP/1.1
Host: ...
22. 위치 추적기 → OAuth 프록시 (단계 6의 요청을 반복):
GET .../location-source?id=userl234 HTTP/1.1
Host: ...
23. OAuth 프록시 → 위치 소스 (단계 7의 요청을 반복하지만, 이제 포함된 유효 액세스 토큰을 가짐) :
GET .../location-source?id=userl234 HTTP/1.1
Host: ...
Authorization: Token realm="..." token="token56789"
...
24. 위치 소스 → OAuth 프록시 (지오(geo)-로케이션 좌표들을 리턴) :
HTTP/1.1 200 OK
Content-Type: application/json
Content-Length: ...
Cache-Control: no-store
{
"lat": 57.502098,
"lng": 18.057159,
}
25. OAuth 프록시 → 위치 추적기 :
HTTP/1.1 200 OK
Content-Type: application/json
Content-Length: ...
Cache-Control: no-store
{
"lat": 57.502098,
"lng": 18.057159,
}
26. 위치 추적기 → 내 데스크탑 (표시된 유저의 위치를 갖는 맵을 리턴) :
HTTP/1.1 200 OK
...
27. 내 데스크탑 → 유저 인터랙션 프록시 (임베드된 맵을 갖는 데스크탑을 리턴) :
HTTP/1.1 200 OK
...
28. 유저 인터랙션 프록시 → 브라우저:
HTTP/1.1 200 OK
...
C) 트랜잭션 Id를 갖는 비동기 변형 :
본 발명의 몇몇 실시예들의 이러한 변형은 (변형 B가 했던 것처럼) "스레드 풀 소진" 문제를 회피하며 변형 B에 따른 것처럼 특별한 응답 메시지("재시도")를 필요로 하지 않는다. 더욱이, 반복된 요청과 유저 정보 사이의 모호하지 않은 상관에 이를 수 있다.
단계 1 내지 단계 8은 도 7의 단계들과 동일하다. 그러나, 단계 2 내지 단계 6에서 요청들은 UIP에 의해 발생된 트랜잭션 Id와 UIP의 영역내 유니크(unique)를 포함한다. 인증 프록시(서비스 4)가 예외 메시지를 수신할 때(8.), 인증 프록시는 UIP의 어드레스가 동기 변형으로 알려져 있는 UIP를 직접 접촉하며(9.), 그리고 유저 인터페이스와 트랜잭션 ID를 UID로 건네준다. 그 다음에만, 서비스 4는 에러 메시지를 서비스 3로 리턴하며(10.), 에러 메시지는 UIP로 다시 전파된다(11., 12.). 에러 메시지는 종래의 에러 메시지일 수 있다.
UIP는 인증 프록시로부터 메시지와 에러 메시지 둘 다 수신하며 트랜잭션 Id에 의해 이들을 상관시킬 수 있다. 따라서, UIP는 유저 인터랙션이 요구된다는 것을 알며, 변형들 A와 B에서와 같이 브라우저로부터 유저 입력을 요청하며(13., 14.), 유저 인터페이스와 트랜잭션 Id를 포함하는 자신의 메시지에 응답하여 인증 프록시로 유저 입력을 전송한다(15.).
그 다음, UIP는 동일한 트랜잭션 Id를 포함하는 서비스 1(단계 2.의 요청)로 원래의 요청을 반복한다(16. - 20.).
인증 프록시가 서비스 체인을 통해 UIP로부터 유저 정보와 반복된 요청 둘 다를 수신할 때, 인증 프록시는 트랜잭션 Id에 기초하여 이들을 상관시킬 수 있다. 그 다음, 서비스 4는 유저 입력을 이용해 서비스 5로부터 리소스를 다시 요청한다(21.). 서비스 5는 서비스 4로 요청된 리소스를 제공한다(22.). 그 후에, 서비스들(4, 3, 그리고 1)은 통상적인 방식으로 (UIP를 통해) 브라우저로 다시 각각의 리소스들을 전파한다(23. - 26.).
이러한 변형에서, 서비스 1이나 서비스 2 또는 서비스 3 어느 서비스도 유저와 인터랙션이 요구되며 진행중이라는 것을 인식하지 못한다. 특히, 유저 정보는 서비스 1 내지 서비스 3을 통해 건네지지 않으며, 잠재적인 보안 위협이 회피된다. 게다가, 제 1 요청 체인(단계 2 내지 단계 7)의 오픈 스레드들은 웹서비스들을 위한 통상적인 응답 시간, 즉 밀리초들내에 종료되어, 서버들이 차단되지 않는다.
자신의 수명동안, 트랜잭션 Id는 UIP의 영역 내에서 고유해야 한다. 또한, 반복된 요청과 유저 정보의 모호하지 않은 상관을 달성하기 위해 바람직할 수 있는 인증 프록시의 영역에서 고유한 트랜잭션 Id를 만들기 위해, 트랜잭션 Id는 바람직하게 MAC 어드레스와 같은, 네트워크에서 고유한 UIP의 식별을 포함할 수 있다.
변형 C의 몇몇 실시예들에서, 유저 정보가 동일한 유저의 여러 요청들을 위해 사용될 수 있는 것이 바람직할 수 있다. 유저 식별이 요청들과 함께 제공되면, 유저 식별은 변형 B에서와 동일한 상관에 의해 달성될 수 있다. 대안으로, 유저 식별은 유저 정보를 이용해 제 1 요청의 상관이 트랜잭션 Id에 기초하여 상관된다는 점에서 달성될 수 있다. 그 다음, 이러한 요청의 유저 식별이 검색되어 유저 정보에 연관된다. 그 다음 동일한 유저의 후속적인 요청들은 자신의 수명동안 유저 정보에 상관될 수 있다.
AJAX-기반 웹 어플리케이션들에 적응
이전 섹션들(도 6의 메시지들 10-11 그리고 도 7의 메시지들 14-15)에 기술된 바와 같이, 본 발명의 몇몇 실시예들에 따른 UI의 삽입의 옵션은 이후 명세서에서 상세히 기술된다. 많은 현대의 Web UI들은 AJAX(Asynchronous JavaScript and XML; http://en.wikipedia.org/wiki/Ajax ( programming ))에 기초하며, AJAX는 인터랙티브 웹 어플리케이션들을 생성하기 위해 클라이언트-측에 사용된 상호관련된 웹 개발 기법들의 그룹이다. Ajax를 사용하여, 웹 어플리케이션들은 기존 페이지의 디스플레이 및 행동과 간섭됨이 없이 백그라운드에서 비동기적으로 서버로부터 데이터를 검색할 수 있다. Ajax 기법의 사용은 웹 페이지들에 대한 인터랙티브 또는 동적 인터페이스들에 있어 증가를 가져올 수 있다. 데이터는 통상적으로 XMLHttpRequest 객체를 이용해 검색된다.
AJAX-기반 웹 UI들을 위해, UI의 삽입은 다음 방식으로 이루어질 수 있다. 웹 UI는, 도 6 또는 도 7의 메시지 1에 대응하는, 유저 인터랙션 프록시에 지속적으로 개방된 HTTP 연결을 유지한다. 그 다음 유저 인터랙션 프록시가 UI를 삽입하도록 요청받는 때에는 언제나, 유저 인터랙션 프록시는 계류중인 HTTP 요청에 응답하여 삽입을 한다. "스레드 풀 소진" 문제를 피하기 위해, 바람직한 해결책은 폴링(polling) 기법을 이용하는 것일 수 있다: 지속적으로 개방된 HTTP 연결을 유지하는 대신에, 클라이언트가 주기적으로 잠재적인 UI 요청을 체크한다.
도 9는 본 발명의 실시예에 따른 장치를 도시한다. 장치는 도 6 내지 도 8의 서비스 4와 같은, 인증 프록시일 수 있다. 도 10은 본 발명의 실시예에 따른 방법을 도시한다. 도 9에 따른 장치는 도 10의 방법을 수행할 수 있지만 이러한 방법에 제한되지 않는다. 도 10의 방법은 도 9의 장치에 의해 수행될 수 있지만 이러한 장치에 의해 수행되는 것에 제한되지 않는다.
장치는 제 1 수신 수단(10), 검출 수단(20), 요청 수단(30), 그리고 제 2 수신 수단(40)을 포함한다.
제 1 수신 수단(10)에 의해 수행될 수 있는 단계(S10)에 따르면, 서비스 요청은 도 6 내지 도 8의 서비스 3과 같은 제 1 파티로부터 수신된다. 검출 수단(20)에 의해 수행될 수 있는, 단계(S20)에 따르면, 상기 서비스 요청에 따르기 위해 유저 인터랙션이 요구되는지가 검출된다. 이와 같은 검출의 예는 도 6 내지 도 8의 서비스 5로부터 에러 메시지의 검출이다. 보다 상세히, 유저 인터랙션을 위한 필요는 아마 유저 인터랙션에 의해 획득될 수 있는 유저 관련 정보를 위한 필요일 수 있다.
유저 인터랙션이 필요없으면, 방법은 종료된다(단계 S25).
유저 인터랙션이 요구되면, 요청 수단(30)은 도 6 내지 도 8의 유저 인터랙션 프록시와 같은 제 2 파티로부터 유저 정보를 요청할 수 있다(단계 S30). 제 2 파티는 제 1 파티와 다르다. 요청은 예를 들어 유저 인터페이스를 포함할 수 있다.
제 2 수신 수단(40)에 의해 수행될 수 있는, 단계(S40)에서, 유저 인터랙션(보다 상세히: 유저 관련 정보)은 제 2 파티로부터 수신된다.
도 11은 본 발명의 실시예에 따른 장치를 도시한다. 장치는 도 6 내지 도 8 중 하나와 같은, 유저 인터랙션 프록시일 수 있다. 도 12는 본 발명의 실시예에 따른 방법을 도시한다. 도 11에 따른 장치는 도 12의 방법을 수행할 수 있지만 이러한 방법에 제한되지 않는다. 도 12의 방법은 도 11의 장치에 의해 수행될 수 있지만 이러한 장치에 의해 수행되는 것에 제한되지 않는다.
장치는 전송 수단(60), 제 1 수신 수단(70), 요청 수단(80), 제 2 수신 수단(90), 그리고 응답 수단(100)을 포함한다. 리소스 요청 수단(60)에 의해 수행될 수 있는 단계(S60)에 따르면, 서비스 요청은 도 6 내지 도 8의 서비스 1과 같은 제 1 디바이스로 전송된다.
제 1 수신 수단(70)에 의해 수행될 수 있는, 단계(S70)에 따르면, 단계(S60)에 따라 전송된 서비스 요청에 따르기 위해 유저 인터랙션을 위한 요청은 제 2 디바이스로부터 수신될 수 있다. 제 2 디바이스는 제 1 디바이스와 다르다.
요청을 수신하자마자, 유저 인터랙션은 도 6 내지 도 8의 브라우저와 같은 유저 인터랙션 디바이스로부터 요청된다(단계 S80). 단계(S80)는 요청 수단(80)에 의해 수행될 수 있다.
제 2 수신 수단(90)에 의해 수행될 수 있는, 단계(S90)에 따르면, 유저 인터랙션은 요청에 응답하여 수신된다. 응답 수단(100)은 제 2 디바이스로 응답을 제공한다(단계 S100). 응답은 수신된 유저 인터랙션에 기초한다.
도 13은 본 발명의 실시예에 따른 장치를 도시한다. 장치는 도 6 및 도 7의 서비스 1, 서비스 2, 그리고 서비스 3과 같은, 리소스 서버일 수 있다. 도 14는 본 발명의 실시예에 따른 방법을 도시한다. 도 13에 따른 장치는 도 14의 방법을 수행할 수 있지만 이러한 방법에 제한되지 않는다. 도 14의 방법은 도 13의 장치에 의해 수행될 수 있지만 이러한 장치에 의해 수행되는 것에 제한되지 않는다.
장치는 제 1 수신 수단(110), 요청 수단(120), 제 2 수신 수단(130), 검출 수단(140), 그리고 응답 수단(150)을 포함한다.
제 1 수신 수단(110)에 의해 수행될 수 있는 단계(S110)에 따르면, 서비스 요청은 제 1 파티로부터 수신된다. 서비스 요청을 충족시키기 위해, 요청 수단(120)에 의해 수행될 수 있는 단계(S120)에 따르면, 리소스는 제 2 파티로부터 요청된다. 제 2 파티는 제 1 파티와 다를 수 있다. 단계(S130)에 따르면, 제 2 수신 수단(130)은 리소스를 위한 요청에 대한 응답을 수신할 수 있다.
단계(S140)에서, 검출 수단(140)은 리소스를 위한 요청에 대한 응답이 재시도 메시지를 포함하는지 검출한다. 몇몇 실시예들에서, 장치는 재시도 메시지의 수신시 리소스를 위한 요청에 관련된 스레드를 종료할 수 있다. 더욱이, 단계(S140)에서 검출 수단(140)은 재시도 메시지가 핸들을 포함하는지를 체크한다.
재시도 메시지가 검출되지 않거나 재시도 메시지가 핸들을 포함하지 않으면, 방법은 종료된다(단계 S145).
그렇지 않으면, 서비스 요청에 응답하여, 핸들을 포함하는 재시도 메시지가 제 1 파티에 제공된다(S150). 이러한 단계는 응답 수단(150)에 의해 수행될 수 있다. 몇몇 실시예들에서, 서비스 요청에 관련된 스레드는 재시도 메시지에 반응하자마자 종료될 수 있다.
도 15는 본 발명의 실시예에 따른 시스템을 도시한다. 시스템은 도 6 내지 도 8의 서비스 4와 같은 제 1 리소스 장치(210)와 도 9에 도시된 장치, 그리고 도 6 내지 도 8의 유저 인터랙션 프록시와 같은 유저 인터랙션 장치(200)와 도 11에 도시된 장치를 포함한다.
유저 인터랙션 장치(200)는 제 1 리소스 장치(210)로부터 대응하는 요청에 응답하여 제 1 리소스 장치(210)로 유저 인터랙션을 제공한다.
도 16에 도시된 본 발명의 실시예에 따른 시스템은 도 15의 실시예에 대응한다. 즉, 시스템은 도 6 내지 도 8의 서비스 4와 같은 제 1 리소스 장치(210)와 도 9에 도시된 장치, 그리고 도 6 내지 도 8의 유저 인터랙션 프록시와 같은 유저 인터랙션 장치(200)와 도 11에 도시된 장치를 포함한다. 더욱이, 시스템은 제 2 리소스 장치(230)를 포함한다. 제 2 리소스 장치는, 도 6 내지 도 8의 서비스 1 내지 서비스 3과 같은, 하나 또는 하나를 초과하는 리소스들 또는 서비스들을 포함할 수 있다.
도 16의 시스템에서, 리소스를 위한 요청에 대응하는 서비스 요청은 제 2 리소스 장치(220)를 통해 유저 인터랙션 장치(200)로부터 제 1 리소스 장치(210)로 건네진다. 유저 인터랙션 장치(200)는 제 1 리소스 장치(210)로부터 수신된 유저 인터랙션을 위한 요청에 응답하여 제 1 리소스 장치(210)로 유저 정보를 제공한다.
도 16의 시스템은 예를 들어 도 6 내지 도 8에 도시된 시스템들에 대응한다.
변형 A에서 변형 B(또는 변형 C)로 도약은 "재시도+핸들(트랜잭션 ID)을 위한 실행 스레드를 트레이드하는 것"으로서 해석될 수 있거나, 또는 즉 (내부) 실행 상태(콜 스택)를 "평범한" 데이터, 즉, 핸들(트랜잭션 Id)과 서비스 4 및 유저 인터랙션 프록시에서 핸들(트랜잭션 Id)과 연관된 데이터로 "구체화(externalizing)"하는 것으로서 해석될 수 있다.
몇몇 실시예들에서, 이러한 고려에 기초하여, 웹 서비스들 연출이 활용될 수 있다: 이들 실시예들에서, 하나의 서비스가 다른 서비스에 송장을 보내는, 협력 서비스들의 세트가 존재한다. 서비스가 "고착될 때", 즉 (예를 들어, 정보가 누락되기 때문에) 상황을 처리할 방법을 모를 때에는 언제나, 서비스는 서비스내 응답내 핸들과 함께 "재시도" 응답을 리턴한다. "재시도" 응답을 수신하는 서비스는 이를 어떻게 처리할지 알거나, 알지 못한다. 후자의 경우에, 서비스는 무턱대고 자신의 콜러(caller)로 다시 응답을 전파한다. 전자의 경우에, 본 명세서의 변형 B에 따른 유저 정보 누락의 경우에 대해 상세히 서술된 바와 같이, 서비스는 상기 경우를 처리한 다음 "고착" 서비스가 자신의 계산을 재개하도록 도움을 준다.
－ 유저 상호작용 외에 － 가능한 사용 경우들의 하나의 클래스는 서비스 웹 "딥 인사이드" 서비스가 몇몇 추가적인 맥락 정보를 요구하는 경우이다. 예를 들어, 상기 서비스는 유저가 수행될 요청된 서비스를 위해 충분한 신용을 갖는다는 신뢰된 소스로부터 주장을 누락할 수 있다(구성 서비스가 SMS를 전송하는 단계를 포함할 수 있다). 다른 예는 서비스가 트랜잭션 환경 내에서 수행될 동작을 기대하는 것이지만, 이는 존재하지 않는다. 엔드-유저들이 이미 활용가능한 서비스 엘리먼트들 또는 인에이블러들, 또는 기타 유저들의 서비스들로부터 새로운 서비스들을 구성할 수 있을 것이기 때문에 이와 같은 사용 경우들은 더욱더 빈번하게 일어날 것으로 예상되며, 이것이 SERVERY 프로젝트의 하나의 핵심 드라이버이다.
몇몇 실시예들이 http 프로토콜에 대하여 기술된다. 그러나, 다른 실시예들에서 다른 프로토콜들은 요청-응답 프로토콜들인 한 사용될 수 있으며, 여기서 "요청기는 요청을 수신하고 처리하는 응답기 시스템으로 요청 메시지를 전송하며, 궁극적으로 응답으로 메시지를 리턴한다" (http://en.wikipedia.org/wiki/Request- response ).
도 6 내지 도 8의 실시예들에서, 서비스 4는 유저 인터페이스를 제공함으로써 유저 인터랙션 프록시로부터 유저 인터랙션을 요청한다. 몇몇 실시예들에서, 요청은 유저 인터페이스 또는 유저 인터페이스를 제공하기 위한 다른 정보 엘리먼트에 대해 기준을 포함할 수 있다. 예는 상기 도 7에 대하여 서술된 메시지 흐름으로 제공된다: 메시지 흐름의 단계(13)에서, HTTP 응답(200)은 자신의 보디 내에 다른 HTTP 응답(302)을 포함한다. 이러한 후자의 HTTP 응답은 유저 인터페이스(UI)를 제공하기 위한 정보 엘리먼트의 구현이다. 따라서, 리턴된 컨텐트는 UI 자체가 아니라, UIP가 컨텐트를 브라우저로 전파한 후, 브라우저가 서비스 5로 리다이렉트하고 차례로 UI 자체를 리턴할 HTTP 리다이렉트 메시지이다(즉, 문제: "당신은 당신의 데이터를 액세스하기 위해 [서비스 3]을 허가하는가?").
상기 실시예들에 따라서와 같이 예외 메시지에 의해 인증을 위한 요청을 트리거하는 것 대신에 또는 추가하여, 다른 조건들이 본 발명의 실시예들에 따른 워크플로우를 트리거할 수 있다: 예를 들어, 서비스 4는 서비스 5가 유저 인터랙션을 요구한다는 표시를 포함할 수 있다. 따라서, 서비스 4는 서비스 5로부터 리소스를 요청할 필요없이 즉시 유저 정보의 획득을 처리할 필요가 있으며, 그 다음에만 획득된 유저 정보를 이용해 서비스 5로부터 리소스를 요청한다.
UID로부터 인증 프록시로 건네진 유저 정보는 무한 수명 또는 사전정의된 유한 수명을 가질 수 있고/있거나, 사전정의된 수의 요청들을 위해 이용가능할 수 있다.
달리 설명되지 않고 문맥으로부터 달리 분명해지지 않는 한, 두 엔티티들이 다르다는 설명은 두 엔티티들이 통신 네트워크에서 다르게 다루어진다는 것을 의미한다. 이것은 두 엔티티들이 반드시 상이한 하드웨어에 기초한다는 것을 의미하지 않는다. 즉, 본 상세한 설명에 기술된 엔티티들의 각각은 상이한 하드웨어에 기초할 수 있거나, 또는 엔티티들의 몇몇 또는 전부는 동일한 하드웨어에 기초할 수 있다.
따라서 상기 상세한 설명에 따르면, 본 발명의 예시적인 실시예들은, 이와 같은 컴퓨터 프로그램(들)을 보유하고 컴퓨터 프로그램 물건(들)을 형성하는 매체들뿐만 아니라 예를 들어 OAuth 프록시와 같은 인증 프록시, 또는 이들의 컴포넌트, 동일물을 구현하는 장치, 동일물을 제어 및/또는 동작하기 위한 방법, 그리고 동일물을 제어 및/또는 동작하는 컴퓨터 프로그램(들)을 제공한다는 것이 분명할 것이다. 본 발명의 추가 예시적인 실시예들은, 이와 같은 컴퓨터 프로그램(들)을 보유하고 컴퓨터 프로그램 물건(들)을 형성하는 매체들뿐만 아니라 이와 같은 컴퓨터 프로그램(들)을 보유하는 매체들과 동일물을 제어 및/또는 동작하는 컴퓨터 프로그램 물건(들)을 형성할 뿐만 아니라 예를 들어 유저 인터랙션 프록시, 또는 이들의 컴포넌트, 동일물을 구현하는 장치, 동일물을 제어 및/또는 동작하기 위한 방법, 그리고 동일물을 제어 및/또는 동작하는 컴퓨터 프로그램(들)을 제공한다. 여전히 본 발명의 추가의 예시적인 실시예들은, 이와 같은 컴퓨터 프로그램(들)을 보유하고 컴퓨터 프로그램 물건(들)을 형성하는 매체들뿐만 아니라 이와 같은 컴퓨터 프로그램(들)을 보유하고 동일물을 제어 및/또는 동작하는 컴퓨터 프로그램 물건(들)을 형성할 뿐만 아니라 예를 들어 리소스 서버, 또는 이들의 컴포넌트, 동일물을 구현하는 장치, 동일물을 제어 및/또는 동작하기 위한 방법, 그리고 동일물을 제어 및/또는 동작하는 컴퓨터 프로그램(들)을 제공한다.
상기 기술된 블록들, 장치들, 시스템들, 기법들 또는 방법들 중 임의의 구현들은, 비 제한적인 예들로서, 하드웨어, 소프트웨어, 펌웨어, 특수 목적 회로들 또는 로직, 범용 하드웨어 또는 컨트롤러 또는 다른 컴퓨팅 디바이스들, 또는 이들의 몇몇 조합으로서 구현들을 포함한다.
제안된 해결책은 협력 서비스들의 웹 내부의 서비스들 중 임의의 서비스에 의해 트리거된 유저 인터랙션에 대처할 수 있다. － 종래 기술 섹션에 리스트 된 해결책들에서와 달리 － 변형 A와 변형 C에 따른 실시예들에서, 기타 서비스들 중 어느 서비스도 유저 인터랙션이 일어나고 있음을 알아채지 못하고, 서비스 개발자들의 어깨의 이러한 부담이 덜어지고, 따라서 서비스 개발이 간단해 진다. 변형 A에 따르면, 이러한 엘레강스의 대가는 "스레드 풀 소진" 문제이며, 변형 C에 따른 이러한 엘레강스의 대가는 트랜잭션 Id 전송의 요구이다. 변형 B와 변형 C의 실시예들은 "스레드 풀 소진" 문제에 대처한다; 이러한 향상의 대가는 콜 체인내 서비스들이 당업자가 "재시도"(변형 B)로 표시하거나 또는 트랜잭션 Id의 송신(변형 C)을 갖는 특별한 응답 타입에 대처할 수 있어야 한다는 것이다.
상기 기술된 것은 본 발명의 바람직한 실시예들에서 현재 고려되는 것이라는 것이 이해될 것이다. 그러나, 주목해야 할 것은 바람직한 실시예들의 상세한 설명은 예로서만 제공되며 다양한 변경들이 첨부된 청구항들에 의해 정해진 바와 같이 본 발명의 범주를 벗어남이 없이 이루어질 수 있다는 것이다.

Claims (49)

  1. 제 1 파티로부터 서비스 요청을 수신하기 위한 제 1 수신 수단;
    상기 서비스 요청에 따르기 위해 유저 인터랙션(user interaction)을 위한 요구를 검출하기 위한 검출 수단;
    상기 제 1 파티와 다른 제 2 파티로부터 상기 유저 인터랙션을 요청하기 위한 요청 수단; 그리고
    상기 제 2 파티로부터 응답으로서 상기 유저 인터랙션을 수신하기 위한 제 2 수신 수단
    을 포함하는,
    장치.
  2. 제 1 항에 있어서,
    유저 인터랙션을 위한 상기 요청은 상기 유저 인터랙션을 실행하기 위해 유저 인터페이스를 제공하기 위한 정보 엘리먼트를 포함하는,
    장치.
  3. 제 1 항 내지 제 2 항 중 어느 한 항에 있어서,
    상기 서비스 요청에 따르기 위해 리소스 디바이스로부터 제 2 리소스를 요청하기 위한 리소스 요청 수단을 더 포함하며; 여기서
    상기 검출 수단은 리소스를 위한 요청에 응답하여 상기 리소스 디바이스로부터 수신된 예외 정보에 기초하여 유저 인터랙션을 위한 상기 요구를 검출하도록 적응된,
    장치.
  4. 제 1 항 내지 제 3 항 중 어느 한 항에 있어서,
    상기 유저 인터랙션은 상기 서비스 요청이 상기 제 1 파티로부터 수신되도록 야기한 유저로부터 요청되는,
    장치.
  5. 제 1 항 내지 제 4 항 중 어느 한 항에 있어서,
    유저 인터랙션을 위한 상기 요청은 상기 서비스 요청의 식별을 포함하는,
    장치.
  6. 제 1 항 내지 제 5 항 중 어느 한 항에 있어서,
    상기 요청 수단은, 상기 유저 인터랙션을 위한 상기 요청과 함께, 트랜잭션 식별자를 제공하도록 적응되며, 여기서 상기 트랜잭션 식별자는 상기 제 1 파티로부터 수신된 상기 서비스 요청내에 포함되는,
    장치.
  7. 제 1 항 내지 제 6 항 중 어느 한 항에 있어서,
    상기 제 1 파티에 응답하기 위한 응답 수단을 더 포함하며, 여기서
    상기 응답은, 상기 서비스 요청에 순응하여, 상기 제 1 파티내 서비스 실행을 중단하기 위한 트리거를 포함하는,
    장치.
  8. 제 1 항 내지 제 4 항 중 어느 한 항에 있어서,
    상기 제 1 파티로부터 수신된 상기 서비스 요청에 관련되는 핸들(handle)을 발생하기 위한 핸들 발생 수단 － 여기서, 상기 핸들은 장치의 영역에서 고유함 －;
    상기 핸들을 포함하는 핸들 메시지가 상기 제 2 파티로부터 상기 장치에 의해 수신되는지를 검출하기 위한 핸들 검출 수단을 더 포함하며; 여기서
    상기 핸들 메시지가 검출되면 상기 요청 수단은 상기 유저 인터랙션을 요청하도록 적응된,
    장치.
  9. 제 8 항에 있어서,
    상기 핸들 메시지에 기초하여 상기 제 2 파티를 식별하기 위한 식별 수단을 더 포함하는,
    장치.
  10. 제 8 항 내지 제 9 항 중 어느 한 항에 있어서,
    상기 서비스 요청은 제 1 유저 식별을 포함하며, 상기 장치는 상기 제 2 서비스 요청 내 포함된 제 2 식별에 기초하여 상기 제 1 파티로부터의 제 2 서비스 요청을 상기 수신된 유저 인터랙션과 상관시키기 위한 상관 수단을 더 포함하는,
    장치.
  11. 제 1 항 내지 제 10 항 중 어느 한 항에 따른 장치를 포함하는 리소스 액세스 프록시.
  12. 제 1 디바이스로 서비스 요청을 전송하기 위한 전송 수단;
    상기 서비스 요청에 따르기 위해 상기 제 1 디바이스와 다른 제 2 디바이스로부터 유저 인터랙션을 위한 요청을 수신하기 위한 제 1 수신 수단;
    유저 인터랙션 디바이스로부터 상기 유저 인터랙션을 요청하기 위한 요청 수단;
    상기 유저 인터랙션 디바이스로부터 상기 유저 인터랙션을 수신하기 위한 제 2 수신 수단; 그리고
    유저 인터랙션을 위한 상기 요청에 대해, 상기 유저 인터랙션 디바이스로부터 수신된 상기 유저 인터랙션에 기초하여 응답하기 위한 응답 수단
    을 포함하는,
    장치.
  13. 제 12 항에 있어서,
    상기 서비스 요청은 상기 서비스 요청을 전송하는 상기 디바이스의 식별을 포함하는,
    장치.
  14. 제 12 항 내지 제 13 항 중 어느 한 항에 있어서,
    상기 유저 인터페이스로부터 상기 서비스 요청을 수신하기 위한 제 3 수신 수단을 더 포함하는,
    장치.
  15. 제 12 항 내지 제 14 항 중 어느 한 항에 있어서,
    유저 인터랙션을 위한 상기 요청에 대해 상기 응답은 상기 제 1 디바이스로 상기 서비스 요청의 제 2 전송을 트리거하도록 적응된,
    장치.
  16. 제 12 항 내지 제 15 항 중 어느 한 항에 있어서,
    상기 서비스 요청에 응답하여 핸들을 포함하는 재시도 메시지를 수신하기 위한 제 4 수신 수단;
    상기 제 2 디바이스로 상기 핸들을 포함하는 핸들 메시지를 제공하기 위한 핸들 메시지 제공 수단을 더 포함하며; 여기서
    상기 제 2 수신 수단은 상기 핸들 메시지의 상기 제공에 응답하여 유저 인터랙션을 위한 상기 요청을 수신하도록 적응된,
    장치.
  17. 제 16 항에 있어서,
    상기 핸들을 포함하는 상기 수신된 재시도 메시지에 기초하여 상기 제 2 디바이스를 식별하기 위한 식별 수단을 더 포함하는,
    장치.
  18. 제 12 항 내지 제 15 항 중 어느 한 항에 있어서,
    유저 인터랙션을 위한 상기 요청은 상기 서비스 요청의 식별을 포함하는,
    장치.
  19. 제 18 항에 있어서,
    상기 서비스 요청을 위한 식별자를 발생하기 위한 식별자 발생 수단을 더 포함하며, 여기서 유저 인터랙션을 위한 상기 요청에 대해 상기 응답은 상기 서비스 요청의 상기 식별자를 포함하는,
    장치.
  20. 제 19 항에 있어서,
    상기 서비스 요청에 응답하여 에러 메시지를 수신하기 위한 제 5 수신 수단;
    상기 식별자에 기초하여 상기 에러 메시지를 유저 인터랙션을 위한 상기 요청과 상관시키기 위한 상관 수단
    을 더 포함하는,
    장치.
  21. 제 12 항 내지 제 20 항 중 어느 한 항에 따른 장치를 포함하는 유저 인터랙션 프록시.
  22. 제 1 파티로부터 서비스 요청을 수신하기 위한 제 1 수신 수단;
    상기 서비스 요청을 충족시키기 위해, 제 2 파티로부터 리소스를 요청하기 위한 요청 수단;
    상기 리소스를 위한 상기 요청에 대한 응답을 수신하기 위한 제 2 수신 수단;
    상기 리소스를 위한 상기 요청에 순응하여, 상기 응답이 핸들과 서비스 실행을 중단하기 위한 트리거를 포함하는 제 1 재시도 메시지를 포함하는지를 검출하기 위한 검출 수단;
    상기 서비스 요청에 순응하여, 상기 응답이 상기 제 1 재시도 메시지라는 것을 상기 검출 수단이 검출하면, 상기 핸들과 서비스 실행을 중단하기 위한 트리거를 포함하는 제 2 재시도 메시지에 의해 상기 서비스 요청에 응답하기 위한 응답 수단
    을 포함하는,
    장치.
  23. 제 1 파티로부터 서비스 요청을 수신하기 위한 수신 수단;
    상기 서비스 요청을 충족시키기 위해, 제 2 파티로부터 리소스를 요청하기 위한 요청 수단을 포함하며; 여기서
    상기 서비스 요청은 식별자를 포함하고; 그리고
    상기 리소스를 위한 상기 요청은 상기 식별자를 포함하는,
    장치.
  24. 제 22 항과 제 23 항 중 어느 한 항에 따른 장치를 포함하는,
    리소스 서버.
  25. 제 1 항 내지 제 10 항 중 어느 한 항에 따른 제 1 리소스 장치; 그리고
    제 12 항 내지 제 20 항 중 어느 한 항에 따른 유저 인터랙션 장치를 포함하고,
    상기 제 1 리소스 장치의 상기 제 2 파티는 상기 유저 인터랙션 장치를 포함하고;
    상기 유저 인터랙션 장치의 상기 제 2 디바이스는 상기 제 1 리소스 장치를 포함하며;
    상기 제 1 리소스 장치의 상기 유저 인터랙션을 위한 상기 요청은 상기 유저 인터랙션 장치의 유저 인터랙션을 위한 상기 수신된 요청이고; 그리고
    상기 유저 인터랙션 장치의 유저 인터랙션을 위한 상기 유저 요청에 대한 상기 응답은 상기 제 1 리소스 장치에 의해 수신된 상기 유저 인터랙션인,
    시스템.
  26. 제 25 항에 있어서,
    제 22 항 내지 제 23 항 중 어느 한 항에 따른 제 2 리소스 장치를 더 포함하며; 여기서
    상기 제 1 리소스 장치의 상기 제 1 파티는 상기 제 2 리소스 장치를 포함하고;
    상기 유저 인터랙션 장치의 상기 제 1 디바이스는 상기 제 2 리소스 장치를 포함하며;
    상기 유저 인터랙션 장치에 의해 전송된 상기 서비스 요청은 상기 제 2 리소스 장치에 의해 수신된 상기 서비스 요청이고; 그리고
    상기 제 2 리소스 장치의 상기 리소스를 위한 상기 요청은 상기 제 1 리소스 장치에 의해 수신된 상기 서비스 요청인,
    시스템.
  27. 제 1 파티로부터 서비스 요청을 수신하는 단계;
    상기 서비스 요청에 따르기 위해 유저 인터랙션을 위한 요구를 검출하는 단계;
    상기 제 1 파티와 다른 제 2 파티로부터 상기 유저 인터랙션을 요청하는 단계; 그리고
    상기 제 2 파티로부터 응답으로서 상기 유저 인터랙션을 수신하는 단계
    를 포함하는,
    방법.
  28. 제 27 항에 있어서,
    유저 인터랙션을 위한 상기 요청은 상기 유저 인터랙션을 실행하기 위해 유저 인터페이스를 제공하기 위한 정보 엘리먼트를 포함하는,
    방법.
  29. 제 27 항 내지 제 28 항 중 어느 한 항에 있어서,
    상기 서비스 요청에 따르기 위해 리소스 디바이스로부터 제 2 리소스를 요청하는 단계를 더 포함하며; 여기서
    상기 검출 단계는 상기 리소스를 위한 상기 요청에 응답하여 상기 리소스 디바이스로부터 수신된 예외 정보에 기초하여 유저 인터랙션을 위한 상기 요구를 검출하도록 적응된,
    방법.
  30. 제 27 항 내지 제 29 항 중 어느 한 항에 있어서,
    상기 유저 인터랙션은 상기 서비스 요청이 상기 제 1 파티로부터 수신되도록 야기한 유저로부터 요청되는,
    방법.
  31. 제 27 항 내지 제 30 항 중 어느 한 항에 있어서,
    유저 인터랙션을 위한 상기 요청은 상기 서비스 요청의 식별을 포함하는,
    방법.
  32. 제 27 항 내지 제 31 항 중 어느 한 항에 있어서,
    상기 요청 단계는, 상기 유저 인터랙션을 위한 상기 요청과 함께, 트랜잭션 식별자를 제공하도록 적응되며, 여기서 상기 트랜잭션 식별자는 상기 제 1 파티로부터 수신된 상기 서비스 요청내에 포함되는,
    방법.
  33. 제 27 항 내지 제 32 항 중 어느 한 항에 있어서,
    상기 제 1 파티에 응답하는 단계를 더 포함하며, 여기서
    상기 서비스 요청에 순응하여, 상기 응답은 상기 제 1 파티내 서비스 실행을 중단하기 위한 트리거를 포함하는,
    방법.
  34. 제 27 항 내지 제 30 항 중 어느 한 항에 있어서,
    상기 제 1 파티로부터 수신된 상기 서비스 요청에 관련되는 핸들을 발생하는 단계 － 여기서 상기 핸들은 상기 방법을 수행하는 상기 장치의 영역에서 고유함 －;
    상기 핸들을 포함하는 핸들 메시지가 상기 제 2 파티로부터 상기 장치에 의해 수신되는지를 검출하는 단계; 여기서
    상기 핸들 메시지가 검출되면 상기 요청 단계는 상기 유저 인터랙션을 요청하도록 적응된,
    방법.
  35. 제 34 항에 있어서,
    상기 핸들 메시지에 기초하여 상기 제 2 파티를 식별하는 단계를 더 포함하는,
    방법.
  36. 제 34 항 내지 제 35 항 중 어느 한 항에 있어서,
    상기 서비스 요청은 제 1 유저 식별을 포함하며, 상기 방법은 상기 제 2 서비스 요청 내 포함된 제 2 식별에 기초하여 상기 제 1 파티로부터의 제 2 서비스 요청을 상기 수신된 유저 인터랙션과 상관시키는 단계를 더 포함하는,
    방법.
  37. 제 1 디바이스로 서비스 요청을 전송하는 단계;
    상기 서비스 요청에 따르기 위해 상기 제 1 디바이스와 다른 제 2 디바이스로부터 유저 인터랙션을 위한 요청을 수신하는 단계;
    유저 인터랙션 디바이스로부터 상기 유저 인터랙션을 요청하는 단계;
    상기 유저 인터랙션 디바이스로부터 상기 유저 인터랙션을 수신하는 단계; 그리고
    유저 인터랙션을 위한 상기 요청에 대해, 상기 유저 인터랙션 디바이스로부터 수신된 상기 유저 인터랙션에 기초하여 응답하는 단계
    를 포함하는,
    방법.
  38. 제 37 항에 있어서,
    상기 서비스 요청은 상기 서비스 요청을 전송하는 상기 디바이스의 식별을 포함하는,
    방법.
  39. 제 37 항 내지 제 38 항 중 어느 한 항에 있어서,
    상기 유저 인터페이스로부터 상기 서비스 요청을 수신하는 단계를 더 포함하는,
    방법.
  40. 제 37 항 내지 제 39 항 중 어느 한 항에 있어서,
    유저 인터랙션을 위한 상기 요청에 대한 상기 응답은 상기 제 1 디바이스로 상기 서비스 요청의 제 2 전송을 트리거하는,
    방법.
  41. 제 37 항 내지 제 40 항 중 어느 한 항에 있어서,
    상기 서비스 요청에 응답하여 핸들을 포함하는 재시도 메시지를 수신하는 단계;
    상기 제 2 디바이스로 상기 핸들을 포함하는 핸들 메시지를 제공하는 단계를 더 포함하며; 여기서
    유저 인터랙션을 위한 상기 요청은 상기 핸들 메시지의 상기 제공에 응답하여 수신되는,
    방법.
  42. 제 41 항에 있어서,
    상기 핸들을 포함하는 상기 수신된 재시도 메시지에 기초하여 상기 제 2 디바이스를 식별하는 단계를 더 포함하는,
    방법.
  43. 제 37 항 내지 제 40 항 중 어느 한 항에 있어서,
    유저 인터랙션을 위한 상기 요청은 상기 서비스 요청의 식별을 포함하는,
    방법.
  44. 제 43 항에 있어서,
    상기 서비스 요청을 위한 식별자를 발생하는 단계를 더 포함하며, 여기서
    유저 인터랙션을 위한 상기 요청에 대한 상기 응답은 상기 서비스 요청의 상기 식별자를 포함하는,
    방법.
  45. 제 44 항에 있어서,
    상기 서비스 요청에 응답하여 에러 메시지를 수신하는 단계;
    상기 식별자에 기초하여 상기 에러 메시지를 유저 인터랙션을 위한 상기 요청과 상관시키는 단계
    를 더 포함하는,
    방법.
  46. 제 1 파티로부터 서비스 요청을 수신하기 위한 제 1 수신 수단;
    상기 서비스 요청을 충족시키기 위해, 제 2 파티로부터 리소스를 요청하기 위한 요청 수단;
    상기 리소스를 위한 상기 요청에 대한 응답을 수신하기 위한 제 2 수신 수단;
    상기 리소스를 위한 상기 요청에 순응하여, 상기 응답이 핸들과 서비스 실행을 중단하기 위한 트리거를 포함하는 제 1 재시도 메시지를 포함하는지를 검출하기 위한 검출 수단;
    상기 서비스 요청에 순응하여, 상기 응답이 상기 제 1 재시도 메시지인 것을 상기 검출 수단이 검출하면, 상기 핸들과 서비스 실행을 중단하기 위한 트리거를 포함하는 제 2 재시도 메시지에 의해 상기 서비스 요청에 대해 응답하기 위한 응답 수단
    을 포함하는,
    방법.
  47. 제 1 파티로부터 서비스 요청을 수신하기 위한 수신 수단;
    상기 서비스 요청을 충족시키기 위해, 제 2 파티로부터 리소스를 요청하기 위한 요청 수단을 포함하며; 여기서
    상기 서비스 요청은 식별자를 포함하고; 그리고
    상기 리소스를 위한 상기 요청은 상기 식별자를 포함하는,
    방법.
  48. 장치의 프로세서상에서 구동할 때, 제 27 항 내지 제 47 항 중 어느 한 항에 따른 방법을 수행하기 위해 정렬되는 소프트웨어 코드 부분들을 포함하는 프로그램을 포함하는,
    컴퓨터 프로그램 물건.
  49. 제 48 항에 있어서,
    상기 컴퓨터 프로그램 물건은 상기 소프트웨어 코드 부분들이 저장되는 컴퓨터-판독가능 매체를 포함하고/하거나, 상기 프로그램은 상기 프로세서의 메모리 내로 직접 로드 가능한,
    컴퓨터 프로그램 물건.
KR1020137018758A 2010-12-17 2010-12-17 웹 리소스들을 위한 유저 인터랙션 KR20130105714A (ko)

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/EP2010/070112 WO2012079650A1 (en) 2010-12-17 2010-12-17 User interaction for web resources

Related Child Applications (1)

Application Number Title Priority Date Filing Date
KR1020147023602A Division KR20140109507A (ko) 2010-12-17 2010-12-17 웹 리소스들을 위한 유저 인터랙션

Publications (1)

Publication Number Publication Date
KR20130105714A true KR20130105714A (ko) 2013-09-25

Family

ID=44202841

Family Applications (2)

Application Number Title Priority Date Filing Date
KR1020147023602A KR20140109507A (ko) 2010-12-17 2010-12-17 웹 리소스들을 위한 유저 인터랙션
KR1020137018758A KR20130105714A (ko) 2010-12-17 2010-12-17 웹 리소스들을 위한 유저 인터랙션

Family Applications Before (1)

Application Number Title Priority Date Filing Date
KR1020147023602A KR20140109507A (ko) 2010-12-17 2010-12-17 웹 리소스들을 위한 유저 인터랙션

Country Status (4)

Country Link
US (1) US20130268680A1 (ko)
EP (1) EP2652930A1 (ko)
KR (2) KR20140109507A (ko)
WO (1) WO2012079650A1 (ko)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20190059838A (ko) * 2017-11-23 2019-05-31 하만인터내셔날인더스트리스인코포레이티드 종속 포털 검출
KR20220069699A (ko) * 2020-11-20 2022-05-27 주식회사 카카오모빌리티 로봇장치의 원격 제어 시스템 및 방법
KR20220069698A (ko) * 2020-11-20 2022-05-27 주식회사 카카오모빌리티 Mms 원격 제어 시스템 및 방법

Families Citing this family (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2010040010A1 (en) * 2008-10-01 2010-04-08 Twilio Inc Telephony web event system and method
US8831563B2 (en) * 2011-02-04 2014-09-09 CSC Holdings, LLC Providing a service with location-based authorization
AU2012275653A1 (en) * 2011-06-27 2013-05-02 Google Inc. Persistent key access to a resources in a collection
US9237156B2 (en) * 2012-05-21 2016-01-12 Salesforce.Com, Inc. Systems and methods for administrating access in an on-demand computing environment
US9009787B2 (en) * 2012-07-25 2015-04-14 Oracle International Corporation System and method of mapping and protecting communication services with OAuth
US8806595B2 (en) 2012-07-25 2014-08-12 Oracle International Corporation System and method of securing sharing of resources which require consent of multiple resource owners using group URI's
JP2014115895A (ja) * 2012-12-11 2014-06-26 Canon Inc 情報処理装置及びその制御方法、並びにプログラム
US20160021097A1 (en) * 2014-07-18 2016-01-21 Avaya Inc. Facilitating network authentication
JP6119709B2 (ja) * 2014-09-29 2017-04-26 ブラザー工業株式会社 サービスプロバイダ装置、プログラム及びサービス提供方法
JP2016085641A (ja) * 2014-10-27 2016-05-19 キヤノン株式会社 権限移譲システム、権限移譲システムにて実行される方法、およびそのプログラム
US20230015697A1 (en) * 2021-07-13 2023-01-19 Citrix Systems, Inc. Application programming interface (api) authorization

Family Cites Families (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7111162B1 (en) * 2001-09-10 2006-09-19 Cisco Technology, Inc. Load balancing approach for scaling secure sockets layer performance
US7221935B2 (en) * 2002-02-28 2007-05-22 Telefonaktiebolaget Lm Ericsson (Publ) System, method and apparatus for federated single sign-on services
GB0419479D0 (en) * 2004-09-02 2004-10-06 Cryptomathic Ltd Data certification methods and apparatus
US8924459B2 (en) * 2005-10-21 2014-12-30 Cisco Technology, Inc. Support for WISPr attributes in a TAL/CAR PWLAN environment
JP4950589B2 (ja) * 2006-08-07 2012-06-13 株式会社東芝 接続管理システム、接続管理方法、および管理サーバ
US7912947B2 (en) * 2008-02-26 2011-03-22 Computer Associates Think, Inc. Monitoring asynchronous transactions within service oriented architecture
US8250627B2 (en) * 2008-07-28 2012-08-21 International Business Machines Corporation Transaction authorization
WO2010094331A1 (en) * 2009-02-19 2010-08-26 Nokia Siemens Networks Oy Authentication to an identity provider
EP3832975A1 (en) * 2009-05-29 2021-06-09 Alcatel Lucent System and method for accessing private digital content
US20110004926A1 (en) * 2009-07-01 2011-01-06 International Business Machines Coporation Automatically Handling Proxy Server and Web Server Authentication
US8984588B2 (en) * 2010-02-19 2015-03-17 Nokia Corporation Method and apparatus for identity federation gateway
US9189649B2 (en) * 2010-06-25 2015-11-17 International Business Machines Corporation Security model for workflows aggregating third party secure services
US8474017B2 (en) * 2010-07-23 2013-06-25 Verizon Patent And Licensing Inc. Identity management and single sign-on in a heterogeneous composite service scenario

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20190059838A (ko) * 2017-11-23 2019-05-31 하만인터내셔날인더스트리스인코포레이티드 종속 포털 검출
KR20220069699A (ko) * 2020-11-20 2022-05-27 주식회사 카카오모빌리티 로봇장치의 원격 제어 시스템 및 방법
KR20220069698A (ko) * 2020-11-20 2022-05-27 주식회사 카카오모빌리티 Mms 원격 제어 시스템 및 방법

Also Published As

Publication number Publication date
US20130268680A1 (en) 2013-10-10
KR20140109507A (ko) 2014-09-15
WO2012079650A1 (en) 2012-06-21
EP2652930A1 (en) 2013-10-23

Similar Documents

Publication Publication Date Title
KR20130105714A (ko) 웹 리소스들을 위한 유저 인터랙션
US9104848B2 (en) Cross-platform authentication from within a rich client
CN108733991B (zh) 网页应用访问方法及装置、存储介质
TWI380663B (en) Method and system for secure binding register name identifier profile
KR101572393B1 (ko) 기존 브라우저 세션 내에서 리치 클라이언트 인증하기
US8863248B2 (en) Method and apparatus to auto-login to a browser application launched from an authenticated client application
US8528066B2 (en) Methods and apparatus for enabling context sharing
EP2936768B1 (en) A system and method of dynamic issuance of privacy preserving credentials
JPH11282804A (ja) ユーザ認証機能付き通信システム及びユーザ認証方法
EP3251323B1 (en) Authentication mechanism for domain redirection of a representational state transfer (rest)-compliant client
US20140282994A1 (en) Method for calling up a client program
US9509691B2 (en) Secure transfer of web application client persistent state information into a new domain
CN103428179A (zh) 一种登录多域名网站的方法、系统以及装置
CN105991518B (zh) 网络接入认证方法及装置
WO2018183322A1 (en) Maintaining a session across multiple web applications
JP4906870B2 (ja) サーバ・サイド動的ページの実行のための方法、システム、およびコンピュータ・プログラム
JP5383923B1 (ja) 情報処理装置、情報処理システム、情報処理方法およびプログラム
CN105339928B (zh) 网站服务器请求重新路由
US8219609B1 (en) Establishing a stateful environment for a stateless environment
EP3123411B1 (en) Double-processing prevention
JP2021140821A (ja) 画面制御装置及び画面制御方法
TWI620091B (zh) 植基於worker序列化請求的認證處理方法

Legal Events

Date Code Title Description
A201 Request for examination
AMND Amendment
E902 Notification of reason for refusal
A107 Divisional application of patent
AMND Amendment
E902 Notification of reason for refusal
AMND Amendment
E601 Decision to refuse application
AMND Amendment