KR20180027597A - 멀티-테넌트 아이덴티티 및 데이터 보안 관리 클라우드 서비스 - Google Patents

멀티-테넌트 아이덴티티 및 데이터 보안 관리 클라우드 서비스 Download PDF

Info

Publication number
KR20180027597A
KR20180027597A KR1020187004762A KR20187004762A KR20180027597A KR 20180027597 A KR20180027597 A KR 20180027597A KR 1020187004762 A KR1020187004762 A KR 1020187004762A KR 20187004762 A KR20187004762 A KR 20187004762A KR 20180027597 A KR20180027597 A KR 20180027597A
Authority
KR
South Korea
Prior art keywords
tenancy
user
service
request
idcs
Prior art date
Application number
KR1020187004762A
Other languages
English (en)
Other versions
KR102041941B1 (ko
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
Family has litigation
First worldwide family litigation filed litigation Critical https://patents.darts-ip.com/?family=61387621&utm_source=google_patent&utm_medium=platform_link&utm_campaign=public_patent_search&patent=KR20180027597(A) "Global patent litigation dataset” by Darts-ip is licensed under a Creative Commons Attribution 4.0 International License.
Priority claimed from US15/450,550 external-priority patent/US9838377B1/en
Priority claimed from US15/450,512 external-priority patent/US9838376B1/en
Priority claimed from US15/469,718 external-priority patent/US10341410B2/en
Priority claimed from US15/485,532 external-priority patent/US9781122B1/en
Application filed by 오라클 인터내셔날 코포레이션 filed Critical 오라클 인터내셔날 코포레이션
Priority claimed from PCT/US2017/031649 external-priority patent/WO2017196774A1/en
Publication of KR20180027597A publication Critical patent/KR20180027597A/ko
Application granted granted Critical
Publication of KR102041941B1 publication Critical patent/KR102041941B1/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/0807—Network architectures or network communication protocols for network security for authentication of entities using tickets, e.g. Kerberos
    • 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/0876—Network architectures or network communication protocols for network security for authentication of entities based on the identity of the terminal or configuration, e.g. MAC address, hardware or software configuration or device fingerprint
    • 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
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/06—Authentication
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/06—Authentication
    • H04W12/068—Authentication using credential vaults, e.g. password manager applications or one time password [OTP] applications
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/06—Authentication
    • H04W12/069—Authentication using certificates or pre-shared keys
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/08—Access security
    • H04W12/084—Access security using delegated authorisation, e.g. open authorisation [OAuth] protocol

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)
  • Power Engineering (AREA)
  • Storage Device Security (AREA)
  • Telephonic Communication Services (AREA)
  • Information Transfer Between Computers (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Abstract

시스템은 클라우드기반의 아이덴티티 및 액세스 관리를 제공한다. 시스템은 아이덴티티 관리 서비스에 대한 요청을 클라이언트로부터 수신하고, 요청을 인증하고, 요청에 기초하여 마이크로서비스를 액세스한다. 시스템은 요청에 기초하여 클라이언트의 테넌시, 유저의 테넌시, 및 자원의 테넌시를 결정한다. 시스템은 요청을 프로세스하기 위해 요구된 데이터를 결정된 테넌시들로부터 검색하고, 여기서 데이터는 데이터베이스에 연결들을 제공하는 연결 풀을 이용하여 마이크로서비스에 의해 검색된다. 시스템은 그런 다음 수신된 요청을 프로세스할 책임이 있는 적절한 마이크로서비스에 의해 아이덴티티 관리 서비스를 수행한다.

Description

멀티-테넌트 아이덴티티 및 데이터 보안 관리 클라우드 서비스 {MULTI-TENANT IDENTITY AND DATA SECURITY MANAGEMENT CLOUD SERVICE}
관련 출원들에 대한 상호 참조
본 출원은 2016년 5월 11일에 출원된 U.S. 가특허 출원 일련 번호. 62/334,645, 2016년 8월 5일에 출원된 U.S. 가특허 출원 일련 번호. 62/371,336, 2016년 8월 17일에 출원된 U.S. 가특허 출원 일련 번호. 62/376,069, 2016년 9월 16일에 출원된 U.S. 가특허 출원 일련 번호. 62/395,463, 2016년 9월 16일에 출원된 U.S. 가특허 출원 일련 번호. 62/395,479, 2016년 9월 16일에 출원된 U.S. 가특허 출원 일련 번호. 62/395,501, 2016년 12월 15일에 출원된 U.S. 가특허 출원 일련 번호. 62/434,501, 2017년 3월 6일에 출원된 U.S. 특허 출원 일련 번호. 15/450,512, 2017년 3월 6일에 출원된 U.S. 특허 출원 일련 번호. 15/450,550, 2017년 3월 27일에 출원된 U.S. 특허 출원 일련 번호. 15/469,718, 및 2017년 4월 12일에 출원된 U.S. 특허 출원 일련 번호. 15/485,532의 우선권을 주장한다. 앞에서의 출원들의 각각의 개시는 참조로서 본 출원에 통합된다.
기술분야
일 실시예는 전반적으로 아이덴티티 관리(identity management)에 관한 것으로, 보다 상세하게는, 클라우드 시스템 내 아이덴티티 관리에 관한 것이다.
일반적으로, 클라우드기반의 애플리케이션들 (예를 들어, 기업 퍼블릭 클라우드 애플리케이션들, 제 3 자 클라우드 애플리케이션들, 등)의 사용은 여러 가지 디바이스들 (예를 들어, 데스크탑 및 모바일 디바이스들) 및 여러 가지 유저들 (예를 들어, 직원들, 파트너들, 고객들, 등)로부터 오는 액세스로 급증하고 있다. 클라우드기반의 애플리케이션들의 풍부한 다이버시티(diversity) 및 접근성은 핵심 관심이 되는 아이덴티티 관리 및 액세스 보안으로 이어진다. 클라우드 환경에서 전형적인 보안 관심들은 인가 받지 않은 액세스, 계정 하이잭킹(hijacking), 악의적인 내부자(insider), 등이다. 따라서, 어떤 디바이스 유형으로부터 또는 어떤 유저 유형에 의해 애플리케이션들이 액세스되는지에 관계 없이 어디든 위치되는 애플리케이션들 또는 클라우드기반의 애플리케이션들에 대한 보안 액세스에 대한 요구가 있다.
일 실시예는 클라우드기반의 아이덴티티 및 액세스 관리를 제공하는 시스템이다. 상기 시스템은 아이덴티티 관리 서비스에 대한 요청을 클라이언트로부터 수신하고, 상기 요청을 인증하고, 상기 요청에 기초하여 마이크로서비스를 액세스한다. 상기 시스템은 상기 요청에 기초하여, 상기 클라이언트의 테넌시, 유저의 테넌시, 및 자원의 테넌시를 결정한다. 상기 시스템은 상기 요청을 프로세스하기 위해 요구된 데이터를 상기 결정된 테넌시들로부터 검색하고, 여기서 상기 데이터는 상기 데이터베이스에 연결들을 제공하는 연결 풀을 이용하여 마이크로서비스에 의해 검색된다. 상기 시스템은 그런 다음 상기 수신된 요청을 프로세스할 책임이 있는 적절한 마이크로서비스에 의해 상기 아이덴티티 관리 서비스를 수행한다.
도면들 1-5는 클라우드기반의 아이덴티티 관리를 제공하는 대표적 실시예들의 블럭 다이어그램들이다.
도 6은 일 실시예의 시스템 뷰를 제공하는 블럭 다이어그램이다.
도 6a는 일 실시예의 기능 뷰를 제공하는 블럭 다이어그램이다.
도 7은 클라우드 게이트를 구현하는 실시예의 블럭 다이어그램이다.
도 8 은 일 실시예에서 다수의 테넌시(tenancy)들을 구현하는 예제 시스템을 예시한다.
도 9는 일 실시예의 네트워크 뷰의 블럭 다이어그램이다;
도 10 은 일 실시예에서 SSO(single sign on) 기능의 시스템 아키텍처 뷰의 블록 다이어그램이다.
도 11은 일 실시예에서 SSO 기능의 메시지 시퀀스 플로우이다.
도 12는 일 실시예에서 분산된 데이터 그리드의 예를 예시한다.
도면들 13-16은 실시예들에 따른 아이덴티티 및 액세스 관리 기능의 흐름도이다.
실시예들은 마이크로서비스들 기반 아키텍처를 구현하는 아이덴티티 클라우드 서비스를 제공하고 멀티-테넌트 아이덴티티 및 데이터 보안 관리 및 클라우드기반 애플리케이션들에 대한 보안 액세스를 제공한다. 실시예들은 하이브리드 클라우드 배치들 (즉, 퍼블릭 클라우드(public cloud) 및 프라이비트 클라우드(private cloud)의 조합을 포함하는 클라우드 배치들)에 대한 보안 액세스(secure access)를 지원한다. 실시예들은 클라우드 및 온-프레미스(on-premise) 양쪽에서 애플리케이션들 및 데이터를 보호한다. 실시예들은 웹, 모바일, 및 API(application programming interface)들을 통하여 멀티-채널 액세스를 지원한다. 실시예들은 상이한 유저들, 예컨대 고객들, 파트너들, 및 직원들에 대한 액세스를 관리한다. 실시예들은 클라우드 뿐만 아니라 온-프레미스에 걸쳐 액세스를 관리, 제어 및 감사(audit)한다. 실시예들은 현존하는 애플리케이션 및 아이덴티티와 새로운 애플리케이션 및 아이덴티티를 통합한다. 실시예들은 수평으로(horizontally) 확장 가능하다(scalable)
일 실시예는 클라우드기반의 멀티-테넌트 아이덴티티 및 액세스 관리 서비스들을 제공하기 위해 스테이트리스(stateless) 중간 티어 환경에서 많은 마이크로서비스들을 구현하는 시스템이다. 일 실시예에서, 각각의 요청된 아이덴티티 관리 서비스는 실시간 태스크들, 및 근-실시간(near-real-time) 태스크들로 쪼개진다. 실시간 태스크들은 중간 티어에 마이크로서비스에 의해 핸들링되는 한편, 근-실시간(near-real-time) 태스크들은 메시지 큐에 오프로드된다. 실시예들은 마이크로서비스들을 액세스하기 위해 보안 모델을 시행하는 라우팅 티어 및 중간 티어에 의해 소모되는 액세스 토큰들을 구현한다. 따라서, 실시예들은 멀티-테넌트, 마이크로서비스들 아키텍처에 기반된 클라우드-스케일 IAM(Identity and Access Management) 플랫폼을 제공한다.
일 실시예는 단체들의 새로운 비즈니스 개시를 위한 빠른, 신뢰할 수 있는, 및 보안 서비스들을 단체(organization)들이 빠르게 개발하는 것을 가능하게 하는 아이덴티티 클라우드 서비스를 제공한다. 일 실시예에서, 아이덴티티 클라우드 서비스는 많은 코어 서비스(core service)들을 제공하고, 이들의 각각은 많은 기업들에 의해 직면된 고유의 난제를 해결한다. 일 실시예에서, 아이덴티티 클라우드 서비스는 예를 들어, 유저들의 최초 온-보딩(on-boarding)/임포팅(importing), 유저 멤버들을 그룹들에 임포팅, 유저들 생성/업데이팅/디스에이블링(disabling)/인에비블링(enabling)/삭제, 유저들을 그룹들에/그룹들로부터 할당(assigning)/할당 해제(un-assigning), 그룹들 생성/업데이팅/삭제, 패스워드들 재설정, 정책들 관리, 활동(activation) 발송, 등 시에 관리자들을 지원한다. 아이덴티티 클라우드 서비스는 또한 예를 들어, 프로파일들 변경, 프라이머리(primary)/복원 이메일들 설정, 이메일들 검증(verifying), 그들의 계정들 잠금 풀기(unlocking), 패스워드들 바꾸기, 패스워드를 잃어버린 경우에 패스워드들 되찾기(recovering), 등 시에 엔드 유저들을 지원한다.
단일화된 액세스의 보안 (Unified Security of Access)
일 실시예는 클라우드 환경에서 뿐만 아니라 온-프레미스(on-premise) 환경에서 애플리케이션들 및 데이터를 보호한다. 실시예는 누군가에 의한 임의의 디바이스로부터의 임의의 애플리케이션에 대한 액세스를 안전하게 보장한다. 실시예는 두개의 환경들 간에 보안에서의 불일치(inconsistency)들이 더 높은 위험들로 귀결될 수 있기 때문에 양쪽 환경들에 걸쳐 보호를 제공한다. 예를 들어, 이런 불일치들은 판매원(sales person)이 심지어 그들이 경쟁상대(competition)에게 전향한(defect) 후에도 그들의 CRM(Customer Relationship Management) 계정에 대한 액세스를 계속 갖게 할 수 있다. 따라서, 실시예들은 온-프레미스 환경에 프로비저닝된 보안 제어들을 클라우드 환경으로 연장한다. 예를 들어, 만약 사람이 회사를 떠나면, 실시예들은 그들의 계정들이 온-프레미스 및 클라우드 양쪽에서 디스에이블링(disable)되는 것을 보장한다.
일반적으로, 유저들은 많은 상이한 채널들 예컨대 웹 브라우저들, 데스크탑들, 이동 전화기들, 태블릿들, 스마트 워치들, 다른 웨어러블(wearable)들, 등을 통하여 애플리케이션들 및/또는 데이터를 액세스할 수 있다. 따라서, 일 실시예는 모든 이들 채널들에 걸쳐 보안된 액세스(secured access)를 제공한다. 예를 들어, 유저는 그들이 그들의 데스크탑 상에서 시작했던 트랜잭션(transaction)을 완료하기 위해 그들의 이동 전화를 사용할 수 있다.
일 실시예는 추가로 다양한 유저들 예컨대 고객들, 파트너들, 직원들, 등에 대한 액세스를 관리한다. 일반적으로, 애플리케이션들 및/또는 데이터는 단지 직원들 에 의해서 뿐만 아니라 고객들 또는 제 3 당사자들에 의해 액세스될 수 있다. 비록 많은 알려진 시스템들은 직원들이 온보딩할 때 보안 조치들을 취하지만, 그것들은 일반적으로 고객들, 제 3 당사자들, 파트너들, 등에 액세스가 주어질 때 동일한 레벨의 보안 조치들을 취하지 않고, 적절하게 관리되지 않는 당사자들에 의한 보안 구멍들(security breach)들의 가능성으로 귀결된다. 그러나, 실시예들은 충분한 보안 조치들이 단지 직원들이 아니라 각각의 유형의 유저에 대한 액세스에 대하여 제공되는 것을 보장한다.
아이덴티티 클라우드 서비스 (Identity Cloud Service)
실시예들은 멀티-테넌트(multi-tenant), 클라우드-스케일, IAM 플랫폼인 아이덴티티 클라우드 서비스 (“IDCS : Identity Cloud Service”)를 제공한다. IDCS는 인증, 인가, 감사(auditing), 및 연합(federation)을 제공한다. IDCS는 퍼블릭 클라우드(public cloud), 및 온-프레미스(on-premise) 시스템들 상에서 운영하는 통상의 애플리케이션들 및 서비스들에 대한 액세스를 관리한다. 대안 또는 추가의 실시예에서, IDCS는 퍼블릭 클라우드 서비스들에 대한 액세스를 또한 관리할 수 있다. 예를 들어, IDCS는 이런 다양한 서비스들/애플리케이션들/시스템들에 걸쳐 SSO(Single Sign On) 기능을 제공하는데 사용될 수 있다.
실시예들은 클라우드-스케일 소프트웨어 서비스들을 디자인, 빌드 및 전달(deliver)하기 위해 멀티-테넌트, 마이크로서비스들 아키텍처에 기반된다. 멀티-테넌시(multi-tenancy)는 해당 서비스를 구매한 다수의 고객들을 안전하게 지원하는 서비스의 하나의 물리적 구현을 갖는 것을 지칭한다. 서비스는 그것의 사용을 제어하는 정책들과 함께 (예를 들어, 서비스를 요청한 클라이언트의 아이덴티티에 기초하여) 상이한 목적을 위해 상이한 클라이언트들에 의해 재사용될 수 있는 소프트웨어 기능 또는 소프트웨어 기능들의 세트 (예컨대 동작들의 세트의 실행 또는 지정된 정보의 검색)이다. 일 실시예에서, 서비스는 하나 이상의 성능들에 대한 액세스를 가능하게 하는 메커니즘이고, 여기서 액세스는 미리 규정된 인터페이스를 이용하여 제공되고 서비스 설명(service description)에 의해 특정된 제약들 및 정책들에 따라 실행된다.
일 실시예에서, 마이크로서비스는 독립적으로 배치할 수 있는 서비스이다. 일 실시예에서, 용어 마이크로서비스(microservice)는 합성 애플리케이션(complex application) 들이 언어-애그노스틱(language-agnostic) API들을 이용하여 서로 통신하는 작은, 독립적인 프로세스들로 이루어진 소프트웨어 아키텍처 디자인 패턴(software architecture design pattern)을 고려한다. 일 실시예에서, 마이크로서비스(microservice)들은 작고, 매우 디커플링된(decoupled) 서비스들이고 각각은 작은 태스크(task)를 수행하는데 집중할 수 있다. 일 실시예에서, 마이크로서비스 아키텍쳐 스타일은 단일 애플리케이션을 작은 서비스들의 스위트(suite)로 전개(develop)시키는 접근법이고, 각각은 그 자체의 프로세스에서 운용되고 가벼운 메커니즘들 (예를 들어, HTTP 자원 API)로 통신한다. 일 실시예에서, 마이크로서비스들은 동일한 기능들의 전부 또는 대부분을 수행하는 모노리식 서비스(monolithic service)에 관련하여 대체하기가 용이하다. 게다가, 각각의 마이크로서비스들은 다른 마이크로서비스들에 악영향을 미치지 않고 업데이트될 수 있다. 그에 반해서, 모노리식 서비스의 하나의 부분에 대한 업데이트들은 모노리식 서비스의 다른 부분들에 바람직하지 않게 또는 의도하지 않게 부정적으로 영향을 미칠 수 있다. 일 실시예에서, 마이크로서비스들은 그것들의 성능들 대하여 유익하게 구조화(organize)될 수 있다. 일 실시예에서, 마이크로서비스들의 집합의 각각에 대한 스타트업(startup)은 해당 마이크로서비스들의 모든 서비스들을 총괄하여 수행하는 단일 애플리케이션에 대한 스타트업 시간보다 훨씬 작다. 일부 실시예들에서, 각각의 이런 마이크로서비스들에 대한 스타트업 시간은 약 일 초 또는 그 미만이지만, 그러나 이런 단일 애플리케이션의 스타트업 시간은 약 일 분, 몇 분, 또는 더 길 수 있다.
일 실시예에서, 마이크로서비스들 아키텍처는 분화(specialization)(즉, 시스템 내 태스크들의 분리) 및 가요적이고, 독립적으로 배치할 수 있는 소프트웨어 시스템들을 빌드하기 위한 SOA(service oriented architecture)들의 구현 접근법을 지칭한다. 마이크로서비스들 아키텍처내 서비스들은 목표를 완수하기 위해 네트워크를 통하여 서로 통신하는 프로세스들이다. 일 실시예에서, 이들 서비스들은 기술-애그노스틱(technology-agnostic) 프로토콜들을 사용한다. 일 실시예에서, 서비스들은 작은 세분화(granularity)를 가지며 가벼운 프로토콜들(lightweight protocol)을 사용한다. 일 실시예에서, 서비스들은 독립적으로 배치할 수 있다(deployable). 시스템의 기능들을 상이한 작은 서비스들로 분배시킴으로써, 시스템의 응집력(cohesion)은 증강되고 시스템의 커플링(coupling)은 축소된다. 이것은 임의의 시간에 기능들 및 특징들을 시스템에 추가하고 시스템을 바꾸는 것을 더 쉽게 만든다. 또한 개별 서비스의 아키텍처가 연속적인 리팩터링(refactoring)을 통하여 현출되는 것을 허용하여서 큰 최신 유행의 디자인에 대한 요구를 줄이고 소프트웨어를 빨리 그리고 연속적으로 릴리즈하는 것(releasing)을 허용한다.
일 실시예에서, 마이크로서비스들 아키텍처에서, 애플리케이션은 서비스들의 집합(collection)으로 전개되고, 각각의 서비스는 개별 프로세스를 실행하고 통신하기 위해 가벼운 프로토콜(예를 들어, 각각의 마이크로서비스에 대한 고유의 API)을 사용한다. 마이크로서비스들 아키텍처에서, 개별 서비스들/성능들로의 소프트웨어의 분해(decomposition)은 제공될 서비스에 의존하는 세분화의 상이한 레벨들에서 수행될 수 있다. 마이크로서비스는 런타임 컴포넌트/프로세스이다. 각각의 마이크로서비스는 다른 모듈들/마이크로서비스들과 대화할 수 있는 자체 완비된 모듈이다. 각각의 마이크로서비스는 다른 것들에 의해 컨택될 수 있는 이름이 없는 범용 포트(unnamed universal port)를 가진다. 일 실시예에서, 이름이 없는 마이크로서비스의 범용 포트는 마이크로서비스가 관례(convention) (예를 들어, 통상의 HTTP(Hypertext Transfer Protocol) 포트로서)에 의해 노출되고 동일한 서비스내에 임의의 다른 모듈/마이크로서비스가 그것에 대화하는 것을 허용하는 표준 통신 채널이다. 마이크로서비스 또는 임의의 다른 자체 완비된 기능 모듈(self-contained functional module)는 포괄적으로 “서비스”로서 지칭될 수 있다.
실시예들은 멀티-테넌트 아이덴티티 관리 서비스들을 제공한다. 실시예들은 다양한 애플리케이션들과의 용이한 통합을 보장하기 위해 오픈 표준들(open standard)에 기반되고, 표준들기반의 서비스들을 통하여 IAM 성능들을 전달한다.
실시예들은 아이덴티티가 무엇을 액세스할 수 있고, 누가 이런 액세스를 제공받을 수 있고, 누가 이런 액세스를 관리할 수 있는지, 등의 결정 및 시행을 수반하는 유저 아이덴티티들의 라이프사이클(lifecycle)을 관리한다. 실시예들은 클라우드에 아이덴티티 관리 워크로드(management workload)를 시행하고 반드시 클라우드에 있을 필요가 없는 애플리케이션들에 대한 보안 기능을 지원한다. 실시예들에 의해 제공된 아이덴티티 관리 서비스들은 클라우드로부터 구매될 수 있다. 예를 들어, 기업(enterprise)은 그들의 애플리케이션들에 대한 그들의 직원들의 액세스를 관리하기 위해 클라우드로부터 이런 서비스들을 구매할 수 있다.
실시예들은 시스템 보안, 엄청난 확장성(massive scalability), 엔드 유저 유용성, 및 애플리케이션 상호동작성(interoperability)을 제공한다. 실시예들은 고객들에 의한 아이덴티티 서비스들의 사용 및 클라우드의 성장(growth)를 다룬다. 마이크로서비스들 기반 토대(foundation)는 수평 확장성 요건들을 처리하지만, 그러나 주의깊은 서비스들의 오케스트레이션(orchestration)은 기능 요건들을 처리한다. 양쪽 목표들을 달성하는 것은 궁극적인 일관성(consistency)을 갖는 스테이트리스를 달성하기 위해 비즈니스 로직의 분해 (가능한 곳은 어디나)을 요구하지만, 실시간 프로세싱을 따르지 않는 많은 동작상의 로직은 보장된 전달 및 프로세싱을 갖는 고 확장가능한 비동기식 이벤트 관리 시스템으로 오프로딩함으로써 근-실시간으로 시프트(shift)된다. 실시예들은 시스템 운영의 용이 및 비용 효율성들을 실현하기 위해서 웹 티어(web tier)로부터 데이터 티어(data tier)까지 전체 멀티-테넌트이다.
실시예들은 애플리케이션들과의 용이한 통합을 위하여 산업 표준들에 기반된다 (예를 들어, OpenID Connect, OAuth2, SAML2(Security Assertion Markup Language 2), SCIM(System for Cross-domain Identity Management), REST(Representational State Transfer), 등). 일 실시예는 클라우드-스케일 API 플랫폼을 제공하고 탄성적 확장성을 위해 수평으로 확장가능한 마이크로서비스들을 구현한다. 실시예는 클라우드 원리들을 레버리지(leverage)하고 각-테넌트 데이터 분리를 갖는 멀티-테넌트 아키텍처를 제공한다. 실시예는 추가로 테넌트 자가-서비스를 통하여 각-테넌트 맞춤화(customization)을 제공한다. 실시예는 다른 아이덴티티 서비스들과의 온-디멘드 통합을 위해 API들을 통하여 이용 가능하고 연속적인 피처 릴리즈(feature release)를 제공한다.
일 실시예는 상호동작성을 제공하고 클라우드 및 온-프레미스에서 IDM(identity management) 기능에서의 투자를 레버리지한다. 실시예는 온-프레미스 LDAP(Lightweight Directory Access Protocol) 데이터로부터 클라우드 데이터까지 그리고 그 반대로 자동화된 아이덴티티 동기화를 제공한다. 실시예는 클라우드와 기업간에 SCIM 아이덴티티 버스를 제공하고, 하이브리드 클라우드 배치들 (예를 들어, 아이덴티티 연합 및/또는 동기화, SSO 에이전트들, 유저 프로비저닝 커넥터들, 등)을 위한 상이한 옵션들을 허용한다.
따라서, 일 실시예는 클라우드기반의 멀티-테넌트 아이덴티티 및 액세스 관리 서비스들을 제공하기 위해 스테이트리스(stateless) 중간 티어에서 많은 마이크로서비스들을 구현하는 시스템이다. 일 실시예에서, 각각의 요청된 아이덴티티 관리 서비스는 실시간 태스크들, 및 근-실시간(near-real-time) 태스크들로 쪼개진다. 실시간 태스크들은 중간 티어에 마이크로서비스에 의해 핸들링되는 한편, 근-실시간(near-real-time) 태스크들은 메시지 큐에 오프로드된다. 실시예들은 마이크로서비스들을 액세스하기 위해 보안 모델을 시행하는 라우팅 티어에 의해 소모되는 토큰들을 구현한다. 따라서, 실시예들은 멀티-테넌트, 마이크로서비스들 아키텍처에 기반된 클라우드-스케일 IAM 플랫폼을 제공한다.
일반적으로, 알려진 시스템들은 상이한 환경들, 예를 들어, 기업 클라우드 애플리케이션들, 파트너 클라우드 애플리케이션들, 제 3 자 클라우드 애플리케이션들, 및 고객 애플리케이션들에 의해 제공된 애플리케이션들에 대한 사일로 액세스(siloed access)를 제공한다. 이러한 사일로 액세스는 다수의 패스워드들, 상이한 패스워드 정책들, 상이한 계정 프로비저닝 및 디-프로비저닝(de-provisioning) 기법들, 서로 전혀 다른 감사, 등을 필요로 할 수 있다. 그러나, 일 실시예는 이런 애플리케이션들 상에서 단일화된 IAM 기능을 제공하는 IDCS를 구현한다. 도 1 은 유저들 및 애플리케이션들 온보딩(onboard)을 위한 단일화된(unified) 아이덴티티 플랫폼 (126)을 제공하는 IDCS (118)를 갖는 대표적 실시예의 블럭 다이어그램 (100)이다. 실시예는 다양한 애플리케이션들 예컨대 기업 클라우드 애플리케이션들 (102), 파트너 클라우드 애플리케이션들 (104), 제 3 자 클라우드 애플리케이션들 (110), 및 고객 애플리케이션들 (112)에 걸쳐서 무결절 유저 경험(seamless user experience)을 제공한다. 애플리케이션들 (102,104,110,112)은 상이한 채널들, 예를 들어, 이동 전화 (106)를 통한 이동 전화 유저 (108)에 의해, 브라우저 (114)를 통한 데스크탑 컴퓨터 유저 (116)에 의해, 등을 통하여 액세스될 수 있다. 웹 브라우저(web browser) (통상 브라우저로 지칭된다)는 World Wide Web상에 서 정보 자원들을 검색(retrieve)하고, 제시(present)하고 그리고 돌아다니기(traverse) 위한 소프트웨어 애플리케이션이다. 웹 브라우저들의 예들은 Mozilla Firefox®, Google Chrome®, Microsoft Internet Explorer®, 및 Apple Safari®이다.
IDCS (118)은 디바이스들 및 애플리케이션들 (아이덴티티 플랫폼 (126)을 통하여), 및 단일화된 방식의 운영(administration) (admin 콘솔 (122)을 통하여)을 거쳐서 단일화된 보안 자격(secure credential), 유저의 애플리케이션들의 단일화된 뷰(unified view)(124)를 제공한다. IDCS 서비스들은 IDCS API들 (142)을 호출(call)함으로써 획득될 수 있다. 이런 서비스들은 예를 들어, 로그인/SSO 서비스들 (128) (예를 들어, OpenID Connect), 연합 서비스(federation service)들 (130) (예를 들어, SAML), 토큰 서비스들 (132) (예를 들어, OAuth), 디렉토리 서비스들 (134) (예를 들어, SCIM), 프로비저닝(provisioning) 서비스들 (136) (예를 들어, SCIM 또는 AToM(Any Transport over Multiprotocol)), 이벤트 서비스들 (138) (예를 들어, REST), 및 역할 기반 액세스 제어 (“RBAC : role-based access control”) 서비스들 (140) (예를 들어, SCIM)를 포함할 수 있다. IDCS (118)는 개설된(offered) 서비스들에 관련된 레포트(report)들 및 대시보드(dashboard)들 (120)을 추가로 제공할 수 있다.
통합 툴들(Integration Tools)
일반적으로, 큰 규모의 회사들이 그들의 온-프레미스 애플리케이션들에 대한 보안 액세스를 위한 준비가 되어 있는 IAM 시스템을 구비하는 것이 보통이다. 비즈니스 업무 (practice)들은 일반적으로 인 하우스(in-house) IAM 시스템 예컨대 Oracle 회사의 “Oracle IAM 스위트(suite)”에 맞춰 완성되고 표준화된다. 심지어 작은 내지 중간 단체들은 일반적으로 간단한 디렉토리 솔루션 예컨대 Microsoft 액티브 디렉토리(“AD : Active Directory”)을 통하여 유저 액세스를 관리하는 것에 맞춰 디자인된 그들의 비즈니스 프로세스들을 가진다. 온-프레미스 통합을 가능하게 하기 위해서, 실시예들은 고객들이 그들의 애플리케이션들을 IDCS와 통합하는 것을 허용하는 툴들을 제공한다.
도 2 는 클라우드 환경 (208)에 IDCS (202)로 온-프레미스 (206)에 있는 AD (204)와 통합을 제공하는 대표적 실시예의 블럭 다이어그램 (200)이다. 실시예는 온-프레미스 및 제 3 자 애플리케이션들, 예를 들어, 온-프레미스 애플리케이션들 (218) 및 클라우드 (208)내 다양한 애플리케이션들/서비스들 예컨대 클라우드 서비스들 (210), 클라우드 애플리케이션들 (212), 파트너 애플리케이션들 (214), 및 고객 애플리케이션들 (216)을 포함하는 모든 애플리케이션들에 걸쳐서 무결절 유저 경험을 제공한다. 클라우드 애플리케이션들 (212)은 예를 들어, 인적 자산 관리 (“HCM : Human Capital Management”), CRM, 인재 취득(talent acquisition) (예를 들어, Oracle 회사에 Oracle Taleo 클라우드 서비스), CPQ(Configure Price 및 Quote), 등을 포함할 수 있다. 클라우드 서비스들 (210)은 예를 들어, PaaS(Platform as a Service), 자바, 데이터베이스, BI(business intelligence), 문서들, 등을 포함할 수 있다.
애플리케이션들 (210,212,214,216,218)은 상이한 채널들, 예를 들어, 이동 전화 (220)를 통한 이동 전화 유저 (220)에 의해, 브라우저 (226)를 통한 데스크탑 컴퓨터 유저 (224)에 의해, 등을 통하여 액세스될 수 있다. 실시예는 클라우드 (208)와 기업(enterprise) (206) 간의 SCIM 아이덴티티 버스 (234) 를 통하여 온-프레미스 AD 데이터로부터 클라우드 데이터로 자동화된 아이덴티티 동기화(synchronization)를 제공한다. 실시예는 추가로 클라우드 (208)로부터 온-프레미스 AD (204)로 인증(authentication)을 (예를 들어, 패스워드들 (232)을 이용하여) 연합하기 위한 SAML 버스 (228)를 제공한다.
일반적으로, 아이덴티티 버스는 아이덴티티 관련 서비스들을 위한 서비스 버스이다. 서비스 버스는 하나의 시스템에서 다른 시스템으로 메시지들을 전달하기 위한 플랫폼을 제공한다. 그것은 예를 들어, SOA(service oriented architecture)에서 신뢰된 시스템들간에 정보 상호교환하기 위한 제어되는 메커니즘이다. 아이덴티티 버스는 표준 HTTP 기반 메커니즘들 예컨대 웹 서비스, 웹 서버 프락시들, 등에 따라 빌드된 로직상의 버스(logical bus)이다. 아이덴티티 버스에서 통신은 개별 프로토콜 (예를 들어, SCIM, SAML, OpenID Connect, 등)에 따라 수행될 수 있다. 예를 들어, SAML 버스는 SAML 서비스들을 위한 메시지들을 전달하기 위한 두개의 시스템들간 HTTP 기반 연결이다. 유사하게, SCIM 버스는 SCIM 프로토콜에 따른 SCIM 메시지들을 전달하기 위해 사용된다.
도 2의 실시예는 고객 AD (204)에 접하여 온-프레미스 (206)에 다운로드되고 인스톨될 수 있는 작은 바이너리(binary) (예를 들어, 1 MB 사이즈)인 아이덴티티 (“ID”) 브리지 (230)를 구현한다. ID 브리지 (230)는 고객에 의해 선택된 OU(organizational unit)들로부터 유저들 및 그룹들 (예를 들어, 유저들의 그룹들)을 청취하고(listen to) 해당 유저들을 클라우드 (208)에 동기화한다. 일 실시예에서, 유저들의 패스워드들 (232)은 클라우드 (208)에 동기화되지 않는다. 고객들은 IDCS 유저들의 그룹들을 IDCS (208)에 관리되는 클라우드 애플리케이션들에 매핑함으로써 유저들에 대한 애플리케이션 액세스를 관리할 수 있다. 유저들의 그룹 멤버쉽이 온-프레미스 (206)에서 변화될 때 마다, 그것들의 대응하는 클라우드 애플리케이션 액세스는 자동으로 변화한다.
예를 들어, 엔지니어링(engineering)에서 판매로 이동하는 직원은 판매 클라우드에 대한 거의 즉각적인 액세스를 획득하고 개발자 클라우드에 대한 액세스를 상실할 수 있다. 이 변화가 온-프레미스 AD (204)에 반영된 때, 클라우드 애플리케이션 액세스 변화는 근-실시간(near-real-time)으로 성취된다. 유사하게, IDCS (208)에 관리되는 클라우드 애플리케이션들에 대한 액세스는 회사를 나가는 유저들에 대하여 철회된다. 완전 자동화를 위하여, 고객들은 엔드 유저들이 단일 회사 패스워드 (332)로 클라우드 애플리케이션들 (210,212,214,216), 및 온-프레미스 애플리케이션들 (218)에 대한 액세스를 획득할 수 있도록 예를 들어, AD 연합 서비스 (“AD/FS”, 또는 SAML 연합(federation)을 구현하는 일부 다른 메커니즘)를 통하여 온-프레미스 AD (204)와 IDCS (208)간에 SSO를 셋 업할 수 있다.
도 3 은 도 2에서와 동일한 컴포넌트들 (202,206,208,210,212,214,216,218,220,222,224,226,228,234)을 포함하는 대표적 실시예의 블럭 다이어그램 (300)이다. 그러나, 도 3의 실시예에서, IDCS (202)은 온-프레미스 IDM (304) 예컨대 Oracle IDM과 통합을 제공한다. 오라클 IDM (304)은 IAM 기능을 제공하기 위한 Oracle Corp.의 소프트웨어 스위트(suite)이다. 실시예는 온-프레미스 및 제 3 자 애플리케이션들을 포함하여 모든 애플리케이션들에 걸쳐 무결절 유저 경험을 제공한다. 실시예는 온-프레미스 클라우드 (202)와 기업 (206) 사이의 SCIM 아이덴티티 버스 (234)를 통하여 온-프레미스 IDM (304)으로부터 IDCS (208)로 유저 아이덴티티들을 프로비저닝한다. 실시예는 추가로 클라우드 (208)로부터 온-프레미스(206)로 인증을 연합하기 위한 SAML 버스 (228) (또는 OpenID Connect 버스)를 제공한다.
도 3의 실시예에서, Oracle Corp.에 OIM(Oracle Identity Manager) 커넥터 (302) 및 Oracle Corp.에 OAM(Oracle Access Manager) 연합 모듈 (306)은 Oracle IDM (304)의 확장 모듈들로서 구현된다. 커넥터는 어떻게 시스템에 대화를 할 것인지에 대한 물리적 인식(physical awareness)을 갖는 모듈이다. OIM은 유저 아이덴티티들 (예를 들어, 유저가 액세스를 가져야 하는 것과 액세스를 가지지 않아야 하는 것에 기초하여 상이한 시스템들내 유저 계정들을 관리하는)을 관리하도록 구성된 애플리케이션이다. OAM은 액세스 관리 기능 예컨대 웹 SSO; 아이덴티티 컨텍스트, 인증 및 인증; 정책 운영; 테스팅; 로깅(logging); 감사(auditing); 등을 제공하는 보안 애플리케이션이다. OAM은 SAML을 위한 빌트 인 지원(built-in support)를 갖는다. 만약 유저가 IDCS (202)에 계정을 가지면, OIM 커넥터 (302) 및 OAM 연합 (306)은 해당 계정으로부터 액세스를 관리하고 해당 계정을 신설/삭제하기 위해 Oracle IDM (304)와 함께 사용될 수 있다.
도 4 는 도면들 2 및 3에서와 동일한 컴포넌트들 (202,206,208,210,212,214,216,218,220,222,224,226,234) 을 포함하는 대표적 실시예의 블럭 다이어그램(400)이다. 그러나, 도 4의 실시예에서, IDCS (202)은 클라우드 아이덴티티들을 온-프레미스 애플리케이션들 (218)에 확장하는 기능을 제공한다. 실시예는 온-프레미스 및 제 3 자 애플리케이션들을 포함하여 모든 애플리케이션들에 걸쳐 아이덴티티의 무결절 뷰(seamless view)를 제공한다. 도 4의 실시예에서, SCIM 아이덴티티 버스 (234)는 IDCS (202)내 데이터를 온-프레미스 LDAP 데이터 소위 “클라우드 캐시(Cloud Cache)” (402)와 동기화하기 위해 사용된다. 클라우드 캐시 (402)는 아래에 보다 상세하게 개시된다.
일반적으로, LDAP에 기초하여 통신하도록 구성된 애플리케이션은 LDAP 연결을 필요로 한다. LDAP 연결은 LDAP가 로컬 네트워크상에 있는 것을 요구하기 때문에 URL을 통하여 이런 애플리케이션에 의해 수립되지 않을 수 있다 (예를 들어, Google로 연결을 제공하는 “www.google.com”과 달리). 도 4의 실시예에서, LDAP기반의 애플리케이션 (218)은 클라우드 캐시 (402)로 연결을 제공하고, 클라우드 캐시 (402)는 IDCS (202)로 연결을 수립하고 그런 다음 데이터가 요청되어질 때 데이터를 IDCS (202)로부터 빼낸다. IDCS (202)와 클라우드 캐시 (402) 사이의 통신은 SCIM 프로토콜에 따라 구현될 수 있다. 예를 들어, 클라우드 캐시 (402)는 SCIM 요청을 IDCS (202)로 발송하고 대응하는 데이터를 리턴하여 수신하기 위해 SCIM 버스 (234)를 사용할 수 있다.
일반적으로, 애플리케이션을 완벽하게 구현하는 것은 소비자 포털(consumer portal)를 빌드하는 것(building), 외부 유저 모집단(external user population)에 마케팅 캠페인(marketing campaign)을 실행하는 것, 웹 및 모바일 채널들을 지원하는 것, 및 유저 인증, 세션들, 유저 프로파일들, 유저 그룹들, 애플리케이션 역할들, 패스워드 정책들, 셀프-서비스/등록(self-service/registration), 소셜 통합(social integration), 아이덴티티 연합(identity federation)을 처리하는 것 등을 포함한다. 일반적으로, 애플리케이션 개발자들은 아이덴티티/보안 전문가들이 아니다. 따라서, 온-디멘드(on-demand) 아이덴티티 관리 서비스들이 희망된다.
도 5 는 도면들 2-4에서와 동일한 컴포넌트들 (202,220,222,224,226,234,402)를 포함하는 대표적 실시예의 블럭 다이어그램(500)이다. 그러나, 도 5의 실시예에서, IDCS (202)은 온 디멘드 보안 아이덴티티 관리를 제공한다. 실시예는 IDCS (202)의 아이덴티티 서비스들과 온 디멘드 통합을 제공한다 (예를 들어, 표준들 예컨대 OpenID Connect, OAuth2, SAML2, 또는 SCIM에 기초하여). 애플리케이션들 (505) (온-프레미스에, 퍼블릭 클라우드에, 또는 프라이비트 클라우드에 있을 수 있는)은 IDCS (202)내 아이덴티티 서비스 API들 (504)을 호출할 수 있다. IDCS (202)에 의해 제공되는 서비스들은 예를 들어, 셀프-서비스 등록 (506), 패스워드 관리 (508), 유저 프로파일 관리 (510), 유저 인증 (512), 토큰 관리 (514), 소셜 통합 (516), 등을 포함할 수 있다.
이 실시예에서, SCIM 아이덴티티 버스 (234)는 IDCS (202)내 데이터를 온-프레미스 LDAP 클라우드 캐시 (402)내 데이터와 동기화하기 위해 사용된다. 더구나, 웹 서버/프락시 (예를 들어, NGINX, Apache, 등) 상에서 운영하는 “클라우드 게이트(Cloud Gate)” (502)는 IDCS (202)로부터 유저 웹 SSO 및 REST API 보안을 획득하기 위해 애플리케이션들 (505)에 의해 사용될 수 있다. 클라우드 게이트 (502)는 SSO 세션들을 수립하기 위해 유저들이 성공적으로 인증되고 및/또는 클라이언트 애플리케이션들이 유효한 액세스 토큰들을 제공하는 것을 보장함으로써 멀티-테넌트(multi-tenant) IDCS 마이크로서비스(microservice)들에 대한 엑세스를 안전하게 하는 컴포넌트이다. 클라우드 게이트 (502)가 아래에 추가로 개시된다. 클라우드 게이트 (502) (웹게이트/웹에이전트에 유사한 집행점(enforcement point))는 지원되는 웹 서버들 뒤에서 운영되는 애플리케이션들이 SSO에 참여하는 것을 가능하게 한다.
일 실시예는 SSO 및 클라우드 SSO 기능을 제공한다. 많은 단체들내 온-프레미스 IAM 및 IDCS 양쪽을 위한 엔트리의 총체적 지점(general point)는 SSO이다. 클라우드 SSO는 유저들이 단일 유저 사인-인(sign-in)으로 다수의 클라우드 자원들을 액세스하는 것을 가능하게 한다. 흔히, 단체들은 그들의 온-프레미스 아이덴티티들을 연합하기를 원할 것이다. 따라서, 실시예들은 투자(investment)를 보존하고 확장하기 위해 (예를 들어, 아이덴티티 클라우드 서비스 접근에 대한 완전하고, 최종적인 전환이 이루어질 때 까지) 현존하는 SSO와 통합을 허용하는 오픈 표준들을 활용한다.
일 실시예는 이하의 기능들을 제공할 수 있다:
ㆍ 유저 계정들, 소유권(ownership), 액세스, 및 인가된 허가들을 추적하기 위해 아이덴티티 저장소(identity store) 유지,
ㆍ 애플리케이션들 액세스를 위해 요구되는 다양한 승인들 (예를 들어, 관리, IT, 인적 자원들, 법적, 및 준수)을 가능하게 하기 위해 워크플로우(workflow)와 통합,
ㆍ 많은 개인 및 퍼블릭 클라우드 자원들을 함유하는 유저 포털에 대한 액세스를 갖는 선택적 디바이스들 (예를 들어, 모바일 및 퍼스널 컴퓨터 (“PC: personal computer”))에 대한 SaaS 유저 계정들 프로비저닝, 및
ㆍ 조절들 및 현재 작업 책임들 준수를 위한 주기적인 관리 증명업무 리뷰(attestation review)를 가능하게 하기.
이들 기능들에 추가하여, 실시예들은 추가로 이하를 제공할 수 있다:
ㆍ 클라우드 애플리케이션들에 계정 라이프 사이클을 관리하기 위한 클라우드 계정 프로비저닝(provisioning),
ㆍ 보다 강건한 MFA(multifactor authentication) 통합,
ㆍ 광대한 모바일 보안 성능들, 및
ㆍ 동적 인증 옵션들.
일 실시예는 적응적(adaptive) 인증 및 MFA을 제공한다. 일반적으로, 패스워드들 및 챌린지 질문(challenge question)들은 흔한 공격들 예컨대 피싱(phishing)에 부적절하고 민감한 것으로 보여져 왔다. 오늘날 대부분의 비즈니스 엔티티(entity)들은 MFA 위험을 줄이기 위해 MFA의 일부 형태에서 검토하고 있다. 성공적으로 배치되도록 하기 위해, 그러나, 솔루션들은 엔드 유저들이 일반적으로 그들의 디지털 경험을 방해하는 어떤 것에 저항할 때 엔드 유저에 의해 용이하게 프로비저닝되고, 유지되고, 및 이해되어야 할 필요가 있다. 회사들은 MFA를 무결절 유저 액세스 경험의 거의 투명 컴포넌트(transparent component)로 함과 동시에 BYOD(bring your own device), 소셜 아이덴티티들, 원격 유저들, 고객들, 및 계약자들을 안전하게 통합하는 방법들을 찾고 있다. MFA 배치 내에서, 산업 표준들 예컨대 OAuth 및 OpenID Connect은 보다 새롭고, 적응적 인증 기술의 통합 및 현존하는 다인자(multifactor) 솔루션들의 통합을 보장하기 위해서 필수이다. 따라서, 실시예들은 유저 세션이 개시된 후에 아이덴티티를 입증하기 위해서 이용 가능한 정보 (즉, IP 어드레스, 위치, 시각, 및 생체 인식(biometric)들)의 평가로서 동적 (또는 적응적) 인증을 정의한다. 적절한 표준들 (예를 들어, 오픈 인증 (“OATH : open authentication”) 및 패스트 아이덴티티 온라인 (“FIDO : fast identity online”)) 통합 및 확장가능한 아이덴티티 관리 프레임워크를 갖는, 실시예들은 단-대-단 보안 IAM 배치의 일부로서 IT 단체내에서 용이하게 채택, 업그레이드, 및 통합될 수 있는 MFA 솔루션들을 제공한다. MFA 및 적응적 정책들을 고려할 때, 단체들은 온-프레미스 및 클라우드 자원들을 가로질러 일관된 정책들을 구현하여야만 하고, 이는 하이브리드 IDCS 및 온-프레미스 IAM 환경에서 시스템들 간에 통합을 요구한다.
일 실시예는 유저 프로비저닝 및 자격증명(certification)을 제공한다. 일반적으로, IAM 솔루션의 근본적인 기능은 전체 유저 프로비저닝 라이프 사이클을 가능하게 하고 지원하는 것이다. 이것은 유저들에게 그들의 아이덴티티 및 단체내에서의 역할(role)에 대하여 적절한 애플리케이션 액세스를 제공하는 것, 그들이 올바른 진행중인 액세스 허가들을 가진다는 것을 자격증명하는 것 (예를 들어, 그들의 역할내에서 사용되는 그들의 역할 또는 태스크들 또는 애플리케이션들이 시간이 흐르면서 변화할 때)을 포함하고, 단체로부터 그들이 떠날 때 그들을 지체없이 디-프로비저닝이 필요로 할 수 있다. 이것은 다양한 준수 요건들을 중촉시키기 위해서 뿐만 아니라 또한 부적절한 내부자 액세스는 보안 구멍들 및 공격들의 주된 원인이기 때문에 중요하다. 아이덴티티 클라우드 솔루션내에서 자동화된 유저 프로비저닝 성능은 그것 자체의 자격에서 뿐만 아니라 또한 하이브리드 IAM 솔루션의 일부로서 중요할 수 있고 이에 의해 IDCS 프로비저닝은 회사가 다운사이즈, 업사이즈, 병합, 또는 현존하는 시스템들을 IaaS/PaaS/SaaS 환경들과 통합하고자 할 때 전환을 위해 온-프레미스 솔루션보다 더 큰 가요성을 제공할 수 있다. IDCS 접근법은 단 한번의(one-off) 업그레이드들로 시간 및 노력을 절약할 수 있고 필요한 부문(department)들, 분할(division)들, 및 시스템들 중에서 적절한 통합을 보장할 수 있다. 이 기술을 확장하는 것에 대한 요구는 종종 회사들 몰래 할 수 있고, 기업을 가로질러 즉각적으로 확장가능한(scalable) IDCS 성능을 전달하는 능력은 가요성, 비용, 및 제어에서 장점들을 제공할 수 있다.
일반적으로, 직원은 그/그녀의 작업이 바뀔 때 수년간 추가의 특권들이 수여된다 (즉, "특권층(privilege creep)"). 가볍게 규제되는 회사들은 일반적으로 과도하게 특권이 주어진(over-privileged) 계정들로 귀결되는 특권층을 중단하거나 느리게 하기 위해서 그들의 직원들의 특권들 (예를 들어, 네트워크들, 서버들, 애플리케이션들, 및 데이터에 대한 액세스) 정기적으로 감사하는 관리기들을 필요로 하는 "증명업무(attestation)" 프로세스가 없다. 따라서, 일 실시예는 정기적으로 수행되는 (적어도 일년에 한 번) 증명업무 프로세스를 제공할 수 있다. 더구나, 병합(merger)들 및 취득(acquisition)들에 따라, 유저들이 SaaS 시스템들, 온-프레미스상에 있을 때, 상이한 부문들(department)에 걸쳐 이어지고, 및/또는 디-프로비저닝(de-provision)되거나 또는 재-할당될 때 이들 툴들 및 서비스들에 대한 요구들은 지수함수적으로 증가한다. 클라우드로의 이동은 추가로 이 상황을 혼란시킬 수 있고, 상황은 현존하는, 흔히 수동으로 관리되는, 자격증명 방법들을 초과하여 빠르게 악화될 수 있다. 따라서, 일 실시예는 이들 기능들을 자동화하고 유저 프로파일들, 액세스 이력, 프로비저닝/디-프로비저닝, 및 아주 세밀한 권리자격(entitlement)들에 대한 정교한 분석(analytics)을 적용한다.
일 실시예는 아이덴티티 분석(identity analytics)을 제공한다. 일반적으로, 포괄적인 자격증명(certification) 및 증명업무(attestation)을 위해 아이덴티티 분석을 IAM 엔진과 통합시키는 능력은 단체의 위험 프로파일을 안전하게 하는 것에 중요할 수 있다. 적절하게 배치된 아이덴티티 분석은 총 내부 정책 집행(total internal policy enforcement)을 요구할 수 있다. 클라우드 및 온-프레미스를 거쳐 단일화된(unified) 단일 관리 뷰를 제공하는 아이덴티티 분석은 순향(proactive) GRC(governance, risk and compliance) 기업 환경에 훨씬 요구되고, 위험을 줄이고 준수 규정들을 충족시키기 위한 폐쇄-루프 프로세스(closed-loop process)을 제공하는데 도움을 줄 수 있다. 따라서, 일 실시예는 관리기(manager)들, 집행부(executive)들, 및 감사기(auditor)들에 의해 요구되는 레포트들 및 분석에 대한 특정 산업 수요들 및 정부 규정들을 수용하기 위해 클라이언트에 의해 용이하게 맞춤화가능한 아이덴티티 분석을 제공한다.
일 실시예는 엔드 유저의 경험 및 효율을 개선시키고 헬프 데스크(help desk) 호출들로부터 비용을 줄이기 위한 자가-서비스 및 액세스 요청 기능을 제공한다. 일반적으로, 많은 회사들이 그들의 직원들을 위한 온-프레미스 자가-서비스 액세스 요청을 배치하지만, 많은 회사들은 공식 회사 벽들 외측에 적절하게 이들 시스템들을 확장하지 않는다. 직원 사용을 너머, 긍정적인 디지털 고객 경험은 비즈니스 신뢰도를 증가시키고 궁극적으로 매출 성장(revenue increase)에 기여하고, 회사들은 고객 헬프 데스크 호출들 및 비용을 덜어줄 뿐만 아니라 또한 고객 만족을 증가시킨다. 따라서, 일 실시예는 필요한 때 현존하는 액세스 제어 소프트웨어 및 MFA 메커니즘들과 무결절로(seamlessly)로 통합하고 오픈 표준들에 기초하는 아이덴티티 클라우드 서비스 환경을 제공한다. SaaS 전달 모델(delivery model)은 더 많은 코어 비즈니스 애플리케이션들에 집중하는 전문적인 IT 스태프(staff) 없이 시스템들 업그레이드들 및 유지보수에 바치는 시간 및 노력을 절약한다.
일 실시예는 PAM(privileged account management)를 제공한다. 일반적으로, SaaS, PaaS, IaaS, 또는 온-프레미스 애플리케이션들을 사용하든지 아니든지 모든 단체는 슈퍼-유저 액세스 자격들 예컨대 시스템 관리자들, 집행부들, HR 오피서(officer)들, 계약자들, 시스템들 적분회로망(system integrator)들, 등을 갖는 내부자들에 의한 인가 받지 않은 특권이 주어진 계정 남용에 취약하다. 게다가, 외부 위협들은 전형적으로 먼저 저-레벨 유저 계정 구멍을 뚫고(breach) 결국에는 기업 시스템 내에 특권이 주어진 유저 액세스 제어들에 도달하고 활용한다. 따라서, 일 실시예는 이런 인가 받지 않은 내부자 계정 사용을 방지하기 위해 PAM을 제공한다. PAM 솔루션의 메인 컴포넌트는 다양한 방식들로, 예를 들어, 기업 서버상에 인스톨될 소프트웨어로서, 또한 기업 서버상의 가상 기기로서, 패키징된 하드웨어/소프트웨어 기기로서, 또는 클라우드 서비스의 일부로서 전달될 수 있는 패스워드 볼트(password vault)이다. PAM 기능은 그것에 사인 인 및 아웃하기 위한 명단(manifest)와 함께, 엔빌로프(envelope)에 보관되어 주기적으로 바뀌는 패스워드들을 저장하기 위해 사용되는 물리적 금고(physical safe)에 유사하다. 일 실시예는 패스워드 체크아웃 뿐만 아니라 시간 한계들을 설정하고, 주기적인 변화들을 강제하고, 자동으로 체크아웃을 추적하고, 및 모든 활동들에 대관 레포팅(reporting)을 허용한다. 일 실시예는 유저가 전혀 패스워드를 알지 않고서 요청된 자원에 직접 통과하여 연결하는 방법을 제공한다. 이 성능은 또한 세션 관리 및 추가 기능을 위한 방법을 조성한다.
일반적으로, 대부분의 클라우드 서비스들은 API들 및 관리상의 인터페이스들을 사용하고, 이는 보안을 우회하는 잠입자(infiltrator)들에게 기회들을 제공한다. 따라서, 일 실시예는 PAM에 대한 새로운 난제들을 제시하는 클라우드로의 이동과 같이 PAM 실행에서의 이들 홀(hole)들을 설명한다. 많은 작은 사이즈 내지 중간 사이즈의 비즈니스들은 이제 그들의 자체 SaaS 시스템들 (예를 들어, 오피스 (365))를 관리하지만, 그러나 더 큰 회사들은 그들의 자체 SaaS 및 IaaS 서비스들을 스핀 업(spin up)하는 개별 비즈니스 유닛들을 가진다. 이들 고객들은 이 책임을 다루는데 거의 경험이 없지만 아이덴티티 클라우드 서비스 솔루션들내에 또는 그들의 IaaS/PaaS 제공자로부터 PAM 성능들을 그 자신들에게서 발견한다. 게다가, 일부 경우들에서, 많은 상이한 지리적으로 분산된 비즈니스 유닛들은 동일한 SaaS 애플리케이션들에 대한 관리상의 책임들을 분리하려고 노력한다. 따라서, 일 실시예는 이런 상황들에서 고객들이 비즈니스 요구들이 지시하는 클라우드 로드 요건들에 대한 확장(scaling)의 보증에 준수(compliance) 및 더 큰 보안으로부터 이동 및 아이덴티티 클라우드 서비스의 전체 아이덴티티 프레임워크(framework)으로 현존하는 PAM을 링크하는 것을 허용한다.
API 플랫폼 (API Platform)
실시예들은 서비스들로서 성능들의 집합(collection)을 노출시키는 API 플랫폼을 제공한다. API들은 마이크로서비스(microservice)들로 종합되고, 각각의 마이크로서비스는 하나 이상의 API들을 노출시킴으로써 하나 이상의 성능들을 제공한다. 즉, 각각의 마이크로서비스는 상이한 유형들의 API들을 노출(expose)시킬 수 있다. 일 실시예에서, 각각의 마이크로서비스는 단지 그것의 API들을 통하여 통신한다. 일 실시예에서, 각각의 API는 마이크로서비스일 수 있다. 일 실시예에서, 다수의 API들은 해당 서비스 (예를 들어, OAuth, SAML, Admin, 등)에 의해 제공될 타겟 성능에 기반된 서비스로 종합된다. 결과적으로, 유사한 API들은 개별 런타임 프로세스들로서 노출되지 않는다. API들은 IDCS에 의해 제공된 서비스들을 사용하기 위해 서비스 소비자에게 이용 가능하게 된 것이다.
일반적으로, IDCS의 웹 환경에서, URL은 세개의 파트들: 호스트, 마이크로서비스, 및 자원 (예를 들어, host/microservice/resource)을 포함한다. 일 실시예에서, 마이크로서비스는 특정 URL 프리픽스(prefix), 예를 들어, “host/oauth/v1”를 갖는 것에 의해 특징지어지고 여기서 실제 마이크로서비스는 “oauth/v1”이고, “oauth/v1”아래에는 다수의 API들, 예를 들어, 요청 토큰들에 대한 API: “host/oauth/v1/token”, 유저를 인증시키는 API: “host/oauth/v1/authorize”, 등이 있다. 즉, URL은 마이크로서비스를 구현하고, URL의 자원 부분은 API를 구현한다. 따라서, 다수의 API들은 동일한 마이크로서비스 아래에 종합되고, 각각의 요청은 아이덴티티 관리 서비스를 수행하도록 구성된 마이크로서비스 (예를 들어, OAuth) 및 아이덴티티 관리 서비스 (예를 들어, 토큰을 요청하고, 유저를 인증하고, 등)를 식별하는 API에 대한 호출을 포함한다.
일 실시예에서, URL의 호스트 부분은 테넌트 (예를 들어, https://tenant3.identity.Oraclecloud.com:/oauth/v1/token”)를 식별한다. 일 실시예에서, URL의 호스트 부분은 요청에 관련된 자원의 테넌시를 식별한다.
필요한 엔드 포인트들에게 외부 서비스들을 통합시키는 애플리케이션들을 구성하는 것 및 해당 구성을 최신으로 유지하는 것은 전형적으로 난제(challenge)이다. 이 난제를 대처하기 위해서, 실시예들은 애플리케이션들이 IDCS API들을 소비하기 위해 그것들이 필요한 IDCS에 대한 정보를 발견할 수 있는 주지의 위치에서 공공 탐지(public discovery) API를 노출시킨다. 일 실시예에서, 두개의 탐지 문서들이 지원된다: IDCS 구성 (예를 들어, <IDCS-URL>/.well-known/idcs-configuration에서 IDCS, SAML, SCIM, OAuth, 및 OpenID Connect 구성을 포함하는), 및 산업-표준 OpenID Connect 구성 (예를 들어, <IDCS-URL>/.well-known/openid-configuration에서). 애플리케이션들은 단일 IDCS URL로 구성됨으로써 탐지 문서들을 검색할 수 있다.
도 6은 일 실시예의 IDCS의 시스템 뷰(600)를 제공하는 블럭 다이어그램이다. 도 6에서, 여러 가지 애플리케이션들/서비스들 (602) 중 임의의 하나는 IDCS 서비스들을 사용하기 위해서 IDCS API들에 HTTP 호출들을 할 수 있다. 이런 애플리케이션들/서비스들 (602)의 예들은 웹 애플리케이션들, 고유 애플리케이션들 (예를 들어, 특정 운영 체제상에서 동작하도록 빌드된 애플리케이션들, 예컨대 윈도우들 애플리케이션들, iOS 애플리케이션들, 안드로이드 애플리케이션들, 등), 웹 서비스들, 고객 애플리케이션들, 파트너 애플리케이션들, 또는 퍼블릭 클라우드에 의해 제공되는 임의의 서비스들, 예컨대 SaaS(Software as a Service), PaaS, 및 IaaS(Infrastructure as a service)이다.
일 실시예에서, IDCS 서비스들을 필요로 하는 애플리케이션들/서비스들 (602)의 HTTP 요청들은 Oracle 퍼블릭 클라우드 BIG-IP 기기 (604) 및 IDCS BIG-IP 기기 (606) (또는 유사한 기술들 예컨대 트래픽을 보호하는 적절한 보안 규칙들을 구현하는 로드 밸런서(load balancer), 또는 컴포넌트 소위 클라우드 LBaaS(Load Balancer as a Service))을 거친다. 그러나, 요청들은 임의의 방식으로 수신될 수 있다. IDCS BIG-IP 기기 (606) (또는, 적용가능한, 유사한 기술 예컨대 로드 밸런서 또는 클라우드 LBaaS로서)에서, 클라우드 프로비저닝 엔진 (608)은 테넌트 및 서비스 오케스트레이션(orchestration)을 수행한다. 일 실시예에서, 클라우드 프로비저닝 엔진 (608)은 고객에 의해 구매된 클라우드 또는 새로운 서비스 인스턴스(instance)로 온-보드(on-board)된 새로운 테넌트와 관련된 내부 보안 아티팩트(internal security artifact)들을 관리한다.
HTTP 요청들은 그런 다음 보안 게이트 (즉, 클라우드 게이트)를 구현하는 IDCS 웹 라우팅 티어 (610)에 의해 수신되고 서비스 라우팅 및 마이크로서비스들 등록 및 탐지 (612)를 제공한다. 요청된 서비스에 의존하여, HTTP 요청은 IDCS 중간 티어 (614)내 IDCS 마이크로서비스로 포워딩된다. IDCS 마이크로서비스들은 외부 및 내부 HTTP 요청들을 프로세스한다. IDCS 마이크로서비스들은 플랫폼 서비스들 및 인프라스트럭처 서비스들을 구현한다. IDCS 플랫폼 서비스들은 IDCS의 비즈니스(business)를 구현하는 자바 기반의 런타임 서비스(runtime service)들에 별도로 배치된다. IDCS 인프라스트럭처 서비스들은 IDCS에 대한 인프라스트럭처 지원을 제공하는 런타임 서비스들에 별도로 배치된다. IDCS는 IDCS 서비스들 및 공유된 라이브러리들에 의해 사용되는 공유 라이브러리들서 패키징된 공통 코드(common code)인 인프라스트럭처 라이브러리들을 더 포함한다. 인프라스트럭처 서비스들 및 라이브러리들은 그들의 기능을 구현하기 위한 플랫폼 서비스들에 의해 요구되는 성능들을 지원하는 단계를 제공한다.
플랫폼 서비스들(Platform Services)
일 실시예에서, IDCS는 표준 인증 프로토콜들을 지원하여서, IDCS 마이크로서비스들은 플랫폼 서비스들 예컨대 OpenID Connect, OAuth, SAML2, SCIM++(System for Cross-domain Identity Management++), 등을 포함한다.
OpenID Connect 플랫폼 서비스는 표준 OpenID Connect Login/Logout 플로우들(flow)을 구현한다. 쌍방향 웹 기반 및 고유 애플리케이션들은 유저의 인증된 아이덴티티를 전달하는 JavaScript Object Notation (“JSON”) Web Tokens (“JWTs”)인 표준 아이덴티티 토큰들을 수신하여, 유저 인증 요청에 대한 표준 브라우저기반의 OpenID Connect 플로우를 레버리지(leverage)한다. 내적으로, 런타임 인증 모델은 호스트 HTTP 쿠키 (JWT 아이덴티티 토큰을 포함)의 형태로 유저의 인증/세션 스테이트를 유지하여 스테이트리스(stateless)이다. OpenID Connect 프로토콜을 통하여 개시된 인증 상호작용(interaction)은 로컬 및 연합 로그인들을 위한 유저 로그인/로그아웃 세러머니(ceremony)을 구현하는 신뢰된 SSO 서비스에 위임(delegate)된다. 이 기능의 추가 세부사항들은 도면들 10 및 11 를 참고로 하여 아래에 더 설명된다. 일 실시예에서, OpenID Connect 기능은 예를 들어, OpenID Foundation 표준들에 따라 구현된다.
OAuth2 플랫폼 서비스는 토큰 인증 서비스들을 제공한다. 그것은 API 호출들에 대한 유저 권리들을 전달하는 액세스 토큰들을 생성하고 승인하기 위한 리치(rich) API 인프라스트럭처를 제공한다. 그것은 다양한 유용한 토큰 승인 유형들을 지원하고, 고객들이 클라이언트들을 그들의 서비스들에 확실하게 연결하는 것을 가능하게 한다. 그것은 표준 2-각(two-legged) 및 3-각(three-legged) OAuth2 토큰 승인 유형들을 구현한다. OIDC(OpenID Connect)에 대한 지원은 순응하는(compliant) 애플리케이션들 (OIDC RP(relaying parties)들))이 아이덴티티 제공자 (OIDC OP(OpenID provider))로서 IDCS와 통합하는 것을 가능하게 한다. 유사하게, 소셜 OIDC OP (예를 들어, Facebook, Google, 등)와 OIDC RP로서 IDCS의 통합은 고객들이 애플리케이션들에 대한 소셜 아이덴티티들 정책기반 액세스를 허용하는 것을 가능하게 한다. 일 실시예에서, OAuth 기능은 예를 들어, IETF(Internet Engineering Task Force), RFC(Request for Comments) 6749에 따라 구현된다.
SAML2 플랫폼 서비스는 아이덴티티 연합 서비스(identity federation service)들을 제공한다. 그것은 고객들이 SAML IDP(identity provider) 및 SAML SP(service provider) 관계 모델들에 기초하여 그들의 파트너들과 연합 합의(federation agreement)을 셋 업하는 것을 가능하게 한다. 일 실시예에서, SAML2 플랫폼 서비스는 표준 SAML2 Browser POST Login 및 Logout Profiles들을 구현한다. 일 실시예에서, SAML 기능은 예를 들어, IETF, RFC 7522에 따라 구현된다.
SCIM은 예를 들어, IETF, RFC들 7642, 7643, 7644에 의해 제공된 아이덴티티 도메인들 또는 IT(information technology) 시스템들간에 유저 아이덴티티 정보 교환 자동화를 위한 오픈 표준이다. SCIM++ 플랫폼 서비스는 아이덴티티 운영 서비스들을 제공하고 고객들이 IDCS의 IDP 피처(feature)들을 액세스하는 것을 가능하게 한다. 운영 서비스(administration service)들은 아이덴티티 라이프사이클, 패스워드 관리, 그룹 관리, 등을 커버하는 스테이트리스 REST 인터페이스들 (즉, API들)의 세트를 노출시켜서, 이런 아티팩트들을 웹-액세스 가능한 자원들로서 노출시킨다.
모든 IDCS 구성 아티팩트(artifact)들은 자원들이고, 운영 서비스들의 API들은 IDCS 자원들 (예를 들어, 유저들, 역할들, 패스워드 정책들, 애플리케이션들, SAML/OIDC 아이덴티티 제공자들, SAML 서비스 제공자들, 키(key)들, 자격증명(certification)들, 통지 템플레이트(notification template)들, 등)을 관리하는 것을 허용한다. 운영 서비스들은 모든 IDCS 자원들 상에서의 CRUDQ(Create, Read, Update, Delete, and Query) 동작들을 위한 스키마(스키마) 기반의 REST API들을 구현하기 위해 SCIM 표준을 레버리지하고 확장된다. 추가적으로, IDCS 그 자체의 운영 및 구성을 위해 사용되는 IDCS의 모든 내부 자원들은 SCIM기반의 REST API들로서 노출된다. 아이덴티티 저장소 (618)에 대한 액세스는 SCIM++ API에 격리된다.
일 실시예에서, 예를 들어, SCIM 표준은 SCIM 스펙(specification)에 의해 정의된 유저들 및 그룹 자원들을 관리하기 위해 구현되고, 반면 SCIM++는 SCIM 표준에 의해 정의된 언어를 이용하여 추가 IDCS 내부 자원들 (예를 들어, 패스워드 정책들, 역할들(roles), 설정들(settings), 등)을 지원하도록 구성된다.
운영 서비스는 필요한 곳에 표준 SCIM 2.0 코어 스키마들 및 스키마 익스텐션(extension)들을 갖는 SCIM 2.0 표준 엔드 포인트(endpoint)들을 지원한다. 추가하여, 운영 서비스는 다른 IDCS 자원들, 예를 들어, 유저들, 그룹들, 애플리케이션들, 설정들, 등을 관리하기 위해 몇몇의 SCIM 2.0 순응 엔드 포인트 익스텐션들을 지원한다. 운영 서비스는 또한 CRUDQ 동작들을 수행하지 않고 대신 기능적 서비스, 예를 들어, “UserPasswordGenerator,” “UserPasswordValidator,” 등을 제공하는 RPC-스타일(remote procedure call-style) REST 인터페이스들의 세트를 지원한다.
IDCS 운영 API들은 인증 및 인가를 위해 OAuth2 프로토콜을 사용한다. IDCS는 공통(common) OAuth2 시나리오들 예컨대 웹 서버, 모바일, 및 자바스크립트 애플리케이션들을 위한 시나리오들을 지원한다. IDCS API들에 대한 액세스는 액세스 토큰들에 의해 보호된다. IDCS 운영 API들을 액세스하기 위해, 애플리케이션은 IDCS 운영 콘솔을 통하여 OAuth2 클라이언트 또는 IDCS 애플리케이션 (OAuth2 클라이언트가 자동으로 생성되는 경우에)로서 등록되고 희망하는 IDCS 운영 역할들이 승인되는 것이 필요하다. IDCS 운영 API 호출할 때, 애플리케이션은 IDCS OAuth2 서비스로부터 액세스 토큰을 처음에 요청한다. 토큰을 획득한 후에, 애플리케이션은 HTTP 인증 헤더에 그것을 포함시켜 액세스 토큰을 IDCS API에 발송한다. 애플리케이션들은 IDCS 운영 REST API들을 직접 사용할 수 있거나, 또는 IDCS 자바 클라이언트 API 라이브러리를 사용할 수 있다.
인프라스트럭쳐 서비스들(Infrastructure Services)
IDCS 인프라스트럭처 서비스들은 IDCS 플랫폼 서비스들의 기능을 지원한다. 이들 런타임 서비스(runtime service)들은 이벤트 프로세싱 서비스 (유저 통지들, 애플리케이션 서브스크립션(subscription)들, 및 데이터베이스에 대한 감사(auditing)를 비동기식으로 프로세싱); 잡 스케줄러(job scheduler) 서비스 (잡들 스케줄링 및 실행, 예를 들어, 유저 개입을 필요로 하지 않는 롱-러닝(long-running) 태스크들을 즉각적으로 또는 구성 시간(configuration time)에 실행하기); 캐시 관리 서비스; 스토리지 관리 서비스 (퍼블릭 클라우드 스토리지 서비스와 통합하기 위한); 레포트 서비스 (레포트(report)들 및 대시보드(dashboard)들을 생성하기 위해); SSO 서비스 (내부 유저 인증 및 SSO를 관리하기 위해); 유저 인터페이스 (“UI”) 서비스 (상이한 유형들의 UI 클라이언트들을 호스팅하기 위해); 및 서비스 관리기 서비스를 포함한다. 서비스 관리기는 Oracle 퍼블릭 클라우드와 IDCS 사이의 내부 인터페이스이다. 서비스 관리기는 Oracle 퍼블릭 클라우드에 의해 발행된 커맨드(command)들을 관리하고, 여기서 커맨드들은 IDCS에 의해 구현되는 것이 요구된다. 예를 들어, 고객이 그들이 무엇인가를 구매할 수 있기 전에 클라우드 저장소(cloud store)내 계정에 사인 업할 때, 클라우드는 테넌트(tenant)를 생성할지를 묻는 요청을 IDCS에 발송한다. 이 경우에, 서비스 관리기는 클라우드가 IDCS를 지원할 것을 기대하는 클라우드 특정 동작들을 구현한다.
IDCS 마이크로서비스는 네트워크 인터페이스 (즉, HTTP 요청)을 통하여 다른 IDCS 마이크로서비스를 호출할 수 있다.
일 실시예에서, IDCS는 데이터베이스 스키마를 이용하는 것을 허용하는 스키마 서비스 (또는 영구 서비스(persistence service))를 또한 제공할 수 있다. 스키마 서비스는 데이터베이스 스키마들을 관리하는 책임을 IDCS에 위임하는 것을 허용한다. 따라서, IDCS의 유저는 해당 기능을 제공하는 IDCS 서비스가 있기 때문에 데이터베이스를 관리할 필요가 없다. 예를 들어, 유저는 각 테넌트 베이시스상에 스키마들을 지속하기 위해 데이터베이스를 사용할 수 있고, 데이터베이스에 더 이상 스페이스(space)가 없을 때, 스키마 서비스는 유저들이 데이터베이스 그 자체를 관리할 필요가 없도록 다른 데이터베이스를 획득하고 스페이스를 늘리는 기능을 관리할 것이다.
IDCS는 아이덴티티 저장소 (618) (유저들, 그룹들, 등을 저장하는), 글로벌 데이터베이스(global database) (620) (그 자체를 구성하기 위해 IDCS에 의해 사용되는 구성 데이터를 저장), 동작 스키마(operational schema) (622) (각 테넌트 스키마 분리를 제공하고 각 고객 베이시스상에 고객 데이터를 저장하는), 감사 스키마 (624) (감사 데이터를 저장하는), 캐싱 클러스터 (626) (성능 속도를 높이기 위해서 캐시 오브젝트(cached object)들을 저장), 등을 포함하여 IDCS에 의해 요구되고/생성된 데이터 리포지터리(repository)들인 데이터 저장소들을 더 포함한다. 모든 내부 및 외부 IDCS 소비자들은 표준들 기반의 프로토콜들을 통하여 아이덴티티 서비스들과 통합한다. 이것은 DNS(domain name system)의 사용으로 요청들을 라우팅할 곳을 분해하는 것을 가능하게 하고, 애플리케이션들 소비하는 것을 아이덴티티 서비스들의 내부 구현예의 이해와 디커플링(decouple) 시킨다.
실시간 및 근-실시간 태스크들 (Real-Time and Near-Real-Time Tasks)
IDCS는 요청된 서비스의 태스크들을 동기식 실시간 및 비동기식 근-실시간 태스크들로 분리하고, 여기서 실시간 태스크들은 유저가 진행하는 것이 요구되는 동작들만을 포함한다. 일 실시예에서, 실시간 태스크는 최소 지연으로 수행되는 태스크이고, 근-실시간 태스크는 유저가 그것을 위해 대기할 필요 없이 백그라운드(background)에서 수행되는 태스크이다. 일 실시예에서, 실시간 태스크는 실질적으로 지연 없이 또는 무시가능한 지연으로 수행되는 태스크이고, 유저에게 거의 순간적으로 수행되는 것처럼 보인다.
실시간 태스크들은 특정 아이덴티티 서비스의 메인 비즈니스 기능을 수행한다. 예를 들어, 로그인 서비스를 요청할 때, 애플리케이션은 유저 자격들을 인증하기 위한 메시지를 발송하고 세션 쿠키(session cookie)를 리턴하여 받는다. 유저가 경험하는 것은 시스템에 로깅하는 것이다. 그러나, 몇몇의 다른 태스크들은 유저의 로그 인과 관련하여, 예컨대 유저가 누구인지를 확인, 통지들 감사, 발송, 등이 수행될 수 있다. 따라서, 자격들을 확인하는 것(validating)은 유저가 세션을 시작하기 위해 HTTP 쿠키를 받도록 실시간으로 수행되는 태스크이지만, 그러나 통지들 (예를 들어, 계정의 생성을 통지하기 위해 이메일 발송), 감사들 (예를 들어, 트랙킹/레코딩), 등에 관련된 태스크들은, 유저가 최소 지연으로 진행할 수 있도록 비동기식으로 수행될 수 있는 근-실시간 태스크들이다.
마이크로서비스를 위한 HTTP 요청이 수신된 때, 대응하는 실시간 태스크들은 중간 티어(middle tier)에 마이크로서비스에 의해 수행되고, 나머지 근-실시간 태스크들 예컨대 반드시 실시간 프로세싱을 따를 필요가 없는 동작 로직/이벤트들은 보장된(guaranteed) 전달 및 프로세싱으로 크게 확장가능한(scalable) 비동기식 이벤트 관리 시스템 (630)을 지원하는 메시지 큐들 (628)에 오프로드된다. 따라서, 어떤 행위(behavior)들은 IDCS가 응답 시간들에서 레이턴시(latency)들을 줄임으로써 고객들에 하이 레벨 서비스를 제공하는 것을 가능하게 하기 위해서 프론트 엔드(front end)로부터 백엔드(backend)까지 푸시(push)된다. 예를 들어, 로그인 프로세스는 자격들의 확인, 로그 레포트의 제출(submission), 가장 최근 로그인 시간의 업데이팅, 등을 포함할 수 있지만, 그러나 이들 태스크들은 메시지 큐에 오프로드(offload)될 수 있고 실시간에 반대되는 근-실시간으로 수행딘다.
일 예에서, 시스템은 새로운 유저를 등록하거나 또는 생성할 필요가 있을 수 있다. 시스템은 유저를 생성하기 위해서 IDCS SCIM API를 호출한다. 최종 결과는 유저가 아이덴티티 저장소 (618)에 생성된 때, 유저는 그들의 패스워드를 리셋하는 링크(link)를 포함하는 통지 이메일을 받는다는 것이다. IDCS가 새로운 유저를 등록하거나 생성하기 위한 요청을 수신한 때, 대응하는 마이크로서비스는 동작 데이터베이스 (도 6에 글로벌 데이터베이스 (620)에 위치된)내 구성 데이터를 면밀히 살펴서 “유저 생성(create user)” 동작이 비동기식 동작으로 구성 데이터에 식별된 “유저 생성(create user)” 이벤트로 마킹된 지를 결정한다. 마이크로서비스는 유저의 생성이 성공적으로 수행되었지만, 그러나 통지 이메일의 실제 발송은 연기되고 백엔드로 푸시된다는 것을 표시하고 클라이언트에 리턴한다. 그렇게 하기 위해서, 마이크로서비스는 저장소인 큐 (628)에 메시지를 큐잉(queue)하는 메시징 API (616)를 사용한다.
큐 (628)를 디큐잉(dequeue)하기 위해서, 인프라스트럭처 마이크로서비스인 메시징 마이크로서비스는, 백그라운드에서 지속적으로 실행하고 큐 (628)에서 이벤트들을 찾기 위해서 큐 (628)를 스캔한다. 큐 (628)에 이벤트들은 이벤트 서브스크라이버들 (630) 예컨대 감사, 유저 통지, 애플리케이션 서브스크립션들, 데이터 분석, 등에 의해 프로세스된다. 태스크 이벤트에 의해 표시된 태스크에 의존하여, 이벤트 서브스크라이버들 (630)은 예를 들어, 감사 스키마 (624), 유저 통지 서비스 (634), 아이덴티티 이벤트 서브스크라이버 (632), 등과 통신할 수 있다. 예를 들어, 메시징 마이크로서비스가 큐 (628)에서 “유저 생성” 이벤트를 찾은 때, 그것은 대응하는 통지 로직을 실행하고 대응하는 이메일을 유저에게 발송한다.
일 실시예에서, 큐 (628)는 마이크로서비스들 (614)에 의해 공표된(published) 동작 이벤트들 뿐만 아니라 IDCS 자원들을 관리하는 API들 (616)에 의해 공표된 자원 이벤트들을 큐잉(queue)한다.
IDCS는 시스템 성능 및 유저 경험을 증강시키기 위해서 실시간 캐싱 구조를 사용한다. 캐시 그 자체는 마이크로서비스로서 또한 제공될 수 있다. IDCS는 IDCS에 의해 지원되는 고객들의 수가 증가할 때 커지는 탄성(elastic) 캐시 클러스터 (626)를 구현한다. 캐시 클러스터 (626)는 아래에 보다 상세하게 개시되는 분산된 데이터 그리드(distributed data grid)로 구현될 수 있다. 일 실시예에서, 기록만을 위한(write-only) 자원들은 캐시를 바이패스(bypass)한다.
일 실시예에서, IDCS 런타임 컴포넌트들은 퍼블릭 클라우드 예컨대 Oracle Corp로부터의 Oracle 퍼블릭 클라우드의 이런 메트릭들을 수집하는 퍼블릭 클라우드 모니터링 모듈 (636)에 헬스(health) 및 동작 메트릭들을 공표한다(publish).
일 실시예에서, IDCS는 유저를 생성하기 위해 사용될 수 있다. 예를 들어, 클라이언트 애플리케이션 (602)은 유저를 생성하기 위해 REST API 호출을 발행할 수 있다. Admin 서비스 ((614)에 플랫폼 서비스)는 유저 관리기 ((614)에 인프라스트럭처 라이브러리/서비스)에 호출을 위임하고, 이는 결국 ID 저장소 (618)내 테넌트-특정 ID 저장소 스트라이프(store stripe)에 유저를 생성한다. “유저 생성 성공(User Create Success)”시에, 유저 관리기는 감사 스키마 (624)내 감사 테이블에 대한 동작을 감사하고, 메시지 큐 (628)에 “identity.user.create.success” 이벤트를 공표한다. 아이덴티티 서브스크라이버(subscriber) (632)는 이벤트를 픽업(pick up) 하고 새롭게 생성된 로그인 세부사항들을 포함하는 “환영(Welcome)” 이메일을 새롭게 생성된 유저에게 발송한다.
일 실시예에서, IDCS는 유저에게 역할을 승인하기 위해서 사용될 수 있고 유저 프로비저닝 액션(user provisioning action)으로 귀결된다. 예를 들어, 클라이언트 애플리케이션 (602)은 유저 역할을 승인하기 위해 REST API 호출을 발행할 수 있다. Admin 서비스 ((614)에 플랫폼 서비스)는 역할 관리기(role manager) ((614)에 인프라스트럭처 라이브러리/서비스)에 호출을 위임하고, 이는 ID 저장소 (618)내 테넌트-특정 ID 저장소 스트라이프에 유저 역할을 승인한다. “역할 승인 성공(Role Grant Success)”시에, 역할 관리기는 감사 스키마 (624)내 감사 테이블에 대한 동작들을 감사하고, 메시지 큐 (628)에 “identity.user.role.grant.success” 이벤트를 공표한다. 아이덴티티 서브스크라이버 (632)는 이벤트를 픽업 하고 프로비저닝 승인 정책을 평가한다. 만약 승인된 역할상에 활성(active) 애플리케이션 승인이 있다면, 프로비저닝 서브스크라이버는 일부 확인을 수행하고, 계정 생성을 개시하고, 타겟 시스템을 호출하고, 타겟 시스템상에 계정을 생성하고, 및 성공한 때 계정 생성을 마킹한다. 각각의 이들 기능들은 대응하는 이벤트들, 예컨대 “prov.account.create.initiate”, “prov.target.create.initiate”, “prov.target.create.success”, 또는 “prov.account.create.success”의 공표로 귀결될 수 있다. 이들 이벤트들은 최종 N 날(day)들에 걸쳐 타겟 시스템에 생성된 계정들의 수를 종합한 그들 자체의 비즈니스 메트릭(business metric)들을 가질 수 있다.
일 실시예에서, IDCS는 유저가 로그 인하는데 사용될 수 있다. 예를 들어, 클라이언트 애플리케이션 (602)은 유저가 로그인을 요청하기 위한 지원 인증 플로우(supported authentication flow) 중 하나를 사용할 수 있다. IDCS는 유저를 인증하고, 성공시에, 감사 스키마(audit schema) (624)내 감사 테이블에 대한 동작을 감사한다. 고장(failure)시에, IDCS는 감사 스키마(audit schema) (624)내 고장을 감사하고, 메시지 큐 (628)에 “login.user.login.failure” 이벤트를 공표한다. 로그인 서브스크라이버는 이벤트를 픽업하고, 유저에 대한 그것의 메트릭들을 업데이트하고, 유저의 액세스 이력상에 추가 분석이 수행될 필요가 있는지를 결정한다.
따라서, “제어의 인버전(inversion of control)” 기능 (예를 들어, 동작이 다른 시스템의 제어하에 있도록 나중에 동작의 실행을 스케줄링하기 위해 실행 플로우(flow of execution)를 바꾸는 것)을 구현함으로써, 실시예들은 추가 이벤트 큐들 및 서브스크라이버들이 더 넓은 유저 베이스(user base)로 배치 전에 작은 유저 샘플상에서 새로운 피처들을 테스트 하거나, 또는 특정 내부 또는 외부 고객들에 대한 특정 이벤트들을 프로세스하기 위해 동적으로 추가되는 것을 가능하게 한다.
스테이트리스 기능 (Stateless Functionality)
마이크로서비스들 자체들이 스테이트를 유지하지 않는 것을 의미하는 것이 IDCS 마이크로서비스들이 스테이트리스(stateless)이다. “스테이트(state)”는 그것의 성능들(capability)을 수행하기 위해 애플리케이션이 사용하는 데이터를 지칭한다. IDCS는 IDCS 데이터 티어내 테넌트 특정 리포지터리들로 모든 스테이트를 지속시킴으로써 멀티-테넌트 기능을 제공한다. 중간 티어 (즉, 요청들을 프로세스하는 코드)는 애플리케이션 코드와 동일한 위치에 저장되는 데이터를 가지지 않는다. 따라서, IDCS는 수평으로(horizontally) 및 수직으로(vertically) 더 확장가능하다.
수직으로 (또는 스케일 업/다운) 확장하는 것은 시스템 내 단일 노드에 자원들을 추가하는 것(또는 단일 노드에서 자원들을 제거하는 것)을 의미하고, 전형적으로 단일 컴퓨터에 CPU들 또는 메모리 추가하는 것을 수반한다. 수직 확장(vertical scalability)은 애플리케이션이 그것의 하드웨어의 한계들까지 스케일 업 하는 것을 허용한다. 수평으로 (또는 스케일 아웃/인) 확장하는 것은 더 많은 노드들을 시스템에 추가하는 것(또는 시스템에서 노드들을 제거하는 것), 예컨대 새로운 컴퓨터를 분산된 소프트웨어 애플리케이션에 추가하는 것을 의미한다. 수평 확장(horizontal scalability)은 애플리케이션이 거의 무한정으로 확장하는 것을 허용하고, 네트워크에 의해 제공된 대역폭의 양에 의해서만 경계지어진다.
IDCS의 중간 티어의 스테이트리스니스(stateless-ness)는 특정한 애플리케이션이 운용되고 있는 지정된 물리적 인프라스트럭처를 가질 필요가 없는 애플리케이션의 작업(work)을 수행하는 더 많은 CPU들, 및 IDCS 컴포넌트들을 단지 추가함으로써 수평으로 그것을 확장가능하게 한다. IDCS 중간 티어의 스테이트리스니스는 심지어 아이덴티티 서비스들을 매우 큰 수의 고객들/테넌트들에 제공할 때로 IDCS를 더 많이 이용 가능하게 한다. IDCS 애플리케이션/서비스를 통과하는 각각의 패스(pass)는 애플리케이션 트랜잭션(application transaction) 그 자체를 수행하기 위해서만 CPU 사용에 집속되지만 그러나 데이터를 저장하기 위해 하드웨어를 이용하지 않는다. 확장(scaling)은 애플리케이션이 운용되고 있을 때 더 많은 슬라이스(slice)들을 추가함으로써 성취되고, 한편 트랜잭션을 위한 데이터는 필요한 때 더 많은 복제품들이 추가될 수 있는 영구 계층(persistence layer)에 저장된다.
IDCS 웹 티어(web tier), 중간 티어(middle tier), 및 데이터 티어(data tier)는 독립적으로 그리고 따로 따로 각각 확장할 수 있다. 웹 티어는 더 많은 HTTP 요청들을 핸들링하기 위해 확장될 수 있다. 중간 티어는 더 많은 서비스 기능을 지원하기 위해 확장될 수 있다. 데이터 티어는 더 많은 테넌트들을 지원하기 위해 확장될 수 있다.
IDCS 기능 뷰(IDCS Functional View)
도 6a는 일 실시예의 IDCS의 기능 뷰의 예시 블럭 다이어그램(600b)이다. 블럭 다이어그램 (600b)에서, IDCS 기능 스택(functional stack)은 서비스들, 공유된 라이브러리들, 및 데이터 저장소들을 포함한다. 서비스들은 IDCS 플랫폼 서비스들 (640b), IDCS 프리미엄 서비스들 (650b), 및 IDCS 인프라스트럭처 서비스들 (662b)를 포함한다. 일 실시예에서, IDCS 플랫폼 서비스들 (640b) 및 IDCS 프리미엄 서비스들 (650b)은 IDCS의 비즈니스를 구현하는 자바기반의 런타임 서비스들에 별개로 배치되고, IDCS 인프라스트럭처 서비스들 (662b)은 IDCS에 인프라스트럭처 지원 제공하는 런타임 서비스들에 별개로 배치된다. 공유 라이브러리들은 IDCS 서비스들 및 공유 라이브러리들에 의해 사용되는 공유 라이브러리들로서 패키지된 공통 코드인 IDCS 인프라스트럭처 라이브러리들 (680b)을 포함한다. 데이터 저장소들은 아이덴티티 저장소 (698b), 글로벌 구성(global configuration) (700b), 메시지 저장소 (702b), 글로벌 테넌트(global tenant) (704b), 개인화 설정들(personalization setting) (706b), 자원들 (708b), 유저 트랜젼트 데이터(transient data) (710b), 시스템 트랜젼트 데이터 (712b), 각 테넌트(per-tenant) 스키마들 (관리된 ExaData) (714b), 오퍼레이션 저장소(operational store) (미도시), 캐싱 저장소(caching store) (미도시), 등을 포함하는 IDCS에 의해 요구된/생성된 데이터 리포지터리(repository)들이다.
일 실시예에서, IDCS 플랫폼 서비스들 (640b)는 예를 들어, OpenID Connect 서비스 (642b), OAuth2 서비스 (644b), SAML2 서비스 (646b), 및 SCIM++ 서비스 (648b)를 포함한다. 일 실시예에서, IDCS 프리미엄 서비스들은 예를 들어, 클라우드 SSO 및 거버넌스(governance) (652b), 기업 거버넌스 (654b), AuthN 브로커(broker) (656b), 연합 브로커(Federation broker) (658b), 및 개인 계정 관리 (660b)를 포함한다.
IDCS 인프라스트럭처 서비스들 (662b) 및 IDCS 인프라스트럭처 라이브러리들 (680b)은 그것들의 작업을 수행하기 위해 IDCS 플랫폼 서비스들 (640b)에 의해 요구된 성능들 지원을 제공한다. 일 실시예에서, IDCS 인프라스트럭처 서비스들 (662b)은 잡 스케줄러(job scheduler) (664b), UI (666b), SSO (668b), 레포트(report)들 (670b), 캐시 (672b), 스토리지 (674b), 서비스 관리기 (676b) (퍼블릭 클라우드 제어), 및 이벤트 프로세서 (678b) (유저 통지들, 앱 서브스크립션, 감사, 데이터 분석)을 포함한다. 일 실시예에서, IDCS 인프라스트럭처 라이브러리들 (680b)은 데이터 관리기 API들 (682b), 이벤트 API들 (684b), 스토리지 API들 (686b), 인증 API들 (688b), 인증 API들 (690b), 쿠키 API들 (692b), 키들 API들 (694b), 및 자격들 API들 (696b)을 포함한다. 일 실시예에서, 클라우드 컴퓨트 서비스 (602b) (내부 Nimbula)는 IDCS 인프라스트럭처 서비스들 (662b) 및 IDCS 인프라스트럭처 라이브러리들 (680b)의 기능을 지원한다.
일 실시예에서, IDCS는 IDCS 서비스들의 소비자에게 다양한 UI들 (602b)을, 예컨대 고객 엔드 유저 UI (604b), 고객 admin UI (606b), DevOps admin UI (608b), 및 로그인 UI (610b)를 제공한다. 일 실시예에서, IDCS는 애플리케이션들의 통합(612b) (예를 들어, 고객 앱 (614b), 파트너 앱 (616b), 및 클라우드 앱 (618b)) 및 펌웨어 통합 (620b)을 허용한다. 일 실시예에서, 다양한 환경들은 그것들의 액세스 제어 요구들을 지원하기 위해서 IDCS와 통합할 수 있다. 이런 통합은 예를 들어, 아이덴티티 브리지 (622b) (AD 통합, WNA, 및 SCIM 커넥터를 제공), Apache 에이전트(agent) (624b), 또는 MSFT 에이전트(626b)에 의해 제공될 수 있다.
일 실시예에서, 내부 및 외부 IDCS 소비자들은 표준들 기반 프로토콜들 (628b)상에 IDCS의 아이덴티티 서비스들, 예컨대 OpenID Connect (630b), OAuth2 (632b), SAML2 (634b), SCIM (636b), 및 REST/HTTP (638b)와 통합한다. 이것은 DNS(domain name system)의 사용으로 요청들을 라우팅할 곳을 분해하는 것을 가능하게 하고, 애플리케이션들 소비하는 것을 아이덴티티 서비스들의 내부 구현예의 이해와 디커플링시킨다.
*도 6a에 IDCS 기능 뷰는 IDCS가 유저 통지들 (클라우드 통지 서비스 (718b)), 파일 스토리지 (클라우드 스토리지 서비스 (716b))에 의존하는 공통 기능을 제공하는 퍼블릭 클라우드 인프라스트럭처 서비스들, 및 DevOps (클라우드 모니터링 서비스 (EM) (722b) 및 클라우드 메트릭들 서비스 (그래파이트(Graphite)) (720b))를 위한 메트릭들/경고(alerting)을 더 포함한다.
클라우드 게이트(Cloud Gate)
일 실시예에서, IDCS는 웹 티어(web tier)내 “클라우드 게이트(Cloud Gate)”를 구현한다. 클라우드 게이트는 기업 IDM 스택들로 작업하는 웹게이트(WebGate) 또는 웹에이전트(WebAgent) 기술들에 유사하게 유저 SSO를 아이덴티티 관리 시스템 (예를 들어, IDCS)에 외부 표면화(externalize)하는 것을 웹 애플리케이션들이 가능하게 하는 웹 서버 플러그인(web server plugin)이다. 클라우드 게이트는 IDCS API들에 대한 액세스를 안전하게 하는 보안 게이트키퍼(security gatekeeper)로서 동작한다. 일 실시예에서, 클라우드 게이트는 OAuth에 기초하여 HTTP 자원들을 보호하기 위해 웹 PEP(Policy Enforcement Point)를 제공하는 웹/프락시 서버 플러그인에 의해 구현된다.
도 7 은 웹 브라우저 및 애플리케이션의 REST API 자원들 (714) 및 웹 브라우저에 대한 액세스를 안전하게 하면서 동시에 오픈 표준들 (예를 들어, OAuth2, OpenID Connect, 등)을 이용하여 IDCS PDP(Policy Decision Point)와 통합하도록 구성된 PEP(Policy Enforcement Point)로서 동작하고 웹 서버 (712)에서 운용하는 클라우드 게이트 (702)를 구현하는 실시예의 블럭 다이어그램(700)이다. 일부 실시예들에서, PDP는 OAuth 및/또는 OpenID Connect 마이크로서비스들 (704)에서 구현된다. 예를 들어, 유저 브라우저 (706)가 유저 (710)의 로그인을 위해 IDCS에 요청(request)를 발송할 때, 대응하는 IDCS PDP는 자격들을 확인하고 그런 다음 자격들이 충분한지 여부 (예를 들어, 추가 자격(credential)들 예컨대 제 2 패스워드를 요청할지 여부)를 결정한다. 도 7의 실시예에서, 클라우드 게이트 (702)는 그것이 로컬 정책을 갖기 때문에 PEP로서 그리고 PDP로서 둘 모두로서 동작할 수 있다.
한번의 배치의 일부로서, 클라우드 게이트 (702)는 OAuth2 클라이언트로서 IDCS에 등록되고, IDCS에 대비하여 그것이 OIDC 및 OAuth2 동작들을 요청하는 것을 가능하게 한다. 그 후에, 그것은 매칭 규칙들(어떻게 URL들에 매칭할 지, 예를 들어, 와일드 카드들(wild cards), 정규 표현들, 등으로) 요청에 대상이 되는 애플리케이션의 보호되고 그리고 보호되지 않는 자원들에 대한 구성 정보를 유지한다. 클라우드 게이트 (702)는 상이한 보안 정책들을 갖는 상이한 애플리케이션들을 보호하도록 배치될 수 있고, 보호된 애플리케이션들은 멀티-테넌트일 수 있다.
웹 브라우저기반의 유저 액세스 동안에, 클라우드 게이트 (702)는 유저 인증 플로우를 개시하는 OIDC RP (718)로서 동작한다. 만약 유저 (710)가 유효한 로컬 유저 세션을 갖지 않으면, 클라우드 게이트 (702)는 유저를 SSO 마이크로서비스로 리다이렉트(re-direct) 시키고 SSO 마이크로서비스로 OIDC “인증 코드” 플로우에 참여한다. 플로우는 아이덴티티 토큰으로서 JWT의 전달을 끝낸다. 클라우드 게이트 (708)는 JWT를 확인하고 (예를 들어, 시그니쳐(signature), 만료(expiration), 목적지(destination)/오디언스(audience), 등을 자세히 살펴서) 유저 (710)에게 로컬 세션 쿠키를 발행한다. 그것은 보호된 자원들에 대한 웹 브라우저 액세스를 안전하게 하고 로컬 세션 쿠키 발행(issuing), 업데이팅(updating) 및 확인(validating)하는 세션 관리기 (716)로서 동작한다. 그것은 또한 그것의 로컬 세션 쿠키의 제거를 위한 로그아웃 URL를 제공한다.
클라우드 게이트 (702)는 또한 IDCS에 대비하여 HTTP Basic Auth 자격들을 확인하는 HTTP Basic Auth 인증기(authenticator)로서 동작한다. 이 행위는 세션이 없는(session-less) 모드 및 세션기반의(session-based) (로컬 세션 쿠키) 모드 양쪽에서 지원된다. 이 경우에 어떠한 서버-측 IDCS 세션도 생성되지 않는다.
REST API 클라이언트들 (708)에 의한 계획에 따른 액세스(programmatic access) 동안에, 클라우드 게이트 (702)는 애플리케이션의 보호된 REST API들 (714)에 대한 OAuth2 자원 서버/필터 (720)로서 역할을 한다. 그것은 인증 헤더 및 액세스 토큰을 갖는 요청의 존재를 체크한다. 클라이언트 (708) (예를 들어, 모바일, 웹 앱, 자바스크립트, 등)가 보호된 REST API (714)와 사용할 액세스 토큰 (IDCS에 의해 발행된)을 제공할 때, 클라우드 게이트 (702)는 API (예를 들어, 시그니쳐, 만료, 오디언스, 등)에 대한 액세스를 허용하기 전에 액세스 토큰을 확인한다. 원래의 액세스 토큰은 변형되지 않은 채 패스된다.
일반적으로, OAuth는 클라이언트 아이덴티티 전파 토큰(propagation token) (예를 들어, 누가 클라이언트인지를 나타내는) 또는 유저 아이덴티티 전파 토큰 (예를 들어, 누가 유저인지를 나타내는) 둘 중 하나를 생성하기 위해 사용된다. 실시예들에서, 클라우드 게이트내 OAuth의 구현은 예를 들어, IETF, RFC 7519에 의해 제공된 웹 토큰들에 대한 포맷을 정의하는 JWT에 기반된다.
유저가 로그 인할 때, JWT가 발행된다. JWT는 IDCS에 의해 사인되고 IDCS에 멀티-테넌트 기능을 지원한다. 클라우드 게이트는 IDCS에 멀티-테넌트 기능을 허용하기 위해 IDCS에 의해 발행된 JWT를 확인한다. 따라서, IDCS는 보안 모델을 보강하는 로직상의 비즈니스 프로세스에 뿐만 아니라 물리적 구조에 멀티-테넌시를 제공한다.
테넌시 유형들 (Tenancy Types)
IDCS는 세개의 유형들의 테넌시들을 : 고객 테넌시(customer tenancy), 클라이언트 테넌시(client tenancy), 및 유저 테넌시(user tenancy)을 특정한다. 고객 또는 자원 테넌시는 누가 IDCS의 고객인지 (즉, 누구를 위해 작업이 수행되고 있는지)를 특정한다. 클라이언트 테넌시는 어느 클라이언트 애플리케이션이 데이터를 액세스 하려고 하는 지를 (즉, 어떤 애플리케이션이 해당 작업을 하고 있는지) 특정한다. 유저 테넌시는 어느 유저가 데이터를 액세스하기 위해 애플리케이션을 사용하고 있는지를 (즉, 누구에 의해 해당 작업이 수행되고 있는지) 특정한다. 예를 들어, 전문 서비스 회사(company)가 웨어하우스 클럽(warehouse club)에 시스템 통합 기능을 제공하고 웨어하우스 클럽 시스템들에 아이덴티티 관리를 제공하기 위해 IDCS를 사용할 때, 유저 테넌시는 전문 서비스 회사에 대응하고, 클라이언트 테넌시는 시스템 통합 기능을 제공하기 위해 사용되는 애플리케이션이고, 고객 테넌시는 웨어하우스 클럽이다.
이들 세개의 테넌시들의 분리 및 식별은 클라우드 기반 서비스에서 멀티-테넌트 기능을 가능하게 한다. 일반적으로, 물리적 기계 온-프레미스상에 인스톨된 온-프레미스 소프트웨어에 대하여, 유저가 로그 인하기 위해 물리적으로 해당 기계상에 있는 것을 요구하기 때문에 세개의 상이한 테넌시들을 특정하는 것이 요구되지 않는다. 그러나, 클라우드기반의 서비스 구조에서, 실시예들은 누가 어떤 애플리케이션을 이용하여 어떤 자원들을 액세스할 것인지를 결정하기 위해서 토큰들을 사용한다. 세개의 테넌시들은 중간 티어에 비즈니스 서비스들에 의해 사용되고 클라우드 게이트(Cloud Gate)에 의해 시행되고, 토큰들에 의해 체계화된다(codify). 일 실시예에서, OAuth 서버가 토큰들을 생성한다. 다양한 실시예들에서, 토큰들은 OAuth 외에 임의의 보안 프로토콜과 함께 사용될 수 있다.
유저, 클라이언트, 및 자원 테넌시들을 디커플링하는 것(decoupling)은 IDCS에 의해 제공된 서비스들의 유저들에게 실질적 비즈니스 장점들을 제공한다. 예를 들어, 그것은 비즈니스 (예를 들어, 헬스케어 비즈니스) 및 그것들의 아이덴티티 관리 문제들의 요구를 이해하는 서비스 제공자가 IDCS에 의해 제공된 서비스들을 구매하고, IDCS의 서비스들을 소비하는 그것들 자체의 백엔드(backend) 애플리케이션을 개발하고, 백엔드 애플리케이션들을 타겟 비즈니스들에 제공하는 것을 허용한다. 따라서, 서비스 제공자는 그들의 희망하는 성능들을 제공하고 어떤 타겟 비즈니스들에 그것들을 공급하기 위해서 IDCS의 서비스들을 확장할 수 있다. 서비스 제공자는 아이덴티티 서비스들을 제공하기 위해서 소프트웨어를 빌드(build)하고 운용할 필요없이 대신 타겟 비즈니스들의 요구들을 만족시키기 위해 IDCS의 서비스들을 맞춤화하고 확장할 수 있다.
일부 알려진 시스템들은 고객 테넌시인 단일 테넌시에 대한 계정만을 설명한다. 그러나, 이런 시스템들은 유저들의 조합 예컨대 고객 유저들, 고객 파트너들, 고객 클라이언트들, 클라이언트들 그 자신들, 또는 고객이 액세스를 위임한 클라이언트들에 의한 액세스를 다룰 때 부적절하다. 실시예들에서 다수의 테넌시들을 정의하고 실행하는 것은 이런 다양한 유저들에 대하여 아이덴티티 관리 기능을 가능하게 한다.
일 실시예에서, IDCS의 하나의 엔티티(entity)는 동시에 다수의 테넌트들에 속하지 않고; 그것은 단지 하나의 테넌트에 속하고, 및 “테넌시(tenancy)”는 아티팩트(artifact)들이 살아있는 곳이다. 일반적으로, 어떤 기능들을 구현하는 다수의 컴포넌트들이 있고, 이들 컴포넌트들은 테넌트들에 속할 수 있거나 또는 그것들은 인프라스트럭처에 속할 수 있다. 인프라스트럭처가 테넌트들을 대신하여 동작할 필요가 있을 때, 그것은 테넌트을 대신하여 엔티티 서비스와 상호 작용한다. 그 경우에, 인프라스트럭처 그 자체는 그 자체의 테넌시를 갖고 고객은 그 자체의 테넌시를 갖는다. 요청이 제출된 때, 요청에 포함된 다수의 테넌시들이 있을 수 있다.
예를 들어, “테넌트 1”에 속하는 클라이언트는 “테넌트 2”를 대한 토큰을 획득하는 요청을 실행할 수 있고 유저를 “테넌트 3”에 특정한다. 다른 예로서, “테넌트 1”에 살아있는 유저는 “테넌트 2”에 의해 소유된 애플리케이션에서 동작을 수행할 필요가 있을 수 있다. 따라서, 유저는 “테넌트 2”의 자원 이름공간(namespace)으로 가서 그 자신들을 위한 토큰을 요청하는 것을 필요로 한다. 따라서, 권한의 위임(delegation of authority)은 “누가(who)” can do “누구에게(whom)” “무엇을(what)” 할 수 있는 지를 식별함으로써 성취된다. 또 다른 예로서, 제 1 단체 (“테넌트 1”)를 위해 작업하는 제 1 유저는 제 2 단체 (“테넌트 2”)를 위해 작업하는 제 2 유저가 제 3 단체 (“테넌트 3”)에 의해 호스트되는 문서에 대한 액세스를 갖는 것을 허용할 수 있다.
일 예에서, “테넌트 1”내 클라이언트는 “테넌트 3”내 애플리케이션을 액세스하기 위해 “테넌트 2”내 유저를 위한 액세스 토큰을 요청할 수 있다. 클라이언트는 “http://tenant3/oauth/token”으로 가서 토큰을 위한 OAuth 요청을 인보크(invoke)함으로써 그렇게 할 수 있다. 클라이언트는 요청에 “클라이언트 어써션(client assertion)”을 포함함으로써 “테넌트 1”에 살아있는 클라이언트로서 그 자체를 식별한다. 클라이언트 어써션은 클라이언트 ID (예를 들어, “클라이언트 1”) 및 클라이언트 테넌시 “테넌트 1”를 포함한다. “테넌트 1”내 “클라이언트 1”으로서, 클라이언트는 “테넌트 3”상에 토큰을 위한 요청을 인보크할 권리를 가지며, 클라이언트는 “테넌트 2”내 유저를 위한 토큰을 원한다. 따라서, “유저 어써션”은 또한 유저의 테넌시로서 “테넌트 2”를 식별하기 위해 동일한 HTTP 요청의 부분으로 패스되고, 요청의 헤더는 자원/애플리케이션의 테넌시로서 “테넌트 3”를 식별한다. 결과적으로, 요청은 클라이언트의 테넌시, 유저의 테넌시, 및 자원의 테넌시를 식별한다. 생성된 액세스 토큰은 애플리케이션 테넌시 (“테넌트 3”)인 타겟 테넌시의 컨텍스트(context)에서 발행될 것이고 유저 테넌시 (“테넌트 2”)를 포함할 것이다. 따라서, 액세스 토큰은 자원/애플리케이션의 테넌시 및 유저의 테넌시를 식별한다.
일 실시예에서, 데이터 티어에, 각각의 테넌트는 별개의 스트라이프(stripe)로서 구현된다. 데이터 관리 관점에서, 아티팩트들은 테넌트에 산다. 서비스 관점에서, 서비스는 어떻게 상이한 테넌트들과 작업할 지를 알고, 다수의 테넌시들은 서비스의 비즈니스 기능에서 상이한 디멘젼(dimension)들이다. 도 8 은 일 실시예에서 다수의 테넌시들을 구현하는 예제 시스템(800)을 예시한다. 시스템 (800)은 데이터베이스 (806)내 데이터와 어떻게 작업할 지를 이해하는 마이크로서비스 (804)에 의해 제공된 서비스를 요청하는 클라이언트 (802)를 포함한다. 데이터베이스 (806)는 다수의 테넌트들 (808)을 포함하고 각각의 테넌트는 대응하는 테넌시의 아티팩트(artifact)들을 포함한다. 일 실시예에서, 마이크로서비스 (804)는 “테넌트 3”에 애플리케이션을 액세스하기 위해서 “테넌트 2”내 유저를 위한 토큰을 얻기 위해서 “테넌트 1”내 클라이언트에 의해 https://tenant3/oauth/token 를 통하여 요청된 OAuth 마이크로서비스이고, 데이터베이스 (806)는 클라이언트 (“테넌트 1”)의 테넌시, 유저 (“테넌트 2”)의 테넌시, 및 자원/애플리케이션 (“테넌트 3”)의 테넌시의 데이터를 저장한다. OAuth 마이크로서비스의 기능은 클라이언트 (802)의 요청이 적법한지(legitimate)를 확인하기 위해서 데이터베이스 (806)로부터의 데이터를 이용하여 마이크로서비스 (804)에서 수행되고, 만약 그것이 적법하면, 토큰을 구성하기 위해 상이한 테넌시들(808)로부터의 데이터를 이용한다. 따라서, 시스템 (800)은 각각의 테넌시로 가는 서비스들을 지원할 뿐만 아니라, 또한 상이한 테넌트들을 대신하여 활동할 수 있는 서비스들을 지원함으로써 그것이 교차-테넌트 환경에서 작업할 수 있는 멀티-테넌트(multi-tenant)이다.
시스템 (800)은 클라이언트에 더 근접한 위치들에 걸쳐서 데이터를 복제함으로써 그리고 데이터베이스 (806)내 데이터로부터 마이크로서비스 (804)가 물리적으로 디커플링되기 때문에 유익하고, 마이크로서비스 (804)는 클라이언트들에 대한 로컬 서비스로서 제공될 수 있고 시스템 (800)은 서비스 의 이용 가능성을 관리할 수 있고 그것을 글로벌하게(globally) 제공한다.
일 실시예에서, 마이크로서비스 (804)는 마이크로서비스 (804)를 운용하는 기계가 임의의 특정 테넌트들에 대한 서비스를 가리키는 임의의 마커(marker)들을 유지하지 않는다는 것을 의미하는 스테이트리스(stateless)이다. 대신에, 테넌시는 예를 들어, 들어오는 요청의 URL의 호스트 부분상에 마킹될 수 있다. 해당 테넌시는 데이터베이스 (806)내 테넌트들 (808) 중 하나를 가리킨다. 큰 수의 테넌트들 (예를 들어, 수백만개 테넌트들)을 지원할 때, 마이크로서비스 (804)는 데이터베이스 (806)에 대한 동일한 수의 연결들을 가지지 않고, 대신 데이터베이스 유저의 컨텍스트하에서 데이터베이스 (806)에 실제 물리적 연결들을 제공하는 연결 풀 (810)을 사용한다.
일반적으로, 연결들은 특정 데이터베이스 또는 서버에 어드레스를 지정(address)하기 위해 인스턴스 및 유저 인증 자격들을 제공하기 위해 사용되는 연결 스트링으로 기저(underlying) 드라이버 또는 제공자를 공급함으로써 빌드된다 (예를 들어, “Server=sql_box;Database=Common;User ID=uid;Pwd=password;”). 일단 연결이 빌드된 후에, 그것은 개방 및 폐쇄될 수 있고, 특성들 (예를 들어, 만약 하나가 존재하면 커맨드 타임-아웃 길이(time-out length), 또는 트랜잭션(transaction))이 설정될 수 있다. 연결 스트링은 데이터 제공자의 데이터 액세스 인터페이스에 의해 지시된 키-값 쌍들의 세트를 포함한다. 연결 풀(connection pool)은 데이터베이스에 대한 향후 요청들이 요구된 때 연결들이 재사용될 수 있도록 유지된 데이터베이스 연결들의 캐시이다. 연결 풀링(connection pooling)에서, 연결이 생성된 후에, 그것은 풀 내에 배치되고 그것은 새로운 연결이 수립될 필요가 없도록 다시 사용된다. 예를 들어, 마이크로서비스 (804)와 데이터베이스 (808) 사이에 열 개의 연결들이 요구될 때, 데이터베이스 유저의 모든 컨텍스트하에서 연결 풀 (810)에 열 개의 오픈 연결들이 있을 것이다 (예를 들어, 특정 데이터베이스 유저와 관련하여, 예를 들어, 누가 해당 연결의 소유자인지, 그의 자격들이 유효한지, 데이터베이스 유저인지, 시스템 자격(system credential)인지, 등).
연결 풀 (810)내 연결들은 어떤 것을 액세스 할 수 있는 시스템 유저에 대하여 생성된다. 따라서, 테넌트를 대신하여 요청들을 프로세싱하는 마이크로서비스 (804)에 의한 감사 및 특권(privilege)들을 정확하게 핸들링하기 위해서, 데이터베이스 동작은 특정 테넌트에 할당된 스키마 소유자(schema owner)와 관련된 "프락시 유저(proxy user)" (812)의 컨텍스트하에서 수행된다. 이 스키마 소유자는 스키마가 생성된 테넌시만을 액세스를 할 수 있고, 테넌시의 값은 스키마 소유자의 값이다. 요청이 데이터베이스 (806)내 데이터에 대하여 만들어진 때, 마이크로서비스 (804)는 해당 데이터를 제공하기 위해 연결 풀 (810) 내 연결들을 사용한다. 따라서, 멀티-테넌시는 자원 테넌시와 관련된 데이터 저장소 프락시 유저(예를 들어, 와 관련하여)의 컨텍스트하에서 생성된 데이터 연결의 최상부(top)상에 각 요청 베이시스(basis) 위에 수립된 테넌트-특정 데이터 저장소 바인딩(binding) (예를 들어, 와 관련하여) 의 컨텍스트하에서 착신 요청들을 프로세싱하는 스테이트리스, 탄성의(elastic) 중간 티어 서비스들을 가짐으로써 달성되고, 데이터베이스는 서비스들과 독립적으로 확장 할 수 있다.
이하는 프락시 유저 (812)를 구현하기 위한 예시 기능을 제공한다:
dbOperation = <prepare DB command to execute>
dbConnection = getDBConnectionFromPool()
dbConnection.setProxyUser (resourceTenant)
result = dbConnection.executeOperation (dbOperation)
이 기능에서, 마이크로서비스 (804)는 연결 풀 (810)로부터 “테넌트”까지 풀링(pull)된 연결 위에 “프락시 유저” 셋팅(setting)을 설정하고 연결 풀 (810)내 데이터베이스 연결을 사용하는 동안 테넌트의 컨텍스트하에서 데이터베이스 동작을 수행한다.
상이한 테넌트들에 대해 동일한 데이터베이스내 상이한 컬럼들을 구성하기 위해 모든 테이블을 스트라이핑(striping)할 때, 하나의 테이블은 함께 혼합된 모든 테넌트들의 데이터를 포함할 수 있다. 그에 반해서, 일 실시예는 테넌트-드리븐(tenant-driven) 데이터 티어를 제공한다. 실시예는 상이한 테넌트들에 대하여 동일한 데이터베이스를 스트라이프하지 않지만, 그러나 대신 각 테넌트 마다 상이한 물리적 데이터베이스를 제공한다. 예를 들어, 멀티-테넌시(multi-tenancy)는 플러그인 가능한 (pluggable) 데이터베이스를 이용함으로써 구현될 수 있다 (예를 들어, Oracle Corp로부터의 Oracle Database 12c) 여기서, 각각의 테넌트는 별개의 파티션(partition)에 할당된다. 데이터 티어에서, 자원 관리기는 요청을 프로세스하고 그런 다음 요청에 대한 데이터 소스를 찾는다 (메타데이터로부터 분리하다). 실시예는 각 요청마다 개별 데이터 소스/저장소에 대한 런타임 스위치를 수행한다. 각각의 테넌트의 데이터를 다른 테넌트들로부터 격리시킴으로써, 실시예는 개선된 데이터 보안을 제공한다.
일 실시예에서, 다양한 토큰들은 상이한 테넌시들을 체계화한다. URL 토큰은 서비스를 요청하는 애플리케이션의 테넌시를 식별할 수 있다. 아이덴티티 토큰은 인증될 유저의 아이덴티티를 체계화할 수 있다. 액세스 토큰은 다수의 테넌시들을 식별할 수 있다. 예를 들어, 액세스 토큰은 액세스가 주어진 유저의 유저 테넌시 뿐만 아니라 이런 액세스 (예를 들어, 애플리케이션 테넌시)의 타겟인 테넌시를 체계화할 수 있다. 클라이언트 어써션 토큰(client assertion token)은 클라이언트 ID 및 클라이언트 테넌시를 식별할 수 있다. 유저 어써션 토큰(user assertion token)은 유저 및 유저 테넌시를 식별할 수 있다.
일 실시예에서, 아이덴티티 토큰은 적어도 유저 테넌트 이름 (즉, 유저가 사는 곳)를 나타내는 “클레임(claim)” [보안 필드내 통상의 기술자에 의해 사용되는]을 포함한다. 인증 토큰들과 관련된 "클레임"은 하나의 서브젝트(subject)가 그 자체 또는 다른 서브젝트를 구성하는 스테이트먼트(statement)이다. 스테이트먼트는 예를 들어 이름, 아이덴티티, 키, 그룹, 특권(privilege), 또는 성능에 대한 것일 수 있다. 클레임들은 제공자에 의해 발행되고, 그것들은 하나 이상의 값들이 주어지고 그런 다음 통상 STS(security token service)로서 알려진 발행기 (issuer)에 의해 발행되는 보안 토큰들로 패키징된다.
일 실시예에서, 액세스 토큰은 적어도 액세스 토큰을 위한 요청이 만들어진 시간에 자원 테넌트 이름을 나타내는 클레임/스테이트먼트 (예를 들어, 고객), 유저 테넌트 이름을 나타내는 클레임/스테이트먼트, 요청을 만드는 OAuth 클라이언트의 이름을 나타내는 클레임, 및 클라이언트 테넌트 이름을 나타내는 클레임/스테이트먼트를 포함한다. 일 실시예에서, 액세스 토큰은 이하의 JSON 기능에 따라 구현될 수 있다:
{
…
" tok_type " : "AT",
"user_id" : "testuser",
"user_tenantname" : "<value-of-identity-tenant>"
“tenant” : “<value-of-resource-tenant>
“client_id” : “testclient”,
“client_tenantname”: “<value-of-client-tenant>”
…
}
일 실시예에서, 클라이언트 어써션 토큰은 적어도 클라이언트 테넌트 이름을 나타내는 클레임/스테이트먼트(claim/statement), 및 요청을 만드는 OAuth 클라이언트의 이름을 나타내는 클레임/스테이트먼트를 포함한다.
본 출원에서 설명된 토큰들 및/또는 다수의 테넌시들은 IDCS외에 임의의 멀티-테넌트 클라우드기반의 서비스에 구현될 수 있다. 예를 들어, 본 출원에서 설명된 토큰들 및/또는 다수의 테넌시들은 SaaS 또는 ERP(Enterprise Resource Planning) 서비스들에 구현될 수 있다.
도 9는 일 실시예의 IDCS의 네트워크 뷰(900)의 블럭 다이어그램이다. 도 9 는 애플리케이션 “존들” (904) 사이의 일 실시예들에서 수행되는 네트워크 상호작용들을 예시한다. 애플리케이션들은 다양한 다른 시스템들에 대한 연결들의 구현 및 요구된 보호 레벨에 기초하여 존들 (예를 들어, SSL 존, 노(no) SSL 존, 등)로 쪼개진다. 일부 애플리케이션 존들은 IDCS의 내부로부터의 액세스를 요구하는 서비스들을 제공하고, 반면 일부 애플리케이션 존들은 IDCS의 외부로부터의 액세스를 요구하는 서비스들을 제공하고, 및 일부는 오픈 액세스이다. 따라서, 개별 보호의 레벨이 각각의 존에 대하여 시행된다.
도 9의 실시예에서, 서비스 통신에 대한 서비스는 HTTP 요청들을 이용하여 수행된다. 일 실시예에서, IDCS는 서비스들을 제공하는 것 뿐만 아니라 또한 IDCS 그 자체 내에 및 거기에 대한 액세스를 안전하게 하기 위해 본 출원에서 설명된 액세스 토큰들을 사용한다. 일 실시예에서, IDCS 마이크로서비스들은 RESTful 인터페이스들을 통하여 노출되고 본 출원에서 설명된 토큰들에 의해 안전하게 보안된다.
도 9의 실시예에서, 여러 가지 애플리케이션들/서비스들 (902) 중 임의의 하나는 IDCS 서비스들을 사용하기 위해서 IDCS API들에 HTTP 호출들을 할 수 있다. 일 실시예에서, 애플리케이션들/서비스들 (902)의 HTTP 요청들은 Oracle 퍼블릭 클라우드 로드 분산 외부 VIP(Virtual IP address) (906) (또는 다른 유사한 기술들), 퍼블릭 클라우드 웹 라우팅 티어 (908), 및 IDCS 로드 분산 내부 VIP 기기 (910) (또는 다른 유사한 기술들)를 통과하여, IDCS 웹 라우팅 티어 (912)에 의해 수신될 것이다. IDCS 웹 라우팅 티어 (912)는 IDCS의 외부로부터 또는 그 내부로부터 오는 요청들을 수신하고 IDCS 플랫폼 서비스들 티어 (914) 또는 IDCS 인프라스트럭처 서비스들 티어 (916)을 거쳐 그것들을 라우팅한다. IDCS 플랫폼 서비스들 티어 (914)는 IDCS의 외부로부터 인보크되는 IDCS 마이크로서비스들, 예컨대 OpenID Connect, OAuth, SAML, SCIM, 등을 포함한다. IDCS 인프라스트럭처 서비스들 티어 (916)는 다른 IDCS 마이크로서비스들의 기능을 지원하기 위해 IDCS의 내부로부터 인보크되는 마이크로서비스들을 지원하는 단계를 포함한다. IDCS 인프라스트럭처 마이크로서비스들의 예들은 UI, SSO, 레포트들, 캐시, 잡 스케줄러, 서비스 관리기, 키들을 만드는 기능, 등이다. IDCS 캐시 티어 (926)는 IDCS 플랫폼 서비스들 티어 (914) 및 IDCS 인프라스트럭처 서비스들 티어 (916)를 위한 캐싱 기능(caching functionality)을 지원한다.
IDCS 내부 및 IDCS에 대한 외부 액세스 양쪽에 대한 보안을 시행함으로써, IDCS의 고객들은 그들이 운용하는 애플리케이션들을 위한 우수한 보안 준수를 제공받을 수 있다.
도 9의 실시예에서, 외에 SQL(Structured Query Language)에 기초하여 통신하는 데이터 티어 (918) 및 LDAP에 기초하여 통신하는 ID 저장소 티어 (920)외에, OAuth 프로토콜은 IDCS 내 IDCS 컴포넌트들 (예를 들어, 마이크로서비스들) 간에 통신을 보호하기 위해 사용되고, 및 IDCS의 외부로부터 액세스를 안전하게 하기 위해 사용되는 동일한 토큰들이 IDCS 내부 보안을 위해 사용된다. 즉, 웹 라우팅 티어 (912)는 요청이 IDCS의 외부로부터 또는 IDCS의 내부로부터 수신되는지 여부에 상관없이 그것이 수신하는 요청들을 프로세싱하기 위해 동일한 토큰들 및 프로토콜들을 사용한다. 따라서, IDCS는 전체 시스템을 보호하기 위해 단일의 일관된(consistent) 보안 모델을 제공하고, 그렇게 함으로써 더 적은 보안 모델들이 시스템에 구현될 수 록, 시스템은 더 안전하기 때문에 우수한 보안 준수를 허용한다.
IDCS 클라우드 환경에서, 애플리케이션들은 네트워크 호출(network call)들을 만듦으로써 통신한다. 네트워크 호출은 적용가능한 네트워크 프로토콜 예컨대 HTTP, TCP(Transmission Control Protocol), UDP(User Datagram Protocol), 등에 기반될 수 있다. 예를 들어, 애플리케이션 “X”는 HTTP URL(Uniform Resource Locator)로서 애플리케이션 “Y”을 노출시킴으로써 HTTP에 기초하여 애플리케이션 “Y”와 통신할 수 있다. 일 실시예에서, “Y”는 각각 성능에 대응하는 많은 자원들을 노출시키는 IDCS 마이크로서비스이다. “X” (예를 들어, 다른 IDCS 마이크로서비스)가 “Y”를 호출하는 것을 요구할 때, 그것은 “Y”를 포함하는 URL 및 인보크될 필요가 있는 자원/성능 (예를 들어, https:/host/Y/resource)을 구성하고 웹 라우팅 티어 (912)를 통과하는 대응하는 REST 호출을 만들어 “Y”로 향하게 한다.
일 실시예에서, IDCS 외부 호출자(caller)는 “Y”가 있는 곳을 알 필요가 없을 수 있지만, 그러나 웹 라우팅 티어 (912)는 애플리케이션 “Y”가 운용되고 있는 곳을 알 필요가 있다. 일 실시예에서, IDCS는 implements 정적(static) 라우팅 정보의 이용 가능성에 대한 요구가 없도록 각각의 애플리케이션이 운용되고 있는 곳을 결정하기 위해 탐지 기능(discovery functionality) (OAuth 서비스의 API에 의해 구현되는)을 구현한다.
일 실시예에서, EM(enterprise manager) (922)는 IDCS로 클라우드기반의 관리 및 온-프레미스(on-premise)를 연장하는 "단일창 방식(single pane of glass)"를 제공한다. 일 실시예에서, Chef 소프트웨어, Inc로부터의 구성 관리 툴인 “Chef” 서버 (924)는, 다양한 IDCS 티어들을 위한 구성 관리 기능을 제공한다. 일 실시예에서, 서비스 배치 인프라스트럭처 및/또는 영구 저장 모듈(persistent stored module) (928)은 테넌트 라이프사이클 관리 동작들, 퍼블릭 클라우드 라이프사이클 관리 동작들, 또는 다른 동작들을 위해 IDCS 웹 라우팅 티어 (912)에 OAuth2 HTTP 메시지들을 발송할 수 있다. 일 실시예에서, IDCS 인프라스트럭처 서비스들 티어 (916)는 ID/패스워드 HTTP 메시지들을 퍼블릭 클라우드 통지 서비스 (930) 또는 퍼블릭 클라우드 스토리지 서비스 (932)로 발송할 수 있다.
클라우드 액세스 제어(Cloud Access Control) - SSO
일 실시예는 클라우드 스케일 SSO 서비스를 구현하기 위한 가벼운(lightweight) 클라우드 표준들을 지원한다. 가벼운 클라우드 표준들의 예들은 브라우저를 통하여 (웹 브라우저가 가볍기 때문에) 액세스를 제공하는 HTTP, REST, 및 임의의 표준이다. 그와는 반대로, SOAP는 클라이언트를 빌드하기 위해 더 많은 관리, 구성, 및 툴링(tooling)을 필요로 하는 무거운(heavy) 클라우드 표준의 예이다. 실시예는 IDCS을 배경으로 유저 인증을 요청하기 위해 애플리케이션들에 대한 OpenID Connect 시멘틱(semantics)을 사용한다. 실시예는 상태 유지(statefull) 서버-측 세션 지원 없이 유저 활성 세션들(active session)들을 추적하기 위해 가벼운 HTTP 쿠키 기반의 유저 세션 트랙킹(cookie-based user session tracking)을 사용한다. 실시예는 인증된 아이덴티티를 그것들 자체의 로컬 세션에 다시 매핑할 때 사용하기 위해 애플리케이션들에 대한 JWT기반의 아이덴티티 토큰들을 사용한다. 실시예는 연합 아이덴티티 관리 시스템들과 통합을 지원하고, IDCS을 배경으로 유저 인증을 요청하기 위해 기업 배치들을 위한 SAML IDP 지원을 노출시킨다.
도 10 은 IDCS 일 실시예에서 IDCS내 SSO 기능의 시스템 아키텍처 뷰의 블럭 다이어그램 (1000)이다. 실시예는 클라이언트 애플리케이션들이 유저 인증 플로우들을 개시하기 위해 표준들 기반의(standards-based) 웹 프로토콜들을 레버리지(leverage)하는 것을 가능하게 한다. 클라우드 시스템과 SSO 통합을 필요로 하는 애플리케이션들은 기업 데이터센터들내에, 원격 파트너 데이터센터들내에 위치될 수 있거나, 또는 심지어 고객 온-프레미스에 의해 동작될 수 있다. 일 실시예에서, 상이한 IDCS 플랫폼 서비스들은 SSO의 비즈니스, 예컨대 연결된 고유의 애플리케이션들로부터 로그인/로그아웃 요청들을 프로세스 하기 위한 OpenID Connect (즉, IDCS와 통합하기 위해 OpenID Connect을 이용하는 애플리케이션들); 연결된 애플리케이션들로부터 브라우저기반의 로그인/로그아웃 요청들을 프로세스하기 위한 SAML IDP 서비스; 외부 SAML IDP을 배경으로 유저 인증을 오케스트레이트 하기 위한 SAML SP 서비스; 및 로컬 또는 연합 로그인 플로우들을 포함하는 엔드 유저 로그인 세러머니(ceremony)를 오케스트레이트하기 위해, 그리고 IDCS 호스트 세션 쿠키를 관리하기 위한 내부 IDCS SSO 서비스를 구현한다. 일반적으로, HTTP는 폼(form)을 가지고 또는 폼 없이 작업한다. 그것이 폼을 가지고 작업할 때, 폼은 브라우저내에 보여진다. 그것이 폼 없이 작업할 때, 그것은 서버 통신에 대한 클라이언트로서 기능한다. OpenID Connect 및 SAML 둘 모두는 폼을 렌더링(render)하는 능력을 요구하며, 이는 브라우저의 존재에 의해 성취될 수 있거나 또는 마치 브라우저가 있는 것처럼 동작하는 애플리케이션에 의해 가상으로(virtually) 수행될 수 있다. 일 실시예에서, IDCS를 통하여 유저 인증/SSO을 구현하는 애플리케이션 클라이언트는 OAuth2 클라이언트로서 IDCS에 등록되는 것을 요구하고 클라이언트 식별자 및 자격들 (예를 들어, ID/패스워드, ID/인증서, 등)을 획득하는 것을 요구한다.
도 10의 대표적 실시예는 두개의 플랫폼 마이크로서비스들: OAuth2 (1004) 및 SAML2 (1006), 및 하나의 인프라스트럭처 마이크로서비스: SSO (1008)를 포함하여 총괄하여 로그인 성능들을 제공하는 세개의 컴포넌트들/마이크로서비스들을 포함한다. 도 10의 실시예에서, IDCS는 SSO 서비스들 (1008)이 3-각 OAuth 플로우를 필요로 하고 OpenID Connect RP(relaying party, 그것의 유저 인증 기능을 IDP에 아웃소싱(outsource)하는 애플리케이션)로서 동작하는 브라우저 기반 웹 또는 고유(native) 애플리케이션들 (1010), 2-각 OAuth 플로우를 필요로 하고 OpenID Connect RP로서 동작하는 고유 애플리케이션들 (1011), 및 SAML SP로서 동작하는 웹 애플리케이션들 (1012)과 같은 상이한 유형들의 애플리케이션들상에서 제공되는 “아이덴티티 메타시스템 (identity Metasystem)”을 제공한다.
일반적으로, 아이덴티티 메타시스템은 디지털 아이덴티티를 위해 상호 운용 가능한(interoperable) 아키텍처이고, 다수의 기저(underlying) 기술들, 구현들, 및 제공자들에 기초하여 디지털 아이덴티티들의 집합(collection)을 채용하는 것을 허용한다. LDAP, SAML, 및 OAuth는 아이덴티티 성능을 제공하는 상이한 보안 표준들의 예들이고 애플리케이션들을 빌드하기 위한 베이시스(basis)일 수 있고, 아이덴티티 메타시스템은 이런 애플리케이션들 상에서 단일화된 보안 시스템을 제공하도록 구성될 수 있다. LDAP 보안 모델은 아이덴티티를 핸들링하기 위해 특정 메커니즘을 지정하고, 시스템을 통과하는 모든 것은 엄격하게 보호될 것이다. SAML는 애플리케이션들 중 하나의 세트가 상이한 보안 도메인 내 상이한 단체에 속하는 애플리케이션들 중 다른 세트와 정보를 안전하게 교환하는 것을 허용하도록 발전되었다. 두개의 애플리케이션들 사이에 신뢰(trust)가 없기 때문에, SAML는 하나의 애플리케이션이 동일한 단체에 속하지 않는 다른 애플리케이션을 인증하는 것을 허용하도록 발전되었다. OAuth는 웹 기반 인증을 수행하기 위한 가벼운 프로토콜인 OpenID Connect를 제공한다.
도 10의 실시예에서, OpenID 애플리케이션 (1010)이 IDCS내 OpenID 서버에 연결할 때, 그것의 “채널들(channel)”은 SSO 서비스를 요청한다. 유사하게, SAML 애플리케이션 (1012)이 IDCS내 SAML 서버에 연결할 때, 그것의 “채널들” 또한 SSO 서비스를 요청한다. IDCS내, 개별 마이크로서비스 (예를 들어, OpenID 마이크로서비스 (1004) 및 SAML 마이크로서비스 (1006))은 각각의 애플리케이션들을 핸들링할 것이고, 이들 마이크로서비스들은 SSO 마이크로서비스 (1008)로부터 SSO 성능을 요청한다. 이 아키텍처는 각각의 프로토콜을 위해 마이크로서비스를 추가하고 그런 다음 SSO 성능을 위해 SSO 마이크로서비스 (1008)를 이용함으로써 임의 개수의 다른 보안 프로토콜들을 지원하도록 확장될 수 있다. SSO 마이크로서비스 (1008)는 세션들을 발행하고 (즉, SSO 쿠키 (1014)가 제공된다) 세션을 발행하는 권한(authority)을 갖는 아키텍처내 유일한 시스템이다. IDCS 세션은 브라우저 (1002)에 의한 SSO 쿠키 (1014)의 사용을 통해 실현된다. 브라우저 (1002)는 또한 그것의 로컬 세션을 관리하기 위해 로컬 세션 쿠키 (1016)를 사용한다.
일 실시예에서, 예를 들어, 브라우저 내에서, 유저는 SAML에 기초하여 제 1 애플리케이션을 사용할 수 있고 로그인될 수 있고, 나중에 상이한 프로토콜 예컨대 OAuth로 빌드된 제 2 애플리케이션을 사용할 수 있다. 유저는 동일한 브라우저내에 제 2 애플리케이션상에 SSO가 제공된다. 따라서, 브라우저는 스테이트(state) 또는 유저 에이전트(user agent)이고 쿠키들을 유지한다.
일 실시예에서, SSO 마이크로서비스 (1008)는 로그인 세러머니 (1018), ID/패스워드 복원(recovery) (1020), 첫번째(first time) 로그인 플로우(1022), 인증 관리기 (1024), HTTP 쿠키 관리기 (1026), 및 이벤트 관리기 (1028)를 제공한다. 로그인 세러머니(1018)는 고객 설정들 및/또는 애플리케이션 컨텍스트에 기초하여 SSO 기능을 구현하고, 로컬 폼(local form) (즉, 베이직(basic) Auth), 외부 SAML IDP, 외부 OIDC IDP, 등에 따라 구성될 수 있다. ID/패스워드 복원 (1020)은 유저의 ID 및/또는 패스워드를 복원하기 위해 사용된다. 첫번째 로그인 플로우(1022)는 유저가 첫번째 로그인 할 때(즉, SSO 세션이 아직 존재하지 않는다) 구현된다. 인증 관리기 (1024)는 성공한 인증에 근거하여 인증 토큰들을 발행한다. HTTP 쿠키 관리기 (1026)는 인증 토큰을 SSO 쿠키에 저장한다. 이벤트 관리기 (1028)는 SSO 기능에 관련된 이벤트들을 공표한다.
일 실시예에서, OAuth 마이크로서비스 (1004)와 SSO 마이크로서비스 (1008)간에 상호작용들은 브라우저 리다이렉트(redirect)들에 기반되어 SSO 마이크로서비스 (1008)는 HTML 폼을 이용하여 유저에게 이의를 제기하고(chanllenge), 자격들을 확인하고, 세션 쿠키를 발행한다.
일 실시예에서, 예를 들어, OAuth 마이크로서비스 (1004)는 3-각(3-legged) OAuth 플로우에 따라 애플리케이션의 유저를 인증하기 위해 브라우저 (1002)로부터 인증 요청을 수신할 수 있다. OAuth 마이크로서비스 (1004)는 그런 다음 OIDC 제공자 (1030)로서 동작하고, 브라우저 (1002)를 SSO 마이크로서비스 (1008)로 리다이렉트하고, 애플리케이션 컨텍스트를 따라 진행한다. 유저가 유효한 SSO 세션을 가진지 아닌지 여부에 의존하여, SSO 마이크로서비스 (1008)는 현존하는 세션을 확인하거나 또는 로그인 세러머니를 수행한다. 성공한 인증 또는 확인(validation)시에, SSO 마이크로서비스 (1008)는 OAuth 마이크로서비스 (1004)로 인증 컨텍스트를 리턴한다. OAuth 마이크로서비스 (1004)는 그런 다음 AZ(authorization) 코드로 콜백(callback) URL에 브라우저 (1002)를 리다이렉트한다. 브라우저 (1002)는 요구된 토큰들 (1032)을 요청하기 위해 OAuth 마이크로서비스 (1004)에 AZ 코드를 발송한다. 브라우저 (1002)는 또한 HTTP 인증 헤더내에 그것의 클라이언트 자격들 (OAuth2 클라이언트로서 IDCS에 등록할 때 획득된)을 포함한다. OAuth 마이크로서비스 (1004)는 응답으로(in return) 브라우저 (1002)에 요구된 토큰들 (1032)을 제공한다. 일 실시예에서, 브라우저 (1002)에 제공된 토큰들 (1032)은 IDCS OAuth2 서버에 의해 사인된(signed) JW 아이덴티티 및 액세스 토큰들을 포함한다. 이 기능의 추가 세부사항들은 도 11 를 참고로 하여 아래에 더 설명된다.
일 실시예에서, 예를 들어, OAuth 마이크로서비스 (1004)는 2-각(2-legged) OAuth 플로우에 따라 유저를 인증하기 위해 고유 애플리케이션(1011)로부터 인증 요청을 수신할 수 있다. 이 경우에, OAuth 마이크로서비스 (1004)내 인증 관리기 (1034)는 대응하는 인증을 수행하고 (예를 들어, 클라이언트 (1011)로부터 수신된 ID/패스워드에 기초하여), 토큰 관리기 (1036)는 성공한 인증 시에 대응하는 액세스 토큰을 발행한다.
일 실시예에서, 예를 들어, SAML 마이크로서비스 (1006)는 SAML SP로서 동작하는 웹 애플리케이션(1012)의 유저를 인증하기 위해 브라우저로부터 SSO POST 요청을 수신할 수 있다. SAML 마이크로서비스 (1006)는 그런 다음 SAML IDP(1038)로서 동작하고, 브라우저 (1002)를 SSO 마이크로서비스 (1008)로 리다이렉트하고, 애플리케이션 컨텍스트를 따라 진행한다. 유저가 유효한 SSO 세션을 가진지 아닌지 여부에 의존하여, SSO 마이크로서비스 (1008)는 현존하는 세션을 확인하거나 또는 로그인 세러머니를 수행한다. 성공한 인증 또는 확인시에, SSO 마이크로서비스 (1008)는 SAML 마이크로서비스 (1006)로 인증 컨텍스트를 리턴한다. SAML 마이크로서비스는 그런 다음 요구된 토큰들과 함께 SP로 리다이렉트한다.
일 실시예에서, 예를 들어, SAML 마이크로서비스 (1006)는 SAML SP (1040)로서 역할을 할 수 있고 원격 SAML IDP (1042) (예를 들어, ADFS(active directory federation service))로 간다. 일 실시예는 표준 SAML/AD 플로우들을 구현한다. 일 실시예에서, SAML 마이크로서비스 (1006)와 SSO 마이크로서비스 (1008)간에 상호작용들은 브라우저 리다이렉트들에 기반되어 SSO 마이크로서비스 (1008)는 HTML 폼을 이용하여 유저에게 이의를 제기하고, 자격들을 확인하고, 세션 쿠키를 발행한다.
일 실시예에서, IDCS내 컴포넌트들 (예를 들어, (1004, 1006, 1008))과 IDCS 외부 컴포넌트 (예를 들어, (1002, 1011, 1042)) 사이의 상호작용들은 방화벽들 (1044)을 통과하여 수행된다.
로그인/로그아웃 플로우(Login/Logout Flow)
도 11은 일 실시예에서 IDCS에 의해 제공된 SSO 기능의 메시지 시퀀스 플로우(1100)이다. 유저가 클라이언트 (1106) (예를 들어, 브라우저 기반의 애플리케이션 또는 모바일/고유 애플리케이션)을 액세스하기 위해 브라우저 (1102)를 사용할 때, 클라우드 게이트(Cloud Gate) (1104)는 애플리케이션 집행점(application enforcement point)으로서 동작하고 로컬 정책 텍스트 파일(local policy text file)에 정의된 정책을 시행한다. 만약 클라우드 게이트 (1104)가 유저가 어떠한 로컬 애플리케이션 세션도 가지지 않는 것을 감지하면, 그것은 유저가 인증될 것을 요구한다. 그렇게 하기 위해서, 클라우드 게이트 (1104)는 OAuth2 마이크로서비스 (1110)를 배경으로 OpenID Connect 로그인 플로우를 개시하기 위해 (scopes = ”openid profile”를 갖는 3-각 AZ Grant 플로우) 브라우저 (1102)를 OAuth2 마이크로서비스 (1110)로 리다이렉트한다.
브라우저 (1102)의 요청은 IDCS 라우팅 티어 웹 서비스 (1108) 및 클라우드 게이트 (1104)를 횡단하여 OAuth2 마이크로서비스 (1110)에 도달한다. OAuth2 마이크로서비스 (1110)는 애플리케이션 컨텍스트(application context)를 구성하고 (즉, 애플리케이션을 설명하는 메타데이터, 예를 들어, 애플리케이션을 연결하는 아이덴티티, 클라이언트 ID, 구성, 무엇을 애플리케이션이 할 수 있는지, 등), 그리고 로그 인 하기 위해 브라우저 (1102)를 SSO 마이크로서비스 (1112)로 리다이렉트한다.
만약 유저가 유효한 SSO 세션을 가지면, SSO 마이크로서비스 (1112)는 로그인 세러머니를 시작하지 않고서 현존하는 세션을 확인한다. 만약 유저가 유효한 SSO 세션을 가지지 않으면 (즉, 어떠한 세션 쿠키도 존재하지 않으면), SSO 마이크로서비스 (1112)는 고객 로그인 선호사항(preference)들 (예를 들어, 브랜드(branded) 로그인 페이지를 디스플레이)에 따라 유저 로그인 세러머니를 개시한다. 그렇게 하기 위해서, SSO 마이크로서비스 (1112)는 자바스크립트에 구현된 로그인 애플리케이션 서비스 (1114)로 브라우저 (1102)를 리다이렉트한다. 로그인 애플리케이션 서비스 (1114)는 브라우저 (1102)에 로그인 페이지를 제공한다. 브라우저 (1102)는 로그인 자격들을 포함하는 SSO 마이크로서비스 (1112)에 REST POST를 발송한다. SSO 마이크로서비스 (1112)는 액세스 토큰을 생성하고 그것을 REST POST에 클라우드 게이트 (1104)로 발송한다. 클라우드 게이트 (1104)는 유저의 패스워드를 확인하기 위해 Admin SCIM 마이크로서비스 (1116)로 인증 정보를 발송한다. Admin SCIM 마이크로서비스 (1116)는 성공한 인증 인지를 결정하고 대응하는 메시지를 SSO 마이크로서비스 (1112)로 발송한다.
일 실시예에서, 로그인 세러머니 동안에, “로그인” 동작이 어떠한 추가 동의도 요구하지 않을 때 로그인 페이지는 동의 페이지(consent page)를 디스플레이 하지 않는다. 대신에, 프라이버시 정책(privacy policy)이 로그인 페이지 상에 명시되고, 애플리케이션들에 노출되고 있는 어떤 프로파일 속성들에 대하여 유저에게 알린다. 로그인 세러머니 동안에, SSO 마이크로서비스 (1112)는 고객의 IDP 선호사항들을 준수하고 만약 구성되면, 구성된 IDP을 배경으로 인증을 위해 IDP로 리다이렉트한다.
성공한 인증 또는 확인시에, SSO 마이크로서비스 (1112)는 유저의 인증 토큰을 함유하는 새롭게 생성된/업데이트된 SSO 호스트 HTTP 쿠키 (예를 들어, “HOSTURL”에 의해 표시된 호스트의 컨텍스트하에서 생성된 쿠키)를 가지고 OAuth2 마이크로서비스 (1110)로 다시 브라우저 (1102)를 리다이렉트한다. OAuth2 마이크로서비스 (1110)는 브라우저 (1102)로 다시 AZ 코드(예를 들어, OAuth 개념(concept))를 리턴하고 클라우드 게이트 (1104)로 리다이렉트한다. 브라우저 (1102)는 AZ 코드를 클라우드 게이트 (1104)로 발송하고, 클라우드 게이트 (1104)는 액세스 토큰 및 아이덴티티 토큰을 요청하기 위해 REST POST를 OAuth2 마이크로서비스 (1110)로 발송한다. 양 토큰들은 OAuth 마이크로서비스 (1110) (오디언스 토큰 클레임(audience token claim)에 의해 표시된)로 스코프(scope)된다. 클라우드 게이트 (1104)는 토큰들을 OAuth2 마이크로서비스 (1110)로부터 수신한다.
클라우드 게이트 (1104)는 유저의 인증 아이덴티티를 그것의 내부 계정 표현(internal account representation)에 매핑하기 위해 아이덴티티 토큰을 사용하고, 그것은 그것 자체의 HTTP 쿠키내에 이 매핑을 저장할 수 있다. 클라우드 게이트 (1104)는 그런 다음 브라우저 (1102)를 클라이언트 (1106)로 리다이렉트한다. 브라우저 (1102)는 그런 다음 클라이언트 (1106)에 도달하고 클라이언트 (1106)로부터 대응하는 응답을 수신한다. 이 지점으로부터, 브라우저 (1102)는 애플리케이션의 로컬 쿠키가 유효한 동안은 무결절로(seamlessly) 애플리케이션 (즉, 클라이언트 (1106))를 액세스할 수 있다. 일단 로컬 쿠키가 무효(invalid)이게 되면, 인증 프로세스가 반복된다.
클라우드 게이트 (1104)는 OAuth2 마이크로서비스 (1110) 또는 SCIM 마이크로서비스로부터 “userinfo”를 획득하기 위해 요청에 수신된 액세스 토큰을 추가로 사용한다. 액세스 토큰은 “profile” 스코프에 의해 허용된 속성들을 위해 “userinfo” 자원을 액세스하는데 충분하다. 그것은 또한 SCIM 마이크로서비스를 통하여 “/me” 자원들을 액세스하는데 충분하다. 일 실시예에서, 디폴트(default)로, 수신된 액세스 토큰은 “profile” 스코프하에서 허용된 유저 프로파일 속성들에 대하여만 유효하다. 다른 프로파일 속성들에 대한 액세스는 클라우드 게이트 (1104)에 의해 발행된 AZ 승인 로그인 요청에 제출된 추가의 (옵션의) 스코프들에 기초하여 허가된다.
유저가 다른 OAuth2 통합된 연결 애플리케이션을 액세스할 때, 동일한 프로세스가 반복된다.
일 실시예에서, SSO 통합 아키텍처는 브라우저 기반의 유저 로그아웃들을 위해 유사한 OpenID Connect 유저 인증 플로우를 사용한다. 일 실시예에서, 현존하는 애플리케이션 세션을 갖는 유저는 로그아웃을 개시하기 위해 클라우드 게이트 (1104)를 액세스한다. 대안적으로, 유저는 IDCS 측상에 개시된 로그아웃을 가질 수 있다. 클라우드 게이트 (1104)는 애플리케이션-특정 유저 세션을 종료하고, OAuth2 마이크로서비스 (1110)를 배경으로 OAuth2 OP(OpenID Provider) 로그아웃 요청을 개시한다. OAuth2 마이크로서비스 (1110)는 유저의 호스트 SSO 쿠키를 킬링(kill)하는 SSO 마이크로서비스 (1112)로 리다이렉트한다. SSO 마이크로서비스 (1112)는 유저의 SSO 쿠키에 추적되는 알려진 로그아웃 엔드 포인트들을 배경으로 리다이렉트들의 세트(OAuth2 OP 및 SAML IDP)를 개시한다.
일 실시예에서, 만약 클라우드 게이트 (1104)가 유저 인증을 요청하기 위해 SAML 프로토콜을 사용하면 (예를 들어, 로그인), 유사한 프로세스가 SAML 마이크로서비스와 SSO 마이크로서비스 (1112) 사이에서 시작된다.
클라우드 캐시(Cloud Cache)
일 실시예는 클라우드 캐시로 지칭되는 서비스/성능을 제공한다. LDAP 기반되는 애플리케이션들과의 (예를 들어, 이메일 서버들, 캘린더(calendar) 서버들, 일부 비즈니스 애플리케이션들, 등) 통신을 지원하기 위해 IDCS에 클라우드 캐시가 제공되는데 이는 이런 애플리케이션들이 LDAP에만 기초하여 통신하도록 구성된 동안에 IDCS는 LDAP에 따라 통신하지 않기 때문이다. 전형적으로, 클라우드 디렉토리들은 REST API들을 통하여 노출되고 LDAP 프로토콜에 따라 통신하지 않는다. 일반적으로, 회사 방화벽들을 가로질러 LDAP 연결들을 관리하는 것은 셋 업 및 관리하기에 어려운 특별한 구성들을 요구한다.
LDAP 기반 애플리케이션들을 지원하기 위해, 클라우드 캐시는 LDAP 통신을 클라우드 시스템과의 통신에 적합한 프로토콜로 변환한다(translate). 일반적으로, LDAP 기반 애플리케이션은 LDAP를 통한 데이터베이스를 사용한다. 애플리케이션은 대안적으로 상이한 프로토콜 예컨대 SQL을 통하여 데이터베이스를 사용하도록 구성될 수 있다. 그러나, LDAP는 트리 구조들로 자원들의 계층적인 표현을 제공하지만, 반면 SQL는 테이블들 및 필드들로서 데이터를 나타낸다. 따라서, LDAP는 기능을 검색하는데 보다 바람직할 수 있고, 한편 SQL은 트랜잭션 기능에 보다 바람직할 수 있다.
일 실시예에서, IDCS에 의해 제공된 서비스들은 예를 들어, 애플리케이션들의 유저를 인증하기 위해 (즉, 아이덴티티 서비스) 또는 애플리케이션에 대한 보안 정책을 시행하기 위해 (즉, 보안 서비스) LDAP 기반 애플리케이션에 사용될 수 있다. 일 실시예에서, IDCS와의 인터페이스는 방화벽을 통과하여 HTTP에 기반된다 (예를 들어, REST). 전형적으로, 회사 방화벽들은 설사 통신이 SSL(Secure Sockets Layer)를 구현한다 하더라도 내부 LDAP 통신에 대한 액세스를 허용하지 않고, 그리고 TCP 포트가 방화벽을 통과하여 노출되는 것을 허용하지 않는다. 그러나, 클라우드 캐시는 LDAP 기반 애플리케이션들이 IDCS에 의해 제공된 서비스들에 도달하는 것을 허용하기 위해 LDAP과 HTTP 사이에서 변환되고, 방화벽은 HTTP에 대하여 오픈될 것이다.
일반적으로, LDAP 디렉토리는 비즈니스의 라인 예컨대 마케팅(marketing) 및 개발에서 사용될 수 있고, 유저들, 그룹들, 작업들, 등을 정의한다. 일 예에서, 마케팅 및 개발 비즈니스는 다른 타겟팅된(targeted) 고객들을 가질 수 있고, 그리고 각각의 고객에 대하여, 그것들 자체의 애플리케이션들, 유저들, 그룹들, 작업들, 등을 가질 수 있다. LDAP 캐시 디렉토리를 운용할 수 있는 비즈니스 라인의 다른 예는 무선 서비스 제공자(wireless service provider)이다. 이 경우에, 무선 서비스 제공자의 유저에 의해 만들어진 각각의 호출은 LDAP 디렉토리를 배경으로 유저 디바이스를 인증하고, LDAP 디렉토리내 대응하는 정보의 일부는 과금 시스템(billing system)과 동기화될 수 있다. 이들 예들에서, LDAP는 런타임(runtime)에서 검색되는 컨텐츠를 물리적으로 분리하는 기능을 제공한다.
일 예에서, 무선 서비스 제공자는 그것들의 코어 비즈니스 (예를 들어, 규칙적인 호출들(regular calls))에 대한 그것 자체의 아이덴티티 관리 서비스들을 핸들링 할 수 있고, 동시에 숏 텀(short term) 마케팅 캠페인(campaign)의 지원에서 IDCS 에 의해 제공된 서비스들을 사용한다. 이 경우에서, 클라우드 캐시는 그것이 클라우드를 배경으로(against) 운용하는 단일 셋의 유저들 및 단일 셋의 그룹들을 그것이 가질 때 LDAP를 "단조롭게 한다(flattens)". 일 실시예에서, 임의 개수의 클라우드 캐시들이 IDCS에 구현될 수 있다.
분산된 데이터 그리드(Distributed Data Grid)
일 실시예에서, IDCS내 캐시 클러스터가 예를 들어, U.S. Pat. Pub. No. 2016/0092540에 개시된 분산된 데이터 그리드에 기반하여 구현되고, 이의 개시는 참조로서 본원에 통합된다. 분산된 데이터 그리드는 분산된(distributed) 또는 클러스터된(clustered) 환경내에서 계산들(computation)과 같은 정보 및 관련된 동작들을 관리하기 위해 컴퓨터 서버들의 집합(collection)이 하나 이상의 클러스터(cluster)들 내에서 함께 작업하는 시스템이다. 분산된 데이터 그리드는 서버들을 가로질러 공유되는 애플리케이션 오브젝트들 및 데이터를 관리하기 위해 사용될 수 있다. 분산된 데이터 그리드는 저 응답 시간, 높은 스루풋, 예측할 수 있는 확장성, 연속적인 이용 가능성, 및 정보 신뢰성을 제공한다. 특별히 예들, 예를 들어, Oracle Corp로부터의 Oracle Coherence 데이터 그리드와 같은 분산된 데이터 그리드들은 더 높은 성능을 달성하고, 다수의 서버들에 걸쳐 동기화된 해당 정보의 복사본들을 유지할 때 이중화(redundancy)를 사용하기 위해 메모리내(in-memory) 정보를 저장하고, 따라서 서버의 고장의 이벤트시에 데이터의 연속된 이용 가능성 및 시스템의 탄력성을 보장한다.
일 실시예에서, IDCS는 모든 마이크로서비스가 차단되지 않고 공유된 캐시 오브젝트에 대한 액세스를 요청할 수 있도록 Coherence와 같은 분산된 데이터 그리드를 구현한다. Coherence는 전통적인 관계형(relational) 데이터베이스 관리 시스템들보다 더 나은 신뢰성, 확장성, 및 성능을 갖도록 디자인된 전용 자바기반의 메모리내 데이터 그리드(proprietary Java-based in-memory data grid)이다. Coherence는 P2P(peer to peer) (즉, 중앙 관리기(central manager) 없는), 메모리내, 분산된 캐시를 제공한다.
도 12는 본 발명의 실시예들을 구현하고 클라이언트들 (1250)에 데이터 액세스를 제공하고 데이터를 저장하는 분산된 데이터 그리드 (1200)의 예제를 예시한다. "데이터 그리드 클러스터(data grid cluster)", 또는 "분산된 데이터 그리드(distributed data grid)"는 분산된 또는 클러스터된 환경내에서 계산들과 같은 정보 및 관련된 동작들을 관리 및 저장하기 위해 하나 이상의 클러스터들 (예를 들어, (1200a, 1200b, 1200c))에 함께 작업하는 복수개의 컴퓨터 서버들 (예를 들어, (1220a, 1220b, 1220c, 및 1220d))을 포함하는 시스템이다. 분산된 데이터 그리드 (1200)는 클러스터 (1200a)내에 다섯개의 데이터 노드들 (1230a, 1230b, 1230c, 1230d, 및 1230e)과 네개의 서버들 (1220a, 1220b, 1220c, 1220d)을 포함하는 것으로 예시되지만, 분산된 데이터 그리드 (1200)는 임의 개수의 클러스터들 및 각각의 클러스터에 임의 개수의 서버들 및/또는 노드들을 포함할 수 있다. 일 실시예에서, 분산된 데이터 그리드 (1200)는 본 발명을 구현한다.
도 12에 예시된 바와 같이, 분산된 데이터 그리드는 함께 작업하는 많은 서버들 (예를 들어, (1220a, 1220b, 1220c, 및 1220d)) 상에 데이터를 분배시킴으로써 데이터 스토리지 및 관리 성능들을 제공한다. 데이터 그리드 클러스터의 각각의 서버는 예를 들어, 하나 내지 두개의 프로세서 소켓들 및 프로세서 소켓 당 두개 내지 네개의 CPU 코어들을 갖는 "상품(commodity) x86" 서버 하드웨어 플랫폼과 같은 통상의 컴퓨터 시스템일 수 있다. 각각의 서버 (예를 들어, (1220a, 1220b, 1220c, 및 1220d))는 하나 이상의 CPU들, 네트워크 인터페이스 카드들 (“NIC”), 및 예를 들어, 최소 4 GB의 RAM 내지 64 GB RAM 또는 그 이상 까지를 포함하는 메모리로 구성된다. 서버 (1220a)는 CPU (1222a), 메모리 (1224a), 및 NIC (1226a)를 갖는 것으로 예시된다 (이들 엘리먼트들은 다른 서버들 (1220b, 1220c, 1220d)에도 또한 존재하지만 그러나 도시되지 않는다). 옵션으로, 각각의 서버는 과잉(spillover) 스토리지 용량을 제공하기 위해 플래시 메모리 (예를 들어, SSD (1228a))가 또한 제공될 수 있다. 제공된 때, SSD 용량은 바람직하게는 RAM의 10배 사이즈이다. 데이터 그리드 클러스터 (1200a)내 서버들 (예를 들어, (1220a, 1220b, 1220c, 1220d))은 고 대역폭 NIC들 (예를 들어, PCI-X 또는 PCIe) 내지 고성능 네트워크 스위치 (1220) (예를 들어, 기가비트 이더넷 또는 그 이상)를 이용하여 연결된다.
클러스터 (1200a)는 바람직하게는 고장 동안에 데이터 손실의 가능성을 피하기 위해 최소의 네개의 물리적 서버들을 함유하지만, 그러나 전형적인 인스톨은 더 많은 서버들을 갖는다. 페일오버(failover) 및 페일백(failback)은 각각의 클러스터에 존재하는 더 많은 서버들이 더 효율적이고 클러스터상에서의 서버 고장의 영향을 줄인다. 서버들 사이의 통신 시간을 최소화하기 위해, 각각의 데이터 그리드 클러스터는 이상적으로는 서버들 사이의 단일 홉 통신(single hop communication)을 제공하는 단일 스위치 (1202)로 제한된다. 클러스터는 따라서 스위치 (1202)상의 포트들의 수에 의해 제한될 수 있다. 전형적인 클러스터는 따라서 4 물리적 서버 와 96 물리적 서버 사이에서 포함할 것이다.
분산된 데이터 그리드 (1200)의 최대 WAN(Wide Area Network)에서, WAN내 각각의 데이터센터는 독립적이지만, 그러나 상호연결된, 데이터 그리드 클러스터들 (예를 들어, (1200a, 1200b, 및 1200c))이다. WAN은 예를 들어, 도 12에 도시된 것보다 더 많은 클러스터들을 포함할 수 있다. 추가적으로, 상호연결되지만 독립적인 클러스터들 (예를 들어, (1200a, 1200b, 1200c))을 이용함으로써 및/또는 서로 원격인 데이터센터들에 상호연결되지만, 독립적인, 클러스터들을 위치시킴으로써, 분산된 데이터 그리드는 자연 재해, 화재, 홍수, 확장된 전력 손실, 및 유사한 것에 의해 야기되는 하나의 클러스터내 모든 서버들의 동시 손실에 대비하여 클라이언트들 (1250)에 대한 서비스 및 데이터를 안전하게 할 수 있다.
하나 이상의 노드들 (예를 들어, (1230a, 1230b, 1230c, 1230d 및 1230e))은 클러스터 (1200a)의 각각의 서버 (예를 들어, (1220a, 1220b, 1220c, 1220d))상에서 운용된다. 분산된 데이터 그리드에서, 노드들은 예를 들어, 소프트웨어 애플리케이션들, 가상 기계들, 또는 유사한 것일 수 있고, 서버들은 노드가 운용하는 운영 체제, 하이퍼바이저(hypervisor), 또는 유사한 것 (미도시)을 포함할 수 있다. Oracle Coherence 데이터 그리드에서, 각각의 노드는 자바 가상 기계 (“JVM(Java virtual machine)”)이다. 많은 JVM들/노드들은 서버상에서 이용 가능한 메모리 및 CPU 프로세싱 파워에 의존하여 각각의 서버상에 제공될 수 있다. JVM들/노드들은 분산된 데이터 그리드에 의해 요구된 때 추가, 시작, 중지 및 삭제될 수 있다. Oracle Coherence를 운용하는 JVM들은 시작될 때 자동으로 접합되고(join) 그리고 클러스터링한다(cluster). 클러스터에 접합하는 JVM들/노드들은 소위 클러스터 멤버들(cluster member) 또는 클러스터 노드(cluster node)들이다.
각각의 클라이언트 또는 서버는 정보를 전달하기 위한 버스 또는 다른 통신 메커니즘, 및 정보를 프로세스하기 위해 버스에 결합된 프로세서를 포함한다. 프로세서는 범용 프로세서 또는 특정 용도 프로세서 중 임의의 유형일 수 있다. 각각의 클라이언트 또는 서버는 프로세서에 의해 실행될 정보 및 명령들을 저장하기 위한 메모리를 더 포함할 수 있다. 메모리는 랜덤 액세스 메모리 (“RAM”), 판독 전용 메모리 (“ROM”), 정적 스토리지 예컨대 자기 또는 광 디스크, 또는 임의의 다른 유형의 컴퓨터 판독가능한 매체들의 임의의 조합으로 구성될 수 있다. 각각의 클라이언트 또는 서버는 네트워크에 대한 액세스를 제공하기 위해 통신 디바이스, 예컨대 네트워크 인터페이스 카드를 더 포함할 수 있다. 따라서, 유저는 각각의 클라이언트 또는 서버와 직접, 또는 네트워크를 통하여 원격에서, 또는 임의의 다른 방법으로 인터페이스할 수 있다.
컴퓨터 판독가능한 매체들은 프로세서에 의해 액세스될 수 있는 임의의 이용 가능한 매체들일 수 있고 휘발성 및 비-휘발성 매체들, 착탈 가능한 및 착탈가능하지 않은 매체 및 통신 매체를 포함한다. 통신 매체는 변조된 데이터 신호 예컨대 반송파 또는 다른 전송 메커니즘에 컴퓨터 판독가능한 명령들, 데이터 구조들, 프로그램 모듈들, 또는 다른 데이터를 포함할 수 있고, 임의의 정보 전달 매체들을 포함할 수 있다.
프로세서는 추가로 버스를 통하여 디스플레이, 예컨대 액정 디스플레이 (“LCD(Liquid Crystal Display)”)에 추가로 결합될 수 있다. 키보드 및 커서 제어 디바이스, 예컨대 컴퓨터 마우스는 유저가 각각의 클라이언트 또는 서버와 인터페이스하는 것을 가능하게 하도록 버스에 추가로 결합될 수 있다.
일 실시예에서, 메모리는 프로세서에 의해 실행될 때 기능을 제공하는 소프트웨어 모듈들을 저장한다. 모듈들은 각각의 클라이언트 또는 서버에 운영 체제 기능을 제공하는 운영 체제(operating system)를 포함한다. 모듈들은 클라우드 아이덴티티 관리 기능, 및 본 출원에 개시된 모든 다른 기능을 제공하는 클라우드 아이덴티티 관리 모듈을 더 포함할 수 있다.
클라이언트들은 웹 서비스 예컨대 클라우드 서비스를 액세스할 수 있다. 웹 서비스는 일 실시예에서 Oracle Corp로부터의 WebLogic Server 상에 구현될 수 있다. 다른 실시예들에서, 웹 서비스의 다른 구현예들이 사용될 수 있다. 웹 서비스는 클라우드 데이터를 저장하는 데이터베이스를 액세스한다.
개시된 바와 같이, 실시예들은 클라우드기반의 멀티-테넌트 IAM 서비스들을 제공하기 위해 마이크로서비스 기반 아키텍처를 구현한다. 일 실시예에서, 각각의 요청된 아이덴티티 관리 서비스는 중간 티어에 마이크로서비스에 의해 핸들링되는 실시간 태스크들, 및 메시지 큐에 오프로드되는 근-실시간(near-real-time) 태스크들로 쪼개진다. 따라서, 실시예들은 클라우드-스케일 IAM 플랫폼을 제공한다.
도 13은 실시예에 따른 IAM 기능의 흐름도 (1300)이다. 일 실시예에서, 도 13의 흐름도의 기능은 프로세서에 의해 실행되는 메모리 또는 다른 컴퓨터 판독가능한 또는 유형의 매체에 저장된 소프트웨어에 의해 구현된다. 다른 실시예들에서, 기능은 하드웨어 (예를 들어, 애플리케이션 특정 집적 회로 (“ASIC(application specific integrated circuit)”), 프로그램 가능한 게이트 어레이 (“PGA(programmable gate array)”), 필드 프로그램 가능한 게이트 어레이 (“FPGA(field programmable gate array)”), 등의 사용을 통하여) 또는 하드웨어 및 소프트웨어의 임의의 조합에 의해 수행될 수 있다.
(1302)에서 아이덴티티 관리 서비스를 위한 요청(request)이 클라이언트로부터 수신되고, (1304)에서 요청이 인증되고, (1306)에서 마이크로서비스가 요청에 기초하여 액세스된다. 예를 들어, 일 실시예에서, 여러 가지 애플리케이션들/서비스들 (602)이 도 6에 예시된 바와 같이 IDCS 마이크로서비스들(614)을 사용하기 위해서 IDCS API들에 HTTP 호출들을 할 수 있다. 일 실시예에서, 마이크로서비스는 다른 모듈들/마이크로서비스들과 통신할 수 있는 자체 완비된 모듈(self-contained module)이고, 각각의 마이크로서비스는 다른 것들에 의해 컨택될 수 있는 이름이 없는(unnamed) 범용 포트를 가질 수 있다. 일 실시예에서, 요청은 본 출원에서 설명된 Cloud Gate와 같은 보안 게이트에 의해 인증된다. 일 실시예에서, 요청은 예를 들어, 도 6에 웹 라우팅 티어 (610) 및/또는 도 7에 클라우드 게이트 (702)를 참고로 하여 인증된다.
(1308)에서 클라이언트의 테넌시, 요청에 관련된 유저의 테넌시, 및 요청에 관련된 자원의 테넌시는 예를 들어, “테넌시 유형들(Tenancy Types)”를 참고로 하여 본 출원에서 설명된 것처럼 요청에 기초하여 결정된다. 일 실시예에서, 요청은 클라이언트의 테넌시를 식별하는 클라이언트 어써션 토큰(client assertion token)을 포함한다. 일 실시예에서, 요청은 유저의 테넌시를 식별하는 유저 어써션 토큰(user assertion token)을 포함한다. 일 실시예에서, 요청의 헤더는 자원의 테넌시를 나타낸다. 일 실시예에서, 자원은 대응하는 자원 테넌트에 의해 소유되고 자원 테넌시에 있는 애플리케이션 또는 데이터이다. 일 실시예에서, 클라이언트는 유저에 의해 사용되는 브라우저이다. 일 실시예에서, 클라이언트의 테넌시, 유저의 테넌시, 및 자원의 테넌시 중 적어도 두개는 동일한 테넌시이다.
일 예에서, “테넌트 1”내 클라이언트는 “테넌트 3”내 애플리케이션을 액세스하기 위해 “테넌트 2”내 유저를 위한 액세스 토큰을 요청할 수 있다. 클라이언트는 “http://tenant3/oauth/token”으로 가서 토큰을 위한 OAuth 요청을 인보크함으로써 그렇게 할 수 있다. 클라이언트는 요청에 “클라이언트 어써션”을 포함함으로써 “테넌트 1”에 살아있는 클라이언트로서 그 자체를 식별한다. 클라이언트 어써션은 클라이언트 ID (예를 들어, “클라이언트 1”) 및 클라이언트 테넌시 “테넌트 1”를 포함한다. “테넌트 1”내 “클라이언트 1”으로서, 클라이언트는 “테넌트 3”상에 토큰을 위한 요청을 인보크시킬 권리를 가지며, 클라이언트는 “테넌트 2”내 유저를 위한 토큰을 원한다. 따라서, “유저 어써션”은 동일한 HTTP 요청의 일부로서 또한 패스된다. 생성된 액세스 토큰은 애플리케이션 테넌시 (“테넌트 3”)인 타겟 테넌시의 컨텍스트에서 발행될 것이고 유저 테넌시 (“테넌트 2”)를 포함할 것이다.
(1310)에서, 데이터는 예를 들어, 도 8에 데이터베이스 (806)로부터의 데이터 검색을 참고로 하여 본 출원에서 설명된 것처럼 데이터베이스내 클라이언트의 테넌시, 유저의 테넌시, 또는 자원의 테넌시 중 적어도 하나로부터 검색된다. 일 실시예에서, 마이크로서비스 (804)는 도 8에 데이터베이스 (806)로부터의 데이터 검색을 참고로 하여 본 출원에서 설명된 것처럼 데이터베이스(806)에 연결들을 제공하는 연결 풀(810)을 이용함으로써 데이터를 검색한다. 일 실시예에서, 클라이언트의 테넌시, 유저의 테넌시, 및 자원의 테넌시는 동일하거나 상이한 테넌시들일 수 있다. 예를 들어, 클라이언트는 제 1 테넌트에 있을 수 있고, 유저는 제 1 테넌트와 다른 제 2 테넌트에 있을 수 있다. 다른 예로서, 클라이언트는 제 1 테넌트에 있을 수 있고, 자원은 제 1 테넌트와 다른 제 2 테넌트에 있을 수 있다. 다른 예로서, 유저는 제 1 테넌트에 있을 수 있고, 자원은 제 1 테넌트와 다른 제 2 테넌트에 있을 수 있다. 다른 예로서, 클라이언트는 제 1 테넌트에 있을 수 있고, 유저는 제 1 테넌트와 다른 제 2 테넌트에 있을 수 있고, 자원은 제 1 및 제 2 테넌트와 다른 제 3 테넌트에 있을 수 있다.
(1312)에서 아이덴티티 관리 태스크는 예를 들어, 도 6에 IDCS 중간 티어 (614)내 마이크로서비스들을 액세스하고 그리고 IDCS “API 플랫폼”를 참고로 하여 본 출원에서 설명된 것 처럼 데이터를 이용하는 서비스에 의해 수행된다. 일 실시예에서, 아이덴티티 관리 태스크는 자원을 액세스하기 위해 유저에 대한 액세스 토큰을 획득하는 것을 포함한다. 일 실시예에서, 해당 액세스 토큰은 자원의 테넌시 및 유저의 테넌시를 식별한다. 일 실시예에서, 아이덴티티 관리 태스크는 유저의 인증을 포함한다. 일 실시예에서, 인증은 3-각 또는 2-각 플로우를 이용하여 OAuth 표준에 기반될 수 있다.
일 실시예에서, 서비스는 스테이트리스(stateless)이다. 일 실시예에서, 마이크로서비스 (804)는 연결 풀 (810)내 개별 연결에 연결하기 위해서 프락시 유저 (812)를 사용한다. 일 실시예에서, 프락시 유저 (812)는 데이터베이스 (806)내 테넌트 (808)를 나타낸다. 일 실시예에서, 데이터베이스 (806) 및 마이크로서비스 (804)는 서로에 독립적으로 확장하도록 구성된다. 일 실시예에서, 데이터베이스 (806)는 분산된 데이터 그리드를 포함한다.
도 14는 실시예에 따른 IAM 기능의 흐름도 (1400)이다. 일 실시예에서, 도 14의 흐름도의 기능은 프로세서에 의해 실행되는 메모리 또는 다른 컴퓨터 판독가능한 또는 유형의 매체에 저장된 소프트웨어에 의해 구현된다. 다른 실시예들에서, 기능은 하드웨어 (예를 들어, 애플리케이션 특정 집적 회로 (“ASIC(application specific integrated circuit)”), 프로그램 가능한 게이트 어레이 (“PGA(programmable gate array)”), 필드 프로그램 가능한 게이트 어레이 (“FPGA(field programmable gate array)”), 등의 사용을 통하여) 또는 하드웨어 및 소프트웨어의 임의의 조합에 의해 수행될 수 있다.
(1402)에서, 자원을 액세스하기 위해 유저에 대한 액세스 토큰을 획득하기 위한 요청이 클라이언트로부터 수신된다. 일 실시예에서, 요청은 HTTP 요청이다. 예를 들어, 일 실시예에서, 여러 가지 애플리케이션들/서비스들 (602)이 도 6에 예시된 바와 같이 IDCS 마이크로서비스들(614)을 사용하기 위해서 IDCS API들에 HTTP 호출들을 할 수 있다. 일 실시예에서, 요청은 액세스 토큰을 획득하고 유저를 인증하기 위한 인증 표준을 나타낸다. 일 실시예에서, 인증 표준은 OAuth이다. 일 실시예에서, 클라이언트는 OAuth 클라이언트이다. 일 실시예에서, 토큰은 JWT이다. 일 실시예에서, 자원은 대응하는 테넌트에 의해 소유되고 자원 테넌시에 있는 애플리케이션 또는 데이터이다. 일 실시예에서, 클라이언트는 유저에 의해 사용되는 브라우저이다. 일 실시예에서, 요청은 예를 들어, 도 6에 웹 라우팅 티어 (610) 및/또는 도 7에 클라우드 게이트 (702)를 참고로 하여 본 출원에서 설명된 클라우드 게이트(Cloud Gate)와 같은 보안 게이트에 의해 인증된다.
(1404)에서, 클라이언트의 테넌시, 유저의 테넌시, 및 자원의 테넌시는 요청에 기초하여 결정된다. 일 실시예에서, 요청은 클라이언트의 테넌시를 식별하는 클라이언트 어써션 토큰을 포함한다. 일 실시예에서, 요청은 유저의 테넌시를 식별하는 유저 어써션 토큰을 포함한다. 일 실시예에서, 요청의 헤더는 자원의 테넌시를 나타낸다. 일 예에서, 예를 들어, “테넌트 1”내 클라이언트는 “테넌트 3”내 애플리케이션을 액세스하기 위해 “테넌트 2”내 유저를 위한 액세스 토큰을 요청할 수 있다. 클라이언트는 “http://tenant3/oauth/token”으로 가서 토큰을 위한 OAuth 요청을 인보크함으로써 그렇게 할 수 있다. 클라이언트는 요청에 “클라이언트 어써션”을 포함함으로써 “테넌트 1”에 살아있는 클라이언트로서 그 자체를 식별한다. 클라이언트 어써션은 클라이언트 ID (예를 들어, “클라이언트 1”) 및 클라이언트 테넌시 “테넌트 1”를 포함한다. “테넌트 1”내 “클라이언트 1”으로서, 클라이언트는 “테넌트 3”상에 토큰을 위한 요청을 인보크시킬 권리를 가지며, 클라이언트는 “테넌트 2”내 유저를 위한 토큰을 원한다. 따라서, “유저 어써션”은 동일한 HTTP 요청의 일부로서 또한 패스된다. 생성된 액세스 토큰은 애플리케이션 테넌시 (“테넌트 3”)인 타겟 테넌시의 컨텍스트에서 발행될 것이고 유저 테넌시 (“테넌트 2”)를 포함할 것이다.
일 실시예에서, 클라이언트의 테넌시, 유저의 테넌시, 및 자원의 테넌시는 동일하거나 상이한 테넌시들일 수 있다. 일 실시예에서, 클라이언트의 테넌시, 유저의 테넌시, 및 자원의 테넌시는 적어도 두개는 동일한 테넌시이다. 일 실시예에서, 클라이언트의 테넌시, 유저의 테넌시, 및 자원의 테넌시는 적어도 두개는 상이한 테넌시들이다. 예를 들어, 클라이언트는 제 1 테넌트에 있을 수 있고, 유저는 제 1 테넌트와 다른 제 2 테넌트에 있을 수 있다. 다른 예로서, 클라이언트는 제 1 테넌트에 있을 수 있고, 자원은 제 1 테넌트와 다른 제 2 테넌트에 있을 수 있다. 다른 예로서, 유저는 제 1 테넌트에 있을 수 있고, 자원은 제 1 테넌트와 다른 제 2 테넌트에 있을 수 있다. 다른 예로서, 클라이언트는 제 1 테넌트에 있을 수 있고, 유저는 제 1 테넌트와 다른 제 2 테넌트에 있을 수 있고, 자원은 제 1 및 제 2 테넌트와 다른 제 3 테넌트에 있을 수 있다.
(1406)에서 마이크로서비스는 요청에 기초하여 액세스된다. 일 실시예에서, 마이크로서비스는 다른 모듈들/마이크로서비스들과 대화할 수 있는 자체 완비된 모듈이고, 각각의 마이크로서비스는 다른 것들에 의해 컨택될 수 있는 이름이 없는 범용 포트를 가질 수 있다. 일 실시예에서, 마이크로 서비스는 예를 들어, 도 6에 IDCS 중간 티어 (614)내 마이크로서비스들을 액세스하고 그리고 IDCS “API 플랫폼”를 참고로 하여 본 출원에서 설명된 것처럼 액세스된다.
(1408)에서 아이덴티티 관리 서비스는 요청에 기초하여 마이크로서비스에 의해 수행된다. 일 실시예에서, 아이덴티티 관리 서비스는 자원의 테넌시 및 유저의 테넌시를 식별하는 액세스 토큰을 생성하는 것을 포함한다. 예를 들어, 일 실시예에서, 액세스 토큰은 적어도 액세스 토큰을 위한 요청이 만들어진 시간에 자원 테넌트 이름을 나타내는 클레임 (예를 들어, 고객), 유저 테넌트 이름을 나타내는 클레임, 요청을 만드는 OAuth 클라이언트의 이름을 나타내는 클레임, 및 클라이언트 테넌트 이름을 나타내는 클레임을 포함한다. 일 실시예에서, 액세스 토큰은 이하의 JSON 기능에 따라 구현될 수 있다:
{
…
" tok_type " : "AT",
"user_id" : "testuser",
"user_tenantname" : "<value-of-identity-tenant>"
“tenant” : “<value-of-resource-tenant>
“client_id” : “testclient”,
“client_tenantname”: “<value-of-client-tenant>”
…
}
일 실시예에서, 아이덴티티 관리 서비스는 유저의 인증을 포함한다. 일 실시예에서, 인증은 예를 들어, 도 10을 참고로 하여 본 출원에서 설명된 것처럼 3-각 또는 2-각 플로우를 이용하여 OAuth 표준에 기반될 수 있다. 일 실시예에서, 요청은 본 출원에서 설명된 클라우드 게이트(Cloud Gate)와 같은 보안 게이트에 의해 인증된다.
일 실시예에서, 클라이언트의 테넌시, 유저의 테넌시, 및 자원의 테넌시의 데이터는 데이터 베이스에 저장된다. 일 실시예에서, 데이터베이스 및 마이크로서비스는 서로에 독립적으로 확장하도록 구성된다. 일 실시예에서, 데이터베이스는 분산된 데이터 그리드를 포함한다.
도 15는 실시예에 따른 IAM 기능의 흐름도 (1500)이다. 일 실시예에서, 도 15의 흐름도의 기능은 프로세서에 의해 실행되는 메모리 또는 다른 컴퓨터 판독가능한 또는 유형의 매체에 저장된 소프트웨어에 의해 구현된다. 다른 실시예들에서, 기능은 하드웨어 (예를 들어, 애플리케이션 특정 집적 회로 (“ASIC(application specific integrated circuit)”), 프로그램 가능한 게이트 어레이 (“PGA(programmable gate array)”), 필드 프로그램 가능한 게이트 어레이 (“FPGA(field programmable gate array)”), 등의 사용을 통하여) 또는 하드웨어 및 소프트웨어의 임의의 조합에 의해 수행될 수 있다.
(1502)에서 아이덴티티 관리 서비스를 수행하기 위한 요청이 수신된다. 일 실시예에서, 요청은 아이덴티티 관리 서비스를 수행하도록 구성된 마이크로서비스 및 아이덴티티 관리 서비스를 식별하는 API에 대한 호출을 포함한다. 일 실시예에서, 마이크로서비스는 다른 모듈들/마이크로서비스들과 통신할 수 있는 자체 완비된 모듈이고, 각각의 마이크로서비스는 다른 것들에 의해 컨택될 수 있는 이름이 없는 범용 포트를 가질 수 있다. 예를 들어, 일 실시예에서, 여러 가지 애플리케이션들/서비스들 (602)이 도 6에 예시된 바와 같이 IDCS 마이크로서비스들(614)을 사용하기 위해서 IDCS API들에 HTTP 호출들을 할 수 있다. 일 실시예에서, 마이크로서비스는 런타임 컴포넌트/프로세스이다.
일 실시예에서, 요청은 URL을 포함한다. 일 실시예에서, 마이크로서비스는 URL의 프리픽스(prefix)에 식별된다. 일 실시예에서, URL의 자원 부분은 API를 식별한다. 일 실시예에서, URL의 호스트 부분은 요청에 관련된 자원의 테넌시를 식별한다. 예를 들어, IDCS의 웹 환경에 “host/micrkservice/resource”과 같은 URL에서, 마이크로서비스는 특정 URL 프리픽스, 예를 들어, “host/oauth/v1”를 갖는 것에 의해 특징지어지고 여기서 실제 마이크로서비스는 “oauth/v1”이고, “oauth/v1”아래에는 다수의 API들, 예를 들어, 요청 토큰들에 대한 API: “host/oauth/v1/token”, 유저를 인증시키는 API: “host/oauth/v1/authorize”, 등이 있다. 즉, URL은 마이크로서비스를 구현하고, URL의 자원 부분은 API를 구현한다. 따라서, 다수의 API들이 동일한 마이크로서비스 아래에 종합된다(aggregate). 일 실시예에서, URL의 호스트 부분은 테넌트 (예를 들어, https://tenant3.identity.Oraclecloud.com:/oauth/v1/token”)를 식별한다.
(1504)에서 요청이 인증된다. 일 실시예에서, 요청은 예를 들어, 도 6에 웹 라우팅 티어 (610) 및/또는 도 7에 클라우드 게이트 (702)를 참고로 하여 본 출원에서 설명된 클라우드 게이트(Cloud Gate)와 같은 보안 게이트에 의해 인증된다.
(1506)에서, 마이크로 서비스는 예를 들어, 도 6에 IDCS 중간 티어 (614)내 마이크로서비스들을 액세스하고 그리고 IDCS “API 플랫폼”를 참고로 하여 본 출원에서 설명된 것처럼 API에 기초하여 액세스된다. 일 실시예에서, 마이크로서비스와의 통신은 마이크로서비스의 이름이 없는 범용 포트는 통하여 구성된다. 일 실시예에서, 이름이 없는 마이크로서비스의 범용 포트는 마이크로서비스가 관례(convention) (예를 들어, 통상의 HTTP 포트로서)에 의해 노출되고 동일한 서비스내에 임의의 다른 모듈/마이크로서비스가 그것에 대화하는 것을 허용하는 표준 통신 채널이다. 일 실시예에서, 마이크로서비스(microservice)은 하나 이상의 API들을 노출시킴으로써 하나 이상의 성능들을 제공한다. 일 실시예에서, 마이크로서비스와의 통신은 하나 이상의 API들을 통하여만 구현된다. 즉, 마이크로서비스는 이런 API들에 대한 호출을 함으로써만 도달/컨택될 수 있다. 일 실시예에서, 마이크로서비스와의 통신은 가벼운 프로토콜에 따라 구성된다. 일 실시예에서, 가벼운 프로토콜은 HTTP 및 REST를 포함한다. 일 실시예에서, 요청은 RESTful HTTP API에 대한 호출은 포함한다. 따라서, 일 실시예는 디스패칭 기능(dispatching functionality)을 제공한다. 각각의 HTTP 요청은 includes URI 및 버브를 포함한다. 실시예는 URI로부터 엔드 포인트 (호스트/서비스/자원)를 파싱(parse)하고 적절한 모듈의 적절한 방법을 디스패치(또는 인보크)하기 위해 그것을 HTTP 버스 (예를 들어, POST, PUT, PATCH, 또는 DELETE)와 조합한다. 이 패턴은 REST에 공통이고 다양한 패키지들 (예를 들어, Jersey)에 의해 지원된다.
(1508)에서 아이덴티티 관리 서비스는 예를 들어, 도 6에 IDCS 중간 티어 (614)내 마이크로서비스들을 액세스하고 그리고 IDCS “API 플랫폼”를 참고로 하여 본 출원에서 설명된 것처럼 마이크로서비스에 의해 수행된다. 일 실시예에서, 마이크로서비스는 스테이트리스이고, 수평으로 확장가능하고, 및 독립적으로 배치할 수 있다. 일 실시예에서, 마이크로서비스의 각각의 물리적 구현은 다수의 테넌트들을 안전하게 지원하도록 구성된다. 일 실시예에서, 아이덴티티 관리 서비스는 로그인 서비스, SSO 서비스, 연합 서비스(federation service), 토큰 서비스, 디렉토리 서비스, 프로비저닝 서비스(provisioning service), 또는 RBAC 서비스를 포함한다.
일 실시예에서, 마이크로서비스는 데이터베이스에 저장된 테넌트 데이터에 기초하여 아이덴티티 관리 서비스를 수행한다. 일 실시예에서, 데이터베이스 및 마이크로서비스는 서로에 독립적으로 확장하도록 구성된다. 일 실시예에서, 데이터베이스는 분산된 데이터 그리드를 포함한다.
도 16은 실시예에 따른 IAM 기능의 흐름도 (1600)이다. 일 실시예에서, 도 16의 흐름도의 기능은 프로세서에 의해 실행되는 메모리 또는 다른 컴퓨터 판독가능한 또는 유형의 매체에 저장된 소프트웨어에 의해 구현된다. 다른 실시예들에서, 기능은 하드웨어 (예를 들어, 애플리케이션 특정 집적 회로 (“ASIC(application specific integrated circuit)”), 프로그램 가능한 게이트 어레이 (“PGA(programmable gate array)”), 필드 프로그램 가능한 게이트 어레이 (“FPGA(field programmable gate array)”), 등의 사용을 통하여) 또는 하드웨어 및 소프트웨어의 임의의 조합에 의해 수행될 수 있다.
(1602)에서 아이덴티티 관리 서비스를 수행하기 위한 요청이 수신되고, (1604)에서 마이크로서비스는 아이덴티티 관리 서비스에 기초하여 액세스된다. 일 실시예에서, 마이크로서비스는 다른 모듈들/마이크로서비스들과 통신할 수 있는 자체 완비된 모듈이고, 각각의 마이크로서비스는 다른 것들에 의해 컨택될 수 있는 이름이 없는 범용 포트를 가질 수 있다. 예를 들어, 일 실시예에서, 여러 가지 애플리케이션들/서비스들 (602)이 도 6에 예시된 바와 같이 IDCS 마이크로서비스들(614)을 사용하기 위해서 IDCS API들에 HTTP 호출들을 할 수 있다. 일 실시예에서, 서비스는 로그인 서비스, SSO 서비스, 연합 서비스(federation service), 토큰 서비스, 디렉토리 서비스, 프로비저닝 서비스(provisioning service), 또는 RBAC 서비스이다.
(1606)에서 아이덴티티 관리 서비스를 완료하기 위해 실행될 것이 요구되는 하나 이상의 실시간 태스크들 및 하나 이상의 근-실시간 태스크들은 예를 들어, “실시간 및 근-실시간 태스크들”를 참고로 하여 본 출원에서 설명된 대로 결정된다. 일 실시예에서, 아이덴티티 관리 서비스는 유저를 인증하는 것을 포함하고 하나 이상의 실시간 태스크들은 유저의 자격들을 확인하고 대응하는 세션을 시작하는 것을 포함한다. 일 실시예에서, 하나 이상의 근-실시간 태스크들은 적어도 하나의 감사 또는 통지들을 포함한다. 일 실시예에서, 요청은 예를 들어, 도 6에 웹 라우팅 티어 (610) 및/또는 도 7에 클라우드 게이트 (702)를 참고로 하여 본 출원에서 설명된 클라우드 게이트(Cloud Gate)와 같은 보안 게이트에 의해 인증된다.
(1608)에서 하나 이상의 실시간 태스크들은 마이크로서비스 (도 6에 마이크로서비스들 (614))에 의해 동기식으로 실행되고, (1610)에서 하나 이상의 근-실시간 태스크들은 비동기식으로 실행되도록 큐 (예를 들어, 도 6에 메시지 큐 (628))로 발송된다. 일 실시예에서, 태스크를 동기식으로 실행하는 것은 다른 태스크의 실행을 시작하기 전에 태스크의 실행이 끝나기를 기다리는 것을 지칭한다. 일 실시예에서, 태스크를 비동기식으로 실행하는 것은 앞에 태스크가 실행이 끝나기 전에 다른 태스크의 실행을 시작하는 것을 허용하는 것을 지칭한다 (예를 들어, 앞에 태스크는 쓰레드(thread)로 실행 중인 동안에, 다른 쓰레드상에 다른 태스크 또는 프로세스를 시작하는 것). 일 실시예에서, 큐는 보장된 전달 및 프로세싱으로 크게 확장가능한 비동기식 이벤트 관리 시스템을 구현하는 메시지 큐 (예를 들어, 도 6에 메시지 큐 (628))이다. 일 실시예에서, 아이덴티티 관리 태스크는 유저가 자원 액세스를 계속 하는 것을 허용하는 것이 요청된다. 일 실시예에서, 유저는 제 1 셋의 서브태스크들이 완료된 때 그리고 제 2 셋의 서브태스크들이 완료되기 전에 계속 자원들 액세스하는 것이 허용된다.
일 실시예에서, 어느 태스크들이 요청의 일부로서 동기식으로 실행될 것인지 그리고 어느 태스크들이 비동기식으로 실행될 것인지에 관한 결정은 런-타임(run-time)에서가 아니라 디자인-시간(design-time)에서 이루어진다. 런-타임에서 실시예는 특정 값들을 갖는 코드를 실행시키지만 (예를 들어, 특정 유저의 생성을 레코딩하는 이벤트들을 발신하거나 또는 특정 유저를 생성하기 위해), 특정 태스크가 동기식 또는 비동기식인지 여부를 런-타임에서 결정하지 않는다. 일 실시예에서, 예를 들어, IDCS가 새로운 유저를 등록하거나 생성하기 위한 요청을 수신한 때, 대응하는 마이크로서비스는 동작 데이터베이스 (도 6에 글로벌 데이터베이스 (620)에 위치된)내 구성 데이터를 면밀히 살펴서 “유저 생성(create user)” 동작이 비동기식 동작으로 구성 데이터에 식별된 “유저 생성(create user)” 이벤트로 마킹된 지를 결정한다. 마이크로서비스는 유저의 생성이 성공적으로 수행되었지만, 그러나 통지 이메일의 실제 발송은 연기되고 백엔드로 푸시된다는 것을 표시하고 클라이언트에 리턴한다. 그렇게 하기 위해서, 마이크로서비스는 저장소인 큐 (628)에 메시지를 큐잉(queue)하는 메시징 API (616)를 사용한다.
일 실시예에서, 마이크로서비스는 스테이트리스(stateless)이다. 일 실시예에서, 마이크로서비스는 데이터베이스에 저장된 테넌트 데이터에 기초하여 아이덴티티 관리 서비스를 수행한다. 일 실시예에서, 데이터베이스 및 마이크로서비스는 서로에 독립적으로 확장하도록 구성된다. 일 실시예에서, 데이터베이스는 분산된 데이터 그리드를 포함한다.
몇몇 실시예들이 본 출원에 구체적으로 예시되고 및/또는 설명된다. 그러나, 개시된 실시예들의 수정예들 및 변형예들은 발명의 취지 및 의도된 범위에서 벗어나지 않고서 첨부된 청구항들의 이해의 범위내에서 그리고 상기의 교리들에 의해 커버된다는 것이 인식될 것이다.

Claims (20)

  1. 프로세서에 의해 실행될 때, 상기 프로세서로 하여금 클라우드기반의 아이덴티티 및 액세스 관리를 제공하게 하는 저장된 명령들을 갖는 비-일시적 컴퓨터 판독가능한 매체에 있어서, 상기 프로세서는:
    자원을 액세스하기 위해 유저에 대한 액세스 토큰을 획득하기 위한 요청을 클라이언트로부터 수신하고;
    상기 요청에 기초하여, 상기 클라이언트의 테넌시, 상기 유저의 테넌시, 및 상기 자원의 테넌시를 결정하고;
    상기 요청에 기초하여 마이크로서비스를 액세스하고; 및
    상기 요청에 기초하여 상기 마이크로서비스에 의해 아이덴티티 관리 서비스를 수행하고, 상기 아이덴티티 관리 서비스는 상기 자원의 테넌시 및 상기 유저의 테넌시를 식별하는 상기 액세스 토큰을 생성하는 것을 포함하는, 컴퓨터 판독가능한 매체.
  2. 청구항 1에 있어서, 상기 클라이언트의 테넌시, 상기 유저의 테넌시, 및 상기 자원의 테넌시 중 적어도 두개는 동일한 테넌시인, 컴퓨터 판독가능한 매체.
  3. 청구항 1에 있어서, 상기 클라이언트의 테넌시, 상기 유저의 테넌시, 및 상기 자원의 테넌시 중 적어도 두개는 상이한 테넌시들인, 컴퓨터 판독가능한 매체.
  4. 청구항 1에 있어서, 상기 요청은 상기 클라이언트의 테넌시를 식별하는 클라이언트 어써션 토큰(client assertion token)을 포함하는, 컴퓨터 판독가능한 매체.
  5. 청구항 1에 있어서, 상기 요청은 상기 유저의 테넌시를 식별하는 유저 어써션 토큰(user assertion token)을 포함하는, 컴퓨터 판독가능한 매체.
  6. 청구항 1에 있어서, 상기 요청의 헤더는 상기 자원의 테넌시를 나타내는, 컴퓨터 판독가능한 매체.
  7. 청구항 1에 있어서, 상기 요청은 HTTP(Hypertext Transfer Protocol) 요청인, 컴퓨터 판독가능한 매체.
  8. 청구항 1에 있어서, 상기 요청은 액세스 토큰을 획득하고 상기 유저를 인증하기 위한 인증 표준(authorization standard)을 나타내는, 컴퓨터 판독가능한 매체.
  9. 청구항 8에 있어서, 상기 인증 표준은 OAuth인, 컴퓨터 판독가능한 매체.
  10. 청구항 9에 있어서, 상기 클라이언트는 OAuth 클라이언트인, 컴퓨터 판독가능한 매체.
  11. 청구항 1에 있어서, 상기 토큰은 JSON(JavaScript Object Notation) Web Token (JWT)인, 컴퓨터 판독가능한 매체.
  12. 청구항 1에 있어서, 상기 클라이언트의 테넌시, 상기 유저의 테넌시, 및 상기 자원의 테넌시의 데이터는 데이터베이스에 저장되고, 상기 데이터베이스 및 상기 마이크로서비스는 서로에 독립적으로 확장하도록 구성된, 컴퓨터 판독가능한 매체.
  13. 청구항 12에 있어서, 상기 데이터베이스는 분산된 데이터 그리드를 포함하는, 컴퓨터 판독가능한 매체.
  14. 클라우드기반의 아이덴티티 및 액세스 관리를 제공하는 방법에 있어서,
    자원을 액세스하기 위해 유저에 대한 액세스 토큰을 획득하기 위한 요청을 클라이언트로부터 수신하는 단계;
    상기 요청에 기초하여, 상기 클라이언트의 테넌시, 상기 유저의 테넌시, 및 상기 자원의 테넌시를 결정하는 단계;
    상기 요청에 기초하여 마이크로서비스를 액세스하는 단계; 및
    상기 요청에 기초하여 상기 마이크로서비스에 의해 아이덴티티 관리 서비스를 수행하는 단계를 포함하되, 상기 아이덴티티 관리 서비스는 상기 자원의 테넌시 및 상기 유저의 테넌시를 식별하는 상기 액세스 토큰을 생성하는 것을 포함하는, 방법.
  15. 청구항 14에 있어서, 상기 클라이언트의 테넌시, 상기 유저의 테넌시, 및 상기 자원의 테넌시 중 적어도 두개는 동일한 테넌시인, 방법.
  16. 청구항 14에 있어서, 상기 클라이언트의 테넌시, 상기 유저의 테넌시, 및 상기 자원의 테넌시 중 적어도 두개는 상이한 테넌시들인, 방법.
  17. 청구항 14에 있어서, 상기 요청은 상기 클라이언트의 테넌시를 식별하는 클라이언트 어써션 토큰을 포함하는, 방법.
  18. 청구항 14에 있어서, 상기 요청은 상기 유저의 테넌시를 식별하는 유저 어써션 토큰(user assertion token)을 포함하는, 방법.
  19. 청구항 14에 있어서, 상기 요청의 헤더는 상기 자원의 테넌시를 나타내는, 방법.
  20. 클라우드기반의 아이덴티티 및 액세스 관리를 제공하기 위한 시스템에 있어서,
    자원을 액세스하기 위해 유저에 대한 액세스 토큰을 획득하기 위한 요청을 클라이언트로부터 수신하는 수신 모듈;
    상기 요청에 기초하여, 상기 클라이언트의 테넌시, 상기 유저의 테넌시, 및 상기 자원의 테넌시를 결정하는 결정 모듈;
    상기 요청에 기초하여 마이크로서비스를 액세스하는 액세스 모듈; 및
    상기 요청에 기초하여 상기 마이크로서비스에 의해 아이덴티티 관리 서비스를 수행하는 수행 모듈(performing module)을 포함하되, 상기 아이덴티티 관리 서비스는 상기 자원의 테넌시 및 상기 유저의 테넌시를 식별하는 상기 액세스 토큰을 생성하는 것을 포함하는, 시스템.
KR1020187004762A 2016-05-11 2017-05-09 멀티-테넌트 아이덴티티 및 데이터 보안 관리 클라우드 서비스 KR102041941B1 (ko)

Applications Claiming Priority (23)

Application Number Priority Date Filing Date Title
US201662334645P 2016-05-11 2016-05-11
US62/334,645 2016-05-11
US201662371336P 2016-08-05 2016-08-05
US62/371,336 2016-08-05
US201662376069P 2016-08-17 2016-08-17
US62/376,069 2016-08-17
US201662395501P 2016-09-16 2016-09-16
US201662395479P 2016-09-16 2016-09-16
US201662395463P 2016-09-16 2016-09-16
US62/395,479 2016-09-16
US62/395,463 2016-09-16
US62/395,501 2016-09-16
US201662434501P 2016-12-15 2016-12-15
US62/434,501 2016-12-15
US15/450,550 US9838377B1 (en) 2016-05-11 2017-03-06 Task segregation in a multi-tenant identity and data security management cloud service
US15/450,512 2017-03-06
US15/450,550 2017-03-06
US15/450,512 US9838376B1 (en) 2016-05-11 2017-03-06 Microservices based multi-tenant identity and data security management cloud service
US15/469,718 US10341410B2 (en) 2016-05-11 2017-03-27 Security tokens for a multi-tenant identity and data security management cloud service
US15/469,718 2017-03-27
US15/485,532 2017-04-12
US15/485,532 US9781122B1 (en) 2016-05-11 2017-04-12 Multi-tenant identity and data security management cloud service
PCT/US2017/031649 WO2017196774A1 (en) 2016-05-11 2017-05-09 Multi-tenant identity and data security management cloud service

Related Parent Applications (1)

Application Number Title Priority Date Filing Date
KR1020187000420A Division KR101871902B1 (ko) 2016-05-11 2017-05-09 멀티-테넌트 아이덴티티 및 데이터 보안 관리 클라우드 서비스

Publications (2)

Publication Number Publication Date
KR20180027597A true KR20180027597A (ko) 2018-03-14
KR102041941B1 KR102041941B1 (ko) 2019-11-07

Family

ID=61387621

Family Applications (4)

Application Number Title Priority Date Filing Date
KR1020187004762A KR102041941B1 (ko) 2016-05-11 2017-05-09 멀티-테넌트 아이덴티티 및 데이터 보안 관리 클라우드 서비스
KR1020187000420A KR101871902B1 (ko) 2016-05-11 2017-05-09 멀티-테넌트 아이덴티티 및 데이터 보안 관리 클라우드 서비스
KR1020187004764A KR101873941B1 (ko) 2016-05-11 2017-05-09 멀티-테넌트 아이덴티티 및 데이터 보안 관리 클라우드 서비스
KR1020187004763A KR101874384B1 (ko) 2016-05-11 2017-05-09 멀티-테넌트 아이덴티티 및 데이터 보안 관리 클라우드 서비스

Family Applications After (3)

Application Number Title Priority Date Filing Date
KR1020187000420A KR101871902B1 (ko) 2016-05-11 2017-05-09 멀티-테넌트 아이덴티티 및 데이터 보안 관리 클라우드 서비스
KR1020187004764A KR101873941B1 (ko) 2016-05-11 2017-05-09 멀티-테넌트 아이덴티티 및 데이터 보안 관리 클라우드 서비스
KR1020187004763A KR101874384B1 (ko) 2016-05-11 2017-05-09 멀티-테넌트 아이덴티티 및 데이터 보안 관리 클라우드 서비스

Country Status (4)

Country Link
EP (4) EP3311548B1 (ko)
JP (4) JP6491796B2 (ko)
KR (4) KR102041941B1 (ko)
CN (4) CN108322472B (ko)

Families Citing this family (91)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10484382B2 (en) 2016-08-31 2019-11-19 Oracle International Corporation Data management for a multi-tenant identity cloud service
US10846390B2 (en) 2016-09-14 2020-11-24 Oracle International Corporation Single sign-on functionality for a multi-tenant identity and data security management cloud service
US10511589B2 (en) 2016-09-14 2019-12-17 Oracle International Corporation Single logout functionality for a multi-tenant identity and data security management cloud service
US10594684B2 (en) 2016-09-14 2020-03-17 Oracle International Corporation Generating derived credentials for a multi-tenant identity cloud service
US10484243B2 (en) 2016-09-16 2019-11-19 Oracle International Corporation Application management for a multi-tenant identity cloud service
WO2018053258A1 (en) 2016-09-16 2018-03-22 Oracle International Corporation Tenant and service management for a multi-tenant identity and data security management cloud service
US10445395B2 (en) 2016-09-16 2019-10-15 Oracle International Corporation Cookie based state propagation for a multi-tenant identity cloud service
US10904074B2 (en) 2016-09-17 2021-01-26 Oracle International Corporation Composite event handler for a multi-tenant identity cloud service
CN108416679B (zh) * 2017-06-07 2022-02-08 平安科技（深圳）有限公司 多保险产品出单的装置、方法及计算机可读存储介质
US10831789B2 (en) 2017-09-27 2020-11-10 Oracle International Corporation Reference attribute query processing for a multi-tenant cloud service
US10705823B2 (en) 2017-09-29 2020-07-07 Oracle International Corporation Application templates and upgrade framework for a multi-tenant identity cloud service
JP7391862B2 (ja) 2017-12-08 2023-12-05 ネット－サンダー，エル・エル・シー 自動的に配備される情報技術（ｉｔ）システム及び方法
US10715564B2 (en) 2018-01-29 2020-07-14 Oracle International Corporation Dynamic client registration for an identity cloud service
US10931656B2 (en) * 2018-03-27 2021-02-23 Oracle International Corporation Cross-region trust for a multi-tenant identity cloud service
US11165634B2 (en) * 2018-04-02 2021-11-02 Oracle International Corporation Data replication conflict detection and resolution for a multi-tenant identity cloud service
US10798165B2 (en) 2018-04-02 2020-10-06 Oracle International Corporation Tenant data comparison for a multi-tenant identity cloud service
US11258775B2 (en) * 2018-04-04 2022-02-22 Oracle International Corporation Local write for a multi-tenant identity cloud service
KR102164040B1 (ko) * 2018-04-16 2020-10-12 (주) 영림원소프트랩 클라우드 기반 전사적 자원 관리 시스템과 외부 시스템 간의 양방향 연동을 위한 마이크로 서비스 아키텍처 기반 open api 허브 시스템
KR102093145B1 (ko) * 2018-06-07 2020-03-25 한밭대학교 산학협력단 생체정보 인식 기반의 데이터 최적화를 위한 오브젝트 스토리지 클라우드 시스템
CN110647575B (zh) * 2018-06-08 2022-03-11 成都信息工程大学 基于分布式的异构处理框架构建方法及系统
US20210342907A1 (en) * 2018-06-15 2021-11-04 Paypal, Inc. Multi-Tenant Dispute Services
US11030329B2 (en) * 2018-06-15 2021-06-08 Paypal, Inc. Unified identity services for multi-tenant architectures
US11012444B2 (en) * 2018-06-25 2021-05-18 Oracle International Corporation Declarative third party identity provider integration for a multi-tenant identity cloud service
US10764273B2 (en) 2018-06-28 2020-09-01 Oracle International Corporation Session synchronization across multiple devices in an identity cloud service
US10635825B2 (en) * 2018-07-11 2020-04-28 International Business Machines Corporation Data privacy awareness in workload provisioning
CN109033805B (zh) * 2018-09-30 2023-05-19 山东电工电气集团新能科技有限公司 带微服务授权认证功能的智能配电终端及授权认证方法
EP3864795A4 (en) * 2018-10-10 2022-05-11 Alibaba Group Holding Limited AUTHENTICATION AND AUTHORIZATION FOR A CLOUD FILE SYSTEM
US11321187B2 (en) 2018-10-19 2022-05-03 Oracle International Corporation Assured lazy rollback for a multi-tenant identity cloud service
CN109495559B (zh) * 2018-11-06 2022-02-22 用友网络科技股份有限公司 微服务客户端的服务注册及调用方法、注册及调用系统
WO2020104839A1 (en) * 2018-11-23 2020-05-28 Pratik Sharma Data triggers in microservices architecture
CN109344206B (zh) * 2018-12-03 2021-07-16 天津电气科学研究院有限公司 一种基于查询推理的olap元数据冲突的自动修复方法
US11057434B2 (en) * 2018-12-05 2021-07-06 International Business Machines Corporation High performance access control
CN109714319A (zh) * 2018-12-06 2019-05-03 深圳市中农网有限公司 微服务的管理系统、方法、装置、计算机设备及存储介质
US10963324B2 (en) * 2018-12-12 2021-03-30 Citrix Systems, Inc. Predictive microservice systems and methods
WO2020140126A1 (en) * 2018-12-28 2020-07-02 Paypal, Inc. Multi-tenant dispute services
US11061929B2 (en) 2019-02-08 2021-07-13 Oracle International Corporation Replication of resource type and schema metadata for a multi-tenant identity cloud service
KR102027749B1 (ko) * 2019-02-08 2019-10-02 아콘소프트 주식회사 마이크로서비스 시스템 및 방법
KR102050188B1 (ko) * 2019-02-08 2019-11-28 아콘소프트 주식회사 마이크로서비스 시스템 및 방법
US11321343B2 (en) 2019-02-19 2022-05-03 Oracle International Corporation Tenant replication bootstrap for a multi-tenant identity cloud service
US11669321B2 (en) 2019-02-20 2023-06-06 Oracle International Corporation Automated database upgrade for a multi-tenant identity cloud service
US11423111B2 (en) 2019-02-25 2022-08-23 Oracle International Corporation Client API for rest based endpoints for a multi-tenant identify cloud service
US11792226B2 (en) 2019-02-25 2023-10-17 Oracle International Corporation Automatic api document generation from scim metadata
US10796276B1 (en) * 2019-04-11 2020-10-06 Caastle, Inc. Systems and methods for electronic platform for transactions of wearable items
US20220222363A1 (en) * 2019-05-09 2022-07-14 Schlumberger Technology Corporation Client isolation with native cloud features
JP2022536706A (ja) * 2019-06-11 2022-08-18 ネット－サンダー，エル・エル・シー セキュリティが強化された自動的に配備される情報技術（ｉｔ）システム及び方法
US10764244B1 (en) * 2019-06-12 2020-09-01 Cisco Technology, Inc. Systems and methods providing a multi-cloud microservices gateway using a sidecar proxy
US11516254B2 (en) * 2019-06-20 2022-11-29 Juniper Networks, Inc. Controlling access to microservices within a multi-tenancy framework
CN110535851A (zh) * 2019-08-27 2019-12-03 浪潮云信息技术有限公司 一种基于oauth2协议的用户认证系统
US11748206B2 (en) * 2019-08-28 2023-09-05 International Business Machines Corporation Data recovery modification based on performance data exhibited by a network of data centers and data recovery requirement
US11687378B2 (en) * 2019-09-13 2023-06-27 Oracle International Corporation Multi-tenant identity cloud service with on-premise authentication integration and bridge high availability
US11870770B2 (en) 2019-09-13 2024-01-09 Oracle International Corporation Multi-tenant identity cloud service with on-premise authentication integration
CN110581897A (zh) * 2019-09-30 2019-12-17 山东浪潮通软信息科技有限公司 一种单向网络环境下实现两个系统之间数据交互的方法
JP7426636B2 (ja) * 2019-10-26 2024-02-02 ミミック・テクノロジー・インコーポレイテッド 分散型エッジクラウドコンピューティングのための方法およびシステム
US10628244B1 (en) * 2019-10-29 2020-04-21 Snowflake Inc. Calling external functions from a data warehouse
KR102432807B1 (ko) * 2019-11-18 2022-08-16 한국전자통신연구원 마이크로서비스 구조 재구성 방법 및 장치
CN111008015B (zh) * 2019-11-22 2023-07-04 广联达科技股份有限公司 一种基于前端技术实现的微前端应用框架
US11507627B2 (en) * 2019-12-19 2022-11-22 Sap Se Analytics content network for content delivery embedding
CN113127821A (zh) * 2019-12-31 2021-07-16 远景智能国际私人投资有限公司 身份验证方法、装置、电子设备及存储介质
CN111241504B (zh) * 2020-01-16 2024-01-05 远景智能国际私人投资有限公司 身份验证方法、装置、电子设备及存储介质
US11501010B2 (en) * 2020-05-20 2022-11-15 Snowflake Inc. Application-provisioning framework for database platforms
CN111610987B (zh) * 2020-05-25 2021-11-05 北京邮电大学 一种基于微服务的数据处理系统和方法
CN111741079A (zh) * 2020-06-01 2020-10-02 广西电网有限责任公司电力科学研究院 一种基于微服务架构的接口处理方法及系统
CN111694857B (zh) * 2020-06-12 2023-11-07 北京百度网讯科技有限公司 存储资源数据的方法、装置、电子设备及计算机可读介质
CN111831874B (zh) * 2020-07-16 2022-08-19 深圳赛安特技术服务有限公司 网页数据信息获取方法、装置、计算机设备及存储介质
CN111953562B (zh) * 2020-07-29 2022-05-24 新华三信息安全技术有限公司 一种设备状态监控方法及装置
US11470159B2 (en) 2020-08-28 2022-10-11 Cisco Technology, Inc. API key security posture scoring for microservices to determine microservice security risks
CN112087520B (zh) * 2020-09-14 2023-08-22 深圳市欣视景科技股份有限公司 数据处理方法、装置、设备及计算机可读存储介质
CN112149079A (zh) * 2020-10-22 2020-12-29 国网冀北电力有限公司经济技术研究院 基于微服务架构的规划评审管理平台及用户访问授权方法
CN112699411B (zh) * 2021-01-04 2024-04-09 北京金山云网络技术有限公司 操作审计信息的存储方法、装置和计算机可读存储介质
CN112769947A (zh) * 2021-01-20 2021-05-07 浪潮云信息技术股份公司 一种基于租户侧容器集群管理微服务引擎实例的方法
US11757645B2 (en) * 2021-01-26 2023-09-12 Sap Se Single-use authorization codes in self-contained format
CN113014847B (zh) * 2021-01-27 2023-06-06 广州佰锐网络科技有限公司 一种基于混合云架构实现音视频通信的方法及系统
CN113254146A (zh) * 2021-04-25 2021-08-13 西安电子科技大学 云平台服务信任值计算、任务调度与负载均衡系统、方法
CN113296798B (zh) * 2021-05-31 2022-04-15 腾讯科技（深圳）有限公司 一种服务部署方法、装置及可读存储介质
CN113542238B (zh) * 2021-06-29 2023-06-16 上海派拉软件股份有限公司 一种基于零信任的风险判定方法及系统
CN113467891B (zh) * 2021-07-12 2022-03-15 腾讯科技（深圳）有限公司 服务处理方法、装置及存储介质
KR102606911B1 (ko) * 2021-09-13 2023-11-29 주식회사 위버스컴퍼니 Api 서버로 인입되는 트래픽을 조절하는 방법 및 시스템
US11785082B2 (en) 2021-09-30 2023-10-10 Oracle International Corporation Domain replication across regions
CN116028938A (zh) * 2021-10-27 2023-04-28 中移(苏州)软件技术有限公司 提供安全服务的方法及装置、电子设备及计算机存储介质
CN114024751B (zh) * 2021-11-05 2023-05-23 抖音视界有限公司 一种应用访问控制方法、装置、计算机设备及存储介质
US11528279B1 (en) 2021-11-12 2022-12-13 Netskope, Inc. Automatic user directory synchronization and troubleshooting
CN114124571A (zh) * 2021-12-09 2022-03-01 上海甄云信息科技有限公司 一种多路对接的单点登录方法及系统
CN114338682A (zh) * 2021-12-24 2022-04-12 北京字节跳动网络技术有限公司 流量身份标识传递方法、装置、电子设备及存储介质
CN114499977B (zh) * 2021-12-28 2023-08-08 天翼云科技有限公司 一种认证方法及装置
WO2023141506A1 (en) * 2022-01-19 2023-07-27 Commscope Technologies Llc System and method of cloud based congestion control for virtualized base station
CN114721845A (zh) * 2022-04-14 2022-07-08 广州有信科技有限公司 一种多租户RestfulAPI接口管理方法及装置
WO2023219773A1 (en) * 2022-05-09 2023-11-16 Oracle International Corporation Remote cloud function invocation service
US20240045980A1 (en) * 2022-08-04 2024-02-08 Getac Technology Corporation Maintaining data security in a multi-tenant microservice environment
US11985058B2 (en) 2022-08-04 2024-05-14 Getac Technology Corporation Interservice communication optimization for microservices
KR102640624B1 (ko) * 2023-05-26 2024-02-23 박만성 자금세탁방지(AML) 서비스를 제공하기 위한 클라우드 기반 SaaS형 자금세탁방지 시스템
CN117176379B (zh) * 2023-06-25 2024-02-09 广东电网有限责任公司佛山供电局 一种基于微服务架构的非结构化数据共享方法及装置

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20120110650A1 (en) * 2010-06-15 2012-05-03 Van Biljon Willem Robert Organizing Permission Associated with a Cloud Customer in a Virtual Computing Infrastructure
US20140090037A1 (en) * 2012-09-21 2014-03-27 Intuit Inc. Single sign-on in multi-tenant environments
US20160124742A1 (en) * 2014-10-30 2016-05-05 Equinix, Inc. Microservice-based application development framework

Family Cites Families (34)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2004302534A (ja) * 2003-03-28 2004-10-28 Nri & Ncc Co Ltd ＷｅｂサービスシステムとＷｅｂサービスシステムのデータ送信処理方法
US20070112574A1 (en) * 2003-08-05 2007-05-17 Greene William S System and method for use of mobile policy agents and local services, within a geographically distributed service grid, to provide greater security via local intelligence and life-cycle management for RFlD tagged items
JP2008027043A (ja) * 2006-07-19 2008-02-07 Gaiax Co Ltd ウェブサイト管理システム、ウェブサイト管理方法、ウェブサイト管理プログラムおよび該プログラムを記録した記録媒体
JP5176301B2 (ja) * 2006-09-25 2013-04-03 大日本印刷株式会社 Ｗｅｂアプリケーション接続管理システム、Ｗｅｂサーバ、Ｗｅｂアプリケーション接続管理方法、プログラム、及び記録媒体
KR101094051B1 (ko) * 2007-08-23 2011-12-19 후지쯔 가부시끼가이샤 생체 인증 시스템 및 컴퓨터 판독 가능한 기록 매체
CN101399813B (zh) * 2007-09-24 2011-08-17 中国移动通信集团公司 身份联合方法
US8417723B1 (en) 2008-09-12 2013-04-09 Salesforce.Com, Inc. System, method and computer program product for enabling access to a resource of a multi-tenant on-demand database service utilizing a token
US8271536B2 (en) 2008-11-14 2012-09-18 Microsoft Corporation Multi-tenancy using suite of authorization manager components
JP5085605B2 (ja) * 2009-05-08 2012-11-28 ヤフー株式会社 ログインを管理するサーバ、方法、およびプログラム
US8392969B1 (en) 2009-06-17 2013-03-05 Intuit Inc. Method and apparatus for hosting multiple tenants in the same database securely and with a variety of access modes
JP2011141785A (ja) * 2010-01-08 2011-07-21 Girunetto Kk 携帯端末を用いた会員登録システム及び認証システム
JP2012234354A (ja) * 2011-04-28 2012-11-29 Nippon Telegr & Teleph Corp <Ntt> データベース増設方法、及びデータベース減設方法
JP5930847B2 (ja) 2011-06-29 2016-06-08 キヤノン株式会社 サーバーシステムおよび制御方法およびプログラム
JP5744656B2 (ja) * 2011-07-15 2015-07-08 キヤノン株式会社 シングルサインオンを提供するシステムおよびその制御方法、サービス提供装置、中継装置、並びにプログラム
US9578014B2 (en) 2011-09-29 2017-02-21 Oracle International Corporation Service profile-specific token attributes and resource server token attribute overriding
WO2013071087A1 (en) * 2011-11-09 2013-05-16 Unisys Corporation Single sign on for cloud
US9087322B1 (en) 2011-12-22 2015-07-21 Emc Corporation Adapting service provider products for multi-tenancy using tenant-specific service composition functions
JP5773910B2 (ja) * 2012-02-29 2015-09-02 三菱電機株式会社 アクセス制御装置及びアクセス制御方法及びプログラム
US9148429B2 (en) 2012-04-23 2015-09-29 Google Inc. Controlling access by web applications to resources on servers
US9621435B2 (en) * 2012-09-07 2017-04-11 Oracle International Corporation Declarative and extensible model for provisioning of cloud based services
US9535863B2 (en) * 2012-09-07 2017-01-03 Oracle International Corporation System and method for supporting message pre-processing in a distributed data grid cluster
US9542546B2 (en) 2012-09-28 2017-01-10 Volusion, Inc. System and method for implicitly resolving query scope in a multi-client and multi-tenant datastore
CN103780635B (zh) * 2012-10-17 2017-08-18 百度在线网络技术（北京）有限公司 云环境中的分布式异步任务队列执行系统和方法
EP2765529B1 (en) 2013-02-12 2021-11-17 Canon Europa N.V. A method of authenticating a user of a peripheral apparatus, a peripheral apparatus, and a system for authenticating a user of a peripheral apparatus
US9251178B2 (en) * 2013-04-26 2016-02-02 Oracle International Corporation System and method for connection labeling for use with connection pools
US9411973B2 (en) 2013-05-02 2016-08-09 International Business Machines Corporation Secure isolation of tenant resources in a multi-tenant storage system using a security gateway
JP6245949B2 (ja) 2013-11-11 2017-12-13 キヤノン株式会社 認可サーバーシステム、その制御方法、およびそのプログラム。
EP3097486A4 (en) 2014-01-20 2018-04-04 Hewlett-Packard Development Company, L.P. Determining a permission of a first tenant with respect to a second tenant
JP2016009299A (ja) * 2014-06-24 2016-01-18 キヤノン株式会社 シングルサインオンシステム、端末装置、制御方法およびコンピュータプログラム
US10664495B2 (en) 2014-09-25 2020-05-26 Oracle International Corporation System and method for supporting data grid snapshot and federation
WO2016065080A1 (en) * 2014-10-21 2016-04-28 Twilio, Inc. System and method for providing a miro-services communication platform
JP2016085641A (ja) 2014-10-27 2016-05-19 キヤノン株式会社 権限移譲システム、権限移譲システムにて実行される方法、およびそのプログラム
CN105515759B (zh) * 2015-11-27 2018-11-09 国网信息通信产业集团有限公司 一种微服务注册方法及系统
CN105577665B (zh) * 2015-12-24 2019-06-18 西安电子科技大学 一种云环境下的身份和访问控制管理系统及方法

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20120110650A1 (en) * 2010-06-15 2012-05-03 Van Biljon Willem Robert Organizing Permission Associated with a Cloud Customer in a Virtual Computing Infrastructure
US20140090037A1 (en) * 2012-09-21 2014-03-27 Intuit Inc. Single sign-on in multi-tenant environments
US20160124742A1 (en) * 2014-10-30 2016-05-05 Equinix, Inc. Microservice-based application development framework

Also Published As

Publication number Publication date
CN108322472B (zh) 2019-06-25
KR20180029073A (ko) 2018-03-19
EP3311548B1 (en) 2019-04-10
CN108322471A (zh) 2018-07-24
JP2018156658A (ja) 2018-10-04
EP3361702B1 (en) 2019-10-23
KR102041941B1 (ko) 2019-11-07
CN108337260B (zh) 2019-04-23
KR20180028520A (ko) 2018-03-16
EP3361700B1 (en) 2021-08-04
CN108322472A (zh) 2018-07-24
KR101874384B1 (ko) 2018-07-04
JP6491381B2 (ja) 2019-03-27
CN107852417A (zh) 2018-03-27
EP3361702A1 (en) 2018-08-15
CN108337260A (zh) 2018-07-27
JP2018142333A (ja) 2018-09-13
EP3361701A1 (en) 2018-08-15
JP2018534653A (ja) 2018-11-22
CN108322471B (zh) 2019-04-23
KR20180016731A (ko) 2018-02-19
EP3311548A1 (en) 2018-04-25
EP3361701B1 (en) 2021-09-01
KR101873941B1 (ko) 2018-07-03
JP2018142332A (ja) 2018-09-13
EP3361700A1 (en) 2018-08-15
JP6491774B2 (ja) 2019-03-27
KR101871902B1 (ko) 2018-06-27
JP6917331B2 (ja) 2021-08-11
CN107852417B (zh) 2021-04-20
JP6491796B2 (ja) 2019-03-27

Similar Documents

Publication Publication Date Title
KR101874384B1 (ko) 멀티-테넌트 아이덴티티 및 데이터 보안 관리 클라우드 서비스
EP3566419B1 (en) Multi-tenant identity cloud service to allow a client to access resources in a remote region after receiving a token from a home region
EP3577885B1 (en) Tenant data comparison for replicating data in a multi-tenant identity cloud service based on json objects
EP3777077B1 (en) Local write for a multi-tenant identity cloud service
EP3513542B1 (en) Tenant and service management for a multi-tenant identity and data security management cloud service
US20180097802A1 (en) Microservices based multi-tenant identity and data security management cloud service
US20190238598A1 (en) Dynamic client registration for an identity cloud service
EP3811257A1 (en) Declarative third party identity provider integration for a multi-tenant identity cloud service
EP3841726A1 (en) Multi-tenant identity cloud service with on-premise authentication integration
JP2019532368A (ja) マルチテナントアイデンティティクラウドサービスのためのデータ管理
WO2017196774A1 (en) Multi-tenant identity and data security management cloud service
WO2021050306A1 (en) Multi-tenant identity cloud service with on-premise authentication integration and bridge high availability
US11693835B2 (en) Dynamic database schema allocation on tenant onboarding for a multi-tenant identity cloud service

Legal Events

Date Code Title Description
A107 Divisional application of patent
A201 Request for examination
E902 Notification of reason for refusal
E701 Decision to grant or registration of patent right