TOP > 国内特許検索 > 権限委譲システム、権限委譲方法および権限委譲プログラム > 明細書

明細書 :権限委譲システム、権限委譲方法および権限委譲プログラム

発行国 日本国特許庁(JP)
公報種別 特許公報(B2)
特許番号 特許第5170648号 (P5170648)
公開番号 特開2009-205342 (P2009-205342A)
登録日 平成25年1月11日(2013.1.11)
発行日 平成25年3月27日(2013.3.27)
公開日 平成21年9月10日(2009.9.10)
発明の名称または考案の名称 権限委譲システム、権限委譲方法および権限委譲プログラム
国際特許分類 G06F  21/41        (2013.01)
G06F  21/33        (2013.01)
G06F  21/34        (2013.01)
H04L   9/32        (2006.01)
FI G06F 21/20 141
G06F 21/20 133
G06F 21/20 134
H04L 9/00 675D
請求項の数または発明の数 9
全頁数 32
出願番号 特願2008-045784 (P2008-045784)
出願日 平成20年2月27日(2008.2.27)
審査請求日 平成23年1月14日(2011.1.14)
特許権者または実用新案権者 【識別番号】000004226
【氏名又は名称】日本電信電話株式会社
【識別番号】504132272
【氏名又は名称】国立大学法人京都大学
発明者または考案者 【氏名】橋本 正一
【氏名】青柳 真紀子
【氏名】永井 靖浩
【氏名】古村 隆明
個別代理人の代理人 【識別番号】100089118、【弁理士】、【氏名又は名称】酒井 宏明
【識別番号】100112656、【弁理士】、【氏名又は名称】宮田 英毅
審査官 【審査官】▲吉▼田 耕一
参考文献・文献 特開2004-206187(JP,A)
特開2001-243517(JP,A)
特開平06-188905(JP,A)
特開2006-004314(JP,A)
特開2006-221506(JP,A)
特開2005-010301(JP,A)
調査した分野 G06F 21/20
H04L 9/32
特許請求の範囲 【請求項1】
アプリケーションサーバ各々を利用する利用者の本人性を認証サーバが認証する構成の下、所定のアプリケーションサーバを利用する権限を他の利用者から委譲された利用者について当該利用者の権限を判定し、当該利用者による当該アプリケーションサーバの利用を制御する権限委譲システムであって、
利用者の本人性を確認可能な情報を格納する格納媒体に、当該格納媒体を利用する利用者が他の利用者から委譲された権限に関する権限委譲情報を格納する格納手段を備え、
前記認証サーバは、
所定のアプリケーションサーバへアクセスすることを要求するアクセス要求を利用者が利用する利用者端末から受け付けた際に、当該利用者が利用する格納媒体に格納されている情報に基づいて当該利用者の本人性を認証するとともに、前記格納手段によって当該格納媒体に格納された権限委譲情報もしくは当該権限委譲情報から導出される情報を、当該アクセス要求にて指定されたアプリケーションサーバに転送する権限委譲情報転送手段を備え、
前記アプリケーションサーバ各々は、
前記権限委譲情報転送手段によって転送された前記権限委譲情報もしくは前記情報を受け付けると、当該権限委譲情報もしくは当該情報から、委譲された権限の内容を抽出し、抽出した当該内容を確認することで、当該権限委譲情報を格納する格納媒体の利用者の権限を判定する判定手段と、
を備えたことを特徴とする権限委譲システム。
【請求項2】
前記権限委譲情報は、委譲の対象となるアプリケーションの種別、および/または、委譲の範囲により、複数のパターンで定義されるものであって、
前記格納手段は、前記複数のパターンの内のいずれかのパターンを、前記権限委譲情報として前記格納媒体に格納することを特徴とする請求項1に記載の権限委譲システム。
【請求項3】
前記格納手段は、権限を他の利用者に委譲する権限委譲者を識別する利用者IDと、権限を委譲される被権限委譲者を識別する利用者IDと、委譲の対象となるアプリケーションの種別および/または委譲の範囲により定義される権限委譲情報のパターンと、当該委譲が有効である有効期限とを、当該権限委譲者によって指定されることで、前記権限委譲情報として前記格納媒体に格納することを特徴とする請求項1または2に記載の権限委譲システム。
【請求項4】
前記権限委譲システムは、発行局サーバと登録局サーバと失効リストリポジトリサーバと登録端末とから構成されるものであって、
前記発行局サーバは、
利用者の本人性を確認するための利用者証明書を発行する利用者証明書発行手段と、
前記権限委譲情報を確認するための権限委譲証明書を発行する権限委譲証明書発行手段とを備え、
前記登録局サーバは、
前記利用者証明書および前記権限委譲証明書の発行申請を受け付ける申請受付手段と、
前記申請受付手段によって受け付けた利用者証明書の発行を前記発行局サーバに要求する利用者証明書発行要求手段と、
前記申請受付手段によって受け付けた権限委譲証明書の発行を前記発行局サーバに要求する権限委譲証明書発行要求手段と、
前記利用者証明書発行手段によって発行された利用者証明書を取得し、当該利用者証明書を申請した利用者が利用する前記登録端末に対して、当該利用者証明書を送信する利用者証明書送信手段と、
前記権限委譲証明書発行手段によって発行された権限委譲証明書を取得し、当該権限委譲証明書によって権限を委譲された利用者が利用する所定の端末に対して、当該権限委譲証明書を送信する権限委譲証明書送信手段とを備え、
前記失効リストリポジトリサーバは、
前記利用者証明書および/または前記権限委譲証明書が失効しているか否かをアプリケーションサーバに通知する通知手段を備え、
前記登録端末は、
前記利用者証明書送信手段によって送信された利用者証明書を取得する利用者証明書取得手段を備え、
前記所定の端末は、
前記権限委譲証明書送信手段によって送信された権限委譲証明書を取得する権限委譲証明書取得手段を備えたことを特徴とする請求項1~3のいずれか一つに記載の権限委譲システム。
【請求項5】
前記登録端末は、
権限を他の利用者に委譲する権限委譲者を識別する利用者ID、権限を委譲される被権限委譲者を識別する利用者ID、委譲の対象となるアプリケーションの種別および/または委譲の範囲により定義される権限委譲情報のパターン、および当該委譲が有効である有効期限の指定を権限委譲者から受け付け、前記登録局サーバに送信することで、権限委譲証明書の発行申請を行う権限委譲証明書申請手段を備え、
前記登録局サーバは、
前記権限委譲者の本人性を、当該権限委譲者が利用する格納媒体に格納された利用者証明書により認証する第1の利用者認証手段と、
前記第1の利用者認証手段によって前記権限委譲者の本人性が認証されたことを条件として、前記権限委譲証明書申請手段によって申請された権限委譲証明書の発行を、前記発行局サーバに送信する権限委譲証明書発行要求手段と、
前記被権限委譲者の本人性を、当該被権限委譲者が利用する格納媒体に格納された利用者証明書により認証する第2の利用者認証手段と、
前記第2の利用者認証手段によって前記被権限委譲者の本人性が認証されたことを条件として、当該被権限委譲者が利用する所定の端末に権限委譲証明書を送信する権限委譲証明書送信手段とを備え、
前記発行局サーバの権限委譲証明書発行手段は、前記権限委譲証明書申請手段によって受け付けられた情報に基づいて、前記権限委譲証明書を発行することを特徴とする請求項4に記載の権限委譲システム。
【請求項6】
前記認証サーバは、
他の利用者から権限を委譲された被権限委譲者の本人性を、当該被権限委譲者が利用する格納媒体に格納された利用者証明書により認証する認証手段を備え、
前記アプリケーションサーバは、
前記認証手段によって前記被権限委譲者の本人性が確認されたことを条件として、当該被権限委譲者が利用する格納媒体に格納された権限委譲証明書を要求する権限委譲証明書要求手段と、
前記権限委譲証明書要求手段によって要求した権限委譲証明書を取得すると、前記被権限委譲者に委譲された権限が有効期限を経過しているか否か、および、当該権限が失効しているか否かを確認する第1の確認手段と、
前記第1の確認手段によって、権限の有効期限を経過していないこと、および、当該権限が失効していないことが確認されたことを条件として、当該委譲の対象および委譲の範囲を確認し、前記被権限委譲者に対して当該アプリケーションサーバを利用する権限を認可するか否かを決定する第2の確認手段と、
を備えたことを特徴とする請求項1~5のいずれか一つに記載の権限委譲システム。
【請求項7】
アプリケーションサーバ各々を利用する利用者の本人性を認証サーバが認証する構成の下、所定のアプリケーションサーバを利用する権限を他の利用者から委譲された利用者について当該利用者の権限を判定し、当該利用者による当該アプリケーションサーバの利用を制御する権限委譲方法であって、
利用者の本人性を確認可能な情報を格納する格納媒体に、当該格納媒体を利用する利用者が他の利用者から委譲された権限に関する権限委譲情報を格納する格納工程を含み、
前記認証サーバは、
所定のアプリケーションサーバへアクセスすることを要求するアクセス要求を利用者が利用する利用者端末から受け付けた際に、当該利用者が利用する格納媒体に格納されている情報に基づいて当該利用者の本人性を認証するとともに、前記格納工程によって当該格納媒体に格納された権限委譲情報もしくは当該権限委譲情報から導出される情報を、当該アクセス要求にて指定されたアプリケーションサーバに転送する権限委譲情報転送工程を含み、
前記アプリケーションサーバ各々は、
前記権限委譲情報転送工程によって転送された前記権限委譲情報もしくは前記情報を受け付けると、当該権限委譲情報もしくは当該情報から、委譲された権限の内容を抽出し、抽出した当該内容を確認することで、当該権限委譲情報を格納する格納媒体の利用者の権限を判定する判定工程と、
を含んだことを特徴とする権限委譲方法。
【請求項8】
アプリケーションサーバ各々を利用する利用者の本人性を認証サーバが認証する構成の下、所定のアプリケーションサーバを利用する権限を他の利用者から委譲された利用者について当該利用者の権限を判定し、当該利用者による当該アプリケーションサーバの利用を制御する権限委譲方法をコンピュータに実行させる権限委譲プログラムであって、
利用者の本人性を確認可能な情報を格納する格納媒体に、当該格納媒体を利用する利用者が他の利用者から委譲された権限に関する権限委譲情報を格納する格納手順をコンピュータに実行させ、
前記認証サーバとしてのコンピュータに、
所定のアプリケーションサーバへアクセスすることを要求するアクセス要求を利用者が利用する利用者端末から受け付けた際に、当該利用者が利用する格納媒体に格納されている情報に基づいて当該利用者の本人性を認証するとともに、前記格納手順によって当該格納媒体に格納された権限委譲情報もしくは当該権限委譲情報から導出される情報を、当該アクセス要求にて指定されたアプリケーションサーバに転送する権限委譲情報転送手順を実行させ、
前記アプリケーションサーバ各々としてのコンピュータに、
前記権限委譲情報転送手順によって転送された前記権限委譲情報もしくは前記情報を受け付けると、当該権限委譲情報もしくは当該情報から、委譲された権限の内容を抽出し、抽出した当該内容を確認することで、当該権限委譲情報を格納する格納媒体の利用者の権限を判定する判定手順と、
を実行させることを特徴とする権限委譲プログラム。
【請求項9】
アプリケーションサーバ各々を利用する利用者の本人性を認証サーバが認証する構成の下、所定のアプリケーションサーバを利用する権限を他の利用者から委譲された利用者について当該利用者の権限を判定し、当該利用者による当該アプリケーションサーバの利用を制御する権限委譲方法であって、
利用者の本人性を確認可能な情報を格納する格納媒体に、当該格納媒体を利用する利用者が他の利用者から委譲された権限に関する権限委譲情報であって、前記アプリケーションサーバにおいて委譲された権限の内容が抽出され、抽出された当該内容が確認されることで、当該格納媒体の利用者の権限が判定される権限委譲情報を格納する格納工程を含んだことを特徴とする権限委譲方法。
発明の詳細な説明 【技術分野】
【0001】
本発明は、権限委譲システム、権限委譲方法および権限委譲プログラムに関する。
【背景技術】
【0002】
教育機関や企業等でのサービス・業務の電子化は急速に進展しつつあり、クライアント-サーバによるWEBアプリケーションが利用されている。これらのサービス・業務のアプリケーションリソースに利用者がアクセスするには、アクセスしようとする本人性の確認が必要なことから、IDとパスワード、ICカード、電子証明書、バイオメトリックスを用いた本人性の確認行為、すなわち、個人認証が行われている(非特許文献1、非特許文献2を参照)。
【0003】
図14に、従来のサービス・業務のアプリケーションごとの認証処理の概要を示す。個人認証は、通常、サービスや業務ごとに行われることから、それぞれの認証サーバが、ID払い出し機能によりIDおよび初期パスワードを発行し、認証情報を管理するためのディレクトリデータベースにこれらの情報を格納するとともに、これらの情報を利用者に電子メールや通知書等により通知する。利用者は、なりすましを防止するため、各認証サーバに対して初期パスワードの変更登録を実施し、以降、自己責任によりこれを管理・運用しなければならない。
【0004】
一方、アプリケーション側が利用者に対して、サービス・業務アプリケーションのリソース使用を許可する認可処理については、個人認証処理が認可と等価であったため、認証と認可は一体として扱われ、利用者およびアプリケーション側は認可を意識することはなかった。
【0005】
ところが、利用者の立場で、複数のIDやパスワードを管理・運用することは繁雑であり、せっかくの電子化のメリットとなるべき利便性を損なっている。このため、利用者の利便性向上、IDとパスワードの漏洩等によるなりすましリスクの抑制、アプリケーション側の視点からは、IDとパスワードの管理コストの低減、および、認証システムの設備投資や運用作業量の抑制などを実現するため、個人認証を複数のサービス・業務で一括して行うシングルサインオンといった認証方式が導入されつつある。
【0006】
シングルサインオン認証は、一度の認証で、複数のサービス・業務を収容するポータル画面に遷移し、以降、シングルログアウトするまで、ポータルに提示されたサービス・業務のアプリケーションにアクセスできるという認証方式である。図15に、IDおよびパスワードによるシングルサインオン認証処理の流れを示す。利用者は、ポータルのURL(Uniform Resource Locator)をクライアント端末に入力し、クライアント端末は、認証サーバへポータルへのアクセス要求を行う。すると、認証サーバは、クライアント端末へ認証情報を要求し、利用者は、IDおよびパスワードをクライアント端末に入力する。そして、クライアント端末は、IDおよびパスワードを認証サーバへ送信し、認証サーバは、ディレクトリデータベースの認証情報とマッチングを行い、本人性を判定する。この結果、正しいと判定されれば、認証サーバは、クライアント端末へポータルのURLアクセスを許可し、シングルサインオン認証処理が完了する。
【0007】
この機能により、利用者は、複数のサービス・業務ごとにIDおよびパスワードを覚えることから解放され、利便性が著しく向上する。一方、バックエンドのアプリケーション側も、IDの発行やそれに伴うIDのライフサイクル管理が一元化される。また、サービス・業務ごとに行っていたサービス・業務の個人認証という行為は大幅に軽減され、認証システムの開発・保守におけるコストや運用稼動の分割損も大きく改善される。
【0008】

【非特許文献1】“ベリサインマネージドPKI”、[online]、[平成20年2月6日検索]、インターネット<http://www.verisign.co.jp/mpki/solution/authdevice/companyid.html>
【非特許文献2】“ID管理システム「GreenOffice Directory」”、[online]、[平成20年2月6日検索]、インターネット<http://www.kccs.co.jp/products/directory/index.html>
【発明の開示】
【発明が解決しようとする課題】
【0009】
ところで、上記した従来の技術では、権限を他の利用者に委譲する権限委譲者から、権限を他の利用者から委譲される被権限委譲者に対して、権限を適切に委譲することができないという課題があった。
【0010】
すなわち、上記してきたように、利用者やアプリケーションサーバ側にとっての利便性向上、IDライフサイクル管理の軽減、認証機能の開発・運用などのコスト低減の観点から、シングルサインオン認証は非常に有効である。ところが、例えば、教育機関や企業における予算権限あるいは業務権限を有する教職員あるいは部課長以上の利用者は、多忙なため、バックエンドアプリケーションへアクセスする権限を、部下あるいは秘書などへ委譲しているという実態があるが、その多くは、IDおよびパスワードを被権限委譲者に教えるといったレベルであり、ミスや不正利用に対して非常にリスクの高いものであった。
【0011】
また、適切な権限委譲の一つの方法として、個別のサービス・業務のアプリケーションに対して、利用者が被権限委譲者を決め、対象業務、委譲範囲、有効期限を通知するといった処理が必要であった。この方法は、権限を委譲する利用者の負担が大きいことと同時に、アプリケーションサーバ側の審査などの負担が大きくなるといった課題があった。別の方法として、シングルサインオン認証に利用するディレクトリデータベースに権限委譲に関わる認可情報を登録する方法もあるが、権限を委譲する利用者の負担が大きいことに加えて、ディレクトリデータベースを更新する作業が増えるとともに、アプリケーション側と連携して内容を確認するといった作業も増えるなど、トータルな仕事量が増えるといった課題があった。
【0012】
さらに、権限を委譲した利用者本人の異動や委譲された人が異動した際には、異動した利用者本人が、失効をアプリケーションサーバ側あるいはディレクトリデータベースに対して迅速に申請しなければならない。これらの更新処理も、アプリケーションサーバ側あるいはディレクトリデータベースにとって大きな負担となっていた。
【0013】
そこで、この発明は、上記した従来技術の課題を解決するためになされたものであり、権限を適切に委譲することが可能な権限委譲システム、権限委譲方法および権限委譲プログラムを提供することを目的とする。
【課題を解決するための手段】
【0014】
上述した課題を解決し、目的を達成するため、本発明は、アプリケーションサーバ各々を利用する利用者の本人性を認証サーバが認証する構成の下、所定のアプリケーションサーバを利用する権限を他の利用者から委譲された利用者について当該利用者の権限を判定し、当該利用者による当該アプリケーションサーバの利用を制御する権限委譲システムであって、利用者の本人性を確認可能な情報を格納する格納媒体に、当該格納媒体を利用する利用者が他の利用者から委譲された権限に関する権限委譲情報を格納する格納手段を備え、前記認証サーバは、所定のアプリケーションサーバへアクセスすることを要求するアクセス要求を利用者が利用する利用者端末から受け付けた際に、当該利用者が利用する格納媒体に格納されている情報に基づいて当該利用者の本人性を認証するとともに、前記格納手段によって当該格納媒体に格納された権限委譲情報もしくは当該権限委譲情報から導出される情報を、当該アクセス要求にて指定されたアプリケーションサーバに転送する権限委譲情報転送手段を備え、前記アプリケーションサーバ各々は、前記権限委譲情報転送手段によって転送された前記権限委譲情報もしくは前記情報を受け付けると、当該権限委譲情報もしくは当該情報から、委譲された権限の内容を抽出し、抽出した当該内容を確認することで、当該権限委譲情報を格納する格納媒体の利用者の権限を判定する判定手段と、を備えたことを特徴とする。
【0015】
また、本発明は、上記の発明において、前記権限委譲情報は、委譲の対象となるアプリケーションの種別、および/または、委譲の範囲により、複数のパターンで定義されるものであって、前記格納手段は、前記複数のパターンの内のいずれかのパターンを、前記権限委譲情報として前記格納媒体に格納することを特徴とする。
【0016】
また、本発明は、上記の発明において、前記格納手段は、権限を他の利用者に委譲する権限委譲者を識別する利用者IDと、権限を委譲される被権限委譲者を識別する利用者IDと、委譲の対象となるアプリケーションの種別および/または委譲の範囲により定義される権限委譲情報のパターンと、当該委譲が有効である有効期限とを、当該権限委譲者によって指定されることで、前記権限委譲情報として前記格納媒体に格納することを特徴とする。
【0017】
また、本発明は、上記の発明において、前記権限委譲システムは、発行局サーバと登録局サーバと失効リストリポジトリサーバと登録端末とから構成されるものであって、前記発行局サーバは、利用者の本人性を確認するための利用者証明書を発行する利用者証明書発行手段と、前記権限委譲情報を確認するための権限委譲証明書を発行する権限委譲証明書発行手段とを備え、前記登録局サーバは、前記利用者証明書および前記権限委譲証明書の発行申請を受け付ける申請受付手段と、前記申請受付手段によって受け付けた利用者証明書の発行を前記発行局サーバに要求する利用者証明書発行要求手段と、前記申請受付手段によって受け付けた権限委譲証明書の発行を前記発行局サーバに要求する権限委譲証明書発行要求手段と、前記利用者証明書発行手段によって発行された利用者証明書を取得し、当該利用者証明書を申請した利用者が利用する前記登録端末に対して、当該利用者証明書を送信する利用者証明書送信手段と、前記権限委譲証明書発行手段によって発行された権限委譲証明書を取得し、当該権限委譲証明書によって権限を委譲された利用者が利用する所定の端末に対して、当該権限委譲証明書を送信する権限委譲証明書送信手段とを備え、前記失効リストリポジトリサーバは、前記利用者証明書および/または前記権限委譲証明書が失効しているか否かをアプリケーションサーバに通知する通知手段を備え、前記登録端末は、前記利用者証明書送信手段によって送信された利用者証明書を取得する利用者証明書取得手段を備え、前記所定の端末は、前記権限委譲証明書送信手段によって送信された権限委譲証明書を取得する権限委譲証明書取得手段を備えたことを特徴とする。
【0018】
また、本発明は、上記の発明において、前記登録端末は、権限を他の利用者に委譲する権限委譲者を識別する利用者ID、権限を委譲される被権限委譲者を識別する利用者ID、委譲の対象となるアプリケーションの種別および/または委譲の範囲により定義される権限委譲情報のパターン、および当該委譲が有効である有効期限の指定を権限委譲者から受け付け、前記登録局サーバに送信することで、権限委譲証明書の発行申請を行う権限委譲証明書申請手段を備え、前記登録局サーバは、前記権限委譲者の本人性を、当該権限委譲者が利用する格納媒体に格納された利用者証明書により認証する第1の利用者認証手段と、前記第1の利用者認証手段によって前記権限委譲者の本人性が認証されたことを条件として、前記権限委譲証明書申請手段によって申請された権限委譲証明書の発行を、前記発行局サーバに送信する権限委譲証明書発行要求手段と、前記被権限委譲者の本人性を、当該被権限委譲者が利用する格納媒体に格納された利用者証明書により認証する第2の利用者認証手段と、前記第2の利用者認証手段によって前記被権限委譲者の本人性が認証されたことを条件として、当該被権限委譲者が利用する所定の端末に権限委譲証明書を送信する権限委譲証明書送信手段とを備え、前記発行局サーバの権限委譲証明書発行手段は、前記権限委譲証明書申請手段によって受け付けられた情報に基づいて、前記権限委譲証明書を発行することを特徴とする。
【0019】
また、本発明は、上記の発明において、前記認証サーバは、他の利用者から権限を委譲された被権限委譲者の本人性を、当該被権限委譲者が利用する格納媒体に格納された利用者証明書により認証する認証手段を備え、前記アプリケーションサーバは、前記認証手段によって前記被権限委譲者の本人性が確認されたことを条件として、当該被権限委譲者が利用する格納媒体に格納された権限委譲証明書を要求する権限委譲証明書要求手段と、前記権限委譲証明書要求手段によって要求した権限委譲証明書を取得すると、前記被権限委譲者に委譲された権限が有効期限を経過しているか否か、および、当該権限が失効しているか否かを確認する第1の確認手段と、前記第1の確認手段によって、権限の有効期限を経過していないこと、および、当該権限が失効していないことが確認されたことを条件として、当該委譲の対象および委譲の範囲を確認し、前記被権限委譲者に対して当該アプリケーションサーバを利用する権限を認可するか否かを決定する第2の確認手段と、を備えたことを特徴とする。
【0020】
また、本発明は、アプリケーションサーバ各々を利用する利用者の本人性を認証サーバが認証する構成の下、所定のアプリケーションサーバを利用する権限を他の利用者から委譲された利用者について当該利用者の権限を判定し、当該利用者による当該アプリケーションサーバの利用を制御する権限委譲方法であって、利用者の本人性を確認可能な情報を格納する格納媒体に、当該格納媒体を利用する利用者が他の利用者から委譲された権限に関する権限委譲情報を格納する格納工程を含み、前記認証サーバは、所定のアプリケーションサーバへアクセスすることを要求するアクセス要求を利用者が利用する利用者端末から受け付けた際に、当該利用者が利用する格納媒体に格納されている情報に基づいて当該利用者の本人性を認証するとともに、前記格納工程によって当該格納媒体に格納された権限委譲情報もしくは当該権限委譲情報から導出される情報を、当該アクセス要求にて指定されたアプリケーションサーバに転送する権限委譲情報転送工程を含み、前記アプリケーションサーバ各々は、前記権限委譲情報転送工程によって転送された前記権限委譲情報もしくは前記情報を受け付けると、当該権限委譲情報もしくは当該情報から、委譲された権限の内容を抽出し、抽出した当該内容を確認することで、当該権限委譲情報を格納する格納媒体の利用者の権限を判定する判定工程と、を含んだことを特徴とする。
【0021】
また、本発明は、アプリケーションサーバ各々を利用する利用者の本人性を認証サーバが認証する構成の下、所定のアプリケーションサーバを利用する権限を他の利用者から委譲された利用者について当該利用者の権限を判定し、当該利用者による当該アプリケーションサーバの利用を制御する権限委譲方法をコンピュータに実行させる権限委譲プログラムであって、利用者の本人性を確認可能な情報を格納する格納媒体に、当該格納媒体を利用する利用者が他の利用者から委譲された権限に関する権限委譲情報を格納する格納手順をコンピュータに実行させ、前記認証サーバとしてのコンピュータに、所定のアプリケーションサーバへアクセスすることを要求するアクセス要求を利用者が利用する利用者端末から受け付けた際に、当該利用者が利用する格納媒体に格納されている情報に基づいて当該利用者の本人性を認証するとともに、前記格納手順によって当該格納媒体に格納された権限委譲情報もしくは当該権限委譲情報から導出される情報を、当該アクセス要求にて指定されたアプリケーションサーバに転送する権限委譲情報転送手順を実行させ、前記アプリケーションサーバ各々としてのコンピュータに、前記権限委譲情報転送手順によって転送された権限委譲情報もしくは前記情報を受け付けると、当該権限委譲情報もしくは当該情報から、委譲された権限の内容を抽出し、抽出した当該内容を確認することで、当該権限委譲情報を格納する格納媒体の利用者の権限を判定する判定手順と、を実行させることを特徴とする。
【0022】
また、本発明は、アプリケーションサーバ各々を利用する利用者の本人性を認証サーバが認証する構成の下、所定のアプリケーションサーバを利用する権限を他の利用者から委譲された利用者について当該利用者の権限を判定し、当該利用者による当該アプリケーションサーバの利用を制御する権限委譲方法であって、利用者の本人性を確認可能な情報を格納する格納媒体に、当該格納媒体を利用する利用者が他の利用者から委譲された権限に関する権限委譲情報であって、前記アプリケーションサーバにおいて委譲された権限の内容が抽出され、抽出された当該内容が確認されることで、当該格納媒体の利用者の権限が判定される権限委譲情報を格納する格納工程を含んだことを特徴とする。
【発明の効果】
【0023】
本発明によれば、格納媒体に権限委譲情報を格納し、アプリケーションサーバが、当該権限委譲情報に基づいて被権限委譲者の権限を判定するので、権限を適切に委譲することが可能になる。
【発明を実施するための最良の形態】
【0024】
以下に添付図面を参照して、この発明に係る権限委譲システム、権限委譲方法および権限委譲プログラムの実施例を詳細に説明する。なお、以下では、前提技術、実施例1に係る権限委譲システムの概要および特徴、実施例1に係る権限委譲システムの構成、実施例1に係る権限委譲システムによる処理の手順、実施例1の効果について順に説明し、次に、他の実施例について説明する。
【実施例1】
【0025】
[前提技術]
従来のシングルサインオン認証は、サービスや業務のアプリケーションを提供する提供者にとって、認証した利用者全てにサービス・業務のリソースへのアクセスを許可する場合には問題ないが、個人認証をパスした一部の人にリソースへのアクセス権限を設定する場合には、バックエンドのアプリケーション側が、対象とするリソースへのアクセスを許可するか否かといった認可をしなくてはならない。その具体的方法として、次のようなことが行われる。
【0026】
(1)特定のアプリケーションのリソースにアクセスできる人のIDをアプリケーションの利用者管理サーバに格納し、個人認証時に確認したIDを基に、アクセスの許可(認可)を与え、利用者にリソースを提示する。もし、アクセス権が無い人であれば、個人認証処理後に、「○○業務に登録されていません」といった注意文がメッセージとして表示される。
【0027】
(2)認証を行う際に利用されるディレクトリデータベースに、IDおよびパスワード以外の情報として、アプリケーション側の認可に必要な情報を付加し、認証判定後にバックエンドアプリケーション側にこれらの認可情報を提示し、アプリケーション側で認可判定する。この認可情報で判定条件が満たさなければ、「○○業務に登録されていません」といった注意文がメッセージとして表示される。
【0028】
最近、サービス・業務の効率化に大きく貢献する電子化が進むにつれ、発生源入力が求められ、教育機関の教職員や企業の部課長などの予算権限や業務権限を有した利用者も、多忙に関わらず自分で入力することが求められる。しかし、多忙のため入力処理ができず、結果として、電子的な組織内処理の遅れによるビジネスなど機会損失が発生することが危惧されている。それゆえ、秘書や部下などによる代行入力によって対応されているが、情報セキュリティの観点からの適切な権限委譲はあまり行われていない。具体的には、アクセス権限を保有している利用者が、IDおよびパスワードを部下や秘書に教えて対応していることが多い。これは、一種の「なりすまし」であり、不正利用やミスがあった場合の対応ができなくなるという問題がある。
【0029】
従って、本来、電子的な方法で、(1)誰に(権限委譲される人)、(2)どのサービス・業務に対して(対象業務)、(3)申請だけかあるいは決裁も含めるかといった内容(委譲範囲)、(4)いつまで委譲するのか(有効期限)、などを明確にした上で、アクセス権限を適正な人へ委譲しなければならない。また、(5)委譲した利用者が異動等によりその権限を失効した場合には、委譲された利用者の権限も同時に失効するといった仕組み(失効処理)が必要となる。
【0030】
「なりすまし」でない権限委譲は、基本的に、権限を有した利用者が、委譲先の利用者登録を新たに申請することで行われる。この時、サービス・業務のアプリケーション側は、申請者の本人確認および権限委譲先の本人確認を行った上で、申請内容について審査しなければならない。シングルサインオン認証では、複数のサービス・業務の収容を前提としているため、権限を委譲しようとする利用者は、対象とするサービス・業務のアプリケーションすべてに対して、権限を委譲される人、権限委譲範囲、有効期限などを申請しなければならず、多忙ゆえに権限委譲を行おうとするのに反して、一層多忙になるといった問題があった。また、異なったサービス・業務に対して、それぞれ異なった複数の人に委譲した場合、あるいは、一つのサービス・業務のアクセス権限を複数の人に委譲する場合には処理が一層増えるといった問題が発生した。さらに、権限を有する本人が異動した場合、あるいは、委譲された利用者が異動した場合など、委譲した権利を失効させる作業を申請ベースでタイムリーに行うことは困難な場合が多かった。
【0031】
一方、認証のディレクトリデータベースに権限委譲を登録する場合、該当するデータベースの一元的な集中管理が前提となる。この場合でも、権限委譲のフラグを追記したりなどの作業は、人事異動などによるデータベースの更新に加えて行われることが多いため、権限委譲の処理が遅れたり、認可に必要な情報をアプリケーション側と連携しつつ審査するといった処理により、管理コストと作業量が膨大になってしまうといった問題があった。
【0032】
権限を委譲する立場の利用者と委譲された利用者とに関わる繁雑な処理を、サービス・業務のアプリケーション全てに対して行わなければならない。加えて、サービス・業務のアプリケーション側は、申請された処理に対して、申請者の本人確認、権限委譲先の本人確認、申請内容の審査を行わなければならない。一方、ディレクトリデータベースに権限委譲による認可情報を付加する場合でも、予算権限やアクセス権限を認識している利用者が申請し、データベース管理者もアプリケーション側と確認の上、データ追記を行う必要があり、通常の更新作業に加えて、非常に多くの作業負荷が発生していた。
【0033】
このような方法では、権限を委譲する利用者の数が多いほど、あるいは、対象となるアプリケーションの数が多いほど、これらの権限委譲処理に関する作業量は急激に増え、登録および失効に関するミスやトラブルが発生するといった問題もあった。特に、シングルサインオン認証では、複数のサービス・業務の利用が前提となっているため、このような負担の著しい増加は明らかであった。
【0034】
上記してきたように、シングルサインオン認証は、複数のサービス・業務について、一度だけ認証することにより、許可されたサービス・業務に対してアクセスでき、利用者にとって利便性が大きく向上している。一方、バックエンドのアプリケーション側にとっても、利用者のID管理を一元化でき、ライフサイクル管理を容易にしており、認証システムの開発・運用・保守を軽減するといった大きなメリットがある。
【0035】
このような状況の中、発生源入力といったサービス・業務の効率化の観点から、予算権限や業務権限を有した教職員や部課長以上の利用者も電子的な入力が必要であるが、多忙なためその権限を部下あるいは秘書などへ適切に委譲するには、利用者本人の作業量が増えたり、アプリケーション側の負荷が増大したり、データベース更新の作業量が増えるなど、大きな問題となっていた。そのため、シングルサインオン認証とアプリケーション側の認可において、利用者およびアプリケーション側のメリットを低下させず、予算権限や業務権限に精通している利用者が安全に安心して権限を委譲できる方式が強く望まれていた。
【0036】
[実施例1に係る権限委譲システムの概要および特徴]
まず、図1を用いて、実施例1に係る権限委譲システムの概要および特徴を説明する。図1は、実施例1に係る権限委譲システムの概要および特徴を説明するための図である。
【0037】
シングルサインオン認証における個人認証の手法として、ICカード等の格納媒体に格納した利用者証明書によって利用者の本人性を確認する手法がある(サービス・業務のシングルサインオン認証において、通常、IDおよびパスワードを使って認証するが、複数のサービス・業務が利用できることもあり、よりセキュアなICカードとPINによる多要素認証を利用する例が増えてきつつある)。かかる手法による場合、利用者は、利用者のみの操作によって利用者証明書の発行を受け、ICカード等の格納媒体に格納する。
【0038】
ここで、実施例1に係る権限委譲システムは、利用者証明書をICカード等の格納媒体に格納する手順をそのまま踏襲する。すなわち、権限を委譲する利用者は、当該利用者のみの操作によって権限委譲証明書(権限を委譲する利用者のID、権限を委譲される利用者のID、権限委譲の対象となるサービス・業務、権限委譲の作業範囲、権限委譲の有効期限等の権限委譲情報を含む)の発行を受け、権限を委譲される利用者の利用者証明書を格納したICカード等の格納媒体に、当該権限委譲証明書を併せて格納する。そして、シングルサインオン認証後のバックエンドアプリケーション側の認可判定の際、バックエンドアプリケーションサーバは、ICカード等の格納媒体に格納された権限委譲情報に基づいて、権限を委譲される利用者の権限を判定する。
【0039】
図1を用いて簡単に説明する。実施例1において、権限を委譲する利用者のことを「権限委譲者」と呼び、権限を委譲される利用者のことを「被権限委譲者」と呼ぶ。図1に示すように、実施例1における認証用ICカード12(特許請求の範囲に記載の「格納媒体」に対応する)は、権限委譲者、被権限委譲者各々が保持するものである。また、認証用ICカード12各々は、権限委譲者、被権限委譲者各々の利用者証明書(利用者の本人性を確認可能な情報を含む)を格納する。
【0040】
ここで、利用者証明書を認証用ICカード12に格納する手順を簡単に説明すると、実施例1においては、図1に示すように、プライベート発行局サーバ7と、登録局(RA)サーバ8と、RA端末10と、カード発行機(図示を省略)とから主に構成されるシステムを想定する。このようなシステムにおいて、RA端末10は、利用者によって操作されることで登録局(RA)サーバ8にアクセスし、利用者証明書の発行申請情報を送信する。続いて、登録局(RA)サーバ8は、RA端末10から送信された発行申請情報の正当性を確認し、プライベート発行局サーバ7に対して利用者証明書の発行を要求する。すると、プライベート発行局サーバ7は、利用者証明書を発行し、登録局(RA)サーバ8に送信する。次に、登録局(RA)サーバ8は、RA端末10から利用者証明書ダウンロード要求を受け付け、RA端末10に対して利用者証明書を送信する。すると、RA端末10は、カード発行機に対して利用者証明書を送信し、カード発行機は、認証用ICカード12に利用者証明書を書き込む。
【0041】
ところで、実施例1に係る権限委譲システムは、権限委譲情報についても、上記した手順をそのまま踏襲して、認証用ICカード12に格納する(図1の(1)を参照)。権限委譲証明書を認証用ICカード12に格納する手順を簡単に説明すると、実施例1に係る権限委譲システムは、利用者証明書を発行する際のシステムと同じシステムにおいて、RA端末10は、権限委譲者によって操作されることで登録局(RA)サーバ8にアクセスし、権限委譲証明書の発行申請情報を送信する。続いて、登録局(RA)サーバ8は、RA端末10から送信された発行申請情報の正当性を確認し、プライベート発行局サーバ7に対して権限委譲証明書の発行を要求する。すると、プライベート発行局サーバ7は、権限委譲証明書を発行し、登録局(RA)サーバ8に送信する。次に、登録局(RA)サーバ8は、被権限委譲者が操作するRA端末10から権限委譲証明書ダウンロード要求を受け付け、被権限委譲者が操作するRA端末10に対して権限委譲証明書を送信する。すると、当該RA端末10は、リーダライタ13に対して権限委譲証明書を送信し、リーダライタ13は、被権限委譲者の認証用ICカード12に、権限委譲証明書を書き込む。
【0042】
さて、実施例1に係る権限委譲システムは、被権限委譲者の認証用ICカード12に格納された権限委譲情報に基づいて、被権限委譲者の権限を判定する。具体的には、まず、クライアント端末1が、バックエンドアプリケーションサーバ5へアクセスすることを要求するアクセス要求を認証サーバ3に送信すると(図1の(2)を参照)、認証サーバ3は、被権限委譲者の認証用ICカード12に格納されている利用者証明書に基づいて、当該被権限委譲者の本人性を認証するとともに、当該認証用ICカード12に格納された権限委譲情報を、当該アクセス要求にて指定されたバックエンドアプリケーションサーバ5に転送する(図1の(3)を参照)。
【0043】
すると、バックエンドアプリケーションサーバ5は、認証サーバ3から転送された権限委譲情報を受け付けると、当該権限委譲情報に基づいて、認証用ICカード12の利用者の権限を判定する(図1の(4)を参照)。
【0044】
このように、実施例1に係る権限委譲システムは、認証用ICカード12に権限委譲情報を格納し、バックエンドアプリケーションサーバ5が、当該権限委譲情報に基づいて被権限委譲者の権限を判定するので、権限を適切に委譲することが可能になる。
【0045】
[実施例1に係る権限委譲システムの構成]
次に、図2および図3を用いて、実施例1に係る権限委譲システムの構成を説明する。図2および図3は、実施例1に係る権限委譲システムの構成を示すブロック図である。なお、以下では、RA端末10、ICカード発行機11、登録局(RA)サーバ8、プライベート発行局サーバ7、クライアント端末1、認証サーバ3、バックエンドアプリケーションサーバ5を順に説明する。
【0046】
[RA端末10]
図2に示すように、実施例1におけるRA端末10は、本発明に特に密接に関連するものとして、登録局サーバアクセス部10aと、利用者認証部10bと、証明書発行申請情報投入部10cと、利用者証明書ダウンロード部10dと、証明書データ送信部10eと、権限委譲証明書ダウンロード部10fとを備える。
【0047】
登録局サーバアクセス部10aは、登録局(RA)サーバ8にアクセスする機能を備えた部である。具体的には、登録局サーバアクセス部10aは、利用者(権限委譲者、被権限委譲者など)によってRA端末10が操作されることで登録局(RA)サーバ8にアクセスする。例えば、登録局(RA)サーバ8がWebサーバとしての機能を備えている場合、登録局サーバアクセス部10aは、RA端末10上のブラウザソフト(以下、ブラウザ)で実現可能であり、登録局(RA)サーバ8に対してHTTP(HyperText Transfer Protocol)通信を行うことで、登録局(RA)サーバ8にアクセスすることができる。
【0048】
利用者認証部10bは、登録局(RA)サーバ8との間で利用者認証を行う機能を備えた部である。具体的には、利用者認証部10bは、登録局(RA)サーバ8の利用者認証部8aとの間で、RA端末10を操作している利用者の本人性を認証することを目的として利用者認証を行う。例えば、利用者認証部10bは、ブラウザとWebサーバとの間における既存のID/パスワード認証や、証明書を用いたSSL(Secure Socket Layer)相互認証等により実現可能である。
【0049】
証明書発行申請情報投入部10cは、登録局(RA)サーバ8に対して、証明書を発行する際に必要な申請情報を投入する機能を備えた部である。具体的には、証明書発行申請情報投入部10cは、登録局(RA)サーバ8の申請情報検証部8bに対して、申請情報を投入する。例えば、証明書発行申請情報投入部10cは、ブラウザ上に表示された申請情報の登録フォーマットに、利用者によって、会社名、名前、利用者ID等の必要情報が投入され、利用者によって、ブラウザ上に用意された送信ボタンが押下されることなどによって実現可能である。
【0050】
利用者証明書ダウンロード部10dは、登録局(RA)サーバ8から利用者証明書をダウンロードする機能を備えた部である。具体的には、利用者証明書ダウンロード部10dは、利用者証明書をダウンロードすることを要求するダウンロード要求を登録局(RA)サーバ8へ送信し、登録局(RA)サーバ8から送信される利用者証明書データをRA端末10に保存する。例えば、利用者証明書ダウンロード部10dは、利用者によって、ブラウザ上に表示されたダウンロードボタンが押下されることなどによって、ダウンロード要求を登録局(RA)サーバ8へ送信し、登録局(RA)サーバ8から送信される利用者証明書データをRA端末10の記憶部に格納することで実現可能である。
【0051】
証明書データ送信部10eは、利用者証明書や権限委譲証明書をICカード発行機11に送信する機能を備えた部である。具体的には、証明書データ送信部10eは、利用者証明書ダウンロード部10dによってダウンロードされRA端末10に保存された利用者証明書や、権限委譲証明書ダウンロード部10fによってダウンロードされRA端末10に保存された権限委譲証明書を、ICカード発行機11のICカードデータ書込部11aに送信する。例えば、証明書データ送信部10eは、既存のコンピュータシステムが所持するデータ通信機能や、ファイルアクセス機能を用いて実現可能である。
【0052】
権限委譲証明書ダウンロード部10fは、登録局(RA)サーバ8から権限委譲証明書をダウンロードする機能を備えた部である。具体的には、権限委譲証明書ダウンロード部10fは、権限委譲証明書をダウンロードすることを要求するダウンロード要求を登録局(RA)サーバ8へ送信し、登録局(RA)サーバ8から送信される権限委譲証明書データをRA端末10に保存する。例えば、権限委譲証明書ダウンロード部10fは、利用者(被権限委譲者)によって、ブラウザ上に表示されたダウンロードボタンが押下されることなどによって、ダウンロード要求を登録局(RA)サーバ8へ送信し、登録局(RA)サーバ8から送信される証明書データを利用者(被権限委譲者)の認証用ICカード12に格納することで実現可能である。
【0053】
例えば、権限委譲証明書ダウンロード部10fは、利用者(被権限委譲者)によって、ブラウザ上に表示されたダウンロードボタンが押下されることなどによって、ダウンロード要求を登録局(RA)サーバ8へ送信し、登録局(RA)サーバ8から送信される権限委譲証明書データを受信し、RA端末10に接続されたリーダライタ13を介して、PKCS(Public Key Cryptography Standards)#11やMS-CAPI(Microsoft Crypto API)等の標準的なICカードアクセスインタフェース機能により、受信した権限委譲証明書データを認証用ICカード12へ書き込むことにより実現可能である。
【0054】
[ICカード発行機11]
図2に示すように、実施例1におけるICカード発行機11は、本発明に特に密接に関連するものとして、ICカードデータ書込部11aを備える。
【0055】
ICカードデータ書込部11aは、認証用ICカード12に利用者証明書データを書き込む機能を備えた部である。具体的には、ICカードデータ書込部11aは、RA端末10の証明書データ送信部10eによって送信された利用者証明書データを、認証用ICカード12に書き込む。例えば、ICカードデータ書込部11aは、既存のICカード発行システムを用いて実現可能である。
【0056】
[登録局(RA)サーバ8]
図2に示すように、実施例1における登録局(RA)サーバ8は、本発明に特に密接に関連するものとして、利用者認証部8aと、申請情報検証部8bと、鍵対生成部8cと、証明書発行要求部8dと、証明書管理部8eと、利用者証明書送信部8fと、権限委譲証明書発行要求部8gと、権限委譲証明書管理部8hと、権限委譲証明書送信部8iと、権限委譲証明書失効要求部8jとを備える。
【0057】
利用者認証部8aは、RA端末10との間で利用者認証を行う機能を備えた部である。具体的には、利用者認証部8aは、RA端末10の利用者認証部10bとの間で、RA端末10を操作している利用者の本人性を認証することを目的として利用者認証を行う。例えば、利用者認証部8aは、ブラウザとWebサーバとの間における既存のID/パスワード認証や、証明書を用いたSSL相互認証等により実現可能である。
【0058】
申請情報検証部8bは、申請情報を検証する機能を備えた部である。具体的には、申請情報検証部8bは、RA端末10の証明書発行申請情報投入部10cによって投入された申請情報を検証し、検証結果を鍵対生成部8cに伝達する。例えば、申請情報検証部8bは、RA端末10から送信された申請情報を受信し、データの過不足や形式チェック等を実施するものであり、既存のWebサーバソフト等により実現可能である。
【0059】
鍵対生成部8cは、鍵対を生成する機能を備えた部である。具体的には、鍵対生成部8cは、申請情報検証部8bから申請情報が正当であるとの検証結果を伝達されると、鍵対を生成する。例えば、鍵対生成部8cは、公開鍵暗号方式における秘密鍵および公開鍵のペアを生成するものであり、既存のPKI(Public Key Infrastructure)アプリケーション等により実現可能である。
【0060】
証明書発行要求部8dは、利用者証明書の発行を要求する機能を備えた部である。具体的には、証明書発行要求部8dは、プライベート発行局サーバ7の証明書発行部7aに対して、鍵対生成部8cによって生成された公開鍵に対する利用者証明書の発行を要求する。例えば、証明書発行要求部8dは、PKCS#10等の標準化されたデータ形式で証明書発行申請データをプライベート発行局サーバ7へ送信するものであり、既存のPKIアプリケーション等により実現可能である。
【0061】
証明書管理部8eは、利用者証明書を管理する機能を備えた部である。具体的には、証明書管理部8eは、プライベート発行局サーバ7の証明書発行部7aから送信された利用者証明書データを受信し、登録局(RA)サーバ8の記憶部に格納する。例えば、証明書管理部8eは、既存のコンピュータシステムが保持するデータ通信機能、データ保存機能を用いて実現可能である。
【0062】
利用者証明書送信部8fは、利用者証明書を送信する機能を備えた部である。具体的には、利用者証明書送信部8fは、証明書管理部8eによって管理されている利用者証明書データを、RA端末10に送信する。例えば、利用者証明書送信部8fは、既存のWebサーバソフトや、これと連携するRDBMS(Relational DataBase Management System)等により実現可能である。
【0063】
権限委譲証明書発行要求部8gは、権限委譲証明書の発行を要求する機能を備えた部である。具体的には、権限委譲証明書発行要求部8gは、プライベート発行局サーバ7の権限委譲証明書発行部7bに対して、権限委譲証明書の発行を要求する。例えば、権限委譲証明書発行要求部8gは、PKCS#10等の標準化されたデータ形式で証明書発行申請データをプライベート発行局サーバ7へ送信するものであり、既存のPKIアプリケーション等により実現可能である。
【0064】
権限委譲証明書管理部8hは、権限委譲証明書を管理する機能を備えた部である。具体的には、権限委譲証明書管理部8hは、プライベート発行局サーバ7の権限委譲証明書発行部7bから送信された権限委譲証明書データを受信し、登録局(RA)サーバ8の記憶部に格納する。例えば、権限委譲証明書管理部8hは、既存のコンピュータシステムが保持するデータ通信機能、データ保存機能を用いて実現可能である。
【0065】
権限委譲証明書送信部8iは、権限委譲証明書を送信する機能を備えた部である。具体的には、権限委譲証明書送信部8iは、権限委譲証明書管理部8hによって管理されている権限委譲証明書データを、RA端末10に送信する。例えば、権限委譲証明書送信部8iは、既存のWebサーバソフトや、これと連携するRDBMS等により実現可能である。
【0066】
権限委譲証明書失効要求部8jは、権限委譲証明書を失効させることを要求する機能を備えた部である。具体的には、権限委譲証明書失効要求部8jは、権限委譲証明書に対する失効を要求する権限委譲証明書失効要求データをプライベート発行局サーバ7の権限委譲証明書失効部7cへ送信する。例えば、権限委譲証明書失効要求部8jは、既存の認証局アプリケーション等により実現可能である。
【0067】
[プライベート発行局サーバ7]
図2に示すように、実施例1におけるプライベート発行局サーバ7は、本発明に特に密接に関連するものとして、証明書発行部7aと、権限委譲証明書発行部7bと、権限委譲証明書失効部7cと、失効リスト公開部7dとを備える。
【0068】
証明書発行部7aは、利用者証明書を発行する機能を備えた部である。具体的には、証明書発行部7aは、登録局(RA)サーバ8の証明書発行要求部8dから利用者証明書の発行要求を受け付け、利用者証明書を発行する。例えば、証明書発行部7aは、既存のPKIアプリケーションあるいは認証局アプリケーションにより実現可能である。
【0069】
権限委譲証明書発行部7bは、権限委譲証明書を発行する機能を備えた部である。具体的には、権限委譲証明書発行部7bは、登録局(RA)サーバ8の権限委譲証明書発行要求部8gから権限委譲証明書の発行要求を受け付け、権限委譲証明書を発行する。なお、例えば、権限委譲証明書は、既存のX.509等で規定された証明書の標準形式に準じた証明書であるため、権限委譲証明書発行部7bは、既存のPKIアプリケーションあるいは認証局アプリケーションにより実現可能である。
【0070】
権限委譲証明書失効部7cは、権限委譲証明書を失効させる機能を備えた部である。具体的には、権限委譲証明書失効部7cは、登録局(RA)サーバ8の権限委譲証明書失効要求部8jから権限委譲証明書の失効要求を受け付け、該当する権限委譲証明書の情報を証明書失効リスト(CRL:Certificate Revocation List)に登録する。例えば、権限委譲証明書失効部7cは、既存のX.509等で規定されており、その標準形式に従った失効リストデータの作成は、既存のPKIアプリケーションあるいは認証局アプリケーションにより実現可能である。
【0071】
失効リスト公開部7dは、証明書失効リストを公開する機能を備えた部である。具体的には、失効リスト公開部7dは、権限委譲証明書失効部7cによって登録された証明書失効リストを、失効リストリポジトリサーバ9へ登録し、公開する。例えば、失効リスト公開部7dは、既存のLDAP(Lightweight Directory Access Protocol)等のリポジトリサーバへのアクセス機能を用いることで実現可能である。
【0072】
[クライアント端末1]
図3に示すように、実施例1におけるクライアント端末1は、本発明に特に密接に関連するものとして、証明書一覧部1aと、ICカードアクセス部1bと、権限委譲証明書送信部1cとを備える。
【0073】
証明書一覧部1aは、利用可能な証明書の一覧を出力部に表示する機能を備えた部である。具体的には、証明書一覧部1aは、認証サーバ3の権限委譲証明書要求画面部3aによる画面情報を受信すると、リーダライタ13を介して認証用ICカード12内に格納された権限委譲証明書等の情報を出力部に表示し、利用者による選択(一覧の中から権限委譲証明書を選択)を受け付ける。例えば、証明書一覧部1aは、既存のブラウザ等により実現可能である。
【0074】
ICカードアクセス部1bは、認証用ICカード12にアクセスする。具体的には、ICカードアクセス部1bは、リーダライタ13を介して認証用ICカード12にアクセスし、当該認証用ICカード12に格納されている権限委譲証明書を受信する。例えば、ICカードアクセス部1bのPINによるアクセス制御機能やICカード内の情報の読み書きに関する機能は、既存のICカードアプリケーションによって実現可能である。
【0075】
権限委譲証明書送信部1cは、権限委譲証明書を送信する機能を備えた部である。具体的には、権限委譲証明書送信部1cは、ICカードアクセス部1bによって受信された権限委譲証明書を、認証サーバ3の権限委譲証明書検証部3bに送信する。例えば、権限委譲証明書送信部1cは、既存のブラウザと、Webサーバとの間の送受信機能を用いることで実現可能である。
【0076】
[認証サーバ3]
図3に示すように、認証サーバ3は、本発明に特に密接に関連するものとして、権限委譲証明書要求画面部3aと、権限委譲証明書検証部3bと、権限委譲証明書転送部3cと、認可結果画面表示部3dとを備える。
【0077】
権限委譲証明書要求画面部3aは、権限委譲証明書を要求する画面情報をクライアント端末1に送信する。具体的には、権限委譲証明書要求画面部3aは、バックエンドアプリケーションサーバ5の権限委譲証明書要求部5aから権限委譲証明書要求を受け付けると、権限委譲証明書の送信を要求する画面情報を、クライアント端末1に送信する。例えば、権限委譲証明書要求画面部3aの画面表示させるための電文生成や送信機能は、通常のWebアプリケーションシステムにおいて実現可能である。
【0078】
権限委譲証明書検証部3bは、権限委譲証明書を検証する。具体的には、権限委譲証明書検証部3bは、クライアント端末1の権限委譲証明書送信部1cによって送信された権限委譲証明書を検証し、検証結果を権限委譲証明書転送部3cに伝達する。例えば、権限委譲証明書検証部3bは、既存のWebサーバにおけるSSL送受信機能や、証明書パース機能を用いることで実現可能である。
【0079】
権限委譲証明書転送部3cは、権限委譲証明書を転送する。具体的には、権限委譲証明書転送部3cは、権限委譲証明書検証部3bによって正当であることが検証された権限委譲証明書を、バックエンドアプリケーションサーバ5の権限委譲証明書確認部5bに送信する。例えば、権限委譲証明書転送部3cは、既存のサーバ間通信機能を用いることで実現可能である。
【0080】
認可結果画面表示部3dは、認可結果の画面情報を送信する。具体的には、認可結果画面表示部3dは、バックエンドアプリケーションサーバ5の認可結果通知部5dから通知された認可結果の画面情報を、クライアント端末1に送信する。例えば、認可結果画面表示部3dの画面表示させるための電文生成や送信機能は、通常のWebアプリケーションシステムにおいて実現可能である。
【0081】
[バックエンドアプリケーションサーバ5]
図3に示すように、バックエンドアプリケーションサーバ5は、本発明に特に密接に関連するものとして、権限委譲証明書要求部5aと、権限委譲証明書確認部5bと、失効情報確認部5cと、認可結果通知部5dとを備える。
【0082】
権限委譲証明書要求部5aは、権限委譲証明書を要求する。具体的には、権限委譲証明書要求部5aは、認可の否決情報とあわせて権限委譲証明書を要求する電文を、認証サーバ3に送信する。例えば、権限委譲証明書要求部5aは、通常のコンピュータシステムにおける電文生成機能、電文送信機能により実現可能である。
【0083】
権限委譲証明書確認部5bは、権限委譲証明書を確認する。具体的には、権限委譲証明書確認部5bは、認証サーバ3の権限委譲証明書転送部3cから転送された権限委譲証明書内に格納された権限委譲情報を確認する。例えば、権限委譲証明書確認部5bは、既存のPKIアプリケーションにおける証明書パース機能等を用いることで実現可能である。
【0084】
失効情報確認部5cは、失効情報を確認する。具体的には、失効情報確認部5cは、失効リストリポジトリサーバ9を参照し、該当する利用者IDの利用者証明書や権限委譲証明書が失効していないかを確認する。例えば、失効情報確認部5cは、既存のPKIアプリケーションにおいて、LDAP等のリポジトリへのアクセスプロトコルを用いた失効リスト情報の照会機能を用いることで実現可能である。
【0085】
認可結果通知部5dは、認可結果を通知する。具体的には、認可結果通知部5dは、権限委譲証明書確認部5bや失効情報確認部5cによって確認された認可結果を、認証サーバ3の認可結果画面表示部3dに送信する。例えば、認可結果通知部5dは、通常のコンピュータシステムにおける電文生成機能、電文送受信機能により実現可能である。
【0086】
[実施例1に係る権限委譲システムによる処理の手順]
次に、図4~図13-2を用いて、実施例1に係る権限委譲システムによる処理の手順を詳細に説明する。なお、以下では、認証用ICカードの発行と認証情報の格納の流れ、権限委譲証明書を認証用ICカードに格納するまでの流れ、本発明におけるシングルサインオン認証処理の流れ、権限を有した利用者での認可処理の流れ、権限を委譲された利用者での認可処理の流れ、権限を委譲された利用者が権限変更を行う認可処理の流れを順に説明する。
【0087】
[認証用ICカードの発行と認証情報の格納の流れ]
図4は、認証用ICカードの発行と認証情報の格納の流れを説明するための図である。実施例1に係る権限委譲システムは、図4に示すように、利用者証明書を発行するプライベート発行局サーバ7、利用者の本人性を確認した上でRA端末10からの利用者証明書発行要求を受け付け、プライベート発行局サーバ7に利用者証明書発行を要求する登録局サーバ8、登録局サーバ8に対して利用者証明書発行要求を申請するためのRA端末10、および、認証用ICカード12に利用者証明書を含む認証情報を格納するためのカード発行機11から構成され、各構成機器は、ネットワークで通信可能な状態になっている。
【0088】
まず、オペレータは、各部門などに設置されたRA端末10における登録局サーバアクセス機能(登録局サーバアクセス部10a)を用いて登録局サーバ8へネットワークを介してアクセスし、登録局サーバ10との間で利用者認証機能(利用者認証部10b)を用いて利用者認証を実施後、証明書発行申請情報投入機能(証明書発行申請情報投入部10c)を用いて利用者証明書の発行申請情報を送信する(図4の(1)を参照)。
【0089】
次に、登録局サーバ8は、申請情報検証機能(申請情報検証部8b)を用いて、RA端末10から申請された利用者証明書発行申請情報の正当性を確認し、鍵対生成機能(鍵対生成部8c)により、秘密鍵および公開鍵の鍵対を生成後、証明書発行要求機能(証明書発行要求部8d)を用いてプライベート発行局サーバ7に対して当該公開鍵に対する証明書の発行を要求する(図4の(1)を参照)。なお、利用者証明書発行申請データには、RA端末10から送信された申請情報の中から、利用者証明書に格納すべき情報を含めて送信される。例えば、会社名や名前、利用者ID等が該当する。
【0090】
そして、プライベート発行局サーバ7は、証明書発行機能(証明書発行部7a)を用いて、登録局サーバ8からの利用者証明書発行要求データを受信し、当該データに基づく利用者証明書を作成し、登録局サーバ8へ利用者証明書を送信する(図4の(2)を参照)。なお、発行された利用者証明書内には、証明書発行申請データに含まれていた会社名や名前等の認証情報が含まれている。
【0091】
すると、登録局サーバ8は、証明書管理機能(証明書管理部8e)を用いて、プライベート発行局サーバ7から送信された利用者証明書データを受信し、登録局サーバ8内に格納する(図4の(2)を参照)。
【0092】
次に、RA端末10は、登録局サーバアクセス機能(登録局サーバアクセス部10a)を用いて、登録局(RA)サーバ8へネットワークを介してアクセスし、利用者認証機能(利用者認証部8a)を用いて、登録局(RA)サーバ8との間で利用者認証を実施後、利用者証明書ダウンロード機能(利用者証明書ダウンロード部10d)を用いて、登録局(RA)サーバ8から利用者証明書をダウンロードする(図4の(2)を参照)。
【0093】
一方、登録局サーバ8では、利用者認証機能(利用者認証部8a)を用いて利用者認証を実施後、利用者証明書送信機能(利用者証明書送信部8f)を用いて、RA端末10からの利用者証明書ダウンロード要求を受け付け、さらにその後、登録局サーバ8内に格納された対象の利用者証明書を検索して取得し、RA端末10に対してこれを送信する(図4の(2)を参照)。
【0094】
続いて、RA端末10は、証明書データ送信機能(証明書データ送信部10e)を用いてカード発行機11に対してダウンロードした利用者証明書データを送信する(図4の(3)を参照)。また、この利用者証明書データの送信の完了と同時に、RA端末10上の利用者証明書データは自動消去する。ICカード発行機11側では、事前に書き込み対象の初期化された認証用ICカード12をICカード発行機11にセットした後、ICカードデータ書込機能(ICカードデータ書込部11a)を用いて、RA端末10からの利用者証明書データを受信後、認証用ICカード12の不揮発性のメモリ領域に利用者証明書データを書き込む(図4の(4)を参照)。
【0095】
以上の機能および手順により、会社名や氏名等の認証に必要な情報を含む利用者証明書が格納された認証用ICカード12を作成し、シングルサインオン認証への利用を実現した。
【0096】
[権限委譲証明書を認証用ICカードに格納するまでの流れ]
次に、図5は、権限委譲証明書に必要な構成要素を説明するための図である。実施例1に係る権限委譲システムは、利用者が権限委譲証明書の申請を入力するRA端末10、利用者の本人性を確認した上で申請を受け付ける登録局サーバ8、権限委譲証明書を生成するプライベート発行局サーバ7、認証に必要な利用者証明書および権限委譲証明書の失効を受け付け、そのリストを公開する失効リストリポジトリサーバ9から主に構成される。また、RA端末10には、利用者が利用者証明書で本人確認を行う場合、権限を委譲される人が自分の利用者証明書で本人確認を行う場合、さらに、自分の認証用ICカードに権限委譲証明書をダウンロードする場合等に利用するリーダライタ13が接続され、認証用ICカード12の読み書きをつかさどる。
【0097】
次に、権限委譲情報パターンについて説明する。利用者が有している権限を委譲するには、いくつかのパターンに集約できる。図6に、このパターン例を示す。もちろん、本人の意思確認や責任内規の整備が必要であるが、この例は、権限を有する利用者が指示して電子処理を行うことを前提としている。基本的に、権限を委譲する内容や範囲として、申請と決裁の場合がほとんどである。これらの対象業務と内容とをパターン化することにより、権限を委譲する利用者が申請を行う際の入力の簡素化が可能になる。
【0098】
図7に、権限委譲証明書を申請する際の申請内容の例を示す。上記した権限委譲情報パターン(番号の選択)に加えて、権限を委譲する人のID番号、権限を委譲される人のID番号、委譲する期限だけであり、同じような情報を、サービス・業務のアプリケーションごとに入力するのに比べ、はるかに短時間に、簡単に申請することが可能になる。
【0099】
図8は、権限委譲証明書を認証用ICカードに格納するまでの流れを説明するための図である。バックエンドアプリケーションサーバにアクセスできる権限を有した利用者が、他者にその権限を委譲したい場合、まず、権限委譲利用者は、RA端末10において、自分の認証用ICカード12をリーダライタ13に挿入する(図8の(1)を参照)。RA端末10は、登録局サーバアクセス機能(登録局サーバアクセス部10a)を用いて登録局サーバ8へアクセス後、利用者認証機能(利用者認証部10b)を用いて認証用ICカード12内の利用者証明書を用いた利用者認証を実施する。続いて、RA端末10は、申請情報投入機能(証明書発行申請情報投入部10c)を用いて、図7に示した権限委譲される人のID、権限委譲情報パターン、権限委譲の有効期限等の情報の指定を受け付け、これを登録局(RA)サーバ8へ送信する(図8の(2)を参照)。
【0100】
なお、認証用ICカード12内の利用者証明書を用いた利用者認証の実施は、例えば、ブラウザとWebサーバ間におけるSSL相互認証において、認証用ICカード12内に格納された秘密鍵情報や証明書情報に対して、PKCS#11やMS-CAPI等の標準的なICカードアクセスインタフェース機能を用いてアクセスし、これらを用いて、クライアント側での認証情報生成や登録局(RA)サーバ8への認証情報の送信を実施することで実現可能である。
【0101】
続いて、登録局(RA)サーバ8は、申請情報検証機能(申請情報検証部8b)を用いてRA端末10から申請された権限委譲証明書発行申請情報の正当性を確認し、鍵対生成機能(鍵対生成部8c)により秘密鍵および公開鍵の鍵対を生成後、権限委譲証明書発行要求機能(権限委譲証明書発行要求部8g)を用いてプライベート発行局サーバ7に対して当該公開鍵に対する権限委譲証明書の発行を要求する(図8の(2)を参照)。なお、権限委譲証明書発行申請データには、RA端末10から送信された申請情報の中から、図7に示すような権限委譲証明書に格納すべき情報を含めて送信される。
【0102】
次に、プライベート発行局サーバ7は、権限委譲証明書発行機能(権限委譲証明書発行部7b)を用いて、登録局サーバ8からの権限委譲証明書発行要求データを受信し、当該データに基づく権限委譲証明書を作成し、登録局サーバ8へ権限委譲証明書を送信する(図8の(4)を参照)。なお、発行された権限委譲証明書内には、権限委譲証明書発行申請データに含まれる権限委譲する人のID、権限委譲される人のID、権限委譲情報のパターン、権限委譲の有効期限等の権限委譲を証明する情報が含まれている。
【0103】
続いて、登録局サーバ8は、権限委譲証明書管理機能(権限委譲証明書管理部8h)を用いて、プライベート発行局サーバ7から送信された権限委譲証明書データを受信し、登録局(RA)サーバ8内に格納する(図8の(4)を参照)。
【0104】
次に、権限を委譲される利用者がシステムにログインした。この際も、権限を委譲される本人の認証用ICカード12をリーダライタ13に挿入し(図8の(3)を参照)、被権限委譲者が利用するRA端末10は、登録局サーバアクセス機能(登録局サーバアクセス部10a)を用いて登録局サーバ8へアクセス後、利用者認証機能(利用者認証部10b)を用いて認証用ICカード12内の利用者証明書を用いた利用者認証を実施する。
【0105】
そして、被権限委譲者が利用するRA端末10は、権限委譲証明書ダウンロード機能(権限委譲証明書ダウンロード部10f)を用いて、登録局(RA)サーバ8から権限委譲証明書を、権限を委譲される本人の認証用ICカード12内にダウンロードする。この時、登録局サーバ8では、利用者認証機能(利用者認証部8a)を用いて利用者認証を実施後、権限委譲証明書送信機能(権限委譲証明書送信部8i)を用いて、被権限委譲者が利用するRA端末10からの権限委譲証明書ダウンロード要求を受け付け、さらにその後、登録局サーバ8内に格納された対象の権限委譲証明書を検索して取得し、被権限委譲者が利用するRA端末10に対してこれを送信する。
【0106】
以上の機能および手順により、権限委譲証明書を、権限の委譲を依頼された利用者の認証用ICカード12内に格納することを実現した。さらに、この一連の操作は非常に簡単である。なお、実施例1においては、被権限委譲者が、自ら操作するRA端末10によって登録局サーバ8へアクセスし、自身向けに発行された権限委譲証明書をICカードに格納する手法を説明したが、本発明はこれに限られるものではない。例えば、被権限委譲者が利用するクライアント端末1が登録局サーバ8に通信可能に接続されている環境であれば、当該被権限委譲者は、当該クライアント端末1によって登録局サーバ8へアクセスし、自身向けに発行された権限委譲証明書をICカードに格納してもよい。言い換えると、権限委譲者が関与することなく被権限委譲者が権限委譲証明書を取得することが可能な手法であれば、どの端末を用いて登録局サーバ8へアクセスするかは任意に変更し得る。
【0107】
[失効リポジトリサーバへの登録]
また、権限委譲証明書の内容変更、利用者や権限を委譲された利用者が異動した際には、権限委譲証明書の発行を申請した利用者、つまりは、権限委譲を希望した利用者が、RA端末10を通して、失効リストリポジトリサーバ9に登録することで、権限委譲証明書を失効させることが可能である。利用者証明書の失効も失効リストリポジトリサーバ9に登録することで、利用者が異動した後も権限委譲証明書が使われることができないように二重のブロックをかけるのである。以上を実現する機能および手順は、以下の通りである。
【0108】
まず、権限委譲を希望した利用者は、RA端末10において自分の認証用ICカード12をリーダライタ13に挿入する。RA端末10は、登録局サーバアクセス機能(登録局サーバアクセス部10a)を用いて登録局サーバ8へアクセス後、利用者認証機能(利用者認証部10b)を用いて認証用ICカード12内の利用者証明書を用いた利用者認証を実施する。続いて、RA端末10は、申請情報投入機能(証明書発行申請情報投入部10c)を用いて、失効を希望する対象の権限委譲証明書の識別情報を含む失効申請情報を入力し、これを登録局(RA)サーバ8へ送信する。
【0109】
続いて、登録局サーバ8は、申請情報検証機能(申請情報検証部8b)を用いてRA端末10から申請された権限委譲証明書失効申請情報の正当性を確認し、権限委譲証明書失効要求機能(権限委譲証明書失効要求部8j)を用いてプライベート発行局サーバ7に対して権限委譲証明書に対する失効を要求する。
【0110】
そして、プライベート発行局サーバ7は、権限委譲証明書失効機能(権限委譲証明書失効部7c)を用いて、登録局サーバ8からの権限委譲証明書失効要求データを受信し、該当の権限委譲証明書の情報を証明書失効リストに登録し、失効リスト公開機能(失効リスト公開部7d)を用いて、証明書失効リストを失効リストリポジトリサーバ9へ登録、公開する。
【0111】
[本発明におけるシングルサインオン認証処理の流れ]
図9は、本発明におけるシングルサインオン認証およびバックエンドアプリケーションサーバ5での認可のシステム構成例を示す図である。通常のシングルサインオン認証でICカードを利用する場合と同様の構成となっている。図10は、本発明におけるシングルサインオン認証処理の流れを説明するための図である。なお、図10に示す処理の流れは、権限を委譲する利用者および権限を委譲された利用者ともに同じであり、認証用ICカード12(利用者証明書)を使ったシングルサインオン認証と同様の流れとなっている。
【0112】
まず、クライアント端末1が、認証サーバ3に対して、ポータルへのアクセス要求を送信する(ステップS101)。次に、認証サーバ3は、クライアント端末1に対して、認証情報要求を送信する(ステップS102)。すると、クライアント端末1は、認証用ICカード12に対して、リーダライタ13を介して認証情報要求を送信する(ステップS103)。
【0113】
ここで、利用者は、認証用ICカード12内に格納された利用者証明書を選択し(ステップS104)、ID、パスワード入力の代わりに、認証用ICカード12を利用してPIN入力する(ステップS105およびステップS106)。なお、認証用ICカード12へのPIN入力は、クライアント端末1上に表示されたPIN入力画面からPINが投入され、これをリーダライタ13を介して認証用ICカード12へ送信することにより実現可能であり、既存のICカード利用アプリケーションにて実装されているものである。
【0114】
すると、クライアント端末1と認証サーバ3との間で、SSL等の暗号通信路を介して、認証用ICカード12内に格納された秘密鍵および利用者証明書を用いたクライアント認証が実施される(ステップS107)。なお、クライアント端末1と認証サーバ3との間でのSSLによる暗号通信路の構築や、SSLにおける利用者証明書を用いたクライアント認証の実施等についても、既存のブラウザおよびWebサーバソフトを用いることで実現可能である。
【0115】
続いて、認証サーバ3は、そのクライアント認証に用いた利用者証明書の識別名(DN)を抽出し(ステップS108)、ディレクトリデータベース4に格納した識別名とマッチングさせ(ステップS109)、認証の判定を行う(ステップS110)。なお、利用者証明書の識別名を取得する機能については、既存のPKIアプリケーション機能が有する証明書パース機能で実現可能であり、さらに、ディレクトリデータベースに格納した識別名とのマッチングについても、既存のWebアプリケーションとRDBMSとの連携機能により実現可能である。
【0116】
こうして、認証の結果、認証OK(利用者の本人性を確認)であれば、認証サーバ3は、クライアント端末1に対して、ポータルのURLを提示する(ステップS111)。
【0117】
[権限を有した利用者での認可処理の流れ]
図11は、権限を有した利用者での認可処理を説明するための図である。ここでは、クライアント端末1の操作者は、すでに図10のシングルサインオン認証処理を完了し、本人認証が済みの状態となった後の流れを示している。
【0118】
まず、対象とするアプリケーションへアクセスする権限を有する利用者の場合、クライアント端末1から認証サーバ3を経由して、対象となるバックエンドアプリケーションサーバ5へアクセス要求を送信する(ステップS120およびS121)。
【0119】
すると、バックエンドアプリケーションサーバ5は、これを受けて利用者IDを要求する(ステップS122)。認証サーバ3は、認証をパスした利用者ID情報をバックエンドアプリケーションサーバ5へ提示し(ステップS123)、バックエンドアプリケーションサーバ5は、利用者管理のデータベースと照合して認可判定を行い(ステップS124)、設定されたアクセス権限に従って、認可結果およびリソースURLを認証サーバ3経由にてクライアント端末1に表示させる(ステップS125およびS126)。
【0120】
このように、権限を有する利用者は、バックエンドアプリケーションサーバ5側の利用者データベースに利用者IDおよびアクセス権限が格納されているので、特別な処理無しにサービス・業務を行うことができる。
【0121】
[権限を委譲された利用者での認可処理の流れ]
図12-1および図12-2は、権限を委譲された利用者での認可処理の流れを説明するための図である。この実施例は、利用者が、元来、アクセス権限を持たない人が、アクセス権限を委譲された利用者の場合である。
【0122】
まず、バックエンドアプリケーションサーバ5側に利用者IDを登録していないので、通常の処理では認可は否決される。従って、通常は、「○○サービスに利用登録がされていません」といったエラーメッセージがクライアント端末に表示される。
【0123】
実施例1に係る権限委譲システムでは、クライアント端末1から認証サーバ3に対して、バックエンドアプリケーションサーバ5へのアクセス要求が送信され、認証サーバ3からバックエンドアプリケーションサーバ5に対して当該アクセス要求が送信され、バックエンドアプリケーションサーバ5において認可判定が行われ、これが否決となった場合(ステップS201~S205)、バックエンドアプリケーションサーバ5は、権限委譲証明書要求機能(権限委譲証明書要求部5a)を用いて、認可の否決情報とあわせて権限委譲証明書を要求する電文を認証サーバ3に返す(ステップS206)。認証サーバ3は、権限委譲証明書の要求電文を受信すると、権限委譲証明書要求画面機能(権限委譲証明書要求画面部3a)を用いて、権限委譲証明書の送信を要求する画面情報をクライアント端末1へ送信する(ステップS207)。
【0124】
クライアント端末1は、画面情報を受信すると、証明書一覧機能(証明書一覧部1a)によりクライアント端末1からアクセス可能な証明書の一覧を表示する(ステップS208)。なお、リーダライタ13を介して認証用ICカード12内に格納された権限委譲証明書の情報も、その一覧に含められて表示される。利用者が、その一覧の中から権限委譲証明書を選択すると(ステップS209)、クライアント端末1は、ICカードアクセス機能(ICカードアクセス部1b)を用いて、認証用ICカード12へアクセスするためのPIN入力画面をクライアント端末1上に表示し、利用者により入力されたPIN情報を認証用ICカード12へ送信し(ステップS210およびS211)、認証用ICカード12におけるPIN照合が完了後、認証用ICカード12内に格納された権限委譲証明書を受信する。
【0125】
クライアント端末1は、さらに、権限委譲証明書送信機能(権限委譲証明書送信部1c)を用いて、図10において確立したSSL等の暗号通信路を介し、認証用ICカード12内から取得した権限委譲証明書を認証サーバ3へ送信する(ステップS212)。
【0126】
認証サーバ3では、権限委譲証明書検証機能(権限委譲証明書検証部3b)を用いて、暗号通信路において暗号化された権限委譲証明書を復号して、権限委譲証明書内に格納された権限委譲された利用者の識別情報を取得し、これを先に実施済みのシングルサインオン認証にて認証済みの利用者と一致していることを確認する(ステップS213)。この確認が完了後、認証サーバ3は、権限委譲証明書転送機能(権限委譲証明書転送部3c)を用いて、権限委譲証明書をバックエンドアプリケーションサーバ5へ送信する(ステップS124)。なお、実施例1においては、認証サーバ3が、権限委譲証明書自体をバックエンドアプリケーションサーバ5へ送信する手法を説明したが、本発明はこれに限られるものではない。認証サーバ3が送信する情報は、利用者が権限委譲に基づいてバックエンドアプリケーションサーバ5にアクセス(ログイン)するものであることを示す情報であれば、権限委譲証明書から導出された他の形態の情報であってもよい。
【0127】
バックエンドアプリケーションサーバ5では、権限委譲情報確認機能(権限委譲証明書確認部5b)を用いて、受信した権限委譲証明書内に格納された権限委譲者の識別情報、権限委譲の有効期限、図7に示した権限委譲の対象業務や委譲範囲を示す委譲パターンの情報を抽出し、その権限委譲者の有するアクセス権限との整合性の確認、権限委譲の有効期限が切れていないことを確認する。また、失効情報確認機能(失効情報確認部5c)を用いて、失効リストリポジトリサーバ9を参照し、該当する利用者IDの利用者証明書や権限委譲証明書が失効していないかを確認する(ステップS215)。なお、有効期限と失効とを先に確認した上で、その他の情報を確認し、認可判定を行ってもよい。
【0128】
最後に、バックエンドアプリケーションサーバ5は、認可結果通知機能(認可結果通知部5d)を用いて、委譲により、アクセス可能なリソースのURL情報を認証サーバ3へ通知し(ステップS216)、認証サーバ3は、認可結果画面表示機能(認証結果画面表示部3d)を用いてこれをクライアント端末1に表示させる(ステップS217)。
【0129】
[権限を委譲された利用者が権限変更を行う認可処理の流れ]
図13-1および図13-2は、権限を委譲された利用者が権限変更を行う認可処理の流れを説明するための図である。この場合、特定アプリケーションへのアクセス権限があるが、その作業可能な範囲が異なる。
【0130】
例えば、図6のパターン2の権限を有していた人が、パターン4の権限を委譲される。結果として、一部の業務に対して、申請や決裁の権限が追加されたことになる。この場合、権限を委譲された利用者は、バックエンドアプリケーションサーバ5(例えば、旅費申請)側に利用者IDを登録しているので、認可は可決される。しかし、パターン2の権限であるので、旅費の決裁処理はできなかった。
【0131】
実施例1に係る権限委譲システムでは、権限を委譲された利用者が、一度認可された後(ステップS301~S307)、クライアント端末1は、権限の変更を、認証サーバ3経由で、旅費アプリケーションサーバ5に対して要求した(ステップS308およびS309)。
【0132】
旅費アプリケーションサーバ5は、権限変更を否決し(ステップS310)、権限委譲証明書要求機能(権限委譲証明書要求部5a)を用いて認証サーバ3に対して権限委譲証明書を要求する(ステップS311)。
【0133】
以降、認証サーバ3が権限委譲証明書の要求電文を受信後の処理は、図12において述べたものと同様の処理が行われ、旅費アプリケーションサーバ5に対して権限委譲証明書が送信される(ステップS312からS319)。
【0134】
旅費アプリケーションサーバ5は、権限委譲情報確認機能(権限委譲証明書確認部5b)および失効情報確認部(失効情報確認部5c)を用いて、図12と同様に受信した権限委譲証明書の内容およびその有効性を確認後、認可結果通知機能(認可結果通知部5d)を用いて、委譲によりアクセス可能なリソースのURL情報を認証サーバ3へ通知し(ステップS321)、認証サーバ3は、認証結果画面表示機能を用いてこれをクライアント端末1に表示させる(ステップS322)。
【0135】
こうして、実施例1においては、委譲により旅費業務の決裁処理が新たに可能となり、決裁ボタンをアクティブにしたリソースのURLをクライアント端末1に表示させた。
【0136】
以上が、認証用ICカード12の利用者証明書を使ってシングルサインオン認証し、権限を委譲された利用者が、権限委譲証明書を使って、サービス・業務のアプリケーションサーバ5で認可されるまでの流れである。本発明による認可処理の流れは、認証用ICカード12の利用者証明書を使った個人認証と同じ操作であるので、利用者にとっても抵抗感無く操作することができる。また、バックエンドアプリケーションサーバ5での認可判定時に、失効リストリポジトリサーバ9を参照することで、利用者の異動など権限失効に対しても自動的に対処できる。
【0137】
[実施例1の効果]
上記してきたように、実施例1によれば、予算や業務に対する権限を有した多忙な教職員や部課長などの利用者にとっても、一度、権限委譲証明書を申請し、その証明書を秘書や部下のICカードに格納することにより、有効期限の範囲でアクセス権限を適切に委譲することができる。また、シングルサインオン認証およびアプリケーション側の認可処理において、利用者、アプリケーション側あるいはディレクトリサーバ側の負担を大幅に増大させずに、権限委譲を安全、安心に行うことができる。
【0138】
少なくとも、従来のように「なりますまし」による処理のようなセキュリティリスクの高い状況から解放され、ミスや不正利用に対してトレースできるといった効果がある。また、従来の権限委譲の方法に比べ、各サービス・業務のアプリケーションに対する申請処理あるいはディレクトリデータベースへの権限委譲情報の追加も必要なく、利用者の処理も大幅に軽減でき、安心して代行入力などが実施できる。
【0139】
さらに、バックエンドアプリケーションサーバ側あるいはディレクトリデータベースも申請ごとに処理することはなく、大きな作業量の負担は発生しなくなる。
【0140】
権限委譲された利用者の認可についても、シングルサインオン認証は従来通りであり、認可否決処理に権限委譲証明書要求が追加された程度であったため、従来の認可処理に比べて負担とは感じられない。従って、シングルサインオン認証のメリットを活かしつつ、権限委譲証明書による認可処理が行えるというメリットがある。
【0141】
実施例1においては、権限委譲証明書をバックエンドアプリケーションサーバ側が読み込み、それを条件として認可判定し、リソースへのアクセスを許可する。権限委譲情報は、複数の典型的なパターンを準備し、それらの一つを選択することにより、権限委譲証明書を発行させる。したがって、権限内容をよく理解している利用者本人が特定のパターンを選択して申請するため、アプリケーション側で行う審査が必要なく、ミスも大幅に抑制できる。
【0142】
また、権限委譲証明書の発行処理は、利用者が、各バックエンドアプリケーションサーバ側、あるいは、ディレクトリデータベースに行う代わりに、利用者証明書を発行した同じ手順にて行うため、処理に必要となる本人確認などの負担が大きく軽減でき、安心、安全に権限委譲の処理を行うことができる。
【0143】
また、シングルサインオン認証後、バックエンドアプリケーションサーバ側が利用者の権限委譲証明書を読み込み、さらに、失効リストリポジトリサーバを参照した上で、認可の判定を自動的に行う。したがって、バックエンドアプリケーションサーバ側での認可時点で、権限委譲証明書の利用者ID(権限を委譲した利用者および委譲された利用者のID)が登録されているため、リポジトリに提示された失効証明書リストを参照することによって、失効を検知でき、認可を拒否できるため、安心して認可処理を行うことができる。
【0144】
従来の技術では、権限を有する利用者が、アプリケーションごとに利用者申請を行い、アプリケーションサーバ側は、本人性を確認した上で申請の都度審査を行っていた。あるいは、権限を有する利用者がディレクトリデータベースに対して、権限委譲による認可情報を追加するように申請しなければならず、ディレクトリデータベース側は、その都度更新などの作業が増えていた。特に、シングルサインオン認証は、多数のサービス・業務を収容することが前提であるため、これら申請の際の本人確認や権限を委譲された人の本人確認および審査などに関る繁雑な処理は極めて膨大となり、シングルサインオン認証のメリットを損なっていた。また、申請と同様に、権限を有した利用者や権限を委譲された人が異動した場合、繁雑な失効申請を迅速に行うことが必要であり、これも作業が増える原因であった。
【実施例2】
【0145】
[他の実施例]
さて、これまで本発明の実施例について説明したが、本発明は上述した実施例以外にも、種々の異なる形態にて実施されてよいものである。
【0146】
[システム構成等]
実施例1において説明した各処理のうち、自動的におこなわれるものとして説明した処理の全部または一部を手動的におこなうこともでき、あるいは、手動的におこなわれるものとして説明した処理の全部または一部を公知の方法で自動的におこなうこともできる。この他、上記文書中や図面中で示した処理手順、制御手順、具体的名称、各種のデータやパラメータを含む情報については、特記する場合を除いて任意に変更することができる。
【0147】
また、図示した各装置の各構成要素は機能概念的なものであり、必ずしも物理的に図示の如く構成されていることを要しない。すなわち、各装置の分散・統合の具体的形態は図示のものに限られず、その全部または一部を、各種の負荷や使用状況などに応じて、任意の単位で機能的または物理的に分散・統合して構成することができる。さらに、各装置にて行なわれる各処理機能は、その全部または任意の一部が、CPUおよび当該CPUにて解析実行されるプログラムにて実現され、あるいは、ワイヤードロジックによるハードウェアとして実現され得る。
【0148】
なお、本実施例で説明した権限委譲方法は、あらかじめ用意されたプログラムをパーソナルコンピュータやワークステーションなどのコンピュータで実行することによって実現することができる。このプログラムは、インターネットなどのネットワークを介して配布することができる。また、このプログラムは、ハードディスク、フレキシブルディスク(FD)、CD-ROM、MO、DVDなどのコンピュータで読み取り可能な記録媒体に記録され、コンピュータによって記録媒体から読み出されることによって実行することもできる。
【産業上の利用可能性】
【0149】
以上のように、本発明に係る権限委譲システム、権限委譲方法および権限委譲プログラムは、アプリケーションサーバを利用する利用者の権限を判定して当該アプリケーションサーバの利用を制御することに有用であり、特に、権限を適切に委譲することに適する。
【図面の簡単な説明】
【0150】
【図1】実施例1に係る権限委譲システムの概要および特徴を説明するための図である。
【図2】実施例1に係る権限委譲システムの構成を示すブロック図である。
【図3】実施例1に係る権限委譲システムの構成を示すブロック図である。
【図4】認証用ICカードの発行と認証情報の格納の流れを説明するための図である。
【図5】権限委譲証明書に必要な構成要素を説明するための図である。
【図6】権限委譲情報パターンについて説明するための図である。
【図7】権限委譲証明書を申請する際の申請内容を説明するための図である。
【図8】権限委譲証明書を認証用ICカードに格納するまでの流れを説明するための図である。
【図9】本発明におけるシングルサインオン認証およびバックエンドアプリケーションサーバ5での認可のシステム構成例を示す図である。
【図10】本発明におけるシングルサインオン認証処理の流れを説明するための図である。
【図11】権限を有した利用者での認可処理を説明するための図である。
【図12-1】権限を委譲された利用者での認可処理の流れを説明するための図である。
【図12-2】権限を委譲された利用者での認可処理の流れを説明するための図である。
【図13-1】権限を委譲された利用者が権限変更を行う認可処理の流れを説明するための図である。
【図13-2】権限を委譲された利用者が権限変更を行う認可処理の流れを説明するための図である。
【図14】従来技術を説明するための図である。
【図15】従来技術を説明するための図である。
【符号の説明】
【0151】
1 クライアント端末
1a 証明書一覧部
1b ICカードアクセス部
1c 権限委譲証明書送信部
2 ネットワーク
3 認証サーバ
3a 権限委譲証明書要求画面部
3b 権限委譲証明書検証部
3c 権限委譲証明書転送部
3d 認可結果画面表示部
4 ディレクトリデータベース
5 バックエンドアプリケーションサーバ
5a 権限委譲証明書要求部
5b 権限委譲証明書確認部
5c 失効情報確認部
5d 認可結果通知部
7 プライベート発行局サーバ
7a 証明書発行部
7b 権限委譲証明書発行部
7c 権限委譲証明書失効部
7d 失効リスト公開部
8 登録局(RA)サーバ
8a 利用者認証部
8b 申請情報検証部
8c 鍵対生成部
8d 証明書発行要求部
8e 証明書管理部
8f 利用者証明書送信部
8g 権限委譲証明書発行要求部
8h 権限委譲証明書管理部
8i 権限委譲証明書送信部
8j 権限委譲証明書失効要求部
9 失効リストリポジトリサーバ
10 RA端末
10a 登録局サーバアクセス部
10b 利用者認証部
10c 証明書発行申請情報投入部
10d 利用者証明書ダウンロード部
10e 証明書データ送信部
10f 権限委譲証明書ダウンロード部
11 ICカード発行機
11a ICカードデータ書込部
12 認証用ICカード
13 リーダライタ
図面
【図1】
0
【図2】
1
【図3】
2
【図4】
3
【図5】
4
【図6】
5
【図7】
6
【図8】
7
【図9】
8
【図10】
9
【図11】
10
【図12-1】
11
【図12-2】
12
【図13-1】
13
【図13-2】
14
【図14】
15
【図15】
16