Quantcast
Channel: IdM実験室
Viewing all 771 articles
Browse latest View live

[AAD/Office365]AAD Sync Betaを試す

$
0
0
しばらく時間が経ってしまいましたが、5月末に現在のディレクトリ同期ツール(DirSync)の後継となるAzure Active Directory Sync(AADSync)のベータ版がConnectサイトに公開されました。

 ダウンロードサイト(要登録)
 https://connect.microsoft.com/site433/Downloads/DownloadDetails.aspx?DownloadID=53361

 関連ポスト:
 [AAD/Office365]AAD Sync(次世代ディレクトリ同期)でクラウドのパスワードをオンプレミスへ
 http://idmlab.eidentity.jp/2014/04/aadoffice365aad-dync.html


基本は現在のディレクトリ同期と同様にForefront Identity Manager 2010 R2(FIM)ベースですが、より簡単に同期ルールを設定できるようなツールも付属しています。
これでディレクトリ同期ツールの手軽さとFIMの柔軟さの両方の良いところを活かすことが出来るようになります。
また同時にかねてからの課題であったマルチフォレスト環境への対応や.localドメインなどの課題へも対応できるようになっています。

今回は簡単にインストール~同期をした結果を載せてみます。


まず、注意事項ですが日本語環境ではBeta版のインストールは出来ませんので、英語環境にしてください。(OSインストールは日本語でも構いませんが、言語の追加で英語を追加し、表示言語を英語にした状態でインストールする必要があります)

ちなみに、当然のことながら事前にAzure AD上にディレクトリ同期を有効にしておく必要があります。

では始めます。

■インストール
モジュールをダウンロードして実行するとモジュールの展開・インストールが行われて自動的に設定が開始されます。

まずはAADへの接続情報の入力です。ここで入力するユーザはテナントの全体管理者の権限を持っている必要があります。


続いてオンプレミスのADDSの情報です。注目すべきはAdd Forestボタンです。
ここで複数のフォレストの情報を登録することでマルチフォレスト環境でもディレクトリ同期が出来ます。


設定したフォレスト情報が表示されているのがわかります。


次に2つの設定を行います。

一つ目はAcount Joinです。
これは複数のフォレストを同期する場合にアカウントを一意に識別してあげる必要があるのですが、その際に使用する属性を選択します。今回はシングルフォレスト構成なので、「My users are only represented once across all forests」を選択します。

二つ目はIdentity federationです。
AzureADとフェデレーションを行う場合にどの属性を使ってアカウントを紐づけるか?という設定です。AzureAD側ではImmutableIdという属性を使います。
これまでのディレクトリ同期ではobjectSidをBase64エンコードした値を使っていましたので、ShibbolethなどAD FS以外のSAML2.0 Identity Providerと接続する際は結構面倒だったのですが、今回からAAD側と紐づけをするための属性を自分で選択できるようになりました。

今回はUserPrincipalNameを選んでいます。


これまで通りHybrid環境のExchangeがある場合の設定もできます。


ここまで来たらもうすぐです。

完了です。その場で同期するならチェックしたままでFinishをクリックします。

とりあえず初期同期が走ります。

何の設定もしていないので、AADSyncを実行するユーザが同期されています。

ついでにグループも同期されています。これもゴミグループですね。。。



■同期ルール設定
これまではサポート外になるのを承知でmiisclientを使って同期ルールを編集することはできましたが、今回からは公式に同期ルールを編集するための簡易ツールがついてきます。

Synchronization Rule Editorが追加される。Synchronization Serviceは従来のmiisclient。


インバウンドとアウトバウンドの同期ルールが一覧で表示されるので、必要なモノを選択してEditをクリックすると編集できます。

ちなみにアウトバウンドはこんな感じ。AADへ連絡先、グループ、ユーザを同期するための設定が並んでいます。


試しにアウトバウンドのルールの編集をしてみます。

同期スコープも編集できます。これで特定のグループのユーザだけ同期する、なんていうことも簡単にできます。

このあたりがAADとオンプレミスのアカウントの紐づけです。どの属性で紐づけるかを選択できるので、例えばオンプレミスが.localドメインだった場合でもメールアドレスなどの属性を使って紐づけることが出来るようになります。

属性の接続など変わったことも出来ます。


ちなみに従来のmiisclientもSynchronization Serviceを開くと使えます。

ちなみにバージョン情報を見てもFIMの面影は消し去られています。。。


先日のOffice365の新機能発表でAzure AD Premiumの有償オプションだった多要素認証についてもMFA for Office365という形でサブスクライバへ無償提供されることが発表されていますし、このようにFIMを使わなくてもかなり柔軟にディレクトリ同期が出来るようになってきている、ますます簡単で便利な環境が提供されてきているので今後の展開が非常に楽しみです。


[告知]登壇予定(Office365、AAD、Identity)

$
0
0
最近はblogの更新もままならないほど忙しい日々なんですが、そんな中2本ほどイベントでお話をさせていただきます。いずれもAzure AD/Office365関係のアイデンティティ管理・フェデレーションの話の予定です。


■6/21(土)@大阪
SQL Worldさん
http://sqlworld.org/event/20140621/

タイムテーブルはこんな感じです。
時間内容スピーカー
13:05 -開場 
13:15 -ご挨拶 
20分 程度O365 概要(仮)SQLWorld 遥佐保
50分 程度O365 SharePointSQLWorld リシュ ジミー
20分 程度PowerBI + O365 の紹介SQLWorld お だ
10分 程度おやつタイム 
50分 程度運用を見据えた失敗しないOffice365導入(仮)Office365 MVP 渡辺元気 さん
50分 程度Office365とアイデンティティ(仮)FIM MVP 富士榮尚寛 さん


Office365、というかAADの話(ID管理、ID連携)をGraphAPIとかフェデレーションの仕組みの話とかをさせていただく予定です。


■6/28(土)@東京
.NETラボさん
http://www.dotnetlab.net/dnn/2014/05/net%E3%83%A9%E3%83%9C-%E5%8B%89%E5%BC%B7%E4%BC%9A-2014%E5%B9%B46%E6%9C%88-2/


こちらのタイムテーブルはこんな感じ。
■タイムテーブル
13:00 開場
13:15-13:30 「.NETラボ紹介」(.NETラボ スタッフ)
13:30-14:00「認証系を勉強する1日を企画したわけ」(Microsoft MVP for Client App Dev 高尾 哲朗)
14:00 – 17:00 「Office365の認証回りの仕様の移り変わりと運用上の苦労話」(Microsoft MVP for Office365 渡辺 元気)
「ADFS+Office365によるセキュリティ強化 デバイス認証、多要素認証編」(Microsoft MVP for Directory Services 国井 傑)
「AADとIdentity管理」(Microsoft MVP for Forefront Identity Manager 富士榮 尚寛)
Microsoft エバンジェリスト 安納さん(調整中)
17:00-17:30 「ライトニングトーク&ディスカッションタイム」
17:30 「グリーティングアワー」
18:00 終了


まぁ、似たような話をします。
ちょっと開発寄りな話になるかも知れません。


資料が全然できていないので、頑張って作ろうと思いますので、お時間のある方は是非・・・

エンタープライズロール管理解説書(第2版) がJNSAアイデンティティ管理WGよりリリース

$
0
0
エンタープライズロール管理解説書の第1版がリリースされてから約1年、改版されたロール管理解説書がリリースされました。

エンタープライズロール管理解説書(第2版)
 http://www.jnsa.org/result/2014/idm_guideline/index.html


JNSAのアイデンティティ管理WGでも「パンドラの箱」と言われ続けてきたロール管理ですが、前回、今回と議論が深まり、企業内でより活用しやすい形にまとまっていると思います。

以下、目次です。

  • ロール管理の定義
  • ロール管理の意義
  • ロール管理導入の流れ
  • ロール管理導入における課題
    • 現状調査・企画フェーズ
    • ロール設計フェーズ
    • 実装方式設計フェーズ
    • 実装・移行・展開フェーズ
  • ロール管理の適正な運用の重要性
    • ロール管理運用の観点
    • トリガイベント分類ごとのロール管理運用のガイドライン
  • 金融業の仮想企業におけるロール管理導入事例


ロールとは何なのか?ビジネスロールとITロールの分け方や関連など概念的な話から実際にロール管理を実装する各フェーズにおいて考えるべき事項、運用面での注意点、そして最後に仮想企業における導入イメージなどこれからロール管理を検討しようとしている企業にとって非常に有用な内容になっていると思いますので、是非ダウンロードして読んでみてください。





Azure ADのSAML対応(IdP編)

$
0
0
Azure Active DirectoryのIdentity Providerとしての機能について、先日の.NETラボ勉強会で話をしましたが、そういえば説明してなかったなぁ、、と思うのがSAMLの対応状況です。

当日の勉強会資料はこちら
 


実は、現状ではAzure ADをSAML IdPとして使う際はIdP起動(IdP Initiated)のユースケースしか対応していません。

つまり、例えばGoogle AppsのようなサービスとのID連携が出来るようになったと言っても、これまで@ITなどで紹介してきた様に、
①サービス(SP)へアクセス
②AzureAD(IdP)へリダイレクト
③認証後、サービスへ戻って利用開始
という流れではサービス利用が出来ない、ということです。

参考)クラウド・サービスと社内システムとのID連携
  第4回 Google AppsとのID基盤連携を実現する
  http://www.atmarkit.co.jp/ait/articles/1301/16/news122.html



実際にGoogle AppsをAzure ADで認証するように構成して、https://mail.google.com/a/<テナントドメイン>へアクセスすると以下のようなエラーが発生します。


Azure ADのアプリケーションアクセス権限はもちろん割り当てているのですが、何とも分かりにくいエラーが出ます。




通信をトレースしてみると、以下のような流れになっています。


①サービスへアクセス
 GET https://mail.google.com/a/<テナントドメイン>/ HTTP/1.1
 ⇒HTTP 302
  Azure ADへリダイレクト

②Azure ADへの認証要求
 GET https://login.windows.net/25461215-0c1f-4dc2-bffc-63e6e6f3f759/saml2?SAMLRequest=xxx&RelayState: https://www.google.com/a/<テナントドメイン>/ServiceLogin?service=mail&passive=true&rm=false&continue=https%3A%2F%2Fmail.google.com%2Fa%2F<テナントドメイン>%2F&ss=1&ltmpl=default&ltmplcache=2&emr=1 HTTP/1.1

 実際のSAML Requestは以下の通り
<samlp:AuthnRequest xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
ID="eafkldjajjdlncljdmnihogjokolljjfdooaboee"
Version="2.0"
IssueInstant="2014-07-31T14:34:01Z"
ProtocolBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"
ProviderName="google.com"
IsPassive="false"
AssertionConsumerServiceURL="https://www.google.com/a/domain/acs"
>
<saml:Issuer xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">google.com</saml:Issuer>
<samlp:NameIDPolicy AllowCreate="true"
Format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified"
/>
</samlp:AuthnRequest>


 ⇒HTTP 302
  Azure ADの認証サービスへリダイレクト(ws-federationでID連携)

③login.microsoftonline.comへ認証要求
 GET https://login.microsoftonline.com/login.srf?wa=wsignin1.0&wreply=https%3a%2f%2flogin.windows.net%2f<テナントID>%2fwsfedisvacs&wp=MBI_FED_SSL&wctx=xxx HTTP/1.1

 ⇒ログイン画面表示

④ID/パスワードでログイン
 POST https://login.microsoftonline.com/ppsecure/post.srf?wa=wsignin1.0&wreply=https%3a%2f%2flogin.windows.net%2f<テナントID>%2fwsfedisvacs&wp=MBI_FED_SSL&wctx=xxx HTTP/1.1

⑤SAMLトークンを受け取り、Azure ADへPOST(ws-federationプロトコル)
 POST https://login.windows.net/<テナントID>/wsfedisvacs HTTP/1.1

 ⇒HTTP 400 Bad Request
  エラー!!先ほどの画面が表示される。



なかなか一筋縄ではいきません。
現状の解としてはアプリケーション・パネル(https://myapps.microsoft.com)からアプリケーションを立ち上げてIdP-InitiatedでID連携をすることとなります。

アプリケーション・パネル




ここからアプリケーション(Google Apps)を選択すると同じくSAMLを使ったID連携が行われて、サービスへログインできます。



このパターンの連携の流れは以下の通りです。

①アプリケーション・アイコンをクリック
 GET https://account.activedirectory.windowsazure.com/applications/redirecttofederatedapplication.aspx?Operation=SignIn&applicationId=<アプリケーションID>&ApplicationConstName=googleapps&SingleSignOnType=Federated&ApplicationDisplayName=Google+Apps HTTP/1.1

②SAML認証要求を発行
 GET https://login.windows.net/<テナントID>/saml2?SAMLRequest=xxxx&RelayState=https%3a%2f%2fwww.google.com%2fa%2facs%2fServiceLogin%3fservice%3dmail%26passive%3dtrue%26rm%3dfalse%26continue%3dhttps%253A%252F%252Fmail.google.com%252Fa%252Facs%252F%26ss%3d1%26ltmpl%3ddefault%26ltmplcache%3d2 HTTP/1.1

 この時のSAMLリクエストは以下の通り
<samlp:AuthnRequest xmlns="urn:oasis:names:tc:SAML:2.0:metadata"
ID="ide478f3cb10e54fd2882a3c68d24cd34a"
Version="2.0"
IssueInstant="2014-07-31T15:07:18.210Z"
IsPassive="false"
AssertionConsumerServiceURL="https://www.google.com/a/domain/acs"
xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
>
<Issuer xmlns="urn:oasis:names:tc:SAML:2.0:assertion">http://google.com</Issuer>
<samlp:NameIDPolicy Format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress" />
</samlp:AuthnRequest>


③login.microsoftonline.comへ認証要求(シングルサインオン)
 GET https://login.microsoftonline.com/login.srf?wa=wsignin1.0&wreply=https%3a%2f%2flogin.windows.net%2f<テナントID>>%2fwsfedisvacs&wp=MBI_FED_SSL&wctx=xxx HTTP/1.1


④SAMLトークンをAzure ADへPOST(ws-federationプロトコル)
 POST https://login.windows.net/<テナントID>/wsfedisvacs HTTP/1.1


⑤SAMLトークンを発行し、Google AppsのACS(SP)へPOST
 POST https://www.google.com/a/<ドメイン>/acs HTTP/1.1

 POSTするSAML Responseは以下の通り
<samlp:Response ID="_cfa4d9a3-07f2-43b3-8721-ec009a314a42"
Version="2.0"
IssueInstant="2014-07-31T15:20:21.298Z"
Destination="https://www.google.com/a/domain/acs"
InResponseTo="ide478f3cb10e54fd2882a3c68d24cd34a"
xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
>
<Issuer xmlns="urn:oasis:names:tc:SAML:2.0:assertion">https://sts.windows.net/tenant/</Issuer>
<ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
<ds:SignedInfo>
<ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" />
<ds:SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256" />
<ds:Reference URI="#_cfa4d9a3-07f2-43b3-8721-ec009a314a42">
<ds:Transforms>
<ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature" />
<ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" />
</ds:Transforms>
<ds:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256" />
<ds:DigestValue>vldBy5BDCPN1SosH0pbBECXLspqjexOKf/CzGfvwhhA=</ds:DigestValue>
</ds:Reference>
</ds:SignedInfo>
<ds:SignatureValue>SlEnVqcu--snip--cPDdkxuJMmg==</ds:SignatureValue>
<KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#">
<ds:X509Data>
<ds:X509Certificate>MIIDPjC--snip--Lg4rOBcXWLAIarZ</ds:X509Certificate>
</ds:X509Data>
</KeyInfo>
</ds:Signature>
<samlp:Status>
<samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success" />
</samlp:Status>
<Assertion ID="_28c961d7-b93e-4c21-88d9-62977d2ce849"
IssueInstant="2014-07-31T15:20:21.298Z"
Version="2.0"
xmlns="urn:oasis:names:tc:SAML:2.0:assertion"
>
<Issuer>https://sts.windows.net/tenant/</Issuer>
<ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
<ds:SignedInfo>
<ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" />
<ds:SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256" />
<ds:Reference URI="#_28c961d7-b93e-4c21-88d9-62977d2ce849">
<ds:Transforms>
<ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature" />
<ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" />
</ds:Transforms>
<ds:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256" />
<ds:DigestValue>swSVM5OvOHWnGp105KYZbMer4xuiJ0O9knGGBP4g/Us=</ds:DigestValue>
</ds:Reference>
</ds:SignedInfo>
<ds:SignatureValue>V2Sbe7Ww--snip--okg==</ds:SignatureValue>
<KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#">
<ds:X509Data>
<ds:X509Certificate>MIID--snip--arZ</ds:X509Certificate>
</ds:X509Data>
</KeyInfo>
</ds:Signature>
<Subject>
<NameID>ieyasut@domain</NameID>
<SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">
<SubjectConfirmationData InResponseTo="ide478f3cb10e54fd2882a3c68d24cd34a"
NotOnOrAfter="2014-07-31T15:25:21.298Z"
Recipient="https://www.google.com/a/domain/acs"
/>
</SubjectConfirmation>
</Subject>
<Conditions NotBefore="2014-07-31T15:20:21.005Z"
NotOnOrAfter="2014-07-31T16:30:21.005Z"
>
<AudienceRestriction>
<Audience>http://google.com</Audience>
</AudienceRestriction>
</Conditions>
<AttributeStatement>
<Attribute Name="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname">
<AttributeValue>ieyasu</AttributeValue>
</Attribute>
<Attribute Name="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname">
<AttributeValue>tokugawa</AttributeValue>
</Attribute>
<Attribute Name="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name">
<AttributeValue>ieyasut@domain</AttributeValue>
</Attribute>
<Attribute Name="http://schemas.microsoft.com/identity/claims/tenantid">
<AttributeValue>tenant</AttributeValue>
</Attribute>
<Attribute Name="http://schemas.microsoft.com/identity/claims/objectidentifier">
<AttributeValue>4ce14587-d409-420e-82a2-7957867c6d20</AttributeValue>
</Attribute>
<Attribute Name="http://schemas.microsoft.com/identity/claims/identityprovider">
<AttributeValue>https://sts.windows.net/tenant/</AttributeValue>
</Attribute>
</AttributeStatement>
<AuthnStatement AuthnInstant="2014-07-31T15:15:13.000Z"
SessionIndex="_28c961d7-b93e-4c21-88d9-62977d2ce849"
>
<AuthnContext>
<AuthnContextClassRef>urn:oasis:names:tc:SAML:2.0:ac:classes:Password</AuthnContextClassRef>
</AuthnContext>
</AuthnStatement>
</Assertion>
</samlp:Response>



⑥Google Appsへのログイン処理(シングルサインオン)
 GET https://www.google.com/accounts/ContinueSignIn?sarp=1&continue=https%3A%2F%2Fmail.google.com%2Fa%2Facs%2F&plt=xxx&scc=0&service=mail HTTP/1.1

 ⇒Gmail画面の表示



いかがでしょうか?
単純にSAMLプロトコルに対応した、と言ってもどこまで対応しているかを知っておかないと利用イメージが違う、、という話になりかねないので、しっかりと押さえておかないといけませんね。

続Azure ADのSAML対応(IdP編)~SP Initiatedに対応

$
0
0
前回のPOSTで現状Azure Active DirectoryのSAML IdP対応はIdP Initiatedだけ、という話をしましたが、直近(9/3)のアップデートでSP Initiatedに対応しました。

 TechnetのActive Directory Teamのブログ
 - 50+ SaaS Apps and growing now support federation with Azure AD!
  http://blogs.technet.com/b/ad/archive/2014/09/03/50-saas-apps-now-support-federation-with-azure-ad.aspx

ブログ本文の本筋はたくさんのSaaSアプリケーションがAzure ADとのフェデレーションに対応したよ、ということなんですが下の方にちょろっとSP Initiated対応!と書いてあります。
これでようやくアプリケーションポータルを経由しなくてもSaaSアプリを使うことが出来ます。

と、言うことで試してみます。
と言っても設定はこれまでと何ら変わりません。今回もGoogle Appsを使います。

①Azure ADの管理コンソールからGoogle Appsを追加し、構成を行います。

 まずはGoogle Appsのドメインを指定します。

 Google Appsに設定する情報が出てくるので、証明書のダウンロードします。


②Google Appsのセキュリティ設定からシングルサインオン設定を行います。
 先ほどダウンロードした証明書のアップロード、各種URLの設定を行います。
 この時、「ドメイン固有の発行元を使用」にチェックを入れておくことを忘れないようにしてください。(前回はこれを入れていなかったからダメだっただけかも知れません。。)

③Azure ADのコンソールでGoogle Appsを使うユーザを追加、選択します。
 ※アプリケーションの構成でプロビジョニングを有効にしておく必要があります。
 Google Appsと同じドメインをAzure ADにも追加し、対象のドメインにユーザを作り、割り当てを行います。


④Google AppsへアクセスするとAzure ADのサインイン画面へリダイレクトされるので、先ほど追加したユーザでサインインします。


すると、無事にGoogle Apps(今回はGmail)が利用できます。




同じようなやり方でカスタムアプリや他のサービスも使えると思いますので、エンタープライズにおける利活用の選択肢がだいぶ拡がったと思います。


ID&IT Management Conference 2014が開催されます

$
0
0
本日と明後日、東京と大阪それぞれで今年もID & IT Management Conferenceが開催されます。

 http://nosurrender.jp/idit2014/




昨年はJNSAのアイデンティティ管理WGとしてID管理システム導入時の要求定義のポイントについてパネルディスカッションを担当させてもらいましたが、今年は標準化が熱い!ということでグローバルスタンダードについてのパネルに出演させていただきます。

特に昨年~今年はOAuth2.0のRFC化やOpenID Connectの正式リリースなどアイデンティティに関する標準化に伴い、Microsoft Azure ADやSalesforce.com Identity、Ping IdentityのPing Oneなどの主要なIDaaS(Identity as a Service)ベンダが相次いで標準をサポートした年でした。
ただ、実際の導入の現場では標準かどうか?よりも各社に固有の事情に対応することの方が当然優先されるわけで、中々標準に目が行くことはありません。ということでSIer目線でID管理プロジェクトの現場ではどんなことを考えているか?という話をしようと思います。



 ※ちなみに昨年度の話はこちら


当日になってしまいましたが、お手隙の人は是非いらしてください。

私も午後から大阪へ向かいます...orz )某所のホテルの部屋にて。。

[AD FS] Windows Server Technical PreviewのAD FSを試す

$
0
0
世の中 Windows 10 という流れですが、いつもの通り Server OS がどうなるかの方が気になってしまうので早速確認してみました。
こういう時、Azure VM は便利ですね。一瞬で試せる環境が手に入ります。

Windows Server Technical Preview のデスクトップ
Server Version は Windows Server 2012 R2 のままです。


ちゃんとスタートメニューも復活しています。



外観は良いとして、確認してみたのは AD FS がどう変わったのか?です。

結論は「そんなに変わっていないけど、便利な機能がついてるっぽい」という感じなので、早速見ていきます。


■インストール
ここははっきり言って何も変わっていません。
見慣れた画面です。



■構成ウィザード
ここも全く変わりません。


■管理コンソール
ちょっと変わってます。

◇メニュー
移動したメニュー、見慣れないメニューがあります。
 ・Device Registration がメニューとして独立、Service の中に入っています。
 ・Policy Templates メニューが追加されています。


◇バージョン
6.4.0.0になってます。
※Windows Server 2012 R2 では 6.3.0.0 でした。


■管理コンソールで変わった部分の詳細

変わった部分をちょっと詳しく確認します。

◇DRS ( Device Registration Service )
 DRS を有効にするには Device 情報を Active Directory 上に登録出来るように PowerShell より「Enable-AdfsDeviceRegistration -PrepareActiveDirectory」 としてスキーマ拡張をする必要がありましたが、今回からウィザードで構成出来るようになっています。

ちなみにウィザードを使うにはちゃんとした(AD DSのドメインサフィックスとAD FSが使う証明書のCNのサフィックスが同じ)サーバ証明書を入れる必要があるので、今回は試せてません。
(適当な証明書で AD FS を構成したので...orz)

◇Policy Templates
 完全に新しい機能っぽいので、まだ使い方がよく分かっていませんが、クレームの要求ルールを作成するのを補助してくれるツールっぽいです。

こんな感じのルールエディタがついています。
(例えばメールアドレスがあれば、、みたいなルールが書けそうです)



テンプレートを作成すると一覧に In use by RP とあるので、適用する RP がどこかで選択できるような気がするんですが、現状該当する設定箇所を見つけられていません。。。
見つけたら更新します。。



■SAML 2.0 IdP として使ってみる
軽く Google Apps とつないでみます。
当然ですが何も変わりません。







まだまだ Technical Preview の段階なので何とも、、ですが、ポリシーの部分が楽になりそうなので、今後が楽しみです。

[AADSync]パスワード同期機能が追加

$
0
0
正式版がリリースされてから時間が経っているにも関わらず全くblogで紹介することなくスルーしてしまっていたAzure Active Directory Synchronization Services(AADSync)ですが、10月の終わりに新ビルドがリリースされています。


ダウンロードサイト(1.0.0470.1023)
 http://www.microsoft.com/en-us/download/details.aspx?id=44225

GA版からの変化点は以下の2点です。

  1. 構成ウィザードがローカライズされた
  2. パスワード同期(オンプレミスAD⇒AzureAD)がサポートされた


1点目のローカライズですが、こんな感じで進化してきています。
 ベータ版:英語環境にしかインストールできない
 GA版:日本語環境にもインストールが出来る(表示は英語)
 新バージョン:構成ウィザードがローカライズされた


ただ、Synchronization Rules EditorやSynchronization Service Managerは相変わらず英語表記です。




次にパスワード同期ですが、ディレクトリ同期ツールでは提供されていた機能がAAD Syncにも実装されてきました。
基本的な仕様や使い方はディレクトリ同期ツールとほぼ同じです。(PowerShellのコマンドレット名が違うくらい)

構成ウィザードの中のオプション機能を選択する画面でパスワード同期にチェックを入れればパスワード(のハッシュ)がオンプレミスのADからAzure ADへ同期されるようになります。


尚、パスワード同期機能を使うためにはAAD Syncに指定したオンプレミスADとの接続に使うユーザに対して以下の権限を付与する必要があります。(Administratorユーザを指定した場合は不要です)
<追加で必要な権限>

  • ディレクトリの変更のレプリケート
  • ディレクトリの変更をすべてにレプリケート


追加方法はActive Directoryユーザとコンピュータより「制御の委任」で行います。

ドメインのルートを右クリックし、[制御の委任]をクリックします。


[委任するカスタムタスクを作成する]を選択します。


[このフォルダー、このフォルダー内の既存のオブジェクト、およびこのフォルダー内の新しいオブジェクトの作成]を選択しウィザードを進めます。


アクセス許可の選択しより「ディレクトリの変更のレプリケート」と「ディレクトリの変更をすべてにレプリケート」にチェックを入れます。




最後に確認してウィザードの構成を終わり、AAD Syncのサービスを再起動します。


うまく同期されればイベントビューアに以下のようなログが記録されます。
(失敗した場合はペンディングリストに入りリトライされます)



※その他注意点
・IPv6が有効な環境でパスワード同期を行う場合は、Azure ADとの接続にIPv6が優先されるため、途中のルータなどでIPv6が通らない場合は同期に失敗する
 (単純なアカウント同期だけだとIPv6⇒IPv4にフォールバックしてくれているのか、問題は発生しません)
 ※Office365 MVPの@genkiwさんの以前の記事の状況と同じだと思われます。
  http://blog.o365mvp.com/2013/03/19/waad_connecting_issue/
・既に構成済みのAAD Syncに後からパスワード同期を有効化する場合、Synchronization Service ManagerからオンプレミスADとAzure ADの各Management AgentのFull Import -> Full Synchronizationを実行する必要があるようです。いずれにしても構成ウィザードを起動する際にWindowsタスクでAAD Syncの同期タスクを無効化する必要があるので、構成ウィザードが完了した後は、手動でFull Import -> Full Synchronizationを実行してから同期タスクを有効化した方が安全です。




ディレクトリ同期やForefront Identity Manager(FIM)+Azure AD Connectorと比較して機能面でも充実していますし、同期設定のカスタマイズも容易になっているので今後はAzure AD / Office365を使う場合はAAD Sync一択になりそうです。

Office2013 Windowsクライアントが多要素認証とSAML IdPサポート

$
0
0
ずいぶん前から「そのうち」と言われていて中々実現しなかったOfficeのネイティブアプリでの多要素認証(MFA)と外部SAML IdPでの認証サポートが今月後半に実現することが発表されました。

Officeの公式blog




※blogより転載

なるほど、ADAL(Active Directory Authentication Library)をOfficeクライアントの認証コードに噛ませてAzure ADや外部IdPとつなげる、という構成なわけです。

これでAzure ADからOAuthのアクセストークンを取得してOffice365のサービスへOfficeクライアントがアクセスするわけですね。


blogによると、以下のことが出来るようになるようです。

1.多要素認証

 いわゆるPhoneFactorとかの追加要素を使った認証ですね。

2.SAML対応の外部IdPでの認証

 現在もMicrosofot Online Sign-In Assistantを使ってAzure ADを使って認証をすることはできましたが、中身はws-trustを使っていたので、実質Azure AD一択でした。しかし、今回ADALを使うことでSAML2.0に対応するので、OpenAMなどと直接接続をすることが出来るようになります。

3.SmartCard認証

 多要素認証の一環でもありますが、AD FSを展開していてSmartCardで認証できるようにしている環境下において、ID/パスワードを入力する代わりにSmartCardのみで認証できるようになります。

4.OutlookでのBASIC認証が不要に

 これまでOutlookとOffice365(Exchange Online)の間はBASIC認証でしたので、ID/パスワードをOutlookからExchangeへ渡して、Exchange Onlineがws-trustでAzure ADやAD FSで認証される、という構成でしたが、ADALをサポートすることでOutlookから直接IdPへ接続し認証後、Exchange Onlineへ接続、という流れに変わります。
 ※おそらく、これでAD FS+Office365+Outlook環境でAD FS Proxyが必要なくなります。


Microsoft Updateで更新プログラムが落ちてくるみたいなので、月末が楽しみです。
また、待ちきれない人に向けてPreview Programもやっているみたいなので、興味がある方は参加してみてはいかがでしょうか?



[AADSync]PowerShellコマンドレット一覧

$
0
0
ディレクトリ同期ツール(DirSync)でもPowerShellモジュールが用意されていましたが、当然Azure Active Directory Synchronization Services(AADSync)にも用意されています。

個々の詳しい内容は機会があれば紹介したいと思いますが、とりあえずモジュール名と使えるコマンドレット名の一覧を書いておきます。

◆モジュール名
Get-Module -ListAvailableを実行すると「ADSync」という名前であることがわかります。
(ディレクトリ同期ツールでは「DirSync」でした)

Directory: C:\Program Files\Microsoft Azure AD Sync\Bin

ModuleType Version    Name    ExportedCommands
---------- -------    ----    ----------------
Binary     1.0.0.0    ADSync  {Get-ADSyncConnector, New-ADSyncConnector, Add-ADSyncConne...


◆コマンドレット一覧
先ほどのADSyncをVerboseモードでインポートすると一覧が取得できます。

PS C:\Users\Administrator> Import-Module ADSync -Verbose
VERBOSE: Loading module from path 'C:\Program Files\Microsoft Azure AD Sync\Bin\ADSync\ADSync.psd1'.
VERBOSE: Loading 'Assembly' from path 'C:\Program Files\Microsoft Azure AD
Sync\Bin\Microsoft.CredentialManagement.OnPremisesPasswordReset.Shared.dll'.
VERBOSE: Loading 'Assembly' from path 'C:\Program Files\Microsoft Azure AD
Sync\Bin\Microsoft.MetadirectoryServices.AADPasswordReset.Types.dll'.
VERBOSE: Loading 'Assembly' from path 'C:\Program Files\Microsoft Azure AD
Sync\Bin\Microsoft.CredentialManagement.OnPremisesPasswordReset.Library.dll'.
VERBOSE: Loading 'Assembly' from path 'C:\Program Files\Microsoft Azure AD Sync\Bin\Microsoft.ServiceBus.dll'.
VERBOSE: Loading 'Assembly' from path 'C:\Program Files\Microsoft Azure AD Sync\Bin\Newtonsoft.Json.dll'.
VERBOSE: Loading module from path 'C:\Program Files\Microsoft Azure AD
Sync\Bin\ADSync\Microsoft.IdentityManagement.PowerShell.Cmdlet.dll'.
VERBOSE: Exporting cmdlet 'Get-ADSyncConnector'.
VERBOSE: Exporting cmdlet 'New-ADSyncConnector'.
VERBOSE: Exporting cmdlet 'Add-ADSyncConnector'.
VERBOSE: Exporting cmdlet 'Remove-ADSyncConnector'.
VERBOSE: Exporting cmdlet 'Add-ADSyncConnectorAnchorConstructionSettings'.
VERBOSE: Exporting cmdlet 'Remove-ADSyncConnectorAnchorConstructionSettings'.
VERBOSE: Exporting cmdlet 'Add-ADSyncConnectorHierarchyProvisioningMapping'.
VERBOSE: Exporting cmdlet 'Get-ADSyncConnectorHierarchyProvisioningDNComponent'.
VERBOSE: Exporting cmdlet 'Get-ADSyncConnectorHierarchyProvisioningMapping'.
VERBOSE: Exporting cmdlet 'Get-ADSyncConnectorHierarchyProvisioningObjectClass'.
VERBOSE: Exporting cmdlet 'Remove-ADSyncConnectorHierarchyProvisioningMapping'.
VERBOSE: Exporting cmdlet 'Add-ADSyncConnectorAttributeInclusion'.
VERBOSE: Exporting cmdlet 'Add-ADSyncConnectorObjectInclusion'.
VERBOSE: Exporting cmdlet 'Remove-ADSyncConnectorAttributeInclusion'.
VERBOSE: Exporting cmdlet 'Remove-ADSyncConnectorObjectInclusion'.
VERBOSE: Exporting cmdlet 'Disable-ADSyncConnectorPartition'.
VERBOSE: Exporting cmdlet 'Disable-ADSyncConnectorPartitionHierarchy'.
VERBOSE: Exporting cmdlet 'Enable-ADSyncConnectorPartition'.
VERBOSE: Exporting cmdlet 'Enable-ADSyncConnectorPartitionHierarchy'.
VERBOSE: Exporting cmdlet 'Get-ADSyncConnectorPartition'.
VERBOSE: Exporting cmdlet 'Get-ADSyncConnectorPartitionHierarchy'.
VERBOSE: Exporting cmdlet 'Update-ADSyncConnectorPartition'.
VERBOSE: Exporting cmdlet 'Add-ADSyncRunStep'.
VERBOSE: Exporting cmdlet 'Get-ADSyncRunProfile'.
VERBOSE: Exporting cmdlet 'New-ADSyncRunProfile'.
VERBOSE: Exporting cmdlet 'Add-ADSyncRunProfile'.
VERBOSE: Exporting cmdlet 'Remove-ADSyncRunProfile'.
VERBOSE: Exporting cmdlet 'Remove-ADSyncRunStep'.
VERBOSE: Exporting cmdlet 'Get-ADSyncConnectorTypes'.
VERBOSE: Exporting cmdlet 'Get-ADSyncGlobalSettings'.
VERBOSE: Exporting cmdlet 'Set-ADSyncGlobalSettings'.
VERBOSE: Exporting cmdlet 'Add-ADSyncGlobalSettingsParameter'.
VERBOSE: Exporting cmdlet 'Get-ADSyncGlobalSettingsParameter'.
VERBOSE: Exporting cmdlet 'Remove-ADSyncGlobalSettingsParameter'.
VERBOSE: Exporting cmdlet 'Get-ADSyncConnectorParameter'.
VERBOSE: Exporting cmdlet 'Set-ADSyncConnectorParameter'.
VERBOSE: Exporting cmdlet 'Get-ADSyncAADPasswordResetConfiguration'.
VERBOSE: Exporting cmdlet 'Get-ADSyncAADPasswordSyncConfiguration'.
VERBOSE: Exporting cmdlet 'Remove-ADSyncAADPasswordResetConfiguration'.
VERBOSE: Exporting cmdlet 'Remove-ADSyncAADPasswordSyncConfiguration'.
VERBOSE: Exporting cmdlet 'Set-ADSyncAADPasswordResetConfiguration'.
VERBOSE: Exporting cmdlet 'Set-ADSyncAADPasswordSyncConfiguration'.
VERBOSE: Exporting cmdlet 'Set-MIISADMAConfiguration'.
VERBOSE: Exporting cmdlet 'Get-ADSyncSchema'.
VERBOSE: Exporting cmdlet 'Set-ADSyncSchema'.
VERBOSE: Exporting cmdlet 'Update-ADSyncConnectorSchema'.
VERBOSE: Exporting cmdlet 'Set-ADSyncAADPasswordSyncState'.
VERBOSE: Exporting cmdlet 'Set-ADSyncServerConfiguration'.
VERBOSE: Exporting cmdlet 'Get-ADSyncServerConfiguration'.
VERBOSE: Exporting cmdlet 'Get-ADSyncRule'.
VERBOSE: Exporting cmdlet 'New-ADSyncRule'.
VERBOSE: Exporting cmdlet 'Add-ADSyncRule'.
VERBOSE: Exporting cmdlet 'Remove-ADSyncRule'.
VERBOSE: Exporting cmdlet 'Add-ADSyncAttributeFlowMapping'.
VERBOSE: Exporting cmdlet 'Remove-ADSyncAttributeFlowMapping'.
VERBOSE: Exporting cmdlet 'Add-ADSyncJoinConditionGroup'.
VERBOSE: Exporting cmdlet 'Remove-ADSyncJoinConditionGroup'.
VERBOSE: Exporting cmdlet 'New-ADSyncJoinCondition'.
VERBOSE: Exporting cmdlet 'Add-ADSyncScopeConditionGroup'.
VERBOSE: Exporting cmdlet 'Remove-ADSyncScopeConditionGroup'.
VERBOSE: Exporting cmdlet 'New-ADSyncScopeCondition'.
VERBOSE: Importing cmdlet 'Add-ADSyncAttributeFlowMapping'.
VERBOSE: Importing cmdlet 'Add-ADSyncConnector'.
VERBOSE: Importing cmdlet 'Add-ADSyncConnectorAnchorConstructionSettings'.
VERBOSE: Importing cmdlet 'Add-ADSyncConnectorAttributeInclusion'.
VERBOSE: Importing cmdlet 'Add-ADSyncConnectorHierarchyProvisioningMapping'.
VERBOSE: Importing cmdlet 'Add-ADSyncConnectorObjectInclusion'.
VERBOSE: Importing cmdlet 'Add-ADSyncGlobalSettingsParameter'.
VERBOSE: Importing cmdlet 'Add-ADSyncJoinConditionGroup'.
VERBOSE: Importing cmdlet 'Add-ADSyncRule'.
VERBOSE: Importing cmdlet 'Add-ADSyncRunProfile'.
VERBOSE: Importing cmdlet 'Add-ADSyncRunStep'.
VERBOSE: Importing cmdlet 'Add-ADSyncScopeConditionGroup'.
VERBOSE: Importing cmdlet 'Disable-ADSyncConnectorPartition'.
VERBOSE: Importing cmdlet 'Disable-ADSyncConnectorPartitionHierarchy'.
VERBOSE: Importing cmdlet 'Enable-ADSyncConnectorPartition'.
VERBOSE: Importing cmdlet 'Enable-ADSyncConnectorPartitionHierarchy'.
VERBOSE: Importing cmdlet 'Get-ADSyncAADPasswordResetConfiguration'.
VERBOSE: Importing cmdlet 'Get-ADSyncAADPasswordSyncConfiguration'.
VERBOSE: Importing cmdlet 'Get-ADSyncConnector'.
VERBOSE: Importing cmdlet 'Get-ADSyncConnectorHierarchyProvisioningDNComponent'.
VERBOSE: Importing cmdlet 'Get-ADSyncConnectorHierarchyProvisioningMapping'.
VERBOSE: Importing cmdlet 'Get-ADSyncConnectorHierarchyProvisioningObjectClass'.
VERBOSE: Importing cmdlet 'Get-ADSyncConnectorParameter'.
VERBOSE: Importing cmdlet 'Get-ADSyncConnectorPartition'.
VERBOSE: Importing cmdlet 'Get-ADSyncConnectorPartitionHierarchy'.
VERBOSE: Importing cmdlet 'Get-ADSyncConnectorTypes'.
VERBOSE: Importing cmdlet 'Get-ADSyncGlobalSettings'.
VERBOSE: Importing cmdlet 'Get-ADSyncGlobalSettingsParameter'.
VERBOSE: Importing cmdlet 'Get-ADSyncRule'.
VERBOSE: Importing cmdlet 'Get-ADSyncRunProfile'.
VERBOSE: Importing cmdlet 'Get-ADSyncSchema'.
VERBOSE: Importing cmdlet 'Get-ADSyncServerConfiguration'.
VERBOSE: Importing cmdlet 'New-ADSyncConnector'.
VERBOSE: Importing cmdlet 'New-ADSyncJoinCondition'.
VERBOSE: Importing cmdlet 'New-ADSyncRule'.
VERBOSE: Importing cmdlet 'New-ADSyncRunProfile'.
VERBOSE: Importing cmdlet 'New-ADSyncScopeCondition'.
VERBOSE: Importing cmdlet 'Remove-ADSyncAADPasswordResetConfiguration'.
VERBOSE: Importing cmdlet 'Remove-ADSyncAADPasswordSyncConfiguration'.
VERBOSE: Importing cmdlet 'Remove-ADSyncAttributeFlowMapping'.
VERBOSE: Importing cmdlet 'Remove-ADSyncConnector'.
VERBOSE: Importing cmdlet 'Remove-ADSyncConnectorAnchorConstructionSettings'.
VERBOSE: Importing cmdlet 'Remove-ADSyncConnectorAttributeInclusion'.
VERBOSE: Importing cmdlet 'Remove-ADSyncConnectorHierarchyProvisioningMapping'.
VERBOSE: Importing cmdlet 'Remove-ADSyncConnectorObjectInclusion'.
VERBOSE: Importing cmdlet 'Remove-ADSyncGlobalSettingsParameter'.
VERBOSE: Importing cmdlet 'Remove-ADSyncJoinConditionGroup'.
VERBOSE: Importing cmdlet 'Remove-ADSyncRule'.
VERBOSE: Importing cmdlet 'Remove-ADSyncRunProfile'.
VERBOSE: Importing cmdlet 'Remove-ADSyncRunStep'.
VERBOSE: Importing cmdlet 'Remove-ADSyncScopeConditionGroup'.
VERBOSE: Importing cmdlet 'Set-ADSyncAADPasswordResetConfiguration'.
VERBOSE: Importing cmdlet 'Set-ADSyncAADPasswordSyncConfiguration'.
VERBOSE: Importing cmdlet 'Set-ADSyncAADPasswordSyncState'.
VERBOSE: Importing cmdlet 'Set-ADSyncConnectorParameter'.
VERBOSE: Importing cmdlet 'Set-ADSyncGlobalSettings'.
VERBOSE: Importing cmdlet 'Set-ADSyncSchema'.
VERBOSE: Importing cmdlet 'Set-ADSyncServerConfiguration'.
VERBOSE: Importing cmdlet 'Set-MIISADMAConfiguration'.
VERBOSE: Importing cmdlet 'Update-ADSyncConnectorPartition'.
VERBOSE: Importing cmdlet 'Update-ADSyncConnectorSchema'.


基本はGUIツール(構成ウィザード、ルールエディタ、同期マネージャ)で出来ることはPowerShellで出来そうですね。

[告知]CLR/H AD+IDスペシャルディ

$
0
0
今月末の11月29日(土)にCLR/Hさんのイベント「AD+IDスペシャルディ〜ハンズオンもあるよ!?」が品川の日本マイクロソフト本社で開催されます。

申し込みURL
 http://clrh.connpass.com/event/9464/

今回はセッションのトラックとハンズオントラックで 2部屋に分かれて開催され、私は「プロトコルから見るID連携」と題してws-federation/SAML/OpenID Connectの解説をAzure ADと外部IdP(AD FS/OpenAMの予定)やアプリケーション(Office365/GoogleApps/OWIN OpenID Connect Middlewareを使って実装したカスタムアプリ)の実際の動きをトレースしながら解説しようと思います。

以下がセッションスケジュールです。クラウドとのID連携の話やAzure IaaS上でのActive Directory設計の話、AD FSのクレームルールの解説など濃いセッションが予定されているので、ご興味のある方はどうぞ。

セッションスピーカー時間
開場-12:30-13:00
クラウド時代におけるID基盤MSいたくらさん13:00-13:50
AD設計の基礎から読み解くIaaS AD阿部さん14:00-14:50
LT & おやつタイム-15:00-16:00
ADFSクレームルール言語Deep Dive国井さん16:00-16:50
プロトコルから見るID連携富士榮17:00-17:50

[Office365/AzureAD]OpenAMとのID連携①

$
0
0
先日告知させて頂いた通り、今月末にCLR/HさんのイベントでID連携のプロトコル周りの話をします。

イベントのために、手元にこんな環境を用意してみました。

プロビジョニング)
 ・AADSyncを使い、オンプレミスのAD DS上のアカウントをAzureAD/OpenDJ/GoogleAppsへID情報を同期します。
 ・AzureADからGoogleAppsへプロビジョニングを行います。
フェデレーション)
 ・AzureADをIdPとしてOffice365/GoogleApps/カスタムアプリといったSPへそれぞれws-federation/SAML2.0/OpenID Connectを使ってフェデレーションします。
 ・AzureADをSPとしてオンプレミスにAD FSを使ったIdPを構築し、ws-federationで接続します。また、先ほどのOffice365等のAzureADのSPの認証をAzureADを経由してAD FSで認証、というマルチプロトコルのフェデレーションのチェインを行います。
 ・並行してOpenAMをIdPとしてOffice365/GoogleAppsをSPとしてSAML2.0でフェデレーションします。


実際の動きはイベントでお見せするとして、構築方法など細かい話を少しずつ書いていこうと思います。

最初は図の右下部分のOffice365とOpenAMのID連携(SSO)について書いていきます。




完成するとこんな感じで動きます。

1. Office365のポータル(http://portal.office.com/)へアクセスするとログイン画面が表示されます。


2. OpenAMと連携するように構成したドメインのユーザのメールアドレスを入力するとOpenAMへリダイレクトされます。



この時、Office365からOpenAMに向けてSAML2.0の認証リクエストが発行されます。

ポイントはNameID Policyがpersistentとなっているあたりです。IdP(OpenAM)はSP(Office365)向けに永続(固定)のNameIDを渡してあげる必要がある、ということです。実際はOffice365のユーザDBとなるAzure Active Directory(AzureAD)に作成するユーザのImmutableIdという属性の値と一致した値をNameIDには指定します。OpenAM(のユーザDBであるOpenDJ)とAzureADでユーザを同期しておく必要があるので、Forefront Identity Manager(FIM)などのID管理ソリューションを使ってユーザを作成します。(今回はAAD Syncを改造しています。当然非サポートです)このあたりは次回以降で別途解説します。
<samlp:AuthnRequest xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
ID="_996b8521-70a0-49b1-809c-c98aba209315"
IssueInstant="2014-11-17T14:20:32Z"
Version="2.0"
AssertionConsumerServiceIndex="0"
>
<saml:Issuer>urn:federation:MicrosoftOnline</saml:Issuer>
<samlp:NameIDPolicy Format="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent" />
</samlp:AuthnRequest>



3. OpenAMへログインします。


認証されるとOpenAMは2で生成されたSAML認証要求に対応する応答メッセージ(SAML Assertion)を生成、ブラウザを経由してOffice365へHTTP/POSTします。
<samlp:Response xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
ID="s20964a4b3df745e7880a0f3415b3215d3f5b2946c"
InResponseTo="_996b8521-70a0-49b1-809c-c98aba209315"
Version="2.0"
IssueInstant="2014-11-17T14:20:51Z"
Destination="https://login.microsoftonline.com/login.srf"
>
<saml:Issuer xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">http://openam.example.net:8080/OpenAM-11.0.0</saml:Issuer>
<samlp:Status xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol">
<samlp:StatusCode xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
Value="urn:oasis:names:tc:SAML:2.0:status:Success"
/>
</samlp:Status>
<saml:Assertion xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
ID="s250501aa5c251e616bc9cba9076bfc828a65b086d"
IssueInstant="2014-11-17T14:20:51Z"
Version="2.0"
>
<saml:Issuer>http://openam.example.net:8080/OpenAM-11.0.0</saml:Issuer>
<ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
<ds:SignedInfo>
<ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" />
<ds:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1" />
<ds:Reference URI="#s250501aa5c251e616bc9cba9076bfc828a65b086d">
<ds:Transforms>
<ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature" />
<ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" />
</ds:Transforms>
<ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1" />
<ds:DigestValue>9WyD3at9dL87t4dley8SYe/pxLk=</ds:DigestValue>
</ds:Reference>
</ds:SignedInfo>
<ds:SignatureValue>
Yz43rxDLhDYs1QK0xj29qqVC19ND248iqa9fbgpg6WbJbDqh5Piq0Hyff8YgGnUmOY6vkJG4AMkR
....snip....
t7hjVQqcVvERxydS6xk=
</ds:SignatureValue>
<ds:KeyInfo>
<ds:X509Data>
<ds:X509Certificate>
MIICQDCCAakCBEeNB0swDQYJKoZIhvcNAQEEBQAwZzELMAkGA1UEBhMCVVMxEzARBgNVBAgTCkNh
....snip....
cGy/F2Zuj8XJJpuQRSE6PtQqBuDEHjjmOQJ0rV/r8mO1ZCtHRhpZ5zYRjhRC9eCbjx9VrFax0JDC
/FfwWigmrW0Y0Q==
</ds:X509Certificate>
</ds:X509Data>
</ds:KeyInfo>
</ds:Signature>
<saml:Subject>
<saml:NameID Format="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent"
NameQualifier="http://openam.example.net:8080/OpenAM-11.0.0"
SPNameQualifier="urn:federation:MicrosoftOnline"
SPProvidedID="kenshinu"
>kenshinu</saml:NameID>
<saml:SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">
<saml:SubjectConfirmationData InResponseTo="_996b8521-70a0-49b1-809c-c98aba209315"
NotOnOrAfter="2014-11-17T14:30:51Z"
Recipient="https://login.microsoftonline.com/login.srf"
/>
</saml:SubjectConfirmation>
</saml:Subject>
<saml:Conditions NotBefore="2014-11-17T14:10:51Z"
NotOnOrAfter="2014-11-17T14:30:51Z"
>
<saml:AudienceRestriction>
<saml:Audience>urn:federation:MicrosoftOnline</saml:Audience>
</saml:AudienceRestriction>
</saml:Conditions>
<saml:AuthnStatement AuthnInstant="2014-11-17T14:20:51Z"
SessionIndex="s20d7f191b8306bb263961ed4056b918f749a60501"
>
<saml:AuthnContext>
<saml:AuthnContextClassRef>urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport</saml:AuthnContextClassRef>
</saml:AuthnContext>
</saml:AuthnStatement>
<saml:AttributeStatement>
<saml:Attribute Name="IDPEmail">
<saml:AttributeValue xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:type="xs:string"
>kenshinu@o365.hoge.net</saml:AttributeValue>
</saml:Attribute>
</saml:AttributeStatement>
</saml:Assertion>
</samlp:Response>



4. Office365へログインします。


うまくいけばシングルサインオンされます。



今回はここまでです。

次回から、以下の流れで順に解説する予定なのでお楽しみに!

第2回)Office365/OpenAMのID連携設定
 カスタムドメインの作成~SSO設定、OpenAMのIdP/SP/CoT(Circle of Trust)定義を行います。

第3回)ユーザのプロビジョニング設定
 AADSyncを使ってAzureAD/OpenDJへオンプレミスAD上のユーザを同期します。

[AADSync]フルパスワード同期を強制的に実行する

$
0
0
先日Azure Active Directory Synchronization Services(AADSync)にもパスワード同期機能が実装された、という話を書きました。
 http://idmlab.eidentity.jp/2014/11/aadsync.html

しかし、ディレクトリ同期ツール(DirSync)にあって、AADSyncにない機能があり、その一つがパスワードの強制同期機能です。

DirSyncではフォーラムのFAQに書かれているように'Set-FullPasswordSync'コマンドレットを実行してサービスを再起動すればパスワードの強制同期が出来ました。

 フォーラムURL:
  http://social.technet.microsoft.com/wiki/contents/articles/18096.dirsync-password-sync-frequently-asked-questions.aspx

 パスワードの強制同期方法(PowerShell)

Import-Module DirSync
Set-FullPasswordSync
Restart-Service FIMSynchronizationService



一方でAADSyncには先にポストしたPowerShellコマンドレット一覧を見ても'Set-FullPasswordSync'が見当たりません。

MSDNフォーラムで色々と情報を探していたんところ、MirosoftのMarkus VilcinskasがTechnet Wikiに書いてくれました。かなり強引な方法ですので、いずれちゃんとしたコマンドレットが用意される気がしますが。

 Technet Wiki - How to Use PowerShell to Trigger a Full Password Sync in Azure AD Sync
  http://social.technet.microsoft.com/wiki/contents/articles/28433.how-to-use-powershell-to-trigger-a-full-password-sync-in-azure-ad-sync.aspx


$adConnector = "mydomain.local"
$aadConnector = "mytenant.onmicrosoft.com - AAD"

Import-Module ADSync
$c = Get-ADSyncConnector -Name $adConnector
$p = New-Object Microsoft.IdentityManagement.PowerShell.ObjectModel.ConfigurationParameter "MicrosoftSynchronize.ForceFullPasswordSync", String, ConnectorGlobal, $null, $null, $null
$p.Value = 1
$c.GlobalParameters.Remove($p.Name)
$c.GlobalParameters.Add($p)
$c = Add-ADSyncConnector -Connector $c

Set-ADSyncAADPasswordSyncConfiguration -SourceConnector $adConnector -TargetConnector $aadConnector -Enable $false
Set-ADSyncAADPasswordSyncConfiguration -SourceConnector $adConnector -TargetConnector $aadConnector -Enable $true



ちなみに各コネクタの名称はSynchronization Service Managerで確認できます。(TypeがActive Directory Domain ServicesとなっているものがオンプレミスADコネクタ、Windows Azure Active Directory (Microsoft)となっているの*.onmicrosoft.com -ADという名前のものがAzureADコネクタです)
さっそく実行してみると、イベントログにパスワード同期が実行されたことが記録されます。


基本的に2分に一回パスワードは同期されますし、ネットワーク障害などで更新が出来なかったときはリトライがされるので大きな問題になることは少ないとは思いますが、メンテナンス時など強制的に全同期をしておきたい時もあると思いますので、そのような際はこのコマンドを使えば良いですね。


[MIM]Microsoft Identity Manager 2015 CTP1が公開されました

$
0
0
既に各所で情報が出ていますが、Forefront Identity Manager(FIM)の次期バージョンであるMicrosoft Identity Manager 2015(MIM2015)のCTP1が正式に公開されました。

Active Directory Team Blog:Microsoft Identity Manager Public Preview is now available!


新機能は既にTechEd Europeなどでも解説されている通り、以下の通りです。
※各種画像は公式blogより転載

◆特権アカウント管理(Privileged Access Management/PAM)

 Active Directory上のアカウントに限定ではありますが、ユーザに対して期間限定で特権を割り当てることが可能になります。
 具体的にはKerberosのチケットのTTLをコントロールしたグループへの参加をさせる形となります。


◆Azure Active Directory(AzureAD)の多要素認証(MFA)を使ったセルフサービスパスワードリセット(SSPR)
 これまでカスタムでSSPRの認証ゲートを組み込んでいましたが、製品としてAzureのMFAに対応したPhone Gateが実装されてきました。
 パスワードを忘れた場合などのリセットをする際の認証に、これまでの秘密の質問だけでなくPhone Factorが使えるようになったので、管理者の負荷を下げることが出来るかもしれません。


◆ストアアプリでのCertificate Manager(CM)の提供
 Certificate Manager(CM)でのスマートカード発行がこれまでのWebベースからストアアプリでも出来るようになりました。タブレット端末で使うときなどは重宝するかも知れません。


◆最新プラットフォームのサポート

 ようやく、以下のプラットフォームに対応しました。
  • Windows Server 2012 R2
  • SharePoint 2013
  • SQL Server 2014
  • Exchange 2013
  • Visual Studio 2013


connectサイトからダウンロードできるので、早々に試してみようと思います。

ダウンロードサイト:




[Office365/AzureAD]OpenAMとのID連携②

$
0
0
前回のポストの続きです。
今回は予告した通りID連携を、カスタムドメインの作成~SSO設定、OpenAMのIdP/SP/CoT(Circle of Trust)定義の順に実際に設定していきます。

◆OpenAM/IdP(Identity Provider)設定

今回の構成はOpenAM上のユーザでOffice365へログオンしたいので、OpenAMをIdentity Provider(IdP)として設定する必要があります。

尚、実際にはOffice365とOpenAMの間にAzureADが挟まっており、Office365/portal.office.com⇒(ws-federation)⇒AzureAD/login.microsoftonline.com⇒(SAML2.0)⇒OpenAMという流れになります。

前回も掲載した図を厳密に書くと以下のようになります。


早速設定を始めます。
OpenAMのインストールを終了し、管理コンソールの[共通タスク]より[ホストアイデンティティープロバイダの作成]をクリックし、IdP定義を作成します。


ここでの設定項目は署名に使う鍵とトラストサークルの2点だけです。
以下を設定します。
・署名鍵:test(実験なので。実際はちゃんとした証明書を使ってください)
・トラストサークル:新しいトラストサークルに追加、トラストサークル名「例)MSO365」



◆OpenAM/RP(Relying Party)設定

次はOffice365をOpenAMにRPとして設定します。
Office365はSAML2.0のメタデータを公開しているので、それをベースにRP設定をします。

まずは以下のURLにアクセスし、メタデータをダウンロードします。
https://nexus.microsoftonline-p.com/federationmetadata/saml20/federationmetadata.xml
※私はいつもIEで上記URLを開き、ファイルメニューの名前を付けて保存よりXMLファイルを保存しています。

早速ダウンロードしたメタデータをOpenAMにインポートと行きたいのですが、インポート前にXMLファイル内の最初のが余分なので削除しておきます。

以下を削除します。


メタデータの用意が出来たら、OpenAMの管理コンソールの[共通タスク]より[リモートサービスプロバイダを登録]をクリックし、先ほどのメタデータをベースにRP設定を行います。
以下を設定します。
・メタデータ:ファイル⇒先ほどのメタデータファイル(federationmetadata.xml)
・トラストサークル:先ほどIdP作成時に作ったCoT(MSO365)
・属性マッピング:表明内の名前⇒IDPEmail、ローカル属性名⇒mail



これでOpenAM側の設定は完了なので、OpenAMのIdP設定(IdPメタデータ)を出力しておきます。
以下のURLよりメタデータが取得できます。
http://:8080/OpenAM-11.0.0/saml2/jsp/exportmetadata.jsp?realm=/&entityid=http://:8080/OpenAM-11.0.0
※realmやポートなどは環境によって異なります。


次はこのIdPメタデータを使ってOffice365/AzureAD側の設定を行います。


◆Office365/AzureADのカスタムドメインの認証設定を行う

ここではOffice365で使うカスタムドメインの認証をOpenAMとのFederationで行う様に設定を行います。
※ドメインの追加はOffice365の管理ポータルからでもAzureの管理ポータルからでも構いません。
※カスタムドメインを追加する手順は省略します。

具体的には、PowerShellの「Set-MsolDomainAuthentication」コマンドレットに以下のパラメータを付けて設定をします。
※当然ですがコマンドレット実行前に「Connect-MsolService」でAzureADへ接続しておいてください。

パラメータ設定する値設定例
DomainNameカスタムドメイン名example.com
FederationBrandNameブランド名(任意の値)eIdentity
AuthenticationFederated固定Federated
PassiveLogOnUriIdPメタデータ内のタグ内のLocation属性の値
※Binding属性の値が「urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST」のもの
http://openam.example.com:8080/OpenAM-11.0.0/SSOPOST/metaAlias/idp
SigningCertificateIdPメタデータ内のタグの中身MIICQDCCAakCBEeNB0swDQYJ….
IssuerUriIdPメタデータ内のタグ内のentityID属性の値http://openam.example.com:8080/OpenAM-11.0.0
ActiveLogOnUriIdPメタデータ内のタグ内のLocation属性の値
※Binding属性の値が「urn:oasis:names:tc:SAML:2.0:bindings:SOAP」のもの
※httpsでないと設定できないのでhttpsで設定(ブラウザを使ったアクセスではこの設定は使わないので、ダミーのURLでもよいのでとにかくhttpsのURLを設定すればOK)
https://openam.example.com:8080/OpenAM-11.0.0/SSOSoap/metaAlias/idp
LogOffUriIdPメタデータ内のタグ内のLocation属性の値
※Binding属性の値が「urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect」のもの
http://openam.example.com:8080/OpenAM-11.0.0/IDPSloRedirect/metaAlias/idp
PreferredAuthenticationProtocol利用するID連携プロトコル(SAMLP)SAMLP


実際のコマンドは以下のように実行します。
$dom = "example.com"
$url = "http://openam.example.com:8080/OpenAM-11.0.0/SSOPOST/metaAlias/idp"
$cert = "MIICQDCCAakCBEeNB0swDQYJKoZIhvcNAQEEBQAwZzELMAkGA1UEBhMCVVMxEzARBgNVBAgTCkNhbGlmb3JuaWExFDASBgNVBAcTC1NhbnRhIENsYXJhMQwwCgYDVQQKEwNTdW4xEDAOBgNVBAsTB09wZW5TU08xDTALBgNVBAMTBHRlc3QwHhcNMDgwMTE1MTkxOTM5WhcNMTgwMTEyMTkxOTM5WjBnMQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZvcm5pYTEUMBIGA1UEBxMLU2FudGEgQ2xhcmExDDAKBgNVB.............Fcfu2/PeYoAdiDAcGy/F2Zuj8XJJpuQRSE6PtQqBuDEHjjmOQJ0rV/r8mO1ZCtHRhpZ5zYRjhRC9eCbjx9VrFax0JDC/FfwWigmrW0Y0Q=="
$entity = "http://openam.example.com:8080/OpenAM-11.0.0"
$ecp="https://openam.example.com:8080/OpenAM-11.0.0/SSOSoap/metaAlias/idp"
$logout = "http://openam.example.com:8080/OpenAM-11.0.0/IDPSloRedirect/metaAlias/idp"

Set-MsolDomainAuthentication -DomainName $dom -FederationBrandName eIdentity -Authentication Federated -PassiveLogOnUri $url -SigningCertificate $cert -IssuerUri $entity -ActiveLogOnUri $ecp -LogOffUri $logout -PreferredAuthenticationProtocol SAMLP



ちなみに設定結果は「Get-MsolDomainFederationSettings」コマンドレットで確認できます。




今回はここまでです。
次回はAzureAD上のユーザとOpenAM上のユーザの紐づけを行うためのプロビジョニング時の工夫について解説します。(単純に初期状態のディレクトリ同期だとImmutableIdでの紐づけがうまく行かないのでカスタマイズが一部必要になります)




[AD FS]プライバシーに考慮したID連携設定

$
0
0
2か月連続でお世話になりましたCLR/HさんのイベントCLR/H Tokyo vol.7で「ID連携における仮名」の話をしてきました。
(数日前まで登壇の事実を忘れていたので事前準備・告知など全くできず・・・)

当日の資料はこちら



当日行ったデモの内容を含め、少し補足しておきたいと思います。

◆仮名(カメイ)とは
仮名(カメイ/pseudonym)とは、プライバシーに考慮しつつID連携を行いたい、というユースケースに対応した仕組みです。
例えば、企業グループ内で共有しているサービスにおいては、あらかじめ信頼したIdentity Provider(IdP)で認証された、という事実だけがあれば本来個人を特定する情報(氏名やメールアドレス)は不要なはずです。(アプリケーションの動作上、もしくは運用上必要になるケースはありますが)
しかし、実際のID連携のシナリオでは「なんとなく」様々な属性が連携されており、ID連携をしている複数のサービス間でユーザ情報の名寄せが出来てしまったりするケースが散見されます。
エンタープライズシナリオにおいては問題になることはあまりありませんが、複数のService Provider(SP)が存在し、かつ運営主体が別個であるコンシューマシナリオやセンシティブな情報を扱うシナリオ(例えば医療情報などを扱うSPを含むシナリオ)ではユーザ情報の名寄せは問題となることがあります。

そんな時、サービス毎にユニークな名前(ハンドルネームのようなイメージ)をIdPが自動的に発行することで名寄せを防ぎます。このユニークな名前のことを「仮名」と呼びます。
また、仮名には、
・永続的な仮名
・一時的な仮名
があります。

永続的な仮名は同じSPに対しては何度ログインし直しても毎回同じ仮名が発行されますので、SP側でデータを持つ場合でも継続してサービスを使うことが出来ます。
一方で一時的な仮名はSPに対してログインする度に異なる仮名が発行されるので、同じサービス内でのID情報(前回のログイン時に行った振る舞いなど)を紐づけられる心配はありません。


◆ID連携プロトコルにおける仮名
スライドではSAMLを例に紹介しましたが、ws-federationやSAML、OpenID Connectなどの各種ID連携プロトコルにおいて仮名が実装されています。(PPID/Private Personal Identifierとか呼んだりしています)

SAMLにおいてはNameID Formatで表現しており、
・永続的仮名では「urn:oasis:names:tc:SAML:2.0:nameid-format:persistent」
・一時的仮名では「urn:oasis:names:tc:SAML:2.0:nameid-format:transient」
が使われます。


◆AD FSでの仮名のサポート
これまであまり話題に上りませんでしたが、AD FSでも当然仮名を扱うことが出来ます。

ずいぶん前の記事ですが、このあたりでこっそりと紹介されています。

Technet
 When to Use a Custom Claim Rule
 http://technet.microsoft.com/en-us/library/ee913558.aspx
 - Example: How to issue a PPID claim based on an LDAP attribute

MSDN blog
 Name Identifiers in SAML assertions
 http://blogs.msdn.com/b/card/archive/2010/02/17/name-identifiers-in-saml-assertions.aspx


簡単に解説すると、AD FSにはビルトインで「_OpaqueIdStore」というIDストアが定義されており、そこから適切なNameID Format(persistent/transient)をプロパティとしてつけてクレームを発行する、という手順になります。

以下に設定例を紹介します。
(基本はMSDN blogの手順です)


◆永続的仮名を発行する場合
対象のRelying Partyのクレームルール(要求変換規則)に以下の2つのルールを定義します。

1._OpaqueIdStoreからIDの払い出し
 以下のカスタムルールを直接記載します。

c:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname"]
=> add(store = "_OpaqueIdStore", types = ("http://mycompany/internal/persistentId"), query = "{0};{1};{2}", param = "ppid", param = c.Value, param = c.OriginalIssuer);




2.払い出された値をNameIDとして発行する
 GUIで設定可能です。
 ・[入力方向の要求の種類]に1で発行した際のtypeを指定します
 ・[出力方向の名前IDの形式]に[永続ID]を指定します


実際に払い出されるSAML AssertionをみるとNameID Formatに「urn:oasis:names:tc:SAML:2.0:nameid-format:persistent」が設定されていて、不必要な属性(名前やメールアドレスなど)が発行されていないことがわかります。

<samlp:Response ID="_8b9add32-95c9-47ae-b0f7-fe8719b14207"
Version="2.0"
IssueInstant="2014-12-20T07:57:32.137Z"
Destination="https://sp.example.com/acs"
Consent="urn:oasis:names:tc:SAML:2.0:consent:unspecified"
InResponseTo="dlmfilinoelgaclpmbbiiknifkjngebcocfoocan"
xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
>
<Issuer xmlns="urn:oasis:names:tc:SAML:2.0:assertion">http://idp.example.local/adfs/services/trust</Issuer>
<samlp:Status>
<samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success" />
</samlp:Status>
<Assertion ID="_f9880ee1-5236-4a03-911a-dc41d4d6e589"
IssueInstant="2014-12-20T07:57:32.137Z"
Version="2.0"
xmlns="urn:oasis:names:tc:SAML:2.0:assertion"
>
<Issuer>http://idp.example.local/adfs/services/trust</Issuer>
<ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
<ds:SignedInfo>
<ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" />
<ds:SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256" />
<ds:Reference URI="#_f9880ee1-5236-4a03-911a-dc41d4d6e589">
<ds:Transforms>
<ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature" />
<ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" />
</ds:Transforms>
<ds:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256" />
<ds:DigestValue>qtaUKLYlHQjHAszsestllzzSlwKG/GnfxBTM0LALHmM=</ds:DigestValue>
</ds:Reference>
</ds:SignedInfo>
<ds:SignatureValue>KC2HtMYzjIQ...snip...bhQ3Dg3QBlpcmiA==</ds:SignatureValue>
<KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#">
<ds:X509Data>
<ds:X509Certificate>MIIC+jCC...snip...E94b3S4cuw==</ds:X509Certificate>
</ds:X509Data>
</KeyInfo>
</ds:Signature>
<Subject>
<NameID Format="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent">Eh1as1gTWtagxAk+ECEuTnu/dzUS2fyOnx3ER/NMCeg=</NameID>
<SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">
<SubjectConfirmationData InResponseTo="dlmfilinoelgaclpmbbiiknifkjngebcocfoocan"
NotOnOrAfter="2014-12-20T08:02:32.137Z"
Recipient="https://sp.example.com/acs"
/>
</SubjectConfirmation>
</Subject>
<Conditions NotBefore="2014-12-20T07:57:32.121Z"
NotOnOrAfter="2014-12-20T08:57:32.121Z"
>
<AudienceRestriction>
<Audience>sp.example.com</Audience>
</AudienceRestriction>
</Conditions>
<AttributeStatement>
<Attribute Name="http://custom/identity/claims/age">
<AttributeValue>I am 25 years old.</AttributeValue>
</Attribute>
</AttributeStatement>
<AuthnStatement AuthnInstant="2014-12-20T07:57:31.839Z"
SessionIndex="_f9880ee1-5236-4a03-911a-dc41d4d6e589"
>
<AuthnContext>
<AuthnContextClassRef>urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport</AuthnContextClassRef>
</AuthnContext>
</AuthnStatement>
</Assertion>
</samlp:Response>


発行されているのは、
・発行元(Issuer):SPがあらかじめ信頼したIdPのEntityID
・識別子(NameID):仮名
・年齢(age):I am 25 years old.(カスタムスキーマを設定して年齢だけ渡すルールを別途書いています)
・認証情報(AuthnContextClassRef):urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport(パスワードで認証されたことを示します)
といった情報くらいです。
サービスは「あらかじめ信頼したIdP」で「パスワードで認証された」ユーザで「18歳以上(25歳という属性より)」であることがわかるので、ログインを許可しコンテンツを利用させることが出来る、と判断することが出来ます。
また、発行されたNameIDは前回同じユーザがログインした時のものと同じ値なので、サービス側で保持している情報との紐づけも可能となります。


◆一時的仮名を発行する場合
同じく、対象のRelying Partyのクレームルール(要求変換規則)に以下の2つのルールを定義します。

1._OpaqueIdStoreからIDの払い出し
 以下のカスタムルールを直接記載します。

c1:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname"]
&& c2:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/authenticationinstant"]
=> add(store = "_OpaqueIdStore", types = ("http://mycompany/internal/sessionid"), query = "{0};{1};{2};{3};{4}", param = "useEntropy", param = c1.Value, param = c1.OriginalIssuer, param = "", param = c2.Value);




2.払い出された値をNameIDとして発行する
 GUIで設定可能です。
 ・[入力方向の要求の種類]に1で発行した際のtypeを指定します
 ・[出力方向の名前IDの形式]に[一時ID]を指定します



実際に払い出されるSAML AssertionをみるとNameID Formatに「urn:oasis:names:tc:SAML:2.0:nameid-format:transient」が設定されていて、不必要な属性(名前やメールアドレスなど)が発行されていないことがわかります。(先の永続IDに発行されたAssertionとNameID部分だけが異なります)

<NameID Format="urn:oasis:names:tc:SAML:2.0:nameid-format:transient">luV8SsaKfGB+vn3IpxhsUL1M/EekpM5E4S20YhWp1Go=</NameID>


こちらも同じく発行されているのは、
・発行元(Issuer):SPがあらかじめ信頼したIdPのEntityID
・識別子(NameID):仮名
・年齢(age):I am 25 years old.(カスタムスキーマを設定して年齢だけ渡すルールを別途書いています)
・認証情報(AuthnContextClassRef):urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport(パスワードで認証されたことを示します)
といった情報くらいです。
サービスは「あらかじめ信頼したIdP」で「パスワードで認証された」ユーザで「18歳以上(25歳という属性より)」であることがわかるので、ログインを許可しコンテンツを利用させることが出来る、と判断することが出来ます。
また、発行されたNameIDは前回同じユーザがログインした時のものとは異なる値なので、サービス側では前回ログインしたユーザと今回ログインしてきたユーザが同じユーザであることが判別できないので、サービス内部でのユーザの紐づけは出来ません。


◆仮名を使う場合の注意点
せっかく仮名を使ったとしても、他にユーザを一意にする属性(メールアドレスなど)をAssertionの中に含めてしまうと仮名を使う意味が全くなくなってしまうので注意が必要です。
(おそらくディレクトリ同期したユーザの情報とAD FSが発行するクレームの紐づけをする必要があるが故にではありますが)悪い例として、Office365のID連携ではNameIDは永続的仮名を使うのですが、別途IDP Emailという属性でメールアドレスを設定する必要があるので、実は仮名の使い方としては意味がありません。

アプリケーションとのID連携を設計する際は、必要とされるプライバシー要件を十分に考慮して利用するNameIDのタイプや連携する属性を検討しましょう。

[Office365/AzureAD]OpenAMとのID連携③

$
0
0
注意事項)
今回のポストでの構成内容は非サポートの構成を含んでいますので、実環境への適用は避けてください。動作上、ライセンス上の問題が発生しても当方は責任を負いかねます。また、本稿はForefront Identity Manager(FIM)に関する知識をある程度持っている方を対象として書いていますので、細かいFIMの使い方については本blogの他のポストなどを参考にしてください。

ここまでシングルサインオンを中心にOpenAMを使ったOffice365とのID連携(フェデレーション)の解説をしてきましたが、今回はそのバックエンドのプロビジョニングについて解説します。

これまでのポスト
[Office365/AzureAD]OpenAMとのID連携①
[Office365/AzureAD]OpenAMとのID連携②

今回も全体の図の中で枠線で囲っている部分の解説をしていきたいと思います。



AADSyncを使ってオンプレミスのAD DS上のアカウントをAzureADおよびOpenAMのレポジトリであるOpenDJにプロビジョニングしています。
早速構成していきましょう。

◆OpenAMのユーザとOffice365のユーザを紐づけるための準備
最初に大前提として、Office365とのID連携を実現するためには「SAML AsserionとAzureAD上のユーザの以下の属性が一致すること」が必要となります。

属性名属性値
SAML AssertionAzureAD
NameIDImmutableId任意の値(AD FS/AADSync構成の場合の初期値はAD DS上のアカウントのObjectSidをBase64エンコードした値)
IDPEmailUserPrincipalNameメールアドレス形式の値(AD FS/AADSync構成の場合の初期値はAD DS上のアカウントのUserPrincipalName属性の値)


通常AD FS/AADSync(もしくはDirSync)を使うと自動的に上記要件を実現する様に設定が行われますが、今回はAD FSの代わりにOpenAMをIdentity Provider(IdP)として使いますので、OpenAMがSAML Assertionとして発行する値とAzureAD上のユーザの属性を一致させるように、OpenAMのユーザレポジトリであるOpenDJおよびAzureADを構成する必要があります。

IDPEmailについては既に前回OpenAMのリモートサービスプロバイダーを設定する際にIDPEmailとOpenAMのmail属性をマッピングするように設定をしてありますので、追加の設定は不要ですので、NameID/ImmutableIdの値をどうするか考える必要があります。
通常、AD DSアカウントを使うのでObjectSid属性を元にImmutableIdを生成しAzureADへプロビジョニングすることになるのですが、OpenAMのレポジトリであるOpenDJにAD DSのObjectSidを持っていくのもナンセンスなので、今回は簡易的になりますが、AD DS上のsAMAccountName属性とOpenDJ上のuidとAzureAD上のImmutableIdにマッピングすることでOpenAMとAzureADが共通の値を使えるようにします。


◆AzureADとの同期設定
何はともあれAADSyncをダウンロードしてセットアップします。

 ダウンロードページ(2014/12/18に最新版がリリースされています)
 http://www.microsoft.com/en-us/download/details.aspx?id=44225

セットアップを行う際、AzureADとAD DSのアカウントのマッチングに関する設定を行う画面が出てきますので、ここを以下のように設定します。
・sourceAnchor attribute : sAMAccountName
・userPrincipalName attribute : mail

このsourceAnchorがAzureAD上のImmutableIdと紐づく属性となるので、先に述べたようにsAMAccountNameを設定します。また、userPrincipalNameについては.localなどのローカル名前空間でAD DSを構成している環境においてはAzureADのメールアドレスと正しく紐づかないので、別属性(ここではメールアドレス属性)にAzureAD上のメールアドレスの値を設定することにします。



◆OpenDJとの同期設定
まず、AADSyncはAD DSとAzureADの同期しかサポートされませんので、当然のことながらそのままではOpenDJにユーザをプロビジョニングすることはできません。
そこで、非サポートですがForefront Identity Manager(FIM)用のGeneric LDAP Connectorを無理やりAADSyncで使えるように構成します。

 Generic LDAP Connector for Forefront Identity Managerのダウンロードページ
 https://www.microsoft.com/en-us/download/details.aspx?id=41163

無理やり、と言っても基本的にDirSyncもAADSyncもエンジンはFIM Synchronization Serviceなので、コネクタをインストールしてフォルダ構成を合わせれば認識してしまいます。

Generic LDAP Connectorをインストールすると実体のDLLは以下のフォルダに展開されます。
 C:\Program Files\Microsoft Azure AD Sync\Synchronization Service\Extensions

これをAADSyncが利用するコネクタ用のフォルダへコピーします。
 C:\Program Files\Microsoft Azure AD Sync\Extensions

同様にパッケージコネクタの定義ファイルもコピーします。
 元)C:\Program Files\Microsoft Azure AD Sync\Synchronization Service\UISHELL\XMLs\PACKAGEDMAs
 先)C:\Program Files\Microsoft Azure AD Sync\UIShell\XMLs\PackagedMAs

後は、Synchronization Managerから管理エージェントを作成し、Run Profileを定義します。
作成するRun ProfileはとりあえずFull Import/Delta Import/Full Synchronization/Delta Synchronization/Exportで大丈夫です。

諸々の設定が終わると、こんな状態になります。



後はAADSyncのSynchronization Rules Editorを使って属性のマッピングを行うのですが、その前に一つ大事な考慮事項があります。
AzureADとOpenAMのID連携設定を行うと、AzureADからOpenAMへ以下の認証要求がSAMLプロトコルで飛んできます。
<samlp:AuthnRequest xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
ID="_142f225c-9a69-4f38-b585-ba4956b17e32"
IssueInstant="2014-12-25T06:49:39Z"
Version="2.0"
AssertionConsumerServiceIndex="0"
>
<saml:Issuer>urn:federation:MicrosoftOnline</saml:Issuer>
<samlp:NameIDPolicy Format="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent" />
</samlp:AuthnRequest>

重要なのはこの要求の中のNameIDPolicy Formatの部分です。
意味合いとしては「Office365/AzureADにログインするには"urn:oasis:names:tc:SAML:2.0:nameid-format:persistent"というフォーマットでNameIDを発行して欲しい」、ということなので、OpenAM側で該当するフォーマットでアサーションを発行してあげるように設定する必要があります。
もちろんOpenAMの全体設定として必ず当該フォーマットでの認証要求があったらNameIDの値に特定の値(ここではuid)を渡す、という設定を行うことも可能ですが、あまりにも汎用性がない構成となってしまいますので、AzureADからの"urn:oasis:names:tc:SAML:2.0:nameid-format:persistent"形式での要求があった場合にはuidの値をNameIDとして発行する、という設定を行いたいと思います。

OpenAMでは上記のようなSP毎に発行するNameIDの値を定義するために、ユーザの以下の属性を使います。
※OpenAMの前身であるOpenSSOの更に前身であるSun Access Managerの時代を彷彿とさせる属性名です。
・sun-fm-saml2-nameid-info
・sun-fm-saml2-nameid-infokey

それぞれの属性には以下のような値を設定する必要があるので、AADSyncのExpression Ruleでマッピングを定義します。

属性
sun-fm-saml2-nameid-info"OpenAMのIdP EntityID"|"SP(AzureAD)のEntityID"|"発行する値"|"OpenAMのIdP EntityID"|"NameID Format"|"発行する値"|"SP(AzureAD)のEntityID"|IDPRole|falsehttps://openam.example.com/OpenAM-11.0.0|urn:federation:MicrosoftOnline|kenshinu|https://openam.example.com/OpenAM-11.0.0|urn:oasis:names:tc:SAML:2.0:nameid-format:persistent|kenshinu|urn:federation:MicrosoftOnline|IDPRole|false
sun-fm-saml2-nameid-infokey"OpenAMのIdP EntityID"|"SP(AzureAD)のEntityID"|"発行する値"openam.example.com/OpenAM-11.0.0|urn:federation:MicrosoftOnline|kenshinu



また、上記属性を使うため、OpenDJ上のアカウントのスキーマ(objectClass)設定として以下を設定します。
・inetOrgPerson
・inetUser
・sunFMSAML2NameIdentifier

AADSyncのSynchronization Rules Editorでマルチバリュー属性を設定する場合は面倒ですが、複数のルールを定義し、joinをしていく必要があるので、追加するobjectClassの値ごとにルールを追加します。


ここまでを踏まえて定義したルールが以下です。
①ベースの作成

ページ設定
Description項目
NameOut to OpenDJ - Base Identity
Connected SystemOpenDJ
Connected System Object TypeinetOrgPerson
Metaverse Object Typeperson
Link Typeprovision
Soft Delete Expiry Interval0
Precedence0
Scoping filterAttributeOperatorValue
mailENDSWITH@example.com
TransformationsFlowTypeTarget AttributeSourceApply OnceMerge Type
Expressiondnuid="& [accountName] & ",ou=people,dc=example,dc=comUpdate
Directsnsn-Update
DirectgivenNamegivenName-Update
Directmailmail-Update
ConstantuserPasswordP@ssw0rdUpdate
Expressionsun-fm-saml2-nameid-infohttps://openam.example.com/OpenAM-11.0.0|urn:federation:MicrosoftOnline|"& [accountName] & "|https://openam.example.com/OpenAM-11.0.0|urn:oasis:names:tc:SAML:2.0:nameid-format:persistent|"& [accountName] & "|urn:federation:MicrosoftOnline|IDPRole|falseMergeCase
Expressionsun-fm-saml2-nameid-infokey"openam.example.com/OpenAM-11.0.0|urn:federation:MicrosoftOnline|"& [accountName]MergeCase
ConstantobjectClassinetOrgPersonMergeCase
Directcncn-Update





尚、objectClass、sun-fm-saml2-nameid-info、sun-fm-saml2-nameid-infokey属性はOpenDJ上でマルチバリュー属性となっているのでMergeTypeはMergeCaseを設定する必要があります。

②objectClassの追加(inetUser)

ページ設定
Description項目
NameOut to OpenDJ - objectClass inetUser
Connected SystemOpenDJ
Connected System Object TypeinetOrgPerson
Metaverse Object Typeperson
Link Typejoin
Precedence0
TransformationsFlowTypeTarget AttributeSourceApply OnceMerge Type
ConstantobjectClassinetUserMergeCase





③objectClassの追加(sunFMSAML2NameIdentifier)

ページ設定
Description項目
NameOut to OpenDJ - objectClass sunFMSAML2NameIdentifier
Connected SystemOpenDJ
Connected System Object TypeinetOrgPerson
Metaverse Object Typeperson
Link Typejoin
Precedence0
TransformationsFlowTypeTarget AttributeSourceApply OnceMerge Type
ConstantobjectClasssunFMSAML2NameIdentifierMergeCase





ここまでで設定が完了するので、AADSyncを使ってAD DS上のユーザをAzureADおよびOpenDJへ実際に同期をしてみます。

◆AD DS上のユーザ作成と同期の実行
今回、ローカルドメイン(.local)としてAD DSを作成したので、userPrincipalNameの代わりにメールアドレスを使う設定を行いましたので、ユーザのメールアドレス属性にAzureADで使うメールアドレスを設定します。




これで準備が整ったので、タスクスケジューラ上のAADSyncスケジュールを有効化して実行します。
尚、OpenDJへの同期についてはAADSyncのスケジューラには組み込まれていませんので手動で実行します。

結果、OpenDJ上に以下のようなユーザが作成され、OpenAMでOffice365/AzureADへシングルサインオン出来るようになります。
dn: uid=kenshinu,ou=people,dc=example,dc=com
objectClass: person
objectClass: organizationalPerson
objectClass: inetorgperson
objectClass: inetUser
objectClass: top
objectClass: sunFMSAML2NameIdentifier
givenName: Kenshin
uid: kenshinu
cn: Kenshin Uesugi
sun-fm-saml2-nameid-info: https://openam.example.com/OpenAM-11.0.0|urn:
federation:MicrosoftOnline|kenshinu|https://openam.example.com/OpenAM-
11.0.0|urn:oasis:names:tc:SAML:2.0:nameid-format:persistent|kenshinu|urn:federa
tion:MicrosoftOnline|IDPRole|false
sn: Uesugi
userPassword: {SSHA}udJ1bXXYdNu2KlpMgXseHxSQnum7i6weFAndjw==
mail: kenshinu@example.com
sun-fm-saml2-nameid-infokey: openam.example.com/OpenAM-11.0.0|urn:fede
ration:MicrosoftOnline|kenshinu




繰り返しになりますが、今回はAADSyncを使いましたが、Forefront Identity Managerを使えばちゃんとサポートされた構成を作ることが出来ますので、マネはしないでください。
ただ、今後AADSyncでも他のレポジトリとの同期をサポートしていく予定もあるようなので、Synchronization Rules Editorの使い方を中心にAADSyncの使い方をマスターしておくと良いと思います。

参考)Directory Integration Tools(DirSync/AADSync/FIMの機能比較)
 http://msdn.microsoft.com/en-us/library/azure/dn757582.aspx

このページを見るとAADSyncでは様々な機能がCS(Comming Soon)となっており、DirSyncやFIMがAADSyncに統合されていく姿が見えてくると思います。

と、言うことで今後もAADSyncについては目が離せませんね。


尚、今回まででOpenAMを使ったOffice365とのID連携については終わりですが、次回以降で最初の全体構成図の他のパートについても解説をしていこうと思います。

[AADSync]オンプレExchangeへのOAuth2認可サポート等

$
0
0
マイクロソフトの製品ライフサイクルに関する考え方がこれまでの一気にバージョンアップ、から継続的にアップデートという方針に変わったのに対応してAADSyncの新機能がちょこちょこリリースされるようになっています。

今回(2014/12/18)のリリース(1.0.475.1202)では以下の機能が追加になっています。

新機能の追加

  • パスワード同期機能が属性ベースでのフィルタリングに対応
    • 属性ベースでパスワード同期するユーザのフィルタリングが出来るようになりました
  • msDS-ExternalDirectoryObjectID属性のオンプレADへの書き戻し対応
    • この属性をオンプレADにも持つことが出来るようになったため、新しいOfficeクライアントからExchangeオンラインに加えてオンプレミスのExchangeへのアクセスについてもOAuth2(JWT)で認可することが可能になりました

  ※OfficeクライアントのOAuth2サポートについては以前のポストを参照してください


その他、もろもろバグ修正

私的に特にうれしいのはsourceAnchorの設定をカスタマイズしてインストールしてもセットアップウィザードを再度実行すると設定が反映されない、というバグ修正でした。(カスタマイズ前提なので)


以下のページからダウンロードできます。
 http://www.microsoft.com/en-us/download/details.aspx?id=44225

MVP Renewal 6th !!

$
0
0
今年もForefront Identity Manager(FIM)の分野でAwardをいただきました。
なんだかんだで6年目に突入です。


今年はFIMからMicrosoft Identity Manager 2015(MIM)へのメジャーアップデートが控えていることもあり、大きな節目になる年だと思います。

また、私が主に活動しているエンタープライズにおけるアイデンティティの分野においても、これまでのクラウドへのシフトをキードライバーとするハイブリッド・アイデンティティ管理(ID連携、REST APIによるプロビジョニング)が更に発展する形で、以下のキーワードがここ数年の主流となってくると思います。(勝手な予想です、念のため。また、もちろん既に動き始めているキーワードばっかりです)

  • モバイル
    • エンタープライズ・モビリティというキーワードで各ベンダが動き始めている 分野ですが、これまでのPCの延長線上でのブラウザ・ベースでのID連携/シングルサインオンから、よりモバイルの特性を活かしたネイティブ・アプリケーションでのID連携が加速していくと思われます。
  • 多要素認証
    • クラウドとのID連携が加速したことにより、もはや企業のセキュリティの境界がFirewallではなくアイデンティティになりましたが、結果としてこれまで考えられなかった「インターネット上に企業がホストするログイン画面を公開する」という状況が拡大してきています。こうなるとコンシューマ・アイデンティティの分野で長年培われてきた知恵を最大限に活用してセキュリティ対策をしていく必要が出てきます。上記のモバイルの流れと相まって、現状の解としてモバイルデバイスを使った多要素認証(SMSやAuthenticatorアプリ連携)のエンタープライズ分野への適用が進むと思われます。
  • 特権ID管理
    • クラウドやモバイルとは直接は関係しませんが、アプリケーションがより分散管理されていく傾向にあるのは間違いないと思います。また、アプリケーションの分散化に対応する形で、ID管理/ID連携がセキュリティ上の管理ポイント(HUB)となっていく傾向にあるのも同様に間違いないと考えられます。そうなってくると、統制を効かせる意味でも、これまで以上に特権IDに関する管理が複雑化・厳密化する傾向にあると考えています。

また、当然これまでもキーワードとなってきたトラストフレームワークのエンタープライズ活用も、グループ企業内外でのID連携の利用拡大に対応して進んで行く事になると思います。上記特権ID管理などについてはLoA(Level of Assurance)やLoP(Level of Protection)を向上・保証する上で重要なキーワードになってくるものなので、今年は一歩進んでくれるんではないかな?と期待している分野です。

最後になりましたが、本年もよろしくお願いいたします。

[JWT/OAuth]Service Accountを使ってGoogle APIを利用する①

$
0
0
今回はサーバアプリケーションからAPIを利用する際の認可の話をGoogleAppsでのOAuth(JWT)の使い方の例をベースに紹介したいと思います。

◆アプリケーションがAPIを利用する際の課題とOAuth2.0
Forefront Identity Manager(FIM)などのサーバアプリケーションからGoogle Admin Directory APIなどを利用する際、サーバアプリケーションに管理者ユーザのIDやパスワードを保持すると様々なデメリットがあります。
例)

  • 管理者のパスワードを変更する際、サーバアプリケーションの設定を変える必要が出てくる
  • サーバアプリケーションに管理者パスワードを保存しておく必要がありセキュリティ上の問題となる可能性がある

※実際、現在codeplex上に公開しているFIM用GoogleApps管理エージェント(Management Agent/MA)ではMA設定にGoogleAppsの管理者ユーザのIDとパスワードを保持しています。

 FIM 2010 GoogleApps MA
 https://fim2010gapps.codeplex.com/


また、サーバアプリケーションに限らずアプリケーションにIDやパスワードを持たせてユーザの代わりにAPIへアクセスするのはよろしくない、ということでOAuth2.0を使った認可(アプリケーションへの権限委譲)が主流になってきています。

(フローの例)
①認可サーバでユーザがAPI(保護対象リソース)へWebアプリケーションがアクセスすることを許可
②認可サーバより発行される認可コードをWebアプリケーションへ渡す
③Webアプリケーションが認可サーバで認可コードとアクセストークンを交換する
④発行されたアクセストークンを使ってAPIを利用


◆サーバアプリケーションがOAuthを使う際の課題と対応
しかし、一般的なWebアプリケーションとは異なりサーバアプリケーションではリソースオーナーであるユーザが一切介在することなくAPIを利用することが求められます。

このようなケースに対応し、Azure Active DirectoryやGoogleApps、Salesforce.comなどの主要クラウドベンダはサーバアプリケーション向けにJWT(JSON Web Token)やJWS(JSON Web Signature)を使ったAPI利用フローを用意しています。

 Azure ADの例(少し古いです)
  http://idmlab.eidentity.jp/2012/09/waad-rest-client-graph-api.html

 GoogleAppsの例(公式ドキュメント)
  https://developers.google.com/accounts/docs/OAuth2ServiceAccount


今回はちょうど先にあげたCodeplexに上げているFIM 2010 GoogleApps MAが使っているGoogleAppsのProvisioning APIの提供が終了するので、代わりに提供されているDirectory APIへ対応させるために改修を行う過程で行ったGoogleApps APIへのアクセス認可の方法を紹介していきます。


◆GoogleAPIへのアクセス用トークンを取得する
さて、実際にGoogleAppsの場合のアクセストークンの取得方法を解説していきます。
先のGoogleのドキュメントをみるとサービスアカウントを使ったAPI利用、というケースが今回のユースケースに該当します。流れとしてはJWTにRSA-SHA256で署名したものをOAuthのトークンエンドポイントへPOSTすればアクセストークが取得できる、とあります。
以下が公式ドキュメントに書いてあるフローです。



【準備】
まずは、JWTを生成する上で必要な設定をGoogle側に入れていきます。

必要なのは、以下の4点です。
①必要なAPIを有効化する
 ⇒GoogleAppsでは最初からすべてのAPIが有効になっているわけではないので、必要なAPIを有効化します。
②クライアントIDを生成する
 ⇒Googleにクライアント情報を登録し、署名に使う証明書を発行してもらう
③GoogleAppsのテナントのAPIアクセスを有効化する
 ⇒初期状態ではAPIアクセスは無効なので有効化する必要があります。
④生成したクライアントから利用できるAPIの範囲(スコープ)を設定する
 ⇒②で生成したクライアントが利用できるAPIをあらかじめ定義しておきます。


順番に見ていきます。①②はGoogle Developer Consoleから、③④はGoogleAppsの管理ダッシュボードのセキュリティメニューから設定します。

①必要なAPIを有効化する
 Google Developer Console(https://console.developers.google.com)にアクセスするとプロジェクトを作成する画面になりますので、まだプロジェクトを作成したことのない人はプロジェクトを作成してください。
 作成が終わったら左ペインの[APIと認証]メニューよりAPIを選択するとAPI一覧の画面になりますので、今回使いたいDirectory APIが含まれるAdmin SDKを探してステータス列の[OFF]のボタンをクリックし有効化を行います。


 確認・同意画面がポップアップするので[同意]をクリックしてAPIを有効化します。


 有効なAPI一覧にAdmin SDKが出てきます。



②クライアントIDを生成する
 次に、同じくDeveloper Consoleの[認証情報]メニューを開き、新しいクライアントIDを作成します。


 作成するクライアントIDの種類を聞かれるので[サービスアカウント]を選択します。


 作成が成功すると、公開鍵/秘密鍵のペアが生成され、秘密鍵の入った証明書ファイル(.p12ファイル)が自動的にダウンロードされます。このファイルは後で使うので大切に保管しておいてください。秘密鍵のパスワードは[notasecret]で固定みたいですが、その値の通り特に秘密事項ではありませんので合言葉として覚えておけばよいです。


 その後、画面上にサービスID情報が表示されます。
 ここで表示されるサービスIDおよびメールアドレス(サービスアカウントのメールアドレス)は後で使いますので、保存しておいてください。



 これでDeveloper Consoleは終わりです。

③GoogleAppsのテナントのAPIアクセスを有効化する
 次はGoogleAppsの管理ダッシュボードの設定です。
 ダッシュボードよりセキュリティメニューを開き、[APIリファレンス]を開くと[APIアクセス]が出てきますので、ここで[APIアクセスを有効にする]にチェックを入れておきます。これでこのGoogleAppsテナントへAPI経由でのアクセスが出来るようになります。


④生成したクライアントから利用できるAPIの範囲(スコープ)を設定する
 同じくセキュリティメニューの[詳細設定]を開きます。ちなみに詳細設定が表示されていない場合は[もっと見る]というリンクがシングルサインオン設定メニューの下にありますので、そちらをクリックしてください。
 サブメニューの中の[APIクライアントアクセスを管理する]をクリックして実際の設定を行います。


 クライアント名に②で生成したクライアントID、APIの範囲に使いたいAPIに対応したスコープを設定します。
 ちなみにDirectory APIの中で今回はユーザを管理したいので、以下を設定します。
  https://www.googleapis.com/auth/admin.directory.user


 スコープの一覧は以下に記載されています。
  https://developers.google.com/admin-sdk/directory/v1/guides/authorizing


ここまでで準備は終わりです。
次回は実際にJWTを生成してアクセストークンを取得するところを解説します。
(.Net標準でSystem.IdentityModel.Tokens.jwtのJwtSecurityTokenHandlerがあるのでせっかくなので使おうとしましたが、結果的にGoogleとはかなり相性が悪く、ほぼスクラッチでコードを書きました...orz。詳しくは次回)
Viewing all 771 articles
Browse latest View live