JP2012181662A - アカウント情報連携システム - Google Patents
アカウント情報連携システム Download PDFInfo
- Publication number
- JP2012181662A JP2012181662A JP2011043920A JP2011043920A JP2012181662A JP 2012181662 A JP2012181662 A JP 2012181662A JP 2011043920 A JP2011043920 A JP 2011043920A JP 2011043920 A JP2011043920 A JP 2011043920A JP 2012181662 A JP2012181662 A JP 2012181662A
- Authority
- JP
- Japan
- Prior art keywords
- account information
- authentication
- user
- organization
- 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.)
- Pending
Links
Abstract
【課題】組織内で通常使用するアカウント情報をそのまま使用して外部のサービスに対してユーザ認証を行った上で利用することができるアカウント情報連携システムを提供する。
【解決手段】社内Webサーバ14と、ディレクトリサーバ17と、Webブラウザ13、および外部アプリケーションサーバ30とからなり、社内Webサーバ14は、外部サービスを利用する際のユーザ認証のためのインタフェースを提供し、ディレクトリサーバ17によってユーザ認証を行う認証部15と、ユーザ12のアカウント情報に基づいて認証チケットを発行し、Webブラウザ13に応答する認証チケット発行部16とを有し、Webブラウザ13は認証チケットを外部アプリケーションサーバ30に転送し、外部アプリケーションサーバ30は、認証チケットからユーザ12のアカウント情報を取得して認証部32を介してユーザ認証を行う連携認証部31を有する。
【選択図】図1
【解決手段】社内Webサーバ14と、ディレクトリサーバ17と、Webブラウザ13、および外部アプリケーションサーバ30とからなり、社内Webサーバ14は、外部サービスを利用する際のユーザ認証のためのインタフェースを提供し、ディレクトリサーバ17によってユーザ認証を行う認証部15と、ユーザ12のアカウント情報に基づいて認証チケットを発行し、Webブラウザ13に応答する認証チケット発行部16とを有し、Webブラウザ13は認証チケットを外部アプリケーションサーバ30に転送し、外部アプリケーションサーバ30は、認証チケットからユーザ12のアカウント情報を取得して認証部32を介してユーザ認証を行う連携認証部31を有する。
【選択図】図1
Description
本発明は、ユーザのアカウント情報を他サービスに連携させる技術に関し、特に、企業内で通常使用されるアカウント情報を外部のサービスに連携させるアカウント情報連携システムに適用して有効な技術に関するものである。
近年、企業で利用される社内システム等においては、ユーザ(社員等)のIDやパスワード等、および氏名や所属部署その他の属性情報などを含むアカウント情報を一元的に管理するとともに、IDとパスワードによるユーザ認証の手段を提供し、これを複数の社内システムから共通で利用可能とするような仕組みが実装される場合が増えている。このようなユーザ管理の仕組みの実装に際しては、例えば、LDAP(Lightweight Directory Access Protocol)を実装したソフトウェアを用いたディレクトリサーバなどが利用される。
また、ユーザが一回のユーザ認証処理を行うことで、ユーザ認証が必要な複数の社内システムを利用できるようにするシングルサインオンの仕組みが実装される場合もある。例えば、各社内システムのサーバにおいてSAML(Security Assertion Markup Language)プロトコルを用いてサーバ間で通信を行って認証情報を自動的に引き継ぐことで、複数の社内システム間でシングルサインオンを実現することができる。
しかしながら、イントラネット内での社内システムの利用のみで業務を完結できない場合もあり、例えば、外部のベンダー等によってASP(Application Service Provider)として提供されるサービスをインターネットを介して業務上利用することになる場合も多い。このとき通常は、当該外部のサービスに対して別途ユーザ登録等を行って、これに対して個別にログイン等の認証処理を行った上でサービスを利用する。
このような環境では、社内システムと外部のシステムとの間でシングルサインオンを実現することは困難である。通常、上述したようなシングルサインオンの仕組みでは、サーバ間で認証情報の引き継ぎが行われるところ、これを可能とするためにはサーバ間で認証情報の引き継ぎ・受け入れを許容する信頼関係の成立が必要とされる。しかし、社内システムと外部のシステムとの間では、セキュリティ上の関係等からこのような信頼関係が成立しない場合も多いからである。
これに対して、例えば、特開2010−86435号公報(特許文献1)には、以下のようなネットワークシステムの例が記載されている。すなわち、当該ネットワークシステムは、複数のWebサーバと中継サーバおよび複数のユーザ端末から構成され、第一のWebサーバは、端末からの認証情報と記憶部の認証情報とを照合して認証を行い、認証が成立した場合に、認証情報に含まれる第一のユーザID、第一のWebサーバへの第一のURL、第二Webサーバへの第二のURLおよび認証強度に関連する情報を含むメッセージを生成して中継サーバに送信する。
中継サーバは、同一ユーザ情報を登録するテーブルから第一のユーザIDに対応する第二のユーザIDを取得して、メッセージ中の第一のユーザIDを第二のユーザIDに書き換えて第二のWebサーバに送信する。第二のWebサーバは、メッセージを受信すると、メッセージから第二のユーザIDを取得し、第二のユーザIDが記憶部に記憶されている場合に、受信した認証強度に関連する情報と記憶部の認証強度に関連する情報に基づいてユーザの再認証を行う。これにより、互いに信頼関係や連携関係にない複数のシステムから構成されるネットワークシステムにおいて、一回の認証情報の入力により、認証が必要な複数のアプリケーションを利用可能とする。
特許文献1のような仕組みを用いれば、例えば、社内システムと外部のASPサービスとの間のような信頼関係が成立していないシステム間で、シングルサインオンの環境を構築することが可能である。
しかしながら、ユーザ(社員等)は、社内システムでのユーザ管理とは別に、外部のサービスにおいても個別にアカウント情報の登録や変更等の管理を行わなければならないのが通常である。また、例えば特許文献1での中継サーバなどのように、社内で通常使用するユーザIDと外部のサービスにおけるユーザIDとの対応情報の管理も行う必要がある。
また従来技術では、例えば社内システムでユーザ認証を経た上でいずれかのアプリケーションを実行した後、その認証情報を引き継いで外部のサービスを利用するという、一般的なシングルサインオンの形態ではなく、ユーザが社内で通常使用するユーザID、パスワード等のアカウント情報をそのまま使用して、外部のサービスに対してユーザ認証を行った上で利用するという形態(アカウント情報の共用)のシステムを構築することは考慮されていない。
そこで本発明の目的は、企業等の組織内で通常使用するアカウント情報をそのまま使用して、組織内のサーバ等からの直接の通信がセキュリティ上制限されている外部のサービスに対してユーザ認証を行った上で利用することができるアカウント情報連携システムを提供することにある。また、外部のサービスに対して個別のアカウント情報の管理を行うことなく利用することができるアカウント情報連携システムを提供することにある。
本発明の前記ならびにその他の目的と新規な特徴は、本明細書の記述および添付図面から明らかになるであろう。
本願において開示される発明のうち、代表的なものの概要を簡単に説明すれば、以下のとおりである。
本発明の代表的な実施の形態によるアカウント情報連携システムは、組織の内部の第1のネットワークに接続され、前記組織内のユーザに対してユーザ認証のためのインタフェースを提供する第1のサーバと、前記組織内のユーザのアカウント情報を管理する第2のサーバと、前記第1のネットワークおよび前記組織の外部の第2のネットワークに接続可能なクライアント端末、および前記第2のネットワークに接続されたアプリケーションサーバとからなり、前記ユーザが、前記アプリケーションサーバによって提供される外部サービスに対して、前記組織内でのアカウント情報を使用してユーザ認証を行った上で利用することを可能とするアカウント情報連携システムであって、以下の特徴を有するものである。
すなわち、前記第1のサーバは、前記組織内のユーザに対して前記外部サービスを利用する際のユーザ認証のためのインタフェースを提供し、前記ユーザによって前記クライアント端末から入力されたアカウント情報を利用して前記第2のサーバによってユーザ認証を行う第1の認証部と、前記第1の認証部が前記第2のサーバから取得した前記ユーザの前記組織内でのアカウント情報に基づいて認証チケットを発行し、発行した前記認証チケットを前記第1の認証部を介して前記クライアント端末に応答する認証チケット発行部とを有する。
また、前記クライアント端末は、前記第1のサーバから応答された前記認証チケットを前記アプリケーションサーバに転送し、前記アプリケーションサーバは、前記外部サービスを利用するためのユーザ認証の機能を提供する第2の認証部と、前記クライアント端末からの前記認証チケットの送付を受け、前記認証チケットから前記ユーザの前記組織内でのアカウント情報を取得して、前記組織内でのアカウント情報に基づいて前記第2の認証部を介してユーザ認証を行う連携認証部とを有する。
本願において開示される発明のうち、代表的なものによって得られる効果を簡単に説明すれば以下のとおりである。
本発明の代表的な実施の形態によれば、企業等の組織内で通常使用するアカウント情報をそのまま使用して、組織内のサーバ等からの直接の通信がセキュリティ上制限されている外部のサービスに対してユーザ認証を行った上で利用することが可能となる。また、外部のサービスに対して個別のアカウント情報の管理を行うことなく利用することが可能となる。
以下、本発明の実施の形態を図面に基づいて詳細に説明する。なお、実施の形態を説明するための全図において、同一部には原則として同一の符号を付し、その繰り返しの説明は省略する。
本発明の一実施の形態であるアカウント情報連携システムは、企業の社員等のユーザが、社内で通常使用するユーザID、パスワード等のアカウント情報をそのまま使用(ここでの「使用」とは画面を通して「入力」することを指す)して、社内のサーバ等からの直接の通信がセキュリティ上制限されている外部のサービスに対して、ユーザ認証を行った上で利用することを可能とするシステムである。さらに、当該外部のサービスにおいて、ユーザ認証時にアカウント情報の作成や変更等を自動的に行うことにより、ユーザが個別にアカウント情報の登録や変更、削除等の管理作業を行うことを不要とする。
<システム構成>
図1は、本発明の一実施の形態であるアカウント情報連携システムの構成例について概要を示した図である。アカウント情報連携システム1は、例えば、企業内においてLAN(Local Area Network)等からなる社内ネットワーク11によってイントラネット10が構成され、これに社内Webサーバ14、ディレクトリサーバ17、および社員等であるユーザ12の有するクライアント端末上で稼働するWebブラウザ13がそれぞれ接続する構成を有する。
図1は、本発明の一実施の形態であるアカウント情報連携システムの構成例について概要を示した図である。アカウント情報連携システム1は、例えば、企業内においてLAN(Local Area Network)等からなる社内ネットワーク11によってイントラネット10が構成され、これに社内Webサーバ14、ディレクトリサーバ17、および社員等であるユーザ12の有するクライアント端末上で稼働するWebブラウザ13がそれぞれ接続する構成を有する。
ユーザ12は、Webブラウザ13を利用して社内Webサーバ14にアクセス可能であるとともに、さらに、インターネット20を介して外部アプリケーションサーバ30にアクセスして外部サービスの提供を受けることが可能である。ここでの外部サービスとしては、ユーザ登録を行った上で、ユーザ認証を経て利用可能となるものが該当し、例えば、Webベースでのメールやストレージなどを始めとするクラウドコンピューティングサービスや、ファイル転送サービス、会員制の各種ポータルサイト、情報提供サイトなどが挙げられる。なお、セキュリティ上、社内Webサーバ14およびディレクトリサーバ17と、外部アプリケーションサーバ30との間での直接の通信は許可されないものとする。
社内Webサーバ14は、例えば、図示しないWebサーバプログラム上で稼働するソフトウェアプログラムとして実装される認証部15および認証チケット発行部16を有し、ユーザ12に対してユーザ認証のためのインタフェースを提供する情報処理装置である。認証部15は、Webブラウザ13を介して、ユーザ12に対して、外部アプリケーションサーバ30によって提供される外部サービスを利用する際のユーザ認証のためのインタフェース(例えばユーザID/パスワードの入力画面)を外部アプリケーションサーバ30に代わって提供する。また、入力されたユーザID/パスワード等のアカウント情報を利用してディレクトリサーバ17に問合せてユーザ認証を行う。
認証チケット発行部16は、認証部15がユーザ認証の際にディレクトリサーバ17から取得したアカウント情報に基づいて後述する認証チケットを発行する。発行した認証チケットは、認証部15によってWebブラウザ13に対して応答される。
ディレクトリサーバ17は、ユーザ12が社内において通常使用するユーザIDやパスワード、属性情報等からなるアカウント情報を一元的に管理するディレクトリサービスの機能を提供する情報処理装置である。本実施の形態では、当該ディレクトリサーバ17においてLDAPを用いて社内のアカウント情報の管理を行うものとしているが、LDAP以外の手法によるものや、ディレクトリサービス以外の仕組みによってアカウント情報を管理するものであってもよい。また、社内で通常使用されるアカウント情報を一元的に管理していることから、他の社内システムやサービスに対して同様にユーザ認証の機能を提供するものであってもよい。
外部アプリケーションサーバ30は、インターネット20等を介してASP等により外部のサービスを提供する情報処理装置であり、例えば、図示しないWebサーバプログラム上で稼働するソフトウェアプログラムとして実装される連携認証部31および認証部32と、外部サービスに係る処理を実行する業務アプリケーション(図示しない)を有する。
認証部32は、外部アプリケーションサーバ30が通常のユーザに対して提供する一般的なユーザ認証の機能を実装するものであり、例えば、ユーザID/パスワードの入力を受け付けて認証を行う認証機能や、アカウント情報の登録や変更・削除などの管理機能などのインタフェースを有する。
連携認証部31は、イントラネット10内のWebブラウザ13から認証チケットの送付を受け、認証チケットからアカウント情報を取得して、これに基づいて認証部32を介してユーザ認証を行う。このとき、認証チケットから取得したアカウント情報に該当するアカウント情報が外部アプリケーションサーバ30に登録されていない場合は、認証部32を介してアカウント情報の新規登録を行う。アカウント情報が登録されている場合は、必要に応じて認証チケットから取得したアカウント情報に基づいて登録内容を更新する。
なお、本実施の形態では、アカウント情報連携システム1をWebベースのシステム構成により実装する場合を例としているが、これに限らず、例えばクライアント/サーバ型のシステム構成とすることも当然可能である。
<処理の流れ(概要)>
図2は、本実施の形態のアカウント情報連携システムにおける全体的な処理の流れの例について概要を示した図である。まず、社内のユーザ12は、外部アプリケーションサーバ30によって提供される外部サービスを利用するため、Webブラウザ13を利用して社内Webサーバ14の認証部15にアクセスして、アカウント情報の入力画面を介してユーザID/パスワードを入力する(1)。認証部15へのアクセスは、例えば、社内Webサーバ14によって提供されるイントラネット10のポータルサイトからのリンクや、Webブラウザ13のブックマーク等を利用して行うことができる。なお、ここで入力するユーザID/パスワードは、ユーザ12がイントラネット10内の社内システムを利用する際に通常使用するものと同じものである。
図2は、本実施の形態のアカウント情報連携システムにおける全体的な処理の流れの例について概要を示した図である。まず、社内のユーザ12は、外部アプリケーションサーバ30によって提供される外部サービスを利用するため、Webブラウザ13を利用して社内Webサーバ14の認証部15にアクセスして、アカウント情報の入力画面を介してユーザID/パスワードを入力する(1)。認証部15へのアクセスは、例えば、社内Webサーバ14によって提供されるイントラネット10のポータルサイトからのリンクや、Webブラウザ13のブックマーク等を利用して行うことができる。なお、ここで入力するユーザID/パスワードは、ユーザ12がイントラネット10内の社内システムを利用する際に通常使用するものと同じものである。
社内Webサーバ14の認証部15は、入力されたアカウント情報に基づいてディレクトリサーバ17に問合せてユーザ認証を行い(2)、認証が成功した場合にはユーザ12についてのユーザIDや属性情報などを含むアカウント情報をディレクトリサーバ17から取得する(3)。
その後、認証部15は、取得したアカウント情報を認証チケット発行部16に渡す。認証チケット発行部16は、渡されたアカウント情報について所定の妥当性チェックを行った後、アカウント情報を暗号化することによって認証チケットを生成して認証部15に発行する(4)。認証部15は、発行された認証チケット18の情報を含むリダイレクト画面をいったんWebブラウザ13に送信する(5)。
Webブラウザ13では、例えばリダイレクト画面を介して外部アプリケーションサーバ30に対して自動的にアクセスをリダイレクトすることで、認証チケット18を外部アプリケーションサーバ30に転送する(6)。当該処理には公知技術を利用することができ、例えば、JavaScript(登録商標)等を利用した自動Submitによって認証チケット18の情報を外部アプリケーションサーバ30の連携認証部31に対してPOST送信することができる。
外部アプリケーションサーバ30の連携認証部31は、転送されたリクエストの内容から認証チケット18の情報を取得し、取得した認証チケット18を復号化してアカウント情報を復元する。さらに、アカウント情報の内容について所定の妥当性チェックを行い、問題がない場合はこのアカウント情報を用いて連携認証処理を行う。すなわち、認証部32を介して外部アプリケーションサーバ30においてユーザ認証処理を行う(7)。なお、ここでは通常のユーザ認証処理と同様の判定処理を行ってもよいし、アカウント情報の内容が妥当であればその内容を引き継いでそのまま認証を成功させるようにしてもよい。
また、上述したように、このとき認証チケット18から取得したアカウント情報に該当するアカウント情報が外部アプリケーションサーバ30に登録されていない場合は、認証部32を介してアカウント情報の新規登録を行う。アカウント情報が登録されている場合は、認証チケット18から取得したアカウント情報に基づいて登録内容を更新する。
連携認証が成功した場合は、外部アプリケーションサーバ30は、サービスを提供するための画面をWebブラウザ13に対して応答する(8)。以上の一連の処理により、ユーザ12は、外部アプリケーションサーバ30によって提供される外部サービスに対して、社内で通常使用するユーザID/パスワード等のアカウント情報を使用して認証処理を行い、シームレスにアクセスすることが可能となる。
<処理の流れ(初期登録)>
以下では、社内Webサーバ14と外部アプリケーションサーバ30との間で認証チケット18の授受を行い、アカウント情報を連携して認証を行う際の処理の詳細について説明する。図3は、アカウント情報連携システム1の環境構築時に暗号鍵を初期登録しておく処理の流れの例について示した図である。
以下では、社内Webサーバ14と外部アプリケーションサーバ30との間で認証チケット18の授受を行い、アカウント情報を連携して認証を行う際の処理の詳細について説明する。図3は、アカウント情報連携システム1の環境構築時に暗号鍵を初期登録しておく処理の流れの例について示した図である。
本実施の形態では、社内Webサーバ14と外部アプリケーションサーバ30との間での認証チケット18の授受に際して、公開鍵暗号化方式と共通鍵暗号化方式を用いたハイブリッド暗号化方式による暗号化を行う。これにより、外部アプリケーションサーバ30に対するアクセスが、アカウント情報を連携して認証処理を行うことができる企業等からのものであることを証明するとともに、認証チケット18の情報が外部に漏洩した場合でも、社内のディレクトリサーバ17に登録されている元のアカウント情報が復元されないようにする。
このため、まず事前の初期登録として、社内Webサーバ14および外部アプリケーションサーバ30において、秘密鍵と公開鍵からなる鍵ペア(秘密鍵41と公開鍵42、および秘密鍵51と公開鍵52)をそれぞれ生成する(S01、S02)。鍵ペアの生成については、PKI(Public Key Infrastructure:公開鍵基盤)を利用した一般的に入手可能な鍵生成ソフトウェアやライブラリを使用することができる。
生成した鍵ペアのうち、それぞれの公開鍵42および公開鍵52を相互に交換する(S03)。鍵交換の手段については特に限定されず、例えば、インターネット20を介して電子メール等により交換してもよいし、電子証明書の形で発行してもよい。記録媒体に格納してインターネット20を介さずに手動で交換することも可能である。交換した公開鍵52、42は、社内Webサーバ14および外部アプリケーションサーバ30においてそれぞれ保管しておく(S04、S05)。
<処理の流れ(認証チケット生成)>
図4は、ユーザ12が外部サービスの利用にあたって社内Webサーバ14にユーザ認証の要求を行った際に、認証チケット発行部16においてアカウント情報に基づいて認証チケット18を生成する処理の流れの例について示した図である。まず、ディレクトリサーバ17から取得したアカウント情報を暗号化するための共通鍵(セッション鍵)43を生成する(S11)。共通鍵43の生成についても、一般的に入手可能な鍵生成ソフトウェアやライブラリを使用することができる。所定のデータ長の乱数を生成して共通鍵43としてもよい。
図4は、ユーザ12が外部サービスの利用にあたって社内Webサーバ14にユーザ認証の要求を行った際に、認証チケット発行部16においてアカウント情報に基づいて認証チケット18を生成する処理の流れの例について示した図である。まず、ディレクトリサーバ17から取得したアカウント情報を暗号化するための共通鍵(セッション鍵)43を生成する(S11)。共通鍵43の生成についても、一般的に入手可能な鍵生成ソフトウェアやライブラリを使用することができる。所定のデータ長の乱数を生成して共通鍵43としてもよい。
さらにこの共通鍵43によって、アカウント情報44を暗号化して暗号化アカウント情報44’を得る(S12)。ここでは、例えばAES(Advanced Encryption Standard)などの公知の暗号化技術を利用することができる。AESによる暗号化については、一般的に入手可能な暗号化ソフトウェアやライブラリを使用することができる。一方、アカウント情報44の暗号化に用いた共通鍵43は、外部アプリケーションサーバ30から鍵交換によって取得している公開鍵52によって暗号化し、暗号化共通鍵43’としておく(S13)。
また、アカウント情報44については、別途ハッシュ化してアカウント情報ハッシュ値45を取得し(S14)、これを社内Webサーバ14が生成して保管している秘密鍵41によって暗号化して、暗号化アカウント情報ハッシュ値45’を得る(S15)。ここでは、例えばRSA(Rivest Shamir Adleman)などの公知の暗号化技術を利用することができる。RSAによる暗号化についても、一般的に入手可能な暗号化ソフトウェアやライブラリを使用することができる。
上記の処理によって得られた、暗号化共通鍵43’、暗号化アカウント情報44’、および暗号化アカウント情報ハッシュ値45’をまとめて認証チケット18として取り扱う。ここで、暗号化アカウント情報ハッシュ値45’は、アカウント情報44がWebブラウザ13等を介して改竄されていないことを証明する電子署名としての役割を有する。
<処理の流れ(アカウント情報復元)>
図5は、Webブラウザ13を介して社内Webサーバ14から認証チケット18の送付を受けた外部アプリケーションサーバ30の連携認証部31において、認証チケット18からアカウント情報を復元する処理の流れの例について示した図である。まず、Webブラウザ13からのリクエストの内容から認証チケット18、すなわち暗号化共通鍵43’、暗号化アカウント情報44’、および暗号化アカウント情報ハッシュ値45’を取得する。このうちの暗号化共通鍵43’について、外部アプリケーションサーバ30が生成して保管している秘密鍵51によって復号化して、共通鍵43を得る(S21)。
図5は、Webブラウザ13を介して社内Webサーバ14から認証チケット18の送付を受けた外部アプリケーションサーバ30の連携認証部31において、認証チケット18からアカウント情報を復元する処理の流れの例について示した図である。まず、Webブラウザ13からのリクエストの内容から認証チケット18、すなわち暗号化共通鍵43’、暗号化アカウント情報44’、および暗号化アカウント情報ハッシュ値45’を取得する。このうちの暗号化共通鍵43’について、外部アプリケーションサーバ30が生成して保管している秘密鍵51によって復号化して、共通鍵43を得る(S21)。
この共通鍵43によって、認証チケット18の暗号化アカウント情報44’を復号化して、アカウント情報44を得る(S22)。さらに、このアカウント情報44についてハッシュ化して復元アカウント情報ハッシュ値46を取得する(S23)。一方、認証チケット18の暗号化アカウント情報ハッシュ値45’について、社内Webサーバ14から鍵交換によって取得している公開鍵41によって復号化して、アカウント情報ハッシュ値45を取得する(S24)。
このアカウント情報ハッシュ値45と、ステップS23で得られた復元アカウント情報ハッシュ値46とを比較して一致するか否かを判定する(S25)。一致していれば、ステップS22で取得したアカウント情報44はWebブラウザ13等を介して改竄されていないことが証明されるため、このアカウント情報44を用いて後続する連携認証処理を行うことができる。一致しない場合には、Webブラウザ13にエラーを応答して処理を終了する。
なお、上述した認証チケット18の授受に際しての一連の暗号化方式は一例であって、他の暗号化方式を採用することも当然可能である。
<処理の流れ(連携認証)>
図6は、外部アプリケーションサーバ30の連携認証部31および認証部32において、認証チケット18から取得したアカウント情報に基づいて連携認証を行う処理の流れの例について示したフローチャートである。まず、連携認証部31は、認証チケット18から取得したアカウント情報44の内容について所定の妥当性チェックを行う(S31)。ここでは、例えば、ユーザIDの一意性チェック(他のグループ等に同一のユーザIDが存在しないか)や、接続元のWebブラウザ13のIPアドレスの範囲チェック、認証チケット18の発行日時(例えばアカウント情報44に予め設定しておく)と現在日時との乖離チェックなどのチェックが行われる。チェックの結果不当な内容がある場合には、Webブラウザ13にエラーを応答して処理を終了する。
図6は、外部アプリケーションサーバ30の連携認証部31および認証部32において、認証チケット18から取得したアカウント情報に基づいて連携認証を行う処理の流れの例について示したフローチャートである。まず、連携認証部31は、認証チケット18から取得したアカウント情報44の内容について所定の妥当性チェックを行う(S31)。ここでは、例えば、ユーザIDの一意性チェック(他のグループ等に同一のユーザIDが存在しないか)や、接続元のWebブラウザ13のIPアドレスの範囲チェック、認証チケット18の発行日時(例えばアカウント情報44に予め設定しておく)と現在日時との乖離チェックなどのチェックが行われる。チェックの結果不当な内容がある場合には、Webブラウザ13にエラーを応答して処理を終了する。
次に、連携認証部31は、取得したアカウント情報44の内容が、外部アプリケーションサーバ30によって提供される外部サービスに対して既に登録済みかを判定する(S32)。登録されていない場合は、認証部32を介して当該アカウント情報を新規登録する(S33)。一方、既に登録済みの場合は、登録されている内容に対して取得したアカウント情報44の内容に変更があるかを判定し(S34)、変更がある場合は、取得したアカウント情報44の内容に基づいて登録内容を更新する(S35)。
その後、連携認証部31は、認証チケット18から取得したアカウント情報44の内容に基づいて、認証部32を介して外部サービスに対するユーザ認証(ログイン)処理を行い(S36)、連携認証処理を終了する。これにより、ユーザ12は、外部アプリケーションサーバ30によって提供される外部サービスに対して直接アクセスしてユーザ認証を行った場合と同様に、Webブラウザ13を介して当該外部サービスを利用することができる。
以上に説明したように、本発明の一実施の形態であるアカウント情報連携システム1によれば、企業の社員等のユーザ12が、社内で通常使用するユーザID、パスワード等のアカウント情報をそのまま使用して、社内Webサーバ14等からの直接の通信がセキュリティ上制限されている外部アプリケーションサーバ30によって提供される外部サービスに対して、ユーザ認証を行った上で利用することが可能となる。また、当該外部サービスにおいて、ユーザ認証時にアカウント情報の作成や変更等を自動的に行うことにより、ユーザ12が個別にアカウント情報の登録や変更、削除等の管理作業を行うことが不要となる。
以上、本発明者によってなされた発明を実施の形態に基づき具体的に説明したが、本発明は前記実施の形態に限定されるものではなく、その要旨を逸脱しない範囲で種々変更可能であることはいうまでもない。
例えば、本実施の形態では、外部アプリケーションサーバ30によって提供される外部サービスについての専用のユーザ認証画面を提供するものとして、社内Webサーバ14および認証部15を構成しているが、他の社内システムによって提供されるサービスについて既に行われているユーザ認証の情報を引き継ぐものとして、シングルサインオンにより当該外部サービスを利用できるようにしてもよい。
すなわち、例えば社内Webサーバ14では他の社内システムが稼動してサービスを提供しており、ユーザ12が当該社内システムの使用に際して、社内Webサーバ14上で認証部15を介してディレクトリサーバ17によるユーザ認証を行った場合は、その後、当該社内システムからユーザ12がURLのリンク等を介して外部アプリケーションサーバ30によって提供される外部サービスを新たに使用する際に、社内Webサーバ14でのユーザ認証の際に使用されたアカウント情報(例えばCookie等に保存)を用いることで、認証チケット発行部16は、ディレクトリサーバ17からアカウント情報を再度取得することなく認証チケット18を発行する。
この認証チケット18を上述した手順と同様の手順でWebブラウザ13を介して外部アプリケーションサーバ30に受け渡し、外部アプリケーションサーバ30において連携認証を行うことで、ユーザ12によるユーザID/パスワードの再度の入力およびディレクトリサーバ17での再度のユーザ認証処理を要さずに外部サービスを利用可能とすることができる。
本発明は、企業内で通常使用されるアカウント情報を外部のサービスに連携させるアカウント情報連携システムに利用可能である。
1…アカウント情報連携システム、
10…イントラネット、11…社内ネットワーク、12…ユーザ、13…Webブラウザ、14…社内Webサーバ、15…認証部、16…認証チケット発行部、17…ディレクトリサーバ、18…認証チケット、
20…インターネット、
30…外部アプリケーションサーバ、31…連携認証部、32…認証部、
41…秘密鍵、42…公開鍵、43…共通鍵、43’…暗号化共通鍵、44…アカウント情報、44’…暗号化アカウント情報、45…アカウント情報ハッシュ値、45’…暗号化アカウント情報ハッシュ値、46…復元アカウント情報ハッシュ値、
51…秘密鍵、52…公開鍵
10…イントラネット、11…社内ネットワーク、12…ユーザ、13…Webブラウザ、14…社内Webサーバ、15…認証部、16…認証チケット発行部、17…ディレクトリサーバ、18…認証チケット、
20…インターネット、
30…外部アプリケーションサーバ、31…連携認証部、32…認証部、
41…秘密鍵、42…公開鍵、43…共通鍵、43’…暗号化共通鍵、44…アカウント情報、44’…暗号化アカウント情報、45…アカウント情報ハッシュ値、45’…暗号化アカウント情報ハッシュ値、46…復元アカウント情報ハッシュ値、
51…秘密鍵、52…公開鍵
Claims (5)
- 組織の内部の第1のネットワークに接続され、前記組織内のユーザに対してユーザ認証のためのインタフェースを提供する第1のサーバと、前記組織内のユーザのアカウント情報を管理する第2のサーバと、前記第1のネットワークおよび前記組織の外部の第2のネットワークに接続可能なクライアント端末、および前記第2のネットワークに接続されたアプリケーションサーバとからなり、
前記ユーザが、前記アプリケーションサーバによって提供される外部サービスに対して、前記組織内でのアカウント情報を使用してユーザ認証を行った上で利用することを可能とするアカウント情報連携システムであって、
前記第1のサーバは、前記組織内のユーザに対して前記外部サービスを利用する際のユーザ認証のためのインタフェースを提供し、前記ユーザによって前記クライアント端末から入力されたアカウント情報を利用して前記第2のサーバによってユーザ認証を行う第1の認証部と、前記第1の認証部が前記第2のサーバから取得した前記ユーザの前記組織内でのアカウント情報に基づいて認証チケットを発行し、発行した前記認証チケットを前記第1の認証部を介して前記クライアント端末に応答する認証チケット発行部とを有し、
前記クライアント端末は、前記第1のサーバから応答された前記認証チケットを前記アプリケーションサーバに転送し、
前記アプリケーションサーバは、前記外部サービスを利用するためのユーザ認証の機能を提供する第2の認証部と、前記クライアント端末からの前記認証チケットの送付を受け、前記認証チケットから前記ユーザの前記組織内でのアカウント情報を取得して、前記組織内でのアカウント情報に基づいて前記第2の認証部を介してユーザ認証を行う連携認証部とを有することを特徴とするアカウント情報連携システム。 - 請求項1に記載のアカウント情報連携システムにおいて、
前記アプリケーションサーバの前記連携認証部は、前記クライアント端末から送付された前記認証チケットから取得した前記ユーザの前記組織内でのアカウント情報が前記アプリケーションサーバに登録されていない場合は、前記認証部を介して、前記組織内でのアカウント情報に基づいて前記アプリケーションサーバに対してアカウント情報の新規登録を行うことを特徴とするアカウント情報連携システム。 - 請求項1または2に記載のアカウント情報連携システムにおいて、
前記アプリケーションサーバの前記連携認証部は、前記クライアント端末から送付された前記認証チケットから取得した前記ユーザの前記組織内でのアカウント情報が前記アプリケーションサーバに既に登録されている場合は、前記アプリケーションサーバでのアカウント情報の登録内容に対して、前記組織内でのアカウント情報の内容に変更がある場合に、前記認証部を介して、前記組織内でのアカウント情報に基づいて前記アプリケーションサーバでのアカウント情報の登録内容を更新することを特徴とするアカウント情報連携システム。 - 請求項1〜3のいずれか1項に記載のアカウント情報連携システムにおいて、
前記第1のサーバの前記認証チケット発行部は、前記認証チケットを暗号化して発行し、
前記アプリケーションサーバの前記連携認証部は、前記クライアント端末から送付された前記認証チケットを復号化して前記ユーザの前記組織内でのアカウント情報を取得することを特徴とするアカウント情報連携システム。 - 請求項1〜4のいずれか1項に記載のアカウント情報連携システムにおいて、
前記第1のサーバでは他のサービスを提供しており、
前記第1の認証部は、前記ユーザが前記他のサービスを利用する際のユーザ認証を行うためのインタフェースを提供し、
前記認証チケット発行部は、前記ユーザが前記他のサービスの利用中に前記アプリケーションサーバによって提供される前記外部サービスを新たに利用する際に、前記他のサービスを利用する際のユーザ認証において使用されたアカウント情報を用いて認証チケットを発行することを特徴とするアカウント情報連携システム。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2011043920A JP2012181662A (ja) | 2011-03-01 | 2011-03-01 | アカウント情報連携システム |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2011043920A JP2012181662A (ja) | 2011-03-01 | 2011-03-01 | アカウント情報連携システム |
Publications (1)
Publication Number | Publication Date |
---|---|
JP2012181662A true JP2012181662A (ja) | 2012-09-20 |
Family
ID=47012814
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2011043920A Pending JP2012181662A (ja) | 2011-03-01 | 2011-03-01 | アカウント情報連携システム |
Country Status (1)
Country | Link |
---|---|
JP (1) | JP2012181662A (ja) |
Cited By (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2016042327A (ja) * | 2014-08-19 | 2016-03-31 | 株式会社リコー | 情報処理システム及び認証方法 |
JP6059307B1 (ja) * | 2015-08-04 | 2017-01-11 | ヤフー株式会社 | 端末装置、情報送信方法、及び情報送信プログラム |
JP2017102882A (ja) * | 2015-11-25 | 2017-06-08 | 株式会社リコー | 情報処理装置、端末装置、プログラム及び情報処理システム |
JP2020047287A (ja) * | 2016-03-15 | 2020-03-26 | 富士ゼロックス株式会社 | プログラム及び情報処理装置 |
Citations (6)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JPH10269184A (ja) * | 1997-03-28 | 1998-10-09 | Hitachi Ltd | ネットワークシステムのセキュリティ管理方法 |
JP2004234329A (ja) * | 2003-01-30 | 2004-08-19 | Nippon Telegraph & Telephone East Corp | Idマッピングを利用したシングルサインオンシステム、方法、プログラム並びに記憶媒体 |
JP2004334395A (ja) * | 2003-05-02 | 2004-11-25 | Taisei Corp | シングルサインオン認証方法 |
JP2006031714A (ja) * | 2004-07-21 | 2006-02-02 | Internatl Business Mach Corp <Ibm> | データ処理システム、方法およびコンピュータ・プログラム(連合ユーザ・ライフサイクル管理用の信頼インフラストラクチャ・サポートを可能にする方法およびシステム) |
JP2009535729A (ja) * | 2006-05-01 | 2009-10-01 | マイクロソフト コーポレーション | 信頼関係に対するクレーム変換 |
JP2010086435A (ja) * | 2008-10-02 | 2010-04-15 | Hitachi Ltd | 情報処理方法およびコンピュータ |
-
2011
- 2011-03-01 JP JP2011043920A patent/JP2012181662A/ja active Pending
Patent Citations (6)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JPH10269184A (ja) * | 1997-03-28 | 1998-10-09 | Hitachi Ltd | ネットワークシステムのセキュリティ管理方法 |
JP2004234329A (ja) * | 2003-01-30 | 2004-08-19 | Nippon Telegraph & Telephone East Corp | Idマッピングを利用したシングルサインオンシステム、方法、プログラム並びに記憶媒体 |
JP2004334395A (ja) * | 2003-05-02 | 2004-11-25 | Taisei Corp | シングルサインオン認証方法 |
JP2006031714A (ja) * | 2004-07-21 | 2006-02-02 | Internatl Business Mach Corp <Ibm> | データ処理システム、方法およびコンピュータ・プログラム(連合ユーザ・ライフサイクル管理用の信頼インフラストラクチャ・サポートを可能にする方法およびシステム) |
JP2009535729A (ja) * | 2006-05-01 | 2009-10-01 | マイクロソフト コーポレーション | 信頼関係に対するクレーム変換 |
JP2010086435A (ja) * | 2008-10-02 | 2010-04-15 | Hitachi Ltd | 情報処理方法およびコンピュータ |
Cited By (6)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2016042327A (ja) * | 2014-08-19 | 2016-03-31 | 株式会社リコー | 情報処理システム及び認証方法 |
JP6059307B1 (ja) * | 2015-08-04 | 2017-01-11 | ヤフー株式会社 | 端末装置、情報送信方法、及び情報送信プログラム |
JP2017033417A (ja) * | 2015-08-04 | 2017-02-09 | ヤフー株式会社 | 端末装置、情報送信方法、及び情報送信プログラム |
JP2017102882A (ja) * | 2015-11-25 | 2017-06-08 | 株式会社リコー | 情報処理装置、端末装置、プログラム及び情報処理システム |
JP2020064660A (ja) * | 2015-11-25 | 2020-04-23 | 株式会社リコー | 情報処理装置、端末装置、プログラム及び情報処理システム |
JP2020047287A (ja) * | 2016-03-15 | 2020-03-26 | 富士ゼロックス株式会社 | プログラム及び情報処理装置 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
AU2021206913B2 (en) | Systems and methods for distributed data sharing with asynchronous third-party attestation | |
US10027670B2 (en) | Distributed authentication | |
US10630489B2 (en) | Apparatus and method for managing digital certificates | |
KR100872099B1 (ko) | 컴퓨터 그리드에 대한 싱글-사인-온 액세스를 위한 방법 및시스템 | |
US8788811B2 (en) | Server-side key generation for non-token clients | |
US9137017B2 (en) | Key recovery mechanism | |
US9130758B2 (en) | Renewal of expired certificates | |
US20110296171A1 (en) | Key recovery mechanism | |
US7320073B2 (en) | Secure method for roaming keys and certificates | |
KR20060100920A (ko) | 웹 서비스를 위한 신뢰되는 제3자 인증 | |
US20110113240A1 (en) | Certificate renewal using enrollment profile framework | |
JP5602165B2 (ja) | ネットワーク通信を保護する方法および装置 | |
US8806195B2 (en) | User interface generation in view of constraints of a certificate profile | |
JP2007328482A (ja) | 通信処理方法及びコンピュータ・システム | |
JP2018092446A (ja) | 認証認可システム及び情報処理装置と認証認可方法とプログラム | |
US7451305B1 (en) | Method and apparatus for securely exchanging cryptographic identities through a mutually trusted intermediary | |
JP2012181662A (ja) | アカウント情報連携システム | |
JP2006260321A (ja) | サービス提供システムおよびそのユーザ認証方法 | |
JP4963425B2 (ja) | セッション鍵共有システム、第三者機関装置、要求側装置、および応答側装置 | |
JP2012103931A (ja) | クラウドサービス間の信頼関係構築方法及びシステム | |
TWI759090B (zh) | 平台登入方法 | |
KR20230133098A (ko) | 인증 기관과 독립적으로 인증서 내의 인증 정보를 관리하기 위한 방법 | |
NL2010808C2 (en) | System and method for remote access. | |
Malygin | INVESTIGATION OF DIGITAL CERTIFICATES: Creation of self-signed certificate on Windows 8 | |
Protocol | draft-hallambaker-omnibroker-02 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20130312 |
|
A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20131227 |
|
A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20140114 |
|
A02 | Decision of refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A02 Effective date: 20140520 |