HP IceWallを活用したクラウドにおける認証システムの最新動向第2回

4.3.3 SAMLレスポンスの生成

社内ポータル（Identity Provider）は、下記のようなSAMLレスポンスを生成します。

ポイント（6）	SAMLでは、Identity Providerが、認証情報（ユーザーはどのような方法で認証されたかなど）をアサーション（Assertion）と呼ばれるXMLで作成します。 SAMLでは、アサーションを相手サイトに渡す場合、認証レスポンス（Response）と呼ばれるXMLでさらに包みます。各電文のXML形式は、SAMLの「Core」仕様書に記述されています。

ポイント（6）

SAMLでは、Identity Providerが、認証情報（ユーザーはどのような方法で認証されたかなど）をアサーション（Assertion）と呼ばれるXMLで作成します。
SAMLでは、アサーションを相手サイトに渡す場合、認証レスポンス（Response）と呼ばれるXMLでさらに包みます。
各電文のXML形式は、SAMLの「Core」仕様書に記述されています。

次に、Identity Providerは、認証レスポンスが改ざんされないように認証レスポンスに、XML署名と呼ばれる方法で署名を付けます。この署名には最初に作成した秘密鍵を使用します。

ポイント（7）	SAMLでは、社内ポータル（Identity Provider）からsalesforce（Service Provider）へ送る認証レスポンスには、XML署名を必ず付けます。 XML署名を付けることで、悪意のあるユーザーが認証レスポンスを改ざんすることを防ぎます。

4.3.4 SAMLレスポンスの送信

社内ポータル（Identity Provider）は、上記で作成した認証レスポンス（XML）をBASE64でエンコード後、下記のようなHTMLを使用し、ブラウザ経由で、salesforce（Service Provider）へ認証レスポンス（XML）転送します。

PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iVVRGLTgiPz48c2FtbHA6UmVzcG9uc2UgeG1sbnM6c2FtbHA9InVybjpvYXNpczpuYW1lczp0YzpTQU1MOjIuMDpwcm90b2NvbCIgeG1sbnM9InVybjpvYXNpczpuYW1lczp0YzpTQU1MOjIuMDphc3NlcnRpb24iIHhtbG5zOnhlbmM9Imh0dHA6Ly93d3cudzMub3JnLzIwMDEvMDQveG1sZW5jIyIgSUQ9ImlTVWV2dlUySnV5cFdneXBUU05CMVhxb1NmamdsWEdoT3N4bW5Ja2F0IiBJc3N1ZUluc3RhbnQ9IjIwMTEtMDEtMjhUMDc6NTU6MDlaIiBWZXJzaW9uPSIyLjAiPgogIDxJc3N1ZXI+aHR0cDovL2l3c2FtbHAuZXhhbXBsZS5jb208L0lzc3Vlcj4KICA8U2lnbmF0dXJlIHhtbG5zPSJodHRwOi8vd3d3LnczLm9yZy8yMDAwLzA5L3htbGRzaWcjIj48U2lnbmVkSW5mbz48Q2Fub25pY2FsaXphdGlvbk1ldGhvZCBBbGdvcml0aG09Imh0dHA6Ly93d3cudzMub3JnL1RSLzIwMDEvUkVDLXhtbC1jMTRuLTIwMDEwMzE1I1dpdGhDb21tZW50cyIvPjxTaWduYXR1cmVNZXRob2QgQWxnb3JpdGhtPSJodHRwOi8vd3d3LnczLm9yZy8yMDAwLzA5L3htbGRzaWcjcnNhLXNoYTEiLz48UmVmZXJlbmNlIFVSST0iIj48VHJhbnNmb3Jtcz48VHJhbnNmb3JtIEFsZ29yaXRobT0iaHR0cDovL3d3dy53My5vcmcvMjAwMC8wOS94bWxkc2lnI2VudmVsb3BlZC1zaWduYXR1cmUiLz48L1RyYW5zZm9ybXM+PERpZ2VzdE1ldGhvZCBBbGdvcml0aG09Imh0dHA6Ly93d3cudzMub3JnLzIwMDAvMDkveG1sZHNpZyNzaGExIi8+PERpZ2VzdFZhbHVlPnhGYm12WTZYQytWVWx6bkpsQ05EUXdLWGZaQT08L0RpZ2VzdFZhbHVlPjwvUmVmZXJlbmNlPjwvU2lnbmVkSW5mbz48U2lnbmF0dXJlVmFsdWU+VTI5ckd2TGJBWFlZUHNVU2duUGdGYkNWeEg5YXBLUTFNbXJvNlVydlB0bllVQituUHhtQ0NpUVdDQllDM0RYd1hhc05DcmVpRmEzeApHZDIySEFQZ0RVOHQzeW54UE5TeXR2OG1tWk83TjB1UG1waTJyVUtia1FQVHlJUFVUMkdJdFcxRGVSL0N0ZW5qR1FxS0RzMitxL1hyCjBQKy9tV21wUUU4TjJyaHkwUFk9PC9TaWduYXR1cmVWYWx1ZT48L1NpZ25hdHVyZT48c2FtbHA6U3RhdHVzPgogICAgPHNhbWxwOlN0YXR1c0NvZGUgVmFsdWU9InVybjpvYXNpczpuYW1lczp0YzpTQU1MOjIuMDpzdGF0dXM6U3VjY2VzcyIvPgogIDwvc2FtbHA6U3RhdHVzPgogIDxBc3NlcnRpb24gSUQ9Imlzd1lwUXVxbzRXaDlYMFlYNHpETFVlalJIb25OTkxvcXE2VXlIRUFOIiBJc3N1ZUluc3RhbnQ9IjIwMTEtMDEtMjhUMDc6NTU6MDlaIiBWZXJzaW9uPSIyLjAiIHhtbG5zPSJ1cm46b2FzaXM6bmFtZXM6dGM6U0FNTDoyLjA6YXNzZXJ0aW9uIj4KICAgIDxJc3N1ZXI+aHR0cDovL2l3c2FtbHAuZXhhbXBsZS5jb208L0lzc3Vlcj4KICAgIDxTdWJqZWN0PgogICAgICA8TmFtZUlEIEZvcm1hdD0idXJuOm9hc2lzOm5hbWVzOnRjOlNBTUw6MS4xOm5hbWVpZC1mb3JtYXQ6dW5zcGVjaWZpZWQiPmthenV0b3NoaS55b25la2F3YUBocC5jb208L05hbWVJRD4KICAgICAgPFN1YmplY3RDb25maXJtYXRpb24gTWV0aG9kPSJ1cm46b2FzaXM6bmFtZXM6dGM6U0FNTDoyLjA6Y206YmVhcmVyIj4KICAgICAgICA8U3ViamVjdENvbmZpcm1hdGlvbkRhdGEgTm90T25PckFmdGVyPSIyMDExLTAxLTI4VDA4OjA1OjA5WiIgUmVjaXBpZW50PSJodHRwczovL2xvZ2luLnNhbGVzZm9yY2UuY29tIi8+CiAgICAgICAgPC9TdWJqZWN0Q29uZmlybWF0aW9uPgogICAgPC9TdWJqZWN0PgogICAgPENvbmRpdGlvbnMgTm90QmVmb3JlPSIyMDExLTAxLTI4VDA3OjUwOjA5WiIgTm90T25PckFmdGVyPSIyMDExLTAxLTI4VDA4OjA1OjA5WiI+CiAgICAgIDxBdWRpZW5jZVJlc3RyaWN0aW9uPgogICAgICAgIDxBdWRpZW5jZT5odHRwczovL3NhbWwuc2FsZXNmb3JjZS5jb208L0F1ZGllbmNlPgogICAgICA8L0F1ZGllbmNlUmVzdHJpY3Rpb24+CiAgICA8L0NvbmRpdGlvbnM+CiAgICA8QXV0aG5TdGF0ZW1lbnQgQXV0aG5JbnN0YW50PSIyMDExLTAxLTI4VDA3OjU1OjA5WiI+CiAgICAgIDxBdXRobkNvbnRleHQ+CiAgICAgICAgPEF1dGhuQ29udGV4dENsYXNzUmVmPnVybjpvYXNpczpuYW1lczp0YzpTQU1MOjIuMDphYzpjbGFzc2VzOlBhc3N3b3JkPC9BdXRobkNvbnRleHRDbGFzc1JlZj4KICAgICAgPC9BdXRobkNvbnRleHQ+CiAgICA8L0F1dGhuU3RhdGVtZW50PgogIDwvQXNzZXJ0aW9uPgo8L3NhbWxwOlJlc3BvbnNlPg==

ポイント（8）	SAMLでは、社内ポータル（Identity Provider）からsalesforce（Service Provider）へ、ブラウザを経由して認証レスポンスを送信します。電文を送信する方法は、SAMLの「Bindings」仕様書に記述されています。

ポイント（9）	認証レスポンスの送信にJavaScriptを使用することで、ユーザーは、ブラウザが認証レスポンスを送信していることを意識する必要はありません。

4.3.5 認証連携の完了

salesforce（Service Provider）は、社内ポータル（Identity Provider）からの認証レスポンスを、ブラウザを経由して受信します。salesforceは、認証レスポンスの署名を検証し、次に、SAMLレスポンス内の認証情報を確認します。認証情報に問題なければ、以降からユーザーがsalesforceのコンテンツにアクセスすることを許可します。

5. Google Appsとの認証連携

次に、Google Apps（Service Provider）との認証連携について説明します。基本的にはsalesforceと同じです。Google Appsの場合は、下記のようにSAMLリクエストを送信する点だけが異なります。

図7：Google Appsへ認証連携するシーケンス（クリックで拡大）

Google Appsが送信するSAMLリクエストは、以下のような電文です。

上記の電文はDEFLATE圧縮アルゴリズムとBASE64でエンコードされています。デコードすると以下のXMLになります。

ポイント（10）	SAMLでは、認証連携を開始する方法として、「SP-Initiated SSO」と「IdP-Initiated SSO」の2種類があります。これは、SAMLの電文がどちらから始まるかで区別されます^＊2。 salesforceでは社内ポータル（Identity Provider）からSAMLの電文が始まっているため「IdP-Initiated SSO」です^＊3。Google Appsでは、Google Apps（Service Provider）からSAMLの電文が始まっているので「SP-Initiated SSO」です。

ポイント（10）

SAMLでは、認証連携を開始する方法として、「SP-Initiated SSO」と「IdP-Initiated SSO」の2種類があります。これは、SAMLの電文がどちらから始まるかで区別されます^＊2。
salesforceでは社内ポータル（Identity Provider）からSAMLの電文が始まっているため「IdP-Initiated SSO」です^＊3。Google Appsでは、Google Apps（Service Provider）からSAMLの電文が始まっているので「SP-Initiated SSO」です。

[*2] ブラウザがIdentity Provider、Service Providerのどちらに「最初にアクセスしたか」ではない点にご注意ください。あくまでも、SAMLの電文を最初に発行した（＝SAMLとして認証連携のトリガーを引いた）点が基準になります。
[*3] salesforceは部分的にSP-Initiated SSOにも対応しています。

6. まとめ

この記事では、以下を説明しました。

クラウドとの認証連携について
クラウドとの認証連携に使用される技術
SAMLの動作とポイント

この記事が、クラウドとの認証連携とSAMLの理解にお役に立てれば幸いです。

7. HP IceWall Federationのご紹介

この記事によりSAMLの具体的な動作は理解していただけたと思います。とはいえ、詳細を理解するにはSAMLの仕様書を読む必要があります。そこで、筆者の所属する日本HPでは、salesforceやGoogle Appsなど、それぞれのサービスとの認証連携に特化したアプリケーションとして、HP IceWallを開発しました。これにより、SAMLを意識せずに社内（学内）システムから認証連携ができます。ご興味にある方はこちらをご覧いただければと思います。

図8：HP HP IceWall Federationの導入例（クリックで拡大）

次回はクラウドの活用事例についてご紹介します

この記事のキーワード：

この記事をシェアしてください

認証データベースへのHBase/Hadoopの適用

クラウドの活用事例

バックナンバー

この記事の筆者

米川和利

日本ヒューレットパッカード株式会社

1995年日立製作所に入社。システム、アプリケーション開発に従事。2001年より現職。
シングルサインオン、アイデンティティ管理、SAML・OpenIDの製品開発に従事する。
小学6年生の時に、カシオのPB-100が懸賞で当たったのがプログラミングの始まり。Javaをこよなく愛するが、最近は、PHPとC#が気になる。趣味は熱帯魚の飼育。週末は、妻と4歳の息子とで食べ歩き。
http://twitter.com/k_yonekawa

米川和利のプロフィールを見る