目次


SAML の迷信と誤解の正体を暴く

Security Assertion Markup Language の紹介

Comments

新参者の Security Assertion Markup Language (SAML) 仕様は、新しく導入されたため、既存の認証サービス、ディレクトリー・サービスなどのシングル・サイン・オン(SSO) 技術と比較されます。SAML は TCP/IP ネットワーク、HTTP 上で XML データを用いた Web インフラストラクチャにおいて、初めての認証プロトコルでしょう。

SAML はセキュリティ情報を交換するために XML ベースのフレームワークとして OASIS グループにより開発されました。SAML は主体に関するアサーションと言う形でセキュリティを表現するため、他のセキュリティのアプローチとは異なっています。他のアプローチでは、ネットワーク内のあるポイントから別のポイントへの安全な通信を保証する証明書を発行するために中央の認証オーソリティ (CA) を使用しています。SAML では、ネットワーク内のどのポイントでも、ユーザのアイデンティティやデータの一部を把握することができます。もし、受信側のアプリケーションがアサーションを信頼し、受け入れれば、それ以降の SAML 準拠のソフトウェアは、ユーザまたはデータの認証を有効とみなすことができます。このことは、信頼できるデータがいくつかのシステムを経由してトランザクションが完全に処理されるビジネス・ワークフローを持った Web サービス標準の来るべき潮流にとっては重要です。

SAML は公開して間もないのですが、SAML を取り巻く多くの迷信と誤解の実態を明らかにしておく必要があります。あなたが、現在明らかになっている標準をきちんと理解していれば、それは意味のないことかも知れません。

この記事では、SAML を取り巻く一般的な迷信と誤解のうちのいくつかに取り組むことにします。

誤解: SAML は完全なアイデンティティ管理ソリューションである。

SAML は、アイデンティティ管理ソリューションにおいて、サーバ間の通信プロトコルとしての重要な役割を果たしています。しかし、SAML はソリューションの全てではありません。情報システム・セキュリティ・スペースで、アイデンティティ管理はコンピューティングの以下のような範囲をカバーする新しい用語として最近出現しました。

  • プロビジョニング--企業内および外部のパートナー情報システムで、ネットワーク・オペレーティング・システム・ディレクトリおよびアプリケーションサーバ・ディレクトリへ新しいユーザを追加する。
  • パスワード管理--ユーザが企業の情報システムにサイン・オンするための資格証明を持つことができる。さらに、ユーザが自身のパスワード、ユーザアカウント・データ、および権限を管理することができる。
  • アクセス・コントロール--システムがユーザ・グループ用にセキュリティ・ポリシーを認識することができる。例えば、セキュリティ・ポリシーにより、誰かが他人の役職を変更することはできないが、代わりに適切なオーソリティへ役職を変更するリクエストを送るルートを決めることができる。

SAML は、2 つのサーバが認証情報を共有する必要があるときに使用されるプロトコル仕様です。しかし SAML 仕様は、商用ディレクトリー・サーバによって提供される実際の認証サービスは提供していません。

迷信: 企業間の Web シングル・サイン・オンは広く理解されており、実装も簡単である。

SAML は、複数のサービス・プロバイダ間で情報システムの構築および操作を相互運用しコストを低減するための試みのうちの 1 つです。今日の競争的でテンポの速い環境において、ブラウザや Web 対応のアプリケーションを通じてユーザにインターオペラビリティを提供するよう企業が連携を行うようになってきました。例えば、ユーザは旅行関連の Web サイトに 1 度サイン・オンすれば、航空券やレンタカーまでも予約することが可能になります。現状では、多数のソフトウェア開発者、QA 技術者、および IT 管理者は、企業間の連携したセキュリティを提供している複雑な、それでいて信頼性の低いバックエンド・システムを扱うことを求められています。

典型的な Web 対応のインフラストラクチャで、最先端の企業システムを実行しているソフトウェアは、認証サーバ間でのブラウザのリダイレクト、サーバ・ドメイン間の HTTP post コマンド、公開鍵基盤 (PKI) 暗号化、PKI 電子証明書などで、あるユーザやグループの信頼レベルを提示する合意されたメカニズムを扱う必要があります。SAML はソフトウェア開発者にどのようにユーザを表現するかを示し、転送されるべきデータを識別し、認証データを送受信するプロセスを定義しています。

迷信: SAML は複雑な設計である。

SAML は、Web インフラストラクチャ (XML/HTTP/TCP) 上にスケーラブルで連携したシステムを設計し構築する必要のあるシステム設計者に青写真を提供します。たとえ SAML を使用しないことにしたとしても、SAML の仕様は相互運用する Web 対応システムを構築する際に、システム設計者が答えを必要とする多くの設計上の疑問に答えることができます。

例として、XML リクエストに認証要求をエンコードするために使用される SAML アサーション・メカニズムを考えてみましょう。SAML では 6 つのステートメントを定義しています。

認証:主体のログイン。認証のための SAML アサーションは次のように見えるでしょう。

fcohen@pushtotest.com logged in at 2003-02-06T19:22:09Z

属性:主体のプロパティの識別。例えば、fcohen@pushtotest.com は管理者の役割を持っているなどです。

権限承認:主体がリソースに対するオペレーションを行うことができるという表明。例えば、fcohen@pushtotest.com は http://www.pushtotest.com/ptt/kits/index.html のGETが許可されるなどです。

アサーション属性:業界コンソーシアムが業界特有の属性を定義することができるオプショナルのメカニズム。

さらに、SAML はアサーションのステートメントで共有されるアサーション属性を次のように定義しています。

バージョン属性:アサーションが準拠する SAML 仕様のメジャーバージョン、マイナーバージョンの識別。

SAML は、認証要求の有効性を制限するためにオプショナルの条件要素も定義しています。例えば、SAML トークンが UTC エンコードした日付で指定した、NotBeforeあるいはNotOnOrAfterで有効とするなどです。

最後に、SAML は、オーソリティを識別するためにXML Signatureエレメントを定義しています。これには、公開鍵、有効期間、使用法のポリシーを備えた X509 証明書を含むことができます。XML Signature は、要素の内容にオーソリティによって生成された署名を含んでいます。その署名は X509 証明書におけるオーソリティの公開鍵情報を使用して証明することができます。一般的に、SAML の複雑さは、SAML ベースのソフトウェアの配備、および公開鍵基盤 (PKI) 環境および電子証明書のセットアップが原因となっています。

誤解: SAML にはほとんどの業界用の属性要件があらかじめ定義されている。

SAML には、どんな業界用の属性要件も定義されていません。代わりに、SAML には特定の業界の属性を定義するために業界コンソーシアムが使用する名前空間メカニズムが定義されています。例えば、航空宇宙産業では、SAML 属性role:mechanicは、航空会社の整備士を定義します。システムの両端に位置する関係者は、それぞれ SAML によって使用される名前空間に合意している必要があります。

SAML 仕様は、SAML の属性および要素を限定するために自身の名前空間を識別します。例えば名前空間「urn:oasis:names:tc:SAML:1.0:action: ghpp」は、SAML オペレーションで使用される http アクション get/head/put/post を定義します。SAML 名前空間のフォーマットが少し奇妙に感じられるかもしれませんが、それはおそらく SAML の名前空間が SOAP や XML-RPC のような従来の XML 名前空間のフォーマットを継承していないためです。XML の名前空間は URI ですが、SAML では URI の URN 変形を使用しており、他の従来のものは URL 変形を使用しています。

迷信: SAML は認証オーソリティである。

SAML はサーバ間で使用される認証プロトコルです。実際にログインするにはさらなる認証が必要でしょう。SAML が示すのは「ログインしました」ということだけです。例えば、LDAP サーバがユーザを認証するときには、認証オーソリティは LDAP サーバとなります(たとえ LDAP サーバが認可を伝達するために SAML を使用していたとしても)。

完全な認証システムでは、ユーザが Web ページへアクセスできるかどうかを決定するためにポリシー決定点 (PDP) を記述する必要があります。さらに、ポリシー実行点 (PEP) も記述する必要があります。これらは、認可を受けて、役割と認可を確認し、アサーションを行う servlet もしくはアプリケーションです。いくつかの企業(Oblix、Netegrity、IBM など)では、商用の PDP や PEP を提供しています。

誤解: SAML は認証に大量のデータを送信する必要があり Web 環境ではうまく機能しない。

認可のリクエストが HTTP リダイレクトにとって長すぎる場合、SAML はアーティファクト・メカニズムを定義します。SAML アーティファクトは長さ 42 バイトで、type-code を含んでいます。内訳は、ソース id に 20 バイト、サーバがアサーション検索に使用する 20 バイトの乱数で構成されます。ソース・サービスがアサーションを一時的に格納し、目的サイトがそのアサーションを受け取り、ソース・サイトのアーティファクトから必要なデータを直接取り出し (pull) ます。これにより、2 つの異なるセキュリティ・サーバでアーティファクトを使用することができます。

迷信: SAML はリプレイ・テクニックを使用して簡単に突破できる。

リプレイ攻撃とは、ある有効なメッセージが傍受され、サービスに対してリプレイされる攻撃のことです。リプレイ攻撃はサービス妨害攻撃と同様に、データの正当性問題を引き起こすことにもなります。

SAML は、リプレイ攻撃からの保護を提供しています。アサーションやメッセージ伝送の際、SAML はアサーションの傍受を防ぐために SSL 暗号の使用を要求しています。さらに、アサーションが後にリプレイされるのを防ぐために、SAML はアサーションが有効な時間範囲を持つことができるデジタル署名メカニズムを提供しています。

アーティファクト・プロファイルにはさらに 2 つのリプレイ対応策があります。

  • SAML ソース・サイトは、アーティファクトが送信されたリクエスト側にアサーションを返すだけです。
  • SAML ソース・サイトは、アーティファクトが使用された後、リプレイされるアーティファクトを無効にすることで、アーティファクトからアサーションへのマッピングをさせないようにしています。

誤解: SAML は認証オーソリティを見つけるための発見手順を定義している。

SAML には SAML アサーションを受理する目的サイトを見つけるメカニズムの定義がありません。

SAML は認証用のpushメカニズムを定義しています。push モデルでは、ユーザがソース・サイトにサイン・インすると、サイトは目的サイトにアサーションを送ります。このプロセスでは、ソース・サイトと目的サイト間にデジタル署名が必要です。Web 環境では、ブラウザが目的サイトへフォームをポストし、hidden のフォーム変数に Base64 にエンコードされた署名およびアサーションを持っています。

今後の SAML 仕様が発見メカニズムを含む可能性はあります。

迷信: SAML は匿名アクセスやゲスト・アクセスは処理しない。

SAML には、匿名の認証を提供する仕様がありません。あなたは Web サイトを通じてパートナーWeb サイトの機能を使用することができるものの、パートナーサイトはあなたが誰であるか知ることができないというシナリオを考えてみてください。SAML はこのような利用法を想定していません。SAML が匿名アクセスやゲスト・アクセスを処理することは可能です。しかしこのためには、匿名またはゲストとして認可されるアクセスの取り決めに、参加企業が合意する必要があります。

迷信: SAML はクライアントとサーバの両方で SSL 証明書が必要である。

SAML は、SAML アサーションのデジタル署名および暗号化を提供するために公開鍵基盤 (PKI) を必要とする前提のもと構築されています。したがって、SAML は PKI で期待される(良いも悪いも含めて)全ての機能をもたらします。

SAML はきめ細かいセキュリティを要求する最初のプロトコルのうちの 1 つです。例えば、SAML アサーションの認証に XML 鍵管理サービス (XKMS) が使用されています。一方、SAML は HTTP Basic あるいは SSL クライアント・サイド認証証明書を使用した HTTP クライアント・サイド認可を要求することにより、SAML アーティファクト用のセキュリティを提供しています。アーティファクトは予期された要求元にのみ送られ、取り出された後に削除されます。

誤解: SAML はベイパーウェアだ・・・誰もまだそれを実装していない。

SAML は、多くの商用製品やオープン・ソース製品で既に提供されています。その一部を以下に列挙します。

  • IBM Tivoli Access Manager
  • Oblix NetPoint
  • SunONE Identity Server
  • Baltimore, SelectAccess
  • Entegrity Solutions AssureAccess
  • Internet2 OpenSAML
  • Netegrity SiteMinder
  • Sigaba Secure Messaging Solutions
  • RSA Security ClearTrust
  • VeriSign Trust Integration Toolkit
  • Entrust GetAccess 7

誤解: マイクロソフトは SAML をサポートしない。

現時点では、Microsoft がどのように SAML をサポートするのかは明らかではありません。しかし、Microsoft や OASIS グループは、SAML を Microsoft のイニシアチブの元に調和させようとしています。Liberty Alliance や OASIS WS-Security プロジェクトからプロトコルを実装しているサービスと、Microsoft .NET Passport を含む Microsoft のプラットフォームやサービスがどのように相互運用できるか、ということが争点となっています。例えば、Liberty Alliance における認証の仕様も、Passport 専用システムも、認証トークンを交換するために SAML トークンを使用しています。しかし、2 つの認証システムでは、あるサイトから次のサイトへとトークンを伝達する方法が異なっています。

Microsoft は、WS-Security ロードマップと SAML プロジェクトを合理化することを公的に名言しています。彼らの関心は、SAML や XrML のような新しく登場した標準においても、既存の IT 投資で動作する汎用 Web サービス・セキュリティ・モデルとしての WS-Security にあるようです。Microsoft は、SAML アサーションを WS-Security の資格情報と同様に使用するために、OASIS WS-Security グループと共に活動しています。そして最近、OASIS WS-Security グループは、SAML の WS-Security バインディングを受け入れるようになりました。

Microsoft は、OASIS WS-Security グループを制御することができない一方で、Chris Kaler はワーキング・グループの共同議長であり、Microsoft の社員でもあります。もし Microsoft が Passport と Liberty Alliance で SAML を使用する計画のために形式的な承認を望むなら、Microsoft は ECMA の規格団体に提案を持っていったであろうと私は思います。

誤解: XML Signature に正規化は必要ない。

これは単純な誤りです。

XML Signature は SAML を含む XML 文書でデジタル署名を使用するため、特別な要件を満たすように設計された仕様です。W3C の XML Signature ワーキング・グループは、どこにでも(XML 文書、SOAP メッセージ・ヘッダー、XML 要素 など)署名でき、デジタル署名を作成したり照合したりするためのプロトコルと手続きを提供する XML 構文を開発しています。

XML Signature の正規化は、複数のサービス間での認証を可能とするために必要です。例えば、あなたがブラウザ・インタフェースでメーカーからパーソナル・コンピュータを買う場合、何がサーバ側で起こるか考えてください。複数のサービスが、あなたのオーダーの一部を処理しています。あるサービスは、あなたがオーダーしたい製品を見つけるために検索を提供します。別のサービスは、与信情報の取得と請求処理サービスです。そして最後のサービスは出荷情報の受付です。これらの 3 つのシステムは SAML アサーションを使用してあなたのレコードを共有しています。たとえ 3 つの異なるシステムがレコードを操作していても、正規化によりレコードのバイトオーダーは同じ状態のままであリ続けます。XML Signature の使命は、署名したコンテンツが変わっておらず、バイト順序も同じであることを確かめることにありますが、正規化無しではレコードが変更され XML Signature が無効となるかもしれません。

要約

セキュリティに焦点を置いた多くの企業が既に製品を出荷しており、SAML は素晴らしいスタートを切っています。SAML 仕様は連携したサービス・グループにおいて、Web 対応のシングル・サイン・オン・サービスを設計するためのフレームワークを提供しています。SAML 仕様ワーキング・グループでは、WS-Security を含む SAML と他の新しい標準との相互運用要件を合理化し続けています。

私はこの記事のための調査にあたり、Oblix 社の主任エンジニアである Charles Knous 氏、および Web Services Special Interest Group of the Software Development Forum (www.sdforum.org) の支援に感謝しています


ダウンロード可能なリソース


関連トピック

  • OASIS コンソーシアム・サイトでSAML 仕様を参照してください。
  • Murdoch Mactaggart 氏の developerWorks 記事「XML でのセキュリティー保護」(2001年 9月) は、XML の暗号化や XML Signature についての優れた入門書です。
  • developerWorks の「WS-Security Profile for XML-based Tokens」(2002年 8月) で、今後の Web サービス・セキュリティ・プロトコルがどのように機能していくのかを確かめてください。
  • Jon Udell 氏のInfoWorldの記事において SAML と PKI に関するバックグラウンドについての知識を深めてください。
  • XML デジタル署名の実装のために、alphaWorks のXML Security Suiteをダウンロードしてください。
  • Web サービスに先立ちよく知られていた XML のシングル・サイン・オンのアプローチに関しては、Frank Cohen による過去の記事を参照してください (developerWorks、2002年 1月)。
  • その他にも developerWorks の XML ゾーンの中に参考になるものがたくさんあります。
  • Java または他の言語で XML 開発を自動化するツール群としてIBM WebSphere Studioがありますので、入手してみて下さい。WebSphere Application Serverと緊密に連携されているものですが、他の J2EE サーバで使うことも出来ます。
  • XML 及び関連技術において IBM 認証開発者になる方法についてはこちらを参照してください。

コメント

コメントを登録するにはサインインあるいは登録してください。

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=XML
ArticleID=295596
ArticleTitle=SAML の迷信と誤解の正体を暴く
publish-date=07082003