(57)【要約】【課題】整合性のあるＩＰアドレス制限を実現すると共に無駄な処理を防止することを目的とする。【解決手段】認証メッセージをクライアント装置より受信する受信手段と、認証メッセージに基づいてシングルサインオンであると判定された場合、ＩＰアドレスの制限処理を省略し、認証メッセージに基づいてシングルサインオンでないと判定された場合、ＩＰアドレスの制限処理を実行する制御手段と、を有することによって課題を解決する。【選択図】図６
2018018157.tif 000002
【特許請求の範囲】
【請求項１】
認証メッセージをクライアント装置より受信する受信手段と、
前記認証メッセージに基づいてシングルサインオンであると判定された場合、ＩＰアドレスの制限処理を省略し、前記認証メッセージに基づいてシングルサインオンでないと判定された場合、ＩＰアドレスの制限処理を実行する制御手段と、
を有するサービスプロバイダー側の情報処理装置。
【請求項２】
前記認証メッセージに基づいてシングルサインオンであるか否かを判定する判定手段を更に有し、
前記制御手段は、前記判定手段によりシングルサインオンであると判定された場合、ＩＰアドレスの制限処理を省略し、前記判定手段によりシングルサインオンでないと判定された場合、ＩＰアドレスの制限処理を実行する請求項１記載のサービスプロバイダー側の情報処理装置。
【請求項３】
前記判定手段は、前記認証メッセージがＩＤプロバイダー側の情報処理装置で生成された認証応答メッセージである場合、シングルサインオンであると判定し、前記認証メッセージがＩＤプロバイダー側の情報処理装置で生成された認証応答メッセージでない場合、シングルサインオンでないと判定する請求項２記載のサービスプロバイダー側の情報処理装置。
【請求項４】
前記制御手段は、前記認証メッセージに基づいてシングルサインオンでないと判定された場合、ユーザーがシングルサインオン設定されているか否かに応じて、ＩＰアドレスの制御処理を変更する請求項１乃至３の何れか１項記載のサービスプロバイダー側の情報処理装置。
【請求項５】
前記制御手段は、前記ユーザーがシングルサインオン設定されている場合、デフォルトのＩＰアドレスの制御処理を実行する請求項４記載のサービスプロバイダー側の情報処理装置。
【請求項６】
サービスプロバイダー側の情報処理装置が実行する情報処理方法であって、
認証メッセージをクライアント装置より受信する受信ステップと、
前記認証メッセージに基づいてシングルサインオンであると判定された場合、ＩＰアドレスの制限処理を省略し、前記認証メッセージに基づいてシングルサインオンでないと判定された場合、ＩＰアドレスの制限処理を実行する制御ステップと、
を含む情報処理方法。
【請求項７】
前記認証メッセージに基づいてシングルサインオンであるか否かを判定する判定ステップを更に含み、
前記制御ステップでは、前記判定ステップによりシングルサインオンであると判定された場合、ＩＰアドレスの制限処理を省略し、前記判定ステップによりシングルサインオンでないと判定された場合、ＩＰアドレスの制限処理を実行する請求項６記載の情報処理方法。
【請求項８】
前記判定ステップでは、前記認証メッセージがＩＤプロバイダー側の情報処理装置で生成された認証応答メッセージである場合、シングルサインオンであると判定し、前記認証メッセージがＩＤプロバイダー側の情報処理装置で生成された認証応答メッセージでない場合、シングルサインオンでないと判定する請求項７記載の情報処理方法。
【請求項９】
前記制御ステップでは、前記認証メッセージに基づいてシングルサインオンでないと判定された場合、ユーザーがシングルサインオン設定されているか否かに応じて、ＩＰアドレスの制御処理を変更する請求項６乃至８の何れか１項記載の情報処理方法。
【請求項１０】
前記制御ステップでは、前記ユーザーがシングルサインオン設定されている場合、デフォルトのＩＰアドレスの制御処理を実行する請求項９記載の情報処理方法。
【請求項１１】
コンピュータを、請求項１乃至５の何れか１項記載のサービスプロバイダー側の情報処理装置の各手段として機能させるためのプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、サービスプロバイダー側の情報処理装置、情報処理方法及びプログラムに関する。
【背景技術】
【０００２】
現在ＷｅｂブラウザーからＲＥＳＴを用いたＡＰＩアクセスでクラウドサービスを利用する形態がデファクトスタンダードになりつつある。この背景としては、モバイルの普及やブラウザーＯＳの登場といったトレンドが影響している。
ビジネス利用のクラウドサービスの場合、社内アクセスは可だが社外からのアクセスは禁止したい、要望がある。この場合、ＩＰアドレスによるアクセス禁止手段が考えられる。従来、ネットワークアクセスに対するシングルサインオン（ＳＳＯ）を確立すると共に、ネットワークにおけるアクセス制限を行うが提案されている（特許文献１）。シングルサインオンの際のＩＰアドレスによるアクセス制限方法では、ＩＤプロバイダー（ＩｄＰ）とサービスプロバイダー（ＳＰ）との両者でＩＰアドレスによるアクセス制限をした際の一貫したアクセス制限の挙動を可能にする。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開２００８−２１９２６６号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
シングルサインオン（ＳＳＯ）設定を行い、ＩＤプロバイダー（ＩｄＰ）側のＩＰアドレス制限が掛かっている場合に、サービスプロバイダー（ＳＰ）側でもＩＰアドレス制限をしたとする。この場合、ＳＳＯ時に２回、ＩＰアドレス制限のチェックが必要になる。
本発明は、整合性のあるＩＰアドレス制限を実現すると共に無駄な処理を防止することを目的とする。
【課題を解決するための手段】
【０００５】
本発明のサービスプロバイダー側の情報処理装置は、認証メッセージをクライアント装置より受信する受信手段と、前記認証メッセージに基づいてシングルサインオンであると判定された場合、ＩＰアドレスの制限処理を省略し、前記認証メッセージに基づいてシングルサインオンでないと判定された場合、ＩＰアドレスの制限処理を実行する制御手段と、を有する。
【発明の効果】
【０００６】
本発明によれば、整合性のあるＩＰアドレス制限を実現すると共に無駄な処理を防止することができる。
【図面の簡単な説明】
【０００７】
【図１】ＳＳＯシステムのシステム構成の一例を示す図である。
【図２】クライアントＰＣのハードウェア構成の一例を示す図である。
【図３】ソフトウェア構成の一例を示す図である。
【図４】ＳＳＯの際の情報処理の一例を示すシーケンス図である。
【図５】ＩｄＰ側ログイン処理の一例を示すフローチャートである。
【図６】実施形態１のＳＰ側ログイン処理の一例を示すフローチャートである。
【図７】ログインシーケンス図である。
【図８】実施形態２のＳＰ側ログイン処理の一例を示すフローチャートである。
【発明を実施するための形態】
【０００８】
以下、本発明の実施形態について図面に基づいて説明する。
以下に示す実施形態のシングルサインオンシステムは、ＳＡＭＬ２．０仕様に従ったシングルサインオン（以下、ＳＳＯという）設定を行い、ＳＳＯを行う。この際、ＩＤプロバイダー（以下、ＩｄＰという）においては、アクセス元ＩＰアドレスを判定してＩＰアドレスによるアクセス制限を行うことができる。また同様に、本実施形態のサービスプロバイダー（以下、ＳＰという）においてもＩｄＰと同様のアクセス元ＩＰアドレス判定によるアクセス制限を行うことができる。
ところが、もしＩＰアドレス制限の設定がＩｄＰ側とＳＰ側とで各々異なる場合、即ちＳＳＯ設定を行っているユーザーが、ＩｄＰ側とＳＰ側とで異なるＩＰアドレスの制限をかけた場合、使用者が混乱する可能性がある。例えば、ＳＰでＩＰアドレス制限をかけてＩｄＰでＩＰアドレス制限をかけていない場合、ＩｄＰの認証は成功したにもかからず、ＳＳＯの過程においてＳＰでＩＰアドレス制限されてしまうことになる。また逆に、ＩｄＰでＩＰアドレス制限をかけてＳＰで制限をかけていない場合、以下のような問題が生じ得る。即ち、直接、ＳＰにログインした際のサービス利用は制限されなくてもＷｅｂブラウザー等でログイン（ＳＳＯ）してからＳＰを利用しようとすると、ＩｄＰの認証時点でＩＰアドレス制限にかかってしまう問題である。
このように、ＳＳＯ時にＩｄＰ及びＳＰで個別にＩＰアドレス制限が可能であるようなＳＳＯシステムにおいて、ＩｄＰ側とＳＰ側とで各々異なるＩＰアドレス制限を行うと、利用者から見てＩＰアドレス制限について一貫した挙動を示さない場合がある。
以下に示す実施形態のＳＳＯシステムは、ＩｄＰ及びＳＰで個別にＩＰアドレス制限をした場合、利用者から見てＳＳＯ時のＩＰアドレス制限について一貫した挙動をする。
【０００９】
図１は、ＳＳＯシステムのシステム構成の一例を示す図である。
ＷＡＮ１００は、Ｗｉｄｅ  Ａｒｅａ  Ｎｅｔｗｏｒｋであり、本明細書ではＷｏｒｌｄ  Ｗｉｄｅ  Ｗｅｂ（ＷＷＷ）システムが構築されている。ＬＡＮ１０１、１０２、１０３は、各構成要素を接続するＬｏｃａｌ  Ａｒｅａ  Ｎｅｔｗｏｒｋである。
クライアントＰＣ２００は、ユーザーが操作するクライアントＰＣである。またＩＤプロバイダー３００は、ＳＳＯのユーザー認証処理を行うＩＤプロバイダーである。更にサービスプロバイダー４００は、ＳＳＯ等でログインした−ユーザーにサービスを提供するサービスプロバイダーである。サービスプロバイダー４００は、例えば、クラウド上で帳票作成サービスや印刷データ生成サービスを行う。なお、ＩＤプロバイダー３００は、ＩＤプロバイダー側の情報処理装置の一例である。また、サービスプロバイダー４００は、サービスプロバイダー側の情報処理装置の一例である。
またクライアントＰＣ２００、ＩＤプロバイダー３００、サービスプロバイダー４００はそれぞれＷＡＮ１００及びＬＡＮ１０１、ＬＡＮ１０２、ＬＡＮ１０３を介して接続されている。クライアントＰＣ２００及びＩＤプロバイダー３００のＩＤ認証サービスやサービスプロバイダー４００の帳票生成や印刷データ生成サービス等のそれぞれのサービスはそれぞれ個別のＬＡＮ上に構成されていてもよいし同一のＬＡＮ上に構成されていてもよい。また、同一のＰＣ上に構成されていてもよい。
ＩＤプロバイダー３００とサービスプロバイダー４００とは、Ｓｅｃｕｒｉｔｙ  Ａｓｓｅｒｔｉｏｎ  Ｍａｒｋｕｐ  Ｌａｎｇｕａｇｅ  ２．０  （ＳＡＭＬ  ２．０）仕様に従うシングルサインオン動作を行う。ＳＡＭＬとは、非営利国際コンソーシアムＯＡＳＩＳで策定されたインターネット上でＩＤやパスワード等を交換するためのＸＭＬ仕様である。ＯＡＳＩＳは、Ｏｒｇａｎｉｚａｔｉｏｎ  ｆｏｒ  ｔｈｅ  Ａｄｖａｎｃｅｍｅｎｔ  ｏｆ  Ｓｔｒｕｃｔｕｒｅｄ  Ｉｎｆｏｒｍａｔｉｏｎ  Ｓｔａｎｄａｒｄｓの略である。
本実施形態においては、ＩＤプロバイダー３００とサービスプロバイダー４００との両者で、各々のサーバへのログイン、シングルサインオン時のアクセス元ＩＰアドレスによるサーバへのアクセス制限機能を有する。またサービスプロバイダー４００は、ＳＳＯ以外にサービスプロバイダー４００への直接のログイン機能を有している。
【００１０】
図２は、クライアントＰＣ２００のハードウェア構成の一例を示す図である。ＩＤプロバイダー３００、サービスプロバイダー４００のサーバコンピューターのハードウェア構成も同様である。図２に示されるハードウェア構成は一般的な情報処理装置のハードウェア構成に相当するものとし、本実施形態のクライアントＰＣ２００及びサーバコンピューターには一般的な情報処理装置のハードウェア構成を適用できる。
ＣＰＵ２０１は、ＲＯＭ２０３のプログラム用ＲＯＭに記憶された、又はハードディスク２１１からＲＡＭ２０２にロードされたＯＳやアプリケーション等のプログラムを実行する。ここでＯＳとはコンピュータ上で稼動するオペレーティングシステムの略語であり、以下オペレーティングシステムのことをＯＳという。ＣＰＵ２０１が、プログラムに基づき処理を実行することにより、クライアントＰＣ２００のソフトウェア構成及び後述する図４、図７のシーケンス図のクライアントＰＣ２００の処理が実現される。キーボードコントローラ（ＫＢＣ）２０５は、キーボード（ＫＢ）２０９やポインティングデバイスからのキー入力を制御する。ＣＲＴコントローラ（ＣＲＴＣ）２０６は、ＣＲＴディスプレイ２０８の表示を制御する。ディスクコントローラ（ＤＫＣ）２０７は各種データを記憶するハードディスク（ＨＤ）２１１やフレキシブルディスク（ＦＤ）等におけるデータアクセスを制御する。ＮＣ２１２は、ネットワークに接続されて、ネットワークに接続された他の機器との通信制御処理を実行する。
【００１１】
ＩＤプロバイダー３００のＣＰＵがＩＤプロバイダーのハードディスク等に記憶されたプログラムに基づき処理を実行することにより、ＩＤプロバイダー３００のソフトウェア構成及び後述する図４のシーケンス図のＩＤプロバイダー３００の処理が実現される。また、ＩＤプロバイダー３００のＣＰＵがＩＤプロバイダーのハードディスク等に記憶されたプログラムに基づき処理を実行することにより、後述する図５のフローチャートの処理が実現される。
また、サービスプロバイダー４００のＣＰＵがサービスプロバイダー４００のハードディスク等に記憶されたプログラムに基づき処理を実行することにより、サービスプロバイダー４００のソフトウェア構成が実現される。また、サービスプロバイダー４００のＣＰＵがサービスプロバイダー４００のハードディスク等に記憶されたプログラムに基づき処理を実行することにより、後述する図４、図７のシーケンス図のサービスプロバイダー４００の処理が実現される。また、サービスプロバイダー４００のＣＰＵがサービスプロバイダー４００のハードディスク等に記憶されたプログラムに基づき処理を実行することにより、後述する図６、図８のフローチャートの処理が実現される。
【００１２】
図３は、クライアントＰＣ２００、ＩＤプロバイダー３００、サービスプロバイダー４００の、それぞれのソフトウェア構成の一例を示す図である。
ＯＳ２１０は、一般的にはリアルタイムＯＳであってもよいし、Ｌｉｎｕｘ（登録商標）等の汎用ＯＳであってもよい。更に、クライアントＰＣ２００は、ＷＷＷを利用するためのユーザーエージェントであるＷｅｂブラウザー２２０を備える。また、クライアントＰＣ２００は、Ｗｅｂブラウザー２２０を介さずにＨＴＴＰプロトコルを用いたＷｅｂ  ＡＰＩサーバを利用するＷｅｂ  ＡＰＩ  クライアント２３０を備える。更に、クライアントＰＣ２００は、Ｗｅｂ  ＡＰＩを利用するアプリケーションであるアプリケーションクライアント２４０を備える。アプリケーションクライアント２４０は、例えば後述するサービスプロバイダー４００の提供する帳票生成や印刷データ生成の機能をＷｅｂ  ＡＰＩで提供するＷｅｂ  ＡＰＩサービスを利用するアプリケーションである。
【００１３】
ＩＤプロバイダー３００は、クライアントＰＣ２００と同様のＯＳ３１０を持つ。更にＩＤプロバイダー３００は、Ｗｅｂ  ＡＰＩサーバ３２０を持つ。Ｗｅｂ  ＡＰＩサーバ３２０は、後述するクライアントＰＣ２００からリダイレクトされたＳＳＯ要求を受け付ける。ＩＤプロバイダー３００は、ＳＳＯ要求やユーザー認証を行う認証モジュール３３０を持ち、更に認証モジュール３３０が利用する認証関連情報を保持するデータベース（ＤＢ）モジュール３４０を持つ。また、ＩＤプロバイダー３００は、Ｗｅｂ  ＡＰＩサーバ３２０、認証モジュール３３０、ＤＢモジュール３４０を利用してＩＤプロバイダー３００のユーザーによるログインを受け付け、ＳＳＯ設定、管理を行うＳＳＯ管理モジュール３５０を持つ。
【００１４】
サービスプロバイダー４００は、クライアントＰＣ２００と同様のＯＳ４１０を持つ。更にサービスプロバイダー４００は、Ｗｅｂ  ＡＰＩサーバ４２０を持つ。Ｗｅｂ  ＡＰＩサーバ４２０は、後述するクライアントＰＣ２００からのＳＳＯ要求やサービス要求を受け付ける。サービスプロバイダー４００は、ＳＳＯ要求やユーザー認証を行う認証モジュール４３０を持ち、更に認証モジュール４３０が利用する認証関連情報を保持するデータベース（ＤＢ）モジュール４４０を持つ。また、サービスプロバイダー４００は、Ｗｅｂ  ＡＰＩサーバ４２０、認証モジュール４３０、ＤＢモジュール４４０を利用してサービスプロバイダー４００のユーザーによるログインを受け付け、ＳＳＯ設定、管理を行うＳＳＯ管理モジュール４５０を持つ。更にサービスプロバイダー４００は、アプリケーション機能を実現するモジュールであるアプリケーションサーバ４６０を持つ。アプリケーションサーバ４６０は、例えば、ＯＡｕｔｈ認証ライブラリ、帳票フォーマット作成ライブラリ、印刷データ変換アプリケーション等である。
【００１５】
＜実施形態１＞
［ＩｄＰ、ＳＰ両者にＩＰアドレス制限がある場合のＳＳＯの際にＳＰ側のＩＰアドレス制限を省略する］
図４は、ＳＳＯの際の情報処理の一例を示すシーケンス図である。本実施形態のＳＳＯシーケンスは基本的にＳＡＭＬ２．０仕様に従い、認証のシーケンスがＳＰへのアクセスから始まるＳＰ  ｉｎｉｔｉａｔｅｄなＳＳＯシーケンスである。また通信方式は、ＳＡＭＬメッセージをＨＴＴＰプロトコルにマッピングするＨＴＴＰバインディングを用いる。但し、本実施形態においては、ＩｄＰ側とＳＰ側との両者で、アクセスユーザーのアクセス元ＩＰアドレスを判定し、予め登録されているアクセス許可ＩＰアドレス以外からのアクセスを拒否する機能を有する。
［ＳＳＯにおけるＩｄＰとＳＰとの信頼関係の構築］
図４のＳＳＯシーケンスが始まる以前に、ＳＡＭＬ２．０仕様準拠に必要なＩｄＰ側及びＳＰ側の準備（信頼関係の構築）ができているものとする。即ち、ＳＰが信頼するＩｄＰの登録と、ＩｄＰが信頼するＳＰの登録と、を各々行っているものとする。より具体的には以下のように登録を行う。
［ＩｄＰ側：信頼するＳＰの登録］
ＩｄＰ側の信頼するＳＰの登録とは、ＩｄＰのユーザーがＩｄＰにログインし、ＩｄＰのＳＳＯ管理モジュール３５０のＳＳＯ管理機能を用いて信頼するＳＰの情報（ＳＰメタデータ）を登録することである。ＩｄＰのＳＳＯ管理モジュール３５０は、ユーザーに紐付けてＳＰメタデータ情報及び秘密鍵をＤＢモジュール３４０に保持する。
ＩｄＰ側に登録する主な情報は、以下のようなものである。
・ＳＰが認証応答メッセージを受け取るエンドポイントのＵＲＬ
・ＳＳＯユーザー毎の、認証応答メッセージの署名に使用するＩｄＰ秘密鍵
本実施形態においてはＳＳＯを行うユーザーが情報を、ＳＳＯ管理モジュール３５０を用いて以下の表１のようなメタデータとしてＩｄＰ側に登録する。
【００１６】
（表１：ＩｄＰに登録するＳＰメタデータ）
「
＜ｍｄ：ＥｎｔｉｔｙＤｅｓｃｒｉｐｔｏｒ  ｅｎｔｉｔｙＩＤ＝"ｈｔｔｐｓ：／／ｓｐ．ｅｘａｍｐｌｅ．ｃｏｍ"＞
＜ｍｄ：ＳＰＳＳＯＤｅｓｃｒｉｐｔｏｒ  ｐｒｏｔｏｃｏｌＳｕｐｐｏｒｔＥｎｕｍｅｒａｔｉｏｎ＝"ｕｒｎ：ｏａｓｉｓ：ｎａｍｅｓ：ｔｃ：ＳＡＭＬ：２．０：ｐｒｏｔｏｃｏｌ"＞
＜ｍｄ：ＮａｍｅＩＤＦｏｒｍａｔ＞
ｕｒｎ：ｏａｓｉｓ：ｎａｍｅｓ：ｔｃ：ＳＡＭＬ：１．１：ｎａｍｅｉｄ−ｆｏｒｍａｔ：ｕｎｓｐｅｃｉｆｉｅｄ
＜／ｍｄ：ＮａｍｅＩＤＦｏｒｍａｔ＞
＜ｍｄ：ＡｓｓｅｒｔｉｏｎＣｏｎｓｕｍｅｒＳｅｒｖｉｃｅ  Ｂｉｎｄｉｎｇ＝"ｕｒｎ：ｏａｓｉｓ：ｎａｍｅｓ：ｔｃ：ＳＡＭＬ：２．０：ｂｉｎｄｉｎｇｓ：ＨＴＴＰ−ＰＯＳＴ"  Ｌｏｃａｔｉｏｎ＝"ｈｔｔｐｓ：／／ｓｐ．ｅｘａｍｐｌｅ．ｃｏｍ／ｅｎｄｐ／ｓａｍｌ／ａｃｓ"  ｉｎｄｅｘ＝"０"／＞
＜／ｍｄ：ＳＰＳＳＯＤｅｓｃｒｉｐｔｏｒ＞
＜／ｍｄ：ＥｎｔｉｔｙＤｅｓｃｒｉｐｔｏｒ＞
」
【００１７】
表１のＳＰメタデータは、ＳＰが認証応答メッセージを受け取るエンドポイントのＵＲＬであるＡｓｓｅｒｔｉｏｎＣｏｎｓｕｍｅｒＳｅｒｖｉｃｅのＨＴＴＰ−ＰＯＳＴ（＜ｍｄ：ＡｓｓｅｒｔｉｏｎＣｏｎｓｕｍｅｒＳｅｒｖｉｃｅ  Ｂｉｎｄｉｎｇ＝"ｕｒｎ：ｏａｓｉｓ：ｎａｍｅｓ：ｔｃ：ＳＡＭＬ：２．０：ｂｉｎｄｉｎｇｓ：ＨＴＴＰ−ＰＯＳＴ"  Ｌｏｃａｔｉｏｎ＝"ｈｔｔｐｓ：／／ｓｐ．ｅｘａｍｐｌｅ．ｃｏｍ／ｅｎｄｐ／ｓａｍｌ／ａｃｓ"  ｉｎｄｅｘ＝"０"／＞）を含む。
またＳＳＯ管理モジュール３５０は、ＳＰメタデータ登録の際にＳＳＯユーザー毎の、認証応答メッセージの署名に使用するＩｄＰ秘密鍵と、ＩｄＰ秘密鍵に対応して後述する認証応答メッセージの署名を検証するための公開鍵と、を生成する。
ＩｄＰのＳＳＯ管理モジュール３５０は、表１のＳＰメタデータ、及び認証応答メッセージの署名に使用するＩｄＰ秘密鍵を、ＳＳＯユーザーに紐付けて、ＤＢモジュール３４０に保持する。
ＩｄＰ側にＳＳＯ設定を行うユーザーが表１のＳＰメタデータをＩｄＰに登録する際、ＩｄＰのＳＳＯ管理モジュール３５０は、ＳＰ側に信頼するＩｄＰとして登録するための、自身のＩｄＰメタデータを出力する。ＳＰ側に信頼するＩｄＰを設定するユーザーは、ＩｄＰメタデータ（詳細は後述）をＳＰ側に登録する。
【００１８】
［ＳＰ側：信頼するＩｄＰの登録］
ＳＰ側の信頼するＩｄＰの登録とは、ＳＰのユーザーがＳＰにログインし、ＳＰのＳＳＯ管理モジュール４５０のＳＳＯ管理機能を用いて信頼するＩｄＰの情報を登録することである。ＳＰのＳＳＯ管理モジュール４５０は、ユーザーに紐付けてＩｄＰメタデータ情報及び秘密鍵をＤＢモジュール４４０に保持する。
ＳＰに登録する主な情報は以下のようなものである。
・ＩｄＰが認証要求を受け付けるＵＲＬ
・ＩｄＰの公開鍵（ＩｄＰからの認証応答に含まれる、ＩｄＰ秘密鍵による署名検証用）
本実施形態においては、ＳＳＯを行うユーザーが情報を以下の表２のようなＩｄＰメタデータとしてＳＰ側に登録する。
【００１９】
（表２：ＳＰに登録するＩｄＰメタデータ）
「
＜ｍｄ：ＥｎｔｉｔｙＤｅｓｃｒｉｐｔｏｒ  ｘｍｌｎｓ：ｍｄ＝"ｕｒｎ：ｏａｓｉｓ：ｎａｍｅｓ：ｔｃ：ＳＡＭＬ：２．０：ｍｅｔａｄａｔａ"  ｘｍｌｎｓ：ｄｓ＝"ｈｔｔｐ：／／ｗｗｗ．ｗ３．ｏｒｇ／２０００／０９／ｘｍｌｄｓｉｇ＃"  ｅｎｔｉｔｙＩＤ＝"ｈｔｔｐｓ：／／ｍａｔｓｕｇａ−ｄｅｖｅｌｏｐｅｒ−ｅｄｉｔｉｏｎ．ｍｙ．ｓａｌｅｓｆｏｒｃｅ．ｃｏｍ"ｖａｌｉｄＵｎｔｉｌ＝"２０２５−０４−０２Ｔ０５：４６：２３．３１１Ｚ"＞
＜ｍｄ：ＩＤＰＳＳＯＤｅｓｃｒｉｐｔｏｒ  ｐｒｏｔｏｃｏｌＳｕｐｐｏｒｔＥｎｕｍｅｒａｔｉｏｎ＝"ｕｒｎ：ｏａｓｉｓ：ｎａｍｅｓ：ｔｃ：ＳＡＭＬ：２．０：ｐｒｏｔｏｃｏｌ"＞
＜ｍｄ：ＫｅｙＤｅｓｃｒｉｐｔｏｒ  ｕｓｅ＝"ｓｉｇｎｉｎｇ"＞
＜ｄｓ：ＫｅｙＩｎｆｏ＞
＜ｄｓ：Ｘ５０９Ｄａｔａ＞
＜ｄｓ：Ｘ５０９Ｃｅｒｔｉｆｉｃａｔｅ＞
ＭＩＩＥＸｊＣＣＡ０ａｇＡｗＩＢＡｇＩＯＡＵＪＥ１ｆｎＣＡＡＡＡＡＧＸａｓｙＩｗＤＱＹＪＫｏＺＩｈｖｃＮＡＱＥＦＢＱＡｗｅＤ
：
２ｋＹＬＦＩＭ７ｓ３Ｓｓ／ｄ＋ＵＶ７ＭｈｇＦｍＴＰ＋ＬｕＣｊＳＳＵｖｋ２ＥＱｄＺ８６Ｇｘ５ＡＬｔ４＋ｌｋＢｗＢＫｑＣＶｔｕ
＜／ｄｓ：Ｘ５０９Ｃｅｒｔｉｆｉｃａｔｅ＞
＜／ｄｓ：Ｘ５０９Ｄａｔａ＞
＜／ｄｓ：ＫｅｙＩｎｆｏ＞
＜／ｍｄ：ＫｅｙＤｅｓｃｒｉｐｔｏｒ＞
＜ｍｄ：ＮａｍｅＩＤＦｏｒｍａｔ＞
ｕｒｎ：ｏａｓｉｓ：ｎａｍｅｓ：ｔｃ：ＳＡＭＬ：１．１：ｎａｍｅｉｄ−ｆｏｒｍａｔ：ｕｎｓｐｅｃｉｆｉｅｄ
＜／ｍｄ：ＮａｍｅＩＤＦｏｒｍａｔ＞
＜ｍｄ：ＳｉｎｇｌｅＳｉｇｎＯｎＳｅｒｖｉｃｅ  Ｂｉｎｄｉｎｇ＝"ｕｒｎ：ｏａｓｉｓ：ｎａｍｅｓ：ｔｃ：ＳＡＭＬ：２．０：ｂｉｎｄｉｎｇｓ：ＨＴＴＰ−ＰＯＳＴ"  Ｌｏｃａｔｉｏｎ＝"ｈｔｔｐｓ：／／ｉｄｐ．ｅｘａｍｐｌｅ．ｃｏｍ／ｉｄｐ／ｅｎｄｐ／ＨｔｔｐＰｏｓｔ"／＞
＜ｍｄ：ＳｉｎｇｌｅＳｉｇｎＯｎＳｅｒｖｉｃｅ  Ｂｉｎｄｉｎｇ＝"ｕｒｎ：ｏａｓｉｓ：ｎａｍｅｓ：ｔｃ：ＳＡＭＬ：２．０：ｂｉｎｄｉｎｇｓ：ＨＴＴＰ−Ｒｅｄｉｒｅｃｔ"  Ｌｏｃａｔｉｏｎ＝"ｈｔｔｐｓ：／／ｉｄｐ．ｅｘａｍｐｌｅ．ｃｏｍ／ｉｄｐ／ｅｎｄｐ／ＨｔｔｐＲｅｄｉｒｅｃｔ"／＞
＜／ｍｄ：ＩＤＰＳＳＯＤｅｓｃｒｉｐｔｏｒ＞
＜／ｍｄ：ＥｎｔｉｔｙＤｅｓｃｒｉｐｔｏｒ＞
」
【００２０】
表２のＩｄＰメタデータは、ＩｄＰが認証要求を受け付けるＵＲＬであるＳｉｎｇｌｅＳｉｇｎＯｎＳｅｒｖｉｃｅのＨＴＴＰ−ＰＯＳＴ（＜ｍｄ：ＳｉｎｇｌｅＳｉｇｎＯｎＳｅｒｖｉｃｅ  Ｂｉｎｄｉｎｇ＝"ｕｒｎ：ｏａｓｉｓ：ｎａｍｅｓ：ｔｃ：ＳＡＭＬ：２．０：ｂｉｎｄｉｎｇｓ：ＨＴＴＰ−ＰＯＳＴ"  Ｌｏｃａｔｉｏｎ＝"ｈｔｔｐｓ：／／ｉｄｐ．ｅｘａｍｐｌｅ．ｃｏｍ／ｉｄｐ／ｅｎｄｐ／ＨｔｔｐＰｏｓｔ"／＞）とＨＴＴＰ−Ｒｅｄｉｒｅｃｔ（＜ｍｄ：ＳｉｎｇｌｅＳｉｇｎＯｎＳｅｒｖｉｃｅ  Ｂｉｎｄｉｎｇ＝"ｕｒｎ：ｏａｓｉｓ：ｎａｍｅｓ：ｔｃ：ＳＡＭＬ：２．０：ｂｉｎｄｉｎｇｓ：ＨＴＴＰ−Ｒｅｄｉｒｅｃｔ"Ｌｏｃａｔｉｏｎ＝"ｈｔｔｐｓ：／／ｉｄｐ．ｅｘａｍｐｌｅ．ｃｏｍ／ｉｄｐ／ｅｎｄｐ／ＨｔｔｐＲｅｄｉｒｅｃｔ"／＞）を含む。また、ＩｄＰメタデータは、ＩｄＰの公開鍵を含むＸ．５０９形式の公開鍵証明書（＜ｄｓ：Ｘ５０９Ｃｅｒｔｉｆｉｃａｔｅ＞）を含む。なお、ＨＴＴＰ−ＰＯＳＴはＨＴＴＰプロトコルのＰＯＳＴメッセージで認証要求を受けるエンドポイントを示す。本実施形態の場合、認証要求はＰＯＳＴメッセージで行われる。またＨＴＴＰ−ＲｅｄｉｒｅｃｔはＨＴＴＰプロトコルのＧＥＴメッセージで認証要求を受けるエンドポイントを示す。もしＧＥＴメッセージで認証要求を行う場合、認証メッセージはＵＲＬのクエリーパラメーターに付与されることになる。
ＳＰのＳＳＯ管理モジュール４５０は、表２のＩｄＰメタデータを、ＳＳＯユーザーに紐付けて、ＤＢモジュール４４０に保持する。
【００２１】
［ＩＰアドレス制限の設定］
図４のＳＳＯシーケンスが始まる以前に、ＩＰアドレス制限に必要なＩｄＰ側及びＳＰ側の準備（ＩＰアドレス制限の設定）ができているものとする。即ち、ＩｄＰのユーザーによる、ＩｄＰのＳＳＯ管理モジュール３５０のＳＳＯ管理機能を用いた、ＩｄＰがユーザーに対し接続を許可するアクセス元ＩＰアドレスの登録を行っているものとする。また、ＳＰのユーザーによる、ＳＰのＳＳＯ管理モジュール４５０のＳＳＯ管理機能を用いた、ＳＰがユーザーに対し接続を許可するアクセス元ＩＰアドレスの登録を行っているものとする。より具体的には以下のように設定を行う。
【００２２】
［ＩｄＰ側：ＩＰアドレス制限の設定］
ＩｄＰ側のＩＰアドレス制限の設定とは、ＩｄＰのユーザーがＩｄＰにログインし、ＩｄＰのＳＳＯ管理モジュール３５０によりＩｄＰのＩＰアドレス制限管理機能を用いて、管理対象ユーザーに対しＩｄＰにアクセス可能なアクセス元ＩＰアドレスを登録することである。登録するＩＰアドレスは、個々のＩＰアドレスでもよいし、ＩＰアドレス範囲でもよい。
ＩｄＰのＩＰアドレス制限設定は、ＩｄＰの内部のＤＢモジュール３４０に存在する以下のようなＩＰアドレス制限設定テーブルで管理される。
（表３：ＩｄＰ側ＩＰアドレス制限設定テーブル）
「
ユーザーＩＤ：アクセス許可ＩＰアドレス
Ｕｓｅｒ０００１：１９２．１６８．＊．＊
Ｕｓｅｒ０００１：１７２．１６．０．＊  −  １７２．２０．０．＊
」
表３のＩｄＰ側ＩＰアドレス制限設定テーブルは、Ｕｓｅｒ０００１がＩｄＰにアクセスする際、アクセス元ＩＰアドレスとして１９２．１６８．０．０／１６の範囲と１７２．１６．０．０から１７２．２０．０．２５５までのＩＰアドレス範囲とを許可する。
【００２３】
［ＳＰ側：ＩＰアドレス制限の設定］
ＳＰ側のＩＰアドレス制限の設定とは、ＳＰのユーザーがＳＰにログインし、ＳＰのＳＳＯ管理モジュール４５０によりＳＰのＩＰアドレス制限管理機能を用いて、管理対象ユーザーに対しＳＰにアクセス可能なアクセス元ＩＰアドレスを登録することである。登録するＩＰアドレスは、個々のＩＰアドレスでもよいし、ＩＰアドレス範囲でもよい。
ＳＰのＩＰアドレス制限設定は、ＳＰの内部のＤＢモジュール４４０に存在する以下のようなＩＰアドレス制限設定テーブルで管理される。
（表４：ＳＰ側ＩＰアドレス制限設定テーブル）
「
ユーザーＩＤ：アクセス許可ＩＰアドレス
Ｕｓｅｒ０００１：１９２．１６８．＊．＊
Ｕｓｅｒ０００１：１７２．１６．０．＊  −  １７２．２０．０．＊
」
表４のＳＰ側ＩＰアドレス制限設定テーブルは、Ｕｓｅｒ０００１がＳＰにアクセスする際、アクセス元ＩＰアドレスとして１９２．１６８．０．０／１６の範囲と、１７２．１６．０．０から１７２．２０．０．２５５までのＩＰアドレス範囲と、を許可する。
上述した［ＳＳＯにおけるＩｄＰとＳＰとの信頼関係の構築］と［ＩＰアドレス制限の設定］とが完了した上で、図４のＳＳＯシーケンスの情報処理が開始可能になる。
【００２４】
図４の本実施形態のＳＳＯシーケンスは、以下のことより始まる。即ち、ユーザーの操作に基づき、クライアントＰＣ２００上のＷｅｂブラウザー２２０は、サービスプロバイダー４００のアプリケーションサーバ４６０を利用するために、サービスプロバイダー４００のＵＲＬにアクセスする（Ｓ４．１）。ＵＲＬは、以下のようなものである。
（表５：ＲｅｌａｙＳｔａｔｅ  ＵＲＬ）
「
ｈｔｔｐｓ：／／ａｐｐｌｉｃａｔｉｏｎ．ｓｐ．ｅｘａｍｐｌｅ．ｃｏｍ／ｐｏｒｔａｌ．ｈｔｍｌ
」
【００２５】
今、ユーザーはＳＳＯ設定されており、かつ、未ログイン状態にあるため、サービスプロバイダー４００のＳＳＯ管理モジュール４５０は、認証要求メッセージ（ＳＡＭＬ  Ｒｅｑｕｅｓｔ）及びリダイレクト用ＨＴＭＬを生成する（Ｓ４．２）。認証要求メッセージは以下の表６のようなものである。
（表６：認証要求メッセージ（ＳＡＭＬ  Ｒｅｑｕｅｓｓｔ））
「
＜ｓａｍｌｐ：ＡｕｔｈｎＲｅｑｕｅｓｔ  ｘｍｌｎｓ：ｓａｍｌｐ＝"ｕｒｎ：ｏａｓｉｓ：ｎａｍｅｓ：ｔｃ：ＳＡＭＬ：２．０：ｐｒｏｔｏｃｏｌ"  ｘｍｌｎｓ：ｓａｍｌ＝"ｕｒｎ：ｏａｓｉｓ：ｎａｍｅｓ：ｔｃ：ＳＡＭＬ：２．０：ａｓｓｅｒｔｉｏｎ"  ＩＤ＝"ｐｆｘ４１ｄ８ｅｆ２２−ｅ６１２−８ｃ５０−９９６０−１ｂ１６ｆ１５７４１ｂ３"  Ｖｅｒｓｉｏｎ＝"２．０"  ＰｒｏｖｉｄｅｒＮａｍｅ＝"ＳＰ  ｔｅｓｔ"  ＩｓｓｕｅＩｎｓｔａｎｔ＝"２０１６−０７−１６Ｔ２３：５２：４５Ｚ"  Ｄｅｓｔｉｎａｔｉｏｎ＝"ｈｔｔｐ：／／ｉｄｐ．ｅｘａｍｐｌｅ．ｃｏｍ／ＳＳＯＳｅｒｖｉｃｅ．ｐｈｐ"  ＰｒｏｔｏｃｏｌＢｉｎｄｉｎｇ＝"ｕｒｎ：ｏａｓｉｓ：ｎａｍｅｓ：ｔｃ：ＳＡＭＬ：２．０：ｂｉｎｄｉｎｇｓ：ＨＴＴＰ−ＰＯＳＴ"  ＡｓｓｅｒｔｉｏｎＣｏｎｓｕｍｅｒＳｅｒｖｉｃｅＵＲＬ＝"ｈｔｔｐ：／／ｓｐ．ｅｘａｍｐｌｅ．ｃｏｍ／ｄｅｍｏ１／ｉｎｄｅｘ．ｐｈｐ？ａｃｓ"＞
＜ｓａｍｌ：Ｉｓｓｕｅｒ＞ｈｔｔｐ：／／ｓｐ．ｅｘａｍｐｌｅ．ｃｏｍ／ｄｅｍｏ１／ｍｅｔａｄａｔａ．ｐｈｐ＜／ｓａｍｌ：Ｉｓｓｕｅｒ＞
＜ｄｓ：Ｓｉｇｎａｔｕｒｅ  ｘｍｌｎｓ：ｄｓ＝"ｈｔｔｐ：／／ｗｗｗ．ｗ３．ｏｒｇ／２０００／０９／ｘｍｌｄｓｉｇ＃"＞
＜ｄｓ：ＳｉｇｎｅｄＩｎｆｏ＞
＜ｄｓ：ＣａｎｏｎｉｃａｌｉｚａｔｉｏｎＭｅｔｈｏｄ  Ａｌｇｏｒｉｔｈｍ＝"ｈｔｔｐ：／／ｗｗｗ．ｗ３．ｏｒｇ／２００１／１０／ｘｍｌ−ｅｘｃ−ｃ１４ｎ＃"／＞
＜ｄｓ：ＳｉｇｎａｔｕｒｅＭｅｔｈｏｄ  Ａｌｇｏｒｉｔｈｍ＝"ｈｔｔｐ：／／ｗｗｗ．ｗ３．ｏｒｇ／２０００／０９／ｘｍｌｄｓｉｇ＃ｒｓａ−ｓｈａ１"／＞
＜ｄｓ：Ｒｅｆｅｒｅｎｃｅ  ＵＲＩ＝"＃ｐｆｘ４１ｄ８ｅｆ２２−ｅ６１２−８ｃ５０−９９６０−１ｂ１６ｆ１５７４１ｂ３"＞
＜ｄｓ：Ｔｒａｎｓｆｏｒｍｓ＞
＜ｄｓ：Ｔｒａｎｓｆｏｒｍ  Ａｌｇｏｒｉｔｈｍ＝"ｈｔｔｐ：／／ｗｗｗ．ｗ３．ｏｒｇ／２０００／０９／ｘｍｌｄｓｉｇ＃ｅｎｖｅｌｏｐｅｄ−ｓｉｇｎａｔｕｒｅ"／＞
＜ｄｓ：Ｔｒａｎｓｆｏｒｍ  Ａｌｇｏｒｉｔｈｍ＝"ｈｔｔｐ：／／ｗｗｗ．ｗ３．ｏｒｇ／２００１／１０／ｘｍｌ−ｅｘｃ−ｃ１４ｎ＃"／＞
＜／ｄｓ：Ｔｒａｎｓｆｏｒｍｓ＞
＜ｄｓ：ＤｉｇｅｓｔＭｅｔｈｏｄ  Ａｌｇｏｒｉｔｈｍ＝"ｈｔｔｐ：／／ｗｗｗ．ｗ３．ｏｒｇ／２０００／０９／ｘｍｌｄｓｉｇ＃ｓｈａ１"／＞
＜ｄｓ：ＤｉｇｅｓｔＶａｌｕｅ＞ｙＪＮ…ＹＦＩ＝＜／ｄｓ：ＤｉｇｅｓｔＶａｌｕｅ＞
＜／ｄｓ：Ｒｅｆｅｒｅｎｃｅ＞
＜／ｄｓ：ＳｉｇｎｅｄＩｎｆｏ＞
＜ｄｓ：ＳｉｇｎａｔｕｒｅＶａｌｕｅ＞ｇ５ｅＭ９ｙＰｎＫｓｍｍ…ＹｇｍＢ３ｓｏｃＰｑＡｉ２Ｑｆ９７Ｅ＝＜／ｄｓ：ＳｉｇｎａｔｕｒｅＶａｌｕｅ＞
＜ｄｓ：ＫｅｙＩｎｆｏ＞
＜ｄｓ：Ｘ５０９Ｄａｔａ＞
＜ｄｓ：Ｘ５０９Ｃｅｒｔｉｆｉｃａｔｅ＞ＭＩＩＣａｊ…Ｈｏｐ１ｎＥｒＶ６Ｑ＝＝＜／ｄｓ：Ｘ５０９Ｃｅｒｔｉｆｉｃａｔｅ＞
＜／ｄｓ：Ｘ５０９Ｄａｔａ＞
＜／ｄｓ：ＫｅｙＩｎｆｏ＞
＜／ｄｓ：Ｓｉｇｎａｔｕｒｅ＞
＜ｓａｍｌｐ：ＮａｍｅＩＤＰｏｌｉｃｙ  Ｆｏｒｍａｔ＝"ｕｒｎ：ｏａｓｉｓ：ｎａｍｅｓ：ｔｃ：ＳＡＭＬ：１．１：ｎａｍｅｉｄ−ｆｏｒｍａｔ：ｅｍａｉｌＡｄｄｒｅｓｓ"  ＡｌｌｏｗＣｒｅａｔｅ＝"ｔｒｕｅ"／＞
＜ｓａｍｌｐ：ＲｅｑｕｅｓｔｅｄＡｕｔｈｎＣｏｎｔｅｘｔ  Ｃｏｍｐａｒｉｓｏｎ＝"ｅｘａｃｔ"＞
＜ｓａｍｌ：ＡｕｔｈｎＣｏｎｔｅｘｔＣｌａｓｓＲｅｆ＞ｕｒｎ：ｏａｓｉｓ：ｎａｍｅｓ：ｔｃ：ＳＡＭＬ：２．０：ａｃ：ｃｌａｓｓｅｓ：ＰａｓｓｗｏｒｄＰｒｏｔｅｃｔｅｄＴｒａｎｓｐｏｒｔ＜／ｓａｍｌ：ＡｕｔｈｎＣｏｎｔｅｘｔＣｌａｓｓＲｅｆ＞
＜／ｓａｍｌｐ：ＲｅｑｕｅｓｔｅｄＡｕｔｈｎＣｏｎｔｅｘｔ＞
＜／ｓａｍｌｐ：ＡｕｔｈｎＲｅｑｕｅｓｔ＞
」
【００２６】
ＳＡＭＬ  ＲｅｑｕｅｓｔはＳＡＭＬ２．０仕様に定義されている、ｅｍｂｅｄｄｅｄ  ｓｉｇｎａｔｕｒｅ付きの＜ＡｕｔｈｎＲｅｑｕｅｓｔ＞要素で表現される。また、認証要求メッセージの送信にはＨＴＴＰ  ＰＯＳＴ  Ｂｉｎｄｉｎｇが用いられる。そのため、サービスプロバイダー４００のＳＳＯ管理モジュール４５０は、生成された表５の認証要求メッセージをＢａｓｅ６４エンコードして表７の認証要求メッセージを含むリダイレクト用ＨＴＭＬを生成する（Ｓ４．２）。そして、ＳＳＯ管理モジュール４５０は、［ＳＰ側：信頼するＩｄＰの登録］で登録したＩｄＰが認証要求を受け付けるＵＲＬにリダイレクトするようにクライアントＰＣ２００に応答する（Ｓ４．３）。
（表７：認証要求メッセージを含むリダイレクト用ＨＴＭＬ）
「
＜ｈｔｍｌ＞
＜ｈｅａｄ＞
＜ｔｉｔｌｅ＞Ａｃｃｅｓｓ  ｒｉｇｈｔｓ  ｖａｌｉｄａｔｅｄ＜／ｔｉｔｌｅ＞
＜／ｈｅａｄ＞
＜ｂｏｄｙ  ｏｎｌｏａｄ＝"ｄｏｃｕｍｅｎｔ．ｆｏｒｍｓ［０］．ｓｕｂｍｉｔ（）"＞
＜ｆｏｒｍ  ｍｅｔｈｏｄ＝"ｐｏｓｔ"  ａｃｔｉｏｎ＝"ｈｔｔｐｓ＆＃ｘ３ａ；＆＃ｘ２ｆ；＆＃ｘ２ｆ；ｓｏｏａａ．ｍｙ．ｓａｌｅｓｆｏｒｃｅ．ｃｏｍ＆＃ｘ２ｆ；ｉｄｐ＆＃ｘ２ｆ；ｅｎｄｐｏｉｎｔ＆＃ｘ２ｆ；ＨｔｔｐＰｏｓｔ"＞
＜ｉｎｐｕｔ  ｔｙｐｅ＝"ｈｉｄｄｅｎ"  ｎａｍｅ＝"ＳＡＭＬＲｅｑｕｅｓｔ"  ｖａｌｕｅ＝"ＰＨＮｈｂＷｘｗＯｋＦ１ｄＧｈｕＵｍＶｘｄＷＶｚｄＣＡｇｅＧ１ｓｂｎＭ６ｃ２ＦｔｂＨＡ９ＩｎＶｙｂｊｐｖＹＸＮｐｃｚｐｕＹＷ１ｌｃｚｐ０ＹｚｐＴＱＵ１Ｍ＆＃ｘｄ；＆＃ｘａ；ＯｊＩｕＭＤｐｗｃｍ９０ｂ２ＮｖｂＣＩＫＳＵＱ９ＩｎＭｙＭ２ＶｌＭＷＥ５Ｎｊｋ１ＯＧＭ５ＺＷＮｋＯＷＺｊＹｍＱ０ＯＤＦｈＮＧＦｌＹＴＡ１ＮＴＲｈＮｊＮｊ＆＃ｘｄ；＆＃．．．．＆＃ｘ２ｂ；Ｃｊｗｖｃ２ＦｔｂＨＡ６＆＃ｘｄ；＆＃ｘａ；ＱＸＶ０ａＧ５ＳＺＸＦ１ＺＸＮ０Ｐｇ＆＃ｘ３ｄ；＆＃ｘ３ｄ；"  ／＞
＜ｉｎｐｕｔ  ｔｙｐｅ＝"ｈｉｄｄｅｎ"  ｎａｍｅ＝"ＲｅｌａｙＳｔａｔｅ"  ｖａｌｕｅ＝"ｈｔｔｐｓ：／／ａｐｐｌｉｃａｔｉｏｎ．ｓｐ．ｅｘａｍｐｌｅ．ｃｏｍ／ｐｏｒｔａｌ．ｈｔｍｌ  "  ／＞
＜ｎｏｓｃｒｉｐｔ＞
＜ｃｅｎｔｅｒ＞
＜ｉｎｐｕｔ  ｔｙｐｅ＝"ｓｕｂｍｉｔ"  ｖａｌｕｅ＝"Ｓｕｂｍｉｔ"  ／＞
＜／ｃｅｎｔｅｒ＞
＜／ｎｏｓｃｒｉｐｔ＞
＜／ｆｏｒｍ＞
＜／ｂｏｄｙ＞
＜／ｈｔｍｌ＞
」
【００２７】
表７の認証要求メッセージを含むリダイレクト用ＨＴＭＬは、ＳＳＯ後のＳＰのアクセスポイントであるＲｅｌａｙＳｔａｔｅを含む。本実施形態の場合、ＲｅｌａｙＳｔａｔｅは表５のＵＲＬになる。
表７の認証要求メッセージを含むリダイレクト用ＨＴＭＬを受け取ったクライアントＰＣ２００のＷｅｂブラウザー２２０は、以下の処理を行う。即ち、クライアントＰＣ２００のＷｅｂブラウザー２２０は、ユーザー認証のために［ＳＰ側：信頼するＩｄＰの登録］で登録したＩｄＰが認証要求を受け付けるＵＲＬが示すＩＤプロバイダー３００にリダイレクトする（Ｓ４．４）。
クライアントＰＣ２００によるリダイレクトの結果、表７の認証要求メッセージを受信したＩＤプロバイダー３００は、ユーザー名、パスワードによるユーザー認証、ＩＰアドレス制限、認証応答メッセージを生成する（Ｓ４．７）。
図５は、ＩＤプロバイダー３００のＩｄＰ側ログイン処理の一例を示すフローチャートである。以下、Ｓ４．７の処理を図５のフローチャートにより詳細に説明する。
図５のフローチャートは、ＩＤプロバイダー３００の認証モジュール３３０が、Ｗｅｂ  ＡＰＩサーバ３２０を経由して７の認証要求メッセージを受信する（Ｓ５０１）ことから始まる。認証要求メッセージを受信した認証モジュール３３０は、ユーザー認証画面を表示して、ユーザー認証画面を介して入力されたユーザー名、パスワードによるユーザー認証を行う（Ｓ５０２）。そして、認証モジュール３３０は、ログインに成功したか否かを判定する（Ｓ５０３）。もしユーザーが正常に認証されてログインに成功と判定されれば（Ｓ５０３においてＹｅｓ）、認証モジュール３３０は、更にＩＰアドレス制限処理を実施する（Ｓ５０４）。一方、ログインに失敗すれば（Ｓ５０３においてＮｏ）、認証モジュール３３０は、ログインエラーのメッセージを生成して（Ｓ５０８）、図５に示す処理を終える。ＩＰアドレス制限処理は次のように行う。即ち、ＩＤプロバイダー３００の認証モジュール３３０は、Ｓ５０１にて受信したＨＴＴＰＳプロトコルによりリダイレクトされた認証要求メッセージを含むリダイレクト用ＨＴＭＬの通信の際のＨＴＴＰヘッダーを解析する。そして、認証モジュール３３０は、Ｆｏｒｗａｒｄｅｄ（又はＸ−Ｆｏｒｗａｒｄｅｄ−Ｆｏｒ）ヘッダーフィールドを取得してアクセス元ＩＰアドレスを取得し、ＩＰアドレス制限を行う。Ｆｏｗａｒｄｅｄ（又はＸ−Ｆｏｒｗａｒｄｅｄ−Ｆｏｒ）ヘッダーフィールドは、一般的に以下のようなフォーマットである。
（表８：Ｆｏｗａｒｄｅｄ（又はＸ−Ｆｏｒｗａｒｄｅｄ−Ｆｏｒ）ヘッダーフィールドのフォーマット）
「
Ｘ−Ｆｏｒｗａｒｄｅｄ−Ｆｏｒ：ｃｌｉｅｎｔ１，ｐｒｏｘｙ１，ｐｒｏｘｙ２
」
Ｆｏｒｗａｒｄｅｄ（又はＸ−Ｆｏｒｗａｒｄｅｄ−Ｆｏｒ）ヘッダーフィールドはカンマとスペースとで区切られたＩＰアドレスの一覧である。クライアントＰＣ２００とＩＤプロバイダー３００との間にプロキシ―サーバが存在する場合、クライアントＰＣ２００のＩＰアドレスの右側に、経由してきた各々のプロキシ―サーバのＩＰアドレスが順次記録される。本実施形態においては、アクセス元ＩＰアドレスとしてＦｏｗａｒｄｅｄ（又はＸ−Ｆｏｒｗａｒｄｅｄ−Ｆｏｒ）ヘッダーフィールドの最も左のカラムにあるＩＰアドレスが用いられる。
【００２８】
認証モジュール３３０は、Ｓ５０２にて認証したユーザーのユーザーＩＤと、Ｆｏｗａｒｄｅｄ（又はＸ−Ｆｏｒｗａｒｄｅｄ−Ｆｏｒ）ヘッダーフィールドのクライアントＰＣ２００のＩＰアドレスと、を取得する。そして認証モジュール３３０は、ＤＢモジュール３４０に存在する表３のＩｄＰ側ＩＰアドレス制限設定テーブルを参照する。認証モジュール３３０は、認証したユーザーＩＤに対応する表３のユーザーＩＤの対応するアクセス許可ＩＰアドレスを取得する。そして、認証モジュール３３０は、アクセス元ＩＰアドレスが、表３のユーザーＩＤに対応する接続許可ＩＰアドレスにマッチ又はＩＰアドレス範囲に含まれているかどうか判定する（Ｓ５０５）。判定の結果、Ｆｏｒｗａｒｄｅｄ（又はＸ−Ｆｏｒｗａｒｄｅｄ−Ｆｏｒ）に含まれるアクセス元のクライアントＰＣ２００のＩＰアドレスがアクセス許可ＩＰアドレスにマッチ又はＩＰアドレス範囲に含まれていれば（Ｓ５０５においてＹｅｓ）、認証モジュール３３０は、Ｓ５０６に進む。即ち、アクセス元のクライアントＰＣ２００はアクセスが許可されたものと見做し、認証モジュール３３０は、認証応答メッセージ（ＳＡＭＬ  Ｒｅｓｐｏｎｓｅ）の生成を行う（Ｓ５０６）。もしＦｏｒｗａｒｄｅｄ（又はＸ−Ｆｏｒｗａｒｄｅｄ−Ｆｏｒ）に含まれるアクセス元のクライアントＰＣ２００のＩＰアドレスがアクセス許可ＩＰアドレスにマッチ又はＩＰアドレス範囲に含まれていなければ（Ｓ５０５においてＮｏ）、認証モジュール３３０は、ＩＰアドレス制限エラーとしてＩＰアドレス制限エラーのメッセージを生成して（Ｓ５０７）、図５に示す処理を終える。
【００２９】
Ｓ５０６にて認証モジュール３３０が生成する認証応答メッセージは以下のようなものである。
（表９：認証応答メッセージ（ＳＡＭＬ  Ｒｅｓｐｏｎｓｅ））
「
＜ｓａｍｌｐ：Ｒｅｓｐｏｎｓｅ  ｘｍｌｎｓ：ｓａｍｌｐ＝"ｕｒｎ：ｏａｓｉｓ：ｎａｍｅｓ：ｔｃ：ＳＡＭＬ：２．０：ｐｒｏｔｏｃｏｌ"  ｘｍｌｎｓ：ｓａｍｌ＝"ｕｒｎ：ｏａｓｉｓ：ｎａｍｅｓ：ｔｃ：ＳＡＭＬ：２．０：ａｓｓｅｒｔｉｏｎ"  ＩＤ＝"＿８ｅ８ｄｃ５ｆ６９ａ９８ｃｃ４ｃ１ｆｆ３４２７ｅ５ｃｅ３４６０６ｆｄ６７２ｆ９１ｅ６"  Ｖｅｒｓｉｏｎ＝"２．０"  ＩｓｓｕｅＩｎｓｔａｎｔ＝"２０１４−０７−１７Ｔ０１：０１：４８Ｚ"  Ｄｅｓｔｉｎａｔｉｏｎ＝"ｈｔｔｐ：／／ｓｐ．ｅｘａｍｐｌｅ．ｃｏｍ／ｄｅｍｏ１／ｉｎｄｅｘ．ｐｈｐ？ａｃｓ"  ＩｎＲｅｓｐｏｎｓｅＴｏ＝"ＯＮＥＬＯＧＩＮ＿４ｆｅｅ３ｂ０４６３９５ｃ４ｅ７５１０１１ｅ９７ｆ８９００ｂ５２７３ｄ５６６８５"＞
＜ｓａｍｌ：Ｉｓｓｕｅｒ＞ｈｔｔｐ：／／ｉｄｐ．ｅｘａｍｐｌｅ．ｃｏｍ／ｍｅｔａｄａｔａ．ｐｈｐ＜／ｓａｍｌ：Ｉｓｓｕｅｒ＞
＜ｓａｍｌｐ：Ｓｔａｔｕｓ＞
＜ｓａｍｌｐ：ＳｔａｔｕｓＣｏｄｅ  Ｖａｌｕｅ＝"ｕｒｎ：ｏａｓｉｓ：ｎａｍｅｓ：ｔｃ：ＳＡＭＬ：２．０：ｓｔａｔｕｓ：Ｓｕｃｃｅｓｓ"／＞
＜／ｓａｍｌｐ：Ｓｔａｔｕｓ＞
＜ｓａｍｌ：Ａｓｓｅｒｔｉｏｎ  ｘｍｌｎｓ：ｘｓｉ＝"ｈｔｔｐ：／／ｗｗｗ．ｗ３．ｏｒｇ／２００１／ＸＭＬＳｃｈｅｍａ−ｉｎｓｔａｎｃｅ"  ｘｍｌｎｓ：ｘｓ＝"ｈｔｔｐ：／／ｗｗｗ．ｗ３．ｏｒｇ／２００１／ＸＭＬＳｃｈｅｍａ"  ＩＤ＝"ｐｆｘｃｅｃｅ９ａ７５−ｆｆ７ｆ−７ｅ３ｆ−７ｆｆ１−ａａｃ９６２ｅ１０ｆ４６"  Ｖｅｒｓｉｏｎ＝"２．０"  ＩｓｓｕｅＩｎｓｔａｎｔ＝"２０１４−０７−１７Ｔ０１：０１：４８Ｚ"＞
＜ｓａｍｌ：Ｉｓｓｕｅｒ＞ｈｔｔｐ：／／ｉｄｐ．ｅｘａｍｐｌｅ．ｃｏｍ／ｍｅｔａｄａｔａ．ｐｈｐ＜／ｓａｍｌ：Ｉｓｓｕｅｒ＞＜ｄｓ：Ｓｉｇｎａｔｕｒｅ  ｘｍｌｎｓ：ｄｓ＝"ｈｔｔｐ：／／ｗｗｗ．ｗ３．ｏｒｇ／２０００／０９／ｘｍｌｄｓｉｇ＃"＞
＜ｄｓ：ＳｉｇｎｅｄＩｎｆｏ＞＜ｄｓ：ＣａｎｏｎｉｃａｌｉｚａｔｉｏｎＭｅｔｈｏｄ  Ａｌｇｏｒｉｔｈｍ＝"ｈｔｔｐ：／／ｗｗｗ．ｗ３．ｏｒｇ／２００１／１０／ｘｍｌ−ｅｘｃ−ｃ１４ｎ＃"／＞
＜ｄｓ：ＳｉｇｎａｔｕｒｅＭｅｔｈｏｄ  Ａｌｇｏｒｉｔｈｍ＝"ｈｔｔｐ：／／ｗｗｗ．ｗ３．ｏｒｇ／２０００／０９／ｘｍｌｄｓｉｇ＃ｒｓａ−ｓｈａ１"／＞
＜ｄｓ：Ｒｅｆｅｒｅｎｃｅ  ＵＲＩ＝"＃ｐｆｘｃｅｃｅ９ａ７５−ｆｆ７ｆ−７ｅ３ｆ−７ｆｆ１−ａａｃ９６２ｅ１０ｆ４６"＞＜ｄｓ：Ｔｒａｎｓｆｏｒｍｓ＞＜ｄｓ：Ｔｒａｎｓｆｏｒｍ  Ａｌｇｏｒｉｔｈｍ＝"ｈｔｔｐ：／／ｗｗｗ．ｗ３．ｏｒｇ／２０００／０９／ｘｍｌｄｓｉｇ＃ｅｎｖｅｌｏｐｅｄ−ｓｉｇｎａｔｕｒｅ"／＞＜ｄｓ：Ｔｒａｎｓｆｏｒｍ  Ａｌｇｏｒｉｔｈｍ＝"ｈｔｔｐ：／／ｗｗｗ．ｗ３．ｏｒｇ／２００１／１０／ｘｍｌ−ｅｘｃ−ｃ１４ｎ＃"／＞＜／ｄｓ：Ｔｒａｎｓｆｏｒｍｓ＞＜ｄｓ：ＤｉｇｅｓｔＭｅｔｈｏｄ  Ａｌｇｏｒｉｔｈｍ＝"ｈｔｔｐ：／／ｗｗｗ．ｗ３．ｏｒｇ／２０００／０９／ｘｍｌｄｓｉｇ＃ｓｈａ１"／＞＜ｄｓ：ＤｉｇｅｓｔＶａｌｕｅ＞ｚＶ９Ｒ…ｈ７ＥＩｌＪｊｌＤｑｇ＝＜／ｄｓ：ＤｉｇｅｓｔＶａｌｕｅ＞＜／ｄｓ：Ｒｅｆｅｒｅｎｃｅ＞＜／ｄｓ：ＳｉｇｎｅｄＩｎｆｏ＞＜ｄｓ：ＳｉｇｎａｔｕｒｅＶａｌｕｅ＞ＷｗｗｓＶｉＸｖＣ７…ｑｘ＋ＦＲＪＹＺｎＡＹ＝＜／ｄｓ：ＳｉｇｎａｔｕｒｅＶａｌｕｅ＞
＜ｄｓ：ＫｅｙＩｎｆｏ＞＜ｄｓ：Ｘ５０９Ｄａｔａ＞＜ｄｓ：Ｘ５０９Ｃｅｒｔｉｆｉｃａｔｅ＞ＭＩＩＣａｊＣＣＡｄＯｇＡ…ＹＺＧｙｃ４ＬｚｇＤ０ＣＲＯＭＡＳＴＷＮｇ＝＝＜／ｄｓ：Ｘ５０９Ｃｅｒｔｉｆｉｃａｔｅ＞＜／ｄｓ：Ｘ５０９Ｄａｔａ＞＜／ｄｓ：ＫｅｙＩｎｆｏ＞＜／ｄｓ：Ｓｉｇｎａｔｕｒｅ＞
＜ｓａｍｌ：Ｓｕｂｊｅｃｔ＞
＜ｓａｍｌ：ＮａｍｅＩＤ  ＳＰＮａｍｅＱｕａｌｉｆｉｅｒ＝"ｈｔｔｐ：／／ｓｐ．ｅｘａｍｐｌｅ．ｃｏｍ／ｄｅｍｏ１／ｍｅｔａｄａｔａ．ｐｈｐ"  Ｆｏｒｍａｔ＝"ｕｒｎ：ｏａｓｉｓ：ｎａｍｅｓ：ｔｃ：ＳＡＭＬ：２．０：ｎａｍｅｉｄ−ｆｏｒｍａｔ：ｔｒａｎｓｉｅｎｔ"＞Ｕｓｅｒ０００１＜／ｓａｍｌ：ＮａｍｅＩＤ＞
＜ｓａｍｌ：ＳｕｂｊｅｃｔＣｏｎｆｉｒｍａｔｉｏｎ  Ｍｅｔｈｏｄ＝"ｕｒｎ：ｏａｓｉｓ：ｎａｍｅｓ：ｔｃ：ＳＡＭＬ：２．０：ｃｍ：ｂｅａｒｅｒ"＞
＜ｓａｍｌ：ＳｕｂｊｅｃｔＣｏｎｆｉｒｍａｔｉｏｎＤａｔａ  ＮｏｔＯｎＯｒＡｆｔｅｒ＝"２０２６−０１−１８Ｔ０６：２１：４８Ｚ"  Ｒｅｃｉｐｉｅｎｔ＝"ｈｔｔｐ：／／ｓｐ．ｅｘａｍｐｌｅ．ｃｏｍ／ｄｅｍｏ１／ｉｎｄｅｘ．ｐｈｐ？ａｃｓ"  ＩｎＲｅｓｐｏｎｓｅＴｏ＝"ＯＮＥＬＯＧＩＮ＿４ｆｅｅ３ｂ０４６３９５ｃ４ｅ７５１０１１ｅ９７ｆ８９００ｂ５２７３ｄ５６６８５"／＞
＜／ｓａｍｌ：ＳｕｂｊｅｃｔＣｏｎｆｉｒｍａｔｉｏｎ＞
＜／ｓａｍｌ：Ｓｕｂｊｅｃｔ＞
＜ｓａｍｌ：Ｃｏｎｄｉｔｉｏｎｓ  ＮｏｔＢｅｆｏｒｅ＝"２０１６−０７−１７Ｔ０１：０１：１８Ｚ"  ＮｏｔＯｎＯｒＡｆｔｅｒ＝"２０２６−０１−１８Ｔ０６：２１：４８Ｚ"＞
＜ｓａｍｌ：ＡｕｄｉｅｎｃｅＲｅｓｔｒｉｃｔｉｏｎ＞
＜ｓａｍｌ：Ａｕｄｉｅｎｃｅ＞ｈｔｔｐ：／／ｓｐ．ｅｘａｍｐｌｅ．ｃｏｍ／ｄｅｍｏ１／ｍｅｔａｄａｔａ．ｐｈｐ＜／ｓａｍｌ：Ａｕｄｉｅｎｃｅ＞
＜／ｓａｍｌ：ＡｕｄｉｅｎｃｅＲｅｓｔｒｉｃｔｉｏｎ＞
＜／ｓａｍｌ：Ｃｏｎｄｉｔｉｏｎｓ＞
＜ｓａｍｌ：ＡｕｔｈｎＳｔａｔｅｍｅｎｔ  ＡｕｔｈｎＩｎｓｔａｎｔ＝"２０１６−０７−１７Ｔ０１：０１：４８Ｚ"  ＳｅｓｓｉｏｎＮｏｔＯｎＯｒＡｆｔｅｒ＝"２０２６−０７−１７Ｔ０９：０１：４８Ｚ"  ＳｅｓｓｉｏｎＩｎｄｅｘ＝"＿ｂｅ９９６７ａｂｄ９０４ｄｄｃａｅ３ｃ０ｅｂ４１８９ａｄｂｅ３ｆ７１ｅ３２７ｃｆ９３"＞
＜ｓａｍｌ：ＡｕｔｈｎＣｏｎｔｅｘｔ＞
＜ｓａｍｌ：ＡｕｔｈｎＣｏｎｔｅｘｔＣｌａｓｓＲｅｆ＞ｕｒｎ：ｏａｓｉｓ：ｎａｍｅｓ：ｔｃ：ＳＡＭＬ：２．０：ａｃ：ｃｌａｓｓｅｓ：Ｐａｓｓｗｏｒｄ＜／ｓａｍｌ：ＡｕｔｈｎＣｏｎｔｅｘｔＣｌａｓｓＲｅｆ＞
＜／ｓａｍｌ：ＡｕｔｈｎＣｏｎｔｅｘｔ＞
＜／ｓａｍｌ：ＡｕｔｈｎＳｔａｔｅｍｅｎｔ＞
＜ｓａｍｌ：ＡｔｔｒｉｂｕｔｅＳｔａｔｅｍｅｎｔ＞
＜ｓａｍｌ：Ａｔｔｒｉｂｕｔｅ  Ｎａｍｅ＝"ｕｉｄ"  ＮａｍｅＦｏｒｍａｔ＝"ｕｒｎ：ｏａｓｉｓ：ｎａｍｅｓ：ｔｃ：ＳＡＭＬ：２．０：ａｔｔｒｎａｍｅ−ｆｏｒｍａｔ：ｂａｓｉｃ"＞
＜ｓａｍｌ：ＡｔｔｒｉｂｕｔｅＶａｌｕｅ  ｘｓｉ：ｔｙｐｅ＝"ｘｓ：ｓｔｒｉｎｇ"＞ｔｅｓｔ＜／ｓａｍｌ：ＡｔｔｒｉｂｕｔｅＶａｌｕｅ＞
＜／ｓａｍｌ：Ａｔｔｒｉｂｕｔｅ＞
＜ｓａｍｌ：Ａｔｔｒｉｂｕｔｅ  Ｎａｍｅ＝"ｍａｉｌ"  ＮａｍｅＦｏｒｍａｔ＝"ｕｒｎ：ｏａｓｉｓ：ｎａｍｅｓ：ｔｃ：ＳＡＭＬ：２．０：ａｔｔｒｎａｍｅ−ｆｏｒｍａｔ：ｂａｓｉｃ"＞
＜ｓａｍｌ：ＡｔｔｒｉｂｕｔｅＶａｌｕｅ  ｘｓｉ：ｔｙｐｅ＝"ｘｓ：ｓｔｒｉｎｇ"＞ｔｅｓｔ＠ｅｘａｍｐｌｅ．ｃｏｍ＜／ｓａｍｌ：ＡｔｔｒｉｂｕｔｅＶａｌｕｅ＞
＜／ｓａｍｌ：Ａｔｔｒｉｂｕｔｅ＞
＜ｓａｍｌ：Ａｔｔｒｉｂｕｔｅ  Ｎａｍｅ＝"ｅｄｕＰｅｒｓｏｎＡｆｆｉｌｉａｔｉｏｎ"  ＮａｍｅＦｏｒｍａｔ＝"ｕｒｎ：ｏａｓｉｓ：ｎａｍｅｓ：ｔｃ：ＳＡＭＬ：２．０：ａｔｔｒｎａｍｅ−ｆｏｒｍａｔ：ｂａｓｉｃ"＞
＜ｓａｍｌ：ＡｔｔｒｉｂｕｔｅＶａｌｕｅ  ｘｓｉ：ｔｙｐｅ＝"ｘｓ：ｓｔｒｉｎｇ"＞ｕｓｅｒｓ＜／ｓａｍｌ：ＡｔｔｒｉｂｕｔｅＶａｌｕｅ＞
＜ｓａｍｌ：ＡｔｔｒｉｂｕｔｅＶａｌｕｅ  ｘｓｉ：ｔｙｐｅ＝"ｘｓ：ｓｔｒｉｎｇ"＞ｅｘａｍｐｌｅｒｏｌｅ１＜／ｓａｍｌ：ＡｔｔｒｉｂｕｔｅＶａｌｕｅ＞
＜／ｓａｍｌ：Ａｔｔｒｉｂｕｔｅ＞
＜／ｓａｍｌ：ＡｔｔｒｉｂｕｔｅＳｔａｔｅｍｅｎｔ＞
＜／ｓａｍｌ：Ａｓｓｅｒｔｉｏｎ＞
＜／ｓａｍｌｐ：Ｒｅｓｐｏｎｓｅ＞
」
【００３０】
本実施形態においては、ＳＡＭＬ  ＲｅｓｐｏｎｓｅはＳＡＭＬ２．０仕様に従い＜ＡｕｔｈｎＲｅｓｐｏｎｓｅ＞要素で表現される。認証応答メッセージには、ＳＡＭＬ２．０仕様に従い、ＳＳＯユーザー毎の、認証応答メッセージの署名に使用するＩｄＰ秘密鍵を用いて表９の＜ｄｓ：Ｓｉｇｎａｔｕｒｅ  ｘｍｌｎｓ：ｄｓ＝"ｈｔｔｐ：／／ｗｗｗ．ｗ３．ｏｒｇ／２０００／０９／ｘｍｌｄｓｉｇ＃"＞以下のようなＸＭＬ  Ｓｉｇｎａｔｕｒｅ標準に従ったアサーション署名が付与される。
また、認証応答メッセージの送信にはＨＴＴＰ  ＰＯＳＴ  Ｂｉｎｄｉｎｇが用いられる。そのため、ＩＤプロバイダー３００のＳＳＯ管理モジュール３５０は、生成された表９の認証応答メッセージをＢａｓｅ６４エンコードして表１０の認証応答メッセージを含むリダイレクト用ＨＴＭＬを生成する。
ここで、図４の説明を再開する。Ｓ４．７は、図５のＳ５０６における認証応答メッセージをＢａｓｅ６４エンコードして下記表１０の認証応答メッセージを含むリダイレクト用ＨＴＭＬの生成である。Ｓ４．７の後、ＩＤプロバイダー３００は、［ＩｄＰ側：信頼するＳＰの登録］で登録したＳＰが認証応答を受け付けるＵＲＬにリダイレクトするようにクライアントＰＣ２００に応答する（Ｓ４．８）。
【００３１】
（表１０：認証応答メッセージを含むリダイレクト用ＨＴＭＬ）
「
＜ｈｔｍｌ  ｘｍｌｎｓ＝"ｈｔｔｐ：／／ｗｗｗ．ｗ３．ｏｒｇ／１９９９／ｘｈｔｍｌ"  ｘｍｌ：ｌａｎｇ＝"ｅｎ"＞
＜ｂｏｄｙ  ｏｎｌｏａｄ＝"ｄｏｃｕｍｅｎｔ．ｆｏｒｍｓ［０］．ｓｕｂｍｉｔ（）"＞
＜ｎｏｓｃｒｉｐｔ＞
＜ｐ＞
＜ｓｔｒｏｎｇ＞Ｎｏｔｅ：＜／ｓｔｒｏｎｇ＞  Ｓｉｎｃｅ  ｙｏｕｒ  ｂｒｏｗｓｅｒ  ｄｏｅｓ  ｎｏｔ  ｓｕｐｐｏｒｔ  ＪａｖａＳｃｒｉｐｔ，
ｙｏｕ  ｍｕｓｔ  ｐｒｅｓｓ  ｔｈｅ  Ｃｏｎｔｉｎｕｅ  ｂｕｔｔｏｎ  ｏｎｃｅ  ｔｏ  ｐｒｏｃｅｅｄ．
＜／ｐ＞
＜／ｎｏｓｃｒｉｐｔ＞
＜ｆｏｒｍ  ａｃｔｉｏｎ＝"ｈｔｔｐｓ：／／ｄｅ０１．ａｕｔｈ．ａ０１．ｃ−ａａｓ−ｔｅｓｔ．ｃｏｍ／ａｕｔｈ／Ｓａｍｌ／ＳＰ／ＳＳＯ／Ｐｏｓｔ"  ｍｅｔｈｏｄ＝"ｐｏｓｔ"＞
＜ｄｉｖ＞
＜ｉｎｐｕｔ  ｔｙｐｅ＝"ｈｉｄｄｅｎ"  ｎａｍｅ＝"ＲｅｌａｙＳｔａｔｅ"  ｖａｌｕｅ＝"ｈｔｔｐｓ：／／ａｐｐｌｉｃａｔｉｏｎ．ｓｐ．ｅｘａｍｐｌｅ．ｃｏｍ／ｐｏｒｔａｌ．ｈｔｍｌ  "  ／＞
＜ｉｎｐｕｔ  ｔｙｐｅ＝"ｈｉｄｄｅｎ"  ｎａｍｅ＝"ＳＡＭＬＲｅｓｐｏｎｓｅ"  ｖａｌｕｅ＝"ＰＤ９４ｂＷｗｇｄｍＶｙｃ２ｌｖｂｊ０ｉＭＳ４ｗＩｉＢｌｂｍＮｖＺＧｌｕＺｚ０ｉＶＶＲ…ｄＨＪｐＹ３Ｒｐｂ２４＋ＰＨＮｈｂＷｗ６ＱＸＶｋａＷＶｕＹ２Ｕ＋ａＨＲｚｃＧ９ｕｃ２Ｕ＋"／＞
＜／ｄｉｖ＞
＜ｎｏｓｃｒｉｐｔ＞
＜ｄｉｖ＞
＜ｉｎｐｕｔ  ｔｙｐｅ＝"ｓｕｂｍｉｔ"  ｖａｌｕｅ＝"Ｃｏｎｔｉｎｕｅ"／＞
＜／ｄｉｖ＞
＜／ｎｏｓｃｒｉｐｔ＞
＜／ｆｏｒｍ＞
＜／ｂｏｄｙ＞
＜／ｈｔｍｌ＞
」
【００３２】
表１０の認証応答メッセージを含むリダイレクト用ＨＴＭＬは、ＳＳＯ後のＳＰのアクセスポイントであるＲｅｌａｙＳｔａｔｅを含む。本実施形態の場合、ＲｅｌａｙＳｔａｔｅは表５のＵＲＬになる。
表１０の認証応答メッセージを含むリダイレクト用ＨＴＭＬを受け取ったクライアントＰＣ２００のＷｅｂブラウザー２２０は、ユーザー認証のために［ＩｄＰ側：信頼するＳＰの登録］で登録したＳＰが認証要求を受け付けるＵＲＬが示すサービスプロバイダー４００にリダイレクトする（Ｓ４．９）。
クライアントＰＣ２００によるリダイレクトの結果、表１０の認証要求メッセージを受信したサービスプロバイダー４００は、ＩＰアドレス制限をスキップ、認証応答メッセージの検証、ユーザー認証を行うＳＰ側認証処理（Ｓ４．１０）を行う。
【００３３】
図６は、サービスプロバイダー４００の情報処理の一例を示すフローチャートである。以下、Ｓ４．１０の処理を図６のフローチャートにより詳細に説明する。
図６のフローチャートは、サービスプロバイダー４００の認証モジュール４３０が、Ｗｅｂ  ＡＰＩサーバ４２０を経由して、認証メッセージとして表１０の認証応答メッセージを受信する（Ｓ６０１）ことから始まる。認証応答メッセージを受信した認証モジュール４３０は、Ｓ６０１で受信した認証メッセージがＳＳＯであるかどうか判定する（Ｓ６０２）。認証メッセージが表１０のような認証応答メッセージ（ＳＡＭＬ  Ｒｅｓｐｏｎｓｅ）を含むＨＴＭＬであればＳＳＯであると判定し（Ｓ６０２においてＹｅｓ）、認証モジュール４３０は、Ｓ６１０に進む。そして、ＳＳＯ管理モジュール４５０は、［ＳＰ側：ＩＰアドレス制限の設定］で設定した値を参照して行うサービスプロバイダー４００に対するアクセス元ＩＰアドレス制限処理をスキップして認証応答メッセージの検証処理を行う（Ｓ６１０）。一方Ｓ６０１で受信した認証メッセージが表１０の認証応答メッセージでなく、サービスプロバイダー４００の通常のログイン処理によるユーザー名、パスワードであればＳＳＯでないと判定し（Ｓ６０２においてＮｏ）、認証モジュール４３０は、Ｓ６０６に進む。そして、認証モジュール４３０は、［ＳＰ側：ＩＰアドレス制限の設定］で設定した値を参照して行うサービスプロバイダー４００に対するアクセス元ＩＰアドレス制限処理（Ｓ６０６）を行う。
【００３４】
ここで図４のシーケンスに従い、Ｓ６０１で受信した認証メッセージがＳＳＯであることを示す表１０の認証応答メッセージであった場合、ＳＳＯ管理モジュール４５０は、認証応答検証処理を行う。Ｓ６１０の認証応答検証処理では、ＳＳＯ管理モジュール４５０は、受け取った表１０の認証応答メッセージから＜ｉｎｐｕｔ  ｔｙｐｅ＝"ｈｉｄｄｅｎ"  ｎａｍｅ＝"ＳＡＭＬＲｅｓｐｏｎｓｅ"  ｖａｌｕｅ＝"  ＰＤ９４ｂＷｗｇｄｍＶｙｃ２ｌｖｂｊ０ｉＭＳ４ｗＩｉＢｌｂｍＮｖＺＧｌｕＺｚ０ｉＶＶＲ…ｄＨＪｐＹ３Ｒｐｂ２４＋ＰＨＮｈｂＷｗ６ＱＸＶｋａＷＶｕＹ２Ｕ＋ａＨＲｚｃＧ９ｕｃ２Ｕ＋"／＞のｖａｌｕｅ＝で示されるＳＡＭＬ  Ｒｅｓｐｏｎｓｅの内容を抜き出し、デコード、検証してその検証の成否を判定する。ＳＡＭＬ  Ｒｅｓｐｏｎｓｅの値はＩＤプロバイダー３００のＳＳＯ管理モジュール３５０が表９の認証応答メッセージをＢａｓｅ６４エンコードした値である。ＳＳＯ管理モジュール４５０は、ＳＡＭＬ  Ｒｅｓｐｏｎｓｅの内容をＢａｓｅ６４デコードし、表９で示される認証応答メッセージを得る。
本実施形態において、ＳＡＭＬ  ＲｅｓｐｏｎｓｅはＳＡＭＬ２．０仕様に従う。ＳＳＯ管理モジュール４５０は、ＳＳＯユーザー毎の、ＩｄＰの公開鍵（ＩｄＰからの認証応答に含まれる、ＩｄＰ秘密鍵による署名検証用）を用いて、表９の認証応答メッセージの＜ｄｓ：Ｓｉｇｎａｔｕｒｅ  ｘｍｌｎｓ：ｄｓ＝"ｈｔｔｐ：／／ｗｗｗ．ｗ３．ｏｒｇ／２０００／０９／ｘｍｌｄｓｉｇ＃"＞以下のようなＸＭＬ  Ｓｉｇｎａｔｕｒｅ標準に従ったアサーション署名の検証等を行う。
【００３５】
ＳＳＯ管理モジュール４５０は、検証の際に使用されるＳＳＯユーザー名として、表９の認証応答メッセージの＜ｓａｍｌ：ＮａｍｅＩＤ  ＳＰＮａｍｅＱｕａｌｉｆｉｅｒ＝"ｈｔｔｐ：／／ｓｐ．ｅｘａｍｐｌｅ．ｃｏｍ／ｄｅｍｏ１／ｍｅｔａｄａｔａ．ｐｈｐ"  Ｆｏｒｍａｔ＝"ｕｒｎ：ｏａｓｉｓ：ｎａｍｅｓ：ｔｃ：ＳＡＭＬ：２．０：ｎａｍｅｉｄ−ｆｏｒｍａｔ：ｔｒａｎｓｉｅｎｔ"＞Ｕｓｅｒ０００１＜／ｓａｍｌ：ＮａｍｅＩＤ＞に含まれる"Ｕｓｅｒ０００１"を用いる。
ＳＳＯ管理モジュール４５０は、認証応答検証処理が正常に終了したか否かを判定する（Ｓ６１１）。認証応答検証処理が正常に終了したと判定した場合（Ｓ６１１においてＹｅｓ）、認証モジュール４３０は、ＳＳＯユーザー名を用いてサービスプロバイダー４００へのログイン処理を行う（Ｓ６０３）。Ｓ４．１０のように、ＳＳＯの認証応答メッセージを正常処理した場合、ログイン処理では、認証モジュール４３０は、パスワード検証を行わずログインを認証し（Ｓ６０４においてＹｅｓ）、ログイン成功のメッセージを返す（Ｓ６０５）。そして、認証モジュール４３０は、図６の処理を終える。Ｓ６１０の認証応答検証処理が正常に終了しない場合（Ｓ６１１においてＮｏ）、認証モジュール４３０は、ログインエラー画面を表示して図６に示す処理を終える（Ｓ６０９）。
【００３６】
図６のフローチャートにより詳述した図４のＳ４．１０の処理を終えた後、サービスプロバイダー４００のＳＳＯ管理モジュール４５０は、表１０の＜ｉｎｐｕｔ  ｔｙｐｅ＝"ｈｉｄｄｅｎ"  ｎａｍｅ＝"ＲｅｌａｙＳｔａｔｅ"  ｖａｌｕｅ＝"ｈｔｔｐｓ：／／ａｐｐｌｉｃａｔｉｏｎ．ｓｐ．ｅｘａｍｐｌｅ．ｃｏｍ／ｐｏｒｔａｌ．ｈｔｍｌ  "  ／＞に含まれるＲｅｌａｙＳｔａｔｅのｖａｌｕｅであるＵＲＬに対し、サービス利用のためのアクセストークンと共に、リダイレクト処理を行うようにクライアントＰＣ２００のＷｅｂブラウザー２２０に対して応答を返す（Ｓ４．１３）。応答を受信したクライアントＰＣ２００のＷｅｂブラウザー２２０は、ＲｅｌａｙＳｔａｔｅで示されていたサービスプロバイダー４００のリダイレクト先ＵＲＬにアクセストークンをもってアクセスする（Ｓ４．１４）。そして、Ｗｅｂブラウザー２２０は、サービスプロバイダー４００のＷｅｂアプリケーションであるアプリケーションサーバ４６０にアクセスしてアプリケーションサービスの利用を開始する。
【００３７】
図７は、ユーザーがサービスプロバイダー４００に直接ログインして行う、例えばサービスプロバイダー上のユーザー、ＳＳＯ設定に係るサービス、を利用するためのログインシーケンス図である。クライアントＰＣ２００のＷｅｂブラウザー２２０は、サービスプロバイダー４００にログインするために、サービスプロバイダー４００のＷｅｂ  ＡＰＩサーバ４２０にアクセスする（Ｓ７．１）。ログイン情報を受信したサービスプロバイダー４００のＷｅｂ  ＡＰＩサーバ４２０は、認証モジュール４３０を呼び出し、ログイン認証処理を行う（Ｓ７．２）。サービスプロバイダー４００の認証モジュール４３０は、Ｓ６０１にて受信したユーザー名、パスワードと共に、ログイン情報受信の際のＨＴＴＰヘッダーを解析する。そして認証モジュール４３０は、Ｆｏｒｗａｒｄｅｄ（又はＸ−Ｆｏｒｗａｒｄｅｄ−Ｆｏｒ）ヘッダーフィールドを取得してアクセス元ＩＰアドレスを取得し、ＩＰアドレス制限を行う（Ｓ６０６）。
Ｆｏｒｗａｒｄｅｄ（又はＸ−Ｆｏｒｗａｒｄｅｄ−Ｆｏｒ）ヘッダーフィールドはカンマとスペースとで区切られたＩＰアドレスの一覧である。クライアントＰＣ２００とサービスプロバイダー４００との間にプロキシ―サーバが存在する場合、クライアントＰＣ２００のＩＰアドレスの右側に、経由してきた各々のプロキシ―サーバのＩＰアドレスが順次、記録される。本実施形態においては、アクセス元ＩＰアドレスとしてＦｏｗａｒｄｅｄ（又はＸ−Ｆｏｒｗａｒｄｅｄ−Ｆｏｒ）ヘッダーフィールドの最も左のカラムにあるＩＰアドレスが用いられる。
【００３８】
認証モジュール４３０は、ステップ６０１にて取得したユーザーのユーザーＩＤと、Ｆｏｗａｒｄｅｄ（又はＸ−Ｆｏｒｗａｒｄｅｄ−Ｆｏｒ）ヘッダーフィールドのクライアントＰＣ２００のＩＰアドレスと、を取得する。認証モジュール４３０は、ＤＢモジュール４４０に存在する表４のＳＰ側ＩＰアドレス制限設定テーブルを参照する。認証モジュール４３０は、認証したユーザーＩＤに対応する表４のユーザーＩＤの対応するアクセス許可ＩＰアドレスを取得し、アクセス元ＩＰアドレスが、表４のユーザーＩＤに対応する接続許可ＩＰアドレスにマッチ又はＩＰアドレス範囲に含まれているかどうか判定する（Ｓ６０７）。判定の結果、Ｆｏｒｗａｒｄｅｄ（又はＸ−Ｆｏｒｗａｒｄｅｄ−Ｆｏｒ）に含まれるアクセス元のクライアントＰＣ２００のＩＰアドレスがアクセス許可ＩＰアドレスにマッチ又はＩＰアドレス範囲に含まれていれば（Ｓ６０７においてＹｅｓ）、認証モジュール４３０は、Ｓ６０３に進む。認証モジュール４３０は、アクセス元のクライアントＰＣ２００はアクセスが許可されたものと見做し、ログイン処理を行う（Ｓ６０３）。Ｆｏｒｗａｒｄｅｄ（又はＸ−Ｆｏｒｗａｒｄｅｄ−Ｆｏｒ）に含まれるアクセス元のクライアントＰＣ２００のＩＰアドレスがアクセス許可ＩＰアドレスにマッチ又はＩＰアドレス範囲に含まれていなない場合（Ｓ６０７においてＮｏ）、認証モジュール４３０は、Ｓ６０８に進む。認証モジュール４３０は、ＩＰアドレス制限エラーとしてＩＰアドレス制限エラーのメッセージを表示して（Ｓ６０８）、図６に示す処理を終える。
Ｓ６０７においてＹｅｓと判定され、Ｓ６０３に移行した場合、認証モジュール４３０は、Ｓ６０１で受け取ったユーザーＩＤ、パスワードと、予めＤＢモジュール４４０に登録されているユーザーＩＤ、パスワードと、を検証して、ログイン処理を行う。認証モジュール４３０は、検証の結果、ログインに成功しなか否かを判定する（Ｓ６０４）。ログインに成功した場合（Ｓ６０４においてＹｅｓ）、認証モジュール４３０は、ログイン成功処理（Ｓ６０５）を行い、図６に示す処理を終える。Ｓ６０３のログインに成功しなかった場合（Ｓ６０４においてＮｏ）、認証モジュール４３０は、ログインエラー画面を表示して（Ｓ６０９）、図６に示す処理を終える。
【００３９】
図６のフローチャートにより詳述した図７のＳ７．２の処理を終えた後、サービスプロバイダー４００のＳＳＯ管理モジュール４５０は、以下の処理を行う。即ち、ＳＳＯ管理モジュール４５０は、Ｓ７．１に含まれるＵＲＬに対し、サービス利用のためのアクセストークンと共に、リダイレクト処理を行うようにクライアントＰＣ２００のＷｅｂブラウザー２２０に対して応答を返す（Ｓ７．３）。応答を受信したクライアントＰＣ２００のＷｅｂブラウザー２２０は、Ｓ７．１に含まれているサービスプロバイダー４００のリダイレクト先ＵＲＬにアクセストークンをもってアクセスする。そして、Ｗｅｂブラウザー２２０は、サービスプロバイダー４００のＷｅｂアプリケーションであるアプリケーションサーバ４６０にアクセスしてアプリケーションサービスの利用を開始する（Ｓ７．４）。
【００４０】
＜実施形態２＞
［ＳＳＯ設定されているユーザーのＳＰ側ログインの際のデフォルトＩＰアドレス制限］
［ＳＳＯにおけるＩｄＰとＳＰの信頼関係の構築］と［ＩＰアドレス制限の設定］とが完了した上で、図７のサービスプロバイダー４００へのログインシーケンスが開始可能になる。
図７は、ユーザーがサービスプロバイダー４００に直接ログインして行う、例えばサービスプロバイダー上のユーザー、ＳＳＯ設定に係るサービス、を利用するためのログインシーケンス図である。クライアントＰＣ２００のＷｅｂブラウザー２２０は、サービスプロバイダー４００にログインするために、サービスプロバイダー４００のＷｅｂ  ＡＰＩサーバ４２０にアクセスする（Ｓ７．１）。ログイン情報を受信したサービスプロバイダー４００のＷｅｂ  ＡＰＩサーバ４２０は、認証モジュール４３０を呼び出し、ログイン認証処理を行う（Ｓ７．２）。
【００４１】
図８は、Ｓ７．２のサービスプロバイダー４００によるログイン認証処理のフローチャートである。
図８で示されるフローは、Ｓ７．２にて、サービスプロバイダー４００の認証モジュール４３０が、ログイン情報を受信（Ｓ８０１）することから始まる。ここで認証モジュール４３０は、受信したログイン情報がＳＳＯによるログインである表１０で示されるような認証応答メッセージを含むリダイレクト用ＨＴＭＬであるか、通常のログイン情報であるユーザー名・パスワードであるか判定する（Ｓ８０２）。ここでもしＳＳＯによるログインであるならば（Ｓ８０２においてＹｅｓ）、認証モジュール４３０は、実施形態１のＳ６０３以降と同様にログイン処理（Ｓ８０３）を行う。Ｓ８０１で受信したログイン情報を通常のログイン情報であるユーザー名・パスワードと判断すると（Ｓ８０２においてＮｏ）、認証モジュール４３０は、ユーザーがＳＳＯ設定されているか否かを確認する（Ｓ８１０）。ＳＳＯ設定の確認は、より具体的には認証モジュール４３０が、ユーザー名に対し［ＳＰ側：信頼するＩｄＰの登録］においてユーザーに紐付けてＤＢモジュール４４０に格納しているＳＰメタデータ情報及び秘密鍵の存在を確認することにより行われる。認証モジュール４３０は、確認でＳＰメタデータ等が存在すれば、ユーザーはＳＳＯ設定されているものとし、ＳＰメタデータ等が存在しなければ、ユーザーはＳＳＯ設定されていないものとする。ＳＳＯ設定は、シングルサインオン設定の略である。
【００４２】
Ｓ８０１で受信したユーザーのユーザーＩＤがＳＳＯ設定されていなかったとすると（Ｓ８１０においてＮｏ）、認証モジュール４３０は、実施形態１の図６のＳ６０６で示したようなＩＰアドレス制限処理を行う（Ｓ８０６）。Ｓ８０６のＩＰアドレス制限処理に成功した場合（Ｓ８０７においてＹｅｓ）、認証モジュール４３０は、Ｓ８０３以降のログイン処理を行う。一方、Ｓ８０６のＩＰアドレス制限処理に失敗した場合（Ｓ８０７においてＮｏ）、認証モジュール４３０は、ＩＰアドレス制限エラー画面を表示して（Ｓ８０８）、図８の処理を終える。
Ｓ８０１で受信したユーザーのユーザーＩＤがＳＳＯ設定されていた場合（Ｓ８１０においてＹｅｓ）、認証モジュール４３０は、［ＳＰ側：ＩＰアドレス制限の設定］で示したユーザーのＩＰアドレス制限の設定、又は未設定状態であっても、デフォルトのＩＰアドレス制限を実施する（Ｓ８１１）。デフォルトのＩＰアドレス制限は、ＤＢモジュール４４０に予め以下の設定を行い、それをＳ８１１にて認証モジュール４３０が参照することにより行われる。ＩＰアドレス制限の対象となる認証要求元のクライアントＰＣ２００のアクセス元ＩＰアドレスは、実施形態１の図６のＳ６０６で示したように、認証モジュール４３０が認証要求ＨＴＴＰメッセージのＦｏｗａｒｄｅｄ（又はＸ−Ｆｏｒｗａｒｄｅｄ−Ｆｏｒ）ヘッダーフィールドのクライアントＰＣ２００のＩＰアドレスを取得する。Ｓ８１０、Ｓ８０６、Ｓ８１１は、認証メッセージに基づいてシングルサインオンでないと判定された場合、ユーザーがシングルサインオン設定されているか否かに応じて、ＩＰアドレスの制御処理を変更する処理の一例である。
【００４３】
（表１１：デフォルトＩＰアドレス制限）
「
ユーザーＩＤ：アクセス許可ＩＰアドレス
Ｕｓｅｒ０００１：１９２．１６８．１００．＊
Ｕｓｅｒ０００１：１７２．２０．０．＊  −  １７２．２０．１２８．＊
」
【００４４】
表１１のサービスプロバイダー４００側デフォルトＩＰアドレス制限設定テーブルは、Ｕｓｅｒ０００１がＩｄＰにアクセスする際、アクセス元ＩＰアドレスとして１９２．１６８．１００．０／１６の範囲と、１７２．２０．０．０から１７２．２０．１２８．２５５までのＩＰアドレス範囲を許可する。
本実施形態の特徴は、サービスプロバイダー４００へのユーザーの通常のＳＳＯでないログインの際に、ユーザーがＳＳＯ設定されているならば、［ＳＰ側：ＩＰアドレス制限の設定］で示したユーザーのＩＰアドレス制限の設定、又は未設定状態であっても、デフォルトのＩＰアドレス制限が実施されることである。
ここで認証モジュール４３０がＳ８１１のデフォルトＩＰアドレス制限処理に成功した場合（Ｓ８０７においてＹｅｓ）、Ｓ８０３以降のログイン処理が行われる。一方、Ｓ８１１のデフォルトＩＰアドレス制限処理に失敗した場合（Ｓ８０７においてＮｏ）、認証モジュール４３０は、ＩＰアドレス制限エラー画面を表示して（Ｓ８０８）、図８の処理を終える。
Ｓ８０３以降のログイン処理、即ちＳ８０３、Ｓ８０４、Ｓ８０５、Ｓ８０９については、実施形態１の図６のＳ６０３、Ｓ６０４、Ｓ６０５、Ｓ６０９と同様である。
【００４５】
＜その他の実施形態＞
本発明は、上述の実施形態の１以上の機能を実現するプログラムを、ネットワーク又は記憶媒体を介してシステム又は装置に供給する。そして、そのシステム又は装置のコンピュータにおける１つ以上のプロセッサーがプログラムを読み出し実行する処理でも実現可能である。また、１以上の機能を実現する回路（例えば、ＡＳＩＣ）によっても実現可能である。
【００４６】
以上、本発明の好ましい実施形態について詳述したが、本発明は係る特定の実施形態に限定されるものではない。
【００４７】
以上、上述した各実施形態の処理によれば、以下のことができる。即ち、シングルサインオン（ＳＳＯ）可能なシステムでＩＤプロバイダー（ＩｄＰ）側、サービスプロバイダー（ＳＰ）側双方でログイン時のＩＰアドレス制限を実装する場合、ＩＰアドレス制限の整合性ある動作を実現し、ユーザーの利便性を向上させることができる。より具体的には、ＩｄＰ側のＩＰアドレス制限ポリシーに従い、例えＳＰ側にＩＰアドレス制限が設定されていたとしてもそれを判定しない。ユーザーにとっては、あくまでＩｄＰ側のポリシーに従う整合性のあるＩＰアドレス制限動作になる。またシステムにとっては、ＳＰ側の無駄な動作（ＩｄＰとＳＰとで設定が異なった場合の処理等）を防止できる。
【符号の説明】
【００４８】
３００  ＩＤプロバイダー
４００  サービスプロバイダー
【図１】
2018018157.tif 000003
【図２】
2018018157.tif 000004
【図３】
2018018157.tif 000005
【図４】
2018018157.tif 000006
【図５】
2018018157.tif 000007
【図６】
2018018157.tif 000008
【図７】
2018018157.tif 000009
【図８】
2018018157.tif 000010