JP4543322B2 - 仲介サーバ、第２の認証サーバ、これらの動作方法、及び通信システム - Google Patents

Description

本発明は、認証情報を用いたシングルサインオン連携方法、シングルサインオンシステム、仲介サーバ、その動作方法及び動作プログラムに関する。

コンピュータネットワークでは、通常、ネットワークを通して利用可能なＷｅｂサーバによるＷｅｂコンテンツ等の複数のリソースへのアクセスやその利用権限をユーザに応じて制限している。このため、ユーザは各リソースへのアクセス時にユーザ名やパスワード等の情報を入力して、その都度認証を得る必要があった。しかし、個々のリソースへアクセスする度にユーザ名やパスワード等の情報を入力する操作は、ユーザにとっては大変煩わしく、またセキュリティ上の理由でリソース毎に異なるパスワードを設定していれば、パスワード数がリソース数に比例して増えるため、必ずしも利便性のよいものではなかった。

そこで、近年、このような複数のリソースにアクセスする際、一度だけ認証を行うことで、同じドメインに属するネットワーク内のアクセス許可されている全てのリソースを利用できる「シングルサインオン（Single Sign-on）」と呼ばれる認証方法が知られている。このシングルサインオン方法を用いたシステム（以下、「シングルサインオンシステム」と呼ぶ）では、例えばクッキー等既存の独自認証識別子を使用した認証情報をクライアント（ユーザ端末）に保管し、同じドメインに属するネットワーク内のＷｅｂコンテンツ等のリソースへのアクセス時にサーバ側でその認証情報を用いて認証を行う方式等が知られている。

なお、本発明に関連する先行技術文献としては、次のものがある。
特開２００４−３５５０７３号公報 特開２００４−２３４３２９号公報 特開２００４−１８５３９６号公報 特許第３５０５０５８号公報

従来、シングルサインオンを行う為には、クッキー等既存の独自認証識別子を使用する必要があった。クッキー等既存の独自認証識別子は、異なるドメイン間でやりとりすることは難しい上、クッキー等既存の独自認証識別子そのものに互換性が無いために、方式の異なるシングルサインオンシステムを連携させる場合、双方のクッキー等既存の独自認証識別子を合わせたり、変換したりする必要があった。

このように方式の異なるシングルサインオンシステム同士を連携させる場合、シングルサインオンサーバが連携相手となるシングルサインオン方式を理解する必要があったため、認証サーバの置き換えや接続先毎の対応が発生するという問題があった。上述した先行技術文献では、このような方式の異なるシングルサインオンシステム同士を連携させる場合の問題解決を必ずしも意図したものではない。

本発明は、このような従来の事情を考慮してなされたもので、方式の異なるシングルサインオンシステムを連携させる場合に、双方のクッキー等既存の独自認証識別子を合わせたり、変換したりする必要がなく、認証サーバの置き換えや接続先毎の対応が発生しないようにすることを目的とする。

上記目的を達成するため、本発明に係る仲介サーバは、第１の認証サーバがクライアントの認証結果を示すために発行する第１の認証識別子をクライアントの認証処理が可能な認証識別子が異なる第２の認証サーバに仲介する仲介サーバであって、前記第１の認証識別子を前記クライアントより受信し、該クライアントが前記第１の認証サーバで認証されていることを確認し、前記確認が行われたことを示す情報を前記第２の認証サーバが処理可能な形式に変換して前記第２の認証サーバへ送付することを特徴とする。

本発明において、前記第１の認証識別子は、ｈｔｔｐプロトコルで用いられるクッキーに含まれることにより前記クライアントから前記受信してもよい。

本発明において、前記第２の認証サーバへ送付する際に、前記仲介サーバが前記変換を行ったことを示す情報を含んでもよい。

また、本発明に係る第２の認証サーバは、第１の認証サーバでクライアントが認証されていることを示す情報を受信し、前記第１の認証サーバで生成された前記クライアントの認証識別子を用いて前記クライアントの認証処理が可能な第２の認証識別子を前記情報から作成し、
前記第２の認証識別子を前記クライアントに送信することを特徴とする。

本発明において、前記情報は、ｈｔｔｐプロトコルで用いられるクッキーに含まれることにより前記クライアントから前記受信してもよい。

本発明において、前記第１の認証サーバと前記第２の認証サーバとが異なるドメインに属することでクッキーに含まれる情報が該第１の認証サーバと該第２の認証サーバでやりとりできなくてもよい。

本発明において、前記認証されていることを示す情報は、前記認証されているクライアントの情報を含んでもよい。

本発明において、前記クライアントの情報は、クライアントを使用しているユーザの識別子を含んでもよい。

また、本発明に係る通信システムは、クライアントと、上記に記載の仲介サーバと、上記に記載の第２の認証サーバとを少なくとも含むことを特徴とする。

本発明に係る仲介サーバの動作方法は、第１の認証サーバがクライアントの認証結果を示すために発行する第１の認証識別子をクライアントの認証処理が可能な認証識別子が異なる第２の認証サーバに仲介する仲介サーバの動作方法であって、前記第１の認証識別子を前記クライアントより受信し、該クライアントが前記第１の認証サーバで認証されていることを確認し、前記確認が行われたことを示す情報を前記第２の認証サーバが処理可能な形式に変換して前記第２の認証サーバへ送付することを特徴とする。

本発明に係る第２の認証サーバの動作方法は、第１の認証サーバでクライアントが認証されていることを示す情報を受信し、前記第１の認証サーバで生成された前記クライアントの認証識別子を用いて前記クライアントの認証処理が可能な第２の認証識別子を前記情報から作成し、前記第２の認証識別子を前記クライアントに送信することを特徴とする。

本発明によれば、方式の異なるシングルサインオンシステムを連携させる場合に、双方のクッキー等既存の独自認証識別子を合わせたり、変換したりする必要がなく、認証サーバの置き換えや接続先毎の対応が発生しない。

次に、本発明に係る認証情報を用いたシングルサインオン連携方法、シングルサインオンシステム、仲介サーバ、その動作方法及び動作プログラムを実施するための最良の形態について図面を参照して詳細に説明する。

本実施の形態は、方式の異なるシングルサインオンシステムに対して仲介となるサーバを用意するだけで連携することを可能とするものである。即ち、本実施の形態では、既存のシングルサインオンシステムに新たに新方式のシングルサインオンシステムを連携させる場合において、既存のシングルサインオンシステムに、既存のシングルサインオン方式を新しいシングルサインオン方式で解釈できる仲介サーバを追加することで、新方式のシングルサインオンシステムで、既存のシングルサインオンシステムを使用することを可能とする。

図１を参照すると、本実施例によるシングルサインオンシステムは、ドメインの異なるネットワークシステムで構成され且つシングルサインオンによる認証方式が異なるシングルサインオンシステム（以下、シングルサインオンドメイン）を備えている。図１の例では、この方式が異なるシングルサインオンシステムとして、既存のシングルサインオンドメイン（第１のシングルサインオンシステム）１と、既存のシングルサインオンドメイン１に接続させようとする新方式のシングルサインオンドメイン（第２のシングルサインオンシステム）２とを有し、両シングルサインオンドメイン１、２にインターネット３１を介してユーザ操作用のクライアント３２が接続されている。

既存のシングルサインオンドメイン１は、認証情報としてクッキー等既存の独自認証識別子を使用する既存のシングルサインオンによる認証を行うもので、ユーザの認証を行う認証サーバ（第１の認証サーバ）１１と、認証サーバ１１によって認証を受けたユーザに対してＷｅｂコンテンツを提供するＷｅｂサーバ（第１のサーバ）１２と、既存のシングルサインオンドメイン１に属する仲介サーバ１０とを有している。認証サーバ１１、Ｗｅｂサーバ１２、及び仲介サーバ１０は、ネットワーク１３に接続され、そのネットワーク１３がインターネット３１に接続されている。

新方式のシングルサインオンドメイン２は、認証情報としてクッキー等既存の独自認証識別子を使用せずに所定の認証アサーションを使用する新方式（例えば、既知のＳＡＭＬ（Security Assertion Markup Language）プロトコルに従って認証情報を交換する方式等）のシングルサインオンによる認証を行うもので、ユーザの認証を行う認証サーバ（第２の認証サーバ）２１と、認証サーバ２１によって認証を受けたユーザに対してＷｅｂコンテンツを提供するＷｅｂサーバ（第２のサーバ）２２と、既存のシングルサインオンドメイン１に属すると共に新方式のシングルサインオンドメイン２に属する仲介サーバ１０とを有している。認証サーバ２１及びＷｅｂサーバ２２は、ネットワーク２３に接続され、そのネットワーク２３がインターネット３１に接続されている。

仲介サーバ１０は、既存のシングルサインオンドメイン１にも新方式のシングルサインオンドメイン２にも属し、新方式のシングルサインオンドメイン２の認証サーバ２１に対して、クライアント３２が既存のシングルサインオンドメイン１で認証を受けている場合、それを認証サーバ２１に通知する機能を持つ。また、認証サーバ１１に対して、クッキー等既存の独自認証識別子の生成要求を行う機能を持つ。図１の例では、Ｗｅｂサーバとしての機能も兼ねている。これらの機能は、仲介サーバ１０を構成するコンピュータ機が予め設定された認証プログラム等のプログラムを実行することで実現される。

認証サーバ１１は、ユーザの認証とクッキー等既存の独自認証識別子の作成を行う機能を持つ。また、認証サーバ１１は、仲介サーバ１０からのクッキー等既存の独自認証識別子の生成要求に対し、クッキー等既存の独自認証識別子の作成を行う機能を持つ。これらの機能は、認証サーバ１１を構成するコンピュータ機が予め設定された認証プログラム等の動作プログラムを実行することで実現される。

Ｗｅｂサーバ１２は、通常のＷｅｂサーバが有している既存の機能のほか、認証サーバ１１で発行されたクッキー等既存の独自認証識別子を理解することができ、認証されたユーザに対しコンテンツの提供を行う機能を持つ。これらの機能は、Ｗｅｂサーバ１２を構成するコンピュータ機が予め設定されたＷｅｂサーバソフトウェア等の動作プログラムを実行することで実現される。Ｗｅｂサーバ１２は、提供するコンテンツにより複数存在するものとする。

認証サーバ２１は、ユーザの認証と認証アサーションの作成を行う機能と、認証アサーションの検証を行う機能とを持つ。認証アサーションは、認証されたことを示す情報で、認証した方式や有効期限などの情報から構成される。これらの機能は、認証サーバ２１を構成するコンピュータ機が予め設定された認証プログラム等の動作プログラムを実行することで実現される。なお、認証アサーションの例として、ＳＡＭＬプロトコルに従い規定されるＳＡＭＬアサーションがある。

Ｗｅｂサーバ２２は、通常のＷｅｂサーバが有している既存の機能のほか、認証サーバ２１で発行された認証アサーションの検証を行うことができ、認証されたユーザに対しコンテンツの提供を行う機能を持つ。これらの機能は、Ｗｅｂサーバ２２を構成するコンピュータ機が予め設定されたＷｅｂサーバソフトウェア等の動作プログラムを実行することで実現される。Ｗｅｂサーバ２２は、提供するコンテンツにより複数存在するものとする。

クライアント３２は、ＰＣ（パーソナルコンピュータ）等のコンピュータ機で構成され、インターネット３１を介して両シングルサインオンドメイン１、２とシングルサインオンを行う。本実施例では、既存のシングルサインオンドメイン１で認証済みのユーザ用のクライアント３２が、新方式のシングルサインオンドメイン２でシングルサインオンを行う場合を想定している。

なお、上記の各種サーバ１０〜１２、２１〜２２及びクライアント３２を構成するコンピュータ機内のハードウェア構成（ＣＰＵ、メモリ（ＲＯＭ／ＲＡＭ）及びその他の記録媒体、通信Ｉ／Ｆ等の各種Ｉ／Ｏ装置等）の詳細については、既存のマシンがそのまま適用され、本発明とは直接関係しないため、その説明を省略する。

次に、図２及び図２を参照して、本実施例の動作について詳細に説明する。

まず、図２を参照して、既存のシングルサインオンドメイン１でユーザを認証した場合に、新方式のシングルサインオンドメイン２からシングルサインオンを実施する場合を考える。

まず、クライアント３２は、既存のシングルサインオンドメイン１に対してユーザＩＤ及びパスワード等の情報を用いてシングルサインオン（ＳＳＯ）を行う。これにより、認証サーバ１１は、ＳＳＯ認証を行い、既存のシングルサインオンドメイン１内で読むことができるクッキー等既存の独自認証識別子を発行する（ステップ１１）。この独自認証識別子は、仲介サーバ１０から参照することができる。

次に、クライアント３２からＷｅｂサーバ２２に対してアクセスを行う（ステップ１２）。アクセスされたＷｅｂサーバ２２は、クライアント３２がまだ認証されていないことを検出する（ステップ１０３）と、認証サーバ２１で認証を行わせるために、リダイレクトをクライアント３２に対して返す（ステップ１０４）。リダイレクトの結果、クライアント３２は、認証サーバ２１に対してアクセスを行う（ステップ１０５）。

認証サーバ２１は、クライアント３２が認証されていないことを検出する（ステップ１０６）と、仲介サーバ１０に対してクライアント３２がシングルサインオンドメイン１で認証を受けているかどうかを問い合わせるために、リダイレクトを発行する（ステップ１０７）。リダイレクトの結果、クライアント３２は、仲介サーバ１０に対してアクセスを行う（ステップ１０８）。このときのアクセス情報には、認証サーバ１１で発行された第１のシングルサインオンドメイン１のクッキー等既存の独自認証識別子が含まれる。

次いで、仲介サーバ１０は、クライアント３２のアクセス情報から認証サーバ１１で発行された既存のシングルサインオンドメイン１のクッキー等既存の独自認証識別子を読み出すと、上記ステップ１１にて既存のシングルサインオンドメイン１の認証サーバ１１により認証されていることを検出する（ステップ１０９）。

これにより、仲介サーバ１０は、既存のシングルサインオンドメイン１で認証されていることを示す認証アサーションを発行し（ステップ１１０）、発行された認証アサーションとともに、認証サーバ２１に戻るようにリダイレクトをかける（ステップ１１１）。リダイレクトの結果、クライアント３２は、認証サーバ２１に対してアクセスを行う（ステップ１１２）。

認証サーバ２１は、クライアント３２から、仲介サーバ１０により発行された認証アサーションを受け取る（ステップ１１３）と、認証アサーションの中身を確認し（ステップ１１４）、受け入れが確認できる場合は、認証サーバ２１で新たにシングルサインオンドメイン２の認証アサーションを生成する（ステップ１１５）。

次いで、認証サーバ２１は、発行された認証アサーションとともに、Ｗｅｂサーバ２２に戻るようにリダイレクトをかける（ステップ１１６）。リダイレクトの結果、クライアント３２は、Ｗｅｂサーバ２２に対してアクセスを行う（ステップ１１７）。

Ｗｅｂサーバ２２は、クライアント３２から認証アサーションを受け取り、中身を確認する（ステップ１１８）。この認証アサーションの確認後、Ｗｅｂサーバ２２は、情報を開示する（ステップ１１９）。

次に、図３を参照して、新方式のシングルサインオンドメイン２でユーザを認証したことを、既存のシングルサインオンドメイン１から利用する場合を考える。

まず、クライアント３２（ユーザ）は、新方式のシングルサインオンドメイン２に対してシングルサインオン（ＳＳＯ）を行うために、Ｗｅｂサーバ２２へアクセスする（ステップ２１）。

アクセスされたＷｅｂサーバ２２は、クライアント３２が認証されていないことを検出し（ステップ２２）、認証サーバ２１へリダイレクトを行う（ステップ２０３）。リダイレクトの結果、クライアント３２は、認証サーバ２１に対してアクセスを行う（ステップ２０４）。

これにより、認証サーバ２１は、ＳＳＯ認証を行い（ステップ２０５）、認証後、認証アサーションを発行し（ステップ２０６）、発行された認証アサーションとともに、仲介サーバ１０に対してクライアント３２が認証されていることを示すためにリダイレクトをかける（ステップ２０７）。リダイレクトの結果、クライアント３２は、仲介サーバ１０に対してアクセスを行う（ステップ２０８）。

仲介サーバ１０は、クライアント３２から受け取った認証アサーションの中身を確認し（ステップ２０９）、受け入れが確認できる場合は、認証サーバ１１に対してクライアント３２のクッキー等既存の独自認証識別子の発行依頼（生成要求）を行う（ステップ２１０）。

認証サーバ１１は、クライアント３２に対してＳＳＯ認証を行い、クッキー等既存の独自認証識別子を発行する（ステップ２１１）。認証サーバ１１は、仲介サーバ１０に対して認証終了を通知する（ステップ２１２）。

仲介サーバ１０は、認証サーバ２１に戻るようにリダイレクトをかける（ステップ２１３）。リダイレクトの結果、クライアント３２は、認証サーバ２１に対してアクセスを行う（ステップ２１４）。

その後、認証サーバ２１は、発行された認証アサーションとともに、Ｗｅｂサーバ２２に戻るように、リダイレクトをかける（ステップ２１５）。リダイレクトの結果、クライアント３２は、認証アサーションと共に、Ｗｅｂサーバ２２に対してアクセスを行う（ステップ２１６）。

Ｗｅｂサーバ２２は、送られた認証アサーションを検証し（ステップ２１７）、その認証アサーションの中身を確認後、情報開示を行い（ステップ２１８）、これによりシングルサインオンが成立する。

従って、本実施例によれば、仲介サーバを用いることにより、クッキー等既存の独自認証識別子を使用している既存のシングルサインオンシステムと、クッキー等既存の独自認証識別子を使用することのできない新方式のシングルサインオンシステムとを連携させることが可能となる。

また、本実施例によれば、既存のシングルサインオンドメイン側の修正が不要であり、修正のためのコストがかからない。これは、従来、異なるシングルサインオン方式を連携させるためには、認証サーバで他のシングルサインオン方式で使用されるクッキー等既存の独自認証識別子を理解し、自身が使用する識別子へ変換する必要があったが、本実施例で示した通りこれが不要となる。

なお、上記実施例では、各サーバ間で認証アサーションを直接渡す場合を説明しているが、その他の実施例として、「アーティファクト」と呼ばれる認証アサーションと結びつけられた識別子を渡し、アーティファクトを渡されたサーバがアサーションを取得する方法を採用することもできる。この場合、上記実施例と比べて、認証アサーションを渡す部分が、アーティファクトを渡すこととなり、また、渡されたサーバの処理にアーティファクトからアサーションを取得しにいくという動作が追加されることになる。なお、アーティファクトの例として、ＳＡＭＬプロトコルに従い規定されるＳＡＭＬアーティファクトがある。

また、上記実施例のステップ１１３を省略することもできる。この場合、Ｗｅｂサーバ２２が、仲介サーバ１０の認証アサーションを直接検証を行うことで実施することが可能となる。

また、上記実施例では、新方式のシングルサインオンドメイン２でユーザを認証したことを既存のシングルサインオンドメイン１から利用する場合において、仲介サーバを使用しているが、その他の実施例として、仲介サーバを使用しない場合でも適用可能である。この場合、認証サーバ１１が、他の認証サーバ（ここでは、認証サーバ２１）からの認証受け入れ要求を受け付ける機能を持つ必要がある。認証サーバ２１での認証後、ステップ２０６において、仲介サーバにリダイレクトを行う代わりに、直接認証サーバ１１に対して認証受け入れ要求を行う。これにより、認証サーバ１１でクッキー等既存の独自認証識別子を発行することで、シングルサインオンの連携を行うことが可能となる。

さらに、上記実施例では、認証サーバ１１が、仲介サーバ１０からのクッキー等既存の独自認証識別子の生成要求に対し、クッキー等既存の独自認証識別子の作成を行う機能を持っているが、その他の実施例として、この機能を持たない場合でも適用可能である。この場合、上記実施例と比べて、新方式のシングルサインオンドメイン２でユーザを認証したことを、既存のシングルサインオンドメイン１からの利用ができなくなる。つまり、ステップ２１以降の実施が不可能となる以外は、上記実施例と同様となる。

本発明の実施例によるシングルサインオンシステムの全体構成を示す図である。 既存のシングルサインオンドメインでユーザを認証した場合に新方式のシングルサインオンドメインからシングルサインオンを実施する場合の動作を説明するシーケンス図である。 新方式のシングルサインオンドメインでユーザを認証したことを既存のシングルサインオンドメインから利用する場合の動作を説明するシーケンス図である。

符号の説明

１ 既存のシングルサインオンドメイン
２ 新方式のシングルサインオンドメイン
１０ 仲介サーバ
１１、２１ 認証サーバ
１２、２２ Ｗｅｂサーバ
１３、２３ ネットワーク

Claims (17)

1. 第１の認証サーバがクライアントの認証結果を示すために発行する第１の認証識別子をクライアントの認証処理が可能な認証識別子が異なる第２の認証サーバに仲介する仲介サーバであって、
   前記第１の認証識別子を前記クライアントより受信し、該クライアントが前記第１の認証サーバで認証されていることを確認し、前記確認が行われたことを示す情報を前記第２の認証サーバが処理可能な形式に変換して前記第２の認証サーバへ送付することを特徴とする仲介サーバ。
2. 前記第１の認証識別子は、ｈｔｔｐプロトコルで用いられるクッキーに含まれることにより前記クライアントから前記受信することを特徴とする請求項１記載の仲介サーバ。
3. 前記第２の認証サーバへ送付する際に、前記仲介サーバが前記変換を行ったことを示す情報を含むことを特徴とする請求項１記載の仲介サーバ。
4. 第１の認証サーバでクライアントが認証されていることを示す情報を受信し、
   前記第１の認証サーバで生成された前記クライアントの認証識別子を用いて前記クライアントの認証処理が可能な第２の認証識別子を前記情報から作成し、
   前記第２の認証識別子を前記クライアントに送信することを特徴とする第２の認証サーバ。
5. 前記情報は、ｈｔｔｐプロトコルで用いられるクッキーに含まれることにより前記クライアントから前記受信することを特徴とする請求項４記載の第２の認証サーバ。
6. 前記第１の認証サーバと前記第２の認証サーバとが異なるドメインに属することでクッキーに含まれる情報が該第１の認証サーバと該第２の認証サーバでやりとりできないことを特徴とする請求項５記載の第２の認証サーバ。
7. 前記認証されていることを示す情報は、前記認証されているクライアントの情報を含むことを特徴とする請求項４記載の第２の認証サーバ。
8. 前記クライアントの情報は、クライアントを使用しているユーザの識別子を含むことを特徴とする請求項７記載の第２の認証サーバ。
9. クライアントと、
   請求項１記載の仲介サーバと、
   請求項４記載の第２の認証サーバと
   を少なくとも含むことを特徴とする通信システム。
10. 第１の認証サーバがクライアントの認証結果を示すために発行する第１の認証識別子をクライアントの認証処理が可能な認証識別子が異なる第２の認証サーバに仲介する仲介サーバの動作方法であって、
    前記第１の認証識別子を前記クライアントより受信し、該クライアントが前記第１の認証サーバで認証されていることを確認し、前記確認が行われたことを示す情報を前記第２の認証サーバが処理可能な形式に変換して前記第２の認証サーバへ送付することを特徴とする仲介サーバの動作方法。
11. 前記第１の認証識別子は、ｈｔｔｐプロトコルで用いられるクッキーに含まれることにより前記クライアントから前記受信することを特徴とする請求項１記載の仲介サーバの動作方法。
12. 前記第２の認証サーバへ送付する際に、前記仲介サーバが前記変換を行ったことを示す情報を含むことを特徴とする請求項１記載の仲介サーバの動作方法。
13. 第１の認証サーバでクライアントが認証されていることを示す情報を受信し、
    前記第１の認証サーバで生成された前記クライアントの認証識別子を用いて前記クライアントの認証処理が可能な第２の認証識別子を前記情報から作成し、
    前記第２の認証識別子を前記クライアントに送信する、
    ことを特徴とする第２の認証サーバの動作方法。
14. 前記情報は、ｈｔｔｐプロトコルで用いられるクッキーに含まれることにより前記クライアントから前記受信することを特徴とする請求項１３記載の第２の認証サーバの動作方法。
15. 前記第１の認証サーバと前記第２の認証サーバとが異なるドメインに属することでクッキーに含まれる情報が該第１の認証サーバと該第２の認証サーバでやりとりできないことを特徴とする請求項１４記載の第２の認証サーバの動作方法。
16. 前記認証されていることを示す情報は、前記認証されているクライアントの情報を含むことを特徴とする請求項１３記載の第２の認証サーバの動作方法。
17. 前記クライアントの情報は、クライアントを使用しているユーザの識別子を含むことを特徴とする請求項１６記載の第２の認証サーバの動作方法。

Images