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

連載目次

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

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

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です。

　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の利用方法で、セキュリティ上の問題にもつながりました。