JP6033990B2 - 単一のフレキシブルかつプラガブルＯＡｕｔｈサーバを備える複数のリソースサーバ、ＯＡｕｔｈ保護したＲＥＳＴ式ＯＡｕｔｈ許諾管理サービス、およびモバイルアプリケーションシングルサインオンするＯＡｕｔｈサービス - Google Patents

単一のフレキシブルかつプラガブルＯＡｕｔｈサーバを備える複数のリソースサーバ、ＯＡｕｔｈ保護したＲＥＳＴ式ＯＡｕｔｈ許諾管理サービス、およびモバイルアプリケーションシングルサインオンするＯＡｕｔｈサービス Download PDF

Info

Publication number
JP6033990B2
JP6033990B2 JP2016515506A JP2016515506A JP6033990B2 JP 6033990 B2 JP6033990 B2 JP 6033990B2 JP 2016515506 A JP2016515506 A JP 2016515506A JP 2016515506 A JP2016515506 A JP 2016515506A JP 6033990 B2 JP6033990 B2 JP 6033990B2
Authority
JP
Japan
Prior art keywords
access
server
resource
service
resource server
Prior art date
Legal status (The legal status 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 status listed.)
Active
Application number
JP2016515506A
Other languages
English (en)
Other versions
JP2016535880A (ja
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
Priority claimed from US14/266,478 external-priority patent/US9237145B2/en
Application filed by オラクル・インターナショナル・コーポレイション filed Critical オラクル・インターナショナル・コーポレイション
Priority claimed from PCT/US2014/056466 external-priority patent/WO2015042349A1/en
Publication of JP2016535880A publication Critical patent/JP2016535880A/ja
Application granted granted Critical
Publication of JP6033990B2 publication Critical patent/JP6033990B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

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/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
    • 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/0853—Network architectures or network communication protocols for network security for authentication of entities using an additional device, e.g. smartcard, SIM or a different communication terminal
    • 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/10—Network architectures or network communication protocols for network security for controlling access to devices or network resources
    • 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/10—Network architectures or network communication protocols for network security for controlling access to devices or network resources
    • H04L63/102—Entity profiles
    • 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/20—Network architectures or network communication protocols for network security for managing network security; network security policies in general
    • 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/20—Network architectures or network communication protocols for network security for managing network security; network security policies in general
    • H04L63/205—Network architectures or network communication protocols for network security for managing network security; network security policies in general involving negotiation or determination of the one or more network security mechanisms to be used, e.g. by negotiation between the client and the server or between peers or by selection according to the capabilities of the entities involved
    • 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

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)
  • Computer And Data Communications (AREA)
  • Storage Device Security (AREA)
  • Telephonic Communication Services (AREA)

Description

優先権主張
本願は、２０１３年９月２０日に出願され、「単一のフレキシブルかつプラガブルOAuthサーバを備える複数のリソースサーバ、OAuth保護したREST式OAuth許諾管理サービス、およびモバイルアプリケーションシングルサインオンするOAuthサービス（MULTIPLE RESOURCE SERVERS WITH SINGLE, FLEXIBLE, PLUGGABLE OAUTH SERVER AND OAUTH-PROTECTED RESTFUL OAUTH CONSENT MANAGEMENT SERVICE, AND MOBILE APPLICATION SINGLE SIGN ON OAUTH SERVICE）」と題された米国仮特許出願番号第６１／８８０３３５号に基づき、米国特許法第１１９条（ｅ）による優先権を主張し、その全体の内容が引用によって本明細書に援用される。
関連出願の相互参照
本願は、２０１１年９月２９日に出願され、「証明書利用者およびOAuthフレームワーク（RELYING PARTY AND OAUTH FRAMEWORK）」と題された米国仮特許出願番号第６１／５４１０２６号の関連出願であり、その内容全体が引用によって本明細書に援用される。また、本願は、２０１２年９月２８日に出願され、「OAuthフレームワーク」と題された米国仮特許出願番号第１３／６３１５３８号の関連出願であり、その全体の内容が引用によって本明細書に援用される。
背景
ＩＤ管理システムは、企業のＩＤ管理またはネットワーク間ＩＤ管理のために、使用できる情報システムまたは一連の技術である。ＩＤ管理は、費用、停止時間および反復作業を減少しながら、安全性および生産性を向上させる目的で、システムおよび企業内またはシステムおよび企業間に、別々のＩＤの認証（authentication）、承認（authorization）、役割および権限を管理することを意味する。ＩＤ管理の一態様は、「シングルサインオン」（single sign-on：ＳＳＯ）である。ＩＤ管理に特に有用である１つの規格は、OAuthである。
ＳＳＯは、複数の相互関連かつ独立するソフトウェアシステムに対するアクセス制御権である。この権利を与える場合、ユーザは、一度ログインすると、すべてのシステムに対するアクセスを得ることができ、各々のシステムに再度ログインするように要求されない。逆に、シングルサインオフ（single sign-off）は、サインアウトという単一行動が複数のソフトウェアシステムに対するアクセスを終了させる権利である。異なるアプリケーションおよびリソースが異なる認証メカニズムをサポートするように、シングルサインオンは、最初の認証に使用された資格情報を内部で異なる資格情報変換して、保存する。ユーザが思考せずあらゆる所にパスワードを入力するように訓練されていないため、ＳＳＯは、フィッシングされる可能性を軽減することができる。ＳＳＯは、異なるユーザ名およびパスワードの組み合わせによるパスワード記憶疲労を軽減する。ＳＳＯは、同一ＩＤのためにパスワードを再入力する時間を軽減することができる。ＳＳＯは、パスワードに関する情報技術（ＩＴ）ヘルプデスクコールの回数を減らすことができるため、ＩＴ費用を軽減する。ＳＳＯは、システムのすべてのレベルの進入／退出／アクセスに安全性を与えるため、ユーザに再要求するという不便性を省く。また、ＳＳＯは、コンプライアンス遵守の集中報告を可能にする。ＳＳＯは、すべての他のアプリケーションおよびシステムが認証目的のために利用する集中型認証サーバを、ユーザが複数回に資格情報を能動的に入力する必要がないように保証する技術と組み合わせて、使用する。
OAuthは、オープン承認規格である。承認の二次的な効果は、認証である。OAuthによって、ユーザは、一般的に、自分の個人情報を渡すことなく、ユーザ名トークンおよびパスワードトークンを提供することによって、１つのサイトに保存された私的なリソース（たとえば、写真、ビデオおよび連絡先リストなど）を別のサイトと共有することができる。各トークンは、決められた期間中に、特定サイトの特定リソースにアクセス権を与える。これによって、ユーザは、自分のアクセス権または自分のすべてのデータを共有することなく、別のサービスプロバイダに保存されている情報のアクセス権を第三者サイトに与えることができる。たとえば、トークンは、次の２時間に特定アルバム内の動画のアクセス権をビデオ編集サイトに与えることができる。
たとえば、典型的なシナリオにおいて、LinkedIn（登録商標）のユーザは、ユーザの連絡先をYahoo（登録商標）からLinkedInにインポートする許可を求められる場合がある。たとえば、LinkedInは、ユーザの連絡先の各々をLinkedInに参加するように招待する電子メールメッセージを送信するために、ユーザの連絡先を取得する必要がある。OAuthが存在しなかったときに、許可を求めるリクエストは、ユーザから、YahooのユーザＩＤおよびパスワードをLinkedInに提供することを要求する。LinkedInは、これらの情報を要求したことによって、そのユーザとして、ユーザのYahooアカウントにログインし、ユーザのYahooアカウントからユーザの連絡先を入手することができる。一般的には、LinkedInにユーザのYahoo（または他のサイト）のＩＤおよびパスワードを与えると、前者のLinkedInサイトが後者のYahooサイト上のユーザアカウントに無制限のアクセス権を与えることになり、好ましくない着想である。殆どの場合、このような無制限のアクセス権は、単に連絡先リストを取得する目的を達成するために、前者のLinkedInサイトに実際に必要されるアクセス権をはるかに超える。
より良い着想は、後者サイト上のユーザアカウントの制限された権限を前者サイトに提供することである。後者サイト上のユーザアカウントの制限された権限は、前者サイトが実行できる特定の操作を指定することができる。たとえば、上記の典型的なシナリオの場合、制限された権限は、LinkedInがユーザの連絡先リストのみにアクセスし、Yahoo上のユーザアカウントに対する他の操作を実行することができないように指定することができる。OAuthは、このような制限された権限を付与することができる。OAuthは、権限の委任を提供する。
OAuthの権限委任技術は、類推による説明から理解することができる。多くの場合、車の所有者は、車を駐車係（バレット）に駐車させるために、車の運転権利を駐車係に一時的に譲渡するときに、汎用のマスターキーを駐車係に与えず、その代わりに、使用が制限されたバレットキーを駐車係に与える。バレットキーは、車を運転するのに十分なアクセス権を駐車係に許可するが、所有者が持っているすべての車アクセス権を駐車係に与えない。同様に、OAuthは、第二サイトに保存されたユーザの連絡先リストにアクセス権利を第一サイトに与えることができるが、第二サイト上のユーザアカウントに関連する他の操作、たとえば、第二サイト上に保存されている電子メールを読むことを第一サイトに与えない。OAuthは、第二サイトに対して指定操作を実行するための制限された権限を第一サイトに与え、指定操作以外の操作を実行する権限を第一サイトに与えない。
別の例として、ユーザは、第一サイトにより提供されたSnapfishなどの写真印刷サービスを使用して、第一サイトから独立している第二サイト、たとえばFlickrに電子的に保存されている特定のカラー写真を印刷したい可能性がある。より具体的には、ユーザは、Flickr上の特定のアルバム、たとえばユーザが最近アラスカを訪問したときの写真を含むアルバムに保存されている写真のみを印刷したい可能性がある。ユーザは、自分のFlickrアカウントに多くの異なるアルバムを保存しているが、アラスカアルバム内の写真のみを印刷したい可能性がある。このような状況において、恐らくユーザは、SnapfishがFlickr上のアラスカアルバムに含まれた内容を除き、他の内容にアクセスして欲しくない。前述のシナリオにおいて、OAuth用語で表す場合、Snapfishは、クライアントであり、Flickrは、リソースサーバ（写真データがリソースである）およびOAuth承認サーバであると考えられる。ユーザは、リソースサーバに保存されたリソース（たとえば、写真データ）の所有者であるため、リソース所有者である。
上記の例の場合、ユーザは、まず、インターネットブラウザアプリケーションを用いて、リソースサーバ（たとえば、Flickr）上のユーザのアラスカアルバム内の写真を印刷するように、クライアント（たとえば、Snapfish）に指示する。これに応じて、クライアント（たとえば、Snapfish）は、ユーザをリソースサーバ（たとえば、Flickr）のサイトにリダイレクトする。このリダイレクト操作は、クライアントがアクセスしたい制限されたデータセット（たとえば、アラスカアルバムの内容）をリソースサーバに示唆することができる。この時に、ユーザがまだリソースサーバに認証されていないため、リソースサーバは、ユーザの身分を分からない。したがって、リソースサーバは、認証するようユーザに要求する。前述したように、この認証は、承認の二次的な効果である。ユーザが（たとえば、リソースサーバに関連する自分のユーザ名およびパスワードを提供することによって）リソースサーバに自分自身を認証した後、リソースサーバは、ユーザのインターネットブラウザに許諾書を送信する。許諾書は、リソースサーバ（たとえば、Flickr）が制限された指定データセット（たとえば、アラスカアルバムの内容）をクライアント（たとえば、Snapfish）に提供する許可をユーザから得たことを確認するように、ユーザに照会する。仮にユーザが許諾すると、リソースサーバは、それに応答して、承認コードをクライアントに送信する。この承認コードは、「フロントチャネル」、すなわち、ユーザのインターネットブラウザによるリダイレクトを介して送信されてもよい。
以下の説明のために、リソースサーバは、OAuth承認サーバとして機能してもよいが、好ましくはリソースサーバのみである。このシナリオにおいて、クライアント（たとえば、Snapfish）は、リソースサーバ（たとえば、Flickr）の信頼できるパートナーである。クライアントは、承認コードまたは「許可」を受信して、承認コードを保存する。クライアントは、ユーザが能動的にこの承認コードを取り消すまで、この承認コードを無期限に保管する。OAuth承認サーバがユーザに代理してさまざまなクライアントに提供している許可のリストを確認するために、ユーザは、OAuth承認サーバにログインする必要がある。承認コードの受信に応答して、クライアント（たとえば、Snapfish）は、リソースサーバ（たとえば、Flickr）に「バックチャネル」コールを行うことができる。バックチャネルコールは、ユーザのインターネットブラウザに関与しない通信である。バックチャネルコールは、リソースサーバからアクセストークンを要求する。アクセストークンは、クライアントに与えたリソースサーバ上のユーザアカウントのアクセス範囲を指定する。たとえば、アクセストークンは、ユーザのアラスカアルバム内容のみへのアクセス権をクライアントに与えることを指定することができる。リソースサーバは、バックチャネルを介して、要求したアクセストークンをクライアントに返送する。クライアントは、このアクセストークンを保存する。その後、クライアントは、アクセストークンの有効期限が切れるまでまたはユーザが許可（すなわち、承認コード）を取り消すまで、アクセストークンをリソースサーバに提示して、アクセストークンにより指定されたリソースサーバ上のリソースにアクセスすることができる。しかしながら、ユーザがアクセストークンに関連する許可を取り消した場合、アクセストークンは、有効期限が切れなくても無効になる。
アクセストークンに加えて、リソースサーバは、「リフレッシュトークン」をクライアントに与えることができる。アクセストークンは通常、指定された有効期限を有するが、リフレッシュトークンは、長期間のトークンである。クライアントは、関連するアクセストークンとともに、リフレッシュトークンを保存することができる。リソースサーバがクライアントの現在のアクセストークンの有効期限が切れたことを表明する場合、クライアントは、リソースサーバにリフレッシュトークンを提示することによって、リソースサーバから新規アクセストークンを取得することができる。
有利には、OAuthに利用された手法は、リソースサーバ上のユーザアカウントのユーザパスワードをクライアントに開示することを回避する。このような資格情報の開示回避は、クライアントがリソースサーバ上のユーザアカウントに対して不正行為を実行することを防止できる。ユーザがパスワードを提供する唯一の時機は、クライアントのサイトからリダイレクトされた後、リソースサーバに直接にユーザの初期認証を行うときのみである。
概要
本発明の実施形態は、識別情報を管理、認証および承認するフレームワークに関連する。一実施形態において、フレームワークは、インターネット識別情報を企業の識別情報およびアクセス管理（identity and access management：ＩＡＭ）インフラストラクチャに統合するために提供される。別の実施形態によれば、フレームワークは、オープン承認のために提供される。
従来、リソースサーバとOAuth承認サーバとは、同一の実体である。本発明の一実施形態によれば、提供された汎用フレームワークは、OAuth承認サーバの責務からリソースサーバを切離す。これらの責務は、範囲の管理、承認トークンの発行、リフレッシュトークンの発行、およびアクセストークンの発行を含むことができる。したがって、この汎用フレームワークを用いて、汎用OAuth承認サーバを実現することができる。その結果、各リソースサーバは、専用のOAuth承認サーバを実装する必要がない。実際は、本発明の一実施形態によれば、すべての複数の異なるリソースサーバは、同一の汎用OAuth承認サーバの機能を同時に利用することができる。たとえば、本発明の一実施形態において、単一のOAuth承認サーバは、複数の異なるリソースサーバの範囲管理を同時に行うことができる。リソースサーバとOAuth承認サーバとの間には、多対一の関係を有することができる。
本発明の一実施形態において、複数の異なるリソースサーバと情報を交換する機能を達成するために、汎用OAuth承認サーバは、どのトークンがどのリソースサーバに属するか、各リソースサーバの信頼パートナーが誰であるかなどを示すマッピング関係データを保管する。さらに、本発明の一実施形態において、汎用OAuthフレームワークは、リソースサーバの管理者がリソースサーバを特定用途に対応させるためにフレームワークを容易にカスタマイズできるように、構成されている。異なるリソースサーバの管理者は、各々の特定のコンポーネントを汎用OAuthフレームワークに「プラグイン」することができる。したがって、本発明の一実施形態において、各リソースサーバは、各リソースサーバが使用する可能性のある潜在的な範囲（すなわち、リソースに対して制限された操作）を汎用OAuth承認サーバに通知する。
本発明の一実施形態によれば、OAuth承認サーバが提供される。OAuth承認サーバは、OAuth承認サーバにおいて、複数の別々の識別ドメインのうち、第一識別ドメイン内で動作する第一クライアントアプリケーションから、リクエストを受信するように構成された第一受信ユニットと、OAuth承認サーバに保管された複数のOAuthサービスプロファイルから、第一識別ドメインのみに適用できる第一OAuthサービスプロファイルを選択するように構成された第一選択ユニットと、第一OAuthサービスプロファイルに基づいて、第一クライアントアプリケーションが第一リソースサーバにアクセスする許可を有するか否かを決定するように構成された第一決定ユニットと、第一クライアントアプリケーションが第一リソースサーバにアクセスする許可を有するという決定に応答して、OAuth承認サーバが第一リソースサーバから取得した範囲情報に基づいて、第一クライアントアプリケーションに第一トークンを生成するように構成された第一生成ユニットと、OAuth承認サーバにおいて、複数の別々の識別ドメインのうち、第一識別ドメインと別体の第二識別ドメイン内で動作する第二クライアントアプリケーションから、リクエストを受信するように構成された第二受信ユニットと、OAuth承認サーバに保管された複数のOAuthサービスプロファイルから、第二識別ドメインのみに適用できる第二OAuthサービスプロファイルを選択するように構成された第二選択ユニットと、第二OAuthサービスプロファイルに基づいて、第二クライアントアプリケーションが第二リソースサーバにアクセスする許可を有するか否かを決定するように構成された第二決定ユニットと、第二クライアントアプリケーションが第二リソースサーバにアクセスする許可を有するという決定に応答して、OAuth承認サーバが第二リソースサーバから取得した範囲情報に基づいて、第二クライアントアプリケーションに第二トークンを生成するように構成された第二生成ユニットとを含む。
上記の特徴および実施形態ならびに他の特徴および実施形態は、以下の明細書、特許請求の範囲および添付の図面を参照すればより明らかになるであろう。
本発明の一実施形態に従ったOAuthシステムアーキテクチャおよびその論理コンポーネントを示すブロック図である。 本発明の一実施形態に従ったリソースサーバ環境を示すブロック図である。 本発明の一実施形態に従ったOAuthクライアント環境を示すブロック図である。 本発明の一実施形態に従った方法の一例を示すフローチャートである。複数の識別ドメインを有するクラウドベースコンピューティング環境に存在するOAuth承認サーバは、この技術を用いて、別々の独立している識別ドメインに動作する異なるアプリケーションを承認するためのトークンを生成することができる。 本発明の一実施形態に従って、クラウドOAuth承認サーバの一例を示すブロック図である。このクラウドOAuth承認サーバは、異なる識別ドメインを有し、クラウドにより提供されたサービスに別々の企業からのクライアントを承認するために、これらのクライアントと情報を交換する。 本発明の一実施形態に従って、ユーザ特有属性を用いてトークンを拡張するための方法の一例を示すフローチャートである。 本発明の一実施形態に従って、複数のリソースサーバからサービスを要求するために使用可能な単一トークンを生成するための方法の一例を示すフローチャートである。 本発明の一実施形態に従って、リソースサーバにより保管された承認ポリシーをOAuth承認サーバにプラグインするための方法の一例を示すフローチャートを示す図である。 図８Ａの続きである。 本発明の一実施形態に従って、承認リクエストをクライアント特有のユーザＩＤリポジトリにアクセスするクライアント特有のプラグインモジュールにルーティングするための方法の一例を示すフローチャートである。 本発明の一実施形態に従って、識別ドメイン特有トークンの属性を有するトークンを生成するための方法の一例を示すフローチャートである。 本発明の一実施形態に従って、リソースサーバにより上書きされる値を有するトークン属性を含むトークンを生成するための方法の一例を示すフローチャートである。 本発明の一実施形態に従った方法の一例を示すフローチャートである。この技術によって、共有OAuth承認サーバは、クラウドコンピューティング環境内の異なる識別ドメインに登録された異なる適応型アクセスマネージャを呼出すことができる。 本発明の一実施形態に従った方法の一例を示すフローチャートである。この技術によって、OAuth承認サーバは、許諾管理用のREST（Representational State Transfer）インターフェイスを提供する。 本発明の一実施形態に従った方法の一例を示すフローチャートである。この技術によって、サーバは、このサーバと別体のモバイル装置上で動作する複数の相互関連するアプリケーション用のアクティブユーザセッションを保管する。 本発明の一実施形態に従った方法の一例を示すフローチャートである。この技術によって、クライアント登録トークンは、帯域外チャネルを介してモバイル装置に安全に送信され、したがって、モバイル装置は、クライアント登録トークンを用いて、シングルサインオンという機能を達成することができる。 実施形態のうちの１つを実現するための分散型システムを示す簡略図である。 本開示の実施形態に従ったシステム環境のコンポーネントを示す簡略ブロック図である。実施形態に従ったシステムのコンポーネントによって提供されるサービスは、クラウドサービスとして提供されることができる。 本発明のさまざまな実施形態を実現することができるコンピュータシステムの一例を示す図である。 本発明のいくつかの実施形態に係るOAuth承認サーバの一例を示す機能ブロック図である。
詳細な説明
以下の記載には、説明の目的で、本発明の実施形態を完全に理解できるようにするために具体的な詳細が記載されている。しかしながら、これらの具体的な詳細がなくても本発明を実施できることは明らかであろう。２０１１年９月２９日に出願され、「証明書利用者およびOAuthフレームワーク」と題された米国仮特許出願番号第６１／５４１０２６号の全体の内容が引用によって本明細書に援用される。
汎用OAuthシステムアーキテクチャ
図１は、本発明の一実施形態に従ったOAuthシステムアーキテクチャ１００およびその論理コンポーネントを示すブロック図である。アーキテクチャ１００は、リソース所有者（またはユーザ）１０２と、クライアントアプリケーション１０４と、リソースレジストリ１０６と、リソースエコシステム１１０とを含む。リソースエコシステムは、クライアントレジストリ１１２と、トークン範囲レジストリ１１４と、範囲レジストリ１１６と、ユーザ許諾１２０と、リソースサーバ１２２とを含む。図示には、１つのリソースサーバ１２２しか示されていないが、本発明の実施形態は、複数の別々のリソースサーバを含むことができる。図１の接続から分かるように、クライアントアプリケーション１０４は、レジストリ１０６と情報を交換する。リソース所有者１０２は、リソースレジストリ１０６およびクライアントレジストリ１１２と情報を交換する。承認サーバ１１８は、クライアントレジストリ１１２、トークン範囲レジストリ１１４およびユーザ許諾１２０の三者と情報を交換する。リソースサーバ１２２は、トークン範囲レジストリ１１４と情報を交換する。ユーザ許諾１２０は、範囲レジストリ１１６と情報を交換する。これらのコンポーネントおよびそれらの機能は、以下でさらに説明する。
本発明の実施形態は、承認の委任を含むことができる。異なるリソースを使用する場合、異なる範囲を定義する必要がある。異なるリソースは、異なる承認モデルおよびソリューションに依存する場合がある。異なるリソースサーバによって保管されたリソースにアクセス権をクライアントアプリケーションに与えるために、異なる特定ユーザの操作が必要である。好ましくは、異なるリソースプロバイダの各々は、各リソースプロバイダの仕様を統合する別体のOAuth承認サーバを設けない。リソースプロバイダの各々が各自のOAuth承認サーバを備えると、企業は、複数の異なるリソースプロバイダおよび複数の異なるクライアントフォームファクタを統合したい場合、無数の異なるOAuth承認サーバインターフェイスを対応しなければならないという問題に直面する。
したがって、本発明の一実施形態において、汎用OAuthフレームワークアーキテクチャが提供される。このフレームワークは、メタデータおよびランタイムレジストリを含むOAuthワイヤプロトコルコンポーネント（クライアントおよびサーバ）を含むことができる。このフレームワークは、アプリケーション特有ソリューションをカスタマイズおよび配置するために、プラガブル「コントラクト」のインフラを含むことができる。
本発明の一実施形態において、リソースサーバ１２２は、トークン範囲レジストリ１１４において、リソースサーバ１２２の認識範囲を示す情報を保存する。各範囲は、リソースサーバ１２２に保存されている異なるセットのリソースに対して実行できる操作の異なるセットを示すことができる。特定の実施形態が複数の異なるまたは別々のリソースサーバを含む場合、トークン範囲レジストリ１１４は、異なるリソースサーバと異なる範囲との間のマッピング関係を保存することができる。さらに、本発明の一実施形態において、各範囲は、トークン範囲レジストリ１１４内の各トークンにマッピングされている。よって、トークン範囲レジストリ１１４を参照することによって、リソースサーバ１２２は、クライアントアプリケーション１０４によってリソースサーバ１２２に提示される特定のトークンにマッピングされた操作のセットおよびリソースのセットを決定することができる。リソースサーバ１２２は、クライアントアプリケーション１０４によってリソースサーバ１２２に保管されたリソースに対して行われる操作を、特定のトークンにマッピングされた操作のセットに具体的に指定された操作に制限することができる。
したがって、本発明の一実施形態において、複数のリソースサーバグループ内の特定リソースサーバの各々は、異なるセットのメタデータをOAuthフレームワークに提供する。これらのメタデータは、その特定リソースサーバ上のリソースにアクセスするために使用することができるトークンにマッピングされた範囲を示している。これらの範囲がリソースサーバの管理者によってカスタマイズすることができるため、OAuthフレームワークをフレキシブルにすることができ、さまざまなユースケースに適用することができる。その結果、多くの異なる種類のリソースサーバのすべては、同一の汎用OAuthフレームワークを利用することができ、異なる種類のリソースサーバの各々に特定のOAuthフレームワークを作成する必要がない。
一実施形態において、図１に示された汎用OAuthフレームワークは、基本的な概念構造を形成する。OAuthフレームワークは、既存のＩＤ管理製品上に重なることができる。OAuthフレームワークにおいて、コントラクトは、これらの既存製品と統合するポイントを定義することができる。OAuthフレームワークとコントラクト実装との組み合わせは、さまざまなユースケースおよび配置オプションを満たすことができる。一実施形態によれば、OAuthフレームワークは、２つの大きな「役割」、すなわち、消費者／クライアントの役割および承認サーバ／リソースサーバの役割を含む。承認サーバ／リソースサーバの役割は、図２を参照して以下に説明する。消費者／クライアントの役割は、図３を参照して以下に説明する。
図２は、本発明の一実施形態に従ったリソースサーバ環境２００を示すブロック図である。本発明の一実施形態において、環境２００は、リソース所有者（またはユーザ）２０２と、クライアントアプリケーション２０４と、リソースサーバ２１０と、OAuth承認サーバ２２０と、ポリシーサービス２４０と、トークンサービス２５０とを含む。リソースサーバ２１０は、アクセストークン検証ＡＰＩ ２１４およびゲート２１６を備えるリソースサーバアプリケーション２１２を含む。OAuth承認サーバ２２０は、トークン範囲レジストリ２２２と、リソース範囲レジストリ２２４と、ユーザ許諾オーケストレーション２２６と、OPSS-TS（Oracleプラットフォームセキュリティサービス−ＴＳ）２２８と、OPSS-AZ（Oracleプラットフォームセキュリティサービス−ＡＺ）２３０と、OAuthコアエンジン２３２と、OAuthプロトコルエンジン２３４と、クライアントレジストリ２３６とを含む。一実施形態において、リソース所有者２０２は、クライアントアプリケーション２０４と情報を交換する。クライアントアプリケーション２０４は、ゲート２１６を介して、アクセストークン検証ＡＰＩ ２１４にアクセスする。また、クライアントアプリケーション２０４は、OAuth許可サーバ２２０と情報を交換する。アクセストークン検証ＡＰＩ ２１４は、トークン範囲レジストリ２２２およびポリシーサービスで２４０と情報を交換する。OPSS-TSは、トークンサービス２５０と情報を交換する。OPSS-AZは、ポリシーサービス２４０と情報を交換する。コンポーネント２２８〜２３４は、共同でトークン範囲レジストリ２２２およびユーザ許諾オーケストレーション２２６と情報を交換する。ユーザ許諾オーケストレーション２２６は、リソース範囲レジストリ２２４と情報を交換する。
本発明の一実施形態において、リソース範囲レジストリ２２４は、OAuth承認サーバ２２０を介して公開されたリソースおよびサービスに関連するリソース情報、リソース範囲および各種メタデータを保存する。本発明の一実施形態において、クライアントレジストリ２３６は、承認されたリモートクライアント（たとえば、クライアントアプリケーション２０４）の信頼キーおよび秘密質問を保存する。一実施形態において、トークン範囲レジストリ２２２は、アクセストークンを保存し、ユーザ（たとえば、リソース所有者２０２）の許諾に基づいて、クライアント（たとえば、クライアントアプリケーション２０４）に発行したトークンを更新する。一実施形態において、トークン範囲レジストリ２２２は、発行されたアクセストークンに関連するAuthZ範囲情報を保存する。
本発明の一実施形態において、リソースサーバ２１０は、自己のメタデータをOAuth承認サーバ２２０に登録する。異なるリソースサーバは、異なるメタデータを同一のOAuth承認サーバに登録することができる。登録プロセスの一環として、このメタデータは、OAuth承認サーバ２２０にインポートされる。このメタデータは、リソースサーバ２１０によって認識または開示されたさまざまな異なる範囲を示す。各範囲は、リソースサーバ２１０によって保管されたリソースの異なるサブセットを指定する。本発明の一実施形態において、登録時に、リソースサーバ２１０によって認識された各範囲は、リソース範囲レジストリ２２４において、リソースサーバ２１０（のみ）にマッピングされる。したがって、本発明の一実施形態において、リソース範囲レジストリは、各登録された範囲内でアクセス可能な対応リソースサーバのリソースのセットを示す。範囲は、たとえば、特定の写真のみにアクセス可能であり、または特定の写真フォルダにアクセス可能であり、または特定セットのフォルダにアクセス可能であることを指定することができる。範囲は、特定のリソースに対して許可された操作、たとえば、読取、更新、削除および作成などを指定することができる。
本発明の一実施形態において、OAuth承認サーバ２２０は、アクセストークンをクライアントアプリケーション２０４に発行する。一実施形態において、OAuth承認サーバ２２０は、トークン範囲レジストリ２２２に、発行されたアクセストークンと、このアクセストークンに割当てられた（リソース範囲レジストリ２２４に保存された範囲から選択された）特定の範囲との間のマッピング関係を保存する。同一リソースサーバ用の異なるアクセストークンは、割当てられた異なる範囲を有することができる。したがって、クライアントアプリケーション２０４がアクセストークンをOAuth承認サーバ２２０に提示する際に、OAuth承認サーバ２２０は、レジストリ２２２範囲トークンを参照することによって、そのアクセストークンにマッピングされている範囲を決定し、リソース範囲レジストリ２２４を参照することによって、その範囲内でアクセス可能なリソースを決定する。
本発明の一実施形態において、OAuth承認サーバ２２０がアクセストークンをクライアントアプリケーション２０４に与えるために、リソース所有者２０２からのユーザ許諾が必要である。たとえば、クライアントアプリケーション２０４がリソースサーバ２１０から特定のリソース（または特定のリソースを含む特定の範囲）へのアクセスをリクエストする場合、リソースサーバ２１０は、そのリクエストをOAuth承認サーバ２２０にリダイレクトすることができる。OAuth承認サーバ２２０は、リソース所有者２０２に照会して、特定のリソース（または特定の範囲）へのアクセス権をクライアントアプリケーション２０４に与えることを検証するために、ユーザ許諾オーケストレーション２２６を呼出すことができる。一実施形態において、ユーザ許諾オーケストレーション２２６は、クライアントアプリケーション２０４が求めているアクセス範囲をリソース所有者２０２に提示し、その範囲に対するアクセスを許諾または拒否する機会をリソース所有者２０２に与える。より具体的には、OAuth承認サーバ２２０は、リソース所有者２０２に照会して、（リソース範囲レジストリ２２４に示された）特定のリソースを含む特定の範囲によって指定されたアクセス権をクライアントアプリケーション２０４に与えるか否かを確認する。リソース所有者２０２からの許諾の受信に応答して、OAuth承認サーバ２２０は、アクセストークンを生成し、アクセストークンと特定の範囲との間のマッピング関係をトークン範囲レジストリ２２２に保存することができる。OAuth承認サーバ２２０は、アクセストークンをクライアントアプリケーション２０４に提供することができる。
その後、クライアントアプリケーション２０４は、アクセストークンをリソースサーバアプリケーション２１２に提示することによって、リソースサーバ２１０上の特定のリソースへのアクセスを試みることができる。特定のリソースにアクセスする許可をクライアントアプリケーション２０４に与える前に、リソースサーバアプリケーション２１２上のエージェントは、アクセストークンをインターセプトして、（たとえば、アクセストークン検証ＡＰＩ ２１４を介して）OAuth承認サーバ２２０においてそのアクセストークンを検証することができる。クライアントアプリケーション２０４がアクセスしようとする特定のリソースがトークン範囲レジストリ２２２に保存されたアクセストークンにマッピングされている範囲を超える場合（たとえば、クライアントアプリケーション２０４がリソース所有者２０２過去に許諾したアクセス範囲の外にあるフォルダにアクセスしようとする場合）、OAuth承認サーバ２２０は、そのアクセストークンを承認せず、リソースサーバ２１０は、特定のリソースへのアクセス権をクライアントアプリケーション２０４に与えない。したがって、アクセス範囲は、リソース所有者２０２が許諾した特定の範囲に依存する。リソース所有者２０２は、クライアントアプリケーション２０４によってリクエストされた特定の範囲に対する許諾を拒否する機会がある。この場合、OAuth承認サーバ２２０は、クライアントアプリケーション２０４用のアクセストークンを作成しない。本発明の一実施形態において、リソースサーバ２１０によって保管されたリソースにアクセスするための各クライアントアプリケーションのリクエストは、リソース範囲レジストリ２２４において、リソースサーバ２１０にマッピングされている範囲を指定する。上述したように、この指定範囲は、リソース所有者２０２からリクエストされた許諾による範囲である。
本発明の一実施形態によれば、上記の説明と同様に、クライアントアプリケーション２０４がアクセストークンをリソースサーバ２１０に提示するときに、アクセス制限が実施される。アクセス制限の実施は、アクセストークンによりエンコードされた範囲を理解する必要がある。アクセストークンは、OAuth承認サーバ２２０によって各範囲定義ごとに発行される。アクセストークンは、発行されたトークンによってエンコードされた範囲ごとに検証される。本発明の一実施形態において、ポリシーサービス２４０およびトークンサービス２５０はともに、発行されたアクセストークンの状態を保管し、発行されたアクセストークンを認証する。本発明の一実施形態において、顧客（すなわち、リソースサーバ２１０の所有者および／または操作者）は、独自のポリシーサービス２４０およびトークンサービス２５０を形成することができる。OAuthフレームワークは、プログラマチックコントラクトまたはプログラマチックインターフェイスを提供することができる。これによって、顧客は、顧客が定義した範囲と一致するように、独自のポリシーおよびトークンサービスをOAuthフレームワークにプラグインすることができる。各顧客は、独自の範囲セットを公開することもできる。公開された範囲セットは、顧客のトークンサービスから返送されるデータの形式を指定することができる。さらに、OAuthフレームワークは、トークン発行時にポリシーの作成を許可するプログラマチックコントラクトまたはプログラマチックインターフェイスを顧客に提供することができる。これらのプログラマチックコントラクトまたはプログラマチックインターフェイスを介して、顧客は、独自のカスタムプログラマチックコードをOAuthフレームワークにプラグインすることができる。顧客は、これらのプログラマチックインターフェイスを用いて、既存のインフラストラクチャをOAuthシステムに接続することができる。一実施形態において、範囲を公開した顧客は、そのトークンサービスおよび／またはポリシーサービスが公開した範囲と一致する範囲の情報を含むトークンを返送することを保証する責任がある。クライアントアプリケーション２０４がトークンを使用しようとすることに応答して、OAuth承認サーバ２２０は、顧客のポリシーを検索しかつトークンを検証するためのアプリケーションプログラミングインターフェイス（ＡＰＩ）を呼出すことができる。
一実施形態において、OAuthフレームワークは、OAuth承認サーバ２２０と情報を交換するために実行する必要のある顧客のコード（たとえば、トークンサービス２５０およびポリシーサービス２４０用のコード）のインターフェイスを指定する。これらのインターフェイスを公開することができる。よって、顧客は、各インターフェイスが受信しようとするパラメータおよび各インターフェイスが返送しようとする値を把握することができる。クライアントアプリケーション２０４がOAuth承認サーバ２２０にリクエストを送信すると、OAuth承認サーバ２２０は、そのリクエストに関連するＡＰＩに応答コールを行う。これらのコールは、たとえば、アクセストークンを生成し、生成したアクセストークンをクライアントアプリケーション２０４に提供するための顧客コード化したコンポーネントに与えたコールを含むことができる。本発明の一実施形態において、OAuth承認サービス２２０は、前述したプログラマチックコントラクトまたはプログラマチックインターフェイスをOPSS-TS ２２８およびOPSS-AZ ２３０の形で公開する。トークンサービス２５０の顧客自分の実装は、OPSS-TS ２２８と情報を交換することができ、ポリシーサービス２４０の顧客自分の実装は、OPSS-AZ ２３０と情報を交換することができる。アクセストークンの作成およびアクセストークンの検証のために、OAuth承認サーバ２２０は、異なるＡＰＩを呼出すことができる。顧客は、カスタムプログラムコードを実行することによって、各タスクを実行することができる。検証中に、トークンの作成時に構築されたポリシーにアクセスすることによって、クライアントアプリケーション２０４がリソースに対して実行しようとする行動は、クライアントアプリケーション２０４が提示したアクセストークンによってコードされたポリシーに合致するか否かを決定することができる。
さらに、本発明の一実施形態において、クライアントアプリケーション２０４がOAuth承認サーバ２２０からアクセストークンを取得しようとするときに呼出されたユーザ許諾オーケストレーション２２６の顧客自分の実装は、OAuth承認サーバ２２０にプラグインすることができる。リソース範囲レジストリ２２４およびトークン範囲レジストリ２２２にインターフェイスを設けることができる。これによって、顧客は、ユーザ許諾オーケストレーション２２６に自分の実装を設けることができ、許諾リクエストを構築する際に使用するデータをコンポーネント２２２および２２４から取得することができる。
本発明の一実施形態において、リソース範囲レジストリ２２４に保存されたマッピング関係は、各範囲内に含まれたサブセットのリソースだけではなく、クライアントアプリケーションによってこのサブセットのリソースに対して実行できるサブセットの排他的な操作を示している。たとえば、特定のマッピング関係は、リソースサーバ２１０に保管された指定サブセットのリソース（たとえば、ファイル、フォルダ、ディレクトリ、リスト、プロフィール、画像、およびドキュメントなど）に対して、読取操作および更新操作を行うことができ、作成操作または削除操作を行うことができないという特定の範囲を示すことができる。したがって、本発明の一実施形態において、上述した許諾リクエストは、範囲に関連するサブセットのリソースだけではなく、その範囲に関連するサブセットの操作も指定する。その結果、リソース所有者２０２は、クライアントアプリケーション２０４が許諾リクエストにより指定した範囲においてサブセットのリソースに対して実行できる種類の許諾操作を正確に知ることができる。
本発明の一実施形態によれば、クライアントアプリケーション２０４は、リソースサーバ２１０によりOAuth承認サーバ２２０に登録された特定範囲のいずれか１つと同等な範囲を有するリソースへのアクセス権をリクエストする。したがって、本発明の一実施形態において、クライアントアプリケーション２０４は、リソースサーバ２１０のために登録される特定の範囲を認識するように、設計されている。クライアントアプリケーション２０４がさまざまな異なるリソースサーバにより保管されたリソースと情報を交換することができるため、さまざまなリソースサーバのベンダは、リソースサーバがOAuth承認サーバ２２０に登録する標準セットの範囲に合意することができ、クライアントアプリケーション２０４およびその他のクライアントアプリケーションの設計者の設計作業を容易にすることができる。
本発明の一実施形態において、クライアントフレームワークは、クライアントアプリケーション２０４などのクライアントアプリケーションがさまざまな異なる種類のリソースプロバイダ用の「フック」を提供できるように、設けられる。たとえば、クライアントアプリケーション２０４は、Google（登録商標）、Facebook（登録商標）、Yahoo、LinkedInの各々のために、フックを提供することができる。図３は、本発明の一実施形態に従ったOAuthクライアント環境３００を示すブロック図である。OAuthクライアント環境３００は、リソース所有者３０２と、リソースサーバ３０４と、OAuth承認サーバ３０６と、クライアントアプリケーション３０８と、OAuthクライアント３２０とを含む。クライアントアプリケーション３０８は、OAuthクライアントＡＰＩ ３１０を含む。OAuthクライアント３２０は、OAuthクライアントエンジン３２２と、リソースレジストリ３２４と、ローカルアプリケーションレジストリ３２６と、トークンレジストリ３２８とを含む。リソースサーバ３０４とOAuth承認サーバ３０６とは、互いに情報を交換する。リソースサーバ３０４とOAuthクライアント３２０とは、互いに情報を交換する。OAuth承認サーバ３０６とのOAuthクライアント３２０とは、リソース所有者３０２を介して（たとえば、リソース所有者３０２のインターネットブラウザによって達成したリダイレクトを用いて）互いに情報を交換する。また、リソース所有者３０２は、ライアントアプリケーション３０８と情報を交換する。クライアントアプリケーション３０８は、OAuthクライアントＡＰＩ ３１０を介して、OAuthクライアントエンジン３２２と情報を交換する。OAuthクライアントエンジン３２２は、リソースレジストリ３２４、ローカルアプリケーションレジストリ３２６およびトークンレジストリ３２８と情報を交換する。
本発明の一実施形態によれば、クライアントアプリケーション３０８と情報を交換し得る異なる種類のリソースサーバの全体に関するメタデータをリソースレジストリ３２４に保存することができ、これによって、クライアントアプリケーション３０８は、さまざまな異なるリソースサーバと情報を交換することができる。リソースレジストリは、たとえば、異なる種類のリソースサーバの各々に認識される異なるセットの範囲を指定することができる。これにより、クライアントアプリケーション３０８は、リソースサーバ３０４によって認識される特定の範囲に応じて、アクセス権を要求することができる。この特定の範囲は、OAuth承認サーバ３０６がクライアントアプリケーション３０８を代理してリソース所有者３０２に送信する許諾リクエストに指定されてもよい。リソースプロバイダは、OAuth規格に準拠した範囲の仕様を公開することができ、これによって、設計者は、プロバイダのリソースサーバ用の適切なサーバと範囲とのマッピング関係をリソースレジストリ３２４に取込むことができる。一実施形態において、クライアントアプリケーション３０８に独立してリソースレジストリ３２４を取込むことができるため、新たに発見されたリソースサーバと情報を交換するためにクライアントアプリケーション３０８を修正する必要がなく、その代わりに、開発者が単にこれらのリソースサーバ用の新規マッピング関係を、クライアントアプリケーション３０８と情報を交換するリソースレジストリ３２４に「プラグイン」すればよい。
多くの場合、リソースプロバイダまたはリソースサーバとして機能する複雑なウェブサイトは、一体式のアプリケーションではない。その反面、多くの場合、複雑なウェブサイトは、さまざまな異なるアプリケーションから構成される。本発明の一実施形態において、ローカルアプリケーションレジストリ３２６は、さまざまな異なるリソースプロバイダとこれらのリソースプロバイダによって提供または公開されたアプリケーションセットと間のマッピング関係を保存する。これらのアプリケーションの各々は、ローカルアプリケーションレジストリ３２６において、そのアプリケーション用のＵＲＬ（Uniform Resource Locator）にマッピングされることができる。本発明の一実施形態において、ローカルアプリケーションレジストリ３２６は、信頼キーを保存し、リモートリソースにアクセスするOAuthクライアントの役割を行使する。
一般的には、クライアントアプリケーション３０８は、特定のアクセストークンの有効期限が切れる前に、その特定のアクセストークンを複数回に使用し、リソースサーバ３０４によって保管されたリソースにアクセスすることができる。本発明の一実施形態において、クライアントアプリケーション３０８がOAuth承認サーバ３０６から取得したアクセストークンは、トークンレジストリ３２８に保存される。クライアントアプリケーション３０８が複数の異なるリソースサーバと情報を交換することができる限り、トークンレジストリ３２８は、アクセストークンとこれらのアクセストークンが属する異なるリソースサーバとの間のマッピング関係を保管することができる。トークンレジストリ３２８は、さまざまな異なるリモートリソースサーバ（たとえば、リソースサーバ３０４）および範囲のために、アクセストークンおよびリフレッシュトークンの両方を保存することができる。
シングルOAuthサーバと情報を交換する複数のリソースサーバ
本発明の実施形態は、クライアントアプリケーションをリソースサーバに結び付けるフレームワークを含むため、さまざまなクライアントアプリケーションがさまざまなリソースサーバにアクセスする許可を有するか否かを示すことができる。クライアントアプリケーションは、事前承認リクエストをOAuth承認サーバに送付することができる。リクエストは、クライアントがいくつかの指定リソースにアクセスする必要があることを示すことができる。クライアントアプリケーションは、OAuth承認サーバと通信することによって、トークンを要求することができる。その後、クライアントアプリケーションは、このトークンをリソースサーバに提示することによって、リソースサーバから、リソースサーバ上に保存されているリソースまたはリソースサーバにより提供されるリソースに対するアクセス権をもらえる。上記の操作は、人間ユーザを代理して実行される。
このように、人間のユーザは、クライアントアプリケーションを介して、リソースサーバにアクセスする操作を実行しようとする。リソースサーバにアクセスする前に、クライアントアプリケーションは、リソースサーバ上に保存されたリソースまたはリソースサーバによって提供されたリソースにアクセスできるように、OAuth承認サーバと通信することによって、OAuth承認サーバからトークンを要請する。本発明の一実施形態によれば、OAuth承認サーバは、トークンの取得を外面化するフレームワークである。
クラウドベースコンピューティング環境は、多くの異なるサービスを含むことができる。たとえば、この環境は、ストレージサービス、メッセージングサービスおよび他のサービスを含むことができる。各サービスは、環境内に位置する別体のリソースサーバによって提供されてもよい。ユーザは、たとえば、ストレージサービスによって保管されているユーザのリソースのうち特定のリソースにアクセスしようとすることがある。ユーザは、クライアントアプリケーションに指示することによって、ユーザを代理してこれらのリソースにアクセスすることができる。リソースにアクセスするために、クライアントアプリケーションは、まず、ストレージサービスを提供するストレージリソースサーバ上に保管されているユーザリソースを読取むまたは書込む権利をクライアントアプリケーションに与えるトークンを取得する必要がある。本発明の一実施形態によれば、OAuth承認サーバは、このようなトークンを付与すべきかまたは付与すべきではないかという決定を一方的に下すことをしない。その代わりに、OAuth承認サーバは、このような決定を、OAuth承認サーバの外部にあるリソースサーバによって管理されるさまざまな承認ポリシーエンジンに外在化させる。よって、トークンを付与すべきかまたは付与すべきではないかという決定およびそのトークンによって示された権限の範囲に関する決定は、クライアントアプリケーションがアクセスしようとするサービスを提供するリソースサーバによって決定される。ストレージサービスの場合、クライアントアプリケーションからのトークンを要求するリクエストに応答して、OAuth承認サーバは、そのリクエストをストレージサービスを提供するストレージリソースサーバに中継することができる。アクセスされるサービスに応じて、OAuth承認サーバは、異なるトークンリクエストを異なるリソースサーバに中継することができる。
クラウドコンピューティング環境に設けられたサービスの各々は、潜在的に異なるサービス管理者に関連付けられることができる。サービス管理者は、特定の識別ドメインにおいて、さまざまなサービスのサービス管理者役に関連付けられたユーザであってもよい。識別ドメインは、クラウドコンピューティング環境のような共有コンピューティング環境の論理パーティションである。このような論理パーティションは、コンピューティング環境内のハードウェア上で動作する識別ドメイン管理ソフトウェアによって互いに分離されている複数の論理パーティションのうち１つであってもよい。各識別ドメインは、潜在的に異なる顧客に関連付けられているコンピューティング環境内の共有ハードウェアおよびソフトウェアリソースの「スライス」とみなすことができる（これらの顧客は、そのスライスを使用する権利を得るために、費用を支払っている）。各識別ドメインは、アプリケーションソフトウェアサービスのユーザＩＤおよびインスタンス（場合によっては、同一のソフトウェアコードの異なる実行インスタンス）を含むことができる。識別ドメイン管理ソフトウェアは、ユーザが１つの識別ドメインからそのドメインに関連付けられていないサービスインスタンスにアクセスすることを防止することによって、および識別ドメインに関連付けられているサービスインスタンスがその識別ドメインに関連付けられているユーザＩＤにアクセスすることを防止することによって、識別ドメインを隔離することができる。
１人のユーザが１つのサービスのサービス管理者であってもよく、別のユーザが別のサービスのサービス管理者であってもよい。各サービスは、そのサービスに特有する関連セットの承認ポリシーを有してもよい。サービスのサービス管理者は、そのサービスの承認ポリシーを管理および設定することができる。サービスの承認ポリシーは、どのユーザまたはユーザロール（user role）がそのサービスに提供されたさまざまなリソースにアクセスすることが許可されたことを示すことができる。たとえば、特定のストレージサービス用の特定の承認ポリシーは、特定のユーザが特定のストレージサービスによって提供された特定のファイルにアクセスすることが許可されたことを示すことができる。別の例において、承認ポリシーは、ゴールドレベルの加入者およびプラチナレベルの加入者などの異なる種類の加入者用の異なるクォータ制限を示すことができる。
一実施形態によれば、クライアントアプリケーションからのトークンリクエストの受信に応答して、OAuth承認サーバは、サービスを提供するリソースサーバに保管されているポリシーエンジンを呼出すことができる。ポリシーエンジンは、サービスのサービス管理者によって管理されている。ポリシーエンジンは、トークンリクエストが有効であるか否かを判断し、判断結果をOAuth承認サーバに通知する。ポリシーエンジンがトークンリクエストが有効であることをOAuth承認サーバに通知した場合、OAuth承認サーバは、それに応答して、クライアントアプリケーションにトークンを返送する。このように、OAuthサーバは、フレームワークとして機能している。
本発明の一実施形態によれば、OAuth承認サーバが配置されているクラウドコンピューティング環境は、互いに分離された複数の別体の識別ドメインを含む。各識別ドメインは、別々のテナントまたは顧客、たとえば、異なる事業組織に関連付けられることができる。したがって、第一営業組織は、クラウドコンピューティング環境内の第一識別ドメインに排他的なアクセスを有する第一テナントであってもよく、第二営業組織は、クラウドコンピューティング環境内の第二識別ドメインに排他的なアクセスを有する第二テナントであってもよい。本発明の一実施形態において、クラウドコンピューティング環境を異なるテナント専用の独立識別ドメインに分割したことにも関わらず、すべての識別ドメインは、全体として、クラウドコンピューティング環境内の単一のOAuth承認サーバインスタンスを利用する。これによって、異なる識別ドメインの各々のために別々のOAuth承認サーバを提供する必要がなくなり、有利である。マルチ識別ドメインクラウドコンピューティング環境の詳細については、２０１３年３月１５日に出願され、「マルチテナンシアイデンティティ管理システム」と題された米国特許出願第１３／８３８８１３号および２０１３年９月５日に出願され、「ＬＤＡＰベースのマルチテナント・インクラウド・アイデンティティ管理システム」と題された米国特許出願第１４／０１９０５１号を参照する。米国特許出願第１３／８３８８１３号および第１４／０１９０５１号の両方の内容全体が、あらゆる目的で引用によりこの明細書中に援用される。
一実施形態によれば、クライアントアプリケーションは、互いに分離されている別々の識別ドメイン内に配置されている。それにもかかわらず、各クライアントアプリケーションは、サービスにアクセスするためのトークンを求めるときに、同一のクラウドOAuth承認サーバインスタンスにトークンをリクエストする。OAuth承認サーバは、その後、トークンリクエストを、トークンが属するサービスを提供するさまざまなリソースサーバに中継する。リソースサーバは、これらのリソースサーバが提供するサービスにアクセスするためのトークンの付与および生成を規制する承認ポリシーを保管する。各リソースサーバの承認ポリシーセットは、別のリソースサーバの承認ポリシーセットと異なってもよい。同一サービスのための承認ポリシーであっても、１つのテナントの承認ポリシーは、別のテナントの承認ポリシーとは異なる場合がある。したがって、一実施形態において、マルチテナント対応リソースサーバの各々は、複数の異なるセットの承認ポリシー保管することができる。これらの複数の異なるセットの承認ポリシーの各々は、異なるテナント専用の異なる識別ドメインに属する。
本発明の一実施形態において、単一のクラウドOAuth承認サーバは、クラウドコンピューティング環境を分割することによって形成された別体の識別ドメインの各々のために、OAuth承認サーバの仮想「スライス」を別々に保管している。OAuth承認サーバは、各「スライス」のために、スライス専用の識別ドメインに属する（OAuthサービスプロファイルとも呼ばれる）構成データを別々に保存することができる。したがって、OAuth承認サーバが１つの識別ドメインのために保管した１つのOAuthサービスプロファイルは、OAuth承認サーバが別の識別ドメインのために保管した別のOAuthサービスプロファイルとは異なってもよい。クラウドコンピューティング環境からサービスを受けているさまざまなテナントの観点から、OAuth承認サーバは、テナント自身のみを代理し、別のテナントを代理しないものである。しかしながら、これは、テナントにとってそのように見えるだけである。OAuth承認サーバが別々の識別ドメインに対して別々のOAuthサービスプロファイルを保管しているという事実は、テナントには分からない。OAuth承認サーバのマルチ識別ドメイン性質は、これらの識別ドメインを所有しているテナントには理解され難い。各々のテナントのクライアントアプリケーションは、テナント自身の計算機に実装された単一の識別ドメイン企業環境内のOAuth承認サーバと情報を交換することと同様の方法で、マルチ識別ドメインクラウドコンピューティング環境内のOAuth承認サーバと情報を交換することができる。マルチテナントOAuth承認サーバで動作可能にするために、さまざまなクライアントアプリケーションを変更する必要はない。
したがって、本発明の一実施形態において、OAuth承認サーバは、さまざまな識別ドメインと、これらの識別ドメイン用のOAuthサービスプロファイルと間のマッピング関係を保管している。OAuth承認サーバは、強化されると、特定の企業環境ではなく、別々の識別ドメインに分割されたクラウドコンピューティング環境の全体にも適用する。さまざまな異なる識別ドメインのクライアントアプリケーションはすべて、同一または類似の宛先もしくはエンドポイントを使用して、同一のOAuth承認サーバにアクセスすることができる。このような宛先は、たとえば、ＵＲＬの形にすることができる。異なるＵＲＬを使用して異なるOAuth承認サーバにアクセスするように、クライアントアプリケーションを構成する必要がない。一実施形態において、各識別ドメインのクライアントアプリケーションに使用され、単一のクラウドOAuth承認サーバにアクセスするＵＲＬは、同一のサフィックスを有するが、識別ドメインを識別する異なるプレフィックスを有する。OAuth承認サーバは、この識別ドメインプレフィックスを使用して、サーバに保管された複数セットのOAuthサービスプロファイルから、トークンリクエストを送信した特定のクライアントアプリケーションに適用される特定のOAuthサービスプロファイルを決定することができる。
一実施形態において、単一のクラウドマルチテナントOAuth承認サーバは、同様に、トークンリクエストを、リクエストが属するサービスを提供するリソースサーバに中継する。リソースサーバにより提供されるサービスを管理する承認ポリシーは、OAuth承認サーバではなく、これらのリソースサーバに保管される。これらの承認ポリシーは、さまざまな異なるユーザロールに付与されるさまざまなレベルのリソースアクセス権（たとえば、読出しクォータ、書込みクォータ、削除クォータなど）を示すことができる。リソースサーバは、特定の識別ドメインに専用することができる。この場合、リソースサーバは、単一の識別ドメインに適用可能な承認ポリシーを保管するサーバであってもよく、異なる識別ドメインに適用できる異なるセットの承認ポリシーを保管するマルチテナント対応サーバであってもよい。
上述したように、本発明の一実施形態において、単一のOAuth承認サーバは、１つの識別ドメインが１つのOAuthサービスプロファイルを有するように、複数の異なるOAuthサービスプロファイルを保管している。本発明の一実施形態において、特定の識別ドメイン用のOAuthサービスプロファイルは、クライアントアプリケーションをリソースサーバに結び付けているため、各クライアントアプリケーションがアクセス可能なリソースサーバを示すことができる。一部のクライアントアプリケーションは、一部のリソースサーバにアクセスできないことがある。１つのOAuthサービスプロファイルデータに指定されたアプリケーション−サーバ結び付け関係は、別のOAuthサービスプロファイルデータに指定されたアプリケーション−サーバ結び付け関係とは異なってもよい。これによって、異なる識別ドメインで動作する特定のクライアントアプリケーションの各々のインスタンスは、同一のリソースサーバにアクセスする権利を有しない。
一実施形態によれば、複数のOAuthサービスプロファイルを別々に生成し、同一の識別ドメインに関連付けることができる。たとえば、人事（ＨＲ）用のOAuthサービスプロファイルは、ＨＲクライアントアプリケーションが特定テナントの識別ドメインに位置するＨＲリソースサーバにアクセスできることを示し、マーケティング用のOAuthサービスプロファイルは、マーケティングクライアントアプリケーションが同一の特定テナントの識別ドメインに位置するマーケティングリソースサーバにアクセスできることを示すことができる。
一実施形態において、クラウドOAuth承認サーバは、クライアントアプリケーションからトークンリクエストの受信に応答して、特定のOAuthサービスプロファイルに指定された結び付け関係を調べる。たとえば、OAuth承認サーバは、クライアントアプリケーションが動作する識別ドメインに関連付けられたOAuthサービスプロファイルにより指定された結び付け関係を調べることができる。OAuth承認サーバは、結び付け関係に基づいて、クライアントアプリケーションがリクエストトークンに関連するリソースサーバと通信できるか否かを決定する。特定のOAuthサービスプロファイルがクライアントアプリケーションがリソースサーバに結び付けられていないことを示した場合、リクエストは、拒否され、クライアントアプリケーションは、リソースサーバと情報を交換しない。
一方、特定のOAuthサービスプロファイルがクライアントアプリケーションがリソースサーバに結び付けられていることを示した場合、OAuth承認サーバは、特定のOAuthサービスプロファイルから、リソースサーバ用のコールバックＵＲＬを決定する。OAuth承認サーバは、このＵＲＬを使用して、リクエストされたリソースに対して許可されたクライアントアプリケーションおよび／またはユーザのアクセス範囲（たとえば、クォータ）に関する照会をリソースサーバに送信する。その照会に応答して、リソースサーバは、承認ポリシーをリクエストパラメータ（たとえば、クライアントアプリケーションＩＤ、ユーザＩＤ、リソースＩＤ）に適用することによって、（アクセスが許可された場合に）許可すべきアクセス範囲を決定することができる。リソースサーバは、アクセス範囲情報をOAuth承認サーバに返信することができる。代替的には、OAuth承認サーバは、リソースサーバからリソースサーバの承認ポリシーを取得し、承認ポリシーのコピーをローカルに保存し、これらの承認ポリシーを適用することによって、許可されるべきアクセス範囲を決定することができる。OAuth承認サーバは、アクセス範囲情報に基づいて、適切なトークンを生成し、クライアントアプリケーションからのトークンリクエストに応答して、生成したトークンをクライアントアプリケーションに提供することができる。よって、クライアントアプリケーションは、リソースサーバが提供するサービスへのアクセスを求めているときに、このトークンをリソースサーバに提示することができる。リソースサーバは、トークンに含まれたアクセス範囲情報に基づいて、クライアントアプリケーションのサービスアクセス権を制限することができる。
図４は、本発明の一実施形態に従った方法の一例を示すフローチャートである。複数の識別ドメインを有するクラウドベースコンピューティング環境に存在するOAuth承認サーバは、この技術を用いて、別々の独立している識別ドメインに動作する異なるアプリケーションを承認するためのトークンを生成することができる。ブロック４０２において、OAuth承認サーバは、複数の独立している識別ドメインのうち、第一識別ドメイン内で動作する第一クライアントアプリケーションから、リクエストを受信する。ブロック４０４において、OAuth承認サーバは、保管している複数のOAuthサービスプロファイルから、第一識別ドメインのみに適用できる第一OAuthサービスプロファイルを選択する。ブロック４０６において、OAuth承認サーバは、第一OAuthサービスプロファイルに基づいて、第一クライアントアプリケーションが第一リソースサーバにアクセスする許可を有するか否かを決定する。ブロック４０８において、OAuth承認サーバは、第一クライアントアプリケーションが第一リソースサーバにアクセスする許可を有するという決定に応答して、OAuth承認サーバが第一リソースサーバから取得した範囲情報に基づいて、第一クライアントアプリケーションに第一トークンを生成する。ブロック４１０において、OAuth承認サーバは、複数の独立している識別ドメインのうち、第二識別ドメイン内で動作する第二クライアントアプリケーションから、リクエストを受信する。第二識別ドメインは、第一識別ドメインと別体である。ブロック４１２において、OAuth承認サーバは、保管している複数のOAuthサービスプロファイルから、第二識別ドメインのみに適用できる第二OAuthサービスプロファイルを選択する。ブロック４１４において、OAuth承認サーバは、第二OAuthサービスプロファイルに基づいて、第二クライアントアプリケーションが第二リソースサーバにアクセスする許可を有するか否かを決定する。ブロック４１６において、OAuth承認サーバは、第二クライアントアプリケーションが第二リソースサーバにアクセスする許可を有するという決定に応答して、OAuth承認サーバが第二リソースサーバから取得した範囲情報に基づいて、第二クライアントアプリケーションに第二トークンを生成する。
図５は、本発明の一実施形態に従って、クラウドOAuth承認サーバの一例を示すブロック図である。このクラウドOAuth承認サーバは、異なる識別ドメインを有し、クラウドにより提供されたサービスに別々の企業からのクライアントを承認するために、これらのクライアントと情報を交換する。図５には、別々の企業５１０Ａおよび５１０Ｂが示されている。企業５１０Ａおよび５１０Ｂは、関係のない異なる事業組織であってもよい。企業５１０Ａおよび５１０Ｂの各々は、本明細書に説明したクラウドコンピューティングサービスの別々の顧客であってもよい。企業５１０Ａは、複数のクライアント、たとえばクライアント５１２ＡＡおよびクライアント５１２ＡＢを含む。クライアント５１２ＡＡおよび５１２ＡＢは、企業５１０Ａ内の異なるユーザに関連付けられることができ、これらのユーザによって操作されることができる。各ユーザは、企業５１０Ａに一意に関連付けられた識別ドメイン内に保存された独自のＩＤを有する。ユーザの各々は、企業５１０Ａに対して一意に定義された職務階層において別々の職務に関連付けられることができる。同様に、企業５１０Ｂは、複数のクライアント、たとえばクライアント５１２ＢＡおよびクライアント５１２ＢＢを含む。クライアント５１２ＢＡおよび５１２ＢＢは、企業５１０Ｂ内の異なるユーザに関連付けられることができ、これらのユーザによって操作されることができる。各ユーザは、企業５１０Ｂに一意に関連付けられた識別ドメイン内に保存された別々のＩＤを有する。ユーザの各々は、企業５１０Ｂに対して一意に定義された職務階層において別々の職務に関連付けられることができる。
クライアント５１２ＡＡ、５１２ＡＢ、５１２ＢＡおよび５１２ＢＢの各々は、クラウドOAuth承認サーバ５０２と情報を交換することができる。このクラウドOAuth承認サーバ５０２は、クライアントが属する企業または識別ドメインに問わず、クラウドコンピューティング環境内のすべてのクライアントにサービスを提供する。クライアント５１２ＡＡ、５１２ＡＢ、５１２ＢＡおよび５１２ＢＢの各々は、インターネット５１４を介して、クラウドOAuth承認サーバ５０２に、（ａ）そのクライアントのユーザの資格情報と（ｂ）そのクライアントがアクセスしたいクラウドベースサービスとを指定する承認トークンリクエストを送信することができる。クラウドOAuth承認サーバ５０２は、インターネット５１４を介して、その承認トークンリクエストを受信する。各承認トークンリクエストに応じて、クラウドOAuth承認サーバ５０２は、承認トークンリクエストを発信したクライアントに関連付けられている識別ドメインを決定することができる。たとえば、クラウドOAuth承認サーバ５０２は、保存されたマッピング関係データに基づいて、クライアント５１２ＡＡおよび５１２ＡＢ（およびそれらに関連するユーザ）が企業５１０Ａに属しており、したがって企業５１０Ａに一意に対応する第一識別ドメインに属していることを決定することができる。この例を続けると、クラウドOAuth承認サーバ５０２は、保存されたマッピング関係データに基づいて、クライアント５１２ＢＡおよび５１２ＢＢ（およびそれらに関連するユーザ）が企業５１０Ｂに属しており、したがって企業５１０Ｂに一意に対応する第一識別ドメインに属していることを決定することができる。
本実施の一実施形態において、クラウドOAuth承認サーバ５０２は、ドメインサービスプロファイル５０４Ａおよびドメインサービスプロファイル５０４Ｂのような複数の異なるドメインサービスプロファイルを保存する。ドメインサービスプロファイルの各々は、異なる識別ドメインに一意に関連付けられることができる。特定のクライアント（およびそれに関連するユーザ）が属する特定の識別ドメインを決定するときに、クラウドOAuth承認サーバ５０２は、サーバ５０２に保存されているいくつかの異なるドメインサービスプロファイルから、特定の識別ドメインに一意に対応するドメインサービスプロファイルを決定することができる。たとえば、クライアント５１２ＡＡおよび５１２ＡＢが（たとえば、企業５１０Ａが所有する）第一識別ドメインに関連付けられているという決定に応じて、クラウドOAuth承認サーバ５０２は、第一識別ドメインに関連付けられたドメインサービスプロファイル５０４Ａを用いて、クライアント５１２ＡＡおよび５１２ＡＢからの承認トークンリクエストを処理すべきことを決定することができる。たとえば、クライアント５１２ＡＡおよび５１２ＡＢが（たとえば、企業５１０Ｂが所有する）第二識別ドメインに関連付けられているという決定に応じて、クラウドOAuth承認サーバ５０２は、第二識別ドメインに関連付けられたドメインサービスプロファイル５０４Ｂを用いて、クライアント５１２ＡＡおよび５１２ＡＢからの承認トークンリクエストを処理すべきことを決定することができる。
一実施形態において、ドメインサービスプロファイル５０４Ａおよび５０４Ｂの各々は、異なるセットのクライアント−サービス結び付け関係を含む。各々のクライアント−サービス結び付け関係は、特定のクライアントが（特定のリソースサーバによって提供される）特定のサービスに対する（任意範囲の）アクセス権を有するか否かを特定することができる。たとえば、ドメインサービスプロファイル５０４Ａは、クライアント−サービス結び付け関係５０６ＡＡおよび５０６ＡＢを含むことができる。たとえば、ドメインサービスプロファイル５０４Ｂは、クライアント−サービス結び付け関係５０６ＢＡおよび５０６ＢＢを含むことができる。この例において、クライアント−サービス結び付け関係５０６ＡＡは、クライアント５１２ＡＡがリソースサーバ５１６Ａによって提供されたサービスへのアクセスを許可されていることを示しており、クライアント−サービス結び付け関係５０６ＡＢは、クライアント５１２ＡＢがリソースサーバ５１６Ｂによって提供されたサービスへのアクセスを許可されていることを示す。同様に、クライアント−サービス結び付け関係５０６ＢＡは、クライアント５１２ＢＡがリソースサーバ５１６Ａによって提供されたサービスへのアクセスを許可されていることを示しており、クライアント−サービス結び付け関係５０６ＢＢは、クライアント５１２ＡＢがリソースサーバ５１６Ｂによって提供されたサービスへのアクセスを許可されていることを示す。
一実施形態において、特定のクライアントと特定のサービスとの間に結び付け関係が存在しないことは、特定のクライアントが特定のサービスのアクセスに許可されていないことを示す決定的な証拠である。別の実施形態において、結び付け関係は、特定のクライアントが特定のサービスにアクセスできるか否かを明示的示すことができる。一実施形態において、特定のクライアントが特定のクライアントからの承認トークンリクエストに指定されたサービスにアクセスできないという決定に応じて、クラウドOAuth承認サーバ５０２は、インターネット５１４を介して、承認トークンリクエストを拒否する指示を特定のクライアントに返送することができる。一実施形態において、クライアント−サービス結び付け関係は、テナント（たとえば、企業５１０Ａおよび５１０Ｂ）からのサービスを利用する申込みに応じて作成され、結び付け関係に指定されたサービスは、テナントの識別ドメインに配置される。したがって、このような実施形態において、特定のテナントが特定のサービスの利用を購入または取得しない場合、そのテナントのクライアント（またはそのユーザ）と特定のサービスとの間には、クライアント−サービス結び付け関係が存在しない。
一実施形態において、クラウドOAuth承認サーバ５０２は、さらに、クラウドコンピューティング環境内において、サービスを提供するリソースサーバ用のサービスコールバックＵＲＬを別々に保存する。図示された例において、クラウドOAuth承認サーバ５０２は、リソースサーバ５１６Ａ用のサービスコールバックＵＲＬ ５０８Ａと、リソースサーバ５１６Ｂ用のサービスコールバックＵＲＬ ５０８Ｂとを保存している。承認トークンリクエストに指定されたクライアント（またはそのユーザ）およびサービスの両方を特定する特定のクライアント−サービス結び付け関係を特定のクライアントが属する識別ドメイン用のドメインサービスプロファイルに位置させることに応じて、クラウドOAuth承認サーバ５０２は、そのサービスを提供する特定のリソースサーバのサービスコールバックＵＲＬを決定する。その後、クラウドOAuth承認サーバ５０２は、インターネット５１４を介して、承認トークンリクエストをそのサービスコールバックＵＲＬを有するリソースサーバに転送する。インターネット５１４内のドメインネームサーバおよびルータは、サービスコールバックＵＲＬを使用して、承認トークンリクエストをクラウドコンピューティング環境内の適切なリソースサーバにルーティングする。
一実施形態において、リソースサーバ５１６Ａおよび５１６Ｂの各々は、ポリシーエンジンを含むまたはポリシーエンジンを実行する。たとえば、リソースサーバ５１６Ａは、ポリシーエンジン５１８Ａを実行することができ、リソースサーバ５１６Ｂは、ポリシーエンジン５１８Ｂを実行することができる。ポリシーエンジン５１８Ａおよび５１８Ｂの各々は、同一のポリシーエンジンコードを有する異なる実行インスタンスであってもよい。ポリシーエンジン５１８Ａおよび５１８Ｂの各々は、複数セットのポリシー含むまたは複数セットのポリシーにアクセスすることができる。各セットのポリシーは、異なる識別ドメインに属することができる。たとえば、ポリシーエンジン５１８Ａは、第一識別ドメイン（すなわち、企業５１０Ａ）に属するポリシー５２０ＡＡにアクセスすることができ、および／または第二識別ドメイン（すなわち、企業５１０Ｂ）に属するポリシー５２０ＡＢにアクセスすることができる。同様に、ポリシーエンジン５１８Ｂは、第一識別ドメイン（すなわち、企業５１０Ａ）に属するポリシー５２０ＢＡにアクセスすることができ、および／または第二識別ドメイン（すなわち、企業５１０Ｂ）に属するポリシー５２０ＢＢにアクセスすることができる。各リソースサーバのポリシーは、異なってもよい。異なる識別ドメインのポリシーは、同一リソースサーバに対しても互いに異なることができる。したがって、ソースサーバ５１６Ａに対してクライアント５１２ＡＡおよび５１２ＡＢを管理するポリシーは、ソースサーバ５１６Ａに対してクライアント５１２ＢＡおよび５１２ＢＢを管理するポリシーと異なってもよい。同様に、ソースサーバ５１ＢＡに対してクライアント５１２ＡＡおよび５１２ＡＢを管理するポリシーは、ソースサーバ５１６Ｂに対してクライアント５１２ＢＡおよび５１２ＢＢを管理するポリシーと異なってもよい。
クラウドOAuth承認サーバ５０２がインターネット５１４を介して転送してきた承認トークンリクエストの受信に応答して、受信側のリソースサーバは、ポリシーエンジンを呼出すことによって、承認トークンリクエストに指定された特定のクライアント（またはユーザ）の識別ドメインに適用される特定セットのポリシーを決定することができる。たとえば、クライアント５１２ＡＡまたはクライアント５１２ＡＢを指定する承認トークンリクエストの受信に応答して、ポリシーエンジン５１８Ａは、承認トークンリクエストに属するポリシー５２０ＡＡを決定することができる。クライアント５１２ＢＡまたはクライアント５１２ＢＢを指定する承認トークンリクエストの受信に応答して、ポリシーエンジン５１８Ａは、承認トークンリクエストに属するポリシー５２０ＡＢを決定することができる。例を続けると、クライアント５１２ＡＡまたはクライアント５１２ＡＢを指定する承認トークンリクエストの受信に応答して、ポリシーエンジン５１８Ｂは、承認トークンリクエストに属するポリシー５２０ＢＡを決定することができる。クライアント５１２ＢＡまたはクライアント５１２ＢＢを指定する承認トークンリクエストの受信に応答して、ポリシーエンジン５１８Ｂは、承認トークンリクエストに属するポリシー５２０ＢＢを決定することができる。
一実施形態において、特定のポリシーエンジンは、その特定のポリシーエンジンを実行するリソースサーバによって提供されたサービスに加入している各テナントのユーザＩＤストアにアクセスする権利を有する。よって、ポリシーエンジンは、ユーザＩＤストアから、承認トークンリクエストに指定されたクライアントまたはユーザの属性を取得することができる。その後、ポリシーエンジンは、認可トークンリクエストに属するポリシーセットから、承認トークンリクエストに指定されたサービスに適用するポリシーを選択することができる。選択されたポリシーは、さまざまなクライアント属性またはユーザ属性に対して、さまざまなアクセス範囲を指定することができる。ポリシーエンジンは、ユーザＩＤストアから読取られるＩＤに関連する属性を基準にして、選択されたポリシーを評価することができる。評価の結果、ポリシーエンジンは、承認トークンリクエストに指定されたサービスを利用するときに、リクエストをするクライアント（およびクライアントユーザ）に許可されるアクセス範囲（たとえば、どのリソースに対して、どの操作が許可されること）を決定することができる。ポリシーエンジンを呼出したリソースサーバは、インターネット５１４を介して、承認トークンリクエストに指定されたクライアント（またはそのユーザ）に許可されたアクセス範囲を示す情報をクラウドOAuth承認サーバ５０２に返送することができる。たとえば、ポリシーエンジン５１８Ａは、ポリシー５２０ＡＡの一部に基づいて、クライアント５１２ＡＡがリソースサーバ５１６Ａにより提供されたサービスに対して第一アクセス範囲を有し、クライアント５１２ＡＢがリソースサーバ５１６Ａにより提供されたサービスに対して第二アクセス範囲を有することを決定することができる。ポリシーエンジン５１８Ａは、ポリシー５２０ＡＢの一部に基づいて、クライアント５１２ＢＡがリソースサーバ５１６Ａにより提供されたサービスに対して第三アクセス範囲を有し、クライアント５１２ＢＢがリソースサーバ５１６Ａにより提供されたサービスに対して第四アクセス範囲を有することを決定することができる。例を続けると、ポリシーエンジン５１８Ｂは、ポリシー５２０ＢＡの一部に基づいて、クライアント５１２ＡＡがリソースサーバ５１６Ｂにより提供されたサービスに対して第五アクセス範囲を有し、クライアント５１２ＡＢがリソースサーバ５１６Ｂにより提供されたサービスに対して第六アクセス範囲を有することを決定することができる。ポリシーエンジン５１８Ｂは、ポリシー５２０ＢＢの一部に基づいて、クライアント５１２ＢＡがリソースサーバ５１６Ｂにより提供されたサービスに対して第七アクセス範囲を有し、クライアント５１２ＢＢがリソースサーバ５１６Ｂにより提供されたサービスに対して第八アクセス範囲を有することを決定することができる。前述の例に言及された第一アクセス範囲〜第八アクセス範囲は、互いに異なってもよい。
クラウドOAuth承認サーバ５０２は、インターネット５１４を介して、リソースサーバ５１６Ａおよび５１６Ｂから、サーバ５０２がこれらのリソースサーバに転送してきたさまざまな承認トークンリクエストに関連するアクセス範囲を示す情報を受信することができる。アクセス範囲を示す情報の受信に応答して、クラウドOAuth承認サーバ５０２は、リソースサーバによって提供されたサービスに対して、リソースサーバから受信したアクセス範囲と同様なアクセス範囲を有することを指定する承認トークンを生成することができる。クラウドOAuth承認サーバ５０２は、インターネット５１４を介して、承認トークンをサーバ５０２が過去に対応する承認トークンのリクエストを受信したクライアント５１２ＡＡ、５１２ＡＢ、５１２ＢＡ、および５１２ＢＢに返送することができる。クライアント５１２ＡＡ、５１２ＡＢ、５１２ＢＡおよび５１２ＢＢは、インターネット５１４を介して、これらの承認トークンを受信して、リソースサーバ５１６Ａおよび５１６Ｂからサービスをリクエストするときに、これらのリソースサーバに承認トークンを提示することができる。リソースサーバ５１６Ａおよび５１６Ｂは、承認トークンに含まれたアクセス範囲を検証することによって、リクエストをしたクライアントがサービスを利用し、指定のリソースに対して特定の操作を実行する権利を有するか否かを判断することができる。
上述した実施形態において、リソースサーバ５１６Ａおよび５１６Ｂは、ポリシーエンジン５１６Ａおよび５１６Ｂをそれぞれ実行し、アクセス範囲を示す情報をクラウドOAuth承認サーバ５０２に返送する。クラウドOAuth承認サーバ５０２は、アクセス範囲に基づいて、承認トークンを生成する。しかしながら、本発明の代替的な実施形態において、アクセス範囲を示す情報をクラウドOAuth承認サーバ５０２に返送する代わりに、リソースサーバ５１６Ａおよび５１６Ｂは、各識別ドメインに適用可能な実際のポリシー（たとえば、リソースサーバ５１６Ａの場合、ポリシー５２０ＡＡおよび５２０ＡＢ、およびリソースサーバ５１６Ｂの場合、ポリシー５２０ＢＡおよび５２０ＢＢ）をサーバ５０２に登録することができる。本発明のこの代替的な実施形態において、クラウドOAuth承認サーバ５０２自体は、クラウドＩＤストアから取得したクライアント（またはユーザ）の属性に対して、適用可能なサブセット内のポリシーを評価することができる。したがって、このような代替的な実施形態において、クラウドOAuth承認サーバ５０２自身は、評価結果に基づいて、リクエストを要求したクライアントに返送される承認トークンに指定されたアクセス範囲を決定することができる。このような代替的な実施形態において、クラウドOAuth承認サーバ５０２は、承認トークンリのクエストをリソースサーバに転送する必要はない。
バンドルされた承認リクエスト
典型的には、特定のユーザを代理してサービスを要求するクライアントアプリケーションは、そのユーザのために複数の異なるサービスへのアクセスを要求することになる。たとえば、クライアントアプリケーションは、ストレージサービス、ドキュメントサービス、およびメッセージングサービスへのアクセスを要求する可能性がある。これらのサービスは、異なるリソースサーバによって提供される可能性がある。強化されない場合、クライアントアプリケーションは、OAuth承認サーバに３つのトークンリクエストを別々に送信することになる。たとえ、特定のユーザを代理して最終的に３つのサービスのすべてが要求されるだろうという予見をクライアントアプリケーションが有しても、このことは妥当する。
このような非効率的な処理を回避するために、本発明の一実施形態において、クライアントアプリケーションは、異なるリソースサーバから提供された異なるサービスを要求する複数のアクセスリクエストを単一のトークンリクエストにバンドルして、この単一のトークンリクエストをOAuth承認サーバに発行することができる。このバンドルリクエストに応じて、OAuth承認サーバは、要求されたサービスを提供するリソースサーバの各々から、承認決定を取得することができる。その後、OAuth承認サーバは、各リソースサーバからの承認決定によるアクセス範囲情報を含む単一トークンを生成することができる。OAuth承認サーバは、この単一トークンをクライアントアプリケーションに返送することができる。これにより、クライアントアプリケーションは、このトークンを、バンドルリクエストに要求されたサービスのいずれかを提供するリソースサーバに提示することができる。
図７は、本発明の一実施形態に従って、複数のリソースサーバからサービスを要求するために使用可能な単一トークンを生成するための方法の一例を示すフローチャートである。ブロック７０２において、OAuth承認サーバは、クライアントアプリケーションから、複数のサービスを指定するトークンリクエストを受信する。ブロック７０３において、トークンリクエストの受信に応答して、OAuth承認サーバは、新規のマルチサービストークンを作成する。ブロック７０４において、OAuth承認サーバは、現在のサービスをトークンリクエストにより指定された第一サービスとして設定する。ブロック７０６において、OAuth承認サーバは、リソースサーバ群から、現在のサービスを提供する特定のリソースサーバを選択する。ブロック７０８において、OAuth承認サーバは、特定のリソースサーバから取得した範囲情報に基づいて、現在のサービスに対して許可されたクライアントアプリケーションのアクセス範囲を決定する。ブロック７１０において、OAuth承認サーバは、現在のサービスのアクセス範囲を示すデータをマルチサービストークンに追加する。ブロック７１２において、OAuth承認サーバは、アクセス範囲データがまだマルチサービストークンに追加されていないさらなるサービスがトークンリクエストに指定されているか否かを決定する。肯定の場合、制御は、ブロック７１４に進み、否定の場合、制御は、ブロック７１６に進む。
ブロック７１４において、OAuth承認サーバは、現在のサービスをトークンリクエストにより指定された次のサービスとして設定する。その後、制御は、ブロック７０６に戻る。
代替的には、ブロック７１６において、OAuth承認サーバは、マルチサービストークンをクライアントアプリケーションに返送する。その後、図７を参照して説明した方法は、終了する。
プラガブル承認ポリシー
一実施形態において、OAuth承認サーバは、リソースサーバによって提供されるサービスのアクセス範囲を決定する必要がない。このような実施形態において、リソースサーバは、各自保管している承認ポリシーに基づいて、アクセス範囲を決定し、OAuth承認サーバは、これらの決定に基づいて決定したアクセス範囲を指定するトークンを生成する。OAuth承認サーバは、アクセス範囲を決定するために、リソースサーバにコールバックを行うことができる。その結果、テナントは、識別ドメインに配置されたリソースサーバ内の承認ポリシーを設定することによって、所望の承認ポリシーをOAuth承認システムに「プラグイン」することができる。
図８Ａおよび８Ｂは、本発明の一実施形態に従って、リソースサーバにより保管された承認ポリシーをOAuth承認サーバにプラグインするための方法の一例を示すフローチャート図である。図８Ａを参照して、ブロック８０２において、リソースサーバは、特定の識別ドメインから、サービス管理者からの承認ポリシーを受信する。リソースサーバにおいて、異なる識別ドメインのサービス管理者が異なってもよい。ブロック８０４において、承認ポリシーの受信に応答して、リソースサーバは、サービス管理者が駐在する識別ドメインを決定する。ブロック８０６において、リソースサーバは、承認ポリシーと識別ドメインとの間のマッピング関係を保存する。ブロック８０８において、OAuth承認サーバは、識別ドメインの承認管理者から、リソースサーバのＵＲＬを指定するプラグイン命令を受信する。ブロック８１０において、プラグイン命令の受信に応答して、OAuth承認サーバは、承認管理者が駐在する識別ドメインを決定する。ブロック８１２において、OAuth承認サーバは、識別ドメインとリソースサーバのＵＲＬとの間のマッピング関係を保存する。
次に図８Ｂを参照して、ブロック８１４において、OAuth承認サーバは、特定の識別ドメイン内のクライアントアプリケーションから、トークンリクエストを受信する。ブロック８１６において、トークンリクエストの受信に応答して、OAuth承認サーバは、複数の潜在的に異なるＵＲＬから、クライアントアプリケーションを備える特定の識別ドメインにマッピングされた特定のＵＲＬを選択する。ブロック８１８において、OAuth承認サーバは、特定のＵＲＬを有するリソースサーバから範囲情報を要求する。リクエストは、特定の識別ドメインおよびクライアントアプリケーションを表示してもよい。ブロック８２０において、特定のＵＲＬを有するリソースサーバは、複数の潜在的に異なる承認ポリシーから、特定の識別ドメインにマッピングされた特定の承認ポリシーを選択する。ブロック８２２において、リソースサーバは、クライアントアプリケーションのＩＤおよび特定の承認ポリシーに基づいて、アクセス範囲情報を生成する。アクセス範囲情報は、クライアントアプリケーションがリソースサーバが提供するサービスに対して有するアクセス範囲（たとえば、許可操作および禁止操作）を示す。ブロック８２４において、リソースサーバは、アクセス範囲情報をOAuth承認サーバに返送する。ブロック８２６において、OAuth承認サーバは、アクセス範囲情報を指定するトークンを生成する。ブロック８２８において、OAuth承認サーバは、トークンをクライアントアプリケーションに返送する。
OAuthリクエストの拡張フォーマットおよびカスタムトークンの属性
一実施形態において、トークンリクエストは、標準OAuth仕様に含まれないデータ項目を含むことができる。OAuth承認システムの性能を増強するために、標準OAuth仕様を超えるようにトークンリクエストのフォーマットを拡張することができる。たとえば、トークンリクエストは、OAuth承認サーバからトークンをリクエストするクライアントアプリケーションによって代理された人間ユーザに属する属性値を含むことができる。リソースサーバは、これらの属性値に基づいてアクセス範囲を決定するため、これらの属性値を取得することが有利である。したがって、トークンリクエストに含み得る情報を拡張すると、リソースサーバは、より洗練されたアクセス範囲を決定することができる。リソースサーバによって保管されている承認ポリシーは、これらの属性を含むより洗練された条件を指定することができる。そうでない場合、これらの属性は、リソースサーバに利用できないため、取入れることがないだろう。クライアントアプリケーションの属性に関連する基準に限定されず、承認ポリシーは、人間ユーザの属性に関連する条件を指定することができる。これらの人間ユーザの属性は、識別ドメインによって区分されたＬＤＡＰベースのＩＤストアに保管されることができる。
一実施形態において、OAuth承認サーバは、ユーザ属性をトークンに挿入することができる。OAuth承認サーバは、ＬＤＡＰディレクトリに保存され得るユーザプロファイルから、ユーザ属性を取得することができる。OAuth承認サーバは、ユーザ属性を含むトークンをクライアントアプリケーションに送信することができる。これによって、クライアントアプリケーションは、そのトークンをリソースサーバに提示することができる。リソースサーバは、トークンに含まれたユーザ属性の少なくとも一部に基づいて、ポリシーを決定することができる。たとえば、リソースサーバは、承認決定を下すために、ユーザのサブスクリプション識別子を知る必要がある。サブスクリプション識別子は、ユーザのプロファイルに保存されることができる。トークンを生成する際に、OAuth承認サーバは、ディレクトリからユーザのプロファイル情報を読取ることができる。OAuth承認サーバは、ユーザのプロファイル情報から、サブスクリプション識別子を読取ることができる。
一実施形態において、OAuth承認サーバは、OAuth管理者定義した構成情報に基づいて、OAuth承認サーバから生成された各トークンに挿入する必要があるユーザ属性などの外部情報の種類を決定する。OAuth承認サーバは、指定情報を取得し、サーバから生成された各トークンに挿入する。OAuth承認サーバは、任意のサービスから情報を取得することができ、取得した情報をトークンに挿入することができる。ユーザ属性情報は、取得および挿入することができる情報の一種である。OAuth承認サーバは、ＬＤＡＰディレクトリ以外のソースから、情報を得ることができる。たとえば、OAuth承認サーバは、ウェブサービスまたは他の実行中のプログラムから、情報を得ることができる。
図６は、本発明の一実施形態に従って、ユーザ特有属性を用いてトークンを拡張するための方法の一例を示すフローチャートである。ブロック６０２において、OAuth承認サーバは、管理者により定義されたユーザ属性セットを指定する構成情報を受信する。たとえば、ユーザ属性セットは、部門および安全性レベルなどを含むことができる。留意すべきことは、部門および安全性レベルなどは、属性の名前であり、特定値ではないことである。ブロック６０４において、OAuth承認サーバは、管理者定義の構成情報を保存する。ブロック６０６において、OAuth承認サーバは、クライアントアプリケーションからトークンリクエストを受信する。ブロック６０８において、OAuth承認サーバは、トークンリクエストに基づいて、ユーザのＩＤを決定する。ブロック６１０において、OAuth承認サーバは、トークンリクエストに基づいて、アクセス範囲を決定する。たとえば、OAuth承認サーバは、上述した方法を使用して、リソースサーバから提供された承認ポリシーに基づいて、アクセス範囲を決定することができる。ブロック６１２において、OAuth承認サーバは、リポジトリから、識別されるユーザの構成情報指定属性値を取得する。ブロック６１４において、OAuth承認サーバは、（ａ）識別されるユーザの構成情報属性値および（ｂ）アクセス範囲の両方を新規トークンに挿入する。ブロック６１６において、OAuth承認サーバは、トークンリクエストに応じて、新規トークンをクライアントアプリケーションに返送する。その後、リソースサーバによって提供されたリソースにアクセスするためのリクエストとともにクライアントアプリケーションから提供されたトークンに指定されたユーザ属性値の少なくとも一部に基づいて、承認を決定することができる。
多様なクライアントプロファイルリポジトリを可能にするクライアントプラグイン
クラウドコンピューティング環境内の各テナントは、異なる識別ドメインに配置された複数のクライアントアプリケーションを有することができる。各クライアントアプリケーションは、クライアントプロファイルを有することができる。一部のテナントは、クライアントプロファイルをＬＤＡＰディレクトリ内に保存して欲しい可能性がある。他のテナントは、クライアントプロファイルを構成ファイル内に保存して欲しい可能性がある。別のテナントは、にクライアントプロファイルをデータベース内に保存して欲しい可能性がある。本発明の一実施形態において、OAuth承認サーバは、プラガブル実装をクライアントに提供する。テナントのクライアントプロファイルを保存するリポジトリは、各々のテナントに基づいて、構成されることができる。
クライアントアプリケーションは、リクエストを行うときに、承認手順の前にクライアントアプリケーションを認証するために使用される識別子およびパスワードをOAuth承認サーバに提供する。OAuth承認サーバは、クライアントアプリケーションの識別子およびパスワードを適切なプラグインに中継することができる。これにより、クライアントアプリケーションを認証することができる。プラグインは、リポジトリの形式に関係なく、クライアントアプリケーションのプロファイルを保存しているリポジトリにアクセスすることができる。一実施形態において、OAuth承認サーバは、各識別ドメインのために、その識別ドメインのクライアントプロファイルにアクセスできるプラグインの位置を示す構成情報を保存する。OAuth承認サーバは、この構成情報に基づいて、承認リクエストを適切なプラグインに中継することができる。
図９は、本発明の一実施形態に従って、認証リクエストをクライアント特有のユーザＩＤリポジトリにアクセスするクライアント特有のプラグインモジュールにルーティングするための方法の一例を示すフローチャートである。ブロック９０２において、OAuth承認サーバは、第一管理者から、第一種のユーザＩＤリポジトリ用の第一プラグインの第一ＵＲＬを受信する。たとえば、第一種のユーザＩＤリポジトリは、関係データベースであってもよい。OAuth承認サーバは、第一プラグインを利用する第一種のクライアントアプリケーションを特定する情報を第一管理者から受信することができる。ブロック９０４において、OAuth承認サーバは、第一種のクライアントアプリケーションと第一ＵＲＬとの間の第一マッピング関係を保存する。したがって、第一プラグインは、OAuth承認サーバに登録される。ブロック９０６において、OAuth承認サーバは、第二管理者から、第二種のユーザＩＤリポジトリ用の第二プラグインの第二ＵＲＬを受信する。たとえば、第二種のユーザＩＤリポジトリは、ＬＤＡＰディレクトリであってもよい。また、OAuth承認サーバは、第二プラグインを利用する第二種のクライアントアプリケーションを特定する情報を第二管理者から受信することができる。ブロック９０８において、OAuth承認サーバは、第二ＵＲＬと第二種のクライアントアプリケーションとの間の第二マッピング関係を保存する。したがって、第二プラグインは、OAuth承認サーバに登録される。
ブロック９１０において、OAuth承認サーバは、特定のクライアントアプリケーション種類を有する特定のクライアントアプリケーションから、ユーザ認証リクエストを受信する。ユーザ認証リクエストは、ユーザ名およびパスワードを指定することができる。ブロック９１２において、OAuth承認サーバは、特定のクライアントアプリケーション種類を指定する特定のマッピング関係（たとえば、第一マッピング関係または第二マッピング関係）を検索する。ブロック９１４において、OAuth承認サーバは、特定のマッピング関係に指定された特定のＵＲＬ（たとえば、第一ＵＲＬまたは第二ＵＲＬ）を決定する。ブロック９１６において、OAuth承認サーバは、特定のＵＲＬを有する特定のプラグイン（たとえば、第一プラグインまたは第二プラグイン）に、ユーザ認証リクエストを転送する。ブロック９１８において、特定のプラグインは、特定のプラグインがアクセスするように設計された特定種類のユーザＩＤリポジトリ（たとえば、第一種のユーザＩＤリポジトリまたは第二種のユーザＩＤリポジトリ）にアクセスする。ブロック９２０において、特定のプラグインは、転送されたユーザ認証リクエストに特定ユーザ名およびパスワードを用いて、特定種類のユーザＩＤリポジトリに含まれた情報に基づいて、特定のクライアントアプリケーションのユーザを認証する。一実施形態において、特定のプラグインは、認証試行の結果（成功または失敗）をOAuth承認サーバに通知することができる。
サービスプロファイル特有トークン属性
一実施形態によれば、OAuthサービスプロファイルレベルで、属性値を定義することができる。たとえば、OAuthサービスプロファイル内で、トークンタイムアウト値を定義することができる。OAuthサービスプロファイルは、すべてのトークンがプロファイルを使用するクライアントアプリケーションに発行された８時間後に無効になることを指定することができる。したがって、OAuth承認サーバは、OAuthサービスプロファイルを使用するクライアントアプリケーション用のトークンを生成するときに、発行してから８時間後に無効になるトークンを生成することができる。OAuthサービスプロファイルは、同一の属性に異なる値を指定することができる。よって、OAuth承認サーバが異なる識別ドメイン内のクライアントアプリケーションのために生成したトークンは、異なるタイムアウト値を有することができる。OAuthサービスプロファイルは各々、特有の属性値を有することができる。
図１０は、本発明の一実施形態に従って、識別ドメイン特有トークンの属性を有するトークンを生成するための方法の一例を示すフローチャートである。ブロック１００２において、OAuth承認サーバは、第一識別ドメインの管理者から、特定のトークン属性の第一値を指定する第一サービスプロファイルを受信する。たとえば、トークン属性を「タイムアウト」にすることができ、第一値を「８時間」にすることができる。ブロック１００４において、第一サービスプロファイルの受信に応答して、OAuth承認サーバは、第一サービスプロファイルと第一識別ドメインとの間の第一マッピング関係を保存する。ブロック１００６において、OAuth承認サーバは、第二識別ドメインの管理者から、特定のトークン属性の第二値を指定する第二サービスプロファイルを受信する。たとえば、トークン属性を同様に「タイムアウト」にすることができ、第二値を「１時間」にすることができる。ブロック１００８において、第二サービスプロファイルの受信に応答して、OAuth承認サーバは、第二サービスプロファイルと第二識別ドメインとの間の第二マッピング関係を保存する。
ブロック１０１０において、OAuth承認サーバは、特定の識別ドメインに含まれたクライアントアプリケーションから、トークンリクエストを受信する。ブロック１０１２において、OAuth承認サーバは、保存されたマッピング関係に基づいて、特定の識別ドメインにマッピングされた特定のサービスプロファイルを決定する。ブロック１０１４において、OAuth承認サーバは、特定のサービスプロファイルから、特定のトークン属性の値を読取る。ブロック１０１６において、OAuth承認サーバは、特定のトークン属性および特定のサービスプロファイルから読取った対応値を含む新規トークンを生成する。たとえば、新規トークンは「タイムアウト」属性と、特定のクライアントアプリケーションの識別ドメインにマッピングされているプロファイルに指定されている対応する値を示すことができる。ブロック１０１８において、OAuth承認サーバは、トークンリクエストに応じて、新規トークンを特定のクライアントアプリケーションに返送する。
リソースサーバ上のトークン属性の上書き
特定のOAuthサービスプロファイルは、さまざまな属性にさまざまな値を指定することができ、OAuth承認サーバは、特定のOAuthサービスプロファイルを適用するクライアントアプリケーションのために、これらの値に準拠する特性を有するトークンを生成することができる。一実施形態において、個々のリソースサーバは、特定の属性値を上書きすることができる。たとえば、特定のリソースサーバは、提供するサービスのタイムアウト属性値を８時間ではなく、わずか１０分間に指定することができる。一実施形態において、リソースサーバが特定属性の値を指定した場合、その値は、OAuthサービスプロファイル内の同一の特定属性に指定された値よりも優先権を有する。
したがって、本発明の一実施形態において、リソースサーバは、OAuthサービスプロファイルから属性値を継承する一方、必要に応じて異なるリソースサーバ特有の属性値を指定することによって継承した属性値を上書きすることができる。このような実施形態において、リソースサーバが適用できるOAuthサービスプロファイルにより指定された属性値の上書きをしない場合、OAuthサービスプロファイルにより指定された属性値は、有効のままに維持され、リソースサーバは、その属性値を、OAuth承認サーバがクライアントアプリケーションに返送されるトークンを生成するために使用されるアクセス範囲の情報の一部としてOAuth承認サーバに送信する。
本発明の一実施例において、識別ドメインレベルで、デフォルト属性値を別々に定義することもできる。よって、同一の識別ドメイン内の複数の異なるOAuthサービスプロファイルは、これらの属性値を継承することができる。このような実施形態において、各OAuthサービスプロファイルは、各リソースサーバがOAuthサービスプロファイルから継承した属性値を上書きする方法と同様に、識別ドメインから継承した属性値を上書きすることができる。
図１１は、本発明の一実施形態に従って、リソースサーバにより上書きされる値を有するトークン属性を含むトークンを生成するための方法の一例を示すフローチャートである。ブロック１１０２において、OAuth承認サーバは、識別ドメインの管理者から、特定のトークン属性の第一値を指定するサービスプロファイルを受信する。たとえば、トークン属性を「タイムアウト」にすることができ、第一値を「８時間」にすることができる。ブロック１１０４は、サービスプロファイルの受信に応答して、OAuth承認サーバは、サービスプロファイルと識別ドメインとの間のマッピング関係を保存する。ブロック１１０６において、リソースサーバは、リソースサーバの管理者から、特定のトークン属性の第二値を指定するリソースサーバ特有プロファイルを受信する。たとえば、トークン属性を同様に「タイムアウト」にすることができ、第二値を「１０分間」にすることができる。ブロック１１０８において、リソースサーバ特有プロファイルの受信に応答して、リソースサーバは、リソースサーバ特有プロファイルを保存する。
ブロック１１１０において、OAuth承認サーバは、識別ドメインに含まれたクライアントアプリケーションから、トークンリクエストを受信する。ブロック１１１２において、OAuth承認サーバは、識別ドメインにマッピングされた特定のサービスプロファイルを決定する。ブロック１１１４において、OAuth承認サーバは、特定のサービスプロファイルから、特定のトークン属性のサービスプロファイル特有値を読取る。ブロック１１１６において、OAuth承認サーバは、特定のリソースサーバがトークンリクエストに指定された特定のサービスを提供することを決定する。ブロック１１１８において、特定のリソースサーバが特定のサービスを提供するという決定に応答して、OAuth承認サーバは、特定のリソースサーバから、リソースサーバ特有値を要求する。ブロック１１２０において、OAuth承認サーバは、特定のトークン属性のリソースサーバ特有値が特定のリソースサーバから受信されたか否かを決定する。肯定の場合、制御は、ブロック１１２２に進み、否定の場合、制御は、ブロック１１２４に進む。
ブロック１１２２において、OAuth承認サーバは、サービスプロファイル特有値ではなく、特定属性と特定属性のリソースサーバ特有値とを含む新規トークンを生成する。この場合、リソースサーバは、サービスプロファイルの特定属性値を上書きする。OAuth承認サーバは、トークンリクエストに応じて、新規トークンを特定のクライアントアプリケーションに返送する。
代替的には、ブロック１１２４において、OAuth承認サーバは、特定属性と特定属性のサービスプロファイル特有値とを含む新規トークンを生成する。この場合、リソースサーバは、特定属性のサービスプロファイル値を継承する。OAuth承認サーバは、トークンリクエストに応じて、新規トークンを特定のクライアントアプリケーションに返送する。
構成可能な適応型アクセスの呼出し
時々、テナントは、静的なＩＤおよびパスワードよりも動的な情報に基づいて、識別ドメイン内に定義されたユーザを認証して欲しい場合がある。たとえば、テナントは、ユーザがアクセスしている現在の地理位置、またはユーザがアクセスしているインターネットプロトコル（ＩＰ）アドレス、またはユーザがアクセスしている時間に基づいて、ユーザを認証して欲しい場合がある。このような動的情報を認証を行うために使用することは、適応型アクセスの基礎を構成する。
適応型アクセスマネージャは、一定の時間に亘って、各ユーザのためにアクセスプロファイルを構築することができる。たとえば、適応型アクセスマネージャは、特定のユーザが通常毎日午前８時から午後５時までの間にシステムにログインすることを決定することができる。しかしながら、適応型アクセスマネージャは、特定の夜において、特定のユーザが深夜にシステムに異常にログインしようとしたことを判断することができる。この不規則なアクセス動作は、不正アクセスの試行を示すことができる。別の例として、適応型アクセスマネージャは、特定のユーザがある夜にボストンからログインし、次の夜にサンフランシスコからログインしたことを判断することができる。両場所の間の距離が遠いため、不正アクセスの試行を示すことができる。不規則なアクセス操作の検出に応じて、適応型アクセスマネージャは、認証の一部として追加の質問をユーザに発行することができる。たとえば、ＩＤおよびパスワードに加えて、適応型アクセスマネージャは、回答が真のユーザしか知らない安全性問題を質問することができる。別の例として、適応型アクセスマネージャは、登録したユーザの電子メールアドレスに一次使用コードを送信し、承認時にユーザのＩＤおよびパスワードに加えて、一回使い切りのコードを要求することができる。代替的には、不正である可能性が大きい特定のアクセスに応答して、適応型アクセスマネージャは、アクセス試行を完全にブロックすることができ、是正措置をとることができるまで、ユーザアカウントを潜在的にロックすることができる。
本発明の一実施形態において、OAuth承認サーバは、ユーザからの少なくとも特定の認証リクエストに応じて、外部の適応型アクセスマネージャを呼出す。たとえば、OAuth承認サーバは、特定のポリシーに基づいて、新規ユーザがモバイル装置から登録されるたびに、適応型アクセスマネージャを呼出すことができる。適応型アクセスマネージャは、認証処理の一部として追加の資格情報（または「第二ファクタ」）を要求すべきか否かを示す情報に基づき、OAuth承認サーバに応答することができる。異なる適応型アクセスマネージャは、複数で存在することができる。本発明の一実施形態において、各テナントは、OAuth承認サーバに独自の「スライス」を構成することによって、テナントが選択した特定の適応型アクセスマネージャを呼出すことができる。このような構成は、たとえば、サービスプロファイルに指定されることができる。したがって、第一テナントは、ユーザを認証するときに、OAuth承認サーバに指示して、第一適応型アクセスマネージャを呼出すことができ、第二テナントは、ユーザを認証するときに、OAuth承認サーバに指示して、第二適応型アクセスマネージャを呼出すことができる。OAuth承認サーバは、さまざまなベンダから提供された異なる適応型アクセスマネージャと統合することができる。
図１２は、本発明の一実施形態に従った方法の一例を示すフローチャートである。この技術によって、共有OAuth承認サーバは、クラウドコンピューティング環境内の異なる識別ドメインに登録された異なる適応型アクセスマネージャを呼出すことができる。ブロック１２０２において、OAuth承認サーバは、第一識別ドメインの管理者から、第一適応型アクセスマネージャの第一ＵＲＬ（Uniform Resource Locator）を指定する第一サービスプロファイルを受信する。ブロック１２０４において、第一サービスプロファイルの受信に応答して、OAuth承認サーバは、第一サービスプロファイルと第一識別ドメインとの間のマッピング関係を保存する。ブロック１２０６において、OAuth承認サーバは、第一識別ドメインと異なる第二識別ドメインの管理者から、第一適応型アクセスマネージャと異なる第二適応型アクセスマネージャの第二ＵＲＬ（Uniform Resource Locator）を指定する第二サービスプロファイルを受信する。ブロック１２０８において、第二サービスプロファイルの受信に応答して、OAuth承認サーバは、第二サービスプロファイルと第二識別ドメインとの間のマッピング関係を保存する。
ブロック１２１０において、OAuth承認サーバは、特定の識別ドメインに関連付けられたユーザから、認証リクエストを受信する。ブロック１２１４において、OAuth承認サーバは、認証リクエストに関連する識別ドメインを決定する。一実施形態において、認証リクエストは、識別ドメインを指定する。別の実施形態において、OAuth承認サーバは、保存されたデータを調べることによって、特定ユーザが関連付けられた識別ドメインを決定するできる。ブロック１２１６において、OAuth承認サーバは、ポリシーを適用することによって、認証リクエストに応答して、適応型アクセスマネージャを呼出すべきか否かを決定する。一実施形態において、適用されたポリシーは、識別ドメイン特有のポリシーであってもよい。よって、認証リクエストの発信源とする識別ドメインに依存して、認証リクエストに適用されるポリシーを選択することができる。ポリシーは、たとえば、認証リクエストがモバイル装置から発信される場合に限って、適応型アクセスマネージャを呼出すべきことを示すことができる。認証リクエストは、その自体がモバイル装置から発信されたか否かを指定することができる。適用可能なポリシーが適応型アクセスマネージャを呼出すべきであると評価された場合、制御は、ブロック１２２０に進み、そうでない場合、ブロック１２１８に進む。
ブロック１２１８において、OAuth承認サーバは、任意の適応型アクセスマネージャを呼出さず、特定ユーザに対して標準認証処理を行う。この場合、図１２を参照して説明した技術は、終了する。
代替的には、ブロック１２２０において、OAuth承認サーバは、ブロック１２１４に決定した識別ドメインにマッピングされたサービスプロファイルにより指定されたＵＲＬに配置された適応型アクセスマネージャを呼出す。この呼出しは、認証リクエストに関連する情報、たとえば、ユーザのＩＤおよびリクエストの発信源（たとえば、ＩＰアドレス）を含むことができる。このような情報に基づいて、呼出された適応型アクセスマネージャは、単純なパスワードの他に、いくつかのより厳しい認証が必要であるか否かに関する決定を下すことができる。より厳しい認証は、たとえば、回答が真のユーザしか知らない１つ以上の質問に回答すること、および／または帯域外（out-of-band）を介して真のユーザに属するテキストメッセージアドレスに送信したワンタイムコードを提示することを含む。ブロック１２２２において、OAuth承認サーバは、ブロック１２２０で呼出された適応型アクセスマネージャから、より厳しい認証を実行するか否かなどの指示を受信する。一実施形態において、この指示は、一種または二種以上のより厳しい認証（上記の例示は、いくつかのより厳しい認証を説明した）を実行すべきであることをさらに示すことができる。ブロック１２２４において、OAuth承認サーバは、適応型アクセスマネージャの応答に基づいて、より厳しい認証を実行するか否かを決定する。適応型アクセスマネージャからの応答がより厳しい認証を実行する必要があると示した場合、制御は、ブロック１２２６に進み、そうでない場合、制御は、ブロック１２１８に戻る。
ブロック１２２６において、OAuth承認サーバは、標準認証処理よりも厳しい認証処理または標準認証処理の他に追加の認証処理を用いて、ユーザを認証しようとする。一実施形態において、このような認証は、適応型アクセスマネージャからの応答により指定された１種類以上のより厳しい認証を実行することを含む。
REST（Representational State Transfer）を使用する許諾管理
典型的なシナリオにおいて、ソーシャルメディアウェブサイトまたは電子メールウェブサイトなどのウェブサイトに統合されたアプリケーションは、ユーザから、ウェブサイトに保管されているユーザの連絡先リストなどのユーザに関する個人情報にアクセスする権限を要求することができる。ユーザは、要求された権限を許可または拒否することができる。アプリケーションがこのような権限を要求する処理は、許諾管理である。権限が付与された場合、許諾されることになる。アプリケーションがユーザから許諾を要求するときに、ウェブサイトは、一般的にユーザを認証する。
多くの場合、許諾を要求する処理において、アプリケーションは、ハイパーテキスト転送プロトコル（ＨＴＴＰ）に基づくリダイレクトを使用して、アプリケーションがアクセスしようとするユーザ情報を保管するＷｅｂサイトからのページをユーザのブラウザにロードする。このページを介して、ウェブサイトは、ユーザのＩＤとパスワードを要求することによって、ユーザを認証する。ユーザを認証した後、ウェブサイトは、アプリケーションのＩＤおよびアプリケーションがアクセスしようとする情報（たとえば、コンタクトリスト）の範囲をユーザに開示することができる。ユーザは、ウェブサイト上の情報にアクセスするアプリケーションに許諾を与えるか否かをウェブサイトに指示することができる。ユーザが許諾を与えた場合に、ウェブサイトは、ユーザアカウントに関連して、その許諾を保存することができる。ユーザは、さまざまなアプリケーションに与えた許諾をすべて表示するように、ウェブサイトに指示することができる。ユーザは、ユーザの希望により選択した許諾を無効にするように、ウェブサイトに指示することができる。アプリケーションは、許諾を有する場合、ユーザから再び許諾を要求することなく、ユーザに許諾された情報にアクセスすることができる。
いくつかの状況において、アプリケーションがユーザの許諾を得るために必要とするインターフェイスは、インターネットブラウザに基づいたものではない。このようなインターフェイスの代替物は、ＨＴＴＰを使用するまたはＨＴＴＰを理解するように設計されていないため、一般的に承認管理の一部として使用されているＨＴＴＰリダイレクトを理解できないまたはＨＴＴＰリダイレクトに適切に反応しない場合がある。たとえば、テレビインターフェイスを介してユーザと情報を交換するアプリケーションは、ユーザの許諾を得る必要があるが、テレビインターフェイスは、ＨＴＭＬリダイレクトを処理するように設計されていない可能性がある。
したがって、本発明の一実施形態は、インターフェイスがインターネットブラウザに基づくものであるか否かおよびインターフェイスがＨＴＴＰ準拠ものであるか否かにもかかわらず、許諾を管理することができる機構を提供する。本発明の一実施形態において、OAuth承認サーバは、許諾管理用のREST式インターフェイスをサポートする。たとえば、ユーザがテレビのリモコン上の特定ボタンを押したことに応答して、ユーザのテレビ上で動作するソフトウェアは、サーバのREST式インターフェイスを呼出すことができる。REST式インターフェイスを介して、ソフトウェアは、サーバにコールバックをすることができ、ボタンの押下を介して提供された許諾を保存することができる。その後、同様のREST式インターフェイスを使用して、許諾を取り消すこともできる。REST式インターフェイスを使用することによって、クライアントアプリケーションは、使用できるカスタムユーザインターフェイスを形成して、許諾管理プロセスを進めることができる。一実施形態において、ＨＴＭＬに基づくリダイレクトは、RESTに基づく承認管理プロセスに関与していない。RESTは、カリフォルニア大学アーバイン校のFielding, Roy Thomasによる２０００年の博士論文「アーキテクチャスタイルおよびネットワークに基づくソフトウェアアーキテクチャの設計」においてより詳細に記載されている。この博士論文は、引用として本明細書に援用される。さらに、RESTは、引用として本明細書に援用される米国特許出願公開第２０１３／００８１１２８号および米国特許出願公開第２０１３／００８６６６９号にも討論されている。
図１３は、本発明の一実施形態に従った方法の一例を示すフローチャートである。この技術によって、OAuth承認サーバは、許諾管理用のREST（Representational State Transfer）インターフェイスを提供する。ブロック１３０２において、OAuth承認サーバは、RESTに基づくインターフェイスをソフトウェアアプリケーションに公開する。ブロック１３０４において、OAuth承認サーバは、RESTに基づくインターフェイスを介して、ソフトウェアアプリケーションから、RESTに基づくリクエストを受信する。RESTに基づくリクエストは、特定のユーザに関連付けられた情報の範囲を指定することができる。ブロック１３０６において、RESTに基づくリクエストに応答して、OAuth承認サーバは、RESTに基づくインターフェイスを介して、ソフトウェアアプリケーションから、特定ユーザに関連する認証資格情報（たとえば、パスワード）を要求する。ブロック１３０８において、OAuth承認サーバは、RESTに基づくインターフェイスを介して、ソフトウェアアプリケーションから、資格情報を受信する。ブロック１３１０において、OAuth承認サーバは、受信した資格情報に基づいて、特定のユーザを認証する。ブロック１３１２において、OAuth承認サーバは、RESTに基づくインターフェイスを介して、ソフトウェアアプリケーションが情報の範囲によって指定された情報にアクセスすることを許諾するか否かをユーザに照会する。ブロック１３１４において、OAuth承認サーバは、RESTに基づくインターフェイスを介して、ユーザの許諾を受信する。ブロック１３１６において、OAuth承認サーバは、ソフトウェアアプリケーションと情報の範囲との間のマッピング関係を保存する。その後、ソフトウェアアプリケーションは、情報にアクセスする許諾をユーザから再取得する必要なく、保存されたマッピング関係による情報範囲内にある情報にアクセスすることができる。いくつかの実施形態において、ユーザは、RESTに基づくインターフェイスを介してOAuth承認サーバと情報を交換することによって、過去にさまざまなエンティティに付与された許諾のリストおよび各々の許諾に関与する情報範囲を取得することができる。いくつかの実施形態において、ユーザは、RESTに基づくインターフェイスを介して、OAuth承認サーバと情報を交換することによって、過去に付与された１つ以上の許諾を取り消すことができる。許諾を取り消すことに連れて、OAuth承認サーバは、取り消された許諾に関連するマッピング関係を削除する。
モバイルアプリケーションのシングルサインオン
クラウドコンピューティング環境において、同一のベンダからの複数のアプリケーションは、同一の識別ドメイン上で動作することができる。スマートフォンなどのモバイル装置からアプリケーションを起動する場合、ユーザは、そのアプリケーションにログインするために、同一のベンダからの別のアプリケーションにログインするためにすでに提供したユーザＩＤとパスワードをさらに提供する必要があるか否かことに悩む。モバイルネイティブアプリケーションは、シングルサインオンメカニズムを欠けるため、インターネットブラウザに基づくアプリケーションと異なる。インターネットブラウザに基づくアプリケーションの場合、ブラウザに保存されたクッキーが１つのウェブサイトにおけるユーザのログインを追跡することができるため、ユーザは、その後、別の関連ウェブサイトにログインする必要がない。
本発明の一実施形態によれば、モバイルネイティブアプリケーションの間に利用可能なシングルサインオン機能を提供することができる機構が提供される。この機構を使用すると、ユーザがユーザＩＤとパスワードを入力することによって１つのモバイルネイティブアプリケーションにログインした場合、モバイルネイティブアプリケーションにログインしたことは、同一のベンダからの他のモバイルネイティブアプリケーションに使用され、アプリケーションごとにユーザＩＤとパスワードを入力する必要なく、他のモバイルネイティブアプリケーションにアクセスする権利をユーザに与えることができる。基本的には、ユーザは、信頼できるアプリケーションのグループに属するモバイルネイティブアプリケーションのいずれかにサインオンすることによって、このグループに属するすべてのモバイルネイティブアプリケーションにサインオンすることができる。
シングルサインオン機能をモバイルネイティブアプリケーションに有効化するために、一実施形態において、アプリケーションにアクセスすることができる各モバイル装置のために、別体のサーバ側ストアが作成される。まず、モバイルネイティブアプリケーションの各々は、すべてのモバイル装置から遠隔しているサーバ上に登録される。モバイル装置上で特定のモバイルネイティブアプリケーションを起動する一回目に、登録処理が実行される。第二ファクタを含む厳しい認証は、各々の特定のモバイルネイティブアプリケーションの登録処理の一部として、実行されてもよい。信頼できるグループ内の各モバイルネイティブアプリケーションがサーバに登録された後、信頼できるグループ内のアプリケーションのいずれかに対する認証は、これらのアプリケーション間に共有されるユーザセッションを作成することができる。これによって、このユーザセッションが有効である間に、ユーザが信頼できるグループ内のいずれかの他のアプリケーションを起動した場合、パスワードの質問は、ユーザに発行されない。グループ内のすべてのアプリケーションを含む信頼サークル（circle of trust）は、サーバ上で保管される。
一実施形態において、各モバイル装置用の別体のデバイスストアは、サーバ上で作成される。特定のモバイル装置から起動されたユーザセッションは、そのモバイル装置のデバイスストアに保存される。サーバは、サーバに登録され信頼できるグループ内の各アプリケーションに、クライアント登録トークンを発行する。クライアント登録トークンは、アプリケーションが起動されたモバイル装置のハードウェア識別子（たとえば、メディアアクセス制御（ＭＡＣ）アドレス）、発行されたトークンが代理するユーザのＩＤ、およびトークンが発行されたアプリケーションのＩＤを含む３つの情報を含む。信頼できるグループ内のアプリケーションの各々は、同一のハードウェア識別子を含むクライアント登録トークンを受信する。アプリケーションＩＤは、信頼グループ内のアプリケーションにより保有されるトークンの間で異なる。クライアント登録トークン内のハードウェア識別子は、サーバによって（たとえば、暗号化技術を用いて）署名されている。
ユーザセッションの作成に先立ち、信頼できるグループ内の第一モバイルネイティブアプリケーションを起動すると、そのアプリケーションは、OAuth承認サーバにクライアント登録トークンを提供する。OAuth承認サーバは、パスワードを用いて第一モバイルネイティブアプリケーションを認証した後、ユーザセッションをクライアント登録トークンにより指定されたモバイル装置に関連付けられているサーバ側デバイスストア内に保存する。ユーザセッションは、指定された有効期限を有する。同一の信頼できるグループ内の別のモバイルネイティブアプリケーションを起動すると、そのアプリケーションも、OAuth承認サーバにクライアント登録トークンを提供する。クライアント登録トークン内のハードウェア識別子を用いて、モバイル装置に関連するデバイスストアのロックを解除することができる。サーバは、トークン内のハードウェア識別子が署名したものであることを判断することができる。サーバは、ハードウェア識別子を有するモバイル装置に関連するデバイスストアがすでに有効なユーザセッションを含むことを判断することができる。この判断に応答して、OAuth承認サーバは、パスワードをユーザに発行する必要がないことをモバイルネイティブアプリケーションに通知する。デバイスストアに有効なユーザセッションが存在するため、ユーザは、追加のサインオンプロセスをすることなく、信頼できるグループ内のすべてのモバイルネイティブアプリケーションを使用することができる。
本発明の一実施形態において、単一の識別ドメインは、複数の異なるサービスプロファイルを保存することができる。たとえば、第一グループのアプリケーションのために、第一サービスプロファイルを確立することができ、第二グループのアプリケーションのために、第二サービスプロファイルを確立することができる。一実施形態において、特定のサービスプロファイルに関連付けられたすべてのアプリケーションは、同一の信頼できるグループ内に配置されている。シングルサインオン機能は、同一の信頼できるグループ内のアプリケーションに利用可能である。識別ドメインを管理するテナントは、識別ドメイン内のサービスプロファイルの各々に、各サービスプロファイルに関連付けられているアプリケーションを指定することができる。たとえば、部門ごとにまたは従業員の役割ごとに、異なるサービスプロファイルを作成することができる。
図１４は、本発明の一実施形態に従った方法の一例を示すフローチャートである。この技術によって、サーバは、このサーバと別体のモバイル装置上で動作する複数の相互関連するアプリケーション用のアクティブユーザセッションを保管する。ブロック１４０２において、サーバ（潜在的なOAuth承認サーバ）は、第一モバイル装置上で動作する第一アプリケーションから、登録リクエストを受信する。ブロック１４０４において、サーバは、第一アプリケーションおよびそのユーザに対して、認証処理を行う。ブロック１４０６において、サーバは、（ａ）第一モバイル装置のハードウェア識別子と、（ｂ）認証したユーザのユーザＩＤと、（ｃ）第一アプリケーションのＩＤとを指定する第一クライアント登録トークンを第一アプリケーションに送信する。第一アプリケーションは、第一クライアント登録トークンを保存する。
ブロック１４０８において、サーバは、第一モバイル装置上で動作する第二アプリケーションから、登録リクエストを受信する。第二アプリケーションは、第一アプリケーションとは異なるが、第一アプリケーションが属する信頼できるグループに属している。信頼できるグループ内のアプリケーションの各々は、たとえば、同一のベンダからの製品であってもよい。ブロック１４１０は、サーバは、第二アプリケーションおよびそのユーザに対して、認証処理を行う。ブロック１４１２は、サーバは、（ａ）第一モバイル装置と同様のハードウェア識別子と、（ｂ）認証したユーザと同様のユーザＩＤと、（ｃ）第一アプリケーションのＩＤと異なる第二アプリケーションのＩＤとを指定する第二クライアント登録トークンを第二アプリケーションに送信する。第二アプリケーションは、第二クライアントの登録トークンを保存する。また、サーバは、他のモバイル装置、たとえば、第二モバイル装置上で動作するアプリケーションから、登録リクエストを受信することもできる。サーバは、それらのアプリケーションにクライアント登録トークンを送信する。送信されたクライアント登録トークンの各々は、それぞれのアプリケーションが動作するモバイル装置のハードウェア識別子を指定する。
ブロック１４１４において、サーバは、特定のモバイル装置上で動作する特定のアプリケーションから、特定のクライアント登録トークンを受信する。特定のモバイル装置は、たとえば、第一モバイル装置、第一モバイル装置と異なる第二モバイル装置または他のモバイル装置であってもよい。また、特定のアプリケーションは、第一モバイル装置上で動作する第一アプリケーション、または第一モバイル装置上で動作する第二アプリケーション、または第一モバイル装置上で動作する他のアプリケーション、または第一モバイル装置以外の他のアプリケーション上で動作する他のアプリケーションであってもよい。ブロック１４１６において、サーバは、特定のモバイル装置用のユーザセッションがサーバに存在するか否かを判断する。特定のモバイル装置用のユーザセッションが存在する場合、制御は、ブロック１４２４に進み、そうでない場合、制御は、ブロック１４１８に進む。
ブロック１４１８において、サーバは、特定のアプリケーションのユーザから認証資格情報を要求するように、特定のアプリケーションに指示する。たとえば、サーバは、ユーザに関連付けられたサーバに既知のパスワードを入力するよう、特定のアプリケーションのユーザに提示するように、特定のアプリケーションに指示することができる。ブロック１４２０において、ユーザ提供した認証資格情報が正当なものであることを確認した後、サーバは、特定のモバイル装置の特有ＩＤにマッピングされた新規ユーザセッションを作成し、保存する。一実施形態において、この特有ＩＤは、ブロック１４１４でサーバにより受信した特定のクライアント登録トークンに指定されたハードウェア識別子である。
ブロック１４２２において、サーバは、特定のアプリケーションのユーザが特定のアプリケーションに正常にログインしたことを特定のアプリケーションに通知する。その後、特定のアプリケーションのユーザは、サインオンしているうちに、特定のアプリケーションの機能を利用することができる。一実施形態において、サーバに保存されたユーザセッションが有効であるうちに、ユーザのサインオン状態が維持される。
代替的には、ブロック１４２４で、サーバは、特定のクライアント登録トークンに指定されたハードウェア識別子がユーザセッションで指定されたハードウェア識別子と一致することを確認する。上述したように、各クライアント登録トークンで送信されたハードウェア識別子およびユーザセッションに指定されたハードウェア識別子のすべては、暗号化技術を用いてサーバに署名することができる。よって、ハードウェア識別子を偽造することができない。サーバは、ハードウェア識別子が一致すると確認した場合、制御は、ブロック１４２２に戻る。この場合、サーバは、ブロック１４１８のように承認認証資格情報を要求することを特定のアプリケーションに指示しない。その理由は、その特定のモバイル装置用のサーバ側ユーザセッションが存在するため、特定のモバイル装置のユーザは、過去にすでにサインオンしたためである。このように、サーバは、モバイル装置上で実行するアプリケーションのために、シングルサインオン機能を提供することができる。
モバイルOAuthサービス
アプリケーションをOAuth承認サーバに初めて登録するときに、サーバがモバイル装置上の正当なモバイルアプリケーションのみにクライアント登録トークンを提供することを前提に、上述したモバイルアプリケーション用のシングルサインオン技術は、十分安全に機能する。安全性強化の一環として、正当なアプリケーションのみがクライアント登録トークンを受信することを保証するために、登録時に、各モバイルアプリケーションに対し、潜在的に第二ファクタを含み得るより厳しい認証を行うことができる。しかしながら、いくつかのハッキング技術がまだこれらの保護手段を破る可能性がある。仮説上、モバイル装置上のアプリケーションは、他のアプリケーションに偽装することができる。
したがって、本発明の一実施形態において、モバイル装置上のアプリケーションが本当に主張していものであることを確認するために、帯域外検証メカニズムが設けられている。アップル（登録商標）ｉＯＳにおいて、アップルプッシュ通知サービス（ＡＰＮＳ）と呼ばれるメカニズムが設けられる。ＡＰＮＳを用いて、モバイル装置上のアプリケーションを一意的に識別することができる。モバイルアプリケーションと通信しようとする外部ソースは、ＡＰＮＳを介して、プッシュ通知をモバイル装置上のモバイルアプリケーションに送信することができる。ＡＰＮＳサーバは、プッシュ通知が送信の目的地である特定の装置上の特定のアプリケーションに送信されることを保証する。この保証は、アップル社が各モバイル装置に発行した証明書に基づいている。アプリケーションは、ＡＰＮＳに登録するときに、モバイル装置の証明書をアップル社のＡＰＮＳサーバに提示する。ＡＰＮＳサーバは、装置トークンをアプリケーションに返送する。ＡＰＮＳサーバは、装置トークンと、アプリケーションと、アプリケーションが動作するモバイル装置との間の関連付けを保存する。アプリケーションは、アプリケーションに通知を送信しようとする外部ソースに、装置トークンを提示することができる。これらの外部ソースは、装置トークンと、外部ソースがアプリケーションに送信しようとする各通知とをＡＰＮＳサーバに提示することができる。ＡＰＮＳサーバは、その装置トークンに関連付けられているアプリケーションに、各通知をプッシュすることができる。
したがって、少なくとも一部のモバイル装置上で、ＡＰＮＳは、メッセージを安全な方法で装置上のアプリケーションに送信するためのメカニズムとして、使用されることができる。ＡＰＮＳは、アプリケーションをOAuth承認サーバに登録するための帯域外メカニズムとして、使用されることができる。OAuth承認サーバは、モバイルアプリケーションを初めてOAuth承認サーバに登録するときに、ＡＰＮＳを介して、クライアント登録トークンをモバイルアプリケーションに送信することができるため、適切なモバイルアプリケーションのみがそのクライアント登録トークンを受信することを保証することができる。偽装のクライアントは、ＡＰＮＳに登録されることがないため、ＡＰＮＳを介して、OAuth承認サーバからプッシュされたクライアント登録トークンを受信することができない。一実施形態において、モバイルアプリケーションの登録処理中に、モバイルアプリケーションは、ＡＰＮＳから受信した装置トークンをOAuth承認サーバに提供し、OAuth承認サーバは、モバイルアプリケーションと情報を通信するたびに、その装置トークンを用いて、そのモバイルアプリケーションに情報をプッシュする。
本発明の代替的な実施形態において、OAuth承認サーバは、ＡＰＮＳを介して、モバイルアプリケーションにすべてのクライアント登録トークンを送信しない。その代わりに、OAuth承認サーバは、クライアント登録トークンを２つの暗号化部分に分割する。OAuth承認サーバは、ＡＰＮＳを介して、クライアント登録トークンの半分をモバイルアプリケーションに送信する。OAuth承認サーバは、ハイパーテキスト転送プロトコル（ＨＴＴＰ）チャネル、典型的にはモバイルアプリケーションがOAuth承認サーバに登録するために使用されたチャネルと同様のチャネルを使用して、クライアント登録トークンの残りの半分をモバイルアプリケーションに送信する。モバイルアプリケーションは、両方の半分を受信し、合併した後、完全なクライアント登録トークンを獲得する。この技術は、ＡＰＮＳを介してすべてのクライアント登録トークンを送信する技術よりも、さらに安全である。
一部のモバイル装置は、アップルｉＯＳを実行しないため、ＡＰＮＳを使用することができない。本発明の一実施形態において、少なくとも一部のモバイル装置、たとえば、アンドロイド（Android、登録商標）オペレーティングシステムを実行する装置は、ＡＰＮＳの代わりに、グーグルクラウドメッセージング（Google Cloud Messaging、ＧＣＭ）を帯域外のトークン伝送チャネルとして使用することを除き、上記と同様の技術を使用して、クライアント登録トークンを受信する。
図１５は、本発明の一実施形態に従った方法の一例を示すフローチャートである。この技術によって、クライアント登録トークンは、帯域外チャネルを介してモバイル装置に安全に送信され、したがって、モバイル装置は、クライアント登録トークンを用いて、シングルサインオンという機能を達成することができる。ブロック１５０２において、OAuth承認サーバは、モバイル装置上で動作するアプリケーションからの登録リクエストに応じて、装置トークンを受信する。この装置トークンは、アプリケーションを一意的に識別し、サービスを利用するアプリケーションが事前登録処理の一環として過去にサービスから受信したものである。このサービスは、OAuth承認サーバまたはOAuth承認サーバが動作する共有クラウドコンピューティング環境とは異なり、OAuth承認サーバまたはOAuth承認サーバが動作する共有クラウドコンピューティング環境により提供または制御されるものではない。一実施形態において、サービスは、アップルプッシュ通知サービス（ＡＰＮＳ）である。別の実施形態において、サービスは、グーグルクラウドメッセージング（ＧＣＭ）である。他の実施形態において、サービスは、アプリケーションを一意的に識別する装置トークンをこれらのアプリケーションに提供する他の通知または他のメッセージングサービスであってもよい。これらのサービスは、しばしば、モバイル装置がアプリケーションをダウンロードできるアプリケーションストアと接通している。一般的には、アプリケーションストアは、アプリケーションをアプリケーションストア内に収容するプロセスの一部として、これらのアプリケーションに一意的なアプリケーション識別子を割当てる。
ブロック１５０４において、OAuth承認サーバは、アプリケーションからの登録リクエストに応じて、クライアント登録トークンを生成する。図１４に関連して上述したように、一実施形態において、クライアント登録トークンは、他の情報の中で、アプリケーションが動作するモバイル機器のＭＡＣアドレスを指定する。ブロック１５０６において、OAuth承認サーバは、クライアント登録トークンを２つの部分に分割する。各部分は、他の部分に含まれていない情報を含む。ブロック１５０８において、OAuth承認サーバは、クライアント登録トークンの各部分を暗号化する。
ブロック１５１０において、OAuth承認サーバは、モバイルアプリケーションが過去に装置トークンを受信したサービスに、装置トークンとクライアント登録トークンの第一暗号化部分を指定する通知との両方を送信する。その後、サービスは、装置トークンの真偽を検証し、クライアント登録トークンの第一暗号化部分を含む通知をモバイル装置上のアプリケーションにプッシュすることができる。アプリケーションとモバイル装置との両方は、装置トークンによって一意的に識別される。装置トークンは、モバイル機器のＭＡＣアドレスを指定することができる。サービスは、モバイル機器のＭＡＣアドレスを用いて、ネットワーク内で、プッシュ通知をそのアドレスに指定することができる。
ブロック１５１２において、OAuth承認サーバは、第一暗号化部分を送信するために使用されたサービスと関係ないハイパーテキスト転送プロトコル（ＨＴＴＰ）チャネルを介して、クライアント登録トークンの第二暗号化部分をモバイル装置に送信する。一実施形態において、このＨＴＴＰチャネルは、モバイル装置がブロック１５０２でOAuth承認サーバに登録リクエストを送信する際に使用したチャネルと同様である。その後、モバイル装置は、クライアント登録トークンの暗号化部分の両方を受信し、各部分を解読し、解読された部分を合併することによって、完全なクライアント登録トークンを得る。その後、モバイル装置は、クライアント登録トークンを保存し、図１４に関連して上述したように、クライアント登録トークンを用いて、モバイル装置上で動作する関連アプリケーション上でシングルサインオン機能を実現する。
ハードウェアの概要
図１６は、実施形態のうちの１つを実現するための分散型システム１６００を示す簡略図である。図示の実施形態において、分散型システム１６００は、１つ以上のネットワーク１６１０を介して、ウェブブラウザまたは専用クライアント（たとえば、オラクルフォーム）などのようなクライアントアプリケーションを実行および作動するように構成された１つ以上のクライアントコンピューティング装置１６０２、１６０４、１６０６および１６０８を含む。サーバ１６１２が、ネットワーク１６１０を介して、リモートクライアントコンピューティング装置１６０２、１６０４、１６０６および１６０８と通信可能に連結されてもよい。
さまざまな実施形態において、サーバ１６１２は、システムの１つ以上のコンポーネントによって提供される１つ以上のサービスまたは１つ以上のソフトウェアアプリケーションを実行するように構成されることができる。いくつかの実施形態において、これらのサービスは、ウェブサービスまたはクラウドサービスとして、またはSaaS（Software as a Service）モデルに基づいて、クライアントコンピューティング装置１６０２、１６０４、１６０６および／または１６０８のユーザに提供されてもよい。よって、クライアントコンピューティング装置１６０２、１６０４、１６０６および／または１６０８を操作するユーザは、１つ以上のクライアントアプリケーションを用いて、サーバ１６１２と情報を交換することによって、これらのコンポーネントによって提供されたサービスを利用することができる。
図示の構成において、システム１６００のソフトウェアコンポーネント１６１８、１６２０および１６２２は、サーバ１６１２上に実装されている。他の実施形態において、システム１６００の１つ以上のコンポーネントおよび／またはこれらのコンポーネントによって提供されたサービスは、１つ以上のクライアントコンピューティング装置１６０２、１６０４、１６０６および／または１６０８によって実現されてもよい。クライアントコンピューティング装置を操作するユーザは、１つ以上のクライアントアプリケーションを用いて、これらのコンポーネントによって提供されたサービスを利用することができる。これらのコンポーネントは、ハードウェア、ファームウェア、ソフトウェア、またはこれらの組み合わせで実現されてもよい。理解すべきことは、分散型システム１６００と異なるさまざまなシステム構成が可能であることである。したがって、図示された実施形態は、実施形態のシステムを実現するための分散型システムの一例であり、限定する意図をしていない。
クライアントコンピューティング装置１６０２、１６０４、１６０６および／または１６０８は、たとえば、Microsoft Windows Mobile（登録商標）のようなソフトウェア、および／またはｉＯＳ、Windowsフォン、アンドロイド、ブラックベリー１７およびパームＯＳなどのさまざまなモバイルオペレーティングシステムを実行することができ、インターネット、電子メール、ショートメッセージサービス（ＳＭＳ）、ブラックベリー（登録商標）または他の通信プロトコルが有効化された手持ち式携帯装置（たとえば、iPhone（登録商標）、携帯電話、Ipad（登録商標）、タブレット、携帯情報端末（ＰＤＡ）または着用できる装置（Google Glass（登録商標）ヘッドマウントディスプレイ）であってもよい。クライアントコンピューティング装置は、例示として、Microsoft Windows（登録商標）オペレーティングシステム、Apple Macintosh（登録商標）オペレーティングシステムおよび／またはLinux（登録商標）オペレーティングシステムのさまざまなバージョンを実行するパーソナルコンピュータおよび／またはラップトップコンピュータを含む汎用のパーソナルコンピュータであってもよい。クライアントコンピューティング装置は、たとえば、さまざまなGNU/Linuxオペレーティングシステム、たとえば、Google Chrome OSを含むがこれに限定されない市販のUNIX（登録商標）またはUNIXに類似するさまざまなオペレーティングシステムを動かすワークステーションコンピュータであってもよい。代替的にまたは追加的には、クライアントコンピューティング装置１６０２、１６０４、１６０６および１６０８は、ネットワーク１６１０を介して通信可能なシンクライアントコンピュータ、インターネット対応のゲームシステム（たとえば、Kinect（登録商標）ジェスチャ入力装置を備えるまたは備えないMicrosoft Xboxゲームコンソール）、および／またはパーソナルメッセージング装置などの他の電子機器であってもよい。
例示の分散型システム１６００は、４つのクライアントコンピューティング装置を備えると示されているが、任意の数のクライアントコンピューティング装置をサポートすることができる。他の装置、たとえばセンサを有する装置は、サーバ１６１２と情報を交換することができる。
分散型システム１６００のネットワーク１６１０は、ＴＣＰ／ＩＰ（伝送制御プロトコル／インターネットプロトコル）、ＳＮＡ（システムネットワークアーキテクチャ）、ＩＰＸ（インターネットパケット交換）、apple Talkなどを含むがこれらに限定されないさまざまな市販プロトコルのいずれかを使用してデータ通信をサポートすることができ、当業者に熟知される任意種類のネットワークであってもよい。単なる例示として、ネットワーク１６１０は、イーサネット（登録商標）、トークンリングおよび／またはその他に基づくローカルエリアネットワーク（ＬＡＮ）であってもよい。ネットワーク１６１０は、広域ネットワークまたはインターネットであってもよい。ネットワーク１６１０は、仮想プライベートネットワーク（ＶＰＮ）を含むがこれに限定されない仮想ネットワーク、イントラネット、エクストラネット、公衆交換電話網（ＰＳＴＮ）、赤外線ネットワーク、無線ネットワーク（たとえば、ＩＥＥＥ（Institute of Electrical and Electronic Engineers）１６０２．１１プロトコルスイート、Bluetooth（登録商標）、および／または任意の他の無線プロトコルの下で動作するネットワーク）および／またはこれらのネットワークと他のネットワークの組み合わせを含むことができる。
サーバ１６１２は、１つ以上の汎用コンピュータ、（例示として、ＰＣ（パーソナルコンピュータ）サーバ、UNIX（登録商標）サーバ、ミッドレンジサーバ、メインフレームコンピュータ、ラックマウントサーバを含む）専用サーバコンピュータ、サーバファーム、サーバクラスタ、または任意の他の適切な構成および／または組み合わせから構成されてもよい。さまざまな実施形態において、サーバ１６１２は、前述の開示に記載された１つ以上のサービスまたはソフトウェアアプリケーションを動かすように構成することができる。たとえば、サーバ１６１２は、本開示の実施形態に従って上記に説明した処理を実行するためのサーバに対応することができる。
サーバ１６１２は、上述したものいずれかを含むオペレーティングシステム、および任意の市販サーバオペレーティングシステムを動かすことができる。また、サーバ１６１２は、ＨＴＴＰ（ハイパーテキスト転送プロトコル）サーバ、ＦＴＰ（ファイル転送プロトコル）サーバ、ＣＧＩ（共通ゲートウェイインターフェイス）サーバ、Java（登録商標）サーバ、データベースサーバなどを含むさまざまな追加サーバアプリケーションおよび／または中間層アプリケーションのいずれかを動かすことができる。例示的なデータベースサーバは、Oracle（登録商標）、Microsoft（登録商標）、Sybase（登録商標）、IBM（登録商標）などの会社から市販されているものを含むがこれらに限定されない。
いくつかの実現例において、サーバ１６１２は、クライアントコンピューティング装置１６０２と、１６０４，１６０６、および１６０８のユーザから受信したデータフィードおよび／またはイベント更新を分析および統合する１つ以上のアプリケーションを含んでもよい。例示として、データフィードおよび／またはイベント更新は、これらに限定されないが、Twitter（登録商標）フィード、Facebook（登録商標）更新または１つ以上の第３情報源および連続データストリームから受信したリアルタイム更新を含むがこれらに限定されない。リアルタイム更新は、センサデータアプリケーション、金融相場表示機、ネットワーク性能測定ツール（たとえば、ネットワーク監視およびトラフィック管理アプリケーション）、ページ遷移（Clickstream）解析ツール、自動車交通監視装置などに関連するリアルタイムイベントを含むことができる。また、サーバ１６１２は、クライアントコンピューティング装置１６０２、１６０４、１６０６および１６０８の１つ以上の表示装置を介して、データフィードおよび／またはリアルタイムイベントを表示するための１つ以上のアプリケーションを含むこともできる。
また、分散型システム１６００は、１つ以上のデータベース１６１４および１６１６を含むことができる。データベース１６１４および１６１６は、さまざまな場所に常駐することができる。例示として、１つ以上のデータベース１６１４および１６１６は、サーバ１６１２の近く（および／またはその中）の非一時記憶媒体に常駐することができる。代替的には、データベース１６１４および１６１６は、リモートサーバ１６１２から離れており、ネットワークに基づく接続または専用接続を介して、サーバ１６１２と通信している。一組の実施形態において、データベース１６１４および１６１６は、記憶領域ネットワーク（ＳＡＮ）に常駐することができる。同様に、サーバ１６１２に寄与する機能を実行するための任意の必要なファイルは、必要に応じて、サーバ１６１２上に／またはサーバ１６１２から離れた場所に保存されてもよい。一組の実施形態において、データベース１６１４および１６１６は、たとえば、Oracleにより提供されるデータベースなどの関係データベースを含むことができる。これらの関係データベースは、ＳＱＬフォーマット命令に応じて、データを取得、保存および更新するように構成されている。
図１７は、本開示の実施形態に従ったシステム環境１７００の１つ以上のコンポーネントを示す簡略ブロック図である。実施形態に従ったシステムの１つ以上のコンポーネントによって提供されるサービスは、クラウドサービスとして提供されることができる。図示の実施形態において、システム環境１７００は、１つ以上のクライアントコンピューティング装置１７０４、１７０６および１７０８を含む。ユーザは、クライアントコンピューティング装置を用いて、クラウドサービスを提供するクラウドインフラストラクチャシステム１７０２と情報を交換することができる。クライアントコンピューティング装置は、ウェブブラウザ、専用クライアントアプリケーション（たとえば、オラクルフォーム）または他のアプリケーションなどのクライアントアプリケーションを作動するように構成されることができる。ユーザは、クライアントアプリケーションを用いてクラウドインフラストラクチャシステム１７０２と情報を交換することによって、クラウドインフラストラクチャシステム１７０２により提供されたサービスを利用することができる。
理解すべきことは、図示のクラウドインフラストラクチャシステム１７０２は、図示されたコンポーネント以外のコンポーネントを備えてもよいことである。さらに、図示の実施形態は、本発明の実施形態を組み込むことができるクラウドインフラストラクチャシステムの一例に過ぎない。いくつかの他の実施形態において、クラウドインフラストラクチャシステム１７０２は、図示よりも多いまたは少ないコンポーネントを有してもよく、２つ以上のコンポーネントを組み合わせてもよく、または異なる構成または配置のコンポーネントを有してもよい。
クライアントコンピューティング装置１７０４、１７０６および１７０８は、上述したクライアントコンピューティング装置１６０２、１６０４、１６０６および１６０８と同様であってもよい。
例示的なシステム環境１７００は、３つのクライアントコンピューティング装置を備えると示されているが、任意の数のクライアントコンピューティング装置をサポートすることができる。他の装置、たとえばセンサを有する装置は、クラウドインフラストラクチャシステム１７０２と情報を交換することができる。
ネットワーク１７１０は、クライアント１７０４、１７０６および１７０８とクラウドインフラストラクチャシステム１７０２との間のデータの通信および交換を促進することができる。各ネットワークは、上記でネットワーク１６１０に関して説明したプロトコルをさまざまな市販プロトコルのいずれかを用いてデータ通信をサポートすることができ、当業者に熟知する任意の種類のネットワークであってもよい。
クラウドインフラストラクチャシステム１７０２は、上記でサーバ１６１２に関して説明したコンポーネントを含み得る１つ以上のコンピュータおよび／またはサーバを含むことができる。
特定の実施形態において、クラウドインフラストラクチャシステムによって提供されたサービスは、需要に応じて、クラウドインフラストラクチャシステムからユーザに提供できるオンラインデータの記憶およびバックアップ、Ｗｅｂベースの電子メールサービス、ホストされたオフィススイートおよび文章連携サービス、データベース処理、管理できる技術サポートサービスなどの多くのサービスを含んでよい。クラウドインフラストラクチャシステムによって提供されるサービスは、ユーザのニーズを満たすように動的に拡張できる。クラウドインフラストラクチャシステムによって提供されたサービスの特定の例示は、本明細書において、「サービスインスタンス」と呼ばれる。一般的には、インターネットなどの通信ネットワークを介して、クラウドサービスプロバイダのシステムからユーザに提供できる任意のサービスは、「クラウドサービス」と呼ばれる。典型的には、パブリッククラウド環境において、クラウドサービスプロバイダのシステムを構成するサーバおよびシステムは、顧客のオンプレミスサーバおよびシステムとは異なる。たとえば、クラウドサービスプロバイダのシステムは、アプリケーションを提供することができ、ユーザは、必要に応じて、インターネットなどの通信ネットワークを介して、アプリケーションを注文し、使用することができる。
いくつかの例において、コンピュータネットワーククラウドインフラストラクチャ内のサービスは、保護されたコンピュータネットワークのストレージアクセス、ホストされたデータベース、ホストされたＷｅｂサーバ、ソフトウェアアプリケーション、またはクラウドベンダによってユーザに提供された他のサービス、または当該技術分野に知られている他のサービスを含むことができる。たとえば、サービスは、インターネットを介して、クラウド上のリモートストレージに対して、パスワードにより保護されたアクセスを含むことができる。別の例として、サービスは、Ｗｅｂサービスにホストされている関係データベースおよびネットワーク上の開発者により私的使用のためのスクリプト言語ミドルウェアエンジンを含むことができる。別の例として、サービスは、クラウドベンダのウェブサイト上でホストされている電子メールソフトウェアアプリケーションに対するアクセスを含むことができる。
特定の実施形態において、クラウドインフラストラクチャシステム１７０２は、セルフサービスのサブスクリプションに基づく、柔軟なスケーラビリティ、信頼性、高可用性および安全性を有する方法で、顧客に提供できる一連のアプリケーション、ミドルウェアおよびデータベースサービスを含むことができる。このようなクラウドインフラストラクチャシステムの例示として、本願譲受人により提供されたOracleパブリッククラウドが挙げられる。
さまざまな実施形態において、クラウドインフラストラクチャシステム１７０２は、顧客から申込んだクラウドインフラストラクチャシステム１７０２のサービスを自動的に提供、管理および追跡するように構成されることができる。クラウドインフラストラクチャシステム１７０２は、さまざまな展開モデルを介して、クラウドサービスを提供することができる。たとえば、サービスは、クラウドサービスを販売する組織に所有された（たとえば、Oracleに所有された）クラウドインフラストラクチャシステム１７０２を有するパブリッククラウドモデルで提供され、一般人または異なる業界の企業に利用されることができる。別の例として、サービスは、単一の組織に専用されたクラウドインフラストラクチャシステム１７０２を有するプライベートクラウドモデルで提供され、組織内の１つ以上の実体に利用されることができる。また、クラウドサービスは、集団クラウドモデルで提供されてもよい。よって、クラウドインフラストラクチャシステム１７０２およびクラウドインフラストラクチャシステム１７０２により提供されたサービスは、関連する集団内の複数の組織によって共有される。また、クラウドサービスは、２つ以上の異なるモデルの組み合わせからなるハイブリッドクラウドモデルで提供されてもよい。
いくつかの実施形態において、クラウドインフラストラクチャシステム１７０２によって提供されたサービスは、SaaS（Software as a Service）カテゴリ、PaaS（Platform as a Service）カテゴリ、IaaS（Infrastructure as a Service）カテゴリ、またはハイブリッドサービスを含む他のカテゴリのサービスに準拠して提供された１つ以上のサービスを含むことができる。顧客は、サブスクリプションの申込みによって、クラウドインフラストラクチャシステム１７０２によって提供された１つ以上のサービスを注文することができる。これに応じて、クラウドインフラストラクチャシステム１７０２は、顧客のサブスクリプション申込書に含まれたサービスを提供する処理を行う。
いくつかの実施形態において、クラウドインフラストラクチャシステム１７０２によって提供されたサービスは、アプリケーションサービス、プラットフォームサービスおよびインフラストラクチャサービスを含むがこれらに限定されない。いくつかの例において、アプリケーションサービスは、SaaSプラットフォームを介して、クラウドインフラストラクチャシステムによって提供されてもよい。SaaSプラットフォームは、SaaSカテゴリに準拠するクラウドサービスを提供するように構成されてもよい。たとえば、SaaSプラットフォームは、統合の開発および展開プラットフォーム上でオンデマンドアプリケーションのスイートを構築し、提供するように、機能することができる。SaaSプラットフォームは、SaaSサービスを提供するために、基礎のソフトウェアおよびインフラストラクチャを管理し、制御することができる。SaaSプラットフォームにより提供されたサービスを利用することによって、顧客は、クラウドインフラストラクチャシステム上で動作するアプリケーションを利用することができる。顧客は、別々のライセンスおよびサポートを購入する必要なく、アプリケーションサービスを取得することができる。さまざまな異なるSaaSサービスを提供することができる。例示としては、販売実績管理、企業統合、および大規模組織のビジネス柔軟性に対する解決策を提供するサービスを含むがこれらに限定されない。
いくつかの実施形態において、プラットフォームサービスは、PaaSプラットフォームを介してクラウドインフラストラクチャシステムによって提供されてもよい。PaaSプラットフォームは、PaaSカテゴリに準拠するクラウドサービスを提供するように構成されてもよい。プラットフォームサービスの例としては、共有されている共通アーキテクチャ上で既存のアプリケーションを統合する能力、およびプラットフォームにより提供された共有サービスを活用する新規アプリケーションを構築する能力を組織（たとえば、Oracle）に与えるサービスを含むがこれに限定されない。PaaSプラットフォームは、PaaSサービスを提供するために、基礎のソフトウェアおよびインフラストラクチャを管理し、制御することができる。顧客は、クラウドインフラストラクチャシステム上で動作するアプリケーションを利用することができる。顧客は、別々のライセンスおよびサポートを購入する必要なく、アプリケーションサービスを取得することができる。さまざまな異なるSaaSサービスを提供することができる。プラットフォームサービスの例としては、oracle Javaクラウドサービス（JCS）、Oracleデータベースクラウドサービス（DBCS）およびその他を含むがこれらに限定されない。
PaaSプラットフォームにより提供されたサービスを利用することによって、顧客は、クラウドインフラストラクチャシステムにサポートされているプログラミング言語およびツールを利用することができ、展開されたサービスを制御することができる。いくつかの実施形態において、クラウドインフラストラクチャシステムによって提供されるプラットフォームサービスは、データベースクラウドサービス、ミドルウェアクラウドサービス（たとえば、Oracle Fusionミドルウェアサービス）、およびJavaクラウドサービスを含むことができる。一実施形態において、データベースクラウドサービスは、データベースリソースを蓄積する能力を組織に与えることができる共有サービス展開モデルをサポートすることができ、DBaaS（Database as a Service）をクラウドデータベースとして顧客に提供することができる。ミドルウェアクラウドサービスは、クラウドインフラストラクチャシステム上でさまざまなビジネスアプリケーションを開発および展開するためのプラットフォームを顧客に提供することができ、Javaクラウドサービスは、クラウドインフラストラクチャシステム上でJavaアプリケーションを展開するためのプラットフォームを顧客に提供することができる。
種々の異なるインフラストラクチャサービスは、IaaSプラットフォームによって、クラウドインフラストラクチャシステムに提供されてもよい。これらのインフラストラクチャサービスは、SaaSプラットフォームおよびPaaSプラットフォームにより提供されたサービスを利用する顧客のために、ストレージ、ネットワークおよびその他の基本的なコンピューティングリソースとしての基礎コンピューティングリソースの管理と制御を容易にする。
特定の実施形態において、クラウドインフラストラクチャシステム１７０２はまた、クラウドインフラストラクチャシステムを利用する顧客に、さまざまなサービスを提供するために使用されるリソースを提供するためのインフラストラクチャリソース１７３０を含むことができる。一実施形態において、インフラストラクチャリソース１７３０は、PaaSプラットフォームおよびSaaSプラットフォームによって提供されたサービスを実行するために、事前に統合され且つ最適化されたサーバリソース、ストレージリソースおよびネットワークリソースなどのハードウェアの組み合わせを含んでもよい。
いくつかの実施形態において、クラウドインフラストラクチャシステム１７０２内のリソースは、複数のユーザに共有されることができ、各々の需要に応じて動的に再割当てることができる。また、リソースは、異なるタイムゾーンでユーザに割当てることができる。たとえば、クラウドインフラストラクチャシステム１７３０は、指定時間内でクラウドインフラストラクチャシステムのリソースを第一時間帯における第一グループのユーザに利用させ、その後、同様のリソースを異なる時間帯における別のグループのユーザに再配分することができ、リソースを最大に利用する。
特定の実施形態において、複数の内部共有サービス１７３２は、提供され、クラウドインフラストラクチャシステム１７０２の異なるコンポーネントまたはモジュールに共有されおよびクラウドインフラストラクチャシステム１７０２によって提供されたサービスに共有されることができる。これらの内部共有サービスは、安全性および識別サービス、統合サービス、企業リポジトリサービス、企業管理サービス、ウイルススキャンおよびホワイトリストサービス、高可用性のバックアップおよびリカバリサービス、クラウドサポートを可能にするサービス、メールサービス、通知サービス、およびファイル転送サービスなどを含むがこれらに限定されない。
特定の実施形態において、クラウドインフラストラクチャシステム１７０２は、クラウドインフラストラクチャシステム内のクラウドサービス（たとえば、SaaSサービス、PaaSサービスおよびIaaSサービス）を包括的に管理する機能を提供することができる。一実施形態において、クラウド管理機能は、クラウドインフラストラクチャシステム１７０２などによって受信した顧客のサブスクリプションを提供、管理、および追跡する機能を含んでもよい。
一実施形態において、図示のように、クラウド管理機能は、１つ以上のモジュール、たとえば、オーダー管理モジュール１７２０、オーダーオーケストレーションモジュール１７２２、オーダー支給モジュール１７２４、オーダー管理監視モジュール１７２６、およびＩＤ管理モジュール１７２８によって提供される。これらのモジュールは、１つ以上のコンピュータおよび／またはサーバを含んでもよく、これらを用いて形成されてもよい。これらのコンピュータおよび／またはサーバは、汎用コンピュータ、専用サーバコンピュータ、サーバファーム、サーバクラスタ、または任意の他の適切な配置および／またはこれらの組み合わせであってもよい。
例示的な動作１７３４において、顧客は、クライアント装置、たとえば、クライアント装置１７０４、１７０６または１７０８を使用して、クラウドインフラストラクチャシステム１７０２により提供された１つ以上のサービスをリクエストし、クラウドインフラストラクチャシステム１７０２によって提供された１つ以上のサービスをオーダーすることによって、クラウドインフラストラクチャシステム１７０２と情報を交換することができる。特定の実施形態において、顧客は、クラウドユーザインターフェイス（ＵＩ）、クラウドＵＩ １７１２、クラウドＵＩ １７１４および／またはクラウドＵＩ １７１６にアクセスし、これらのＵＩを介して、サブスクリプションをオーダーすることができる。クラウドインフラストラクチャシステム１７０２が顧客のオーダーに応答して受信したオーダー情報は、顧客と、クラウドインフラストラクチャシステム１７０２により提供され、顧客が購読しようとする１つ以上のサービスとを識別する情報を含むことができる。
顧客がオーダーした後、オーダー情報は、クラウドＵＩ１７１２、１７１４および／または１７１６を介して受信される。
動作１７３６において、オーダーは、オーダーデータベース１７１８に保存される。オーダーデータベース１７１８は、クラウドインフラストラクチャシステム１７１８によって操作され、または他のシステム要素と連動して操作されるいくつかのデータベースのうち１つであってもよい。
動作１７３８において、オーダー情報は、オーダー管理モジュール１７２０に転送される。いくつかの例において、オーダー管理モジュール１７２０は、オーダーに関連する請求および会計機能、たとえば、オーダーの確認、および確認後オーダーの記入を実行するように構成されてもよい。
動作１７４０において、オーダーに関する情報は、オーダーオーケストレーションモジュール１７２２に伝達される。オーダーオーケストレーションモジュール１７２２は、オーダー情報を利用して、顧客がオーダーしたサービスおよびリソースの提供を用意する。いくつかの例において、オーダーオーケストレーションモジュール１７２２は、オーダー支給モジュール１７２４のサービスを用いて、オーダーしたサービスをサポートするように、リソースの提供を用意することができる。
特定の実施形態において、オーダーオーケストレーションモジュール１７２２は、各オーダーに関連したビジネスプロセスを管理することができ、ビジネスロジックを適用することによって、オーダーに対して支給をするか否かを判断することができる。動作１７４２において、新規サブスクリプションのオーダーを受信すると、オーダーオーケストレーションモジュール１７２２は、リソースを割当て、サブスクリプションオーダーを満たすために必要なリソースを構成するように、リクエストをオーダー支給モジュール１７２４に送信する。オーダー支給モジュール１７２４は、顧客がオーダーしたサービス用のリソースを割当てることができる。オーダー支給モジュール１７２４は、クラウドインフラストラクチャシステム１７００により提供されたクラウドサービスと、リクエストされたサービスを提供するためのリソースを供給するために使用される物理的な実装層との間の抽象化レベルを形成する。このように、オーダーオーケストレーションモジュール１７２２は、たとえば、サービスおよびリソースをその場で支給するかまたは事前に支給するか、リクエストに応じて割当てる／与えるかなどの実装詳細から単離することができる。
動作１７４４において、サービスおよびリソースを支給した後、クラウドインフラストラクチャシステム１７０２のオーダー支給モジュール１７２４は、提供されるサービスの通知をクライアント装置１７０４、１７０６および／または１７０８を操作する顧客に送信することができる。
動作１７４６において、オーダー管理監視モジュール１７２６は、顧客のサブスクリプションオーダーを管理および追跡することができる。いくつかの例において、オーダー管理監視モジュール１７２６は、サブスクリプションオーダー内のサービスの利用統計、たとえば、ストレージの使用量、データの転送量、ユーザの数、システムの起動時間およびシステムの停止時間を収集するように構成されることができる。
特定の実施形態において、クラウドインフラストラクチャシステム１７００は、ＩＤ管理モジュール１７２８を含むことができる。ＩＤ管理モジュール１７２８は、クラウドインフラストラクチャシステム１７００に、識別サービス、たとえば、アクセス管理および認可サービスを提供するように構成することができる。いくつかの実施形態において、ＩＤ管理モジュール１７２８は、クラウドインフラストラクチャシステム１７０２によって提供されたサービスを利用したい顧客に関する情報を制御することができる。このような情報は、顧客のＩＤを承認する情報、およびさまざまなシステムリソース（たとえば、ファイル、ディレクトリ、アプリケーション、通信ポート、メモリセグメントなど）に対して許可された顧客の実行権限を記載する情報を含むことができる。ＩＤ管理モジュール１７２８は、各顧客に関する記述情報、記述情報にアクセスおよび変更する方法、および記述情報にアクセスおよび変更した顧客に対する管理を含むことができる。
図１８は、本発明のさまざまな実施形態を実現することができるコンピュータシステム１８００の一例を示す図である。コンピュータシステム１８００を用いて、上述したコンピュータシステムのいずれかを実現することができる。図示のように、コンピュータシステム１８００は、バスサブシステム１８０２を介して、複数の周辺サブシステムと連通する処理ユニット１８０４を含む。周辺サブシステムは、処理加速ユニット１８０６と、Ｉ／Ｏサブシステム１８０８と、記憶サブシステム１８１８と、通信サブシステム１８２４とを含むことができる。記憶サブシステム１８１８は、有形コンピュータ読取可能記憶媒体１８２２と、システムメモリ１８１０とを含む。
バスサブシステム１８０２は、コンピュータシステム１８００のさまざまなコンポーネントおよびサブシステムが必要に応じて相互通信させるための機構を形成する。図示には、バスサブシステム１８０２を単一のバスとして概略的に示しているが、代替的な実施形態において、バスサブシステムは、複数のバスを利用してもよい。バスサブシステム１８０２は、メモリバスまたはメモリコントローラ、周辺バス、およびさまざまなバスアーキテクチャのいずれかを使用するローカルバスを備えるいくつかの種類のバス構造のいずれかを有してもよい。たとえば、このようなアーキテクチャは、業界標準アーキテクチャ（ISA）バス、マイクロチャネルアーキテクチャ（MCA）バス、拡張ISA（EISA）バス、ビデオエレクトロニクス規格協会（VESA）ローカルバス、および周辺構成要素相互接続（PCI）バスを含むことができる。これらのバスは、IEEE P1386.1規格に準拠した製造されたメザニンバスとして実現することができる。
１つ以上の集積回路（たとえば、従来のマイクロプロセッサまたはマイクロコントローラ）として実装することができる処理ユニット１８０４は、コンピュータシステム１８００の動作を制御する。処理ユニット１８０４は、１つ以上のプロセッサを含むことができる。これらのプロセッサは、シングルコアプロセッサであってもよく、マルチコアプロセッサであってもよい。特定の実施形態において、処理ユニット１８０４は、各々シングルコアプロセッサまたはマルチコアプロセッサを備える１つ以上の独立した処理ユニット１８３２および／または１８３４として実装されてもよい。他の実施形態において、処理ユニット１８０４は、２つのデュアルコア（dual-core）プロセッサを単一のチップに集積することにより形成されたクアッドコア（Quad-core）処理ユニットとして実装されてもよい。
さまざまな実施形態において、処理ユニット１８０４は、プログラムコードに応じてさまざまなプログラムを実行することができ、複数のプログラムまたはプロセスを同時に実行することができる。任意の時点で、実行されるプログラムコードの一部または全てをプロセッサ１８０４および／または記憶サブシステム１８１８に常駐することができる。適切なプログラミングによって、プロセッサ１８０４は、上述したさまざまな機能を提供することができる。コンピュータシステム１８００は、デジタルシグナルプロセッサ（DSP）および専用プロセッサなどを含むことができる処理加速ユニット１８０６をさらに備えてもよい。
Ｉ／Ｏサブシステム１８０８は、ユーザインターフェイス入力装置と、ユーザインターフェイス出力装置とを含むことができる。ユーザインターフェイス入力装置は、キーボード、マウスまたはトラックボールなどのポインティング装置、ディスプレイに組み込まれたタッチパッドまたはタッチスクリーン、スクロールホイール、クリックホイール、ダイヤル、ボタン、スイッチ、キーパッド、音声命令認識システムを備える音声入力装置、マイクロフォン、および他の種類の入力装置を含んでもよい。また、ユーザインターフェイス入力装置は、たとえば、Microsoft Kinect（登録商標）モーションセンサのようなモーション検知および／またはジェスチャ認識装置を含んでもよい。Microsoft Kinect（登録商標）モーションセンサは、ジェスチャおよび音声命令を利用する自然ユーザインターフェイス（NUI）を介して、Microsoft Xbox（登録商標）３６０ゲームコントローラなどの入力装置を制御することができ、それと対話することができる。また、ユーザインターフェイス入力装置は、Google Glass（登録商標）瞬き検出器のような眼球ジェスチャ認識装置を含むことができる。Google Glass（登録商標）瞬き検出器は、ユーザの眼球活動（たとえば、写真を撮るときおよび／またはメニューを選択するときの「瞬き」）を検出し、眼球活動を入力装置（たとえば、Google Glass（登録商標））に入力する入力に変換する。さらに、ユーザインターフェイス入力装置は、音声命令を介してユーザと音声認識システム（たとえば、Siri（登録商標）ナビゲータ）との対話を可能にする音声認識検出装置を含んでもよい。
また、ユーザインターフェイス入力装置は、三次元（３Ｄ）マウス、ジョイスティックまたはポインティングスティック、ゲームパッド、グラフィックタブレット、スピーカなどのオーディオ／ビジュアル装置、デジタルカメラ、デジタルビデオカメラ、ポータブルメディアプレーヤ、ウェブカメラ、イメージスキャナ、指紋スキャナ、バーコードリーダ、３Ｄスキャナ、３Ｄプリンタ、レーザ距離計、および視線追跡装置を含むがこれらに限定されない。さらに、ユーザインターフェイス入力装置は、たとえば、コンピュータ断層撮影装置、磁気共鳴像装置、超音波放射断層撮影装置、および医療用超音波装置などのような医用画像入力装置を含んでもよい。また、ユーザインターフェイス入力装置は、たとえば、ＭＩＤＩキーボードおよび電子楽器などの音声入力装置を含んでもよい。
ユーザインターフェイス出力装置は、ディスプレイサブシステム、インジケータライト、またはオーディオ出力装置などの非視覚ディスプレイを含んでもよい。ディスプレイサブシステムは、たとえば、陰極線管（ＣＲＴ）、液晶ディスプレイ（ＬＣＤ）またはプラズマディスプレイを使用するフラットパネル装置、投射装置またはタッチスクリーンであってもよい。一般に、「出力装置」という用語を使用する場合、コンピュータシステム１８００から情報をユーザまたは他のコンピュータに出力するためのすべての可能な種類の装置および機構を含むことを意図している。たとえば、ユーザインターフェイス出力装置は、文字、画像およびオーディオ／ビデオ情報を視覚的に伝達するさまざまな表示装置、たとえば、モニタ、プリンタ、スピーカ、ヘッドフォン、カーナビゲーションシステム、プロッタ、音声出力装置、およびモデムを含むがこれらに限定されない。
システムメモリ１８１０は、記憶サブシステム１８１８を含むことができる。記憶サブシステム１８１８は、ソフトウェア要素を備え、図示では、これらのソフトウェア要素は、システムメモリ１８１０内に配置されている。コンピュータシステム１８００は、処理ユニット１８０４にロード可能かつ実行可能なプログラム命令、およびこれらのプログラムの実行により生成されたデータを記憶することができる。
コンピュータシステム１８００の構成およびタイプに応じて、システムメモリ１８１０は、揮発性メモリ（たとえば、ランダムアクセスメモリ（random access memory：ＲＡＭ））であってもよく、および／または、不揮発性メモリ（たとえば、読取り専用メモリ（read-only memory：ＲＯＭ）、フラッシュメモリ）であってもよい。一般に、ＲＡＭは、処理ユニット１８０４がすぐにアクセス可能なデータおよび／またはプログラムモジュール、および／または、処理ユニット１８０４によって現在動作および実行されているデータおよび／またはプログラムモジュールを収容する。いくつかの実現例では、システムメモリ１８１０は、スタティックランダムアクセスメモリ（static random access memory：ＳＲＡＭ）またはダイナミックランダムアクセスメモリ（dynamic random access memory：ＤＲＡＭ）などの複数の異なるタイプのメモリを含み得る。いくつかの実現例では、始動中などにコンピュータシステム１８００内の要素間で情報を転送することを助ける基本ルーチンを含む基本入力／出力システム（basic input/output system：ＢＩＯＳ）が、一般にＲＯＭに格納され得る。一例としておよび非限定的に、システムメモリ１８１０は、クライアントアプリケーション、ウェブブラウザ、中間層アプリケーション、リレーショナルデータベース管理システム（relational database management system：ＲＤＢＭＳ）などを含み得るアプリケーションプログラム１８１２、プログラムデータ１８１４およびオペレーティングシステム１８１６も示す。一例として、オペレーティングシステム１８１６は、マイクロソフトウィンドウズ（登録商標）、アップルマッキントッシュ（登録商標）および／もしくはリナックス（登録商標）オペレーティングシステムのさまざまなバージョン、さまざまな市販のＵＮＩＸ（登録商標）もしくはＵＮＩＸライクオペレーティングシステム（さまざまなＧＮＵ／リナックスオペレーティングシステム、Google Chrome（登録商標）ＯＳなどを含むが、これらに限定されるものではない）、ならびに／または、ｉＯＳ、Windows（登録商標）フォン、アンドロイド（登録商標）ＯＳ、ブラックベリー（登録商標）１８ＯＳおよびパーム（登録商標）ＯＳオペレーティングシステムなどのモバイルオペレーティングシステムを含み得る。
また、記憶サブシステム１８１８は、いくつかの実施例の機能を提供する基本的なプログラミングおよびデータ構造を格納するための有形のコンピュータ読取可能な記憶媒体を提供し得る。プロセッサによって実行されたときに上記の機能を提供するソフトウェア（プログラム、コードモジュール、命令）が記憶サブシステム１８１８に格納され得る。これらのソフトウェアモジュールまたは命令は、処理ユニット１８０４によって実行され得る。また、記憶サブシステム１８１８は、本発明に従って使用されるデータを格納するためのリポジトリを提供し得る。
また、記憶サブシステム１８００は、コンピュータ読取可能な記憶媒体１８２２にさらに接続可能なコンピュータ読取可能な記憶媒体リーダ１８２０を含み得る。コンピュータ読取可能な記憶媒体１８２２は、システムメモリ１８１０とともに、または必要に応じてシステムメモリ１８１０と組み合わせて、コンピュータ読取可能な情報を一時的および／または永久に収容、格納、送信および検索するための記憶媒体に加えて、リモート記憶装置、ローカル記憶装置、固定的な記憶装置および／または取外し可能な記憶装置を包括的に表すことができる。
また、コードまたはコードの一部を含むコンピュータ読取可能な記憶媒体１８２２は、当該技術分野において公知のまたは使用される任意の適切な媒体を含み得て、当該媒体は、情報の格納および／または送信のための任意の方法または技術において実現される揮発性および不揮発性の、取外し可能および取外し不可能な媒体などであるが、これらに限定されるものではない記憶媒体および通信媒体を含む。これは、ＲＡＭ、ＲＯＭ、電子的消去・プログラム可能ＲＯＭ（electronically erasable programmable ROM：ＥＥＰＲＯＭ）、フラッシュメモリもしくは他のメモリ技術、ＣＤ−ＲＯＭ、デジタル多用途ディスク（digital versatile disk：ＤＶＤ）、または他の光学式記憶装置、磁気カセット、磁気テープ、磁気ディスク記憶装置もしくは他の磁気記憶装置、または他の有形のコンピュータ読取可能な媒体などの有形のコンピュータ読取可能な記憶媒体を含み得る。また、これは、データ信号、データ送信などの無形のコンピュータ読取可能な媒体、または、所望の情報を送信するために使用可能でありかつ計算システム１８００によってアクセス可能なその他の媒体を含み得る。
一例として、コンピュータ読取可能な記憶媒体１８２２は、取外し不可能な不揮発性磁気媒体から読取るまたは当該媒体に書込むハードディスクドライブ、取外し可能な不揮発性磁気ディスクから読取るまたは当該ディスクに書込む磁気ディスクドライブ、ならびに、ＣＤ ＲＯＭ、ＤＶＤおよびブルーレイ（登録商標）ディスクまたは他の光学式媒体などの取外し可能な不揮発性光学ディスクから読取るまたは当該ディスクに書込む光学式ディスクドライブを含み得る。コンピュータ読取可能な記憶媒体１８２２は、ジップ（登録商標）ドライブ、フラッシュメモリカード、ユニバーサルシリアルバス（universal serial bus：ＵＳＢ）フラッシュドライブ、セキュアデジタル（secure digital：ＳＤ）カード、ＤＶＤディスク、デジタルビデオテープなどを含み得るが、これらに限定されるものではない。また、コンピュータ読取可能な記憶媒体１８２２は、フラッシュメモリベースのＳＳＤ、企業向けフラッシュドライブ、ソリッドステートＲＯＭなどの不揮発性メモリに基づくソリッドステートドライブ（solid-state drive：ＳＳＤ）、ソリッドステートＲＡＭ、ダイナミックＲＡＭ、スタティックＲＡＭなどの揮発性メモリに基づくＳＳＤ、ＤＲＡＭベースのＳＳＤ、磁気抵抗ＲＡＭ（magnetoresistive RAM：ＭＲＡＭ）ＳＳＤ、およびＤＲＡＭとフラッシュメモリベースのＳＳＤとの組み合わせを使用するハイブリッドＳＳＤを含み得る。ディスクドライブおよびそれらの関連のコンピュータ読取可能な媒体は、コンピュータ読取可能な命令、データ構造、プログラムモジュールおよび他のデータの不揮発性記憶装置をコンピュータシステム１８００に提供し得る。
通信サブシステム１８２４は、他のコンピュータシステムおよびネットワークとのインターフェイスを提供する。通信サブシステム１８２４は、他のシステムからデータを受信したり、コンピュータシステム１８００から他のシステムにデータを送信するためのインターフェイスの役割を果たす。たとえば、通信サブシステム１８２４は、コンピュータシステム１８００がインターネットを介して１つ以上の装置に接続することを可能にし得る。いくつかの実施例では、通信サブシステム１８２４は、（たとえば３Ｇ、４ＧまたはＥＤＧＥ（enhanced data rates for global evolution）などの携帯電話技術、高度データネットワーク技術を用いて）無線音声および／またはデータネットワークにアクセスするための無線周波数（radio frequency：ＲＦ）トランシーバコンポーネント、ＷｉＦｉ（ＩＥＥＥ１６０２．１１ファミリ標準または他のモバイル通信技術またはそれらの任意の組み合わせ）、全地球測位システム（global positioning system：ＧＰＳ）レシーバコンポーネント、および／または、他のコンポーネントを含み得る。いくつかの実施例では、通信サブシステム１８２４は、無線インターフェイスに加えて、または無線インターフェイスの代わりに、有線ネットワーク接続（たとえばイーサネット）を提供し得る。
また、いくつかの実施例において、通信サブシステム１８２４は、コンピュータシステム１８００を使用し得る１人以上のユーザを代表して、構造化されたおよび／または構造化されていないデータフィード１８２６、イベントストリーム１８２８、イベント更新１８３０などの形態で入力通信を受信し得る。
一例として、通信サブシステム１８２４は、ツイッター（登録商標）フィード、フェースブック（登録商標）更新、リッチ・サイト・サマリ（Rich Site Summary：ＲＳＳ）フィードなどのウェブフィードなどのデータフィード１８２６をリアルタイムでソーシャルネットワークおよび／または他の通信サービスのユーザから受信し、および／または、１つ以上の第三者情報源からリアルタイム更新を受信するように構成され得る。
また、通信サブシステム１８２４は、連続的なデータストリームの形態でデータを受信するように構成され得て、当該データは、連続的である場合もあれば本質的に明確な端部を持たない状態で境界がない場合もあるリアルタイムイベントのイベントストリーム１８２８および／またはイベント更新１８３０を含み得る。連続的なデータを生成するアプリケーションの例としては、たとえばセンサデータアプリケーション、金融ティッカ、ネットワーク性能測定ツール（たとえばネットワークモニタリングおよびトラフィック管理アプリケーション）、クリックストリーム分析ツール、自動車交通モニタリングなどを含み得る。また、通信サブシステム１８２４は、構造化されたおよび／または構造化されていないデータフィード１８２６、イベントストリーム１８２８、イベント更新１８３０などを、コンピュータシステム１８００に結合された１つ以上のストリーミングデータソースコンピュータと通信し得る１つ以上のデータベースに出力するように構成され得る。
コンピュータシステム１８００は、手持ち式携帯機器（たとえばiPhone（登録商標）携帯電話、Ipad（登録商標）計算タブレット、ＰＤＡ）、ウェアラブル装置（たとえばGoogle Glass（登録商標）ヘッドマウントディスプレイ）、ＰＣ、ワークステーション、メインフレーム、キオスク、サーバラックまたはその他のデータ処理システムを含むさまざまなタイプのうちの１つであってもよい。
コンピュータおよびネットワークが絶え間なく進化し続けるため、図示されているコンピュータシステム１８００の説明は、特定の例として意図されているにすぎない。図に示されているシステムよりも多くのまたは少ない数の構成要素を有する多くの他の構成が可能である。例えば、ハードウェア、ファームウェア、（アプレットを含む）ソフトウェア、または組み合わせにおいて、カスタマイズされたハードウェアも使用されてもよく、および／または、特定の要素が実装されてもよい。さらに、ネットワーク入力／出力装置などの他の計算装置への接続が利用されてもよい。本明細書で提供される開示および教示に基づいて、当業者は、さまざまな実施例を実現するための他の手段および／または方法を理解するであろう。
いくつかの実施形態に従って、図１９は、上述した本発明の原理に従って構成されたOAuth承認サーバ１９００の一例を示す機能ブロック図である。サーバの機能ブロックは、本発明の原理を実施するためのハードウェア、ソフトウェア、またはハードウェアとソフトウェアの組み合わせによって実現されてもよい。なお、当業者なら理解できるように、上述した本発明の原理を実現するために、図１９に示された機能ブロックを合併してもよく、サブブロックに分離してもよい。したがって、本明細書の説明は、本明細書に記載の機能ブロックの任意の可能な組み合わせまたは分離もしくはさらなる定義をサポートすることができる。
図１９に示すように、OAuth承認サーバ１９００は、第一受信ユニット１９１０と、第一選択ユニット１９２０と、第一決定ユニット１９３０と、第一生成ユニット１９４０とを含むことができる。
第一受信ユニット１９１０は、OAuth承認サーバ１９００において、複数の別々の識別ドメインのうち、第一識別ドメイン内で動作する第一クライアントアプリケーションから、リクエストを受信することができる。第一選択ユニット１９２０は、OAuth承認サーバ１９００に保管された複数のOAuthサービスプロファイルから、第一識別ドメインのみに適用できる第一OAuthサービスプロファイルを選択することができる。第一決定ユニット１９３０は、第一OAuthサービスプロファイルに基づいて、第一クライアントアプリケーションが第一リソースサーバにアクセスする許可を有するか否かを決定することができる。第一生成ユニット１９４０は、第一クライアントアプリケーションが第一リソースサーバにアクセスする許可を有するという決定に応答して、OAuth承認サーバ１９００が第一リソースサーバから取得した範囲情報に基づいて、第一クライアントアプリケーションに第一トークンを生成することができる。
図１９を参照して、OAuth承認サーバ１９００は、第二受信ユニット１９５０と、第二選択ユニット１９６０と、第二決定ユニット１９７０と、第二生成ユニット１９８０とを含むことができる。
第二受信ユニット１９５０は、OAuth承認サーバ１９００において、複数の別々の識別ドメインのうち、第二識別ドメイン内で動作する第二クライアントアプリケーションから、リクエストを受信することができる。第二識別ドメインは、第一識別ドメインと別体である。第二選択ユニット１９６０は、OAuth承認サーバ１９００に保管された複数のOAuthサービスプロファイルから、第二識別ドメインのみに適用できる第二OAuthサービスプロファイルを選択することができる。第二決定ユニット１９７０は、第二OAuthサービスプロファイルに基づいて、第二クライアントアプリケーションが第二リソースサーバにアクセスする許可を有するか否かを決定することができる。第二生成ユニット１９８０は、第二クライアントアプリケーションが第二リソースサーバにアクセスする許可を有するという決定に応答して、OAuth承認サーバが第二リソースサーバから取得した範囲情報に基づいて、第二クライアントアプリケーションに第二トークンを生成することができる。
上記の明細書では、本発明の局面は、その具体的な実施例を参照して記載されているが、本発明はこれに限定されるものではないことを当業者は認識するであろう。上記の発明のさまざまな特徴および局面は、個々にまたは一緒に使用されてもよい。さらに、実施例は、明細書のより広い精神および範囲から逸脱することなく、本明細書に記載されているものを越えたどのような環境およびアプリケーションでも利用可能である。したがって、明細書および図面は、限定的ではなく例示的であるものとみなされるべきである。

Claims (17)

  1. 方法であって、
    承認コンピュータシステムにおいて、複数の識別ドメインのうちのある識別ドメイン内で動作するクライアントアプリケーションから、リソースサーバにアクセスするためのリクエストを受信するステップと、
    前記承認コンピュータシステムにおいて、前記複数の識別ドメインのうちの前記識別ドメインのみに適用できるサービスプロファイルを識別するステップとを含み、前記サービスプロファイルは、前記クライアントアプリケーションがアクセス権を有する前記識別ドメイン内のリソースサーバのセットを識別する情報を含み、
    前記承認コンピュータシステムにおいて、前記サービスプロファイルに含まれる前記情報によって識別された前記リソースサーバのセットに基づいて、前記クライアントアプリケーションが前記識別ドメイン内の前記リソースサーバにアクセスするアクセス権を有するか否かを判断するステップを含み、前記リソースサーバが前記リソースサーバのセットに含まれているという判断に応じて、前記クライアントアプリケーションが前記リソースサーバにアクセスするアクセス権が許可され、
    前記クライアントアプリケーションが前記識別ドメイン内の前記リソースサーバにアクセスするアクセス権を有しないという判断に応じて、前記承認コンピュータシステムにおいて、前記リソースサーバにアクセスする前記リクエストを拒否するステップを含み、前記リソースサーバにアクセスする前記リクエストを拒否するステップは、前記クライアントアプリケーションから前記識別ドメイン内の前記リソースサーバへの通信を遮断することを含み、
    前記クライアントアプリケーションが前記識別ドメイン内の前記リソースサーバにアクセスするアクセス権を有するという判断に応じて、前記承認コンピュータシステムにおいて、前記リソースサーバにアクセスし、前記リソースサーバについての範囲情報を取得するステップと、
    前記承認コンピュータシステムにおいて、前記リソースサーバから取得した前記範囲情報に基づいて、前記クライアントアプリケーションが前記リソースサーバにアクセスするためのトークンを生成するステップとを含む、方法。
  2. 前記承認コンピュータシステムは、ＯＡｕｔｈ承認サーバに含まれている、請求項１に記載の方法。
  3. 前記承認コンピュータシステムにおいて、前記クライアントアプリケーションを認証する認証リクエストを受信するステップと、
    前記認証リクエストの受信に応じて、複数のクライアントプラグインから、前記識別ドメインにマッピングされたクライアントプラグインを選択し、前記認証リクエストを前記クライアントプラグインに送信するステップとをさらに含む、請求項１または２に記載の方法。
  4. 前記リクエストに基づいて、前記クライアントアプリケーションによって要求されたサービスを識別するステップと、
    前記サービスに基づいて、前記サービスを要求した前記クライアントアプリケーションがアクセスするリソースサーバを決定するステップとをさらに含む、請求項１〜３のいずれか１項に記載の方法。
  5. 前記サービスプロファイルを用いて、前記リソースサーバに対応するコールバックユニフォームリソースロケータ（ＵＲＬ）を決定するステップをさらに含み、
    前記リソースサーバに対するアクセスは、前記コールバックＵＲＬを用いて実行され、
    前記リソースサーバは、前記識別ドメインに関連付けられた承認ポリシーに基づいて、前記範囲情報を決定する、請求項１〜４のいずれか１項に記載の方法。
  6. 前記範囲情報は、前記リソースサーバによって提供されるリソースにアクセスするサービスに許可された１つ以上の操作を示し、
    前記サービスは、前記リクエストに示される、請求項１〜５のいずれか１項に記載の方法。
  7. 前記サービスプロファイルは、前記クライアントアプリケーションがアクセス権を有する１つ以上のサービスを示し、
    前記１つ以上のサービスは、前記リソースサーバによって提供される、請求項１〜６のいずれか１項に記載の方法。
  8. 前記サービスプロファイルを用いて、前記クライアントアプリケーションからの前記リクエストに示されたサービスが、前記クライアントアプリケーションがアクセス権を有する前記１つ以上のサービスに含まれていないことを決定するステップと、
    前記サービスが前記１つ以上のサービスに含まれていないという決定に基づいて、前記リクエストを拒否するステップとをさらに含む、請求項７に記載の方法。
  9. コンピュータシステムであって、
    １つ以上のハードウェアプロセッサと、
    前記１つ以上のハードウェアプロセッサに動作可能に結合されたメモリとを含み、前記メモリは命令のセットを格納しており、前記命令のセットは、前記１つ以上のハードウェアプロセッサによって実行されると、前記１つ以上のプロセッサに以下のステップを実行させ、前記以下のステップは、
    複数の識別ドメインのうちのある識別ドメイン内で動作するクライアントアプリケーションから、リソースサーバにアクセスするためのリクエストを受信するステップと、
    前記複数の識別ドメインのうちの前記識別ドメインのみに適用できるサービスプロファイルを識別するステップとを実行させ、前記サービスプロファイルは、前記クライアントアプリケーションがアクセス権を有する前記識別ドメイン内のリソースサーバのセットを識別する情報を含み、
    前記サービスプロファイルに含まれる前記情報によって識別された前記リソースサーバのセットに基づいて、前記クライアントアプリケーションが前記識別ドメイン内の前記リソースサーバにアクセスするアクセス権を有するか否かを判断するステップを実行させ、前記リソースサーバが前記リソースサーバのセットに含まれているという判断に応じて、前記クライアントアプリケーションが前記リソースサーバにアクセスするアクセス権が許可され、
    前記識別ドメイン内の前記リソースサーバにアクセスするアクセス権を有しないという判断に応じて、前記クライアントアプリケーションが前記リソースサーバにアクセスする前記リクエストを拒否するステップを含み、前記リソースサーバにアクセスする前記リクエストを拒否するステップは、前記クライアントアプリケーションから前記識別ドメイン内の前記リソースサーバへの通信を遮断することを含み、
    前記識別ドメイン内の前記リソースサーバにアクセスするアクセス権を有するという判断に応じて、前記リソースサーバにアクセスし、前記リソースサーバについての範囲情報を取得するステップと、
    前記リソースサーバから取得した前記範囲情報に基づいて、前記クライアントアプリケーションが前記リソースサーバにアクセスするためのトークンを生成するステップとを含む、コンピュータシステム。
  10. 前記１つ以上のハードウェアプロセッサおよび前記メモリは、ＯＡｕｔｈ承認サーバに含まれている、請求項９に記載のコンピュータシステム。
  11. 前記命令のセットは、前記１つ以上のハードウェアプロセッサによって実行されると、前記１つ以上のプロセッサに、
    前記クライアントアプリケーションを認証するための認証リクエストを受信するステップと、
    前記認証リクエストの受信に応じて、複数のクライアントプラグインから、前記識別ドメインにマッピングされたクライアントプラグインを選択し、前記認証リクエストを前記クライアントプラグに送信するステップとをさらに実行させる、請求項９または１０に記載のコンピュータシステム。
  12. 前記命令のセットは、前記１つ以上のハードウェアプロセッサによって実行されると、前記１つ以上のプロセッサに、
    前記リクエストに基づいて、前記クライアントアプリケーションによって要求されたサービスを識別するステップと、
    前記サービスに基づいて、前記サービスを要求した前記クライアントアプリケーションがアクセスするリソースサーバを決定するステップとをさらに実行させる、請求項９〜１１のいずれか１項に記載のコンピュータシステム。
  13. 前記命令のセットは、前記１つ以上のハードウェアプロセッサによって実行されると、前記１つ以上のプロセッサに、
    前記サービスプロファイルを用いて、前記リソースサーバに対応するコールバックユニフォームリソースロケータ（ＵＲＬ）を決定するステップをさらに実行させ、
    前記リソースサーバに対するアクセスは、前記コールバックＵＲＬを用いて実行され、
    前記リソースサーバは、前記識別ドメインに関連付けられた承認ポリシーに基づいて、前記範囲情報を決定する、請求項９〜１２のいずれか１項に記載のコンピュータシステム。
  14. 前記範囲情報は、前記リソースサーバによって提供されるリソースにアクセスするサービスに許可された１つ以上の操作を示し、
    前記サービスは、前記リクエストに示される、請求項９〜１３のいずれか１項に記載のコンピュータシステム。
  15. 前記サービスプロファイルは、前記クライアントアプリケーションがアクセス権を有する１つ以上のサービスを示し、
    前記１つ以上のサービスは、前記リソースサーバによって提供される、請求項９〜１４のいずれか１項に記載のコンピュータシステム。
  16. 前記命令のセットは、前記１つ以上のハードウェアプロセッサによって実行されると、前記１つ以上のプロセッサに、
    前記サービスプロファイルを用いて、前記クライアントアプリケーションからの前記リクエストに示されたサービスが、前記クライアントアプリケーションがアクセス権を有する前記１つ以上のサービスに含まれていないことを決定するステップと、
    前記サービスが前記１つ以上のサービスに含まれていないという決定に基づいて、前記リクエストを拒否するステップとをさらに実行される、請求項９〜１５のいずれか１項に記載のコンピュータシステム。
  17. 命令を含むコンピュータ読取可能メモリであって、前記命令は、１つ以上のプロセッサによって実行されると、前記１つ以上のプロセッサに以下のステップを実行させ、前記以下のステップは、
    承認コンピュータシステムにおいて、複数の識別ドメインのうちのある識別ドメイン内で動作するクライアントアプリケーションから、リソースサーバにアクセスするためのリクエストを受信するステップと、
    前記承認コンピュータシステムにおいて、前記複数の識別ドメインのうちの前記識別ドメインのみに適用できるサービスプロファイルを識別するステップとを実行させ、前記サービスプロファイルは、前記クライアントアプリケーションがアクセス権を有する前記識別ドメイン内のリソースサーバのセットを識別する情報を含み、
    前記承認コンピュータシステムにおいて、前記サービスプロファイルに含まれる前記情報によって識別された前記リソースサーバのセットに基づいて、前記クライアントアプリケーションが前記識別ドメイン内の前記リソースサーバにアクセスするアクセス権を有するか否かを判断するステップを実行させ、前記リソースサーバが前記リソースサーバのセットに含まれているという判断に応じて、前記クライアントアプリケーションが前記リソースサーバにアクセスするアクセス権が許可され、
    前記クライアントアプリケーションが前記識別ドメイン内の前記リソースサーバにアクセスするアクセス権を有しないという判断に応じて、前記承認コンピュータシステムにおいて、前記リソースサーバにアクセスする前記リクエストを拒否するステップを実行させ、前記リソースサーバにアクセスする前記リクエストを拒否するステップは、前記クライアントアプリケーションから前記識別ドメイン内の前記リソースサーバへの通信を遮断することを含み、
    前記クライアントアプリケーションが前記識別ドメイン内の前記リソースサーバにアクセスするアクセス権を有するという判断に応じて、前記承認コンピュータシステムにおいて、前記リソースサーバにアクセスし、前記リソースサーバについての範囲情報を取得するステップと、
    前記承認コンピュータシステムにおいて、前記リソースサーバから取得した前記範囲情報に基づいて、前記クライアントアプリケーションが前記リソースサーバにアクセスするためのトークンを生成するステップとを含む、コンピュータ読取可能メモリ。
JP2016515506A 2013-09-20 2014-09-19 単一のフレキシブルかつプラガブルＯＡｕｔｈサーバを備える複数のリソースサーバ、ＯＡｕｔｈ保護したＲＥＳＴ式ＯＡｕｔｈ許諾管理サービス、およびモバイルアプリケーションシングルサインオンするＯＡｕｔｈサービス Active JP6033990B2 (ja)

Applications Claiming Priority (19)

Application Number Priority Date Filing Date Title
US201361880335P 2013-09-20 2013-09-20
US61/880,335 2013-09-20
US14/266,478 US9237145B2 (en) 2011-09-29 2014-04-30 Single sign-on (SSO) for mobile applications
US14/266,472 2014-04-30
US14/266,486 2014-04-30
US14/266,466 US9350718B2 (en) 2011-09-29 2014-04-30 Using representational state transfer (REST) for consent management
US14/266,515 US9544294B2 (en) 2011-09-29 2014-04-30 Pluggable authorization policies
US14/266,454 US9699170B2 (en) 2011-09-29 2014-04-30 Bundled authorization requests
US14/266,496 2014-04-30
US14/266,486 US9374356B2 (en) 2011-09-29 2014-04-30 Mobile oauth service
US14/266,496 US9531697B2 (en) 2011-09-29 2014-04-30 Configurable adaptive access manager callouts
US14/266,472 US9197623B2 (en) 2011-09-29 2014-04-30 Multiple resource servers interacting with single OAuth server
US14/266,466 2014-04-30
US14/266,505 US9578014B2 (en) 2011-09-29 2014-04-30 Service profile-specific token attributes and resource server token attribute overriding
US14/266,454 2014-04-30
US14/266,505 2014-04-30
US14/266,478 2014-04-30
US14/266,515 2014-04-30
PCT/US2014/056466 WO2015042349A1 (en) 2013-09-20 2014-09-19 Multiple resource servers with single, flexible, pluggable oauth server and oauth-protected restful oauth consent management service, and mobile application single sign on oauth service

Publications (2)

Publication Number Publication Date
JP2016535880A JP2016535880A (ja) 2016-11-17
JP6033990B2 true JP6033990B2 (ja) 2016-11-30

Family

ID=55167638

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2016515506A Active JP6033990B2 (ja) 2013-09-20 2014-09-19 単一のフレキシブルかつプラガブルＯＡｕｔｈサーバを備える複数のリソースサーバ、ＯＡｕｔｈ保護したＲＥＳＴ式ＯＡｕｔｈ許諾管理サービス、およびモバイルアプリケーションシングルサインオンするＯＡｕｔｈサービス

Country Status (4)

Country Link
US (3) US9450963B2 (ja)
EP (1) EP3047626B1 (ja)
JP (1) JP6033990B2 (ja)
CN (1) CN105659558B (ja)

Families Citing this family (143)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9081951B2 (en) * 2011-09-29 2015-07-14 Oracle International Corporation Mobile application, identity interface
US9544294B2 (en) 2011-09-29 2017-01-10 Oracle International Corporation Pluggable authorization policies
US20130212007A1 (en) 2012-02-10 2013-08-15 Protegrity Corporation Tokenization in payment environments
CN105659558B (zh) 2013-09-20 2018-08-31 甲骨文国际公司 计算机实现的方法、授权服务器以及计算机可读存储器
US9471807B1 (en) * 2014-11-05 2016-10-18 Emc Corporation System and method for creating a security slices with storage system resources and related operations relevant in software defined/as-a-service models, on a purpose built backup appliance (PBBA)/protection storage appliance natively
US9876780B2 (en) * 2014-11-21 2018-01-23 Sonos, Inc. Sharing access to a media service
US9881166B2 (en) 2015-04-16 2018-01-30 International Business Machines Corporation Multi-focused fine-grained security framework
US10949841B2 (en) * 2015-05-07 2021-03-16 Visa International Service Association Provisioning of access credentials using device codes
US10084794B2 (en) 2015-06-02 2018-09-25 ALTR Solutions, Inc. Centralized access management of web-based or native applications
US10104084B2 (en) * 2015-07-30 2018-10-16 Cisco Technology, Inc. Token scope reduction
US9554279B1 (en) * 2015-11-12 2017-01-24 Finjan Mobile, Inc. Authorized areas of authentication
EP3384471B1 (en) * 2015-12-03 2022-04-13 Nokia Technologies Oy Access management
US10567381B1 (en) * 2015-12-17 2020-02-18 Amazon Technologies, Inc. Refresh token for credential renewal
US20170187726A1 (en) * 2015-12-24 2017-06-29 Zeta (Better World Technology Pvt. Ltd.) Cross-domain message authentication
US10341862B2 (en) * 2016-02-05 2019-07-02 Verizon Patent And Licensing Inc. Authenticating mobile devices
US9740740B1 (en) 2016-02-22 2017-08-22 Pebble Technology Corp. Using metadata to take action on an SMS message on a proprietary system
US10055578B1 (en) * 2016-05-17 2018-08-21 Sprint Communications Company L.P. Secure software containers
US11063926B1 (en) * 2016-05-19 2021-07-13 Citibank, N.A. Devices and methods for single sign-on and regulatory compliance
WO2017208305A1 (ja) * 2016-05-30 2017-12-07 楽天株式会社 サーバ装置、サービス方法、プログラム、ならびに、非一時的なコンピュータ読取可能な情報記録媒体
WO2017219007A1 (en) 2016-06-17 2017-12-21 Weimer Jonathan Blockchain systems and methods for user authentication
US20180012197A1 (en) * 2016-07-07 2018-01-11 NextEv USA, Inc. Battery exchange licensing program based on state of charge of battery pack
US10375073B2 (en) 2016-08-29 2019-08-06 International Business Machines Corporation Configuration based client for OAuth authorization with arbitrary services and applications
US20180063152A1 (en) * 2016-08-29 2018-03-01 Matt Erich Device-agnostic user authentication and token provisioning
US10484382B2 (en) 2016-08-31 2019-11-19 Oracle International Corporation Data management for a multi-tenant identity cloud service
US10594684B2 (en) 2016-09-14 2020-03-17 Oracle International Corporation Generating derived credentials for a multi-tenant identity cloud service
JP6960450B2 (ja) * 2016-09-14 2021-11-05 オラクル・インターナショナル・コーポレイション マルチテナントアイデンティティおよびデータセキュリティ管理クラウドサービスのためのシングルサインオンおよびシングルログアウト機能
US10445395B2 (en) 2016-09-16 2019-10-15 Oracle International Corporation Cookie based state propagation for a multi-tenant identity cloud service
US20180091490A1 (en) * 2016-09-23 2018-03-29 Apple Inc. Authentication framework for a client of a remote database
US10873511B2 (en) * 2016-11-22 2020-12-22 Airwatch Llc Management service migration for managed devices
US10063533B2 (en) * 2016-11-28 2018-08-28 International Business Machines Corporation Protecting a web server against an unauthorized client application
KR20180065428A (ko) * 2016-12-07 2018-06-18 삼성전자주식회사 디바이스를 클라우드 서버에 등록시키는 방법 및 장치
KR102645768B1 (ko) * 2016-12-07 2024-03-11 엔에이치엔 주식회사 다중 계정 통합 관리 시스템 및 방법
US10462124B2 (en) 2016-12-30 2019-10-29 Google Llc Authenticated session management across multiple electronic devices using a virtual session manager
US10541992B2 (en) * 2016-12-30 2020-01-21 Google Llc Two-token based authenticated session management
US10554641B2 (en) 2017-02-27 2020-02-04 International Business Machines Corporation Second factor authorization via a hardware token device
JP6857065B2 (ja) * 2017-03-27 2021-04-14 キヤノン株式会社 認証認可サーバー、リソースサーバー、認証認可システム、認証方法及びプログラム
US10623410B2 (en) * 2017-04-24 2020-04-14 Microsoft Technology Licensing, Llc Multi-level, distributed access control between services and applications
US10972453B1 (en) * 2017-05-03 2021-04-06 F5 Networks, Inc. Methods for token refreshment based on single sign-on (SSO) for federated identity environments and devices thereof
US10089801B1 (en) 2017-05-15 2018-10-02 Amazon Technologies, Inc. Universal access control device
US10708053B2 (en) * 2017-05-19 2020-07-07 Intuit Inc. Coordinating access authorization across multiple systems at different mutual trust levels
CN108964885B (zh) * 2017-05-27 2021-03-05 华为技术有限公司 鉴权方法、装置、***和存储介质
JP6740545B2 (ja) * 2017-05-30 2020-08-19 日本電気株式会社 情報処理装置、検証装置、情報処理システム、情報処理方法、及び、プログラム
US10511593B2 (en) 2017-06-13 2019-12-17 Microsoft Technology Licensing, Llc Cross cloud application access
US10469479B2 (en) * 2017-06-13 2019-11-05 Microsoft Technology Licensing, Llc Cross cloud tenant discovery
US10136318B1 (en) * 2017-06-21 2018-11-20 At&T Intellectual Property I, L.P. Authentication device selection to facilitate authentication via an updateable subscriber identifier
US10547622B2 (en) * 2017-06-30 2020-01-28 International Busines Machines Corporation Extended OAuth architecture support in a scalable environment
US10530771B2 (en) * 2017-06-30 2020-01-07 Verizon Patent And Licensing Inc. System and method of inter-account resource access management
US20190014095A1 (en) 2017-07-06 2019-01-10 At&T Intellectual Property I, L.P. Facilitating provisioning of an out-of-band pseudonym over a secure communication channel
US11290438B2 (en) 2017-07-07 2022-03-29 Oracle International Corporation Managing session access across multiple data centers
US10581918B2 (en) * 2017-07-21 2020-03-03 Itron, Inc. Open authorization claim scheme to secure resources
US10491595B2 (en) * 2017-07-31 2019-11-26 Airwatch, Llc Systems and methods for controlling email access
US10491596B2 (en) 2017-07-31 2019-11-26 Vmware, Inc. Systems and methods for controlling email access
US10721222B2 (en) * 2017-08-17 2020-07-21 Citrix Systems, Inc. Extending single-sign-on to relying parties of federated logon providers
US10355864B2 (en) 2017-08-29 2019-07-16 Citrix Systems, Inc. Policy based authentication
US10958659B2 (en) 2017-08-30 2021-03-23 Red Hat, Inc. Setting application permissions in a cloud computing environment
CN109511115B (zh) * 2017-09-14 2020-09-29 华为技术有限公司 一种授权方法和网元
US10931673B2 (en) * 2017-09-19 2021-02-23 Amazon Technologies, Inc. Policy activation for client applications
US10498538B2 (en) * 2017-09-25 2019-12-03 Amazon Technologies, Inc. Time-bound secure access
US10505733B2 (en) 2017-09-25 2019-12-10 Citrix Systems, Inc. Generating and managing a composite identity token for multi-service use
US11050730B2 (en) * 2017-09-27 2021-06-29 Oracle International Corporation Maintaining session stickiness across authentication and authorization channels for access management
US11308132B2 (en) 2017-09-27 2022-04-19 Oracle International Corporation Reference attributes for related stored objects in a multi-tenant cloud service
US11316689B2 (en) * 2017-09-29 2022-04-26 Oracle International Corporation Trusted token relay infrastructure
CN111492389A (zh) 2017-10-20 2020-08-04 慧与发展有限责任合伙企业 使用区块链对服务进行认证和支付
WO2019078877A1 (en) 2017-10-20 2019-04-25 Hewlett Packard Enterprise Development Lp TRANSMITTING OR RECEIVING BLOCK CHAIN INFORMATION
WO2019078878A1 (en) 2017-10-20 2019-04-25 Hewlett Packard Enterprise Development Lp ACCESS TO INFORMATION BASED ON PRIVILEGES
US11582040B2 (en) 2017-10-20 2023-02-14 Hewlett Packard Enterprise Development Lp Permissions from entities to access information
WO2019079928A1 (zh) * 2017-10-23 2019-05-02 华为技术有限公司 一种访问令牌管理方法、终端和服务器
US10587618B2 (en) * 2017-11-14 2020-03-10 Microsoft Technology Licensing, Llc Dual binding
US10536461B2 (en) * 2017-12-19 2020-01-14 Sap Se Service identity propagation between applications and reusable services
JP2019125075A (ja) * 2018-01-15 2019-07-25 富士通株式会社 ストレージ装置、ストレージシステムおよびプログラム
US10715564B2 (en) 2018-01-29 2020-07-14 Oracle International Corporation Dynamic client registration for an identity cloud service
US10841313B2 (en) * 2018-02-21 2020-11-17 Nutanix, Inc. Substituting callback URLs when using OAuth protocol exchanges
US20190286840A1 (en) 2018-03-15 2019-09-19 Honeywell International Inc. Controlling access to customer data by external third parties
US10853511B2 (en) * 2018-03-19 2020-12-01 Salesforce.Com, Inc. Securely accessing and processing data in a multi-tenant data store
US10922401B2 (en) * 2018-04-18 2021-02-16 Pivotal Software, Inc. Delegated authorization with multi-factor authentication
US10838739B2 (en) 2018-04-19 2020-11-17 Circle Media Labs Inc. Network-connected computing devices and methods for executing operating programs in RAM memory
US10275613B1 (en) 2018-04-20 2019-04-30 Capital One Services, Llc Identity breach notification and remediation
US10855670B2 (en) 2018-05-03 2020-12-01 Vmware, Inc. Polling service
US10855669B2 (en) * 2018-05-03 2020-12-01 Vmware, Inc. Authentication service
CN112154634A (zh) * 2018-05-18 2020-12-29 瑞典爱立信有限公司 应用程序访问控制
US11303627B2 (en) 2018-05-31 2022-04-12 Oracle International Corporation Single Sign-On enabled OAuth token
WO2019240793A1 (en) * 2018-06-14 2019-12-19 Hewlett-Packard Development Company, L.P. Access tokens with scope expressions of personal data policies
US10893033B2 (en) 2018-06-28 2021-01-12 Salesforce.Com, Inc. Accessing client credential sets using a key
US11146543B2 (en) * 2018-07-12 2021-10-12 Vmware, Inc. Contact consolidation across multiple services
US10904238B2 (en) * 2018-07-13 2021-01-26 Sap Se Access token management for state preservation and reuse
US11558193B2 (en) * 2018-08-13 2023-01-17 Google Llc Location-based access to controlled access resources
CN112567716B (zh) * 2018-08-17 2024-05-03 维萨国际服务协会 安全数据传输***和方法
US11477217B2 (en) 2018-09-18 2022-10-18 Cyral Inc. Intruder detection for a network
US11606358B2 (en) * 2018-09-18 2023-03-14 Cyral Inc. Tokenization and encryption of sensitive data
US11645375B2 (en) 2018-09-27 2023-05-09 International Business Machines Corporation Authorization of resource access
US11263348B2 (en) * 2018-09-28 2022-03-01 Atlassian Pty Ltd. Managing content authorization in a federated application system
US10771570B2 (en) * 2018-10-15 2020-09-08 Citrix Systems, Inc. Scalable message passing architecture a cloud environment
US11245682B2 (en) * 2018-10-18 2022-02-08 Oracle International Corporation Adaptive authorization using access token
CN111147436B (zh) * 2018-11-05 2022-03-11 华为技术有限公司 一种网络切片授权的方法及通信装置
DE102018219067A1 (de) * 2018-11-08 2020-05-14 Robert Bosch Gmbh Transparenzmechanismus zur lokalen Komposition von personenbezogenen, verteilt gespeicherten Nutzerdaten
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
US20200311246A1 (en) * 2019-03-27 2020-10-01 Visa International Service Association Enhanced consumer device validation
US11184666B2 (en) 2019-04-01 2021-11-23 Sonos, Inc. Access control techniques for media playback systems
IT201900005876A1 (it) * 2019-04-16 2020-10-16 Roberto Griggio Sistema e metodo per la gestione delle credenziali di accesso multi-dominio di un utente abilitato ad accedere ad una pluralità di domini
US11277267B2 (en) * 2019-05-07 2022-03-15 International Business Machines Corporation Fine-grained token based access control
CN112383663B (zh) * 2019-05-08 2022-03-04 华为技术有限公司 一种显示的方法及设备
CN110278187B (zh) * 2019-05-13 2021-11-16 网宿科技股份有限公司 多终端单点登录方法、***、同步服务器及介质
US11017064B2 (en) 2019-05-14 2021-05-25 Bank Of America Corporation Authentication using interprogram communication
US11652631B2 (en) 2019-06-27 2023-05-16 International Business Machines Corporation Distribution of security credentials
US11206269B1 (en) * 2019-06-28 2021-12-21 Amazon Technologies, Inc. Managing non-persistent privileged and non-privileged operator access to infrastructure systems hosted in a cloud computing environment
US11115401B2 (en) 2019-07-08 2021-09-07 Bank Of America Corporation Administration portal for simulated single sign-on
US11323432B2 (en) 2019-07-08 2022-05-03 Bank Of America Corporation Automatic login tool for simulated single sign-on
US11089005B2 (en) 2019-07-08 2021-08-10 Bank Of America Corporation Systems and methods for simulated single sign-on
US11134078B2 (en) 2019-07-10 2021-09-28 Oracle International Corporation User-specific session timeouts
CN110493319B (zh) * 2019-07-23 2022-07-12 视联动力信息技术股份有限公司 数据同步方法、***及装置
US11423135B1 (en) * 2019-07-31 2022-08-23 Intuit Inc. Offline processing using on-demand access tokens
US11405207B2 (en) * 2019-07-31 2022-08-02 The Toronto-Dominion Bank Dynamic implementation and management of hash-based consent and permissioning protocols
US11768925B2 (en) * 2019-08-19 2023-09-26 Google Llc Smart device management resource picker
US11870770B2 (en) 2019-09-13 2024-01-09 Oracle International Corporation Multi-tenant identity cloud service with on-premise authentication integration
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
CN110661817B (zh) * 2019-10-25 2022-08-26 新华三大数据技术有限公司 资源访问方法、装置及服务网关
JP2021082004A (ja) * 2019-11-19 2021-05-27 キヤノン株式会社 認可サーバー、システム、システムの方法、および認可サーバーのプログラム
US11863673B1 (en) * 2019-12-17 2024-01-02 APPDIRECT, Inc. White-labeled data connections for multi-tenant cloud platforms
GB2590421A (en) * 2019-12-17 2021-06-30 Daimler Ag Method for operating a multimedia system
US11507627B2 (en) * 2019-12-19 2022-11-22 Sap Se Analytics content network for content delivery embedding
FR3105849B1 (fr) * 2019-12-27 2022-01-07 Bull Sas Procede et systeme de gestion d’autorisation pour une plateforme de gouvernance unifiee d’une pluralite de solutions de calcul intensif
US11140148B1 (en) * 2020-03-30 2021-10-05 Konica Minolta Business Solution U.S.A., Inc. Method and system for instant single sign-on workflows
US11863994B2 (en) * 2020-04-13 2024-01-02 The Government of the United States of America, represented by the Secretary of Homeland Security System and network for access control using mobile identification credential for sign-on authentication
US20210367982A1 (en) * 2020-05-22 2021-11-25 Coqual Inc. Hosted confidential discussion system
US11876796B2 (en) * 2020-06-09 2024-01-16 Strata Identity, Inc. Systems, methods, and storage media for abstraction and enforcement in an identity infrastructure
EP4173226A4 (en) * 2020-06-29 2024-03-06 Nokia Technologies Oy ACCESS CONTROL OF A SERVICE BASED MANAGEMENT FRAMEWORK
US11824856B1 (en) * 2020-07-10 2023-11-21 Amazon Technologies, Inc. Chaining of authorizations
US20220060513A1 (en) * 2020-08-21 2022-02-24 Oracle Intenational Corporation Centralized request processing and security zone policy enforcement in a cloud infrastructure system
US11671419B2 (en) 2020-09-30 2023-06-06 APPDIRECT, Inc. Multi-cloud data connections for white-labeled platforms
EP3979103A3 (en) 2020-10-01 2022-07-06 Nokia Technologies Oy Apparatus, methods, and computer programs
CN116325829A (zh) * 2020-10-09 2023-06-23 上海诺基亚贝尔股份有限公司 用于动态授权的机制
EP3996448A1 (en) * 2020-11-05 2022-05-11 Sony Group Corporation Flexible and dynamic resource allocation
US20220382849A1 (en) * 2021-05-25 2022-12-01 Vmware, Inc. Credentials management and usage in application modernization
CN113347242B (zh) * 2021-05-28 2023-04-18 Oppo广东移动通信有限公司 跨设备资源访问方法、装置、存储介质及电子设备
US12010125B2 (en) * 2021-06-29 2024-06-11 Microsoft Technology Licensing, Llc Anomaly detection in an application with delegate authorization
US12015607B2 (en) 2021-08-13 2024-06-18 The Toronto-Dominion Bank System and method for authenticating client devices communicating with an enterprise system
US11546358B1 (en) * 2021-10-01 2023-01-03 Netskope, Inc. Authorization token confidence system
CN114499977B (zh) * 2021-12-28 2023-08-08 天翼云科技有限公司 一种认证方法及装置
CN114138375A (zh) * 2021-12-30 2022-03-04 高新兴智联科技有限公司 一种物联网服务云架构及应用该云架构的射频测试***
US11882057B2 (en) * 2022-03-28 2024-01-23 Bank Of America Corporation Pluggable cloud security system
CN114650183A (zh) * 2022-04-11 2022-06-21 远景智能国际私人投资有限公司 资源管理方法、装置、服务器及存储介质
CN116248670B (zh) * 2023-03-24 2023-11-07 安芯网盾(北京)科技有限公司 一种文件传输控制方法及***

Family Cites Families (92)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20010056354A1 (en) 2000-05-05 2001-12-27 Feit Michelle Stacy Methods and systems for requesting services from service providers over a communications network
US20020091945A1 (en) * 2000-10-30 2002-07-11 Ross David Justin Verification engine for user authentication
US6879584B2 (en) 2001-01-31 2005-04-12 Motorola, Inc. Communication services through multiple service providers
US20020184535A1 (en) * 2001-05-30 2002-12-05 Farah Moaven Method and system for accessing a resource in a computing system
US7243369B2 (en) * 2001-08-06 2007-07-10 Sun Microsystems, Inc. Uniform resource locator access management and control system and method
US7207058B2 (en) 2002-12-31 2007-04-17 American Express Travel Related Services Company, Inc. Method and system for transmitting authentication context information
US7685206B1 (en) * 2004-02-12 2010-03-23 Microsoft Corporation Authorization and access control service for distributed network resources
WO2005109822A1 (en) * 2004-05-11 2005-11-17 Telefonaktiebolaget Lm Ericsson (Publ) Method and apparatus for providing access to an identity service
JP2005341090A (ja) * 2004-05-26 2005-12-08 Ricoh Co Ltd ビジネスオフィス装置
US8607322B2 (en) 2004-07-21 2013-12-10 International Business Machines Corporation Method and system for federated provisioning
US7774830B2 (en) 2005-03-14 2010-08-10 Microsoft Corporation Access control policy engine controlling access to resource based on any of multiple received types of security tokens
US7784092B2 (en) * 2005-03-25 2010-08-24 AT&T Intellectual I, L.P. System and method of locating identity providers in a data network
US7788494B2 (en) * 2005-06-28 2010-08-31 Intel Corporation Link key injection mechanism for personal area networks
US8972449B2 (en) 2005-12-29 2015-03-03 Nextlabs, Inc. Preventing conflicts of interests between two or more groups
US8639939B2 (en) 2006-07-07 2014-01-28 Sandisk Technologies Inc. Control method using identity objects
US20090193507A1 (en) 2008-01-28 2009-07-30 Wael Ibrahim Authentication messaging service
US9003050B2 (en) 2008-04-11 2015-04-07 Mobitv, Inc. Distributed and scalable content streaming architecture
US8141140B2 (en) 2008-05-23 2012-03-20 Hsbc Technologies Inc. Methods and systems for single sign on with dynamic authentication levels
GB2460412B (en) * 2008-05-28 2012-09-19 Hewlett Packard Development Co Information sharing
US20090296936A1 (en) * 2008-05-30 2009-12-03 Contineo Systems System and method for creating a secure billing identity for an end user using an identity association
US8250635B2 (en) 2008-07-13 2012-08-21 International Business Machines Corporation Enabling authentication of openID user when requested identity provider is unavailable
US20100043065A1 (en) * 2008-08-12 2010-02-18 International Business Machines Corporation Single sign-on for web applications
US8763102B2 (en) 2008-09-19 2014-06-24 Hewlett-Packard Development Company, L.P. Single sign on infrastructure
US8869256B2 (en) * 2008-10-21 2014-10-21 Yahoo! Inc. Network aggregator
US20100146570A1 (en) 2008-12-10 2010-06-10 Electronics And Telecommunications Research Institute Web service gateway for iptv service and method of operating the same
US8752153B2 (en) * 2009-02-05 2014-06-10 Wwpass Corporation Accessing data based on authenticated user, provider and system
US8364970B2 (en) * 2009-02-18 2013-01-29 Nokia Corporation Method and apparatus for providing enhanced service authorization
EP2257026B1 (en) 2009-05-29 2021-01-13 Alcatel Lucent System and method for accessing private digital content
FR2948053B1 (fr) * 2009-07-15 2011-07-29 Hameur Sa Ensemble et procede pour le nettoyage d'une grille
US9490984B2 (en) 2009-09-14 2016-11-08 Interdigital Patent Holdings, Inc. Method and apparatus for trusted authentication and logon
US8522335B2 (en) 2009-12-01 2013-08-27 International Business Machines Corporation Token mediation service in a data management system
EP2529527B1 (en) * 2010-01-25 2015-12-02 Nokia Solutions and Networks Oy Method for controlling access to resources
EP2532132A1 (en) * 2010-02-05 2012-12-12 Nokia Siemens Networks Oy Improved identity management
US8353019B2 (en) 2010-03-26 2013-01-08 Canon Kabushiki Kaisha Security token destined for multiple or group of service providers
US9391978B2 (en) * 2010-05-25 2016-07-12 Novell, Inc. Multiple access authentication
US20110314532A1 (en) * 2010-06-17 2011-12-22 Kyle Dean Austin Identity provider server configured to validate authentication requests from identity broker
US8402527B2 (en) * 2010-06-17 2013-03-19 Vmware, Inc. Identity broker configured to authenticate users to host services
US9189649B2 (en) * 2010-06-25 2015-11-17 International Business Machines Corporation Security model for workflows aggregating third party secure services
WO2012004916A1 (ja) * 2010-07-09 2012-01-12 日本電気株式会社 サービス提供システム
US8474017B2 (en) 2010-07-23 2013-06-25 Verizon Patent And Licensing Inc. Identity management and single sign-on in a heterogeneous composite service scenario
US20120028609A1 (en) * 2010-07-27 2012-02-02 John Hruska Secure financial transaction system using a registered mobile device
EP2625838A1 (en) * 2010-10-08 2013-08-14 Telefónica, S.A. A method, a system and a network element for ims control layer authentication from external domains
US8544068B2 (en) * 2010-11-10 2013-09-24 International Business Machines Corporation Business pre-permissioning in delegated third party authorization
US20120144501A1 (en) 2010-12-03 2012-06-07 Salesforce.Com, Inc. Regulating access to protected data resources using upgraded access tokens
US8832271B2 (en) * 2010-12-03 2014-09-09 International Business Machines Corporation Identity provider instance discovery
US9225532B2 (en) 2010-12-06 2015-12-29 Verizon Patent And Licensing Inc. Method and system for providing registration of an application instance
US8769646B2 (en) * 2010-12-08 2014-07-01 Disney Enterprises, Inc. System and method for associating a universal user identification and a domain specific user identification
US8713589B2 (en) 2010-12-23 2014-04-29 Microsoft Corporation Registration and network access control
US8924489B2 (en) 2011-01-05 2014-12-30 Apple Inc. Message push notification client improvements for multi-user devices
US8990557B2 (en) 2011-02-17 2015-03-24 Ebay Inc. Identity assertion framework
US20130024371A1 (en) 2011-02-22 2013-01-24 Prakash Hariramani Electronic offer optimization and redemption apparatuses, methods and systems
US20120227098A1 (en) * 2011-03-03 2012-09-06 Microsoft Corporation Sharing user id between operating system and application
US20120233334A1 (en) 2011-03-07 2012-09-13 Avaya Inc. Shared media access for real time first and third party control
US8533796B1 (en) * 2011-03-16 2013-09-10 Google Inc. Providing application programs with access to secured resources
US20120278876A1 (en) * 2011-04-28 2012-11-01 Mcdonald Greg System, method and business model for an identity/credential service provider
US9271127B2 (en) 2011-05-18 2016-02-23 Shanzhen Chen Automatic switching and failover method and system for messages and voice calls between cellular and IP networks
US20120331536A1 (en) 2011-06-23 2012-12-27 Salesforce.Com, Inc. Seamless sign-on combined with an identity confirmation procedure
US8650622B2 (en) * 2011-07-01 2014-02-11 Telefonaktiebolaget Lm Ericsson (Publ) Methods and arrangements for authorizing and authentication interworking
US8756692B2 (en) 2011-07-06 2014-06-17 Eureka! It Works, Llc Controlling network-based applications with social media postings
US9418216B2 (en) * 2011-07-21 2016-08-16 Microsoft Technology Licensing, Llc Cloud service authentication
US9544294B2 (en) * 2011-09-29 2017-01-10 Oracle International Corporation Pluggable authorization policies
US9081951B2 (en) 2011-09-29 2015-07-14 Oracle International Corporation Mobile application, identity interface
US9043886B2 (en) 2011-09-29 2015-05-26 Oracle International Corporation Relying party platform/framework for access management infrastructures
US8601554B2 (en) 2011-11-09 2013-12-03 Microsoft Corporation Home realm discovery in mixed-mode federated realms
US8973118B2 (en) 2011-12-14 2015-03-03 Cellco Partnership Token based security protocol for managing access to web services
US20130160144A1 (en) 2011-12-14 2013-06-20 Microsoft Corporation Entity verification via third-party
CN102546648B (zh) * 2012-01-18 2015-04-01 Ut斯达康通讯有限公司 一种资源访问授权的方法
US9794735B2 (en) 2012-02-15 2017-10-17 Dropbox Inc. Context determination for mobile devices when accessing remote resources
US9901815B2 (en) 2012-03-22 2018-02-27 The Regents Of The University Of California Devices, systems, and methods for monitoring, classifying, and encouraging activity
CN102611709B (zh) * 2012-03-31 2014-11-12 北京奇虎科技有限公司 一种对第三方资源的访问控制方法及***
US8898764B2 (en) 2012-04-19 2014-11-25 Microsoft Corporation Authenticating user through web extension using token based authentication scheme
US9148429B2 (en) 2012-04-23 2015-09-29 Google Inc. Controlling access by web applications to resources on servers
US20140007213A1 (en) 2012-06-29 2014-01-02 Wepay, Inc. Systems and methods for push notification based application authentication and authorization
US9053304B2 (en) 2012-07-13 2015-06-09 Securekey Technologies Inc. Methods and systems for using derived credentials to authenticate a device across multiple platforms
US9032033B2 (en) 2012-07-19 2015-05-12 Telefonaktiebolaget L M Ericsson (Publ) Method and apparatus for private token communication services
US8806595B2 (en) 2012-07-25 2014-08-12 Oracle International Corporation System and method of securing sharing of resources which require consent of multiple resource owners using group URI's
US8782411B2 (en) 2012-07-25 2014-07-15 Oracle International Corporation System and method of extending oauth server(s) with third party authentication/authorization
US9009787B2 (en) 2012-07-25 2015-04-14 Oracle International Corporation System and method of mapping and protecting communication services with OAuth
US8745718B1 (en) 2012-08-20 2014-06-03 Jericho Systems Corporation Delivery of authentication information to a RESTful service using token validation scheme
JP6025480B2 (ja) * 2012-09-27 2016-11-16 キヤノン株式会社 認可サーバーシステム、権限移譲システム、その制御方法、およびプログラム
US9442778B2 (en) 2012-10-01 2016-09-13 Salesforce.Com, Inc. Method and system for secured inter-application communication in mobile devices
US20140136346A1 (en) 2012-11-13 2014-05-15 Chirpify, Inc. System and methods for processing in-stream transactions on micro-blogs and other social networks
US10069838B2 (en) 2012-12-18 2018-09-04 Adobe Systems Incorporated Controlling consumption of hierarchical repository data
US9232339B2 (en) 2013-02-07 2016-01-05 Oracle International Corporation Mobile push notification
US20140337955A1 (en) * 2013-05-09 2014-11-13 Microsoft Corporation Authentication and authorization with a bundled token
WO2014190023A2 (en) 2013-05-21 2014-11-27 Cubic Corporation Multi-modal journey planning and payment
US9165031B2 (en) 2013-06-13 2015-10-20 Microsoft Technology Licensing, Llc Retrieving stored data using a web service
JP6198477B2 (ja) 2013-06-21 2017-09-20 キヤノン株式会社 権限移譲システム、認可サーバーシステム、制御方法、およびプログラム
JP6166596B2 (ja) 2013-06-21 2017-07-19 キヤノン株式会社 認可サーバーシステムおよびその制御方法、並びにプログラム
US9215226B2 (en) 2013-07-24 2015-12-15 Adobe Systems Incorporated Dynamically mapping users to groups
CN105659558B (zh) 2013-09-20 2018-08-31 甲骨文国际公司 计算机实现的方法、授权服务器以及计算机可读存储器
WO2015042349A1 (en) 2013-09-20 2015-03-26 Oracle International Corporation Multiple resource servers with single, flexible, pluggable oauth server and oauth-protected restful oauth consent management service, and mobile application single sign on oauth service

Also Published As

Publication number Publication date
US20160028737A1 (en) 2016-01-28
EP3047626B1 (en) 2017-10-25
CN105659558B (zh) 2018-08-31
EP3047626A1 (en) 2016-07-27
CN105659558A (zh) 2016-06-08
US9407628B2 (en) 2016-08-02
US20160080361A1 (en) 2016-03-17
US20170302655A1 (en) 2017-10-19
JP2016535880A (ja) 2016-11-17
US9450963B2 (en) 2016-09-20
US9860234B2 (en) 2018-01-02

Similar Documents

Publication Publication Date Title
JP6033990B2 (ja) 単一のフレキシブルかつプラガブルＯＡｕｔｈサーバを備える複数のリソースサーバ、ＯＡｕｔｈ保護したＲＥＳＴ式ＯＡｕｔｈ許諾管理サービス、およびモバイルアプリケーションシングルサインオンするＯＡｕｔｈサービス
US10084823B2 (en) Configurable adaptive access manager callouts
US10693864B2 (en) Single sign-on between multiple data centers
JP6895431B2 (ja) アクセス管理のためのパスワードレス認証
US10666643B2 (en) End user initiated access server authenticity check
CN107113302B (zh) 多租户计算***中的安全性和许可架构
US10581826B2 (en) Run-time trust management system for access impersonation
WO2015042349A1 (en) Multiple resource servers with single, flexible, pluggable oauth server and oauth-protected restful oauth consent management service, and mobile application single sign on oauth service

Legal Events

Date Code Title Description
A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20160901

A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20160901

A871 Explanation of circumstances concerning accelerated examination

Free format text: JAPANESE INTERMEDIATE CODE: A871

Effective date: 20160901

TRDD Decision of grant or rejection written
A975 Report on accelerated examination

Free format text: JAPANESE INTERMEDIATE CODE: A971005

Effective date: 20161007

A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20161018

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20161026

R150 Certificate of patent or registration of utility model

Ref document number: 6033990

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250