JP6305005B2 - 認証サーバーシステム、制御方法、そのプログラム - Google Patents

Description

本発明は、サービス利用時の通知に関する制御を行う認証サーバーシステム、制御方法、そのプログラムに関する。

近年、サービスと呼ばれる例えばインターネットを介してソフトウェアの機能を提供するシステムが注目を集めている。サービスは、共有のサーバー上に展開した同一のＷｅｂアプリケーションを複数の企業や組織に提供する“マルチテナントサービス”という形態をとっている。ここで“テナント”とは、従来の専用サーバーを用いてサービスを提供していた企業や組織の単位を意味する。

このようなサービスにおいて、サービス提供者がサービス利用者に対してシステムメンテナンス情報や新機能情報など、通知情報を発信する場合がある。特にシステムメンテナンスなどによりサービスが停止する場合には、利用者への通知が重要となる。もし通知がされないと、利用者観点では突然サービスが停止したように見えてしまうため、問題となる可能性がある。ここで、各ユーザーにメールで通知する方法も有効ではあるが、メールアドレスが登録されていないユーザーがいる場合もあり、それだけでは十分ではない。そのため、ユーザーがサービスにログインした際に、通知情報を表示する機能が求められている。

ユーザーがサービスの利用に際しサービスを提供するシステムにログインした際に、通知情報を表示する機能として、ユーザーの個人情報に表示情報を関連付けて管理する方法が従来から知られている（参考文献１）。この方法では、サービス提供者が通知したい情報を強制表示情報としてユーザーに設定する事で、そのユーザーがログインした際に通知情報を画面に表示する事が出来る。以上が通知情報に関する従来技術の説明である。

次に、サービスのマッシュアップ時における認証処理について従来技術を説明する。マッシュアップによって連携する複数のサービスはそれぞれ別のサービスとなるため、それぞれのサービス提供システムにログインを行う必要がある。しかし、複数のサービスが連携している際に、それぞれのサービス提供システムにアクセスする毎にログイン画面が表示され、ログイン操作を行うのが手間である。この手間をなくすため、ＳＡＭＬ（Ｓｅｃｕｒｉｔｙ Ａｓｓｅｒｔｉｏｎ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）によるＳｉｎｇｌｅ Ｓｉｇｎ Ｏｎ（ＳＳＯ）を利用する場合がある。シングルサインオン認証方式（以降、ＳＳＯ）では、ある１つのサービス提供システムをＩｄｅｎｔｉｔｙ Ｐｒｏｖｉｄｅｒ（ＩｄＰ）とし、その他のサービス提供システムをＳｅｒｖｉｃｅ Ｐｒｏｖｉｄｅｒ（ＳＰ）とする。ユーザーはＩｄＰであるサービス提供システムにログインすることで、ログイン操作を行わずに他のサービスを利用することが出来る。例えばＰＤＦを作成するサービス提供システムをＩｄＰ、インターネット上にデータを保存するサービス提供システムをＳＰとする。ユーザーがＩｄＰであるＰＤＦ作成サービスにアクセスすると、ログイン画面が表示され、ユーザーはログイン操作を１度行う。するとその後、生成したＰＤＦをＳＰであるサービス提供システムに保存する際には、ＳＰでのログインは要求されず、シームレスに２つのサービスをマッシュアップさせることが可能になる。

特開２００３−２５６３８２号公報

一方で、ＳＳＯなどにより複数のサービスが連携した際に各サービスがそれぞれ通知情報を表示すると通知の表示により連携処理が止まってしまうという課題がある。ユーザーが通常のログイン操作を行ってサービスにアクセスする際には、ユーザーはそのサービスを意識し画面操作を行っているため、通知情報を表示しても問題とはなりにくい。しかし、ＳＳＯ連携によりユーザーが複数のサービスを意識せずに利用できている状態においては、サービス間のシームレスな連携による操作感を損ねてしまう可能性がある。

本願発明は、ＳＳＯを始めとする一部の認証処理を省略する様な認証方式であるか否かに基づき通知情報の通知制御を行うことで、上述した課題を解決する認証サーバーシステムを提供することを目的とする。

本発明の一実施形に係る認証サーバーシステムは、サービスの利用に関する認証処理を行う認証サーバーシステムであって、ユーザーに認証情報の入力を要求し、入力された前記認証情報を受け付けて前記認証情報を基に認証処理を行う第１の認証方式、および前記認証サーバーシステムとは異なる別の認証サーバーシステムにおいて行われた認証処理が成功したことに応じて、ユーザーに認証情報の入力を要求せずに前記認証情報を受け付けることなく認証処理を行う第２の認証方式、両方の認証方式による認証処理を行う認証手段と、ユーザーが操作する端末に前記サービスに関連する通知を行う通知手段と、前記認証手段により前記第１の認証方式による認証処理が行われた結果、前記端末による前記サービスの利用が許可された場合は前記通知手段による通知が行われるように制御し、前記認証手段により前記第２の認証方式による認証処理が行われた結果、前記端末による前記サービスの利用が許可された場合は前記通知手段による通知が行われないように制御する制御手段と、を有し、し、前記認証手段は、前記別の認証サーバーシステムにおいて行われた認証処理が成功したことに応じて発行される認可情報を受け付けた場合に前記認可情報を基に前記第２の認証方式による認証処理を行い、前記端末による前記サービスの利用を許可し、前記制御手段は、前記認証手段が前記認可情報を検証したことに応じて前記端末へ送信するレスポンスを取得し、前記レスポンスから前記第２の認証方式による認証処理が行われたことを特定し、前記通知手段による通知が行われないように制御することを特徴とする。

本発明により、ＳＳＯを始めとする一部の認証処理を省略する様な認証方式により複数のサービスが連携した際に各サービスがそれぞれ通知情報を表示することを抑制することが可能になる。

システム全体図 サーバーのハードウェア構成図 リソースサーバーのソフトウェア構成図 認証サーバーのソフトウェア構成図 サービス管理サーバーのソフトウェア構成図 外部認証サーバーのソフトウェア構成図 認証サーバー１０３が保持するアカウントテーブル サービス管理サーバー１０４が保持する通知情報テーブル ユーザーへの通知情報表示判定フロー図 ユーザーがＳＳＯによりアクセスした際の通知情報表示判定フロー図 ユーザーがＳＳＯ以外の方法でアクセスした際の通知情報表示判定フロー図 サービス管理サーバー１０４が保持する通知情報テーブル 認証サーバー１０３が保持するテナントテーブル 認証サーバー１０３が保持するライセンステーブル ユーザーがアクセスした際の、ライセンス提供した販売会社による通知情報表示判定フロー図 認証サーバー１０３が保持する顧客テナントテーブル ユーザーがアクセスした際の、テナント単位での通知情報表示判定フロー図 認証サーバー１０３が保持するテナントテーブル 認証サーバー１０３が保持するアカウントテーブル ユーザーがアクセスした際の、ユーザー単位での通知情報表示判定フロー図 サービス管理サーバー１０４が保持する除外ＵＲＬテーブル ユーザーがアクセスした際の、ＵＲＬ単位での通知情報表示判定フロー図 サービス管理サーバー１０４が保持する通知情報テーブル 通知情報登録画面 ユーザーがアクセスした際の、認証方式による通知情報表示判定フロー図

本願発明におけるサービスとは、情報処理装置が提供する機能のことを指す。サービスを実現するＷｅｂアプリケーションなどは、サーバーコンピューターで実行されるソフトウェアである。ここで複数のサービスが連携する際に、１つのサービスを利用しているように見せるために、ＳＡＭＬによるＳＳＯを利用する場合がある。ＳＳＯを実現する事で、ユーザーは１度のログインで連携している全てのサービスを利用できるようになる。本願発明ではＳＳＯを例に、認証処理時に用いられた認証方式がＳＳＯである場合はクライアントへ通知を行わないように制御する情報処理システムについて説明する。

図１は、その情報処理システムを示す図である。インターネット１００は、インターネットなどの外部から接続可能なパブリックなネットワークである。イントラネット１０１は、ＬＡＮなどの外部から接続不可能なプライベートなネットワークである。

リソースサーバー１０２は、印刷サービスや帳票サービスといったリソースサービスを提供しているサービスシステムである。リソースサーバー１０２は、インターネット１００を介したクライアント端末１０６あるいは不図示の外部サービスシステムからのリクエストに応じて、リソースサービスを提供する。なおリソースサーバー１０２に設置されるリソースサービスは１つでもよく、複数でもよい。

認証サーバー１０３は、ユーザーを認証する認証サーバーである。認証サーバー１０３は、ユーザーに対してリソースサーバー１０２やサービス管理サーバー１０４へのアクセスを制御する。サービス管理サーバー１０４は、通知情報の管理や、通知情報画面生成を行う。

リソースサーバー１０２、認証サーバー１０３、サービス管理サーバー１０４はそれぞれ連携しサービスシステム１０５を構成する。サービスシステム１０５がサービス提供システムであり、ユーザーにサービスを提供する上で必要となるサーバー群である。なお、リソースサーバー１０２、認証サーバー１０３、サービス管理サーバー１０４は同一のサーバー上に構成されていてもよいし、同一のＬＡＮ上に構成されてもよいし、それぞれ個別のＬＡＮ上に構成されてもよい。また、実施例１において各サーバーは１台ずつ設置されているが、複数台で構成されていてもよい。よって、本願発明においてサーバーシステムと称した場合、１台、または複数台で構成されているサーバーを指しているものとする。例えば、認証サーバーシステムと称した場合、対象は１台の認証サーバー、または認証サーバー、およびサービス管理サーバー１０４の複数台で構成されたサーバー群の何れか１つとして捉えられることになる。

クライアント端末１０６は、インターネット１００を介して、パーソナルコンピューターやモバイル端末などのサービスを利用する際に使用される情報機器端末であり、Ｗｅｂブラウザがインストールされている。外部認証サーバー１０７は、Ｉｄｅｎｔｉｔｙ Ｐｒｏｖｉｄｅｒ（ＩｄＰ）であり、サービスシステム１０５における認証サーバー１０３とは別に提供される認証サーバーである。

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

図３は、リソースサーバー１０２のソフトウェア構造を示したブロック図である。リクエスト処理部３０１は、インターネット１００を経由して送信されたリソースサービスへのリクエストを処理する処理部である。例えばリソースサービスが帳票サービスの場合、帳票データ生成リクエスト及び帳票データ取得リクエストを受信する。また、リクエスト処理部３０１は、機能制御部３０２から返される処理結果を呼び出し元に返す。機能制御部３０２は、リクエスト処理部３０１が受信したリクエストに応じて必要な処理を行い、応答データを呼び出し元に返す。また、機能制御部３０２はイントラネット１０１経由で認証サーバー１０３に対して認証リクエストを送信し、認証結果を受信する。処理部３０３は、機能制御部３０２からのリクエストを受信して、リクエストに応じた処理を行い、機能制御部３０２に返す。例えば帳票サービスの場合、帳票データ生成リクエストを受信して、元データから帳票データを生成する。

図４は、認証サーバー１０３のソフトウェア構造を示したブロック図である。リクエスト処理部４０１は、認証サーバー１０３がインターネット１００及びイントラネット１０１を経由して受信した認証サーバーへのリクエストを処理する処理部である。また、リクエスト処理部４０１は、アクセス制御部４０２から返される応答データを呼び出し元に返す。アクセス制御部４０２は、データ管理部４０３から取得するデータに基づき、サービスシステム１０５内の各リソースサーバーからの認証および認可要求を処理する処理部である。また、ＩｄＰから送られるＳＡＭＬの検証を行う。認証データ管理部４０３は、ユーザーアカウントのデータを管理する。以上から、サービスシステム１０５はＳＰであると言える。なお、認証サーバー１０３は入力されたユーザーの認証情報を基に認証処理を行う認証方式、およびＳＳＯの認証方式、両方の認証方式による認証処理を行う。詳細は、後述する図１０、および図１１にて説明を行う。

図５は、サービス管理サーバー１０４のソフトウェア構造を示したブロック図である。リクエスト処理部５０１は、サービス管理サーバー１０４へのリクエストを処理する処理部である。またリクエスト処理部５０１は、機能制御部５０２から返される応答データを呼び出し元に返す。機能制御部５０２は、認証サーバー１０３にユーザー情報取得を要求し、取得したデータとデータ管理部５０３から取得するデータにより通知情報表示を制御する処理部である。データ管理部５０３は、通知情報のデータを管理する。

図６は、外部認証サーバー（ＩｄＰ）１０７のソフトウェア構造を示したブロック図である。リクエスト処理部４０１は、認証サーバー１０３がインターネット１００及びイントラネット１０１を経由して受信した認証サーバーへのリクエストを処理する処理部である。また、リクエスト処理部４０１は、アクセス制御部４０２から返される応答データを呼び出し元に返す。アクセス制御部４０２は、データ管理部４０３から取得するデータに基づき、各サービスシステムからの認証および認可要求を処理する処理部である。また、ＳＰに対してＳＡＭＬの検証要求を行う。認証データ管理部４０３は、ユーザーアカウントのデータを管理する。

図７は、認証サーバー１０３が管理するユーザーアカウント情報のデータ構造をテーブル形式で示した図である。アカウントテーブル７００は、ユーザーＩＤ７０１、テナントＩＤ７０２、通知済みリビジョン７０３からなる。テナントＩＤ７０２は、ユーザーが所属するテナントをシステムで一意に識別するためのＩＤである。通知済みリビジョン７０３は、そのユーザーに表示した通知情報を示す番号である。通知済みリビジョン７０３には、後述する通知情報テーブル８００に登録されているリビジョン番号を保存する。

図８は、サービス管理サーバー１０４が管理する通知情報のデータ構造をテーブル形式で示した図である。通知情報テーブル８００は、通知ＩＤ８０１、リビジョン８０２、掲載開始日８０３、掲載終了日８０４、通知内容８０５からなる。なお、掲載開始日、掲載終了日ではなく掲載日数として管理しても良いので、これらをまとめて通知期間と定義する。リビジョン８０２は、通知情報が掲載された時点で採番され、ユーザーがどの通知まで表示したかを示すための情報である。具体的には、２０１３年１０月１２日になると、通知ＩＤ「５」の通知が掲載開始日となる。その時点で通知情報テーブル８００に登録されているリビジョン番号の最大値が「３」であるので、通知ＩＤ「５」に対して、リビジョン番号「４」が割り当たる。通知内容８０５は、通知画面に表示される文字列である。なお通知内容８０５は、言語毎に別テーブルで管理してもよい。

図９は、リソースサーバー１０２、認証サーバー１０３、サービス管理サーバー１０４からなるサービスシステム１０５がＷｅｂブラウザを搭載した端末であるクライアント端末１０６からアクセスを要求された際の、通知情報表示判定フローである。サービスシステム１０５の各サーバー間での具体的なデータの送受信については、後述の図１０、図１１に示す。

ステップＳ９０１においてサービスシステム１０５はアクセス要求を受け付け、ステップＳ９０２においてアクセス要求者の認証を行う。ステップＳ９０３において、サービスシステム１０５は、ステップＳ９０２で行った認証方式がＳＳＯであるか否かの判定を行う。認証方式がＳＳＯであった場合、サービスシステム１０５の通知情報は表示しないように制御するものと判断し、ステップＳ９０４において、ステップＳ９０１でアクセス要求された画面を表示する。なお、ここではステップＳ９０２ではＳＳＯであるか否かの判定を行う形式を説明したが、ＳＳＯであるか、それとも別の認証方式であるかを判定するような認証方式の種類を基に判定する形式であっても良い。

認証方式がＳＳＯではなかった場合、即ち、認証サーバー１０３がユーザーに認証情報の入力を要求し、入力された認証情報を受け付けてその認証情報を基に認証処理を行う認証式の場合、サービスシステム１０５はステップＳ９０５において、掲載中の通知情報の内、認証したユーザーが未表示の通知情報があるかを確認する。掲載中の通知情報がなかった場合や、認証したユーザーが全ての掲載中の通知情報を表示済みだった場合、通知なしと判断し、ステップＳ９０４において、アクセス要求された画面を表示する。掲載中の通知情報がある場合、ステップＳ９０６において、不図示の通知画面を生成し、通知画面を表示する。なお通知画面においては、掲載中の全ての通知情報を表示してもよいし、ログインしたユーザーが未表示の通知情報のみを表示してもよい。認証方式がＳＳＯであった場合、Ｓ９０４で通知画面を表示することなくサービスを受ける上で必要な画面を表示する。

図１０は、ユーザーがＩｄＰである外部認証サーバー１０７のＷｅｂページよりログインを行い、ＳＡＭＬによるＳＳＯでサービスシステム１０５にアクセスした際の処理方法を示すシーケンス図である。なお前提として、認証サーバー１０３とＩｄＰである外部認証サーバー１０７は事前にＳＡＭＬによるＳＳＯに必要な設定が全てなされているものとする。

ステップＳ１００１において、クライアント端末１０６上のＷｅｂブラウザ（不図示）を用いて、外部認証サーバー１０７の不図示のログイン画面にアクセスを行う。アクセスされた外部認証サーバー１０７は、ステップＳ１００２においてクライアント端末１０６から入力されたユーザー認証情報を基に認証処理を行い、ステップＳ１００３においてＳＡＭＬレスポンスの生成を行う。一般的なＩｄＰで生成するＳＡＭＬレスポンスでは認証したユーザーを識別する情報等が含まれており、さらにそのレスポンス情報は電子署名されている。外部認証サーバー１０７はサービスシステム１０５に対するリダイレクトの指示と共に、クライアント端末１０６にレスポンスを返す。

ステップＳ１００４において、クライアント端末１０６上のＷｅｂブラウザは外部認証サーバー１０７から受け取ったＳＡＭＬレスポンスと共に、認証サーバー１０３に対してＳＡＭＬ検証要求を行う。ステップＳ１００５において、認証サーバー１０３は受け取ったＳＡＭＬレスポンスが正規なものであるか否かを検証する。本検証では、ＳＡＭＬレスポンスの電子署名を、事前に設定したＩｄＰの電子証明書に基づき正規なものであるか否かを検証し、その上でＳＡＭＬレスポンスに含まれるユーザー識別情報を取得する。さらに、事前に設定したＩｄＰのユーザーと本システムのユーザーのマッピング情報を元に、ＳＡＭＬレスポンスから取得したユーザー識別情報を認証サーバー１０３が管理している本システムのユーザーに変換してログインを許可し、認証セッションを生成する。

ステップＳ１００６において、認証サーバー１０３は、サービスシステム１０５へのアクセス時の認証方式がＳＡＭＬによるＳＳＯなのか、それ以外の認証方式なのかを判定する。ここで、認証サーバー１０３は認証サーバーのＷｅｂページへのアクセスのレスポンスを全てフックするように設定されている。一般的なＷｅｂサーバーは外部モジュールを追加する事で、ＨＴＴＰ機能の処理途中に自由に処理を追加する事が可能である。認証サーバー１０３は、認証方式がＳＳＯであるか否かの判定を行うためにＳＳＯフックモジュールを追加し、認証サーバーでの全てのＷｅｂページのＨＴＴＰレスポンスをフックしている。

なお、ＳＳＯフックモジュールは認証サーバー１０３の全てのレスポンスの処理で実行されるため、例えばログイン画面へのレスポンスなどもフックされる。認証サーバー１０３は認証方式がＳＡＭＬによるものなのか否かを判断するために、ＳＡＭＬ検証のためのＵＲＬを記憶し、フックしたレスポンスのリクエストＵＲＬの確認を行う。例えばＳＡＭＬ検証ＵＲＬとして“／ａｕｔｈ／Ｓａｍｌ／ＳＰ／ＳＳＯ／Ｐｏｓｔ”を保持していた場合、フックしたレスポンスのリクエストＵＲＬを確認し、ＳＡＭＬ検証ＵＲＬとの比較を行う。もしフックしたレスポンスがＳＡＭＬ検証ＵＲＬへのリクエストであったならば、認証サーバー１０３は認証方式がＳＡＭＬによるＳＳＯであると判断する。さらに認証サーバー１０３は、認証方式がＳＡＭＬによるＳＳＯである事を検証すると、通知情報表示はなしと判断しレスポンスを返す。

ステップＳ１００７において、クライアント端末１０６上のＷｅｂブラウザは、認証サ−バー１０３から受け取ったレスポンスに含まれる、ＳＡＭＬ検証成功後のリソースサービスへのリダイレクト先ＵＲＬへとリダイレクトを行う。ステップＳ１００８において、リソースサーバー１０２は要求された画面を生成し、クライアント端末１０６に返す。クライアント端末１０６は、ステップＳ１００９において、受け取った画面をクライアント端末１０６上のＷｅｂブラウザに表示する。

図１１は、ユーザーがＳＰである認証サーバー１０３のＷｅｂページよりログインを行い、認証情報であるＩＤとパスワードを入力してサービスシステム１０５にアクセスした際の処理方法を示すシーケンス図である。即ち、図１０のフローに示すＳＳＯによる認証方式の認証処理ではない場合のフローである。

ステップＳ１１０１において、クライアント端末１０６上のＷｅｂブラウザ（不図示）を用いて、認証サーバー１０３の不図示のログイン画面にアクセスを行う。アクセスされた認証サーバー１０３は、ステップＳ１１０２において認証処理を行い、ステップＳ１００３においてＳＡＭＬレスポンスの生成を行う。ステップＳ１００３において、認証サーバー１０３は、フックしたレスポンスのＵＲＬを確認し、認証方式がＳＡＭＬによるＳＳＯなのか、それ以外の認証方式なのかを判定する。認証サーバー１０３は、認証方式がＳＳＯ以外であると判定すると、サービス管理サーバー１０４に対して認証結果を渡し、通知表示判定を要求する。

ステップＳ１１０４において、サービス管理サーバー１０４は、受け取った認証結果を利用し、認証されたユーザー情報の取得を要求する。ステップＳ１１０５において、認証サーバー１０３は、認証されたユーザーの情報をアカウントテーブル７００から取得し、サービス管理サーバー１０４に返す。本例では、ユーザーＩＤ「ｕｉｄ００００００２」のユーザーが、「２０１３年１０月１０日」にアクセスしたものとする。

ステップＳ１１０６において、サービス管理サーバー１０４は、通知情報テーブル８００の情報と、取得したユーザー情報から、認証したユーザーに未表示の通知情報があるかを判定する。具体的には、通知情報テーブルから、現在掲載中の通知情報としてリビジョン「１」「２」「３」があると判断する。その上で、ユーザーＩＤ「ｕｉｄ００００００２」のユーザーの通知済みリビジョンが「１」であるため、リビジョン「２」「３」の通知は未表示であると判断される。

ステップＳ１１０７において、サービス管理サーバー１０４は、認証したユーザーに未表示の通知情報があるかを判定する。未表示の通知情報がない場合には、図１０と同様に、ステップＳ１００７にてリクエストされた画面を生成し、ステップＳ１００８でクライアント端末１０６上のＷｅｂブラウザに表示する。未表示の通知情報があった場合、ステップＳ１１０８において、不図示の通知画面を生成し、クライアント１０６に返す。なお通知画面には、掲載中の全ての通知情報を表示してもよいし、ログインしたユーザーが未表示の通知情報のみを表示してもよい。具体的には、掲載中の通知情報であるリビジョン「１」「２」「３」の通知を全て表示してもよく、ユーザーＩＤ「ｕｉｄ００００００２」のユーザーが未表示のリビジョン「２」「３」の通知のみを表示してもよい。ステップＳ１１０９において、クライアント端末１０６は、受け取った通知画面を表示する。なお、通知画面はログイン画面から遷移した同じ画面に表示してもよく、別のウインドウでポップアップして開いてもよい。その後、図１０と同様に、リクエストした画面を表示する。

本願発明の実施例１により、ＳＡＭＬによるＳＳＯによりアクセスしたユーザーには通知情報を表示せず、ＳＡＭＬによるＳＳＯ以外の方法でアクセスしたユーザーには未表示の通知情報を表示する事が出来る。

次に、認証時に通知情報を強制表示しない第２の形態について説明する。マルチテナントサービスであるサービスにおいては、ユーザーは組織や企業を示すテナントに所属し、そのテナントの設定に従ってサービスを利用する。またサービスでは、ユーザーにサービスを販売する販売会社もテナントとして管理する場合がある。販売会社用のテナント（以下、販売テナント）に所属するユーザー（以下、販売ユーザー）は、顧客用のテナント（以下、顧客テナント）の作成や、顧客テナントへのサービスの提供を行える。

ここで、販売会社テナントによっては、利便性を重視しＳＡＭＬによるＳＳＯ以外の認証の場合でも通知情報を画面に表示させないという設定を行う場合が考えられる。本形態では、認証方式以外に販売テナント単位で通知情報の表示を行うか判定する方式について説明する。

図１２は、認証方式に加え、販売会社テナントの単位で通知情報を表示するかの判定を行う際の、サービス管理サーバー１０４が管理する通知情報のデータ構造をテーブル形式で示した図である。通知情報テーブル１２００は、通知ＩＤ８０１、リビジョン８０２、ライセンスＩＤ１２０１、掲載開始日８０３、掲載終了日８０４からなる。ライセンスＩＤ１２０１は、通知情報が関係するサービスを示すＩＤである。

図１３は、認証サーバー１０３が管理するテナント情報のデータ構造をテーブル形式で示した図である。販売テナントを管理するテーブルは販売テナントテーブル１３００、顧客テナントを管理するテーブルは顧客テナントテーブル１３１０で管理される。販売テナントテーブル１３００は、テナントＩＤ１３０１、テナント名１３０２、通知表示１３０３からなる。通知表示１３０３は、ＳＡＭＬによるＳＳＯ以外の方法で認証した際に、未表示の通知を表示するかの設定である。通知表示が「しない」となっている場合、ログインしたユーザーに未表示の通知があったとしても、通知画面を表示しない。顧客テナントテーブル１３１０は、テナントＩＤ１３１１、テナント名１３１２から成る。

図１４は、認証サーバー１０３が管理するサービス情報のデータ構造をテーブル形式で示した図である。サービスを管理する情報はサービステーブル１４００、顧客テナントが利用できるサービスを管理する情報はライセンステーブル１４１０、販売テナントが販売できるサービスを管理する情報は販売権テーブル１４２０で管理される。販売テナントのユーザーが顧客にサービスを販売すると、そのサービスに対応するライセンスが対象の顧客テナントに設定される。顧客テナントのユーザーは、自テナントに設定されているライセンスに対応するサービスを利用できる。サービステーブル１４００は、サービス名１４０１、ライセンスＩＤ１４０２からなる。ライセンスＩＤ１４０２は、サービスをシステムが一意に識別するためのＩＤである。ライセンステーブル１４１０は、テナントＩＤ１４１１、ライセンスＩＤ１４１２、販売テナントＩＤ１４１３からなる。テナントＩＤ１４１１は、ライセンスが設定されている顧客テントを示す。ライセンスＩＤ１４１２は、その顧客テナントに設定されているライセンスを示す。販売テナントＩＤ１４１３は、顧客テナントにライセンスを設定した販売ユーザーが所属する販売テナントのテナントＩＤを示す。販売権テーブル１４２０は、テナントＩＤ１４２１とライセンスＩＤ１４２２からなる。

図１５は、本実施形態において、サービスシステム１０５がアクセスを要求された際の通知情報表示判定フローである。ステップＳ９０１からＳ９０３は図９で説明したフローと同じである。ステップＳ１５０１において、サービスシステム１０５はアカウントテーブ７００から認証したユーザーの所属テナントを取得し、販売テナントテーブル１３００と顧客テナントテーブル１３１０から、そのユーザーのテナントを判定する。もし認証したユーザーが販売テナントのユーザーであった場合、ステップＳ１５０２を行う。また、認証したユーザーが顧客テナントのユーザーであった場合、ステップＳ１５０３を行う。

認証したユーザーが販売テナントに所属していた場合、ステップＳ１５０２において、サービスシステム１０５は、販売テナントテーブル１３００からユーザーが所属する販売テナントの通知情報を取得する。もし認証したユーザーが所属する販売テナントの通知設定が「通知しない」であったならば、通知情報は表示せず、図９で説明したステップＳ９０４に進み、アクセス要求先画面を表示する。また、もし販売テナントの通知設定が「通知する」であったならば、ステップＳ１５０３を行う。

ステップＳ１５０３において、サービスシステム１０５は、認証した販売テナントのユーザーに未表示の通知があるかを判定する。サービスシステム１０５は、販売権テーブル１４２０とサービステーブル１４００から、対象の販売テナントが扱えるサービスを取得する。そして通知情報テーブル１２０１から、対象の販売テナントが扱えるサービスの掲載中の通知情報を取得する。その上で、アカウントテーブル７００から、認証したユーザーに通知済みのリビジョンを取得し、表示する通知情報を決定する。認証したユーザーが所属する販売テナントが扱えるサービスについて、掲載中の通知情報がない場合や、掲載中の通知情報が全てユーザーに通知済みであった場合、通知表示は行わず、ステップＳ９０４に進む。認証したユーザーが所属するテナントが扱えるサービスについて、認証したユーザーに未表示の通知があったならば、ステップＳ９０６で通知情報を表示する。以降のフローは図９で説明したものとなる。

例えば、ユーザーＩＤ「ｕｉｄ００００００１」のユーザーが、「２０１３年１０月１０日」にアクセスしたものとする。アカウントテーブル７００から、「ｕｉｄ００００００１」のユーザーはテナントＩＤ「９００ＡＡ」に所属している事が分かり、販売テナントテーブル１３００から販売テナントであると判断される。ここで、販売テナントテーブル１３００から、テナントＩＤ「９００ＡＡ」は通知を「表示する」となっているため、サービスシステム１０５は、通知表示判定を行う。サービステーブル１４００と販売権テーブル１４２０から、テナントＩＤ「９００ＡＡ」はライセンスＩＤ「１」である「サービスＬ」と、ライセンスＩＤ「３」である「サービスＮ」が扱える事がわかる。また、アカウントテーブル７００から、「ｕｉｄ００００００１」のユーザーは「リビジョン１」の通知まで表示している事がわかる。これらの情報と通知情報テーブル１２００を元に、サービスシステム１０５は、サービスＬのリビジョン「２」、サービスＮのリビジョン「３」の通知情報を表示すると判定する。

認証したユーザーが顧客テナントに所属していた場合、ステップＳ１５０４において、サービスシステム１０５はライセンステーブル１４１０から、ユーザーが所属するテナントにライセンスを設定した販売テナントを取得する。そして販売テナントテーブル１３００から、各販売テナントが通知表示をするかの判定を行う。もしライセンスを設定した全ての販売テナントが通知を「表示しない」設定の場合、通知情報は表示せず、図９で説明したステップＳ９０４に進み、アクセス要求先画面を表示する。また、１つでも通知を「表示する」販売テナントがあったならば、ステップＳ１５０５を行う。

ステップＳ１５０５において、サービスシステム１０５は、通知を「表示する」となっていた販売テナントから設定されたサービスについて、通知を行うかの判定を行う。サービスシステム１０５は、通知情報テーブル１２００から、通知を「表示する」となっていた販売テナントから設定されたサービスに、掲載中の通知があるかを判定する。その上で、アカウントテーブル７００から、認証したユーザーに通知済みのリビジョンを取得し、表示する通知情報を決定する。掲載中の通知がない場合や、掲載中の通知情報が全てユーザーに通知済みであった場合、通知表示は行わず、ステップＳ９０４に進む。もし認証したユーザーに未表示の通知があったならば、ステップＳ９０６で通知情報を表示する。以降のフローは図９で説明したものとなる。

例えば、ユーザーＩＤ「ｕｉｄ００００００６」のユーザーが、「２０１３年１０月１０日」にアクセスしたものとする。アカウントテーブル７００から、「ｕｉｄ００００００６」のユーザーはテナントＩＤ「１００２ＡＡ」に所属しており通知をリビジョン「１」まで表示している事が分かり、顧客テナントテーブル１３１０から顧客テナントであると判断される。また、ライセンステーブル１４１０から、販売テナント「９００ＡＡ」からライセンスＩＤ「１」を、「９０１ＡＡ」からライセンスＩＤ「２」と「３」を設定されている事が分かる。ここで、販売テナントテーブル１３００より、「９００ＡＡ」は通知を「表示する」設定となっており、「９０１ＡＡ」は通知を「表示しない」設定となっている。そのためサービスシステム１０５は、テナントＩＤ「１００２ＡＡ」に所属するユーザーには、ライセンスＩＤ「１」に対応する「サービスＬ」の通知のみを表示すると判断する。これらの情報と通知情報テーブル１２００を元に、サービスシステム１０５は、サービス「Ｌ」のリビジョン「２」の通知情報を表示すると判断する。

実施例２の方法により、ＳＡＭＬによるＳＳＯ以外の方法でアクセスしたユーザーに対して、販売テナントの設定により未表示の通知情報を表示するかを制御出来る。

次に、認証時に通知情報を強制表示しない第３の形態について説明する。マルチテナントサービスであるサービスにおいては、テナント単位で組織や企業を管理しており、各テナントに対して企業や組織毎のカスタムを行える。そのため、顧客テナント毎に、ＳＡＭＬによるＳＳＯ以外の認証の場合でも、通知情報を画面に表示させないという設定を行う場合が考えられる。本形態では、認証方式以外に、顧客テナント単位で通知情報の表示を行うか判定する方式について説明する。

図１６は、認証サーバー１０３が管理する顧客テナント情報のデータ構造をテーブル形式で示した図である。顧客テナントテーブル１６００は、テナントＩＤ１３１１、テナント名１３１２、通知表示１６０１から成る。通知表示１６０１は、ＳＡＭＬによるＳＳＯ以外の方法で認証した際に、未表示の通知を表示するかの設定である。通知表示が「しない」となっている場合、ログインしたユーザーに未表示の通知があったとしても、通知画面を表示しない。

図１７は、本実施形態において、サービスシステム１０５がアクセスを要求された際の通知情報表示判定フローである。ステップＳ９０１からＳ９０３は図９で説明したフローと同じである。ステップＳ１７０１において、サービスシステム１０５はアカウントテーブル７００から認証したユーザーの所属テナントを取得し、顧客テナントテーブル１６００から、そのユーザーのテナントを判定する。もし認証したユーザーが顧客テナントのユーザーであった場合、ステップＳ１７０２を行う。また、もし認証したユーザーが顧客テナントのユーザーでなかった場合、ステップＳ９０５に進み、以下図９で説明したフローを実施する。

ステップＳ１７０２において、サービスシステム１０５は顧客テナントテーブル１６００から、認証したユーザーの所属テナントの通知表示を確認する。もし通知を「表示する」設定の場合、ステップＳ９０５に進み、以下図９で説明したフローを実施する。もし通知を「表示しない」設定の場合、通知情報は表示せず、図９で説明したステップＳ９０４に進み、アクセス要求先画面を表示する。例えば、ユーザーＩＤ「ｕｉｄ００００００６」のユーザーが、「２０１３年１０月１０日」にアクセスしたものとする。アカウントテーブル７００から、「ｕｉｄ００００００６」のユーザーはテナントＩＤ「１００２ＡＡ」に所属しており通知をリビジョン「１」まで表示している事が分かる。また、顧客テナントテーブル１６００から顧客テナントであると判断され、通知を「表示しない」テナントに所属している事が分かる。これにより、サービスシステム１０５は、通知を表示しない、と判断する。

実施例３の方式により、ＳＡＭＬによるＳＳＯ以外の方法でアクセスしたユーザーに対して、顧客テナントの設定により未表示の通知情報を表示するかを制御出来る。

次に、認証時に通知情報を強制表示しない第４の形態について説明する。マルチテナントサービスであるサービスにおいては、テナント内にその企業や組織の管理者と、一般のユーザーが混在した状態で管理される。一般ユーザーアカウントと管理者アカウントを分けて管理すると、一般ユーザーからのエスカレーションなどが発生した際に、新たなアカウントを作成しなくてはならず手間が大きく、また現在の利用者情報や設定が引き継げないという問題がある。そのため、一般ユーザーアカウントに権限設定を行う事で、管理者アカウントとする事も可能である。

ここで、ＳＡＭＬによるＳＳＯ以外の認証の場合でも、ユーザーの権限によって通知情報を画面に表示させない設定を行う場合が考えられる。例えば通知がある場合にも、一般ユーザーには表示を行わず、管理者のみに表示するなどが考えられる。本形態では、認証方式以外に、ユーザーアカウント単位で通知情報の表示を行うか判定する方式について説明する。

図１８は、認証サーバー１０３が管理するテナント情報のデータ構造をテーブル形式で示した図である。販売テナントを管理するテーブルは販売テナントテーブル１８００、顧客テナントを管理するテーブルは顧客テナントテーブル１８１０で管理される。販売テナントテーブル１８００は、テナントＩＤ１３０１、テナント名１３０２、管理者への通知表示１８０１、一般者への通知表示１８０２からなる。管理者への通知表示１８０１は、ＳＡＭＬによるＳＳＯ以外の方法で認証した際に、販売テナントの管理者に未表示の通知を表示するかの設定である。通知表示が「しない」となっている場合、管理者アカウントのユーザーがログインした場合に、未表示の通知があったとしても、通知画面を表示しない。一般者への通知表示１８０２は、ＳＡＭＬによるＳＳＯ以外の方法で認証した際に、販売テナントの一般ユーザーに未表示の通知を表示するかの設定である。

顧客テナントテーブル１８１０は、テナントＩＤ１３０１、テナント名１３０２、管理者への通知表示１８１１、一般者への通知表示１８１２からなる。管理者への通知表示１８１１は、ＳＡＭＬによるＳＳＯ以外の方法で認証した際に、顧客テナントの管理者に未表示の通知を表示するかの設定である。通知表示が「しない」となっている場合、管理者アカウントのユーザーがログインした場合に、未表示の通知があったとしても、通知画面を表示しない。一般者への通知表示１８１２は、ＳＡＭＬによるＳＳＯ以外の方法で認証した際に、顧客テナントの一般ユーザーに未表示の通知を表示するかの設定である。

図１９は、認証サーバー１０３が管理するユーザーアカウント情報のデータ構造をテーブル形式で示した図である。アカウントテーブル１９００は、ユーザーＩＤ７０１、テナントＩＤ７０２、通知済みリビジョン７０３、管理者１９０１からなる。管理者１９０１は、対象のアカウントが管理者かを管理する情報である。

図２０は本実施形態において、サービスシステム１０５がアクセスを要求された際の通知情報表示判定フローである。ステップＳ９０１からＳ９０３は図９で説明したフローと同じである。ステップＳ２００１において、サービスシステム１０５は認証したユーザーの権限から、通知表示する設定なのかを判定する。サービスシステム１０５は、アカウントテーブル１９００から認証したユーザーのテナントＩＤと、管理者かの情報を取得する。その後販売テナントテーブル１８００と顧客テナントテーブル１８１０から、認証したユーザーに通知表示するかの判定を行う。もし認証したユーザーが通知表示しない設定ならば、通知画面を表示せず、ステップＳ９０４に進み、アクセス要求先画面を表示する。もし認証したユーザーが通知表示する設定ならば、ステップＳ９０５に進み、以下図９で説明したフローを実施する。

実施例４の方法により、ＳＡＭＬによるＳＳＯ以外の方法でアクセスしたユーザーに対して、テナント毎の設定とユーザーの権限に従って、未表示の通知情報を表示するかを制御出来る。

次に、認証時に通知情報を強制表示しない第５の形態について説明する。複数の機能を持ち、機能単位などで複数の画面を持つサービスにおいて、あるサービス利用時には通知を表示するが、そのサービスの特定の機能を利用する際のみ、通知を表示しない事が求められる場合がある。また、他サービスと連携している際に、特定の連携先から呼び出された際や、特定の機器から呼び出された際に通知を表示しない事が求められる場合もある。例えば複合機の画面の様な小さい画面からアクセスされた際に、画面に通知情報が収まりきらない、といった問題が考えられる。本形態では、認証方式以外に、アクセス先単位で通知情報の表示を行うか判定する方式について説明する。

図２１は、サービス管理サーバー１０４が管理する除外ＵＲＬのデータ構造をテーブル形式で示した図である。除外ＵＲＬテーブル２１００は、ＵＲＬ２１０１からなる。ＵＲＬ２１０１は、アクセス時に通知表示をしないＵＲＬを示す。なおＵＲＬ２１０１は、ＵＲＬパラメーターなど、ＵＲＬの一部のみでもよい。

図２２は本実施形態において、サービスシステム１０５がアクセスを要求された際の通知情報表示判定フローである。ステップＳ９０１からＳ９０３は図９で説明したフローと同じである。ステップＳ２２０１において、サービスシステム１０５はアクセスされたＵＲＬが除外ＵＲＬか否かの判定を行う。アクセスされたＵＲＬが除外ＵＲＬテーブル２１００に含まれるか確認し、含まれていた場合には通知表示を表示せず、ステップＳ９０４に進み、アクセス要求先画面を表示する。もし除外ＵＲＬに含まれていなかったならば、ステップＳ９０５に進み、以下図９で説明したフローを実施する。例えば特定の小さい画面の機器から呼び出す際に、アクセス先ＵＲＬにＵＲＬパラメーターを追加し、サービスシステム１０５を呼び出す。サービスシステム１０５は、パラメーターが除外ＵＲＬに登録されている事を確認し、通知表示なしと判断する。

実施例５の方法により、ＳＡＭＬによるＳＳＯ以外の方法でアクセスしたユーザーに対して、アクセス先ＵＲＬによって未表示の通知情報を表示するかを制御出来る。

次に、認証時に通知情報を強制表示しない第６の形態について説明する。認証方式による通知情報の表示を管理した際に、特定の認証方式の場合のみ通知情報を表示したい場合が考えられる。例えばＳＡＭＬによるＳＳＯを行う際に、ＳＰ側にＩｄＰが発行したＳＡＭＬ証明書を事前に登録する必要がある。このＳＡＭＬ証明書を登録することで複数のサービスシステムがシングルサインオン連携することができる。だが、このＳＡＭＬ証明書の有効期限が切れるとＳＡＭＬによるＳＳＯが出来なくなる。そのため、ＳＳＯによりアクセスしているユーザーに対して、このようなＳＳＯが利用できなくなるといった情報のみは、表示する必要が考えられる。本形態では、認証方式ごとに、特別に通知情報を表示する方式について説明する。

図２３は、サービス管理サーバー１０４が管理する通知情報のデータ構造をテーブル形式で示した図である。通知情報テーブル２３００は、通知ＩＤ８０１、リビジョン８０２、掲載開始日８０３、掲載終了日８０４、認証方式２３０１、通知内容８０５からなる。認証方式２３０１は、その通知が特定の認証方式に対して通知するかを管理している。

図２４は本実施形態において、通知情報を登録する画面を示した図である。通知登録画面２４００は、サービス選択部２４０１、掲載開始日入力部２４０２、掲載終了日入力部２４０３、認証方式選択部２４０４、通知タイトル入力部２４０５、情報入力部２４０６、登録ボタン２４０７、登録キャンセルボタン２４０８から構成される。サービス選択部２４０１は、登録する通知が対応するサービスを選択する選択部である。なおサービス選択部２４０１は必須ではなく、項目が存在しなくてもよいし、空を指定してもよい。認証方式選択部２４０２は、登録する通知が対応する認証方式を選択する選択部である。サービスシステム１０５が対応している１つまたは複数の選択肢からなり、複数を一度に選択する事も出来る。

図２５は本実施形態において、サービスシステム１０５がアクセスを要求された際の通知情報表示判定フローである。ステップＳ９０１からＳ９０６は図９で説明したフローと同じである。ステップＳ２５０１において、サービスシステム１０５は、掲載中の通知に認証方式がＳＳＯの場合に表示する通知があるかを判定する。通知情報テーブル２３００から、掲載中の通知に対して、認証方式２３０１が設定されているかを確認する。もしＳＳＯの場合に表示する通知がない場合には、通知表示を表示せず、ステップＳ９０４に進み、アクセス要求先画面を表示する。もし掲載中の通知にＳＳＯの場合に表示する通知があった場合、ステップＳ２５０２に進む。本例では、ユーザーＩＤ「ｕｉｄ００００００２」のユーザーが、「２０１３年１０月１０日」にＳＳＯでアクセスしたものとする。すると、通知情報テーブル２３００では、通知リビジョン「１」「２」「３」が掲載中と判断され、さらに通知リビジョン「１」と「３」の通知は、認証方式がＳＳＯの際に表示する通知であると判断される。

ステップＳ２５０２において、サービスシステム１０５は、認証したユーザーが掲載中のＳＳＯの場合に表示する通知が表示済みかを判定する。もしＳＳＯの場合に表示する通知が表示済みであった場合には、通知表示を表示せず、ステップＳ９０４に進み、アクセス要求先画面を表示する。もし掲載中の通知にＳＳＯの場合に表示する通知があった場合、ステップＳ９０６に進み、以下図９で説明したフローを実施する。本例では、ユーザーテーブル７００から、ユーザーＩＤ「ｕｉｄ００００００２」のユーザーはリビジョン「１」の通知のみ表示している。そして通知情報テーブルから、リビジョン「１」と「３」の通知がＳＳＯの場合に表示する通知だと判断される。ここで、ユーザーＩＤ「ｕｉｄ００００００２」のユーザーはリビジョン「１」の通知は表示済みだが、リビジョン「３」の通知は表示していないため、サービスシステム１０５は、通知を表示すると判断し、通知画面を表示する。なお、表示する通知は表示していないＳＳＯ関連通知であるリビジョン「３」だけでもよく、全てのＳＳＯ関連通知であるリビジョン「１」「３」でもよく、また掲載中の全ての通知であるリビジョン「１」「２」「３」でもよい。

実施例６の方法により、ＳＡＭＬによるＳＳＯによりアクセスしたユーザーには通知情報を表示しないが、ＳＡＭＬに関係する通知のみは表示する事が出来る。

（その他の実施例）
これまでの説明で各実施例が独立して実施される形態を説明したが、各実施例を組み合わせて本願発明を実施することも可能である。例えば、図１５のＳ９０３でＹｅｓと判定された後、図２５のＳ２５０１以降の判定処理を行い認証方式がＳＳＯ認証でありＳＳＯ認証処理が行われた場合であっても通知を行うことが可能である。

また、各実施例では２つの認証方式をベースに説明を行った。即ち１つ目は、ユーザーに認証情報の入力を要求し、入力された認証情報を受け付けてその認証情報を基に認証処理を行う認証方式である。２つ目は、外部認証サーバー１０７において行われた認証処理が成功したことに応じて、ユーザーに認証情報の入力を要求せず、事前にＳＡＭＬ証明書の交換が済んでおりＳＳＯ連携が定まっている外部認証サーバー１０７において認証処理が行われた結果発行された認可情報であるＳＡＭＬレスポンスを基に認証処理を行う認証方式、即ちシングルサイオン認証方式である。しかし、認証方式はこれらの方式でなくても良い。特に後者の認証式はＳＳＯである必要はなくＯＡＵＴＨのようなユーザーの権限を他のサービスへ移譲する形式であっても良い。ＯＡＵＴＨの場合、ユーザーが権限を移譲することを許可したことで発行されるＯＡＵＴＨトークンを基に、図９のＳ９０３を行えば良い。ＯＡＵＴＨと判断された場合は、通知が行われないように制御される。

また、本願発明は、以下の処理を実行することによっても実現される。即ち、上述した実施例の機能を実現するソフトウェア（プログラム）を、ネットワーク又は各種記憶媒体を介してシステム或いは装置に供給し、そのシステム或いは装置のコンピュータ（またはＣＰＵやＭＰＵ等）がプログラムを読み出して実行する処理である。

Claims (6)

1. サービスの利用に関する認証処理を行う認証サーバーシステムであって、
   ユーザーに認証情報の入力を要求し、入力された前記認証情報を受け付けて前記認証情報を基に認証処理を行う第１の認証方式、および前記認証サーバーシステムとは異なる別の認証サーバーシステムにおいて行われた認証処理が成功したことに応じて、ユーザーに認証情報の入力を要求せずに前記認証情報を受け付けることなく認証処理を行う第２の認証方式、両方の認証方式による認証処理を行う認証手段と、
   ユーザーが操作する端末に前記サービスに関連する通知を行う通知手段と、
   前記認証手段により前記第１の認証方式による認証処理が行われた結果、前記端末による前記サービスの利用が許可された場合は前記通知手段による通知が行われるように制御し、前記認証手段により前記第２の認証方式による認証処理が行われた結果、前記端末による前記サービスの利用が許可された場合は前記通知手段による通知が行われないように制御する制御手段と、を有し、
   前記認証手段は、前記別の認証サーバーシステムにおいて行われた認証処理が成功したことに応じて発行される認可情報を受け付けた場合に前記認可情報を基に前記第２の認証方式による認証処理を行い、前記端末による前記サービスの利用を許可し、
   前記制御手段は、前記認証手段が前記認可情報を検証したことに応じて前記端末へ送信するレスポンスを取得し、前記レスポンスから前記第２の認証方式による認証処理が行われたことを特定し、前記通知手段による通知が行われないように制御することを特徴と
   する認証サーバーシステム。
2. 前記制御手段は、前記第１の認証方式による認証処理が行われた結果、前記端末による前記サービスの利用が許可された場合において、前記通知手段による通知を行わないように設定されている際は、前記通知手段による通知が行われないように制御することを特徴とする請求項１に記載の認証サーバーシステム。
3. 前記通知手段は、通知期間、通知内容、および前記通知内容が対応する認証方式を関連づけて保存するテーブルに基づき、前記通知期間の内に前記通知内容を通知し、
   前記制御手段は、前記第２の認証方式による認証処理が行われた結果、前記端末による前記サービスの利用が許可された場合において、前記通知期間の内に通知すべき前記通知内容があり、かつ前記通知内容が前記第２の認証方式に対応している際は、前記通知手段による通知が行われるように制御することを特徴とする請求項１または２に記載の認証サーバーシステム。
4. 前記通知期間、前記通知内容を設定するための項目と、前記通知内容が前記第２の認証方式に対応することを設定するための項目とを含む通知登録画面を提供する提供手段を更に有し、
   前記提供手段により提供された通知登録画面の項目に設定された情報を前記テーブルに保存することを特徴とする請求項３に記載の認証サーバーシステム。
5. 前記第２の認証方式とは、シングルサインオン認証方式であることを特徴とする請求項１乃至４の何れか１項に記載の認証サーバーシステム。
6. サービスの利用に関する認証処理を行う認証サーバーシステムを制御する制御方法であって、
   認証手段は、ユーザーに認証情報の入力を要求し、入力された前記認証情報を受け付けて前記認証情報を基に認証処理を行う第１の認証方式、および前記認証サーバーシステムとは異なる別の認証サーバーシステムにおいて行われた認証処理が成功したことに応じて、ユーザーに認証情報の入力を要求せずに前記認証情報を受け付けることなく認証処理を行う第２の認証方式、両方の認証方式による認証処理を行い、
   通知手段は、ユーザーが操作する端末に前記サービスに関連する通知を行い、
   制御手段は、前記認証手段により前記第１の認証方式による認証処理が行われた結果、前記端末による前記サービスの利用が許可された場合は前記通知手段による通知が行われるように制御し、前記認証手段により前記第２の認証方式による認証処理が行われた結果、前記端末による前記サービスの利用が許可された場合は前記通知手段による通知が行われないように制御し、
   前記認証手段は、前記別の認証サーバーシステムにおいて行われた認証処理が成功したことに応じて発行される認可情報を受け付けた場合に前記認可情報を基に前記第２の認証方式による認証処理を行い、前記端末による前記サービスの利用を許可し、
   前記制御手段は、前記認証手段が前記認可情報を検証したことに応じて前記端末へ送信するレスポンスを取得し、前記レスポンスから前記第２の認証方式による認証処理が行われたことを特定し、前記通知手段による通知が行われないように制御することを特徴とする制御方法。

Images