KR20140116422A - 서버 애플리케이션을 인증 제공자와 통합하는 기법 - Google Patents

서버 애플리케이션을 인증 제공자와 통합하는 기법 Download PDF

Info

Publication number
KR20140116422A
KR20140116422A KR1020147020076A KR20147020076A KR20140116422A KR 20140116422 A KR20140116422 A KR 20140116422A KR 1020147020076 A KR1020147020076 A KR 1020147020076A KR 20147020076 A KR20147020076 A KR 20147020076A KR 20140116422 A KR20140116422 A KR 20140116422A
Authority
KR
South Korea
Prior art keywords
application
authentication
list
issuer
token
Prior art date
Application number
KR1020147020076A
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 KR20140116422A publication Critical patent/KR20140116422A/ko

Links

Images

Classifications

    • 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/0823—Network architectures or network communication protocols for network security for authentication of entities using certificates
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00—Network arrangements, protocols or services for addressing or naming
    • H04L61/35—Network arrangements, protocols or services for addressing or naming involving non-standard use of addresses for implementing network functionalities, e.g. coding subscription information within the address or functional addressing, i.e. assigning an address to a function
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/321—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving a third party or a trusted authority
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3263—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving certificates, e.g. public key certificate [PKC] or attribute certificate [AC]; Public key infrastructure [PKI] arrangements
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2101/00—Indexing scheme associated with group H04L61/00
    • H04L2101/30—Types of network names
    • H04L2101/365—Application layer names, e.g. buddy names, unstructured names chosen by a user or home appliance name
    • 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/06—Network architectures or network communication protocols for network security for supporting key management in a packet data network
    • H04L63/062—Network architectures or network communication protocols for network security for supporting key management in a packet data network for key distribution, e.g. centrally by trusted party
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/22—Parsing or analysis of headers

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Storage Device Security (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Computer And Data Communications (AREA)
  • Information Transfer Between Computers (AREA)

Abstract

온라인 및 온프레미스 애플리케이션은 신뢰된 인증 제공자를 식별한다. 애플리케이션은 인증 크리덴셜의 신뢰된 발행자의 리스트를 이용하여 구성된다. 애플리케이션이 인증을 요구하는 요청을 수신할 경우, 애플리케이션은 신뢰된 발행자 리스트를 포함하는 401 응답을 리턴한다. 요청 애플리케이션은 401 응답으로부터의 신뢰된 발행자 리스트를 인즈 제공자의 자체 리스트와 비교한다. 두 리스트 간에 매치가 있으면, 요청 애플리케이션은 인증 제공자에 대한 자체 발행된 토큰을 생성한다. 인증 제공자는 자체 발행 토큰을 사용하여 요청 애플리케이션에 대한 인증 토큰을 생성한다. 두 애플리케이션 사이에 직접 신뢰가 존재하면, 요청 애플리케이션은 인증 제공자 없이 타겟 파트너 애플리케이션에 대한 토큰을 직접 생성할 수도 있다.

Description

서버 애플리케이션을 인증 제공자와 통합하는 기법{INTEGRATING SERVER APPLICATIONS WITH MULTIPLE AUTHENTICATION PROVIDERS}
복수의 온프레미스(on-premise) 및 온라인 환경에 걸쳐 분산되는 서버 및 서비스의 배치 토폴로지(deployment topology)가 점점 복잡해지고 있다. 애플리케이션은 이들의 배치 특징 또는 위치에 관계없이 이들 서버 및 서비스에 걸쳐 보안 액세스를 요구한다. 성공적인 보안 액세스는 일반적으로 서버 및 서비스에 의한 인증 체계(authentication scheme) 지원에 의해 관리된다. 통상적으로, 다른 서버나 서비스에 대한 요청을 하는 서버 또는 서비스는 그 요청을 인증하여 그 인증이 성공하도록 하는 방법을 알 필요가 있다.
성공적인 인증을 위해 오쓰(OAuth) 프로토콜과 같은 표준 인증 프로토콜이 서버 및 서비스에 의해 사용될 수 있다. 그러나, 그러한 표준 프로토콜은 서버 및 서비스 간에 신뢰를 쌓을 수 있는 방법을 이들에게 충분히 설명하지 못한다. 또한, 기존의 인증 프로토콜은 온라인 및 온프레미스 환경에 걸쳐있는 복잡한 배치 토폴로지를 고려하지 않는다.
예를 들어, 오쓰(AOuth) 프로토콜은 흔히, 모든 애플리케이션 및 서비스가 인증을 위한 크리덴셜(credential)을 성공적으로 획득하기 위해 신뢰하고 의존해야 하는 단일 인증 서버를 요구한다. 그러나, 많은 시나리오는 이 단일 인증 서버 개념을 사용할 수 없다.
또한, 오쓰(OAuth) 프로토콜은 프로토콜 흐름을 상세히 기술하지만, 이 프로토콜은 프로토콜의 의미 및 내용에 대한 상세를 인증 서버의 특정한 구현에 맡긴다. 이것은 인증 서버와 통합되는 서버 또는 서비스가 다른 인증 서버와 통합되는 다른 서버 또는 서비스에게 요청을 하기 위해 반드시 동일한 인증 서버를 성공적으로 사용하는 것에 의존할 수는 없다는 것을 의미한다. 많은 시나리오에서, 특히 온프레미스 시나리오에서, 서버 또는 서비스는 어떠한 인증 서버와는 전혀 통합될 수 없다.
마지막으로, 성공적인 인증 후에, 서버 및 서비스는 일반적으로 원치않은 액세스로부터 리소스들을 보호하기 위해 권한(authorization) 메커니즘을 구현한다. 일반적으로 이들 권한 메커니즘은 서비스에 대한 소유권이지만, 인증을 위해 질의된 크리덴셜의 일부분으로서 제공되는 아이덴티티(identity)에 기초한다. 오쓰 프로토콜에 의하면, 클라이언트 애플리케이션은 검증된 신뢰할 수 있는 아이덴티티이다. 클라이언트의 아이덴티티가 변하면, 권한이 재구성되어야 하고 새로운 클라어언트 애플리케이션 아이덴티티로 검증될 때까지 인증이 이용가능하지 않다.
본 요약은 이하의 상세한 설명에서 보다 자세히 설명될 개념들 중 선택된 것들을 단순화된 형태로 소개하고자 제공된다. 본 요약은 청구 대상의 필수 특성 또는 핵심 특성을 나타내고자 하는 것이 아니며, 청구 대상의 범위를 한정하기 위해 사용되는 것도 아니다.
실시예들은 서비스 및 서버 애플리케이션이 오쓰(OAuth) 2.0 프로토콜과 같은 표준 인증 프로토콜을 사용하여 성공적으로 인증하도록 하는 일반적인 모델을 제공한다. 서버 및 서비스는 상이한 프로토콜 시맨틱스를 구현하는 복수의 인증 서버와 통합될 수 있다. 다른 서버 및 서비스와 같이 클라이언트는 인증 서버가 없는 경우 표준 프로토콜을 사용하여 신뢰인측(relying party)에 액세스할 수 있다. 신뢰인측에 대해 인증하기 위해 클라이언트가 크리덴셜의 적절한 발행자를 선택할 수 있게 하는 광고 메커니즘이 신뢰인측에게 제공된다.
본 발명의 실시예의 상기 및 다른 이점들 및 특징들을 보다 명확히 하기 위해, 첨부 도면을 참조하여 본 발명의 실시예들을 보다 구체적으로 설명할 것이다. 이들 도면은 단지 본 발명의 전형적인 실시예들을 도시하며 따라서 본 발명의 범위를 제한하는 것으로 고려되어서는 안 된다. 본 발명은 첨부 도면의 사용을 통해 추가적인 특이성 및 세부사항을 기술하고 설명할 것이다.
도 1은 수락할 수 있는 인증 소스를 식별하기 위해 서로 통신하는 2개의 서비스를 도시한다.
도 2는 인증 크리덴셜의 신뢰된 발행자를 식별하기 위한 방법 또는 프로세스를 도시한다.
도 3a 및 3b는 발신 토큰(outbound token)에 대한 발행자를 선택하기 위해 발행자 매치를 이용하는 애플리케이션에 대한 발신 토큰의 구축을 위한 방법 또는 프로세스를 도시한 흐름도이다.
도 4는 도 1 내지 3의 예가 구현될 수 있는 적절한 컴퓨팅 및 네트워킹 환경의 일례를 도시한다.
도 1은 수락할 수 있는 인증 소스를 식별하기 위해 서로 통신하는 2개의 서비스(101, 102)를 도시한 것이다. 일부 실시예에서, 서비스(101, 102)는 동일 서버 및/또는 프레미스 상에 위치할 수 있으며 동일 관리자에 의해 구성될 수 있다. 다른 실시예에서, 서비스(101, 102)는 별개의 서버 및/또는 별개의 프레미스 상에서 서로 떨어져서 위치할 수 있으며 상이한 관리자에 의해 구성될 수 있다. 이러한 구성에서, 서버(101, 102)는 LAN, WAN, 인트라넷, 또는 인터넷과 같은 무선 또는 유선 네트워크를 통해 통신할 수 있다. 이들 구성은 본 명세서에서 "온프레미스(on-premise)" 구성으로 지칭될 수 있다. 서비스(101, 102)가 클라우드 내 호스팅된 환경이고 별개의 호스팅 조직에 의해 관리될 경우, 이 구성은 본 명세서에서 "온라인" 구성으로 지칭된다.
서비스(101, 102)는 상이한 애플리케이션의 별개의 인스턴스 또는 동일 애플리케이션의 별개의 인스턴스일 수 있다. 어느 경우든, 사용자는 서비스들(101, 102) 사이에서 정보 및 데이터를 공유하고자 할 수 있다. 예를 들어, 사용자는 서비스(101) 상에서 작업하고자 할 수 있고 서비스(102) 상에서 동작을 수행하거나 또는 서비스(102)를 이용하여 데이터를 교환하고자 할 수 있다. 서비스 A(101)는 그러한 동작을 수행하거나 데이터를 교환하라는 요청(103)을 서비스 B(102)에게 전송한다. 서비스 B(102)가 요청(103)에 따라 동작하기 전에, 서비스 B(102)는 요청(103)을 인증해야 한다. 서비스(101)는 인증 크리덴셜 또는 토큰의 승인된 소스를 식별하는 신뢰된 발행자 리스트(104)를 갖도록 구성된다. 이와 유사하게, 서비스(102)는 자신의 신뢰된 발행자 리스트(105)를 갖는다. 신뢰된 발행자 리스트는, 예를 들어, 하나 이상의 인증 서비스(106, 107)를 식별할 수 있다. 각각의 서비스(101, 102)는 수락할 수 있는 인증 서비스의 자체 리스트를 가질 수 있다. 예를 들어, 서비스(101)는 인증 서비스(106, 107)를 신뢰할 수 있는 반면에, 서비스(102)는 인증 서비스(107)만 신뢰할 수도 있다.
일부 직접 신뢰(direct-trust) 실시예에서, 서비스(101, 102)는 자체 인증(self-authenticate)할 수 있거나 자신의 인증 크리덴셜 또는 토큰을 생성할 수 있다.
오쓰 프로토콜과 같은 표준 인증 프로토콜이 서비스(101, 102)를 서로에게 인증하는데 사용될 수 있다. 그러나, 그러한 프로토콜은 항상 성공적이지는 않은데, 그 이유는 서비스(101, 102)가 동일한 인증 서비스(106, 107)를 공유할 수 없거나 또는 양립할 수 없는 인증 구성을 가질 수 있기 때문이다.
서버(102)가 요청(103)을 수신하는 경우, 서버(102)는 그 요청(103)이 인증을 요구함을 나타내는 401 (인가되지 않은)응답(108)을 반환한다. 클라이언트는 적절한 권한 헤더 필드를 갖는 요청(103)을 반복할 수 있다. 권한 필드 값은 요구되는 리소스의 영역(realm)에 대한 애플리케이션의 인증 정보를 포함하는 크리덴셜로 이루어진다.
일실시예에서, 401 인가되지 않은 응답(108)은 응답 서비스(102)로부터의 신뢰된 발행자 리스트(105)를 포함한다. 따라서, 응답(108)은 서비스(101)에게 요청(103)이 인증되어야 하고 서비스(101)가 필요한 인증 크리덴셜 또는 토큰을 획득할 수 있는 신뢰된 소스의 리스트를 제공한다. 서비스(101)는 신뢰된 또는 승인된 인증 서비스의 리스트(104)를 갖는다. 서비스(101)는 수신된 신뢰된 리스트(105)를 자신의 신뢰된 리스트(104)와 비교하고, 이들 두 리스트 사이의 임의의 매치(match)를 식별한다. 예를 들어, 서비스(101)가 인증 서비스(106, 107)를 신뢰하고, 서비스(102)가 인증 서비스(107)를 신뢰하면, 그 후 서비스(101)는 인증 서비스(107)를 이용하여 적절한 크리덴셜을 획득할 수 있다.
서비스(101, 102)에 대한 신뢰된 발행자 리스트(104, 105)는 선호되는 인증 소스의 계층을 식별할 수 있다. 예를 들어, 신뢰된 발행자 리스트(104)는 소스들을 (1) 동일 애플리케이션의 다른 배치의 직접 신뢰, (2) 인증 서비스(105), 및 (3) 인증 서비스(106)로 우선순위화하거나 또는 정렬한다. 일실시예에서, 서비스(101)는 자신의 리스트(104)와 수신된 리스트(105)를 비교하고 가장 선호되는 발행자를 선택할 것이다.
도 2는 인증 크리덴셜의 신뢰된 발행자를 식별하는 방법 또는 프로세스를 도시한 것이다. 단계(201)에서, 제1 서비스로부터 제2 서비스로 요청이 전송된다. 단계(202)에서, 제1 서비스가 그 요청에 대해 인증이 요구됨을 나타내는 응답을 수신한다. 이 응답은 제2 서비스에 있어서의 신뢰된 인증 발행자의 리스트를 포함한다. 단계(203)에서, 제1 서비스는 제2 서버로부터의 신뢰된 발행자의 리스트를 자신의 신뢰된 발행자의 리스트와 비교한다. 단계(204)에서, 제1 서비스는 제1 및 제2 서비스 모두에 의해 신뢰되는 인증 발행자를 식별한다.
단계(205)에서, 제1 서비스는 두 서비스에 의해 신뢰되는 인증 발행자로부터 인증 크리덴셜을 획득한다. 단계(206)에서, 제1 서비스는 인증 크리덴셜을 포함하는 새로운 요청을 생성한다. 인증 크리덴셜은 두 서비스에 의해 신뢰된 소스로부터 나오기 때문에, 제2 서비스는 통상적으로 제2 요청을 수락할 것이다.
구성( Configuration )
신뢰된 발행자 식별 프로세스에 참가하기 위해, 각각의 서버 또는 서비스는 적절한 정보를 갖도록 구성되어야 한다. 일실시예에서, 각 서버 또는 서비스에 대해 다음 정보들이 구성된다.
애플리케이션 발행자 식별자( Application Issuer Identifier ). 애플리케이션 발행자 식별자는 자체 발행된 토큰에 대한 발행자 필드에 사용된다. 애플리케이션 발행자 식별자는 PIDapp@realm의 포맷을 갖는다. 애플리케이션 발행자 식별자의 요구된 필드는 다음과 같이 포매팅된다.
PIDapp 필드는 애플리케이션에 대한 주요 식별자이다. 일실시예에서, 이것은 현재 애플리케이션을 나타내는 전역 고유 식별자(GUID; Globally Unique Identifier)이다. 다른 실시예에서, 이들 식별자에 걸쳐 고유성을 보장하는 임의의 구현이 이용될 수 있다. Realm 필드는 온프레미스 설치를 위한 디폴트 도메인일 수 있다. 온라인 설치에서, Realm 값은 테넌트 식별자일 수 있다. 그러나, 테넌트 식별자는 Realm 필드의 단지 하나의 가능한 값일 뿐이며, 다른 값으로 설정될 수도 있다.
보안 토큰 서비스( STS : Security Token Service ). 하나 이상의 STS는 또한 각 서버 또는 서비스에 대해 구성된다. 각각의 STS는 PIDsts@[ TID ], metadataURL의 포맷을 갖는다.
PIDsts 필드는 STS를 나타내는 GUID이다.
TID 필드는 다음과 같이 구성된다.
온프레미스 설치에 있어서, TID 필드는 테넌트 식별자(TenantID)이며, 이는 특정 테넌트를 식별하기 위해 고유성을 보장하는 임의의 구현 또는 GUID이다. 대부분의 온라인 설치에 있어서, TID 필드는 공란 (또는 *)이며 적절한 테넌트 ID로 대체되어야 한다. 예컨대, 동일 회사를 상이한 배치로 나타내는 테넌트들 사이의 신뢰에 필요한 특정 테넌트 내의 온라인 설치의 경우, TID 필드는 TenantID이다.
metadataURL 필드는 STS와의 신뢰 확립을 위한 인증서(certificate)를 검색하는데 사용되는 URL을 포함한다.
일부 애플리케이션은 발행자 식별자를 저장하지 않고, 대신에 키, 키 식별자(예컨대, 인증서 지문), 및 메타데이터 URL만 저장한다.
구성된 파트너 앱들. 구성된 파트너 앱들은 PIDapp@[realm],{UseSTS|metadataURL} 포맷을 갖는다.
PIDapp 필드는 다른 서버 또는 서비스와 같은 파트너 애플리케이션(PA; partner application)을 나타내는 GUID이다.
Realm 필드는 온라인 설치의 경우 공란 (또는 *)이며 적절한 테넌트 ID로 대체되어야 한다. Realm 필드는 온프레미스 설치에 있어서 디폴트 도메인을 유지한다.
이 PA에 대한 인입 토큰이 구성된 STS들 중 하나에 의해 발행되어야하는지 여부를 선택하기 위해 UseSTS 필드가 사용된다.
metadataURL 필드는 애플리케이션에 대한 직접 신뢰를 위해 인증서를 검색하는데 사용될 수 있는 URL이다.
일부 애플리케이션은 발행자 식별자를 저장하지 않고, 대신에 키, 키 식별자(예컨대, 인증서 지문), 및 메타데이터 URL만 저장한다.
유효 도메인 또는 영역 리스트( Valid Domain or Realm List ). 신뢰된 발행자 리스트는 온라인 및 온프레미스 구성에 대해 구성된다. 온라인 설치의 경우, 신뢰된 발행자 리스트는 테넌트에 의해 맵핑된 모든 테넌트 도메인 서픽스(domain suffixes)의 리스트이다. 온프레미스 설치의 경우, 신뢰된 발행자 리스트는 모든 유효 도메인 서픽스의 리스트이다.
일반적으로, 빈(empty) 영역은 "*" 영역과 동일함을 의미하도록 해석된다. "*" 엔트리는 전역 구성 템플릿을 지원하는데 사용되며, 여기서 단일 구성의 엔트리는 구성 및 저장 요건을 단순화하기 위해 수백만 개의 테넌트를 지원할 수 있다.
영역(realm)은 보안 바운다리에 대한 식별자이며, PID(principal ID)는 영역에 의해(즉, 영역에 대해 고유하게) 한정된다. TID(Tenant Id)는 영역에 대한 가능한 값의 스트링이다. TID는 데이터센터의 영역들에 대한 주요 이름이다. DNS 도메인명은 온프레미스 구성에 사용된 영역에 대한 다른 가능한 값의 스트링이다. DNS 도메인명은 오디언스(audence)/리소스 내의 영역으로서 STS에게 전송될 수 있지만, 도메인명은 STS가 발행하는 토큰 내의 TID로 대체된다.
발행자 정보의 공개.
발행자의 리스트는, 인증 헤더 내에 베어러 스킴(Bearer scheme)을 갖는 임의의 요청에 대해 인증에 실패하는 401 응답에 리턴된다.
각각의 애플리케이션 호스트는 수신할 토큰을 제공하는 신뢰된 발행자의 리스트를 구축한다. 일실시예에서, 이 리스트는 상기 구성으로부터의 모든 STS 및 신뢰와 관련하여 STS에 의존하지 않는 모든 파트너 애플리케이션(즉, 직접 신뢰를 사용할 모든 파트너 애플리케이션)을 포함한다. 일부 실시예에서, 구성 데이터 내에 발행자 식별자를 저장하지 않고 대신에 키 및 자신의 식별자만 저장하는 애플리케이션은 발행자 리스트를 구축할 수 없을 수 있다.
일실시예에서, 발행자 리스트가 애플리케이션에 의해 구축될 수 없다면, 애플리케이션은 이 경우 자신의 식별자(예컨대, client_id) 및 영역(realm)을 리턴한다. Realm 값은 테넌트 식별자일 수 있다. 발행자 리스트가 구축되면, 영역은 선택적(optional)이며 통상적으로 애플리케이션들 사이에 직접 신뢰를 갖는(즉 STS 없이) 순수한 온프레미스 배치로 제공되거나 또는 영역이 401 응답을 생성하는 엔드포인트 URL로부터 명확히 결정될 수 있다.
예를 들어, 요청은 다음과 같이 포매팅될 수 있다.
POST/리소스(resource) HTTP/1.1
인증: 베리어(Authorization: Bearer)
401 응답은 다음과 같이 "WWW - Autenticate" 헤더에 "Bearer" 인증 체계의 "trusted_issuers" 파라미터 내에 콤마로 분리된 발행자의 리스트를 갖고 있다.
인가되지 않은(Unauthorized) HTTP/1.1 401
WWW-Authenticate: Bearer trusted_issuers="PIDsts@*,PIDapp@realm",
realm="realm", client_id="PID"
온프레미스 설치는 STS 없이 온 프레미스 설치 사이에 직접 신뢰 확립을 용이하게 하기 위해 메타데이터 내에 PID, 영역, 및 인증서를 공개할 수 있다. 온라인 설치 공개는 필요치 않다.
발신 토큰의 구축( Construction of Outbound Token )
도 3a 및 3b는 발신 토큰에 대한 발행자를 선택하기 위해 발행자 매치를 이용하는 애플리케이션에 있어서의 발신 토큰의 구축을 위한 방법 또는 프로세스(300)를 도시한 흐름도이다. 프로세스(300)는 다음 입력 파라미터를 갖는다.
user@user-domain 포맷을 갖는 사용자 또는 다른 URI;
파트너 앱 식별자(Partner App Identifier)(PIDpa);
목적지 호스트(Destination Host)(pahost);
테넌트(Tenant) ID(tid); 및
특정 테넌트에 대한 엔트리 및 전역 STS를 포함하는 발신 STS의 리스트(온라인 전용).
단계(301)에서, trusted _ issuers 파라미터가 실패한 요청에 대한 응답으로 수신되는 401 응답에 포함되는지 여부를 판정하는데, 여기서 요청은 "Bearer" 스킴을 갖는다. 단계(302)에서, 애플리케이션은 WWW-인증 헤더의 trusted _ issuers 파라미터로부터 발행자의 리스트(즉, 인입 발행자 리스트)를 획득한다. trusted_issuers 파라미터가 401 응답 메시지 내의 WWW-인증 헤더에 존재하지 않으면, 프로세스는 312로 진행한다.
단계(303)에서, 애플리케이션은 인입 발행자 리스트 내의 발행자들 중 하나가 로컬 애플리케이션 발행자 식별자(PIDapp@realm)와 매치되는지 판정한다. 일실시예에서, 모든 PID 및 영역 컴포넌트는 인입 리스트 상의 발행자와 로컬 애플리케이션 발행자 식별자 간에 정확히 매치되어야 한다.
PID 및 영역 컴포넌트가 단계(303)에서 매치되면, 프로세스는 단계(304)로 진행하여 자체 발행 토큰을 생성한다. 자체 발행된 토큰은 다음 요소들을 포함한다.
iss: PIDapp@realm;
nameid: PIDapp@realm; 및
aud: PIDpa@target-realm/pahost@user-domain.
iss(발행자) 및 nameid(네임 식별자) 요소는 로컬 애플리케이션 발행자 식별자에 대응한다. aud(오디언스) 요소는 파트너 애플리케이션의 ID(PIDpa), 목적지 호스트(pahost), 및 사용자 도메인(user - domain)에 기초하여 구축될 수 있다. target-realm 필드는 서비스가 호출을 시도하고 있는 애플리케이션의 영역이다.
단계(303)에서 로컬 애플리케이션 발행자 식별자와의 매치가 없으면, 프로세스는 단계(305)로 진행한다. 단계(305)에서, 애플리케이션은 인입 발행자 리스트 내의 발행자들 중 하나가, STS를 나타내는 GUID인, PIDsts만 사용하는 구성된 STS 중 하나와 매치되는지 여부를 판정한다. 애플리케이션은 이 매치에 있어서 영역 파라미터를 무시한다. 단계(305)에서 매치가 있으면, 단계(306)에서, 애플리케이션은 매치된 STS 구성 엔트리가 빈 TID를 갖는지 여부를 판정한다.
단계(307)에서, 매치된 STS 구성 엔트리가 비어있지 않은(non-empty) TID를 포함하면, 애플리케이션은 STS에 대한 토큰을 구축할 때 매치된 STS 엔트리로부터의 TID를 영역 파라미터로서 사용한다. 또는, 단계(308)에서, 매치된 STS 구성 엔트리가 빈 TID를 가지면, 애플리케이션은 STS에 대한 토큰을 구축할 때 상기 입력 파라미터로부터의 테넌트 ID를 영역 파라미터로서 사용한다.
단계(309)에서, 애플리케이션은 STS에 대한 자체 발행된 토큰을 생성한다. STS에 대한 자체 발행된 토큰은 다음 파라미터를 포함한다.
iss: PIDapp@tid;
nameid: PIDapp@tid;
aud: PIDsts@tid/pahost@user-domain; 및
resource: PIDpa @target-realm/pahost@user-domain.
iss/nameid PID 요소(PIDapp)는 애플리케이션 발행자 식별자로부터 나온다. 영역 요소(tid)는 단계(307/308)로부터 선택되고, 전술한 입력 파라미터로부터의 테넌트 ID 및 구성된 STS TID에 기초한다. aud PID 요소(PIDsts)는 STS 구성 엔트리로부터 나온다. 리소스 요소는 파트너 애플리케이션의 ID(PIDpa) 및 사용자 도메인에 기초하여 구축된다.
그 후, 자체 발행된 토큰이 STS에게 제공되고, 이 STS는 단계(310)에서 다음 파라미터를 사용하여 토큰을 생성한다.
iss: PIDsts@tid;
nameid: PIDapp@tid; 및
aud: PIDpa@tid/desthost@tid.
STS는 iss 요소에 대해 자신의 issuer@tenant ID를 사용한다. nameid 요소는 자체 발행된 토큰으로부터 검증되고 복사된다. aud 요소는 토큰 요청 파라미터의 리소스 요소로부터 검증되고 복사된다. 영역이 DNS 도메인으로서 제공되면 이것은 실제 테넌트 ID로 대체된다. 영역이 테넌트 id로서 제공되면, 아무런 대체도 필요치 않다.
단계(303, 305)에서 어떠한 매치도 없으면, 토큰은 생성될 수 없고, 프로세스는 단계(311)에서 종료된다.
단계(301)에서 401 응답에 trusted _ issuers 파라미터가 존재하지 않으면, 프로세스는 단계(312)로 진행한다.
단계(312)에서, 애플리케이션은 401 응답의 WWW-인증 헤더에 영역 파라미터가 존재하는지 여부를 판정한다. 단계(313)에서, 애플리케이션은 "@"와 연결된 파트너 앱 식별자 및 401 응답(예컨대, PIDpa@realm) 내의 영역 값이 구성된 파트너 애플리케이션들 중 하나와 정확히 매치되는지 여부를 판정한다. 단계(313)에서 PIDpa@realm이 구성된 파트너 애플리케이션들 중 하나와 정확히 매치되고 직접 신뢰가 구성되면, 단계(314)에서 애플리케이션은 자체 발행된 토큰을 생성한다. 자체 발행된 토큰은 다음 파라미터를 사용하여 포매팅된다.
iss: PIDapp@realm;
nameid: PIDapp@realm; 및
aud: PIDpa@realm/pahost@realm.
iss 및 nameid 요소(PIDapp@realm)는 로컬 애플리케이션 발행자 식별자에 대응한다. aud 요소는 파트너 애플리케이션의 ID(PIDpa) 및 401 응답에서 리턴된 영역 값에 기초하여 구축된다.
단계(313)에서 구성된 파트너 애플리케이션들 중 하나와 PIDapp@realm 사이에 아무런 매치가 없으면, 프로세스는 단계(315)로 진행한다. 단계(315)에서, 애플리케이션은 401 응답에서 리턴된 영역 값이 임의의 구성된 STS의 영역과 매치되는지 여부를 판정한다.
단계(315)에서 정확한 매치가 없으면, 단계(316)에서 애플리케이션은 빈 영역을 갖는 STS 구성을 선택한다.
단계(315) 또는 단계(316)에서 매치가 존재하면, 단계(317)에서 애플리케이션은 매치된 STS 구성 엔트리가 빈 TID를 포함하는지 여부를 판정한다. 매치된 STS 구성 엔트리가 비어있지 않은 TID를 포함하면, 단계(318)에서 애플리케이션은 매치된 STS 구성으로부터의 TID를 영역으로서 사용하여 STS에 대한 자체 발행된 토큰을 구성한다. 매치된 STS 구성 엔트리가 빈/"*" 영역을 가지면, 단계(319)에서 애플리케이션은 위 입력 파라미터로부터의 영역 [TID]을 사용하여 STS에 대한 자체 발행된 토큰을 구축한다. 자체 발행된 토큰은 다음 파라미터를 갖는다.
iss: PIDapp@tid;
nameid: PIDapp@tid;
aud: PIDsts@tid/stshost@tid; 및
resource: PIDpa@target-realm/pahost@user-domain.
iss 및 nameid 요소 PID(PIDapp)는 애플리케이션 발행자 식별자로부터 나온다. aud 요소 PID(PIDsts)는 STS 구성 엔트리로부터 나온다. iss, nameid, 및 aud 요소(tid)에 대한 영역은 입력 파라미터로부터의 테넌트 ID 또는 구성된 STS TID에 기초하여 선택된다. stshost 요소는 STS 메타데이터 문서 내의 발행자 엔드포인트로부터 나온다. 리소스 요소는 파트너 애플리케이션의 ID(PIDpa) 및 사용자 도메인에 기초하여 구성된다.
단계(318) 또는 단계(319)로부터의 자체 발행된 토큰은 그 후 STS에 제공되고, 단계(320)에서 STS는 다음 파라미터를 사용하여 토큰을 생성한다.
iss: PIDsts@tid;
nameid: PIDapp@tid; 및
aud: PIDpa@tid/desthost@tid.
STS는 iss 요소에 대해 자신의 issuer@tenant ID를 사용한다. nameid 요소는 자체 발행된 토큰으로부터 검증되고 복사된다. aud 요소는 자체 발행된 토큰의 리소스 요소로부터 검증되고 복사된다. DNS 도메인이 제공되면, DNS 영역은 실제 테넌트 ID(tid)로 대체된다. 이와 달리 테넌트 id가 제공되면, 아무런 대체도 필요치 않다.
도 3a 및 3b의 단계들에서 어떠한 매치도 없으면, 프로세스는 중지되고 토큰이 생성될 수 없다.
단일 발신 발행자를 사용하는 애플리케이션의 경우, 애플리케이션은 단계(317 내지 320)를 이용하여 토큰을 생성하기 위해 단지 그 발행자를 사용해야 한다.
수신 토큰의 검증( Validation of Inbound Token )
애플리케이션이 발행자 식별자 기반 토큰 검증을 구현하면, 애플리케이션은 발행자 식별자를 획득하고 토큰 서명 검증을 위한 인증서를 찾아낸다. 애플리케이션은 발행자를 STS의 리스트에 대해 매치시키는데, 이는 애플리케이션에 대한 전역 구성의 일부이다. 발행자 내의 PID는 STS 구성을 정확하게 매치시켜야 한다. 영역은 그것이 STS 구성 엔트리 내에 지정되는 경우에만(즉, 비어있지 않는 경우에만) 매치될 것이다. STS 구성 엔트리가 빈 영역 또는 "*"를 가지면, 발행자 식별자 내의 영역 값은 유효 테넌트 ID여야 한다.
토큰은 직접 신뢰를 갖는 파라미터 애플리케이션의 리스트에 대해 매치될 수 있다. 직접 신뢰를 갖는 애플리케이션의 리스트는 애플리케이션의 전역 구성으로부터 나온다. 일부 실시예에서, 직접 신뢰는 테넌트 구성으로부트의 애플리케이션을 포함할 수 있다. 테넌트는 토큰의 오디언스(aud:) 필드 내의 영역에 기초하여 조사된다. 일실시예에서, 모든 필드(PID@realm)는 직접 신뢰를 위해 정확히 매치되어야 하며 어떠한 와일드카드 매치도 허용되지 않는다. 토큰 내 네임 식별자의 영역 및 PID는 발행자의 영역 및 PID와 동일해야 한다.
매치가 없으면, 애플리케이션은 토큰을 거부한다. 그렇지 않으면, 애플리케이션은 인증서를 리트리브할 수 있다. 인증서는 STS 또는 파트너 애플리케이션과 연관된 메타데이터 문서로부터 획득될 수 있다. 이와 달리, 인증서의 직접 구성도 허용된다.
애플리케이션이 키 식별자 기반 토큰 검증을 구현하면, 애플리케이션은 토큰으로부터의 인증서 지문과 같은 키 식별자를 획득하고, 이것을 구성 내의 모든 유효 키 식별자에 대해 매치시킨다. 매치가 없으면, 애플리케이션은 토큰을 거부한다. 이와 달리, 애플리케이션은 키와 연관된 메타데이터 문서로부터 인증서를 리트리브하거나 인증서 자체를 구성할 수 있다.
애플리케이션은 리트리브된 인증서를 사용하여 토큰 서명을 검증한다.
일실시예에서, 애플리케이션은 네임 식별자를 획득하고 이것을 파트너 애플리케이션 리스트에 대해 매치시킨다. PID는 정확하게 매치되어야 한다. 영역은 파트너 애플리케이션 구성 엔트리 내에서 지정되는 경우에만(비어있지 않거나 "*"이 없는 경우에만) 매치될 것이다. 파트너 애플리케이션 구성 엔트리가 빈 영역을 가지면, 네임 식별자의 영역은 발행자의 영역과 동일해야 한다.
애플리케이션은 오디언스를 획득하고 그 필드들을 매치시킨다. PID는 애플리케이션을 액세스하는데 이용된 호스트명 및 로컬 애플리케이션 PID를 정확히 매치시켜야 한다. SIS 발행 토큰에 있어서, 영역은 발행자의 영역(tenant ID)을 매치시켜야 한다. 애플리케이션 발행 토큰에 있어서, 영역은 로컬로 구성된 전역 또는 테넌트 도메인 중 하나를 매치시켜야 한다. 온라인 또는 멀티 테넌트 환경에 있어서, 영역은 유효 테넌트 ID 또는 유효 테넌트로 리졸브(resolve)하는 도메인이어야 한다.
본 명세서에서 설명한 토큰의 구성 및 검증은 애플리케이션, 서버, 서비스, 장치, 제품 등을 포함하는 둘 이상의 참가자에 의해 사용될 수 있음을 이해할 수 있을 것이다. 참가자는 구성된 STS, 파트너 애플리케이션, 및 신뢰된 발행자를 식별하도록 구성될 수 있다. 그러면 참가자는 전술한 바와 같이 토큰을 생성하고, 교환하고 검증한다.
도 2에 도시된 프로세스의 단계들(201 내지 206) 및 도 3에 도시된 프로세스의 단계들(301 내지 320)은 동시에 및/또는 순차적으로 실행될 수 있음을 이해할 수 있을 것이다. 또한 각 단계는 임의의 순서로 수행될 수 있으며 1회 또는 반복해서 수행될 수도 있음을 이해할 수 있을 것이다.
도 4는 도 1 내지 3의 예들이 구현될 수 있는 적절한 컴퓨팅 및 네트워킹 환경(400)의 일례를 도시한 것이다. 인증 서비스들, 인증 크리덴셜을 획득하기 위해 본 명세서에서 설명한 서비스들 및 애플리케이션들이 컴퓨터 시스템(400) 상에서 구현될 수 있다. 컴퓨팅 시스템 환경(400)은 적절한 컴퓨팅 환경의 일례일 뿐이며 본 발명의 사용 기능의 범위에 대해 어떠한 제한을 암시하고자 하는 것은 아니다. 본 발명은 수많은 다른 범용 또는 특수 목적 컴퓨팅 시스템 환경 또는 구성과 함께 사용가능하다. 본 발명에 사용하기에 적합할 수 있는 공지되어 있는 컴퓨팅 시스템, 환경, 및/또는 구성의 예로는 개인용 컴퓨터, 서버 컴퓨터, 핸드헬드 또는 랩탑 장치, 태블릿 장치, 멀티프로세서 시스템, 마이크로프로세서 기반 시스템, 셋탑 박스, 프로그램가능한 가전, 네트워크 PC, 미니컴퓨터, 메인프레임 컴퓨터, 이들 시스템 또는 장치 중 어느 하나를 포함하는 분산 컴퓨팅 환경 등을 들 수 있다.
본 발명은 컴퓨터에 의해 실행되는 프로그램 모듈과 같은 컴퓨터 실행가능 명령어의 일반적인 컨텍스트에서 기술될 수 있다. 일반적으로, 프로그램 모듈은 특정한 태스크를 수행하거나 특정한 추상 데이터 타입을 구현하는 루틴, 프로그램, 객체, 컴포넌트, 데이터 구조 등을 포함한다. 본 발명은 또한 태스크가 통신망을 통해 링크되는 원격 처리 장치에 의해 수행되는 분산 컴퓨팅 환경에서 실시될 수도 있다. 분산 컴퓨팅 환경에서, 프로그램 모듈은 메모리 저장 장치를 포함하는 로컬 및/또는 원격 컴퓨터 저장 매체에 위치할 수 있다.
도 4를 참조하면, 본 발명의 다양한 특징들을 구현하는 예시적인 시스템은 컴퓨터(400) 형태의 범용 컴퓨팅 장치를 포함할 수 있다. 컴포넌트들은 처리 유닛(408), 시스템 메모리와 같은 데이터 저장부(402), 데이터 저장부(402)를 포함한 다양한 시스템을 처리 유닛(408)에 연결하는 시스템 버스(403)를 포함할 수 있지만, 이들로 한정되지는 않는다. 시스템 버스(403)는 메모리 버스 또는 메모리 컨트롤러, 주변 버스, 및 임의의 다양한 버스 아키텍처들 중 어느 하나를 이용하는 로컬 버스를 포함하는 몇몇 유형의 버스 구조 중 어느 하나일 수 있다. 예를 들어, 제한적인 것은 아니지만, 그러한 아키텍처는 ISA(Industry Standard Architecture) 버스, MCA(Micro Channel Architecture) 버스, EISA(Enhanced ISA) 버스, VESA(Video Electronics Standards Association) 로컬 버스, 및 메자닌(Mezzanine) 버스로도 알려져 있는 PCI(Peripheral Component Interconnect) 버스를 포함한다.
컴퓨터(400)는 통상적으로 다양한 컴퓨터 판독가능 매체(404)를 포함한다. 컴퓨터 판독가능 매체(404)는 컴퓨터(400)에 의해 액세스될 수 있는 임의의 이용가능한 매체일 수 있으며 휘발성 및 비휘발성 매체, 및 착탈식 및 비착탈식 매체 모두를 포함하지만, 전파된 신호는 제외한다. 예를 들어, 제한적인 것은 아니지만, 컴퓨터 판독가능 매체(404)는 컴퓨터 저장 매체 및 통신 매체를 포함할 수 있다. 컴퓨터 저장 매체는 컴퓨터 판독가능 명령어, 데이터 구조, 프로그램 모듈 또는 기타 데이터와 같은 정보 저장을 위한 임의의 방법 또는 기술로 구현된 휘발성 및 비휘발성, 착탈식 및 비착탈식 매체를 포함한다. 컴퓨터 저장 매체는, 제한적인 것은 아니지만, RAM, ROM, EEPROM, 플래시 메모리 또는 기타 메모리 기술, CD-ROM, DVD(digital versatile disk) 또는 다르 광학 디스크 저장부, 자기 카세트, 자기 테이프, 자기 디스크 저장부 또는 기타 자기 저장 장치, 또는 원하는 정보를 저장하는데 사용될 수 있으며 컴퓨터(400)에 의해 액세스될 수 있는 임의의 다른 매체를 포함한다. 통신 매체는 통상적으로 컴퓨터 판독가능 명령어, 데이터 구조, 프로그램 모듈 또는 기타 데이터를 반송파 또는 전송 메커니즘과 같은 변조된 데이터 신호로 구현하고 임의의 정보 전달 매체를 포함한다. "변조된 데이터 신호"란 용어는 정보를 신호로 인코드하는 것과 같은 방식으로 설정 또는 변경된 하나 이상의 특징을 갖는 신호를 의미한다. 예를 들어, 제한적인 것은 아니지만, 통신 매체는 유선 네트워크 또는 직접 유선 접속과 같은 유선 매체, 음향, RF, 적외선 및 기타 무선 매체들과 같은 무선 매체를 포함한다. 이들의 임의의 조합 또한 컴퓨터 판독가능 매체의 범위 내에 포함될 수 있다. 컴퓨터 판독가능 매체는 컴퓨터 저장 매체에 저장된 소프트웨어와 같이 컴퓨터 프로그램 제품으로 구현될 수 있다.
데이터 저장부 또는 시스테 메모리(402)는 ROM 및 RAM과 같은 휘발성 및/또는 비휘발성 메모리 형태의 컴퓨터 저장 매체를 포함한다. 예컨대 시동(start-up) 동안에 컴퓨터(400) 내의 요소들 사이에서 정보를 전달하는 것을 돕는 BIOS(basic input/output system)는 통상적으로 ROM에 저장된다. RAM은 통상적으로 처리 유닛(408)에 의해 즉각 액세스가능하고/또는 현재 작동되는 데이터 및/또는 프로그램 모듈을 포함한다. 예를 들어, 제한적인 것은 아니지만, 데이터 저장부(402)는 운영 체제, 애플리케이션 프로그램, 및 기타 프로그램 모듈 및 프로그램 데이터를 보유한다.
데이터 저장부(402)는 다른 착탈식/비착탈식, 휘발성/비휘발성 컴퓨터 저장 매체를 포함할 수도 있다. 예를 들어, 데이터 저장부(402)는 비착탈식의 비휘발성 자기 매체에 대해 판독 또는 기록하는 하드 디스크 드라이브, 착탈식의 비휘발성 자기 디스크에 대해 판독 또는 기록하는 자기 디스크 드라이브, 및 CD ROM 또는 기타 광학 매체와 같은 착탈식의 비휘발성 광 디스크에 대해 판독 또는 기록하는 광학 디스크 드라이브일 수 있다. 예시적인 운영 환경에서 사용될 수 있는 다른 착탈식/비착탈식, 휘발성/비휘발성 컴퓨터 저장 매체는 자기 테이프 카세트, 플래시 메모리 카드, DVD, 디지털 비디오 테이프, 고체 상태 RAM, 고체 상태 ROM 등을 포함하지만, 이에 한정되지는 않는다. 도 4에 도시되고 위에서 기술된 드라이브 및 이들의 관련 컴퓨터 저장 매체는 컴퓨터 판독가능 명령어, 데이터 구조, 프로그램 모듈 및 컴퓨터(400)를 위한 기타 데이터를 저장한다.
사용자는 사용자 인터페이스(405) 또는 태블릿, 전자 디지타이저, 마이크, 키보드, 및/또는 일반적으로 마우스, 트랙볼 또는 터치 패드로 지칭되는 포인팅 장치와 같은 다른 입력 장치를 통해 커맨드 및 정보를 입력할 수 있다. 다른 입력 장치는 조이스틱, 게임 패드, 위성 접시, 스캐너 등을 포함할 수 있다. 또한 음성 입력 또는 NUI(natural user interface)가 사용될 수 있다. 이들 및 다른 입력 장치는 흔히 시스템 버스(403)에 결합되는 사용자 입력 인터페이스(405)를 통해 처리 유닛(408)에 접속되지만, 병렬 포트, 게임 포트 또는 USB와 같은 다른 인터페이스 및 버스 구조에 의해 접속될 수도 있다. 또한, 모니터(406) 또는 다른 유형의 디스플레이 장치가 비디오 인터페이스와 같은 인터페이스를 통해 시스템 버스(403)에 접속된다. 모니터(406)는 또한 터치 스크린 패널 등과 통합될 수도 있다. 모니터 및/또는 터치 스크린 패널이 태블릿 타입의 개인용 컴퓨터에서와 같이 컴퓨팅 장치(400)가 포함되는 하우징에 물리적으로 결합될 수 있음에 주의하라. 또한, 컴퓨팅 장치(400)와 같은 컴퓨터는 출력 주변 인터페이스 등을 통해 연결될 수 있는 스피커 및 프린트와 같은 다른 주변 출력 장치를 포함할 수도 있다.
컴퓨터(400)는 원격 컴퓨터와 같은 하나 이상의 원격 컴퓨터에 대한 논리 접속(407)을 이용하여 네트워킹된 환경에서 동작할 수 있다. 예를 들어, 인증 서비스, 서비스 및 애플리케이션이 인증 크리덴셜을 획득하기 위해 네트워크 접속을 통해 통신할 수 있다. 원격 컴퓨터는 개인용 컴퓨터, 서버, 라우터, 네트워크 PC, 피어 장치 또는 기타 일반 네트워크 노드일 수 있으며, 통상적으로 컴퓨터(400)와 관련하여 전술한 많은 또는 모든 요소들을 포함한다. 도 4에 도시된 논리 접속은 하나 이상의 LAN 및 하나 이상의 WAN을 포함하지만, 다른 네트워크를 포함할 수도 있다. 이러한 네트워킹 환경은 사무실, 전사적 컴퓨터 네트워크, 인트라넷 및 인터넷에서 일상적이다.
컴퓨터(400)는 LAN 네트워킹 환경에서 사용될 경우에 네트워크 인터페이스 또는 어댑터(407)를 통해 LAN에 접속될 수 있다. 컴퓨터(400)는 통상적으로 모뎀 또는 인터넷과 같은 WAN을 통해 통신을 확립하는 다른 수단을 포함한다. 내부 또는 외부에 있을 수 있는 모뎀은 네트워크 인터페이스(407) 또는 다른 적절한 메커니즘을 통해 시스템 버스(403)에 연결될 수 있다. 예컨대 인터페이스 및 안테나를 포함하는 무선 네트워킹 컴포넌트는 액세스 포인트 또는 피어 컴퓨터와 같은 적절한 장치를 통해 WAN 또는 LAN에 연결될 수 있다. 네트워킹된 환경에서, 컴퓨터(400)와 관련하여 도시된 프로그램 모듈 또는 그 부분들은 원격 메모리 저장 장치에 저장될 수 있다. 도시된 네트워크 접속은 예시적이며 컴퓨터들 사이에 통신 링크를 확립하는 다른 수단이 이용될 수도 있음을 이해할 수 있을 것이다.
구조적 특징 및/또는 방법적 동작에 특정된 언어로 본 발명을 설명하였지만, 첨부한 청구범위에 정의되어 있는 청구 대상은 반드시 전술한 특정한 특징들 또는 동작들에 한정되지는 않음을 이해해야 한다. 오히려, 전술한 특정한 특징들 및 동작들은 청구범위를 구현하는 예시적인 형태로서 개시된다.

Claims (10)

  1. 제1 애플리케이션으로부터 제2 애플리케이션으로 요청을 전송하는 단계와,
    상기 요청에 대한 응답을 수신하는 단계 -상기 응답은 상기 제2 애플리케이션에 의해 신뢰된 인증 발행자의 리스트를 포함함- 와,
    상기 제2 애플리케이션에 의해 신뢰된 인증 발행자의 리스트를 상기 제1 애플리케이션에 대해 승인된 인증 발행자의 리스트와 비교하는 단계와,
    상기 리스트들 사이의 인증 발행자 매치(match)를 식별하는 단계
    를 포함하는 방법.
  2. 제1항에 있어서,
    양쪽 리스트에서 매치되는 인증 발행자로부터 인증 크리덴셜을 획득하는 단계를 더 포함하는
    방법.
  3. 제2항에 있어서,
    상기 인증 크리덴셜을 사용하여 상기 제2 애플리케이션에 대해 수정된 요청을 생성하는 단계를 더 포함하는
    방법.
  4. 제1항에 있어서,
    상기 응답은 인증되지 않은 요청을 포함하는 401 응답이고, 상기 제2 애플리케이션에 의해 신뢰된 상기 인증 발행자의 리스트는 상기 401 응답의 WWW-인증 헤더에서 전송되는
    방법.
  5. 제1항에 있어서,
    GUID(Globally Unique Identifier)를 이용하여 상기 제2 애플리케이션에 의해 신뢰된 인증 발행자가 상기 제1 애플리케이션에 대해 승인된 인증 발행자와 매치되는지 여부를 판정하는 단계를 더 포함하는
    방법.
  6. 제5항에 있어서,
    승인된 인증 발행자 구성으로부터의 테넌트 식별자를 이용하여 인증 발행자에 대한 토큰을 구축하는 단계를 더 포함하는
    방법.
  7. 제5항에 있어서,
    입력 파라미터의 집합을 생성하는 단계와,
    상기 입력 파라미터로부터의 테넌트 식별자를 이용하여 인증 발행자에 대한 토큰을 구축하는 단계를 더 포함하는
    방법.
  8. 제1항에 있어서,
    승인된 인증 발행자 구성과 상기 승인된 인증 발행자 구성으로부터의 테넌트 식별자를 매치시키는 GUID를 사용하여 상기 인증 발행자에 대한 자체 발행된 토큰을 생성하는 단계를 더 포함하는
    방법.
  9. 제8항에 있어서,
    상기 인증 발행자로부터 인증 토큰을 수신하는 단계를 더 포함하되, 상기 인증 토큰은 상기 자체 발행된 토큰을 사용하여 상기 인증 발행자에 의해 생성되는
    방법.
  10. 컴퓨터 시스템으로서,
    프로세서와,
    시스템 메모리와,
    컴퓨터 실행가능 명령어가 저장되어 있는 하나 이상의 컴퓨터 판독가능한 매체를 포함하되,
    상기 컴퓨터 실행가능 명령어는 프로세서에 의해 실행될 경우, 프로세서로 하여금 인증 크리덴셜을 생성하는 방법을 수행하게 하며,
    상기 프로세서는,
    제1 애플리케이션으로부터 제2 애플리케이션으로 요청을 전송하고,
    상기 요청에 대한 응답을 수신하며 -상기 응답은 상기 제2 애플리케이션에 의해 신뢰된 인증 발행자의 리스트를 포함함-,
    상기 제2 애플리케이션에 의해 신뢰된 인증 발행자의 리스트를 상기 제1 애플리케이션에 대해 승인된 인증 발행자의 리스트와 비교하고,
    상기 두 리스트에서 매치되는 인증 발행자를 식별
    하도록 동작하는, 컴퓨터 시스템.
KR1020147020076A 2012-01-19 2013-01-16 서버 애플리케이션을 인증 제공자와 통합하는 기법 KR20140116422A (ko)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US13/354,324 US8819794B2 (en) 2012-01-19 2012-01-19 Integrating server applications with multiple authentication providers
US13/354,324 2012-01-19
PCT/US2013/021615 WO2013109556A1 (en) 2012-01-19 2013-01-16 Integrating server applications with multiple authentication providers

Publications (1)

Publication Number Publication Date
KR20140116422A true KR20140116422A (ko) 2014-10-02

Family

ID=48638732

Family Applications (1)

Application Number Title Priority Date Filing Date
KR1020147020076A KR20140116422A (ko) 2012-01-19 2013-01-16 서버 애플리케이션을 인증 제공자와 통합하는 기법

Country Status (6)

Country Link
US (1) US8819794B2 (ko)
EP (1) EP2805447B1 (ko)
JP (1) JP6185934B2 (ko)
KR (1) KR20140116422A (ko)
CN (1) CN103179108B (ko)
WO (1) WO2013109556A1 (ko)

Families Citing this family (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN107579948B (zh) * 2016-07-05 2022-05-10 华为技术有限公司 一种网络安全的管理系统、方法及装置
EP3432539B1 (de) * 2017-07-20 2020-12-23 Siemens Aktiengesellschaft Verfahren zum aufbau eines kommunikationskanals zwischen einer servereinrichtung und einer clienteinrichtung
US11025628B2 (en) * 2018-04-17 2021-06-01 Cisco Technology, Inc. Secure modification of manufacturer usage description files based on device applications
US11924112B2 (en) * 2021-03-30 2024-03-05 Cisco Technology, Inc. Real-time data transaction configuration of network devices

Family Cites Families (33)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CA2188330C (en) * 1995-12-12 2001-04-24 Michael D. Bamburak A method for selecting a wireless communications service provider in a multi-service provider environment
US6052590A (en) * 1997-07-29 2000-04-18 Ericsson, Inc. Method for reducing control channel scan time
US6510236B1 (en) 1998-12-11 2003-01-21 International Business Machines Corporation Authentication framework for managing authentication requests from multiple authentication devices
WO2003032572A1 (en) 2001-10-12 2003-04-17 Geo Trust, Inc. Methods and systems for automated authentication, processing and issuance of digital certificates
US7584505B2 (en) * 2001-10-16 2009-09-01 Microsoft Corporation Inspected secure communication protocol
US7707120B2 (en) 2002-04-17 2010-04-27 Visa International Service Association Mobile account authentication service
US7240366B2 (en) 2002-05-17 2007-07-03 Microsoft Corporation End-to-end authentication of session initiation protocol messages using certificates
US7392375B2 (en) * 2002-09-18 2008-06-24 Colligo Networks, Inc. Peer-to-peer authentication for real-time collaboration
US8020196B2 (en) 2002-10-25 2011-09-13 Randle William M Secure transmission and exchange of standardized data
US20080114832A1 (en) * 2003-03-07 2008-05-15 Atreus Systems Corp. Using multiple policy distribution points to initiate a network-based service
US7644275B2 (en) * 2003-04-15 2010-01-05 Microsoft Corporation Pass-thru for client authentication
JP2005259111A (ja) * 2004-01-26 2005-09-22 Ricoh Co Ltd ユーザ情報取扱い装置、ユーザ情報取扱いプログラム及び記録媒体
US7194763B2 (en) 2004-08-02 2007-03-20 Cisco Technology, Inc. Method and apparatus for determining authentication capabilities
US7945954B2 (en) * 2004-09-07 2011-05-17 Coueignoux Philippe J M Controlling electronic messages
US7539193B2 (en) * 2005-01-27 2009-05-26 Time Warner Cable, Inc. System and method for facilitating communication between a CMTS and an application server in a cable network
US8631476B2 (en) 2005-03-31 2014-01-14 Sap Ag Data processing system including explicit and generic grants of action authorization
US8091120B2 (en) * 2005-12-21 2012-01-03 At&T Intellectual Property I, L.P. Adaptive authentication methods, systems, devices, and computer program products
US7600123B2 (en) * 2005-12-22 2009-10-06 Microsoft Corporation Certificate registration after issuance for secure communication
US7788730B2 (en) * 2006-01-17 2010-08-31 International Business Machines Corporation Secure bytecode instrumentation facility
US7805489B2 (en) * 2006-06-27 2010-09-28 Research In Motion Limited Electronic mail communications system with client email internet service provider (ISP) polling application and related methods
WO2008013525A1 (en) * 2006-07-25 2008-01-31 Northrop Grumman Corporation Common access card heterogeneous (cachet) system and method
US8171535B2 (en) * 2006-12-19 2012-05-01 Canon Kabushiki Kaisha Dynamic web service policy broadcasting/enforcement for applications
US8347403B2 (en) * 2006-12-19 2013-01-01 Canon Kabushiki Kaisha Single point authentication for web service policy definition
US8281375B2 (en) 2007-01-05 2012-10-02 Ebay Inc. One time password authentication of websites
WO2009050924A1 (ja) * 2007-10-19 2009-04-23 Nippon Telegraph And Telephone Corporation 利用者認証システム及びその方法
CN101610241B (zh) * 2008-06-16 2012-11-21 华为技术有限公司 一种绑定认证的方法、系统和装置
US8151333B2 (en) * 2008-11-24 2012-04-03 Microsoft Corporation Distributed single sign on technologies including privacy protection and proactive updating
US20100251353A1 (en) 2009-03-25 2010-09-30 Novell, Inc. User-authorized information card delegation
US8347356B2 (en) 2009-03-31 2013-01-01 Microsoft Corporation Adaptive HTTP authentication scheme selection
US8078870B2 (en) * 2009-05-14 2011-12-13 Microsoft Corporation HTTP-based authentication
US9015609B2 (en) * 2009-05-18 2015-04-21 American Well Corporation Provider to-provider consultations
US8527360B2 (en) * 2011-04-29 2013-09-03 Daon Holdings Limited Methods and systems for conducting payment transactions
US8868680B2 (en) * 2011-06-30 2014-10-21 Infosys Technologies Ltd. Methods for recommending personalized content based on profile and context information and devices thereof

Also Published As

Publication number Publication date
CN103179108A (zh) 2013-06-26
CN103179108B (zh) 2016-08-10
US20130191894A1 (en) 2013-07-25
WO2013109556A1 (en) 2013-07-25
EP2805447A1 (en) 2014-11-26
EP2805447A4 (en) 2015-10-21
JP6185934B2 (ja) 2017-08-23
JP2015505626A (ja) 2015-02-23
US8819794B2 (en) 2014-08-26
EP2805447B1 (en) 2019-04-10

Similar Documents

Publication Publication Date Title
US10642969B2 (en) Automating internet of things security provisioning
US8220032B2 (en) Methods, devices, and computer program products for discovering authentication servers and establishing trust relationships therewith
EP2883337B1 (en) Secure mobile client with assertions for access to service provider applications
RU2439692C2 (ru) Управляемое политиками делегирование учетных данных для единой регистрации в сети и защищенного доступа к сетевым ресурсам
US8850553B2 (en) Service binding
US9258292B2 (en) Adapting federated web identity protocols
US20180270066A1 (en) Secure enrolment of security device for communication with security server
US20110035792A1 (en) Client/server system for communicating according to the standard protocol opc ua and having single sign-on mechanisms for authenticating, and method for performing single sign-on in such a system
JP5239341B2 (ja) ゲートウェイ、中継方法及びプログラム
WO2022247751A1 (zh) 远程访问应用的方法、系统、装置、设备及存储介质
KR20080053298A (ko) 접속 프로세스의 비교적 초기에 인증함으로써 시큐어접속을 생성하는 방법 및 그 방법을 수행하게 하는 컴퓨터실행가능 명령어를 갖는 컴퓨터 프로그램 제품
EP1974501A2 (en) Ad-hoc creation of group based on contextual information
CN112437100A (zh) 漏洞扫描方法及相关设备
JP2015194879A (ja) 認証システム、方法、及び提供装置
US11601431B2 (en) Split-tiered point-to-point inline authentication architecture
JP6185934B2 (ja) サーバー・アプリケーションと多数の認証プロバイダーとの統合
US11503012B1 (en) Client authentication using a client certificate-based identity provider
JP2022528711A (ja) 分散台帳に関連付けられた宛先アドレッシング
WO2021108420A1 (en) Method and system for facilitating an identification of an application
US11611541B2 (en) Secure method to replicate on-premise secrets in a cloud environment
US20100287600A1 (en) Assigning User Requests of Different Types or Protocols to a User by Trust Association Interceptors
CN116418539A (zh) 身份认证方法、系统、装置、设备及存储介质
WO2009127163A1 (zh) 用户属性查询的方法、提供服务的方法及设备

Legal Events

Date Code Title Description
N231 Notification of change of applicant
WITB Written withdrawal of application