3 認証技術の標準化動向
3.5. シングルサインオンシングルサインオン(SSO)
3.5.1 SAML(Security Assertion Markup Language)
利用者の資格などの属性によってアクセスできるページやWebサイトを制限 したり、また与えられたアクセス権限により資源へのアクセスを制御するいわ ゆる認可サービスが必要である。SAMLは認証情報伝達サービス
(Authentication Assertion)に加えて2つの認可サービスが加えられている。
1つは属性情報の伝達(Authorization Assertion)であり、もう1つはアクセ ス制御情報の伝達(Authorization Decision Assertion)である。
SAML仕様はPKIのセキュリティ環境の利用のみを前提にしたものではな く、セキュリティを強化したID/パスワードから対称鍵を使った認証も使うこ とが出来る幅の広いものとなっている。
SAML標準の1つの目的は、異なるベンダのアクセス制御製品間の相互運用 性を推進することである。現状では異なるベンダ製品で既に大規模に展開され たサイト間でのSSOを実現することが難しい。しかし、SAML標準を実装し たアクセス制御製品間では連携SSOが可能となる。
・SAMLのモデル
SAMLはセキュリティ情報交換のためのXMLベースのフレームワークであ る。SAMLは要求と応答のプロトコルと応答に含まれるアサーションの構文仕 様を定めたものである。このセキュリティ情報は対象とする主体(Subject:人 又はコンピュータ)のあるセキュリティドメインにおける認証情報や属性情報 や認可情報をアサーションの形式で表現する。
SAML オーソリティには以下の3つのオーソリティがあり、要求者の問合わ
せに対して、
・認証オーソリティは認証情報の再利用(SSO)を可能にする「認証アサー ション」を提供する
・属性オーソリティはポリシーに定めた資格や役職などの「属性アサーショ ン」提供する
・認可決定オーソリティはポリシーで定めた規則に従った「認可決定アサー ション」提供する
アサーションの提供を受けた要求者はこれらのアサーションをそれぞれのポ リシーで実行するアプリケーション(PEP:Policy Enforcement Point)に渡 し要求を実行する。すなわち、
・本人性(Identity)を認証し、
・本人の資格属性情報を収集し、
・本人の認可権限によって特定の資源へのアクセス(読み、書き、実行など)
させる
図 3-27にSAMLのフレームワークを示す。図に示すようにSystem Entity
(主体のクライアント又はクライアントからアクセス要求を受けたサーバー)
は、まずSAML 認証オーソリティにSAML認証要求としてクレデンシャル(パ スワードや鍵情報など)を示す。認証オーソリティは認証ポリシーや外部の認 証環境(PKIなど)を検証して、主体の本人性(Identity)を証明する認証ア サーション(Authentication Assertion)を発行する。次にこの認証アサーシ ョンを属性オーソリティ又はPDP(Policy Decision Point)に示して認可権限 を問合わせる。属性オーソリティはポリシーに沿った主体の資格などの属性ア サーションを発行し、PDPに主体のアクセス権限を問合わせる。PDPは予め 登録された認可権限をポリシーデータベースから検索し属性決定アサーション を発行し、実際にアクセス制御を行うPEP(Policy Enforcement Point)に渡 しアプリケーション要求に沿ったWebページへのアクセスや資源へのアクセ スを実行させるのである。
Authentication Authority
Attribute
Authority Polic
Authenticatio n
Attribute
Assertion Author
Policy Enforcement Point(PEP)
System Entity
Policy Policy Policy
外部認証環境 PKIなど
クレデンシャル 情報(鍵情報など)
アプリケーション要求 SAML
要求
クライアント又は
アクセス要求を受けたサーバ
アクセス制御の実行 SAML
SAML Authority
アクセス規則など
(Rule) 属性DBなど
(Role)
図 3‑ 27 SAML フレームワーク
シングルサインオン(SSO)
SAMLの主要な利用法にはシングルサインオン(SSO)がある。SSOの概 念は図 3-28に示すように、(Step 1)Webユーザーは最初にソースWebサイ ト(認証オーソリティ)で認証を受ける。(Step 2)その後この認証情報を用い て他のWebサイトに再度認証することなくアクセスできる。
Web ユ ー ザ
ソース
Webサイト
目的
Webサイト
Step 1 認証
Step 2 セ キ ュ ア な 資 源 の 利
SAML 認 証 オ ー ソ リ テ
ブラウザユーザー又は Webサーバ
図 3‑ 28 シングルサイン・モデル
・SSO Pullモデル
SSOにはPullモデルとPushモデルがある。ここではPullモデルを示すこ とにする。Pullモデルは図 3-29に示すようなSSO認証の手順をとる。①Web ユーザーがクレデンシャル(パスワード又は公開鍵又は認証の参照先)を示し て、②ソースWebサイトで認証を受けた後に、③目的Webサイトにアクセス すると、④目的WebサイトはWebユーザーの認証情報をソースWebサイトに 問合わせ、⑤認証アサーションを引き出す(Pull)。⑥その後Webユーザーは 目的Webサイトの資源を利用出来るようになる。
ソース Webサイト
目的 Webサイト
Webユーザー
① 認証と目的へのリンク
② 認証の参照先
③ 目的へのアクセス要求
④ SAML認証要求
⑤ SAML認証提供(Pull)
⑥ 目的サイトの 資源を提供
図 3‑ 29 SSO Pul l モデル
・SAMLプロトコルとSAMLアサーション
SAMLプロトコルは要求と応答の手順を定めたものである。SAMLは下位の トランスポートプロトコルに独立に定めているが、1つのバインディングとし てSAML over SOAP over HTTPの仕様をOASISで定めている。
SAMLプロトコルを図 3-30に示す。SAMLクライアント(Requester)は 要求プロトコル<Request>要素の子要素に各種の<Query>要素を指定して要 求を送信する。SAMLレスポンダ(SAML オーソリティ)は応答プロトコル
<Response>要素の子要素に<Status>要素と<Assertion>要素を含めた応答を 返す。<Response>処理で何らかのエラーが生じた場合、<Response>要素は
<Status>要素にエラーコードを返すだけで<Assertion>要素は含まない。
SAMLクライアント
(Requester)
SAMLレスポンダ
(SAML Authority)
<Request>
<xxQuery>
…
</xxQuery>
</Request>
<Response>
<Status>…</Status>
<Assertion>
…
</Assertion>
</Response>
要求
応答
認証、属性 、 認可決定 などどれかのQueryを 要求する
認証、 属性 、 認可決定 などど れか の アサーシ ョンを応答する 要求処理のステータス
Successやエラーコードを返す
図 3‑ 30 SAML プロトコル
SAMLの<Request>、<Response>及び<Assertion>にはデジタル署名(XML 署名)を付けることができる。デジタル署名はオプションであるが、デジタル 署名を付けた場合、送信者の識別や否認防止を強力にサポートする。
SAMLは柔軟で拡張性に富む認証と認可の仕組みを提供している。SAMLは Webサービスのセキュリティメカニズムをサポートし、標準的手法で認証アサ ーションをアプリケーションに伝達できる。今後SAMLを実装した各種のアプ リケーションに採用されていくであろう。