JP6719875B2 - 認証サーバ、認証方法およびプログラム - Google Patents

Description

本発明は、同一セキュリティドメイン内で複数のＷｅｂサービスを異なるサブドメインで提供している場合に、発行するクッキー（Ｃｏｏｋｉｅ）のドメイン範囲を判定する方法に関する。

インターネット上で提供されているＷｅｂサービスにおいて、Ｗｅｂサービスが発行した情報をＷｅｂブラウザに保存するＣｏｏｋｉｅという仕組みが使われている。一般的に認証機能で保護されたサーバへのアクセスは、認証が成功したことを示す認証トークンや認証セッションをＣｏｏｋｉｅとしてクライアントのＷｅｂブラウザに保存しておき、そのＣｏｏｋｉｅを利用して行われる。Ｗｅｂサービスを利用する際には、クライアントからサーバにＣｏｏｋｉｅが送信されることで、サーバはユーザを特定し、サービスを提供する。また、Ｃｏｏｋｉｅには、セキュリティの観点から、Ｃｏｏｋｉｅが有効であるドメインを設定し、Ｃｏｏｋｉｅ情報を取得できるＷｅｂサービスを限定する機能がある。Ｃｏｏｋｉｅにドメイン範囲が設定されていた場合、Ｗｅｂブラウザはそのドメイン範囲に一致するＷｅｂサービスに対してのみ、そのＣｏｏｋｉｅを送信するようになる。

ここで、１つのドメイン内に複数のサービスの夫々をサブドメインとして提供する場合がある。例えば１つのドメイン“ｅｘａｍｐｌｅ．ｃｏｍ”において、サービスＡ用サブドメイン“ＡＡＡ．ｅｘａｍｐｌｅ．ｃｏｍ”や、サービスＢ用サブドメイン“ＢＢＢ．ｅｘａｍｐｌｅ．ｃｏｍ”などが提供できる。Ｃｏｏｋｉｅの仕組みとして、各サービスは、自身のドメインに含まれる範囲でしかＣｏｏｋｉｅを発行、取得出来ない。例えば、サービスＡは、自サービスのサブドメイン“ＡＡＡ．ｅｘａｍｐｌｅ．ｃｏｍ”を範囲とするＣｏｏｋｉｅと、自サービスのサブドメインが含まれるドメイン“ｅｘａｍｐｌｅ．ｃｏｍ”を範囲とするＣｏｏｋｉｅは発行、取得できる。しかし、サービスＢのサブドメイン“ＢＢＢ．ｅｘａｍｐｌｅ．ｃｏｍ”を範囲としたＣｏｏｋｉｅは発行、利用できない。そのため、いずれかのサブドメインのサービスにアクセスして認証した後に、異なるサブドメインのサービス利用時の認証をスキップするには、Ｃｏｏｋｉｅ範囲をドメイン全体（“ｅｘａｍｐｌｅ．ｃｏｍ”）とする必要がある。しかし、このようにＣｏｏｋｉｅ範囲を広くすると、同じドメイン内の全サービスがＣｏｏｋｉｅ情報を取得出来るようになる。そのため、意図しないサービスも情報を取得出来てしまうという課題がある。

この課題を解決する手段として、特許文献１の方法が提案されている。従来技術では、サブドメインである認証サービスにログインすると、認証サービスが提供されているサブドメインのみを設定したＣｏｏｋｉｅと、ドメイン全体を設定した、ドメイン範囲が広いＣｏｏｋｉｅを合わせて発行する。その際、ドメイン範囲が広いＣｏｏｋｉｅには認証情報を含めず検証用の情報のみを設定する。各サービスはドメイン範囲が広いＣｏｏｋｉｅから検証用情報を取得し、認証サービスに問い合わせを行う事で、ユーザの認証情報を取得する。

特表２０１４−５２９１５６号公報

従来技術により、同一のセキュリティドメインに複数のサブドメインのサービスが提供されている場合にも、意図しないサブドメインのサービスがＣｏｏｋｉｅから情報を取得することを防げる。しかしながら、従来技術においては、不要なＣｏｏｋｉｅの発行を防げることができない。Ｃｏｏｋｉｅを受け取ったサービスは、Ｃｏｏｋｉｅから取得した情報を利用して認証サービスに問い合わせをする事で、ユーザ情報などが取得できる。そのため、ユーザが利用していないサービスでも、そのユーザが他のサブドメインのサービスを利用していた場合、そのユーザのユーザ情報を取得出来るという課題がある。

本発明は、前述の課題に鑑みてなされたものであり、端末から認証サーバへのアクセスを受け付け、認証されたユーザーが同一ドメインの中の複数のサブドメインが提供する複数のサービスを利用する権限を持つかどうかを確認する確認手段と、前記確認手段により前記ユーザーが前記権限を持つと確認された場合に、前記複数のサブドメインを利用範囲とするクッキーを前記端末に発行し、前記確認手段により前記ユーザーが前記権限を持たないと確認された場合に、前記複数のサブドメインを利用範囲とするクッキーを発行するのではなくて前記認証サーバのサブドメインを利用範囲とするクッキーを前記端末に発行する発行手段とを有することを特徴とする認証サーバを提供する。

本発明により、ユーザが利用できるサービスに応じて、適切な範囲でＣｏｏｋｉｅを発行できるようになり、不要なサービスがＣｏｏｋｉｅ情報を取得する事を防ぐことができる。

システム全体図 サーバのハードウェア構成図 サーバのソフトウェア構成図 Ｃｏｏｋｉｅの発行フロー図 Ｃｏｏｋｉｅの利用フロー図 Ｃｏｏｋｉｅが発行されていない状態でのサービス利用フロー図 Ｃｏｏｋｉｅが発行されていない状態でのサービス利用フロー図

以下、本発明を実施するための最良の形態について図面を用いて説明する。なお、フローチャートにおいては、各ステップを「Ｓ」で表す。

＜実施例１＞
実施例１では、インターネット上で複数のオンラインサービスが提供されており、それらが同一ドメインの中の異なるサブドメインサービスとして提供されていることを想定している。なお、ここで言う「オンラインサービス」とは、Ｗｅｂサイト、Ｗｅｂアプリケーション、Ｗｅｂサービスなどが提供する機能群のことである。Ｗｅｂサイト、Ｗｅｂアプリケーション、Ｗｅｂサービスなどは、サーバコンピュータで実行されるソフトウェアである。

また、本実施例で説明する「Ｃｏｏｋｉｅ」（クッキー）とは、図１に記載の夫々のサーバが、後述する端末１０５のＷｅｂブラウザ３２０に保存させる情報であり、認証サーバ１０２で認証が成功したことを示す情報を含むデータである。認証が成功したことを示す情報とは、例えば認証トークンや、認証セッション情報である。そしてＣｏｏｋｉｅは図１の夫々のサーバ上のＷｅｂサービスにアクセスした際にＷｅｂブラウザ３２０から送信され、ユーザの特定に利用される。これにより、１度認証に成功したユーザが、以降のサービス利用時に、再度認証を行わずにサービスを利用できるというメリットがある。

図１は各種Ｗｅｂサービスが存在するネットワーク構成を示す図である。インターネット１００は外部から接続可能なパブリックなネットワークである。イントラネット１０１は、ＬＡＮなどの外部から接続不可能なプライベートなネットワークである。認証サーバ１０２は、ユーザの認証情報および認可情報を管理するサービスシステムである。リソースサーバ１０３、１０４は、印刷サービスや帳票サービスといったリソースサービスを提供するＷｅｂサービスシステムである。リソースサーバ１０３、１０４は、インターネット１００を介したクライアント端末１０５あるいは不図示の外部サービスシステムからのリクエストに応じて、リソースサービスを提供する。なお、各リソースサーバに設置されるリソースサービスは１つでも複数でもよい。また、認証サーバ１０２とリソースサーバ１０３、１０４は、同一のサーバ上に構成されてもよいし、それぞれ個別のＬＡＮ上に構成されてもよい。実施例１において各サーバは１台ずつ設置されているが、複数台で構成されていてもよい。端末（クライアント端末）１０５は、ＰＣや、スマートフォンやタブレットと呼ばれる携帯端末や、画像形成装置であり、Ｗｅｂブラウザ３２０がインストールされている。

図２は図１に示した各種サービスが配置されているサーバのハードウェア構成を示す図である。ユーザインターフェース２０１は、ディスプレイ、キーボード、マウスなどによる情報の入出力を行うハードウェアである。これらのハードウェアを備えないコンピュータは、リモートデスクトップなどにより、他のコンピュータから接続・操作することも可能である。ネットワークインターフェース２０２は、ＬＡＮなどのネットワークに接続して、他のコンピュータやネットワーク機器との通信を行うハードウェアである。ＣＰＵ２０３は、ＲＯＭ２０４、ＲＡＭ２０５、二次記憶装置２０６などから読み込んだプログラムを実行し、各種サービスを実現する。ＲＯＭ２０４は、組込済みプログラムおよびデータが記録されている記憶装置である。ＲＡＭ２０５は一時メモリ領域である。二次記憶装置２０６は、ＨＤＤに代表されるような外部記憶装置である。各部は入出力インターフェース２０７を介して接続されている。

図３は本実施例に係る認証サーバ１０２、リソースサーバ１０３、１０４、端末１０５のモジュール構成を示す図である。認証サーバ１０２は、リクエスト処理部３００、アクセス制御部３０１、データ管理部３０２により認証サービスを提供する。リクエスト処理部３００は、認証サーバ１０２がインターネット及びイントラネットを経由して受信した該認証サーバへのリクエストを処理する。また、リクエスト処理部３００は、アクセス制御部３０１から返される応答データを呼び出し元に返す。アクセス制御部３０１は、データ管理部３０２から取得するデータに基づき、認証および認可要求を処理する。また、アクセス制御部３０１は、データ管理部３０２に対して、アカウント追加やアカウント情報変更を行う。データ管理部３０２は、ユーザカウントのデータや、認可情報、連携しているサービス情報を管理する。

リソースサーバ１０３、１０４は、リクエスト処理部３１０、機能制御部３１１によりリソースサービスを提供する。リクエスト処理部３１０はリソースサーバ１０３、１０４がインターネット及びイントラネットを経由して受信したリソースサービスへのリクエストを処理する。また、リクエスト処理部３１０は、機能制御部３１１から返される処理結果を呼び出し元に返す。機能制御部３１１は、リクエスト処理部３１０が受信したリクエストに応じて必要な処理を行い、応答データを呼び出し元に返す。

端末１０５はＷｅｂブラウザ３２０を備える。Ｗｅｂブラウザ３２０はＷＷＷを利用するためのユーザエージェントであり、インターネット１００経由で認証サーバ１０２、リソースサーバ１０３、１０４へのアクセスを行う。

図４は、認証サービスへのアクセス時にＣｏｏｋｉｅを発行する発行処理のフローを示す図である。なお、認証サービスは認証サーバ１０２によって提供されるものとする。まず、Ｓ４０１において、ユーザは端末１０５上のＷｅｂブラウザ３２０を用いて、認証サーバ１０２に対してアクセスを行う。アクセスされた認証サーバ１０２は、Ｓ４０２において認証処理を行い、認証トークンを発行する。以下に、認証サーバ１０２がデータ管理部３０２で管理しているアカウント情報の例を示す。本実施例では、認証サーバ１０２はユーザＩＤ「ａｄｍｉｎ＠１００１ＡＡ」で認証したものとする。

Ｓ４０３において、認証サーバ１０２は、アカウントテーブルとロールテーブルから、認証したユーザの権限を確認し、サービステーブルから、認証したユーザが複数のサブドメインのサービスを利用する権限を持つかどうか確認する。以下に、認証サーバ１０２がデータ管理部３０２で管理しているロール情報の例とサービス情報の例を示す。

本実施例では、ロールテーブルから、ユーザＩＤ「ａｄｍｉｎ＠１００１ＡＡ」には、ロールＩＤ「ロールＡ」、「ロールＢ」、「ロールＣ」が設定されていることが確認される。そしてサービステーブルから、「ロールＡ」に対応するサービスＡ、「ロールＢ」に対応するサービスＢ、「ロールＣ」に対応するサービスＣの利用権限があると判断される。

Ｓ４０４において、認証サーバ１０２は、ユーザが複数のサブドメインのサービス利用権限を持つかどうかを判定する。ユーザが複数のサブドメインのサービス利用権限を持たない場合はＳ４０５に進み、当該利用権限を持つ場合はＳ４０６に進む。各サービスが提供されるサブドメインはサービステーブルで確認できる。本実施例では、サービスＡはサブドメイン「ＡＡＡ．ｅｘａｍｐｌｅ．ｃｏｍ」で提供され、サービスＢはサブドメイン「ＢＢＢ．ｅｘａｍｐｌｅ．ｃｏｍ」で提供され、サービスＣはサブドメイン「ＣＣＣ．ｅｘａｍｐｌｅ．ｃｏｍ」で提供される。よって、ユーザ「ａｄｍｉｎ＠１００１ＡＡ」は複数のサブドメインのサービスを利用する権限を持つと判断される。なお、Ｓ４０３とＳ４０４において、ユーザが複数のサブドメインのサービス利用権限を持つかどうかをユーザに設定されたロールによって判定したが、ユーザのその他の属性情報や、ユーザが所属するグループの権限などで判断してもよい。

Ｓ４０５で、認証サーバ１０２は、ユーザが複数のサブドメインのサービス利用権限を持たないので、アクセスした認証サーバが提供するサブドメインに限定したＣｏｏｋｉｅを発行し、そのＣｏｏｋｉｅに認証トークンを保存する。そして、Ｓ４０２で受け取ったアクセス要求への応答として、端末１０５に応答を返す。

Ｓ４０６では、認証サーバ１０２は、ユーザが複数のサブドメインのサービス利用権限を持つので、ドメイン範囲（利用範囲）が広いＣｏｏｋｉｅを発行し、そのＣｏｏｋｉｅに認証トークンを保存する。そして、Ｓ４０２で受け取ったアクセス要求への応答として端末１０５に応答を返す。本実施例では、ユーザが複数のサブドメインのサービス利用権限を持つので、ドメイン範囲が「ｅｘａｍｐｌｅ．ｃｏｍ」であるＣｏｏｋｉｅを発行して、発行したＣｏｏｋｉｅにユーザ「ａｄｍｉｎ＠１００１ＡＡ」の認証トークンを保存する。

Ｓ４０７において、端末１０５は、受け取ったＣｏｏｋｉｅを用いて、サービスの利用を行う。端末１０５は、受け取ったＣｏｏｋｉｅのドメイン範囲と一致するＷｅｂサービスにアクセスした際に、そのサービスに対してＣｏｏｋｉｅを送信する。Ｃｏｏｋｉｅを受け取ったサービスは、Ｃｏｏｋｉｅから認証トークンを取得してユーザを特定し、認証を要求せずにサービスの提供を行う。

以上説明した実施例１の方法により、ユーザの持つ権限によって自動でＣｏｏｋｉｅに設定するドメイン範囲が決定される。これにより、複数のサブドメインのサービスの利用権限を持たないユーザには、アクセスしたサブドメインのみを範囲としたＣｏｏｋｉｅが発行されるので、不要なサービスにＣｏｏｋｉｅ情報が送信されることを防ぐことができる。一方、複数のサブドメインのサービスの利用権限を持つユーザには、異なるサブドメインのサービスにアクセスした際にＣｏｏｋｉｅが送信されるので、異なるサブドメインのサービスも利用できる。

＜実施例２＞
実施例２では複数の異なるサブドメインのサービスを利用することを前提とする。複数のサブドメインのＷｅｂサービスを利用する場合でも、ドメイン範囲が広いＣｏｏｋｉｅを利用し続けると、意図しないサービスにＣｏｏｋｉｅを渡す危険性がある。実施例２においては、複数のサブドメインのＷｅｂサービスを利用する権限を持つユーザが、異なるサブドメインのサービスにアクセスした際のＣｏｏｋｉｅ管理について説明する。

図５は、認証サービスと、認証サービスのサブドメインと異なるサブドメインのリソースサービスとを利用する際のフローである。ここで、認証サービスは認証サーバ１０２によって提供され、サブドメインは「ＡＡＡ．ｅｘａｍｐｌｅ．ｃｏｍ」とする。またリソースサービスは、リソースサーバ１０３によって提供され（サービスＢ）、サブドメインは「ＢＢＢ．ｅｘａｍｐｌｅ．ｃｏｍ」とする。

Ｓ４０１〜Ｓ４０５の処理は、図４で説明したフローと同一なので説明を省略する。Ｓ５０１において、認証サーバ１０２は、ドメイン範囲が広いＣｏｏｋｉｅと、認証サーバ１０２のサブドメインに限定したドメイン範囲が狭いＣｏｏｋｉｅの２つを発行する。そしてＳ４０２で受け取ったアクセス要求への応答として端末１０５に応答を返す。本実施例では、ユーザＩＤ「ａｄｍｉｎ＠１００１ＡＡ」で認証したものとする。Ｓ５０１において、ドメイン「ｅｘａｍｐｌｅ．ｃｏｍ」を設定したドメイン範囲が広いＣｏｏｋｉｅと、認証サービスのサブドメイン「ＡＡＡ．ｅｘａｍｐｌｅ．ｃｏｍ」を設定したドメイン範囲が狭いＣｏｏｋｉｅが発行される。

Ｓ５０２で、ユーザは端末１０５上のＷｅｂブラウザ３２０を用いて、サービスＢを利用するために、リソースサーバ１０３に対してアクセスを行う。Ｓ５０３で、リソースサーバ１０３はＣｏｏｋｉｅから情報取得を行ない、続いてＳ５０４で、Ｃｏｏｋｉｅから情報を取得できたかどうか判定する。Ｃｏｏｋｉｅから認証情報が取得出来なかった場合はＳ５０５に進む。認証情報は、例えば、リソースサーバ１０３のドメインが利用出来るＣｏｏｋｉｅがＷｅｂブラウザ３２０に保存されていないがためにＣｏｏｋｉｅが送られなかった場合や、Ｃｏｏｋｉｅに認証情報が保存されていなかった場合などには取得出来ない。Ｓ５０５においては、リソースサーバ１０３は端末１０５に対して、サービスＢの利用権限がない旨を応答する。

Ｓ５０４で、Ｃｏｏｋｉｅから認証情報が取得できたと判定された場合はＳ５０６に進む。本実施例では、ドメイン「ｅｘａｍｐｌｅ．ｃｏｍ」を範囲としたＣｏｏｋｉｅが発行されているので、リソースサーバ１０３は、そのＣｏｏｋｉｅから認証トークンを取得できる。サブドメイン「ＡＡＡ．ｅｘａｍｐｌｅ．ｃｏｍ」を範囲としたＣｏｏｋｉｅしか発行されていない場合は、リソースサーバ１０３は、認証トークンが取得できないためにサービスを提供することができない。

Ｓ５０６において、Ｃｏｏｋｉｅから取得した認証情報を元に、ユーザがサービス利用権限を持つかどうか確認する。利用権限の確認は、認証サービス１０２に権限検証を要求したり、リソースサーバ１０３が取得したユーザ情報から判断したりして実行する。サービスの利用権限がなかった場合はＳ５０５に進み、利用権限があった場合にはＳ５０７に進む。本実施例では、Ｃｏｏｋｉｅから取得したユーザ「ａｄｍｉｎ＠１００１ＡＡ」の認証トークンを検証し、サービス利用権限ありと判断する。

Ｓ５０７において、リソースサーバ１０３は、サービスＢのサブドメインを範囲としたＣｏｏｋｉｅを発行し、そのＣｏｏｋｉｅにＳ５０３で取得した情報を保存する。本実施例では、サブドメイン「ＢＢＢ．ｅｘａｍｐｌｅ．ｃｏｍ」を範囲としたＣｏｏｋｉｅを発行し、そのＣｏｏｋｉｅにユーザ「ａｄｍｉｎ＠１００１ＡＡ」の認証トークンを保存する。

Ｓ５０８において、リソースサーバ１０３は、ドメイン範囲が広いＣｏｏｋｉｅを無効化する。本実施例では、ドメイン「ｅｘａｍｐｌｅ．ｃｏｍ」を範囲としたＣｏｏｋｉｅの有効期限を変更して有効期限切れとすることで、ドメイン範囲が広いＣｏｏｋｉｅを無効にする。Ｓ５０９で、リソースサーバ１０３はサービスＢの提供を行う。Ｓ５１０において、端末１０５は、端末１０５上のＷｅｂブラウザ３２０の画面に受け取った情報を表示する。

以上説明した実施例２の方法により、複数のサブドメインの利用権限を持つユーザが、異なるサブドメインのサービスにアクセスした時点で、ドメイン範囲の広いＣｏｏｋｉｅを無効にする。そのため、複数のサブドメインの利用権限を持つユーザであっても、意図しないサービスにＣｏｏｋｉｅ情報が送信されることを防ぐことができる。

＜実施例３＞
実施例３においては、ドメイン範囲が広いＣｏｏｋｉｅが発行されていない状態で、複数の異なるサブドメインのサービスを利用することを前提とする。図６Ａ、図６Ｂは、それぞれ異なるサブドメインのサービスである認証サービス、リソースサーバ１０３によるサービスＢ、リソースサーバ１０４によるサービスＣを利用する際のフローを示す図である。

先ず、図６ＡのＳ６０１で、端末１０５は、Ｗｅｂブラウザ３２０を用いて、リソースサーバ１０３にサービスＢの利用要求を行なう。Ｓ６０２で、リソースサーバ１０３は、Ｃｏｏｋｉｅから情報取得を行なう。ここでは、ドメイン範囲の広いＣｏｏｋｉｅおよびサービスＢ用のＣｏｏｋｉｅが共に発行されていないため、Ｃｏｏｋｉｅから情報は取得出来ない。そのためＳ６０３において、リソースサーバ１０３は、認証サーバ１０２に対するリダイレクト指示と共に認証要求を端末１０５に返す。Ｓ６０４で、端末１０５上のＷｅｂブラウザ３２０は、認証要求を認証サーバ１０２にリダイレクトする。

Ｓ６０５において、認証サーバ１０２は、Ｃｏｏｋｉｅから情報取得を行なう。ここでは、ドメイン範囲の広いＣｏｏｋｉｅおよび、認証サービス用のＣｏｏｋｉｅが共に発行されていないため、Ｃｏｏｋｉｅから情報は取得出来ない。Ｃｏｏｋｉｅから認証トークンが取得出来なかったため、認証サーバ１０２は、Ｓ４０２でユーザ認証を行う。なお、Ｓ４０２〜Ｓ４０５、及びＳ５０１の処理は、図５で説明したフローと同一なので説明を省略する。本実施例では、ユーザＩＤ「ａｄｍｉｎ＠１００１ＡＡ」で認証したものとする。そのため、Ｓ４０５において、ドメイン「ｅｘａｍｐｌｅ．ｃｏｍ」を設定したドメイン範囲が広いＣｏｏｋｉｅと、サブドメイン「ＡＡＡ．ｅｘａｍｐｌｅ．ｃｏｍ」を設定したドメイン範囲が狭いＣｏｏｋｉｅが発行される。Ｓ６０６で、端末１０５は、受け取った応答をＳ６０４の応答として、リソースサーバ１０３に対してリダイレクトする。

リソースサーバ１０３は、認証要求の応答を受け取ると、Ｃｏｏｋｉｅから情報を取得してサービス提供を行なう。なお、Ｓ５０３〜Ｓ５１０までの処理は、図５で説明したフローと同一なので説明を省略する。本実施例では、リソースサーバ１０３は、ドメイン範囲が広いＣｏｏｋｉｅから認証トークンを取得し、リソースサーバ１０３のサブドメイン「ＢＢＢ．ｅｘａｍｐｌｅ．ｃｏｍ」を設定したドメイン範囲が狭いＣｏｏｋｉｅを発行する。また、ドメイン範囲が広いＣｏｏｋｉｅの無効化を行う。Ｓ５１０の処理の後、フローは図６ＢのＳ６０７へ進む。

図６ＢのＳ６０７において、端末１０５は、端末１０５上のＷｅｂブラウザ３２０を用いて、リソースサーバ１０４にサービスＣの利用要求を行う。

Ｓ６０８において、リソースサーバ１０４は、Ｃｏｏｋｉｅから情報取得を行なう。ここでは、ドメイン範囲の広いＣｏｏｋｉｅおよびサービスＣのドメイン用Ｃｏｏｋｉｅが共に発行されていないため、Ｃｏｏｋｉｅから情報は取得出来ない。そのため、Ｓ６０９で、リソースサーバ１０４は認証サーバ１０２へのリダイレクト指示と共に認証要求を端末１０５に返す。

Ｓ６１０において、端末１０５上のＷｅｂブラウザ３２０は、認証要求を認証サーバ１０２にリダイレクトする。

Ｓ６１１で、認証サーバ１０２はＣｏｏｋｉｅから情報取得を行う。ここでは、認証サービスのサブドメイン「ＡＡＡ．ｅｘａｍｐｌｅ．ｃｏｍ」用のＣｏｏｋｉｅが発行されているため、そのＣｏｏｋｉｅから認証トークンが取得できる。認証サーバ１０２は、取得した認証トークンを用いて権限確認を行う。なお、Ｓ４０３〜Ｓ４０５及びＳ５０１の処理は、図５で説明したフローと同一なので説明を省略する。

本実施例では、サブドメイン「ＡＡＡ．ｅｘａｍｐｌｅ．ｃｏｍ」を設定したドメイン範囲が狭いＣｏｏｋｉｅは発行済みなので再発行はされず、ドメイン「ｅｘａｍｐｌｅ．ｃｏｍ」を設定したドメイン範囲が広いＣｏｏｋｉｅのみ発行される。

Ｓ６１２において、端末１０５は、受け取った応答をＳ６１０の応答として、リソースサーバ１０４に対してリダイレクトする。

リソースサーバ１０４は、認証要求の応答を受け取ると、Ｃｏｏｋｉｅから情報を取得してサービス提供を行う。なお、Ｓ５０３〜Ｓ５１０までは、図５で説明したフローと同様なので説明を省略する（図５のＳ５０７ではリソースサーバ１０３用のＣｏｏｋｉｅを発行するのに対し、図６ＢのＳ５０７ではリソースサーバ１０４用のＣｏｏｋｉｅを発行する点のみ異なる）。

以上説明した実施例３の方法により、Ｃｏｏｋｉｅが発行されていない状態でサービスにアクセスした際に、適宜ドメイン範囲が広いＣｏｏｋｉｅが発行される。その上で、アクセスしたサービスが、ドメイン範囲が広いＣｏｏｋｉｅを利用すると、そのドメイン範囲が広いＣｏｏｋｉｅが無効になる。そのため、複数のサブドメインのサービスを利用しつつ、意図しないサービスにＣｏｏｋｉｅ情報が渡ることを防ぐことができる。なお本実施例では、Ｓ４０３でユーザが複数のサブドメインのサービスの利用権限を持つかどうかの確認を行なうが、ここで利用要求されたサービスの利用権限があるかをどうかを判定しても良い。

＜その他の実施例＞
本発明は、上述の実施例の１以上の機能を実現するプログラムを、ネットワーク又は記憶媒体を介してシステム又は装置に供給し、そのシステム又は装置のコンピュータにおける１つ以上のプロセッサーがプログラムを読出し実行する処理でも実現可能である。また、１以上の機能を実現する回路（例えば、ＡＳＩＣ）によっても実現可能である。

１０２ 認証サーバ
１０３ リソースサーバ
１０４ リソースサーバ
１０５ 端末
３０２ データ管理部
３２０ Ｗｅｂブラウザ

Claims (7)

1. 端末から認証サーバへのアクセスを受け付け、認証されたユーザーが同一ドメインの中の複数のサブドメインが提供する複数のサービスを利用する権限を持つかどうかを確認する確認手段と、
   前記確認手段により前記ユーザーが前記権限を持つと確認された場合に、前記複数のサブドメインを利用範囲とするクッキーを前記端末に発行し、前記確認手段により前記ユーザーが前記権限を持たないと確認された場合に、前記複数のサブドメインを利用範囲とするクッキーを発行するのではなくて前記認証サーバのサブドメインを利用範囲とするクッキーを前記端末に発行する発行手段とを有することを特徴とする認証サーバ。
2. 前記発行手段は、前記確認手段により前記ユーザーが前記権限を持つと確認された場合は、前記複数のサブドメインを利用範囲とする前記クッキーとともに前記認証サーバのサブドメインを利用範囲とする前記クッキーも発行することを特徴とする請求項１に記載の認証サーバ。
3. 前記認証サーバはリソースサーバと連携しており、前記端末が前記リソースサーバにアクセスした場合、前記リソースサーバは、前記発行手段が発行した前記複数のサブドメインを利用範囲とする前記クッキーを取得し、取得した前記クッキーに基づいて、前記リソースサーバのサブドメインを利用範囲とするクッキーを発行することを特徴とする請求項２に記載の認証サーバ。
4. 前記リソースサーバは、取得した前記クッキーを、前記リソースサーバのサブドメインを利用範囲とする前記クッキーを発行した後に無効化することを特徴とする請求項３に記載の認証サーバ。
5. 前記リソースサーバは、前記端末が前記リソースサーバにアクセスした際に前記ユーザーが有効なクッキーを取得できない場合は、前記認証サーバに対し認証を要求し、前記認証サーバは該要求に応答して、前記確認手段および前記発行手段による処理を行なうことを特徴とする請求項３に記載の認証サーバ。
6. 端末から認証サーバへのアクセスを受け付け、認証されたユーザーが同一ドメインの中の複数のサブドメインが提供する複数のサービスを利用する権限を持つかどうかを確認する確認ステップと、
   前記確認ステップにより前記ユーザーが前記権限を持つと確認された場合に、前記複数のサブドメインを利用範囲とするクッキーを前記端末に発行し、前記確認ステップにより前記ユーザーが前記権限を持たないと確認された場合に、前記複数のサブドメインを利用範囲とするクッキーを発行するのではなくて前記認証サーバのサブドメインを利用範囲とするクッキーを前記端末に発行する発行ステップとを有することを特徴とする、認証サーバにおける認証方法。
7. 請求項１〜５のいずれか１項に記載の認証サーバをコンピュータで実現させるためのプログラム。

Images