SAMLからOpenID Connectへ - フェデレーション技術の広がり

Prepared for Enterprise Identity Working Group seminar by OpenID Foundation Japan

Transcript

1. 工藤達雄 株式会社野村総合研究所 http://www.linkedin.com/in/tatsuokudo SAMLからOpenID Connectへ フェデレーション技術の広がり
2. Copyright 2013 OpenID Foundation Japan - All Rights Reserved. SAML「から」OpenID Connectへ…? そもそも、「従業員向けSaaS/ASP」において SAMLは普及しているのだろうか? SAML SP（サービス・プロバイダ）機能を 備えたSaaS/ASPは増えているが、大多数が あまり利用されていないのはなぜだろうか? 1
3. Copyright 2013 OpenID Foundation Japan - All Rights Reserved. 普及しているのは「特定SaaS/ASPのSAML」 2 年 仕様 製品・サービス（主要トピック） 2002 SAML 1.0 承認 ID-FF 1.0 公開 •SSOベンダがSAML対応を表明 2003 SAML 1.1 承認 ID-FF 1.1, 1.2 公開 •SAML対応SSO製品が複数登場（当初はオプション機能だったが、後に製品標準 装備として提供されることが一般的に） 2004 •SAML対応Appサーバ、グループウェアなどが複数登場 2005 SAML 2.0 承認 •英語圏において、複数のASP（WebExなど）がSAML SP（サービス・プロバイダ） 機能を実装 2006 •Google AppsがSAML 2.0 SP機能を実装 2007 •LDAPサーバやActive Directoryと連携し、従業員IDを用いてGoogle Appsに ログインするためのゲートウェイ（Google Apps専用IdP）製品が複数登場 2008 •Salesforce.comがSAML 1.1 SP機能を実装 •複数のSAML対応SSO製品が、Google AppsやSalesforce.comと連携する ためのIdP設定をかんたんに行える機能（ウィザードなど）を実装 •ゲートウェイ（Google Apps専用IdP）機能を提供するASPが複数登場 2009 •英語圏において、従業員IDで複数のSaaS/ASPにログインするためのゲートウェイ 機能を提供するSaaS（IDaaS）が複数登場 … SAMLの歴史（従業員向けSaaS/ASPの文脈で）
4. Copyright 2013 OpenID Foundation Japan - All Rights Reserved. ID管理システム プロビ ジョニング システム SSO / アクセス 管理 システム 「特定SaaS/ASPのSAML」であれば 利用企業側は連携環境を構築しやすい 3 GApps独自の ユーザープロビジョニング API エンドユーザー 向けWeb アプリケーション 社内の ユーザー追加・ 変更・削除 GAppsの 利用 管理者 エンドユーザー 利用企業A社 Google Apps SFDC独自のユーザー・ プロビジョニング API エンドユーザー 向けWeb アプリケーション Salesforce.com SFDCの 利用 SFDC独自APIに 従い、SFDCの ユーザー追加・ 変更・削除 GAppsのAPIに従い、 GAppsのユーザー 追加・変更・削除 GApps 独自の 方法で認証 結果・属性 情報要求 社内IDで ログイン SFDC独自の方 法でID管理結果・ 属性情報要求 人事情報 システム 社内の ユーザー追加・ 変更・削除 GApps独自 接続機能 SFDC独自API 接続機能 SFDC独自方式 準拠API GApps独自方 式準拠API
5. Copyright 2013 OpenID Foundation Japan - All Rights Reserved. SAML対応SaaS/ASPの「勝ち組」と「負け組」 勝ち組 • SSO製品が「設定ウィザード」を提供し てくれる • フル装備のSSOソリューションから単機 能なゲートウェイまで、あるいはオンプ レミスからサービス利用まで、幅広い選 択肢がある • （準勝ち組）SSO製品に広くサポートさ れているとはいえないものの、ニーズが 高く、SAML IdP設定ノウハウが蓄積さ れつつある。また英語圏ではIDaaSが 標準でサポートしている 負け組 • SSO製品がサポートしていないため、 利用企業側が自前でSAML IdP設定を しなくてはならない • 利用企業側でのIdP設定の難易度が高 いため、費用がかかり、SAML連携が 普及しない • SAML連携が普及しないため、SSO製 品による標準サポートが行われない • そして負のスパイラルへ… 4
6. Copyright 2013 OpenID Foundation Japan - All Rights Reserved. これから「従業員IDでログイン」機能を提供する SaaS/ASPが「負け組」にならないためには  いまからGoogle AppsやSalesforce.comの真似をしても無意味  利用企業ががんばってSAML IdPになったのは、彼らのサービスが魅力的で あったから  多数のベンダがさまざまな「専用SAML IdP」を提供するようになったの は、ユーザーベースが巨大だったから  利用企業側のコストとリスクを最小化しないといけない  独自SAMLプロフゔイルや独自仕様に対応するのは利用企業の負担となる  複数のASP/SaaSに対して連携できることが望ましい 5 SAML SPではなくOpenID Connect RP*になる *Relying Party （リライング・パーティ）
7. Copyright 2013 OpenID Foundation Japan - All Rights Reserved. ID管理システム プロビ ジョニング システム SSO / アクセス 管理 システム 利用企業とSaaS/ASPとの間のID連携仕様を OpenID Connect によって共通化 ユーザー・ プロビジョニングAPI （SCIM Server) エンドユーザー向けWeb アプリケーション （OpenID Connect RP） 社内の ユーザー追加・ 変更・削除 サービスAの 利用 管理者 エンドユーザー 利用企業A社 SaaS A社 ユーザー・ プロビジョニングAPI （SCIM Server) エンドユーザー向けWeb アプリケーション （OpenID Connect RP） SaaS B社 サービスBの 利用 SCIM APIに従い、 サービスBの ユーザー追加・ 変更・削除 SCIM APIに従い、 サービスAの ユーザー追加・ 変更・削除 OpenID Connectで認 証結果・属性 情報要求 社内IDで ログイン OpenID Connectで ID管理結果・属性情 報要求 人事情報 システム 社内の ユーザー追加・ 変更・削除 ID連携API （OpenID Connect IdP) プロビジョニン グ機能（SCIM Client) 6
8. Copyright 2013 OpenID Foundation Japan - All Rights Reserved. APIアクセス認可への拡張 7 ID情報 （部門、役職、 内線、…） 1 2 3 4 8 5 6 7 企業 2. ユーザのID情報を要求 （認証リクエスト） 4. ユーザのID情報を返却 （認証レスポンス） 同時に「トークン」（API アクセス権の情報）を返却 5. 「トークン」を用いて、ユーザー に成り代わってWebサービスの APIを呼び出し 会社A ID連携システム 会社Aユーザ 会社A Webサービス Webアプリケーション 6. 「トークン」の有効 性・真正性を確認 7. 処理結果（業務データ など）を返却 8. 企業を またがって マッシュアップした コンテンツを提供 全社共有情報 ・インフルエンザ ・CSR活動参加 ・海外渡航注意喚起 ・セミナー連絡 などなど 部門向け情報 個人向け情報 ・賞与 ・保険加入 ・人間ドック ・申請状況一覧 ・◦◦部組合員情報 など プロジェクト 向け情報 3. 社内のIDで ユーザ認証 会社A 共通IDシステム 会社AのIDで ログイン 1. 社外のアプリケー ションにアクセス 業務データ Web API
9. Copyright 2013 OpenID Foundation Japan - All Rights Reserved. 8 SAMLだけではAPIアクセス認可まで対応できない 仕様 SAML 2.0 OAuth 1.0 OAuth 2.0 OpenID 2.0 OpenID Connect ID受け入れ側（リラ イング・パーティ）の 実装・運用の容易さ ×（XMLやSOAP、PKIなどの スキルが必要であり、通常は SAML処理ライブラリやミドル ウェアの導入が必須） △（署名処理が必要であり、通常は OAuth処理ライブラリなどの導入が 必須） ◦（ライブラリ等の導入が不要） △（鍵交換や署名処理が必要であ り、通常はOpenID処理ライブラリ などの導入が必須） ◦（ライブラリ等の導入が不要） Webブラウザ以外 （デスクトップアプリ、 スマートフォンアプリ など）への対応 △（仕様上はWebブラウザ以 外にも対応可能だが、実際に 広く利用されているのはWeb SSOのみ） ◦ ◦ ×（Webブラウザのリダイレクト機 能に依存したプロトコルであり、 Webブラウザ以外への対応は不 可能） ◦ 認証結果の連携 ◦ ×（仕様のスコープ外であり、OAuth 採用事業者の独自拡張が乱立） ×（仕様のスコープ外であり、OAuth 採用事業者の独自拡張が乱立） ◦ ◦ 属性情報の連携 ◦ ×（仕様のスコープ外であり、OAuth 採用事業者の独自拡張が乱立） ×（仕様のスコープ外であり、OAuth 採用事業者の独自拡張が乱立） ◦ ◦ APIアクセス認可 （アクセストークン配 布）への対応 ×（仕様のスコープ外） ◦ ◦ △（OAuth 1.0とのハイブリッドに より対応） ◦ 複数のアクセストー クンへの対応 ×（仕様のスコープ外） ×（仕様のスコープ外） ×（仕様のスコープ外） ×（仕様のスコープ外） ◦ 認証結果・属性情報 への署名や暗号化 ◦ ×（そもそも、認証結果・属性情報の 連携は仕様のスコープ外） ×（そもそも、認証結果・属性情報の 連携は仕様のスコープ外） △（共有鍵による署名のみ可能。 暗号化は仕様のスコープ外） ◦ サイト間のセッション 管理 ◦ ×（仕様のスコープ外） ×（仕様のスコープ外） ×（仕様のスコープ外） ◦ 機能の不十分な Webブラウザ（携帯 電話等）への対応 × ◦ ◦ × ◦ 備考 さまざまなユースケースに適用 可能な仕様であるが、それゆ えに複雑であり、結果的には企 業内ID管理システムと企業向 けSaaSとの間でのSSOに利 用されるにとどまっている。 Web APIのアクセス認証プロトコル として広く普及。ただしメッセージへ の署名処理など、実装が難しい点も ある。またID連携に関しては仕様の スコープ外のため、独自仕様が乱立 している。 OAuth 1.0をベースに、より容易に 実装できるように仕様を簡略化。 OAuth 1.0を採用していた事業者は 現在徐々にOAuth 2.0に移行しつつ ある。しかしOAuth 1.0同様、ID連 携に関してはスコープ外。 Webサイト間の認証結果・属性情 報の交換に特化したプロトコルで あり、従前の仕様（SAML 2.0)に 比較して単純なプロトコルであるが、 鍵交換や署名処理など、まだ実装 が容易ではない点が残る。 OAuth 2.0をベースに、ID連携のた めのプロトコルを定義。OAuth 2.0の 実装のしやすさを活かしつつ、ID連 携に十分な機能を定義している。 Google、PayPal、日本経済新聞社、 Yahoo! JAPANなどがすでに自社 サービスに適用。 アイデンティティ関連仕様の比較
10. Copyright 2013 OpenID Foundation Japan - All Rights Reserved. 「アイデンティティ・フェデレーション」から 「サービス・フェデレーション」へ 9 オーソリテイティブ・ ソース（人事 システムなど） プロビジョニング・ システム アイデンティティ・ リポジトリ / SSO / トークン管理システム SaaS プロバイダ SaaS プロバイダ Web サービス Web サービス ユーザー・ エージェント （Webブラウザ） ユーザー・ エージェント （モバイルApp） ユーザー・ エージェント （外部サービス） ユーザー・ エージェント （デスクトップApp） ユーザー・ エージェント （Webサービス） 企業 API API API API