JP2016085638A - サーバー装置、端末装置、システム、情報処理方法及びプログラム - Google Patents
サーバー装置、端末装置、システム、情報処理方法及びプログラム Download PDFInfo
- Publication number
- JP2016085638A JP2016085638A JP2014218654A JP2014218654A JP2016085638A JP 2016085638 A JP2016085638 A JP 2016085638A JP 2014218654 A JP2014218654 A JP 2014218654A JP 2014218654 A JP2014218654 A JP 2014218654A JP 2016085638 A JP2016085638 A JP 2016085638A
- Authority
- JP
- Japan
- Prior art keywords
- user
- user information
- terminal device
- server device
- information
- 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.)
- Pending
Links
Landscapes
- Information Transfer Between Computers (AREA)
Abstract
【課題】各ユーザーの作業負荷を増やすことなく、かつ、管理者によるIDマッピング情報の生成の負荷を軽減する。
【解決手段】端末装置とネットワークを介して通信可能なサーバー装置であって、前記端末装置のユーザーの固有IDを含むユーザー情報を前記端末装置から受信する受信手段と、前記受信手段により受信されたユーザー情報のうち前記端末装置により指定された属性情報を含むユーザー情報に含まれる固有IDと、前記サーバー装置において認証されるユーザー情報のうち前記属性情報を含むユーザー情報に含まれるユーザーの固有IDとを紐付けて、前記端末装置と前記サーバー装置との認証連携に係るIDマッピング情報を生成する生成手段と、を有することによって課題を解決する。
【選択図】図6
【解決手段】端末装置とネットワークを介して通信可能なサーバー装置であって、前記端末装置のユーザーの固有IDを含むユーザー情報を前記端末装置から受信する受信手段と、前記受信手段により受信されたユーザー情報のうち前記端末装置により指定された属性情報を含むユーザー情報に含まれる固有IDと、前記サーバー装置において認証されるユーザー情報のうち前記属性情報を含むユーザー情報に含まれるユーザーの固有IDとを紐付けて、前記端末装置と前記サーバー装置との認証連携に係るIDマッピング情報を生成する生成手段と、を有することによって課題を解決する。
【選択図】図6
Description
本発明は、サーバー装置、端末装置、システム、情報処理方法及びプログラムに関する。
近年、企業内に設置されたPC、タブレット、画像形成装置等の端末が、インターネット上に展開された所謂クラウドサービスと連携し、ユーザーに機能を提供する形態が拡大している。各端末は、クラウドサービスと連携することによって、端末自身が持つ機能だけではなく、それ以外の機能もユーザーに提供することができる。
企業内に設置された端末やインターネット上に展開されたクラウドサービスを利用するためには、正当でない利用の防止やユーザーを識別するために、通常、ユーザー認証を必要とする。その結果、ユーザーは端末を用いてクラウドサービスと連携する機能を利用するために、端末及びクラウドサービスのそれぞれにて、認証情報の入力を求められることになり、利便性にかけるという課題がある。
この課題を解決する方法として、複数の認証システム間で連携することで、一方の認証システムでの認証結果をもって、他方の認証システムにて認証することができるシングルサインオン技術の利用が広がっている。例えば、Security Assertion Markup Language(以下SAML)プロトコルや、OpenID Foundation(http://openid.net/foundation/)が規定しているOpenID Connectといった技術が知られている。これらのシングルサインオン技術では、一方の認証システムで認証されたユーザーを特定するIDと、他方の認証システムでのユーザーを特定するIDとを対応付けたIDマッピング情報を用いることで、シングルサインオンするユーザーを特定している。
企業内に設置された端末やインターネット上に展開されたクラウドサービスを利用するためには、正当でない利用の防止やユーザーを識別するために、通常、ユーザー認証を必要とする。その結果、ユーザーは端末を用いてクラウドサービスと連携する機能を利用するために、端末及びクラウドサービスのそれぞれにて、認証情報の入力を求められることになり、利便性にかけるという課題がある。
この課題を解決する方法として、複数の認証システム間で連携することで、一方の認証システムでの認証結果をもって、他方の認証システムにて認証することができるシングルサインオン技術の利用が広がっている。例えば、Security Assertion Markup Language(以下SAML)プロトコルや、OpenID Foundation(http://openid.net/foundation/)が規定しているOpenID Connectといった技術が知られている。これらのシングルサインオン技術では、一方の認証システムで認証されたユーザーを特定するIDと、他方の認証システムでのユーザーを特定するIDとを対応付けたIDマッピング情報を用いることで、シングルサインオンするユーザーを特定している。
シングルサインオン技術を用いることで、ユーザーは、一度だけ認証情報を入力することで複数の認証システムから認証を受けることが可能となる。しかしながら、複数の認証システムを利用する場合、それら複数の認証システム間におけるユーザー情報のIDマッピング情報を事前に生成しておく必要がある。そのため、認証システムの数が増大すると、IDマッピング情報を生成するための作業負荷が増大するという課題がある。
特許文献1には、IDマッピング情報を自動生成する技術が開示されている。特許文献1には、複数の認証システムと、それら複数の認証システムと連携して共通で利用される認証基盤とから構成される技術が開示されている。認証基盤には共通IDと呼ばれる、認証基盤にてユーザーを識別するためのユーザーIDが登録されている。また、各認証システムのIDと、認証基盤の共通IDとのIDマッピング情報を認証基盤にて管理する構成となっている。そして、各認証システムのIDと共通IDとのIDマッピング情報は、ユーザーが各認証システムでの認証を受けた後に共通IDへの認証を行うことによって動的に生成される。即ち、認証基盤の共通IDへの認証を介して各認証システムのIDが紐付けられることになる。この認証基盤の共通IDへの認証を介することで、セキュアに、かつ、各ユーザーの操作によってIDマッピング情報が動的に生成されることを実現している。結果、管理者による、大量のユーザーに対するIDマッピング情報の生成や管理の負荷を軽減することができる。
特許文献1には、IDマッピング情報を自動生成する技術が開示されている。特許文献1には、複数の認証システムと、それら複数の認証システムと連携して共通で利用される認証基盤とから構成される技術が開示されている。認証基盤には共通IDと呼ばれる、認証基盤にてユーザーを識別するためのユーザーIDが登録されている。また、各認証システムのIDと、認証基盤の共通IDとのIDマッピング情報を認証基盤にて管理する構成となっている。そして、各認証システムのIDと共通IDとのIDマッピング情報は、ユーザーが各認証システムでの認証を受けた後に共通IDへの認証を行うことによって動的に生成される。即ち、認証基盤の共通IDへの認証を介して各認証システムのIDが紐付けられることになる。この認証基盤の共通IDへの認証を介することで、セキュアに、かつ、各ユーザーの操作によってIDマッピング情報が動的に生成されることを実現している。結果、管理者による、大量のユーザーに対するIDマッピング情報の生成や管理の負荷を軽減することができる。
従来技術により、各認証システムと認証基盤の共通IDとにおいて認証情報を入力することで自動的にIDマッピング情報が生成されるため、管理者による大量ユーザーのIDマッピング情報の生成及び管理のための作業負荷を軽減することができる。しかしながら、各ユーザーが全ての認証システムと共通IDとについて認証情報の入力を少なくとも一度は行う必要があり、各ユーザーの作業負荷をなくすことはできていない。
本発明は、各ユーザーの作業負荷を増やすことなく、かつ、管理者によるIDマッピング情報の生成の負荷を軽減することを目的とする。
本発明は、各ユーザーの作業負荷を増やすことなく、かつ、管理者によるIDマッピング情報の生成の負荷を軽減することを目的とする。
そこで、本発明のサーバー装置は、端末装置とネットワークを介して通信可能なサーバー装置であって、前記端末装置のユーザーの固有IDを含むユーザー情報を前記端末装置から受信する受信手段と、前記受信手段により受信されたユーザー情報のうち前記端末装置により指定された属性情報を含むユーザー情報に含まれる固有IDと、前記サーバー装置において認証されるユーザー情報のうち前記属性情報を含むユーザー情報に含まれるユーザーの固有IDとを紐付けて、前記端末装置と前記サーバー装置との認証連携に係るIDマッピング情報を生成する生成手段と、を有する。
本発明によれば、各ユーザーの作業負荷を増やすことなく、かつ、管理者によるIDマッピング情報の生成の負荷を軽減することができる。
以下、本発明を実施するための形態について図面を用いて説明する。
<実施形態1>
本実施形態においては、端末利用者が、端末からクラウドサービスを利用する際に、端末にて認証されていることをもってシングルサインオンを実現する。そのシングルサインオンを実現するためには、以下の処理が事前に必要となる。
まず、第一の設定として端末の管理者が、クラウドサービスにてシングルサインオンをするための設定を実施する。なお本実施形態では、シングルサインオン技術として、OpenID Connectを利用して説明するが、プロトコルを限定するわけではない。例えば、シングルサインオン技術であれば、SAMLやOpenIDを用いることも可能である。
次に、第二の設定として端末をクラウドサービスに登録し、当該端末であることを証明するための情報を取得しておく必要がある。この情報は、OAuth2.0でいうところのクライアントID及びシークレットである。本実施形態では、この端末登録の方法として、SSL/TLSのX.509証明書を用いたクライアント認証を用いて、端末自身が能動的に登録処理を実施し、クライアントID、シークレットを取得するフローで説明する。しかしながら、この方法に限定するわけではない。例えば、ID、パスワードや、何かしらのトークンを用いてクライアント認証を受け、動的に登録処理するよう構成することもできる。更に、管理者が、別の方法で取得したクライアントID、シークレットを端末に登録する構成でも実現することができる。
<実施形態1>
本実施形態においては、端末利用者が、端末からクラウドサービスを利用する際に、端末にて認証されていることをもってシングルサインオンを実現する。そのシングルサインオンを実現するためには、以下の処理が事前に必要となる。
まず、第一の設定として端末の管理者が、クラウドサービスにてシングルサインオンをするための設定を実施する。なお本実施形態では、シングルサインオン技術として、OpenID Connectを利用して説明するが、プロトコルを限定するわけではない。例えば、シングルサインオン技術であれば、SAMLやOpenIDを用いることも可能である。
次に、第二の設定として端末をクラウドサービスに登録し、当該端末であることを証明するための情報を取得しておく必要がある。この情報は、OAuth2.0でいうところのクライアントID及びシークレットである。本実施形態では、この端末登録の方法として、SSL/TLSのX.509証明書を用いたクライアント認証を用いて、端末自身が能動的に登録処理を実施し、クライアントID、シークレットを取得するフローで説明する。しかしながら、この方法に限定するわけではない。例えば、ID、パスワードや、何かしらのトークンを用いてクライアント認証を受け、動的に登録処理するよう構成することもできる。更に、管理者が、別の方法で取得したクライアントID、シークレットを端末に登録する構成でも実現することができる。
次に、第三の設定として端末の管理者が、端末がクラウドサービスとシングルサインオンすることを許可するための設定をする。ここでは、先ほど取得したクライアントID、シークレットを用いた、OAuth2.0をプロトコルとして許可するための処理を説明するが、プロトコルを限定するわけではない。例えば、取得したクライアントID、シークレットを用いたBasic認証によって、端末自身が許可を得るよう構成することも可能である。
そして、第四の設定として、複数の端末間でのユーザー情報の同期と、端末とクラウドサービスとのユーザーのIDマッピング情報の生成を行う。この第四の設定は、第三の設定の中で実施される場合と、端末にて端末のユーザー情報の更新を行った際に実施される場合とがある。
本実施形態では、これら第一、第二、第三、第四の設定を順次説明し、その後に、端末利用者によるシングルサインオン処理について説明する。
そして、第四の設定として、複数の端末間でのユーザー情報の同期と、端末とクラウドサービスとのユーザーのIDマッピング情報の生成を行う。この第四の設定は、第三の設定の中で実施される場合と、端末にて端末のユーザー情報の更新を行った際に実施される場合とがある。
本実施形態では、これら第一、第二、第三、第四の設定を順次説明し、その後に、端末利用者によるシングルサインオン処理について説明する。
本実施形態に係るシングルサインオンシステムは、図1に示すような構成のネットワーク上に実現される。図1は、本実施形態に係るシングルサインオンシステムのシステム構成の一例を示す図である。100は、Wide Area Network(WAN)であり、本実施形態ではWorld Wide Web(WWW)システムが構築されている。101は、各構成要素を接続するLocal Area Network(LAN)である。200は、OAuth2.0を実現するための認可サーバー装置(以下、単に認可サーバーとする)である。400A、400B(以下、400とする)は、端末装置(以下、単に端末とする)である。端末400は、PCや、スマートフォンやタブレットと呼ばれる携帯端末や、画像形成装置等であり、端末利用者を認証するための認証モジュールを備える。この認証モジュールは不図示の認証サーバーと通信することで端末利用者を認証するよう構成することもできる。更に、端末400は、Webブラウザーと、アプリケーションモジュールとを備える。ユーザーはそれらのWebブラウザーやアプリケーションモジュールを用いて認可サーバー200と通信する。500は、データベースサーバー装置(以下、単にデータベースサーバーとする)である。データベースサーバー500は、認可サーバー200とLAN101を介して接続しており、認可モジュールが利用するデータが格納されている。また、認可サーバー200と端末400とはWAN100及びLAN101を介して接続されている。なお、データベースサーバー500は、認可サーバー200と同一のサーバー上に構成されてもよい。
このように本実施形態に係るシングルサインオンシステムでは、認可サーバー200、データベースサーバー500、端末400がネットワークを介して通信可能に接続されている。
このように本実施形態に係るシングルサインオンシステムでは、認可サーバー200、データベースサーバー500、端末400がネットワークを介して通信可能に接続されている。
図2は、認可サーバー200、端末400のハードウェア構成の一例を示す図である。なお、図2に示されるハードウェアブロック図は、PC等の一般的な情報処理装置のハードウェアブロック図に相当するものとし、本実施形態の各サーバー及び端末には一般的な情報処理装置のハードウェア構成を適用できる。以下、図2のハードウェア構成を認可サーバー200のハードウェア構成とした場合を例に説明する。
CPU201は、ROM203のプログラム用ROMに記憶された、或いはハードディスク(HD)等の外部メモリ211からRAM202にロードされたOSやアプリケーション等のプログラムを実行し、システムバス204に接続される各ブロックを制御する。ここでOSとはコンピュータ上で稼動するオペレーティングシステムの略語であり、以下オペレーティングシステムのことをOSと呼ぶ。RAM202は、CPU201の主メモリ、ワークエリア等として機能する。キーボードコントローラ(KBC)205は、キーボード209や不図示のポインティングデバイスからのキー入力を制御する。CRTコントローラ(CRTC)206は、CRTディスプレイ210の表示を制御する。ディスクコントローラ(DKC)207は、各種データを記憶するハードディスク(HD)等の外部メモリ211におけるデータアクセスを制御する。ネットワークコントローラ(NC)208は、WAN100、LAN101、もしくは公衆回線を介して接続された他の機器との通信制御処理を実行する。
CPU201は、ROM203のプログラム用ROMに記憶された、或いはハードディスク(HD)等の外部メモリ211からRAM202にロードされたOSやアプリケーション等のプログラムを実行し、システムバス204に接続される各ブロックを制御する。ここでOSとはコンピュータ上で稼動するオペレーティングシステムの略語であり、以下オペレーティングシステムのことをOSと呼ぶ。RAM202は、CPU201の主メモリ、ワークエリア等として機能する。キーボードコントローラ(KBC)205は、キーボード209や不図示のポインティングデバイスからのキー入力を制御する。CRTコントローラ(CRTC)206は、CRTディスプレイ210の表示を制御する。ディスクコントローラ(DKC)207は、各種データを記憶するハードディスク(HD)等の外部メモリ211におけるデータアクセスを制御する。ネットワークコントローラ(NC)208は、WAN100、LAN101、もしくは公衆回線を介して接続された他の機器との通信制御処理を実行する。
後述する説明においては、特に断りのない限り、認可サーバー200における実行のハード上の主体はCPU201であるものとする。そして、CPU201が外部メモリ211等に記憶されているアプリケーションプログラムを実行することにより、後述する認可サーバー200のソフトウェア構成及びシーケンス図における認可サーバー200の処理が実現される。
端末400のハードウェア構成についても上述した図2の通りである。即ち、端末400のCPU201が端末400の外部メモリ211等に記憶されているアプリケーションプログラムを実行することにより、後述する端末400のソフトウェア構成及びシーケンス図における端末400の処理が実現される。
端末400のハードウェア構成についても上述した図2の通りである。即ち、端末400のCPU201が端末400の外部メモリ211等に記憶されているアプリケーションプログラムを実行することにより、後述する端末400のソフトウェア構成及びシーケンス図における端末400の処理が実現される。
図3は、認可サーバー200、端末400のソフトウェア構成の一例を示す図である。認可サーバー200は、認可モジュール600、HTTPサーバーモジュール610をアプリケーションとして備える。HTTPサーバーモジュール610は、WAN100を介して接続する端末400とのHTTP通信を行うためのモジュールである。また、HTTPサーバーモジュール610は、SSL/TLSによる通信が可能に構成されており、不図示の証明書ストアを持つ。また、本実施形態におけるHTTPサーバーモジュール610は、後述するクライアント登録要求を受け付けるエンドポイントにて、要求元に対してX.509形式の証明書による認証を要求するよう構成されている。
認可モジュール600は、HTTPサーバーモジュール610上で動作したり、HTTPサーバーモジュール610と連携して動作したりするWebアプリケーションである。認可モジュール600は、HTTPサーバーモジュール610を介して端末400からの要求を受け付け、処理し、応答する。以後、本実施形態では、端末400からHTTPサーバーモジュール610を介して認可モジュール600とHTTP通信する処理について、単に端末400からの認可モジュール600への要求及び応答として記載する。また、本実施形態では、HTTPサーバーモジュール610にて、後述するクライアント登録要求を受け付けた場合は、要求元にX.509証明書を用いたクライアント認証を要求するよう構成されている。そして、クライアント認証に成功した場合、受信したクライアント認証情報を認可モジュール600に通知するよう構成されている。また、認可モジュール600は、OAuth2.0に対応しており、端末400からのOAuth2.0に関するリクエストを処理して応答する機能を備える。その際、認可モジュール600は、端末400に対して、ユーザーを認証するための画面を応答し、ユーザーを認証する機能を備える。更に、認可モジュール600は、OpenID ConnectのRP(Relying Party)の機能を備えており、後述する端末400にて認証された情報をもって、シングルサインオンを受ける機能を備える。
認可モジュール600は、HTTPサーバーモジュール610上で動作したり、HTTPサーバーモジュール610と連携して動作したりするWebアプリケーションである。認可モジュール600は、HTTPサーバーモジュール610を介して端末400からの要求を受け付け、処理し、応答する。以後、本実施形態では、端末400からHTTPサーバーモジュール610を介して認可モジュール600とHTTP通信する処理について、単に端末400からの認可モジュール600への要求及び応答として記載する。また、本実施形態では、HTTPサーバーモジュール610にて、後述するクライアント登録要求を受け付けた場合は、要求元にX.509証明書を用いたクライアント認証を要求するよう構成されている。そして、クライアント認証に成功した場合、受信したクライアント認証情報を認可モジュール600に通知するよう構成されている。また、認可モジュール600は、OAuth2.0に対応しており、端末400からのOAuth2.0に関するリクエストを処理して応答する機能を備える。その際、認可モジュール600は、端末400に対して、ユーザーを認証するための画面を応答し、ユーザーを認証する機能を備える。更に、認可モジュール600は、OpenID ConnectのRP(Relying Party)の機能を備えており、後述する端末400にて認証された情報をもって、シングルサインオンを受ける機能を備える。
端末400は、認証モジュール810、Webブラウザー820及びアプリケーションモジュール800をアプリケーションとして備える。認証モジュール810は、端末400を利用する端末利用者を認証するための機能を備える。認証モジュール810は、不図示の認証サーバーと通信することで端末利用者を認証するよう構成することもできる。本実施形態では、端末400内で管理している端末ユーザー情報を用いて認証する構成で説明する。アプリケーションモジュール800は、端末400にて動作するアプリケーションである。アプリケーションモジュール800は、後述する処理を行うことで、端末400への認証を基に、認可モジュール600へのシングルサインオンを実現する。端末400は、WWWを利用するためのユーザーエージェントであるWebブラウザー820を備える。また、アプリケーションモジュール800は、自身を証明するためのX.509形式の証明書及びその秘密鍵を保持している。そして、アプリケーションモジュール800は、それらをHTTPサーバーモジュール610との通信確立時に利用することで、HTTPサーバーモジュール610に対してアプリケーションモジュール800からの要求であることを証明することができる。
図4を用いて第一の設定である、端末400の管理者が認可モジュール600にてシングルサインオンをするための設定を説明する。管理者は、端末400が備えるWebブラウザー820を用いて認可モジュール600のシングルサインオン設定画面にアクセスする。認可モジュール600は、ユーザーが認証済みかどうかを検証し、未認証である場合はログイン画面を応答する。ユーザーが認証済みかどうかを検証するために、一般的には、Webブラウザー820からリクエストされるHTTPヘッダーのCookie情報に認証トークンが含まれているかを確認する。そして、認証トークンが含まれている場合は、認証トークンが有効か否かを検証することによって行われる。
図4(a)は、ログイン画面の例である。ログイン画面2000は、ユーザーIDを入力するためのユーザーID入力領域2001、パスワードを入力するためのパスワード入力領域2002及び入力したユーザーID、パスワードを用いてユーザー認証を実行するためのログインボタン2003を備える。端末400の管理者は、応答されたログイン画面2000にて、認可モジュール600へユーザー認証するためのユーザーID、パスワードを入力し、ログインボタン2003を押下する。Webブラウザー820は、ログインボタン2003の押下を検知すると、ログイン要求として、ユーザーID入力領域2001及びパスワード入力領域2002に入力されている情報を認可モジュール600に送信する。
図4(a)は、ログイン画面の例である。ログイン画面2000は、ユーザーIDを入力するためのユーザーID入力領域2001、パスワードを入力するためのパスワード入力領域2002及び入力したユーザーID、パスワードを用いてユーザー認証を実行するためのログインボタン2003を備える。端末400の管理者は、応答されたログイン画面2000にて、認可モジュール600へユーザー認証するためのユーザーID、パスワードを入力し、ログインボタン2003を押下する。Webブラウザー820は、ログインボタン2003の押下を検知すると、ログイン要求として、ユーザーID入力領域2001及びパスワード入力領域2002に入力されている情報を認可モジュール600に送信する。
表1に、認可モジュール600のユーザーテーブルに登録されているユーザー情報の例を示す。
ログイン要求を受けた認可モジュール600は、受信したユーザーID、パスワードの組が認可モジュール600のユーザーテーブルに登録されているユーザー情報と合致するかを検証することで、ユーザーを認証する。例えば、認可モジュール600は、受信したユーザーIDが「admin@xx.com」で、パスワードが「admin」であった場合、ユーザーID「admin@xx.com」のユーザーとして認証する。そして、認可モジュール600は、認証したことを示す認証トークンを生成し、Cookieに設定し、認可モジュール600のシングルサインオン設定画面にリダイレクトされるよう応答する。認証トークンは、ユーザーID、もしくは、ユーザーをユニークに特定するためのUUIDと紐付けられ、認可モジュール600にて保存される。認可モジュール600は、ログイン要求の情報が合致しない場合は、不図示のログインエラー画面を応答する。なお、本実施形態では、ユーザーを認証するための情報として、ユーザーIDとパスワードとの組を利用する方法で説明しているが、この方法に限定するわけではない。例えば、SSL/TLSのクライアント証明書を利用する方法や、複数の認証情報を入力することによる多要素認証といった方法を用いることも可能である。
Webブラウザー820は、Cookieに設定された認証トークンを用いて、認可モジュール600のシングルサインオン設定画面へアクセスする。認可モジュール600は、認証トークンを用いてユーザーが認証済みかどうかを検証し、認証済みである場合は認証トークンに紐付けられた情報をもってユーザーを特定する。そして、認可モジュール600は、特定したユーザーの権限情報が「管理者」である場合に、シングルサインオン設定画面を応答する。例えば、認可モジュール600は、認証トークンに紐付けられた情報が「UUID:10000000」であった場合は、認可モジュール600のユーザーテーブルのUUID列を検索し、一致する「行1」のユーザーであることを特定する。そして、認可モジュール600は、行1のユーザーの権限情報列を参照すると「管理者」であることがわかる。ここで、認可モジュール600は、特定したユーザーの権限情報が「管理者」ではなかった場合は、不図示の権限エラー画面を応答する。
図4(b)は、シングルサインオン設定画面の例である。シングルサインオン設定画面2100は、シングルサインオン設定を有効化するための有効ボタン2101、無効化するための無効ボタン2102を備える。また、シングルサインオン設定が有効な場合は、ユーザー情報のIDマッピング情報の生成を自動で行うか手動で行うかを選択するための自動マッピング選択ボタン2103を備える。自動マッピングが選択された場合は、ユーザー情報のどの属性の一致によってIDマッピングするか、即ち、マッピング条件を選択するための属性選択ボタン2104を備える。この属性選択ボタン2104は、本実施形態ではメールアドレスかユーザー名を選択可能に構成しているが、その他の属性を追加することも可能である。なお、自動マッピングしない場合は、不図示の画面にて、手動でIDマッピング情報を設定することになる。そして、これらIDマッピング設定を反映するためのIDマッピング設定ボタン2105を備える。本実施形態ではシングルサインオン設定が有効で、かつ、IDマッピング設定としてメールアドレスによる自動マッピングが設定されているとして説明する。
以上が、第一の設定である、端末400の管理者が認可モジュール600にて行うシングルサインオンをするための設定である。
図4(b)は、シングルサインオン設定画面の例である。シングルサインオン設定画面2100は、シングルサインオン設定を有効化するための有効ボタン2101、無効化するための無効ボタン2102を備える。また、シングルサインオン設定が有効な場合は、ユーザー情報のIDマッピング情報の生成を自動で行うか手動で行うかを選択するための自動マッピング選択ボタン2103を備える。自動マッピングが選択された場合は、ユーザー情報のどの属性の一致によってIDマッピングするか、即ち、マッピング条件を選択するための属性選択ボタン2104を備える。この属性選択ボタン2104は、本実施形態ではメールアドレスかユーザー名を選択可能に構成しているが、その他の属性を追加することも可能である。なお、自動マッピングしない場合は、不図示の画面にて、手動でIDマッピング情報を設定することになる。そして、これらIDマッピング設定を反映するためのIDマッピング設定ボタン2105を備える。本実施形態ではシングルサインオン設定が有効で、かつ、IDマッピング設定としてメールアドレスによる自動マッピングが設定されているとして説明する。
以上が、第一の設定である、端末400の管理者が認可モジュール600にて行うシングルサインオンをするための設定である。
図5を用いて、第二の設定である端末400を認可モジュール600に登録する処理(以下、クライアント登録処理とする)に関するシーケンスを説明する。本シーケンスは、ユーザーが端末400において、認可モジュール600に未登録であるアプリケーションモジュール800を利用する際のフローを示している。ユーザーが端末400のアプリケーションモジュール800利用時に認可モジュール600に未登録である、即ち後述するクライアントID、シークレットが未取得である場合に開始されるシーケンスである。
アプリケーションモジュール800は、自身が未登録であった場合、S1.1にて、認可モジュール600に対して、クライアント登録要求を行う。なお、本実施形態ではアプリケーションモジュール800がクライアント登録要求を行うきっかけを、端末400にてユーザーが当該アプリケーションモジュール800をインストールし、初めて起動したタイミングとして説明する。なお、他のきっかけとしては、ユーザーがアプリケーションモジュール800の機能を選択し、不図示のリソースサーバーへのリソース要求が発生するタイミングが考えられる。また、アプリケーションモジュール800が明示的に開始される操作を受け付ける操作画面を備え、ユーザーが端末400にて当該操作をしたタイミングが考えられる。なお、クライアント登録要求は、クライアント名や、リダイレクトURI等の、OAuthのAuthorization Code Grantを利用するための情報を含む。また、その他の情報として、クライアントを説明するための文字列や、説明が記載されるサイトのURI等の付属情報を含むよう構成することもできる。
アプリケーションモジュール800は、自身が未登録であった場合、S1.1にて、認可モジュール600に対して、クライアント登録要求を行う。なお、本実施形態ではアプリケーションモジュール800がクライアント登録要求を行うきっかけを、端末400にてユーザーが当該アプリケーションモジュール800をインストールし、初めて起動したタイミングとして説明する。なお、他のきっかけとしては、ユーザーがアプリケーションモジュール800の機能を選択し、不図示のリソースサーバーへのリソース要求が発生するタイミングが考えられる。また、アプリケーションモジュール800が明示的に開始される操作を受け付ける操作画面を備え、ユーザーが端末400にて当該操作をしたタイミングが考えられる。なお、クライアント登録要求は、クライアント名や、リダイレクトURI等の、OAuthのAuthorization Code Grantを利用するための情報を含む。また、その他の情報として、クライアントを説明するための文字列や、説明が記載されるサイトのURI等の付属情報を含むよう構成することもできる。
認可サーバー200のHTTPサーバーモジュール610ではクライアント認証が必要になるよう構成されている。そのため、アプリケーションモジュール800からのクライアント登録要求に対してHTTPサーバーモジュール610によるクライアント認証の処理が実施される。アプリケーションモジュール800からのクライアント登録要求を受け付けたHTTPサーバーモジュール610は、SSL/TLS通信のネゴシエーションを開始する。HTTPサーバーモジュール610は、アプリケーションモジュール800に対してクライアント認証を要求する。S1.2にて、HTTPサーバーモジュール610は、不図示の証明書ストアにて設定されている証明書を用いて、取得したクライアント認証情報を検証し、アプリケーションモジュール800をデバイス登録の要求元として認証する。なお、本実施形態ではクライアントの認証方法として、SSL/TLSのクライアント証明書による認証方式にて説明したが、その他にも例えば、Basic認証やDigest認証といった、ID及びパスワードを用いる方式等が考えられる。更には、これら主体を認証する機能を経て、認証された主体に対してクライアントを登録するための認可トークンを発行する機能を設け、当該認可トークンを検証することによってクライアント登録を受け付けるよう構成することも可能である。
S1.3にて、HTTPサーバーモジュール610は、アプリケーションモジュール800を認証した後に、認可モジュール600に対して、アプリケーションモジュール800から受信したクライアント登録要求を通知する。その際、HTTPサーバーモジュール610は、認証したアプリケーションモジュール800を識別するためのクライアントの認証情報も通知する。S1.4にて、認可モジュール600は、HTTPサーバーモジュール610より通知されたクライアント認証情報を取得する。
S1.3にて、HTTPサーバーモジュール610は、アプリケーションモジュール800を認証した後に、認可モジュール600に対して、アプリケーションモジュール800から受信したクライアント登録要求を通知する。その際、HTTPサーバーモジュール610は、認証したアプリケーションモジュール800を識別するためのクライアントの認証情報も通知する。S1.4にて、認可モジュール600は、HTTPサーバーモジュール610より通知されたクライアント認証情報を取得する。
表2に、認可モジュール600のクライアント認証情報テーブルの例を示す。
例えば、認可モジュール600にて取得したクライアント認証情報が、「Issuer=xx.com,Subject=dev.xx.com」だった場合、クライアント登録する際の権限は「SSO可」となる。また、前記取得したクライアント認証情報が未登録だった場合は、認証エラーとなり、認可モジュール600は、アプリケーションモジュール800に認証エラーを応答する。
S1.5にて、認可モジュール600は、クライアントID及びクライアントを認証するための秘匿情報であるシークレットを発行し、クライアント登録要求にて取得した情報と合わせてデータを格納する。表3に、認可モジュール600が格納する、認可モジュール600のクライアントテーブルの例を示す。
S1.5にて、認可モジュール600は、クライアントID及びクライアントを認証するための秘匿情報であるシークレットを発行し、クライアント登録要求にて取得した情報と合わせてデータを格納する。表3に、認可モジュール600が格納する、認可モジュール600のクライアントテーブルの例を示す。
上記登録が完了した後に、S1.6にて、認可モジュール600は、発行したクライアントIDとシークレットとを、アプリケーションモジュール800に応答する。アプリケーションモジュール800は、取得したクライアントID及びシークレットを保存する。その際、アプリケーションモジュール800は、認可モジュール600への認可要求を行うためのURIである認可URIを格納する。この認可URIは、クライアント登録の応答として認可モジュール600に応答するよう構成される。表4に、アプリケーションモジュール800のクライアントテーブルの例を示す。
以上が第二の設定であるクライアント登録処理である。このシーケンスによって、端末400が認可モジュール600に登録される。
図6を用いて、第三の設定である、端末400が認可モジュール600とシングルサインオンすることを許可するために端末400の管理者により行われる設定に係る処理のシーケンスを説明する。また、本シーケンスにて、第四の設定である、ユーザー情報の同期処理、端末400とクラウドサービスとにおけるユーザーのIDマッピング情報の生成処理についても説明する。
S2.1にて、端末400の管理者は、端末400にてログイン操作を行う。このログイン操作は、端末400が備える認証モジュール830において定められている認証方法によって行われる。本実施形態の特徴として、この認証方法はシングルサインオンシステムと関係することなく選択することができる。認証方法としては、例えば、ユーザーID、パスワードの組み合わせを検証する方法、指紋等の生体情報を利用する方法、非接触型のICカードを利用する方法、更には、複数の認証方法を組み合わせる多要素認証方法等が考えられる。また、認証モジュール830が、不図示の認証サーバーと通信することで端末利用者を認証するよう構成することもできる。本実施形態では、ユーザーID、パスワードの組み合わせを検証する認証方法を用いた場合を例として説明する。表5に、本実施形態における認証モジュール810のユーザーテーブルの例を示す。
認証モジュール810は、認証モジュール810のユーザーテーブルを参照し、ユーザーID、パスワードの組にてユーザー認証を行う。また、UUIDは、端末400のユーザーを一意に識別するための情報(固有ID)である。このUUIDが、後述するIDマッピング情報に登録されるIDとなる。
S2.1にて、端末400の管理者は、端末400にてログイン操作を行う。このログイン操作は、端末400が備える認証モジュール830において定められている認証方法によって行われる。本実施形態の特徴として、この認証方法はシングルサインオンシステムと関係することなく選択することができる。認証方法としては、例えば、ユーザーID、パスワードの組み合わせを検証する方法、指紋等の生体情報を利用する方法、非接触型のICカードを利用する方法、更には、複数の認証方法を組み合わせる多要素認証方法等が考えられる。また、認証モジュール830が、不図示の認証サーバーと通信することで端末利用者を認証するよう構成することもできる。本実施形態では、ユーザーID、パスワードの組み合わせを検証する認証方法を用いた場合を例として説明する。表5に、本実施形態における認証モジュール810のユーザーテーブルの例を示す。
S2.2にて、認証モジュール830は、ユーザーを認証する。例えば、ユーザーIDが「admin」で、パスワードが「admin」であった場合、認証モジュール830は、ユーザーID「admin」のユーザーとして認証する。S2.3にて、認証モジュール830は、認証したユーザーの認証情報を生成し保存する。この認証情報は、端末400の管理者が不図示のログアウト操作を実施するか、設定された時刻が経過するまで有効な状態で保存される。認証情報には、認証したユーザーのユーザーID、UUID及び権限情報が格納されている。なお、認証情報としては、各情報を直接格納するのではなく、ユーザーID、UUID及び権限情報が参照可能に紐付けられたトークンでもよい。
端末400の管理者は、認証モジュール830での認証を受けた後に、S2.4、S2.5にて、Webブラウザー820を用いてアプリケーションモジュール800にアクセスする。なお、アプリケーションモジュール800へのアクセスを開始するきっかけとしては、アプリケーションモジュール800へアクセスするためのブックマークが保存され、そのブックマークを選択した場合が考えられる。また、アプリケーションモジュール800が明示的に開始される操作を受け付ける操作画面を備え、端末400の管理者が、端末400にて当該操作をしたタイミングが考えられる。
端末400の管理者は、認証モジュール830での認証を受けた後に、S2.4、S2.5にて、Webブラウザー820を用いてアプリケーションモジュール800にアクセスする。なお、アプリケーションモジュール800へのアクセスを開始するきっかけとしては、アプリケーションモジュール800へアクセスするためのブックマークが保存され、そのブックマークを選択した場合が考えられる。また、アプリケーションモジュール800が明示的に開始される操作を受け付ける操作画面を備え、端末400の管理者が、端末400にて当該操作をしたタイミングが考えられる。
S2.6にて、アプリケーションモジュール800は、Webブラウザー820に対して操作画面を応答する。図7(a)は、アプリケーションモジュール800が応答する操作画面の例である。操作画面2200は、端末400の管理者が認証連携を開始するための認証連携ボタン2201と、後述するユーザーが認可連携を開始するための認可連携ボタン2202とを備える。なお、本画面を応答する際に、アプリケーションモジュール800は、認証モジュール830から認証情報を取得し、権限情報が「管理者」の場合にのみ認証連携ボタン2201を表示するよう構成することができる。S2.7にて、端末400の管理者は、Webブラウザー820に表示された操作画面2200にて、認証連携ボタン2201を押下する。S2.8にて、Webブラウザー820は、アプリケーションモジュール800に対して認証連携要求を行う。
認証連携要求を受けたアプリケーションモジュール800は、認証連携処理フローを開始する。認証連携処理フローは、アプリケーションモジュール800が、認可モジュール600に対してOAuth2.0による認可トークン取得を行うフローと、取得した認可トークンを用いて認可モジュール600に対して認証連携を要求するフローとからなる。OAuth2.0による認可トークン取得を行うフローとして、本実施形態ではOAuth2.0に定義されているAuthorization Code Grantを用いて説明するが、これに限定するわけではない。例えば、Implicit Grantを用いることも可能である。
認証連携要求を受けたアプリケーションモジュール800は、認証連携処理フローを開始する。認証連携処理フローは、アプリケーションモジュール800が、認可モジュール600に対してOAuth2.0による認可トークン取得を行うフローと、取得した認可トークンを用いて認可モジュール600に対して認証連携を要求するフローとからなる。OAuth2.0による認可トークン取得を行うフローとして、本実施形態ではOAuth2.0に定義されているAuthorization Code Grantを用いて説明するが、これに限定するわけではない。例えば、Implicit Grantを用いることも可能である。
S2.9、S2.10にて、アプリケーションモジュール800は、Webブラウザー820を介して認可モジュール600へ認可要求を行う。この認可要求は、表4のクライアントテーブルに登録されている認可URI「https://authz/C001/authz」に対して行われる。また、この認可要求には、少なくとも、クライアント登録の結果取得したクライアントID及び登録したリダイレクトURI、そして認可モジュール600の認証連携を実施するためのリソース範囲を示すスコープが含まれる。認可要求を受けた認可モジュール600は、ユーザーが認証済みかどうかを検証し、未認証である場合はS2.11にて、ログイン画面を応答する。S2.12、S2.13、S2.14にて行われる、認可モジュール600におけるユーザー認証処理については前述の通りである。ユーザー認証処理の結果、認証トークンが生成される。
S2.15にて、認可モジュール600は、受信した認可要求のうち、クライアントIDとリダイレクトURIとの組が正しいか検証する。より具体的には、認可モジュール600は、認可要求に含まれるクライアントID、リダイレクトURIの組が、認可モジュール600のクライアントテーブルに登録されているクライアントID、リダイレクトURIの組と一致するか検証する。不一致の場合、認可モジュール600は、不図示のエラー画面をWebブラウザー820に応答する。一致した場合、認可モジュール600は、認証トークンからユーザーを特定する。特定したユーザーの権限情報が「管理者」でない場合、認可モジュール600は、Webブラウザー820を介してアプリケーションモジュール800に権限エラーを応答する。ユーザーの権限情報が「管理者」である場合、認可モジュール600は、S2.16にてWebブラウザー820に対して認可確認画面を応答する。
S2.15にて、認可モジュール600は、受信した認可要求のうち、クライアントIDとリダイレクトURIとの組が正しいか検証する。より具体的には、認可モジュール600は、認可要求に含まれるクライアントID、リダイレクトURIの組が、認可モジュール600のクライアントテーブルに登録されているクライアントID、リダイレクトURIの組と一致するか検証する。不一致の場合、認可モジュール600は、不図示のエラー画面をWebブラウザー820に応答する。一致した場合、認可モジュール600は、認証トークンからユーザーを特定する。特定したユーザーの権限情報が「管理者」でない場合、認可モジュール600は、Webブラウザー820を介してアプリケーションモジュール800に権限エラーを応答する。ユーザーの権限情報が「管理者」である場合、認可モジュール600は、S2.16にてWebブラウザー820に対して認可確認画面を応答する。
図7(b)は、応答される認可確認画面の例である。認可確認画面2300は、認可要求に含まれるクライアントIDを基に認可モジュール600のクライアントテーブルから取得したクライアント名を表示する領域であるアクセス元表示領域2301を備える。また、認可確認画面2300は、認可要求に含まれるスコープの説明を表示する領域であるスコープ表示領域2302を備える。更に、認可確認画面2300は、ユーザーが上記情報の内容について認可操作を実行する許可ボタン2303及び拒否を実行する拒否ボタン2304を備える。ここで、ユーザーが拒否ボタン2304を押下した場合、認可モジュール600は、Webブラウザー820を介してアプリケーションモジュール800に権限エラーを応答する。S2.17にて、端末400の管理者が認可確認画面2300で許可ボタン2303を押下、即ち認可操作を行った場合、Webブラウザー820は、S2.18にて認可モジュール600に認可されたことを通知する。
S2.19にて、認可モジュール600は、認可コードを発行する。より具体的には、認可モジュール600は、トークンIDを発行し、認可要求に含まれるスコープ、クライアントID、認証して許可を得たユーザーのUUIDを、トークンテーブルに登録する。その際、認可モジュール600は、トークン種別を認可コードとし、有効期限に当該認可コードが有効である日時を登録する。表6Aに認可モジュール600のトークンテーブルの例を示す。
S2.19にて、認可モジュール600は、認可コードを発行する。より具体的には、認可モジュール600は、トークンIDを発行し、認可要求に含まれるスコープ、クライアントID、認証して許可を得たユーザーのUUIDを、トークンテーブルに登録する。その際、認可モジュール600は、トークン種別を認可コードとし、有効期限に当該認可コードが有効である日時を登録する。表6Aに認可モジュール600のトークンテーブルの例を示す。
S2.20、S2.21にて、認可モジュール600は、発行した認可コードのトークンIDを付与してWebブラウザー820を介し、アプリケーションモジュール800に認可を応答する。より具体的には、認可モジュール600は、認可要求時に取得したリダイレクトURIに対してWebブラウザー820をリダイレクトするようWebブラウザー820にリダイレクト応答する。S2.22にて、アプリケーションモジュール800は、認可モジュール600に対して認可トークンを要求する。この認可トークン要求には、少なくとも、取得した認可コード、保存しているクライアントID、シークレット及び認可要求時に送信したリダイレクトURIが含まれる。
S2.23にて、認可モジュール600は、取得したクライアントID、シークレットの組をもってクライアントを認証する。より具体的には、認可モジュール600は、取得したクライアントID、シークレットの組が、認可モジュール600のクライアントテーブルのクライアントID、シークレットの組と一致するかを検証することでクライアントを認証する。認可モジュール600は、クライアント認証に失敗した場合はアプリケーションモジュール800に認証エラーを応答する。一方、認可モジュール600は、クライアント認証に成功した場合、認証したクライアントIDにて特定されるクライアントの権限情報を確認する。クライアントの権限情報が「SSO可」でない場合、認可モジュール600は、アプリケーションモジュール800に権限エラーを応答する。一方、クライアントの権限情報が「SSO可」であった場合、認可モジュール600は、取得した認可コードを検証する。より具体的には、認可モジュール600は、取得した認可コードのトークンIDが認可モジュール600のトークンテーブルに登録されているかを検証し、登録されている場合は有効期限の範囲内かを検証する。更に、認可モジュール600は、認可トークン要求にて取得したリダイレクトURIが、トークンIDに紐付くクライアントIDのリダイレクトURIと一致するかを検証する。
S2.23にて、認可モジュール600は、取得したクライアントID、シークレットの組をもってクライアントを認証する。より具体的には、認可モジュール600は、取得したクライアントID、シークレットの組が、認可モジュール600のクライアントテーブルのクライアントID、シークレットの組と一致するかを検証することでクライアントを認証する。認可モジュール600は、クライアント認証に失敗した場合はアプリケーションモジュール800に認証エラーを応答する。一方、認可モジュール600は、クライアント認証に成功した場合、認証したクライアントIDにて特定されるクライアントの権限情報を確認する。クライアントの権限情報が「SSO可」でない場合、認可モジュール600は、アプリケーションモジュール800に権限エラーを応答する。一方、クライアントの権限情報が「SSO可」であった場合、認可モジュール600は、取得した認可コードを検証する。より具体的には、認可モジュール600は、取得した認可コードのトークンIDが認可モジュール600のトークンテーブルに登録されているかを検証し、登録されている場合は有効期限の範囲内かを検証する。更に、認可モジュール600は、認可トークン要求にて取得したリダイレクトURIが、トークンIDに紐付くクライアントIDのリダイレクトURIと一致するかを検証する。
認可コード検証の結果が無効であった場合、認可モジュール600は、アプリケーションモジュール800にトークンエラーを応答する。そして、認可コード検証の結果が有効であった場合、認可モジュール600は、S2.24にて認可トークンを発行する。より具体的には、認可モジュール600は、トークンIDを発行し、認可コードに紐付くスコープ、ユーザーのUUID、認証したクライアントIDを認可モジュール600のトークンテーブルに登録する。その際、認可モジュール600は、トークン種別を認可トークンとし、有効期限に当該認可トークンが有効である日時を登録する。また、認可モジュール600は、検証した認可コードを削除するか、有効期限を過去の日時に更新することで無効化する。表6Bに、認可モジュール600のトークンテーブルの例を示す。
S2.25にて、認可モジュール600は、発行した認可トークンのトークンIDをアプリケーションモジュール800に応答する。その際、認可トークンの有効期限を応答するよう構成することもできる。本実施形態では、認可トークンを更新するためのリフレッシュトークンを発行しない例で説明したが、認可モジュール600のトークンテーブルにて、リフレッシュトークンのトークンID及び有効期限を管理するよう構成することもできる。その際、認可モジュール600が、認可トークン発行時にリフレッシュトークンも発行し、認可トークンの応答時に発行したリフレッシュトークンのトークンIDも含めて応答するよう構成することもできる。
S2.26にて、認可トークンを取得したアプリケーションモジュール800は、クライアントID、シークレット及びX.509形式の鍵ペアを発行し、自身のOPテーブルに登録する。この際、OPIDは自身が認証要求を受け付けるURLとなる。表7Aにアプリケーションモジュール800のOPテーブルの例を示す。
S2.27にて、アプリケーションモジュール800は、取得した認可トークンを用いて認可モジュール600に認証連携要求を行う。認証連携要求には、少なくとも、認可トークンのトークンID、OPテーブルに登録したOPID、発行した鍵ペアの公開鍵、アプリケーションモジュール800で発行したクライアントID、シークレットが含まれる。S2.28にて、認可モジュール600は、検証要求された認可トークンのトークンIDを検証し、検証結果としてトークンに紐付く情報を取得する。より具体的には、認可モジュール600は、認可モジュール600のトークンテーブルに登録されていて、かつ、有効期限内であるかを検証し、結果が「利用不可」であれば、アプリケーションモジュール800に検証エラーの応答を返す。一方、認可モジュール600は、検証の結果が「利用可」であれば、特定された認可トークンに紐付く情報を認可トークン情報として取得する。この認可トークン情報には、少なくとも、認可モジュール600のトークンテーブルのクライアントID、UUID及びUUIDから特定される認可モジュール600のユーザーテーブルのユーザーIDが含まれる。なお、認可トークンの検証時にスコープを検証することもできる。その場合、認可モジュール600は、認可トークンのトークンIDで特定される認可トークンのスコープに、必要なスコープが含まれているか否かを検証する。
S2.29にて、認可トークンの検証結果が「利用可」であった場合、認可モジュール600は、認証連携設定を行う。より具体的には、認可モジュール600は、取得した情報を基に、RPテーブルにデータを登録する。その際、認可モジュール600は、認証要求の応答を受け付けるリダイレクトURI「https://authz/RP001/res」及び認可トークンに紐付くクライアントIDを認可クライアントIDとして格納する。表8に、認可モジュール600のRPテーブルの例を示す。
S2.30にて、認可モジュール600は、アプリケーションモジュール800に認証連携応答を返す。この認証連携応答には、少なくとも、RPテーブルに登録したリダイレクトURIが含まれる。S2.31にて、アプリケーションモジュール800は、OPテーブルを更新する。より具体的には、アプリケーションモジュール800は、取得した「リダイレクトURI」を追加する。表7Bに、アプリケーションモジュール800のOPテーブルの例を示す。
以上が第三の設定である。次に、第四の設定について説明する。
S2.32にて、アプリケーションモジュール800は、認可モジュール600に対してユーザー情報確認要求を行う。S2.33にて、認可モジュール600は、後述するIDマッピングマスターテーブルの有無を確認する。この場合は、まだIDマッピングマスターテーブルは生成されていない、もしくはデータが入っていないため、S2.34にて、認可モジュール600は、アプリケーションモジュール800に対して未登録であることを応答する。S2.35にて、アプリケーションモジュール800は、Webブラウザー820に対してユーザー情報登録確認画面を応答する。図7(c)は、アプリケーションモジュール800が応答するユーザー情報登録確認画面の例である。ユーザー情報登録確認画面2400は、端末400のユーザー情報を認可モジュール600に登録するか否かを確認する画面である。ユーザー情報登録確認画面2400は、登録を許可するボタン2401、拒否するボタン2402を備える。なお、拒否するボタン2402が押下された場合は、処理が終了する。
S2.36にて、端末400の管理者は、Webブラウザー820に表示されたユーザー情報登録確認画面2400にて、ユーザー情報の登録を許可するボタン2401を押下する。S2.37にて、Webブラウザー820は、アプリケーションモジュール800に対してユーザー登録要求を行う。S2.38にて、ユーザー登録要求を受けたアプリケーションモジュール800は、認証モジュール830に対してユーザー情報取得要求を行う。S2.39にて、ユーザー情報取得要求を受けた認証モジュール830は、表5に示す認証モジュール830のユーザーテーブルに登録されているユーザー情報を取得し、アプリケーションモジュール800に取得したユーザー情報を応答する。なお、このユーザー情報には、メールアドレス等の表5に示されていない他の情報が含まれていてもよい。S2.40にて、ユーザー情報の応答を受けたアプリケーションモジュール800は、認可モジュール600に対してユーザー情報登録要求を行う。ユーザー情報登録要求には、自身のOPID及び認証モジュール830から取得したユーザー情報が含まれる。
S2.36にて、端末400の管理者は、Webブラウザー820に表示されたユーザー情報登録確認画面2400にて、ユーザー情報の登録を許可するボタン2401を押下する。S2.37にて、Webブラウザー820は、アプリケーションモジュール800に対してユーザー登録要求を行う。S2.38にて、ユーザー登録要求を受けたアプリケーションモジュール800は、認証モジュール830に対してユーザー情報取得要求を行う。S2.39にて、ユーザー情報取得要求を受けた認証モジュール830は、表5に示す認証モジュール830のユーザーテーブルに登録されているユーザー情報を取得し、アプリケーションモジュール800に取得したユーザー情報を応答する。なお、このユーザー情報には、メールアドレス等の表5に示されていない他の情報が含まれていてもよい。S2.40にて、ユーザー情報の応答を受けたアプリケーションモジュール800は、認可モジュール600に対してユーザー情報登録要求を行う。ユーザー情報登録要求には、自身のOPID及び認証モジュール830から取得したユーザー情報が含まれる。
S2.41にて、ユーザー情報登録要求を受けた認可モジュール600は、取得した情報をIDマッピングマスターテーブルに保存する。その際、認可モジュール600は、マッピングキーとして、第一の設定のシングルサインオン設定画面2100にて設定されたIDマッピング設定の内容を反映する。本実施形態では、IDマッピング設定としてメールアドレスによる自動マッピングが設定されている。表9に、認可モジュール600のIDマッピングマスターテーブルの例を示す。
S2.42にて、認可モジュール600は、取得したOPID、ユーザー情報、IDマッピングマスターテーブル及び表1に示す認可モジュール600のユーザーテーブルの情報を基に、IDマッピング情報を生成する。より具体的には、認可モジュール600は、IDマッピングマスターテーブルから、マッピングキーで指定された属性に関する情報(属性情報)を取得し、この属性の値がユーザーテーブルに登録されているユーザーとのIDマッピング情報を生成する。例えば、本実施形態では、メールアドレス「admin@xx.com」が一致するとする。この場合、IDマッピングマスターテーブルの端末ユーザー名「admin」と、表1に示すユーザーテーブルのユーザーID「admin@xx.com」が同一ユーザーとしてマッピングされる。その際、認可モジュール600は、認証モジュール830から取得した端末ユーザーのUUIDと、表1に示すユーザーテーブルのUUIDとを紐付けて、IDマッピングテーブルに保存する。表10Aに、生成された認可モジュール600のIDマッピングテーブルの例を示す。
S2.43にて、認可モジュール600は、アプリケーションモジュール800に対してユーザー情報登録応答を返す。S2.44にて、アプリケーションモジュール800は、Webブラウザー820に対して操作画面を応答し、処理を終了する。ここで応答される操作画面は、図7(a)にて説明した操作画面2200である。その際、認証連携ボタン2201は実行済みであるとして無効状態で表示されるよう構成してもよい。
以上が、第三及び第四の設定である。これら処理の結果、端末400の管理者にて、端末400が認可モジュール600とシングルサインオンすることが許可される。また、以上の第一、第二、第三、第四の設定を行うことで、その後に、端末利用者によるシングルサインオン処理を行うことが可能となる。
以上が、第三及び第四の設定である。これら処理の結果、端末400の管理者にて、端末400が認可モジュール600とシングルサインオンすることが許可される。また、以上の第一、第二、第三、第四の設定を行うことで、その後に、端末利用者によるシングルサインオン処理を行うことが可能となる。
次に、図8、図9を用いて、シングルサインオン処理の詳細について説明する。図8は、第一、第二、第三、第四の設定がなされた端末400にて、端末利用者が不図示のクラウドサービスを利用するための認可トークンを取得するためのシーケンスである。より具体的には、端末400にログインしたことで、認可モジュール600に対してシングルサインオンし、OAuth2.0の認可確認画面が提示されるまでのシーケンスである。
S3.1にて、端末利用者は、端末400にてログイン操作を行う。このログイン操作は、端末400が備える認証モジュール830において定められている認証方法によって行われる。本実施形態の特徴として、この認証方法はシングルサインオンシステムと関係することなく選択することができる。認証方法としては、例えば、ユーザーID、パスワードの組み合わせを検証する方法、指紋等の生体情報を利用する方法、非接触型のICカードを利用する方法、更には、複数の認証方法を組み合わせる多要素認証方法等が考えられる。また、認証モジュール830が、不図示の認証サーバーと通信することで端末利用者を認証するよう構成することもできる。本実施形態では、ユーザーID、パスワードの組み合わせを検証する認証方法を用いた場合を例として説明する。ここで、本実施形態における認証モジュール830のユーザーテーブルは、表5を用いて上述した通りである。認証モジュール830のユーザーテーブルにおいて、ユーザーID、パスワードの組にてユーザー認証が行われる。また、UUIDは、端末400のユーザーを一意に識別するための情報(固有ID)である。このUUIDが、前述の第四の設定にて生成したIDマッピングテーブルの端末UUIDに記載した情報と対応している。
S3.1にて、端末利用者は、端末400にてログイン操作を行う。このログイン操作は、端末400が備える認証モジュール830において定められている認証方法によって行われる。本実施形態の特徴として、この認証方法はシングルサインオンシステムと関係することなく選択することができる。認証方法としては、例えば、ユーザーID、パスワードの組み合わせを検証する方法、指紋等の生体情報を利用する方法、非接触型のICカードを利用する方法、更には、複数の認証方法を組み合わせる多要素認証方法等が考えられる。また、認証モジュール830が、不図示の認証サーバーと通信することで端末利用者を認証するよう構成することもできる。本実施形態では、ユーザーID、パスワードの組み合わせを検証する認証方法を用いた場合を例として説明する。ここで、本実施形態における認証モジュール830のユーザーテーブルは、表5を用いて上述した通りである。認証モジュール830のユーザーテーブルにおいて、ユーザーID、パスワードの組にてユーザー認証が行われる。また、UUIDは、端末400のユーザーを一意に識別するための情報(固有ID)である。このUUIDが、前述の第四の設定にて生成したIDマッピングテーブルの端末UUIDに記載した情報と対応している。
S3.2にて、認証モジュール830は、ユーザーを認証する。例えば、ユーザーIDが「user」で、パスワードが「user」であった場合、認証モジュール830は、ユーザーID「user」のユーザーとして認証する。
S3.3にて、認証モジュール830は、認証したユーザーの認証情報を生成し保存する。この認証情報は、端末400の管理者が不図示のログアウト操作を実施するか、設定された時刻が経過するまで有効な状態で保存される。認証情報には、認証したユーザーのユーザーID、UUID及び権限情報が格納されている。なお、認証情報としては、各情報を直接格納するのではなく、ユーザーID、UUID及び権限情報が参照可能に紐付けられたトークンでもよい。端末利用者は、認証モジュール830での認証を受けた後に、S3.4、S3.5にて、Webブラウザー820を用いてアプリケーションモジュール800にアクセスする。なお、アプリケーションモジュール800へのアクセスを開始するきっかけとしては、アプリケーションモジュール800へアクセスするためのブックマークが保存され、そのブックマークを選択した場合が考えられる。また、アプリケーションモジュール800が明示的に開始される操作を受け付ける操作画面を備え、端末400の管理者が端末400にて当該操作をしたタイミングが考えられる。
S3.6にて、アプリケーションモジュール800は、Webブラウザー820に対して操作画面を応答する。操作画面の例については、図7(a)を用いて説明した通りである。S3.7にて、端末利用者は、Webブラウザー820に表示された操作画面2200にて、認可連携ボタン2202を押下する。S3.8にて、Webブラウザー820は、アプリケーションモジュール800に対して認可要求を行う。
S3.3にて、認証モジュール830は、認証したユーザーの認証情報を生成し保存する。この認証情報は、端末400の管理者が不図示のログアウト操作を実施するか、設定された時刻が経過するまで有効な状態で保存される。認証情報には、認証したユーザーのユーザーID、UUID及び権限情報が格納されている。なお、認証情報としては、各情報を直接格納するのではなく、ユーザーID、UUID及び権限情報が参照可能に紐付けられたトークンでもよい。端末利用者は、認証モジュール830での認証を受けた後に、S3.4、S3.5にて、Webブラウザー820を用いてアプリケーションモジュール800にアクセスする。なお、アプリケーションモジュール800へのアクセスを開始するきっかけとしては、アプリケーションモジュール800へアクセスするためのブックマークが保存され、そのブックマークを選択した場合が考えられる。また、アプリケーションモジュール800が明示的に開始される操作を受け付ける操作画面を備え、端末400の管理者が端末400にて当該操作をしたタイミングが考えられる。
S3.6にて、アプリケーションモジュール800は、Webブラウザー820に対して操作画面を応答する。操作画面の例については、図7(a)を用いて説明した通りである。S3.7にて、端末利用者は、Webブラウザー820に表示された操作画面2200にて、認可連携ボタン2202を押下する。S3.8にて、Webブラウザー820は、アプリケーションモジュール800に対して認可要求を行う。
S3.9、S3.10にて、アプリケーションモジュール800は、Webブラウザー820を介して認可モジュール600に対して認可要求を行う。この認可要求は、クライアントテーブルに登録されている認可URI「https://authz/C001/authz」に対して行われる。また、この認可URIのリクエストパラメーターとして、クライアントID「C001」、クライアント登録時に設定したリダイレクトURI「https://OP001/res」が含まれる。また、不図示のクラウドサービスを利用するための認可トークン取得であれば、そのサービスのリソース範囲を示すスコープを含むよう構成することもできる。
認可要求を受けた認可モジュール600は、ユーザーが認証済みかどうかを検証し、未認証である場合はRPテーブルから情報を取得する。その際、認可モジュール600は、認可要求に含まれるクライアントIDが認可クライアントIDに登録されているRP情報を取得する。ここで取得できなかった場合、認可モジュール600は、上述したS2.11と同様にログイン画面を応答する。本実施形態では、クライアントID「C001」を認可クライアントIDとして登録済みであるため、OPID「https://OP001」の情報が取得される。そして、認可モジュール600は、認可要求に含まれる認可URI「https://authz/C001/authz」及び付随するパラメーターを保存する。その際、認可モジュール600は、ランダムで重複しない値であるstateを生成し、紐付けて保存する。ここでは、stateとして「12345」を認可モジュール600が生成したとして説明する。表11に、認可モジュール600のSTATEテーブルの例を示す。
認可要求を受けた認可モジュール600は、ユーザーが認証済みかどうかを検証し、未認証である場合はRPテーブルから情報を取得する。その際、認可モジュール600は、認可要求に含まれるクライアントIDが認可クライアントIDに登録されているRP情報を取得する。ここで取得できなかった場合、認可モジュール600は、上述したS2.11と同様にログイン画面を応答する。本実施形態では、クライアントID「C001」を認可クライアントIDとして登録済みであるため、OPID「https://OP001」の情報が取得される。そして、認可モジュール600は、認可要求に含まれる認可URI「https://authz/C001/authz」及び付随するパラメーターを保存する。その際、認可モジュール600は、ランダムで重複しない値であるstateを生成し、紐付けて保存する。ここでは、stateとして「12345」を認可モジュール600が生成したとして説明する。表11に、認可モジュール600のSTATEテーブルの例を示す。
S3.11、S3.12にて、認可モジュール600は、Webブラウザー820を介して、アプリケーションモジュール800に認証要求を行う。この認証要求は、OPID「https://OP001」、即ちアプリケーションモジュール800のURLを宛先とする。この認証要求には、少なくとも、認可モジュール600のRPテーブルに登録されているクライアントID「RP001」、リダイレクトURI「https://authz/RP001/res」、先ほど生成したstate「12345」及びスコープとして「openid」が含まれる。
S3.13にて、アプリケーションモジュール800は、認証要求に含まれるパラメーターを検証する。より具体的には、アプリケーションモジュール800は、通知されたクライアントID、リダイレクトURIがアプリケーションモジュール800のOPテーブルに登録されている情報と一致するかを検証する。S3.14にて、アプリケーションモジュール800は、認証モジュール830に対して認証情報の取得を要求する。S3.15にて、認証モジュール830は、保存されている認証情報をアプリケーションモジュール800に応答する。本実施形態では、認証情報としてユーザーID「user」、UUID「AAAAAA2」が応答されるものとして説明する。
S3.13にて、アプリケーションモジュール800は、認証要求に含まれるパラメーターを検証する。より具体的には、アプリケーションモジュール800は、通知されたクライアントID、リダイレクトURIがアプリケーションモジュール800のOPテーブルに登録されている情報と一致するかを検証する。S3.14にて、アプリケーションモジュール800は、認証モジュール830に対して認証情報の取得を要求する。S3.15にて、認証モジュール830は、保存されている認証情報をアプリケーションモジュール800に応答する。本実施形態では、認証情報としてユーザーID「user」、UUID「AAAAAA2」が応答されるものとして説明する。
S3.16にて、アプリケーションモジュール800は、IDトークンを生成し保存する。IDトークンには、発行者情報iss、Subject識別子sub、この場合は認証モジュール830から取得したUUIDが含まれる。このとき、発行者情報issは、OPIDとなる。更には、OpenID ConnectのIDトークンとして定義された、IDトークンの対象を示すaud、この場合は認証要求に含まれるクライアントIDとなる。更に、IDトークンは、IDトークンの有効期限であるexp、IDトークンを発行した日時iatを含むことができる。また、IDトークンは、OpenID Connectの定義に従いJWT(JSON Web Token)形式の文字列として生成され、更に、JWS(JSON Web Signature)で定義された署名が付与される。署名には、アプリケーションモジュール800のOPテーブルに登録されている鍵ペアを用いる。更には、JWE(JSON Web Encryption)で定義された暗号化手段により暗号化が施されることもある。暗号化には、例えば、クライアントのシークレットを用いてもよい。また、署名と同じ鍵ペアを用いてもよい。更には、認可モジュール600から認証連携応答を受ける際に共通鍵を指定されるよう構成してもよい。表12に、アプリケーションモジュール800のIDトークンテーブルの例を示す。
S3.17、S3.18にて、アプリケーションモジュール800は、Webブラウザー820を介して認可モジュール600に認証応答を返す。認証応答には、少なくとも、生成したIDトークンと、認証要求に含まれるstateとが含まれる。なお、本実施形態では、生成されるトークンをIDトークンのみとして説明したが、アプリケーションモジュール800は、別途認可トークンを生成して応答してもよい。
S3.19にて、認可モジュール600は、IDトークンを検証する。より具体的には、認可モジュール600は、IDトークンが暗号化されている場合は、予め取り決められた方法にて復号する。次に、認可モジュール600は、IDトークンに含まれる発行元であるissが、認可モジュール600のRPテーブルに登録されているOPIDと一致するかを検証する。次に、認可モジュール600は、IDトークンに署名が付与されている場合は、認可モジュール600のRPテーブルに格納されている情報をIDトークンに含まれるissのOPIDとして特定し、その情報に含まれる公開鍵にて署名検証を行う。次に、認可モジュール600は、IDトークンに含まれるIDトークンの有効期限であるexpが現在の日時範囲内であるかを検証する。そして、認可モジュール600は、IDトークンの対象であるaudに、認可モジュール600のRPテーブルに登録されているクライアントIDが含まれているかを検証する。更に、認可モジュール600は、認証応答に含まれるstateがSTATEテーブルに保存されているか確認する。その他、OpenID Connectで定義されているオプションを用いて検証項目を増やすことも可能である。
S3.19にて、認可モジュール600は、IDトークンを検証する。より具体的には、認可モジュール600は、IDトークンが暗号化されている場合は、予め取り決められた方法にて復号する。次に、認可モジュール600は、IDトークンに含まれる発行元であるissが、認可モジュール600のRPテーブルに登録されているOPIDと一致するかを検証する。次に、認可モジュール600は、IDトークンに署名が付与されている場合は、認可モジュール600のRPテーブルに格納されている情報をIDトークンに含まれるissのOPIDとして特定し、その情報に含まれる公開鍵にて署名検証を行う。次に、認可モジュール600は、IDトークンに含まれるIDトークンの有効期限であるexpが現在の日時範囲内であるかを検証する。そして、認可モジュール600は、IDトークンの対象であるaudに、認可モジュール600のRPテーブルに登録されているクライアントIDが含まれているかを検証する。更に、認可モジュール600は、認証応答に含まれるstateがSTATEテーブルに保存されているか確認する。その他、OpenID Connectで定義されているオプションを用いて検証項目を増やすことも可能である。
S3.20にて、認可モジュール600は、IDマッピング情報を取得する。より具体的には、認可モジュール600は、IDトークンに含まれるissをOPIDとして、また、subを端末UUIDとして、認可モジュール600のIDマッピングテーブルからユーザーIDを取得する。本実施形態では、OPID「https://OP001」、端末UUID「AAAAAA1」であるため、ユーザーID「admin@xx.com」が取得される。S3.21にて、認可モジュール600は、取得したユーザーIDを用いて、認証トークンを生成する。そして、認可モジュール600は、生成した認証トークンを、取得したユーザーID、もしくはUUIDと紐付けて保存する。
S3.22にて、認可モジュール600は、認証連携応答として、Webブラウザー820に対して、生成した認証トークンをCookieに設定し、認可モジュール600のURIにリダイレクトするよう応答する。ここで、認可モジュール600のURIは、認可モジュール600のSTATEテーブルにて、state「12345」で特定されるURIとなる。結果として、S3.23にて、Webブラウザー820は、設定されたCookie情報を付与した状態で、認可モジュール600に対して認可要求することとなる。
S3.22にて、認可モジュール600は、認証連携応答として、Webブラウザー820に対して、生成した認証トークンをCookieに設定し、認可モジュール600のURIにリダイレクトするよう応答する。ここで、認可モジュール600のURIは、認可モジュール600のSTATEテーブルにて、state「12345」で特定されるURIとなる。結果として、S3.23にて、Webブラウザー820は、設定されたCookie情報を付与した状態で、認可モジュール600に対して認可要求することとなる。
認可モジュール600は、Cookieとして受信した認証トークンを用いて、ユーザーが認証済みかどうかを検証し、認証済みである場合は、認証トークンに紐付けられた情報をもってユーザーを特定する。そして、認可モジュール600は、受信した認可要求のうち、クライアントIDとリダイレクトURIとの組が正しいか検証する。より具体的には、認可モジュール600は、認可要求に含まれるクライアントID、リダイレクトURIの組が、認可モジュール600のクライアントテーブルに登録されているクライアントID、リダイレクトURIの組と一致するか検証する。不一致の場合、認可モジュール600は、不図示のエラー画面をWebブラウザー820に応答する。一致する場合、認可モジュール600は、S3.24にてWebブラウザー820に対して認可確認画面を応答する。認可確認画面の例については、図7(b)を用いて説明した通りである。
以下の認可フローについては、図6で説明したシーケンスと同様であるため、説明を省略する。以上の処理により、端末400の認証方法に関して制限を設けることなく、端末利用者が、端末400からクラウドサービスを利用する際に、端末400にて認証されていることをもってクラウドサービスに対してシングルサインオンを実現することが可能となる。
以下の認可フローについては、図6で説明したシーケンスと同様であるため、説明を省略する。以上の処理により、端末400の認証方法に関して制限を設けることなく、端末利用者が、端末400からクラウドサービスを利用する際に、端末400にて認証されていることをもってクラウドサービスに対してシングルサインオンを実現することが可能となる。
次に、図9、図10を用いて、本実施形態の特徴である、ある端末400にて既に第四の設定がなされている状態で、別の端末400にて第三の設定を実施した場合のシーケンスを説明する。なお、図9のシーケンス図では、図6で説明したS2.32の認可モジュール600におけるユーザー情報確認要求までのシーケンスは同様であるため説明を省略する。
ユーザー情報確認要求を受けた認可モジュール600は、S2.33にて、IDマッピングマスターテーブルの有無を確認する。この場合は、既にIDマッピングマスターテーブルに図6にて説明した情報が登録済みであるため、S4.1にて、認可モジュール600は、アプリケーションモジュール800に対してユーザー情報が登録済みであることを応答する。S4.2にて、アプリケーションモジュール800は、Webブラウザー820に対してユーザー情報同期確認画面を応答する。
ユーザー情報確認要求を受けた認可モジュール600は、S2.33にて、IDマッピングマスターテーブルの有無を確認する。この場合は、既にIDマッピングマスターテーブルに図6にて説明した情報が登録済みであるため、S4.1にて、認可モジュール600は、アプリケーションモジュール800に対してユーザー情報が登録済みであることを応答する。S4.2にて、アプリケーションモジュール800は、Webブラウザー820に対してユーザー情報同期確認画面を応答する。
図10は、アプリケーションモジュール800が応答するユーザー情報同期確認画面の例である。ユーザー情報同期確認画面2500は、認可モジュール600のIDマッピングマスターテーブルから取得されたユーザー情報を端末400に同期するか否かを確認する画面である。ユーザー情報同期確認画面2500は、同期する際のモードを選択するためのモード選択ボタン2501、同期を許可するボタン2502、拒否するボタン2503を備える。また、同期モードとしてマージモードが選択された際は、マージする際に同一ユーザーとみなすための属性(マージ条件)を選択するための属性選択ボタン2504を備える。なお、拒否するボタン2503が押下された場合は、処理が終了する。同期モードとしては上書きモードとマージモードとの2種から選択できる。上書きモードは、端末400のユーザー情報をクリアし、IDマッピングマスターテーブルから取得したユーザー情報のみが登録されるモードである。マージモードは、IDマッピングマスターテーブルから取得したユーザー情報と端末400に登録されているユーザー情報とを、属性選択ボタン2504にて選択された属性を用いてマージし、登録するモードである。ここでは、属性として、ユーザー名やメールアドレス等が選択可能であるものとしているが、他のユーザー属性を選択可能とすることもできる。なお、データの整合性を考慮すると、図4(b)のIDマッピング設定にて選択した属性と同じ属性を選択することが好ましい。
S4.3にて、端末400の管理者は、Webブラウザー820に表示されたユーザー情報同期確認画面にて、ユーザー情報の同期を許可するボタン2502を押下する。S4.4にて、Webブラウザー820は、アプリケーションモジュール800に対してユーザー同期要求を行う。このユーザー同期要求には選択された同期モードの情報が含まれる。S4.5にて、ユーザー同期要求を受けたアプリケーションモジュール800は、認可モジュール600に対してユーザー情報取得要求を行う。S4.6にて、ユーザー情報取得要求を受けた認可モジュール600は、IDマッピングマスターテーブルに保存されているユーザー情報を取得し、S4.7にてアプリケーションモジュール800に応答する。
S4.8にて、認可モジュール600のユーザー情報を取得したアプリケーションモジュール800は、認証モジュール830に対してユーザー情報取得要求を行う。S4.9にて、ユーザー情報取得要求を受けた認証モジュール830は、認証モジュール830のユーザーテーブルの情報を取得し、アプリケーションモジュール800にユーザー情報を応答する。S4.10にて、ユーザー情報の応答を受けたアプリケーションモジュール800は、設定された同期モードを確認する。ここで、選択された同期モード毎のシーケンスについてそれぞれ説明する。
S4.8にて、認可モジュール600のユーザー情報を取得したアプリケーションモジュール800は、認証モジュール830に対してユーザー情報取得要求を行う。S4.9にて、ユーザー情報取得要求を受けた認証モジュール830は、認証モジュール830のユーザーテーブルの情報を取得し、アプリケーションモジュール800にユーザー情報を応答する。S4.10にて、ユーザー情報の応答を受けたアプリケーションモジュール800は、設定された同期モードを確認する。ここで、選択された同期モード毎のシーケンスについてそれぞれ説明する。
同期モードとして上書きモードが選択された場合、S4.11にて、アプリケーションモジュール800は、認証モジュール830から取得したユーザー情報が存在した場合は、認証モジュール830に対して全ユーザー情報の削除を行う。その後、端末400の管理者は、アプリケーションモジュール800の操作画面を介して、アプリケーションモジュール800が認可モジュール600から取得したユーザー情報の登録を実施する。なお、認証モジュール830から取得したユーザー情報が存在しなかった場合、アプリケーションモジュール800は、全ユーザー情報の削除をスキップし、認可モジュール600から取得したユーザー情報の登録を実施する。
次に、同期モードとしてマージモードが選択された場合、アプリケーションモジュール800は、認可モジュール600から取得したユーザー情報と、認証モジュール830から取得したユーザー情報との比較を行う。より具体的には、アプリケーションモジュール800は、マージ属性として選択された属性を比較し、一致するユーザーを同一ユーザーとして扱う。次に、S4.11にて、アプリケーションモジュール800は、属性比較にて属性が一致しなかったユーザー情報のうち、認可モジュール600にのみ存在するユーザーの登録を認証モジュール830に対して要求する。以上が、選択された同期モード毎の説明である。なお、ここでは上述のマージモードに係るマージ処理が端末400で実行されるものとして説明したが、マージ処理は認可サーバー200で実行されるように構成されてもよい。より具体的には、認可モジュール600が、アプリケーションモジュール800から受け付けたマージ属性に従って、認可モジュール600のユーザー情報と、アプリケーションモジュール800から新たに受け付けたユーザー情報とをマージする。そして、認可モジュール600は、マージしたユーザー情報をアプリケーションモジュール800に送信する。
次に、同期モードとしてマージモードが選択された場合、アプリケーションモジュール800は、認可モジュール600から取得したユーザー情報と、認証モジュール830から取得したユーザー情報との比較を行う。より具体的には、アプリケーションモジュール800は、マージ属性として選択された属性を比較し、一致するユーザーを同一ユーザーとして扱う。次に、S4.11にて、アプリケーションモジュール800は、属性比較にて属性が一致しなかったユーザー情報のうち、認可モジュール600にのみ存在するユーザーの登録を認証モジュール830に対して要求する。以上が、選択された同期モード毎の説明である。なお、ここでは上述のマージモードに係るマージ処理が端末400で実行されるものとして説明したが、マージ処理は認可サーバー200で実行されるように構成されてもよい。より具体的には、認可モジュール600が、アプリケーションモジュール800から受け付けたマージ属性に従って、認可モジュール600のユーザー情報と、アプリケーションモジュール800から新たに受け付けたユーザー情報とをマージする。そして、認可モジュール600は、マージしたユーザー情報をアプリケーションモジュール800に送信する。
S4.13にて、アプリケーションモジュール800は、認証モジュール830に対してユーザー情報取得要求を行う。S4.14にて、ユーザー情報取得要求を受けた認証モジュール830は、認証モジュール830のユーザーテーブルの情報を取得し、アプリケーションモジュール800にユーザー情報を応答する。S4.15にて、ユーザー情報の応答を受けたアプリケーションモジュール800は、認可モジュール600に対してユーザー情報登録要求を行う。ユーザー情報登録要求には、自身のOPID及び認証モジュール830から取得したユーザー情報が含まれる。
S4.16にて、ユーザー情報登録要求を受けた認可モジュール600は、取得した情報のうち、IDマッピングマスターテーブルに登録されていないユーザー情報のみ登録を行う。ここで、登録されているか否かの判定は、第一の設定のシングルサインオン設定画面2100にて設定されたIDマッピング設定に従って行われる。本実施形態では、IDマッピング設定としてメールアドレスによる自動マッピングが設定されているため、メールアドレスが未登録のユーザーのみ追加登録が行われる。
S4.16にて、ユーザー情報登録要求を受けた認可モジュール600は、取得した情報のうち、IDマッピングマスターテーブルに登録されていないユーザー情報のみ登録を行う。ここで、登録されているか否かの判定は、第一の設定のシングルサインオン設定画面2100にて設定されたIDマッピング設定に従って行われる。本実施形態では、IDマッピング設定としてメールアドレスによる自動マッピングが設定されているため、メールアドレスが未登録のユーザーのみ追加登録が行われる。
S4.17にて、認可モジュール600は、取得したOPID、ユーザー情報、IDマッピングマスターテーブル及び認可モジュール600のユーザーテーブルの情報を基に、IDマッピング情報を生成する。より具体的には、IDマッピングマスターテーブルから、マッピングキーで指定された属性に関する情報(属性情報)を取得し、この属性の値がユーザーテーブルに登録されているユーザーとのIDマッピング情報を生成する。表10Bに、端末400のOPIDが「https://OP002」であり、同期モードとして上書きモードが設定された場合における認可モジュール600のIDマッピングテーブルの例を示す。
このとき、OPIDが「https://OP002」から登録されたユーザーの端末UUIDと、既に登録されていたOPIDが「https://OP001」から登録されたユーザーの端末UUIDとは異なるとしているが、端末400の動作仕様によっては、同一のUUIDとして上書き登録され、同一のUUIDとなることもある。しかしながら、UUIDを同一にすることは名寄せに利用される可能性があるため、UUIDはユニークなIDであることが好ましい。なお、以降の処理は図6におけるS2.43以降のシーケンスと同様のため説明を省略する。
以上の処理を行うことで、複数の端末400にて管理者が第三の設定であるOP登録を実施することに伴って、各ユーザーのIDマッピングが自動生成される。結果として、各ユーザーにおける、複数の端末400と認可モジュール600との間でのシングルサインオンを実現するためのIDマッピング情報の生成における負荷をなくすことができる。更に、管理者はOP登録という操作のみでIDマッピング情報が生成されるため、別途IDマッピング情報を生成するという作業を実施する必要がない。
以上の処理を行うことで、複数の端末400にて管理者が第三の設定であるOP登録を実施することに伴って、各ユーザーのIDマッピングが自動生成される。結果として、各ユーザーにおける、複数の端末400と認可モジュール600との間でのシングルサインオンを実現するためのIDマッピング情報の生成における負荷をなくすことができる。更に、管理者はOP登録という操作のみでIDマッピング情報が生成されるため、別途IDマッピング情報を生成するという作業を実施する必要がない。
次に、既に第三の設定であるOP登録されている端末400にて、端末400の管理者が認証モジュール830のユーザー情報を追加した場合の処理を説明する。本処理については、図6及び図9を用いて説明した処理との差分のみ説明する。
端末400の管理者は、図6における、S2.1、S2.3までの端末400での認証処理の後に、Webブラウザー820を介し、アプリケーションモジュール800の操作画面にアクセスする。そして、端末400の管理者は、ユーザー情報の管理を選択する。ユーザー情報の管理が選択されると、アプリケーションモジュール800は、認証モジュール830からユーザー情報を取得し、Webブラウザー820に不図示のユーザー情報の管理画面を応答する。端末400の管理者は、ユーザー情報の管理画面にてユーザーを追加する。Webブラウザー820を介してユーザーの追加要求を受けたアプリケーションモジュール800は、認証モジュール830に対してユーザー情報を追加する。以降、図9のS4.13以降のシーケンスと同様の処理を実施することによって、認可モジュール600にてIDマッピングマスターテーブルが更新される。
なお、端末400の管理者がアプリケーションモジュール800の操作画面を介して、ユーザー情報を追加するよう説明したが、その他の方法として、アプリケーションモジュール800が、認証モジュール830のユーザー情報の更新を監視する構成も考えられる。また、アプリケーションモジュール800が、認証モジュール830から通知を受けるよう構成することも考えられる。そして、そのような構成において、アプリケーションモジュール800が、得られた情報を基にS4.13以降の処理を実行するよう構成することもできる。
端末400の管理者は、図6における、S2.1、S2.3までの端末400での認証処理の後に、Webブラウザー820を介し、アプリケーションモジュール800の操作画面にアクセスする。そして、端末400の管理者は、ユーザー情報の管理を選択する。ユーザー情報の管理が選択されると、アプリケーションモジュール800は、認証モジュール830からユーザー情報を取得し、Webブラウザー820に不図示のユーザー情報の管理画面を応答する。端末400の管理者は、ユーザー情報の管理画面にてユーザーを追加する。Webブラウザー820を介してユーザーの追加要求を受けたアプリケーションモジュール800は、認証モジュール830に対してユーザー情報を追加する。以降、図9のS4.13以降のシーケンスと同様の処理を実施することによって、認可モジュール600にてIDマッピングマスターテーブルが更新される。
なお、端末400の管理者がアプリケーションモジュール800の操作画面を介して、ユーザー情報を追加するよう説明したが、その他の方法として、アプリケーションモジュール800が、認証モジュール830のユーザー情報の更新を監視する構成も考えられる。また、アプリケーションモジュール800が、認証モジュール830から通知を受けるよう構成することも考えられる。そして、そのような構成において、アプリケーションモジュール800が、得られた情報を基にS4.13以降の処理を実行するよう構成することもできる。
次に、既に第三の設定であるOP登録されている複数の端末400があり、一方の端末400にて認証モジュール830に登録されているが、他方の端末400では登録されていないユーザーが、登録されていない端末400を利用する場合の処理を説明する。
ユーザーは、認証モジュール830に対してログイン操作を実施する。ログイン操作を受けた認証モジュール830は、ログイン操作から得られたユーザーIDのユーザーがユーザーテーブルに登録されていない場合に、アプリケーションモジュール800に対して、ユーザー情報の同期処理を要求する。以降は、図9のS4.5以降の処理を行うことによって、ユーザー情報が同期され、ユーザーテーブルに登録される。ユーザー情報の同期処理の完了後、再度、認証処理を実行する。ここで、他の端末400にてユーザーが登録済みであれば、ユーザーは認証を受けることが可能となる。
次に、既に第三の設定であるOP登録されている複数の端末400があり、認可モジュール600のIDマッピングマスターテーブルが更新されたことを検知可能に構成されているアプリケーションモジュール800での処理を説明する。
アプリケーションモジュール800は、定期的な確認か、もしくはWebSokcetと呼ばれる技術によって、認可モジュール600におけるIDマッピングマスターテーブルの更新を検知する。IDマッピングマスターテーブルの更新を検知したアプリケーションモジュール800が、図9で説明したS4.5以降の処理を実行することで、ユーザー情報の定期的な同期が行われる。
ユーザーは、認証モジュール830に対してログイン操作を実施する。ログイン操作を受けた認証モジュール830は、ログイン操作から得られたユーザーIDのユーザーがユーザーテーブルに登録されていない場合に、アプリケーションモジュール800に対して、ユーザー情報の同期処理を要求する。以降は、図9のS4.5以降の処理を行うことによって、ユーザー情報が同期され、ユーザーテーブルに登録される。ユーザー情報の同期処理の完了後、再度、認証処理を実行する。ここで、他の端末400にてユーザーが登録済みであれば、ユーザーは認証を受けることが可能となる。
次に、既に第三の設定であるOP登録されている複数の端末400があり、認可モジュール600のIDマッピングマスターテーブルが更新されたことを検知可能に構成されているアプリケーションモジュール800での処理を説明する。
アプリケーションモジュール800は、定期的な確認か、もしくはWebSokcetと呼ばれる技術によって、認可モジュール600におけるIDマッピングマスターテーブルの更新を検知する。IDマッピングマスターテーブルの更新を検知したアプリケーションモジュール800が、図9で説明したS4.5以降の処理を実行することで、ユーザー情報の定期的な同期が行われる。
以上の処理により、第三の設定であるOP登録後のユーザー情報を追加した場合においても、ユーザーの処理負荷を増やすことなく、自動的にIDマッピング情報を生成することができる。更に、管理者においても端末400のユーザー情報の管理をすることで自動的にIDマッピング情報が生成されるため、別途IDマッピング情報のメンテナンスを実施する必要がない。
<その他の実施形態>
本発明は、上述の実施形態の1以上の機能を実現するプログラムを、ネットワーク又は記憶媒体を介してシステム又は装置に供給し、そのシステム又は装置のコンピュータにおける1つ以上のプロセッサーがプログラムを読出し実行する処理でも実現可能である。また、1以上の機能を実現する回路(例えば、ASIC)によっても実現可能である。
本発明は、上述の実施形態の1以上の機能を実現するプログラムを、ネットワーク又は記憶媒体を介してシステム又は装置に供給し、そのシステム又は装置のコンピュータにおける1つ以上のプロセッサーがプログラムを読出し実行する処理でも実現可能である。また、1以上の機能を実現する回路(例えば、ASIC)によっても実現可能である。
以上、上述した各実施形態によれば、複数の端末400にて管理者がシングルサインオンの設定を行うことに伴って各ユーザーのIDマッピング情報が自動生成される。これにより、各ユーザーの作業負荷を増やすことなく、かつ、管理者によるIDマッピング情報の生成の負荷を軽減することができる
以上、本発明の好ましい形態について詳述したが、本実施形態は係る特定の実施形態に限定されるものではなく、特許請求の範囲に記載された本発明の要旨の範囲内において、種々の変形・変更が可能である。
200 認可サーバー、400A、400B 端末、500 データベースサーバー、600 認可モジュール、610 HTTPサーバーモジュール、800 アプリケーションモジュール、810 認証モジュール、820 Webブラウザー
Claims (16)
- 端末装置とネットワークを介して通信可能なサーバー装置であって、
前記端末装置のユーザーの固有IDを含むユーザー情報を前記端末装置から受信する受信手段と、
前記受信手段により受信されたユーザー情報のうち前記端末装置により指定された属性情報を含むユーザー情報に含まれる固有IDと、前記サーバー装置において認証されるユーザー情報のうち前記属性情報を含むユーザー情報に含まれるユーザーの固有IDとを紐付けて、前記端末装置と前記サーバー装置との認証連携に係るIDマッピング情報を生成する生成手段と、
を有するサーバー装置。 - 前記受信手段により受信されたユーザー情報と、前記端末装置により前記ユーザー情報に対して指定された属性情報とを紐付けて登録する登録手段を更に有し、
前記生成手段は、前記登録されたユーザー情報に含まれるユーザーの固有IDと、前記サーバー装置において認証されるユーザー情報のうち前記登録されたユーザー情報と紐付けて登録されている属性情報を含むユーザー情報に含まれるユーザーの固有IDとを紐付けて、前記IDマッピング情報を生成する請求項1に記載のサーバー装置。 - 前記端末装置からユーザー情報が登録済みであるか否かの確認要求を受け付けて未登録であることが確認された場合に、前記端末装置に対してユーザー情報の取得を要求する要求手段を更に有し、
前記受信手段は、前記要求手段による要求に対する応答として、前記端末装置のユーザーの固有IDを含むユーザー情報を前記端末装置から受信する請求項1又は2に記載のサーバー装置。 - 他の端末装置から新たにユーザー情報が受信された場合に、前記他の端末装置により指定されたマージ条件に従って、前記サーバー装置に登録されているユーザー情報と、前記他の端末装置から新たに受信されたユーザー情報とをマージするマージ手段と、
前記マージ手段によりマージされたユーザー情報を前記他の端末装置に送信する送信手段と、を更に有する請求項1乃至3の何れか1項に記載のサーバー装置。 - サーバー装置とネットワークを介して通信可能な端末装置であって、
前記サーバー装置において認証されるユーザーの固有IDを含むユーザー情報が登録済みであるか否かの確認を前記サーバー装置に要求する要求手段と、
前記要求手段による要求の応答として未登録であることが確認された場合に、前記端末装置に登録されている前記端末装置のユーザーの固有IDを含むユーザー情報を前記サーバー装置に送信する第1の送信手段と、
前記要求手段による要求の応答として登録済みであることが確認された場合に、前記サーバー装置から登録済みのユーザー情報を取得して前記端末装置に登録されているユーザー情報と同期させる同期手段と、
前記同期手段により同期されたユーザー情報を前記サーバー装置に送信する第2の送信手段と、
を有する端末装置。 - 前記同期手段は、前記端末装置に登録されているユーザー情報を削除し、前記サーバー装置から取得した登録済みのユーザー情報を前記端末装置に登録する請求項5に記載の端末装置。
- 前記同期手段は、設定されたマージ条件に従って、前記端末装置に登録されているユーザー情報に前記サーバー装置から取得した登録済みのユーザー情報をマージする請求項5に記載の端末装置。
- 前記同期手段によるユーザー情報の同期に係る同期モードの設定を受け付けるとともに、ユーザー情報をマージさせることにより同期させる同期モードについてはマージ条件の設定を受け付ける設定画面を表示する表示手段を更に有する請求項5乃至7の何れか1項に記載の端末装置。
- 前記サーバー装置が前記端末装置から受信したユーザー情報に基づいて前記サーバー装置と前記端末装置との認証連携に係るIDマッピング情報を生成する際のマッピング条件の設定を受け付ける設定画面を表示する表示手段を更に有する請求項5乃至8の何れか1項に記載の端末装置。
- 前記サーバー装置に登録されているユーザー情報の更新を検知する検知手段を更に有し、
前記要求手段は、前記検知手段により前記更新が検知された場合に前記確認を前記サーバー装置に要求する請求項5乃至9の何れか1項に記載の端末装置。 - ネットワークを介して通信可能な端末装置と、サーバー装置とを含むシステムであって、
前記端末装置は、
前記端末装置のユーザーの固有IDを含むユーザー情報を前記サーバー装置に送信する送信手段を有し、
前記サーバー装置は、
前記送信手段により送信されたユーザー情報を前記端末装置から受信する受信手段と、
前記受信手段により受信されたユーザー情報のうち前記端末装置により指定された属性情報を含むユーザー情報に含まれる固有IDと、前記サーバー装置において認証されるユーザー情報のうち前記属性情報を含むユーザー情報に含まれるユーザーの固有IDとを紐付けて、前記端末装置と前記サーバー装置との認証連携に係るIDマッピング情報を生成する生成手段と、
を有するシステム。 - 端末装置とネットワークを介して通信可能なサーバー装置が実行する情報処理方法であって、
前記端末装置のユーザーの固有IDを含むユーザー情報を前記端末装置から受信する受信ステップと、
前記受信ステップにより受信されたユーザー情報のうち前記端末装置により指定された属性情報を含むユーザー情報に含まれる固有IDと、前記サーバー装置において認証されるユーザー情報のうち前記属性情報を含むユーザー情報に含まれるユーザーの固有IDとを紐付けて、前記端末装置と前記サーバー装置との認証連携に係るIDマッピング情報を生成する生成ステップと、
を含む情報処理方法。 - サーバー装置とネットワークを介して通信可能な端末装置が実行する情報処理方法であって、
前記サーバー装置において認証されるユーザーの固有IDを含むユーザー情報が登録済みであるか否かの確認を前記サーバー装置に要求する要求ステップと、
前記要求ステップによる要求の応答として未登録であることが確認された場合に、前記端末装置に登録されている前記端末装置のユーザーの固有IDを含むユーザー情報を前記サーバー装置に送信する第1の送信ステップと、
前記要求ステップによる要求の応答として登録済みであることが確認された場合に、前記サーバー装置から登録済みのユーザー情報を取得して前記端末装置に登録されているユーザー情報と同期させる同期ステップと、
前記同期ステップにより同期されたユーザー情報を前記サーバー装置に送信する第2の送信ステップと、
を含む情報処理方法。 - ネットワークを介して通信可能な端末装置と、サーバー装置とを含むシステムにおける情報処理方法であって、
前記端末装置が、前記端末装置のユーザーの固有IDを含むユーザー情報を前記サーバー装置に送信する送信ステップと、
前記サーバー装置が、前記送信ステップにより送信されたユーザー情報を前記端末装置から受信する受信ステップと、
前記サーバー装置が、前記受信ステップにより受信されたユーザー情報のうち前記端末装置により指定された属性情報を含むユーザー情報に含まれる固有IDと、前記サーバー装置において認証されるユーザー情報のうち前記属性情報を含むユーザー情報に含まれるユーザーの固有IDとを紐付けて、前記端末装置と前記サーバー装置との認証連携に係るIDマッピング情報を生成する生成ステップと、
を含む情報処理方法。 - 端末装置とネットワークを介して通信可能なコンピュータに、
前記端末装置のユーザーの固有IDを含むユーザー情報を前記端末装置から受信する受信ステップと、
前記受信ステップにより受信されたユーザー情報のうち前記端末装置により指定された属性情報を含むユーザー情報に含まれる固有IDと、前記コンピュータにおいて認証されるユーザー情報のうち前記属性情報を含むユーザー情報に含まれるユーザーの固有IDとを紐付けて、前記端末装置と前記コンピュータとの認証連携に係るIDマッピング情報を生成する生成ステップと、
を実行させるためのプログラム - サーバー装置とネットワークを介して通信可能なコンピュータに、
前記サーバー装置において認証されるユーザーの固有IDを含むユーザー情報が登録済みであるか否かの確認を前記サーバー装置に要求する要求ステップと、
前記要求ステップによる要求の応答として未登録であることが確認された場合に、前記コンピュータに登録されている前記コンピュータのユーザーの固有IDを含むユーザー情報を前記サーバー装置に送信する第1の送信ステップと、
前記要求ステップによる要求の応答として登録済みであることが確認された場合に、前記サーバー装置から登録済みのユーザー情報を取得して前記コンピュータに登録されているユーザー情報と同期させる同期ステップと、
前記同期ステップにより同期されたユーザー情報を前記サーバー装置に送信する第2の送信ステップと、
を実行させるためのプログラム。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2014218654A JP2016085638A (ja) | 2014-10-27 | 2014-10-27 | サーバー装置、端末装置、システム、情報処理方法及びプログラム |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2014218654A JP2016085638A (ja) | 2014-10-27 | 2014-10-27 | サーバー装置、端末装置、システム、情報処理方法及びプログラム |
Publications (1)
Publication Number | Publication Date |
---|---|
JP2016085638A true JP2016085638A (ja) | 2016-05-19 |
Family
ID=55972145
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2014218654A Pending JP2016085638A (ja) | 2014-10-27 | 2014-10-27 | サーバー装置、端末装置、システム、情報処理方法及びプログラム |
Country Status (1)
Country | Link |
---|---|
JP (1) | JP2016085638A (ja) |
Cited By (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
KR20190024821A (ko) * | 2017-08-31 | 2019-03-08 | 캐논 가부시끼가이샤 | 권한 위양 시스템, 그 제어 방법 및 저장 매체 |
US10708254B2 (en) | 2017-02-27 | 2020-07-07 | Fuji Xerox Co., Ltd. | Information processing apparatus and non-transitory computer readable medium storing information processing program for single sign-on |
JPWO2021171381A1 (ja) * | 2020-02-25 | 2021-09-02 |
-
2014
- 2014-10-27 JP JP2014218654A patent/JP2016085638A/ja active Pending
Cited By (7)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US10708254B2 (en) | 2017-02-27 | 2020-07-07 | Fuji Xerox Co., Ltd. | Information processing apparatus and non-transitory computer readable medium storing information processing program for single sign-on |
KR20190024821A (ko) * | 2017-08-31 | 2019-03-08 | 캐논 가부시끼가이샤 | 권한 위양 시스템, 그 제어 방법 및 저장 매체 |
JP2019046060A (ja) * | 2017-08-31 | 2019-03-22 | キヤノン株式会社 | 権限委譲システム、制御方法、およびプログラム |
US11088847B2 (en) * | 2017-08-31 | 2021-08-10 | Canon Kabushiki Kaisha | Authority transfer system, control method therefor, and storage medium |
KR102362456B1 (ko) * | 2017-08-31 | 2022-02-14 | 캐논 가부시끼가이샤 | 권한 위양 시스템, 그 제어 방법 및 저장 매체 |
JPWO2021171381A1 (ja) * | 2020-02-25 | 2021-09-02 | ||
JP7352847B2 (ja) | 2020-02-25 | 2023-09-29 | 日本電気株式会社 | 情報処理装置、情報処理方法及び記憶媒体 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US10771459B2 (en) | Terminal apparatus, server apparatus, blockchain and method for FIDO universal authentication using the same | |
US9571494B2 (en) | Authorization server and client apparatus, server cooperative system, and token management method | |
CN110138718B (zh) | 信息处理系统及其控制方法 | |
JP6727799B2 (ja) | 権限委譲システム、情報処理装置、認可サーバ、制御方法およびプログラム | |
US9021570B2 (en) | System, control method therefor, service providing apparatus, relay apparatus and computer-readable medium | |
JP6376869B2 (ja) | データ同期システム、その制御方法、認可サーバー、およびそのプログラム | |
JP6675163B2 (ja) | 権限委譲システム、認可サーバの制御方法、認可サーバおよびプログラム | |
JP6061633B2 (ja) | デバイス装置、制御方法、およびそのプログラム。 | |
JP2016009299A (ja) | シングルサインオンシステム、端末装置、制御方法およびコンピュータプログラム | |
JP2019046060A (ja) | 権限委譲システム、制御方法、およびプログラム | |
JP2019046059A (ja) | 権限委譲システム、制御方法、およびプログラム | |
US9185102B2 (en) | Server system and control method | |
US20180341759A1 (en) | Image processing apparatus, system related to image processing apparatus, and method | |
US11483159B2 (en) | Terminal registration system and terminal registration method | |
JPWO2011089712A1 (ja) | 認証方法、認証システムおよび認証プログラム | |
JP2011215753A (ja) | 認証システムおよび認証方法 | |
JP2018092446A (ja) | 認証認可システム及び情報処理装置と認証認可方法とプログラム | |
JP7196241B2 (ja) | 情報処理装置、制御方法、およびプログラム | |
JP2016115260A (ja) | 権限移譲システム、権限移譲システムに用いられる認可サーバー、リソースサーバー、クライアント、媒介装置、権限移譲方法およびプログラム | |
JP6719875B2 (ja) | 認証サーバ、認証方法およびプログラム | |
US20130318590A1 (en) | Information processing system, control method thereof, and storage medium thereof | |
JP2016085638A (ja) | サーバー装置、端末装置、システム、情報処理方法及びプログラム | |
JP2017120502A (ja) | クラウドサービスへのIoT機器の登録方法 | |
JP2012033042A (ja) | シングルサインオンシステム及びシングルサインオン方法 | |
JP6128958B2 (ja) | 情報処理サーバーシステム、制御方法、およびプログラム |