IDaaSに関して考えてみる

たまには製品の実装の話以外も、ということでIDaaS（Identity as a Service）について考えてみます。

クラウドの潮流の中でXaaSというキーワードで「何でもサービス化」というのが流行って？いますが、アイデンティティをサービス提供する形態として「IDaaS」というのもしばしば耳にする様になってきました。

■IDaaSとは何か？

IDaaSとは平たく言うとアイデンティティプロバイダ機能のクラウドサービスなので、
・セキュリティトークンサービス（STS）
　認証機能
　セキュリティトークンの発行、変換機能
・アイデンティティストア
　アイデンティティ情報の保持
　ライフサイクル管理機能（セルフサービスポータル等）
といった機能が提供されることになります。

また、場合によっては他のクラウドサービスへのプロビジョニングを行ったりすることもあり得ると考えられます。

■IDaaSのメリット
IDaaSのメリットとして主に以下の事項が挙げられます。
サービスプロバイダにとって
・認証機能やアイデンティティ管理機を自前で開発しなくてよい
・アイデンティティ情報などのセンシティブな情報を自前で保持しなくてよい

利用者／利用企業にとって
・（サービスが対応していれば）複数のサービスで横断的に利用できる認証基盤となり、シングルサインオンが出来る
・複数のサービスと個別に信頼関係を結ぶ必要がなくなる（フェデレーション・ゲートウェイとしての利用）
・STSのトークン変換機能を使うことで自前（オンプレミス）のIdPを使うことができる（クラウド上にアイデンティティ情報をおく必要が必ずしもなくなる）

もちろん使い方や利用するサービスによってすべてのメリットを享受できるわけではありませんが、特にフェデレーション・ゲートウェイとしての機能はクラウド・オンプレミスのアイデンティティ連携を行う上では非常に有用な機能となりえると思われます。

■現在のプレイヤー
現在のプレイヤーとしては、GoogleやYahoo!、Windows LiveIDなどOpenIDプロバイダとしてサービスを提供しているものや、FacebookやTwitterなどOAuth対応という形で一部の認証や認可の機能をサービスプロバイダに提供しているものなどが挙げられます。
ただ、先述のクラウド・オンプレミス連携を行う上で重要となるフェデレーション・ゲートウェイ機能を提供しているサービスはまだ少なく、PingIdentityや対応するサービスが限定的ですがマイクロソフト（Microsoft Federation Gateway）くらいがメジャーどころだと思います。

■IDaaSを立ち上げるには？
これはIDaaSに限りませんがGoogleやAmazonの様に自前でサービスを提供するためにシステムを開発するプロバイダやマイクロソフトの様に元々製品を持っていたものをベースにサービスを提供するプロバイダと違って、OSS以外の既製品を組み合わせてサービス化していくのは採算的に中々厳しいと思われます。
（AmazonやGoogleの実装を元としてEucalyptusやHadoopが出てきていますが、あくまでリファレンス実装ですし、AmazonやGoogle自身が販売してるモノではありません。仮に彼らが自身のサービスに使っているツールを製品として販売したら相当な価格になるんじゃないかと思います）

例えばIDaaSを立ち上げるのに、市販のシングルサインオン系の製品を使ってしまうと、それらの殆どはユーザ数でライセンス課金なので、1ユーザあたり数千円～数万円の値付けをしないと採算が合わないでしょうが、ユーザが単なる認証機能にそれだけの金額を払うことはないでしょう。（Novell製品で米VerizonなどはIDaaSをやっているといいますから、それなりにベンダの値引きがあるんでしょうが・・・）

となると、自前でIdPを実装するかWSO2やOpenSSO/OpenAMなどのOSSをベースとして独自のサービスを実装するという覚悟が必要になるのかも知れません。

また、価格面以外にも認証や認可などセキュリティの根幹を担う機能を外部に委託する事になるので、ユーザからも提携するサービスプロバイダからも信頼される必要があります。ユーザに対してはOpenID CXやID-WSFの様に利用者自身の責任において属性の公開範囲等をコントロールする様な仕組みもありますし、この辺りになるともっと公的な機関との連携が必要になると思いますがKantara/LibertyのIdentity Assurance Framework(IAF)やGSA(米国調達庁)とICAMの例の様に第3者による認定制度の様な仕組みも必要になってくるでしょう。

IAFの認定アセスメントのイメージ

GSA/ICAM/OIXによる認定のイメージ


このように色々とハードルが高い世界ではありますが、出来れば日本でもPingIdentityの様にIDaaSプロバイダが出てくると面白いと思っています。

ADFS2.0の相互運用性 [7/26更新]

以前ADFS2.0がSAML2.0の相互運用性テストにパスした、という話題がありましたがSAMLに対応した他のSSO製品やサービスとの連携の情報が少しずつ出てきました。

◆他のフェデレーション／SSO製品との相互運用性

Sun OpenSSO

http://blogs.msdn.com/b/eugeniop/archive/2010/06/30/identity-federation-interoperability-wif-adfs-sun-s-opensso.aspx

IBM Tivoli Federated Identity Manager

http://blogs.msdn.com/b/eugeniop/archive/2010/06/30/identity-federation-interoperability-wif-adfs-ibm-tivoli-federated-identity-manager.aspx

CA SiteMinder

http://blogs.msdn.com/b/eugeniop/archive/2010/07/01/identity-federation-interoperability-wif-adfs-ca-siteminder.aspx?wa=wsignin1.0

7/26更新

Oracle Identity Federation

http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=46bd1cc0-cbe1-4426-875d-428b25b65f1a

また、SAMLに対応しているサービスとの連携については某所で記事を近々公開する予定なので、乞うご期待！

ちなみに、GoogleApps、Salesforce.com、Windows LiveID、Windows Azureとの連携のHow Toを公開予定です。

↓調査・実験の過程の各所の私の足跡（というか残骸）です。待ちきれない方はご参考までに(笑)

GoogleApps

http://www.google.com/support/forum/p/Google%20Apps/thread?tid=4752fe07313712ff&hl=en

Salesforce.com

http://social.msdn.microsoft.com/Forums/en-US/Geneva/thread/2fc66b27-966c-49e5-891e-6e7e404e001d

どうなる？Sun IdM ( 2010/1/30 追記 )

2010/1/30更新

SunのシニアソフトウェアアーキテクトのSébastien Stormacq氏のblogにまとまっているので少々修正です。（@tkudoさんに感謝）

そろそろ眠気がピークですが、なんとかIdM部分だけは、、と思って頑張ってます。

というわけで、日本時間1/28 2:00-7:00という極東に住んでいることを後悔するようなスケジュールで開催されている「Oracle + Sun Strategy Update」ですが、IdM部分について軽く紹介しておきます。
（眠いので間違っている可能性ありです。気づいたら直します）

結果から書きますが、基本的な方針としては「Oracle製品に統合」です。
















細かく分野ごとに見ていくとこんな感じです。

分野	方針	旧Sun製品	Oracle製品
Directory Services	Oracle Internet DirectoryとSun Directory Serverの両方をサポートする。OpenDSへの投資は継続する。	Sun Java System Directory Server	Oracle Internet Directory
Role Management	Sun Role ManagerはSuiteから切り出されてIdentity Analyticsへ	Sun Role Manager	Oracle Role Manager
Provisioning/Lifecycle Management	Oracle Identity Managerを戦略製品として継続させる。Sun Identity ManagerはSPMLアダプタとしてOracle Identity Managerへ統合される。Sun Identity ManagerはOracle Wavesetへリネーム。Sun Identity Managerからのマイグレーションツールを提供する予定。	Sun Identity Manager	Oracle Identity Manager
Access Management	Oracle Access Managerを戦略製品として継続させる。OpenSSOからのマイグレーションツールを提供する予定。OpenSSO STS機能を取り込みエンハンス。	OpenSSO	Oralce Access Manager
Virtual Directory	Oracle Virtual Directoryを戦略製品として継続させる	Sun Java System Directory Server EE	Oracle Virtual Directory
eSSO	Oracle Enterprise Single Sign-On Plusを戦略製品として継続させる	-	Oralce Enterprise Single Sign--On Plus
権限管理（Entitlement Management）	Oracle Entitlements Serverを戦略製品として継続させる	-	Oracle Entitlements Server
Identity Federation	Oracle Identity Federationを戦略製品として継続させ、OpenSSOのfedletを取り込む。OpenSSOからのマイグレーションツールを提供する予定。	OpenSSO	Oracle Identity Federation

※ちなみにSun Java System Directory Server Enterprise Editionに入っていたIdentity Synchronization for Windowsはどうなるんだろう？？LDAP-ADのお手軽同期ツールとしては良かったんですけどねぇ。

尚、サポートに関しては統合後も継続されるようですので、既存ユーザは保護されるようです。

とりあえずまた追加情報などあればアップデートしていきます。

ADFS2.0 ＆ WIF on AzureでオンプレミスとクラウドのSSO その3

意外とご好評を頂いた？このシリーズも今回で最終回です。

いよいよ今回は、
３．Azure上のアプリケーションを作成・発行する
４．シングルサインオンしてみる
をお送りします。


初回にも書きましたが、Azure上でもオンプレミスと同じコードが動きますが、環境面での違いを吸収するために少々設定が必要になります。

環境面での違いをまとめると、下記のようになります。

ポイント	Azure	オンプレミス
証明書のインストール方法	サービス毎に証明書をアップロード	IISへの設定
Webサイトへの証明書のバインド方法	プロジェクト側（WebRole）で使う証明書を指定	IISのサイトの設定
WIFコンポーネントの呼び出し方法	プロジェクトにWIFコンポーネントをパッケージングして一緒にデプロイ	アプリケーションサーバにインストールされているWIFコンポーネントへアクセス

では作業を始めます。
流れとしては、
・Azure上へサービスを作成する
・証明書を準備する
・Azure上へ証明書をアップロードする
・アプリケーションを作成する
・Azure上へデプロイ／実行する
・ADFS2.0にRelyingPartyを設定する
・Azure上のアプリケーションの動作を確認する
・オンプレミスアプリケーションとのSSO動作を確認する
となります。

少々ステップが多くなりますが、順番に見ていきます。

◆Azure上へサービスを作成する

　プロジェクトを開き、New ServiceからHostedサービスを作成します。
　注）ここで作成したサービス名を証明書にも使うので記録しておきます。
　　　今回は「pasvfed」という名前を使いました。







　サービスを追加し、Hosted Servicesを選択します。













　以下のパラメータでサービスを作成します。

項目	設定値	備考
Service Label	pasvfed
Public Service Name	http://pasvfed.cloudapp.net
Region	Anywhere US	何故かAnywhere AsiaだとDr. Watsonが出たので

◆証明書を準備する

　証明書を作成するのにネイティブ暗号化APIモジュール（CAPICOM）を使用します。
　もちろん上記リンクからダウンロードしても良いのですが、Identity Training Kitに入っているので今回はそちらを使いました。（CAPICOMそのものよりも後で出てくる証明書作成のバッチファイルが欲しかったので）
　※ちなみにCAPICOMは＜Identity Training Kitインストールフォルダ＞\Labs\WindowsAzureAndPassiveFederation\Source\Setup\Scripts以下にあるcapicom_dc_sdk.msiです。

　インストールが終わったら証明書の作成とインストールを行います。
　インストールは同じく＜Identity Training Kitインストールフォルダ＞\Labs\WindowsAzureAndPassiveFederation\Source\Assets以下にある、CreateCert.cmdを使います。

　まず、Visual Studioコマンドプロンプトを管理者で実行します。

　CreateCert.cmdのあるフォルダへ移動して、以下を実行します。

xxxx:\> CreateCert.cmd pasvfed

　このとき、引数に先程Azure上で作成したサービスの名称を渡します。

　実行すると、秘密キーのパスワードの作成、秘密キーのパスワード入力を求められるので「abc!123」を入力します。
　※CreateCert.cmdをそのまま使う場合、パスワードはabc!123である必要があります。
　　詳しくはバッチファイルの中を見るとわかります。























　その後、証明書インストール時にセキュリティの警告が出るのが「はい」をクリックします。

　コマンドが成功するとcertsフォルダの中に、
　・pasvfed.cloudapp.net.cer
　・pasvfed.cloudapp.net.pfx
　・pasvfed.cloudapp.net.pvk
　という3つのファイルが出来上がります。


◆Azure上へ証明書をアップロードする

　先程作成した証明書をAzure上へ予めアップロードしておきます。手順としてAzureのサービスのCertificatesからManageをクリックします。







　作成した証明書（pfxファイル）を選択肢、パスワードに先ほど指定した「abc!123」を指定し、uploadを行います。










　成功するとInstalled Certificatesにアップロードした証明書が表示されます。


◆アプリケーションを作成する

・プロジェクトの作成

　オンプレミス側で実行したのと同様にVSを管理者として起動し、新しいプロジェクトを以下の通り作成します。

項目	値	備考
プロジェクト名	pasvfed	Azure上のサービス名と合わせます
プロジェクトの種類	Visual C# → Cloud Service	もちろん言語は任意
テンプレート	Windows Azure Cloud Service
追加するロール	ASP.NET Web Role
ロール名	Web	もちろん任意

・SSLの設定

　次に、WebロールのSSL設定を行います。
　ソリューションエクスプローラからpasvfed→Roles→Webを右クリックしてプロパティウィンドウを表示します。

　Certificatesメニューを開き、「Add Certificate」をクリックし、以下の通り証明書を設定します。

項目	値	備考
Name	pasvfed
Store Location	Local Machine	デフォルト
Store Name	My	デフォルト
Thumbprint	右側のボタンをクリックして先ほど作成したpasvfedという名前の証明書を選択する

　次に追加した証明書を使うようにエンドポイントの設定を行います。Endpointsメニューを開き、以下の様に設定します。

項目		値	備考
HTTP		無効
HTTPS		有効
	Name	HttpsIn	デフォルト
	Port	443	デフォルト
	SSL certificate name	pasvfed	ドロップダウンリストから選択

・参照設定の追加

　Webロールのプロジェクトの参照設定にオンプレミスと同様にMicrosoft.IdentityModelを追加します。
　1点異なるのが、Microsoft.IdentityModelのプロパティに以下のパラメータを設定する必要がある点です。

　・ローカルコピー：True
　・特定バージョン：False

　これは、Azure上のアプリケーションからWIFコンポーネントへアクセスできないため、
、ローカルコピーを有効にして強制的にプロジェクトパッケージにコンポーネントを含めるために行う設定です。


・STSへの参照を設定

　これはオンプレミスと全く同じ手順です。
　Webロールを右クリックして出てくるAdd STS referenceからWizardを開き、以下の設定を行います。※オンプレミスと異なる点はApplication URIのみです。

ステップ	設定項目	設定値	備考
Welcome	Application configuration location	プロジェクトのweb.configファイル	初期状態で指定されているので変更不要
	Application URI	https://pasvfed.cloudapp.net	発行先となるURIを指定
Security Token Service	Security Token Service (STS) option	Use an existing STS	既に作成したADFS2.0をSTSとして指定
	STS WS-Federation metadata document location	https://adfs20.eidentity.local/FederationMetadata/2007-06/FederationMetadata.xml	ADFS2.0のMetadataのエンドポイントを指定
STS signing certificate chain validation error	Certificate validation option	Disable certificate chain validation	STSが自己署名入り証明書を使っているため、証明書チェーンの確認を無効化する
Security Token encryption	Security Token encryption option	No encryption

・Web.configの編集

　Add STS referenceでWeb.configは書き換わるのですが、Azure上にアップロードした証明書の参照に関する設定を一部手動で追加する必要があります。
　場所は、タグの内で、以下を追加します。

<servicecertificate> 　<certificatereference x509findtype="FindByThumbprint" findvalue="xxxxxx"> </servicecertificate>

※ThumbprintはWebロールに設定した証明書のものを使用


・Default.aspxのコーディング

　いよいよ実装ですが、コードはオンプレミスと全く同じものを使います。














　ここまででアプリケーションの実装は完了です。次はいよいよAzure上へのデプロイです。


◆Azure上へデプロイ／実行する

　ソリューションエクスプローラからpasvfedプロジェクトを右クリックして「発行」をクリックします。

　自動的にパッケージファイルが作成されたフォルダとブラウザが開き、Azureのサイトへ移動されます。

　プロジェクトからサービスを開き、Production環境のDeployボタンをクリックします。
　※今回は直接Production環境へデプロイします。これは、Azure上のアプリケーションはローカル、ステージング、プロダクションのそれぞれの環境でURIが変わるため、Passive Federationではアプリケーション→STS→アプリケーションとリダイレクションで遷移させる際に実行環境によって遷移先が変わってしまうためです。本当はHOSTヘッダをみて遷移先を変えるなどの工夫をするのですが、STSにADFS2.0を使う場合はそのあたりの作り込みが出来ない？ので、私は開発環境、ステージング環境もそれぞれRelying Partyとして登録しています。（ただの調査不足かも知れませんが）













　先ほど出来上がったパッケージファイルと構成ファイルをアップロードします。
　ラベルは適当な文字列でOKです。



























　デプロイが完了したらRunをクリックしアプリケーションを実行します。












　ステータスがInitializingになると、しばらく時間がかかるのでその間にSTSの設定をしておきましょう。












◆ADFS2.0にRelyingPartyを設定する

　これは前回オンプレミスで作成したのと同様の手順です。今回作成したアプリケーションのFederationMetadata.xmlを読み込ませると自動的にRelyingPartyのURIとしてpasvfed.cloudapp.netが設定されます。






◆Azure上のアプリケーションの動作を確認する

　そんなことをしているうちに、AzureのサービスのステータスがReadyになります














　準備が出来たら、ブラウザでhttps://pasvfed.cloudapp.net/へアクセスしてみます。
　オンプレミスと同じようにSTSへリダイレクトされ、ログインするとAzure上のアプリケーションが表示されます。

























◆オンプレミスアプリケーションとのSSO動作を確認する

　最後に、本当にオンプレミスとシングルサインオンになっているかを試してみます。

　最初にオンプレミスへアクセスします。
　するとSTSへリダイレクトされ、オンプレミスアプリケーションが表示されます。














　そのまま、オンプレミス上の「Azureアプリケーション」というハイパーリンクをクリックします。すると今度はSTSへのログオンすることなく、Azure上のアプリケーションが表示されます。











　ということで、今回作成した環境で本当に基礎的なクレームベースのWebアプリケーションではありますが、オンプレミスとクラウドのアプリケーションのシングルサインオンが実現出来ました。

　他にも色々とやりたい事が尽きないのですが、是非今度はOpenSSOとADFS2.0のフェデレーション環境下でオンプレミスはOpenSSO、AzureはWIF/ADFSという環境でのシングルサインオンとかにも手を出したいところです。

第4回Liberty Alliance技術セミナー

先週3/6（金）に開催された第4回Liberty Alliance技術セミナーの資料が公開されています。
http://wiki.projectliberty.org/index.php/JapanSIG/Seminars/TechSeminar

残念ながら参加はできなかったので、早速資料をチェックしてみました。

・SAML2.0の仕様詳細とデモ実演

　SAMLって何？というところから、ProfileやBinding、Assertion、Protocolの定義内容などがわかりやすく解説されています。
　日本語の資料であまりわかりやすい資料がないので、貴重です。

・SAML2.0とOpenIDの相互運用デモ

　SAML、OpenID、CardSpaceの相互運用の取り組み、Concordia Projectの紹介などのオーバービューから具体的なデモシナリオ、デモ実演という流れです。デモが見たかったです・・・。


最近この手の相互運用のネタが結構流行っていますが、まだSAMLやOpenIDなどのキーワードが浸透しきっていないせいか、「相互運用」の意味が理解しづらいものとなっているのでは？と感じています。
Libertyなどで話題に上っている「相互運用」はあくまで利用者の視点でSAML対応のIdPで認証されたユーザがシームレスにOpenID対応のRPのサービスを利用できる、ということを指しています。（SUICAとICOCAの相互運用とイメージ的には近いかも知れません）

ただ、それぞれのキーワードの定義をものすごく乱暴に解説すると、
・SAML：認証の仕組みではなく、認証情報の連携や属性交換の仕組み。認証状態（認証されたIdP情報）や属性をXMLベースのAssertionで受け渡す
・OpenID：認証の仕組みではなく、認証情報の連携や属性交換の仕組み。IdP（OP）のURI自体がIDとなっている
・CardSpace：InfoCardというメタファを利用して認証プロバイダをユーザ自身に選択させる仕組み
となります。
こうやってみると、SAMLとOpenIDやCardSpaceを同列に並べてしまうことにちょっと違和感を感じてしまいます。

全体的に言葉遊びになってしまいがちですが、うまくマッチする日本語がないのが最大の原因なのかも知れませんね。

Liberty Alliance Day 2008 @ Tokyo

今日（といっても深夜をまわってしまったので、昨日）、ベルサーレ九段で開催された「Liberty Alliance Day 2008」に参加してきました。

テーマは「Trust and Harmony for the Emerging Identity Ecosystem」ということで、アイデンティティ管理に関連する信頼性確保やプライバシー保護に関する話がメインでした。
基調講演ではOracleのRoger Sullivan氏がLiberty Allianceが注力するポイントの一つとしてIAF（Identity Assurance Framework」の話をしたり、相互運用性に関するパネルではLiberty、OpenID、CardSpaceについて、セキュリティ、プライバシー保護という観点での取り組みを紹介したりと盛りだくさんでした。

ポイントはそれぞれこんな感じ。
・信頼性確保
　Liberty AllianceではIAF、OpenIDではReputation、PAPEのようにIdP/OPの信頼性を保証するための枠組みの策定に注力している（実際に商用利用するにはまだまだ、といったところですが）
・プライバシー保護
　SPへ提供する属性情報をユーザに選択/確認させる、という仕組みが実装されてきつつある。Geneva CardSpaceのデモもあり、InfoCardの中のどんな属性が実際にSPに提供されるかをユーザがあらかじめ確認する様子がみれました。

後は、こういうイベント恒例の新技術、プロジェクトの発表。
今回は、
・OpenSSO 8.0 Enterprise Edition ： 11/14リリース
・Genevaの（おそらく）国内初の発表（LibertyだけにSAML2.0サポート※がポイント）
　※どこまでサポートするかは未定とのことですが。
でした。

まぁ400人くらいの参加があったようなので、それなりに盛況だったんではないでしょうか？