OpenAMのOpenID Connectへの対応：OSSによるアイデンティティ管理（4）（1/3 ページ）

OpenAMは、SAMLをはじめとする多くのフェデレーションプロトコルに対応しています。先日ローンチされたOpenID Connectにもいち早く対応しました。

[和田 広之（野村総合研究所）, 田村 広平（フリーランス），＠IT]

連載目次

OpenAMが提供するフェデレーションサービス

　第4回はOpenAMのOpenID Connectへの対応について紹介します。その前に、まずはOpenAMがこれまでに対応してきたフェデレーション^（注1）プロトコルについて簡単に解説し、今後主流になると思われるOpenID Connectの概要とOpenAMの対応内容について説明します。

注1　フェデレーション（Federation）：異なるサービス間の連携をすること。一般的には、SAMLなどの標準的なプロトコルを使用して複数のクラウドサービスへSSOできるようにすることを意味します。

OpenAMが対応するフェデレーションプロトコル

　OpenAMは、あらゆるサービスへのSSOを実現できるように、これまで多くのフェデレーションプロトコルに対応してきました。SAML 1.0の実装から始まり、WS-Federation 1.1やID-FF 1.2などの多くのプロトコルを実装してきました。さらにOpenAM 10.0.0ではOAuth 2.0を、OpenAM 11.0.0ではOpenID Connect 1.0を実装しています。

図1　OpenAMのフェデレーションプロトコル対応状況（出典：http://www.slideshare.net/ForgeRock/openam-an-introduction）

　OpenAMが対応している主なフェデレーションプロトコルとその概要は、以下の通りです。

プロトコル	概要
SAML 1.0 / 1.1 / 2.0	標準化団体OASIS Openによって策定された、認証情報を安全に交換するためのXMLベースのプロトコル。歴史あるプロトコルのため、多くのアイデンティティ管理ベンダーによって実装されており、提供されているサービスやソフトウェアが多い。Google AppsやSalesforceなどのクラウドサービス、学認（Shibboleth）などとの連携が可能（関連記事）。
Liberty ID-FF 1.1 / 1.2	Liberty Allianceによって策定されたフェデレーションプロトコル。SAML 1.0をベースに仕様が策定されたが、最終的にSAML 2.0に統一されている。
WS-Federation 1.1	標準化団体OASIS Openによって策定されたフェデレーションプロトコル。Webサービス向けのセキュリティ仕様「WS-Security」の構成要素。マイクロソフトなどが主な推進者。Active Directory Federation Serviceなどの、マイクロソフトが提供するサービスやソフトウェアと連携する場合に利用されることが多い。
OAuth 2.0	標準化団体IETFによって策定された、WebサービスのAPIへのアクセスを認可する方法を定めたプロトコル。認証ではなく、認可（どのリソースにアクセスできるか）について規定している点で他のプロトコルとは異なる。Facebook、Google Apps、Windows Liveなどさまざまなサービスで実装されている（関連記事）。
OpenID Connect 1.0	標準化団体OpenID Foundationによって策定されたREST/JSONベースのプロトコル。OAuth 2.0をベースに認証目的でも利用できるように拡張している。野村総合研究所、グーグルなどにより開発が開始され、2014年2月に最終承認された現在最も新しいフェデレーションプロトコル。多くの企業がサポートを表明しており、今後普及していく可能性が高い。グーグル、マイクロソフト、セールスフォースなどが既に一部のサービスでサポートを開始し、国内でもヤフー、ミクシィなどのサービスで実装されている。グーグルは、2015年4月までに全面的にOpenID Connectに移行することを予定している（関連記事）。
表1　OpenAMが対応している主なフェデレーションプロトコル

フェデレーションプロトコルの歴史と現状

　現在、グーグルやセールスフォースなどの大手クラウドサービスを中心に利用されているフェデレーションプロトコルが、SAMLです。

　SAMLの歴史は古く、最初のバージョンであるSAML 1.0の仕様が公開されたのは、10年以上前の2002年になります。その後、SAML 1.0をベースに、ID-FF（Liberty ID-FF 1.0）などが仕様化されましたが、最終的に各仕様はSAML 2.0として2005年に統合されています。それから現在に至るまで仕様は改定されることなく、最新バージョンは2.0のままとなっています。

　SAMLは非常に複雑なプロトコルであったため、急速に普及することはありませんでしたが、2014年現在においても、各社サービスでSAML 2.0に対応したとの発表があるように、徐々に対応サービスは増えています。ただし、いずれも大規模なユーザー数を保持するサービスばかりで、中小規模のユーザー数のサービスでは十分に普及しているとは言えないのが現状です。

　SAML同様に、WS-FederationもXMLベースの仕様で、マイクロソフトのサービスを中心に実装されてきました。しかし、Active Directory Federation ServicesがSAML 2.0に対応したように、近年はマイクロソフトを含む多くのベンダーがWS-FederationだけでなくSAMLをサポートする傾向があります。つい先日も、Office 365がSAML 2.0に対応したとのアナウンスがありました。

　SAMLやWS-Federationは、サービスを提供するベンダーがユーザー情報を管理する、ベンダー主導の認証体系でした。それに対して、ユーザー自身が認証サービスを選択し、ユーザー情報の提供・管理を行う、ユーザー主導の認証体系であるOpenIDが2006年ごろから注目されるようになりました。

　OpenIDは、サービス提供者間の事前の信頼関係の構築が不要なため、特にコンシューマー向けサービスを中心に普及しましたが、モバイルアプリケーションへの対応やセキュリティ要件などに対して、いくつかの課題を抱えていました。

　OpenIDは、認証について規定したプロトコルであり、その後どのリソースにアクセスできるかという認可については扱っていませんでした。そこで、認可の標準仕様の必要性が生まれ、策定されたのがOAuthです。

　OAuthはTwitterをはじめ、多くのサービスで実装されるようになりましたが、実際にはOAuth＋OpenIDの組み合わせで使われるよりも、単独で認証用途としても使われるようなケースが増加しました。これは仕様の設計者の意図しない不適切なOAuthの利用方法で、セキュリティ上の問題にもつながりました。