全国7000万人のSAMLフリークの方に朗報です！！
ついに、Azure Active Directory（Azure AD）が発行するSAML Assertionにカスタム属性をマッピングすることが出来るようになりました。
公式Blogでのアナウンス
#AzureAD now supports custom unique IDs in SAML tokens for gallery apps
https://blogs.technet.microsoft.com/ad/2016/05/13/azuread-now-supports-custom-unique-ids-in-saml-tokens-for-gallery-apps/
これで何がうれしいか？というと、例えばSAML AssertionのこれまではnameIdentifierにuserPrincipalNameやmail属性など限定的な属性しかマッピングできなかったが故に例えば、Google AppsのカスタムドメインとAzure ADのカスタムドメイン名をきっちり合わせておかないとSSOできなかったり、特に複数のSaaSアプリケーションを契約していて各SaaSアプリのnameIdentifierが異なる形式だったときに不具合が起きたり、、ということが解消するんです！
ちょっと視点は異なりますが、以前Google AppsへのSSO時のSAML Assertionのマッピングのワークアラウンドについて書きました。この辺りもカスタム属性マッピングで解消できるポイントの一つです。
[Azure AD]Google AppsとのSSO設定でのポイント
http://idmlab.eidentity.jp/2016/02/azure-adgoogle-appssso.html
早速見ていきましょう。
◆準備１）Azure AD Connectで拡張属性の同期ルールを設定する
まずは、Azure AD上のextensionAttributeに値をセットしてあげないといけません。今回はオンプレミスのActive Directory上の属性をAzure AD Connectを使って同期することにします。変更が必要なのは、
オンプレAD⇒Metaverse
Metaverse⇒Azure AD
の同期ルールです。今回は、オンプレADの「説明」属性をAzure ADのextensionAttribute1へ同期することにしたので、まずはAzure AD ConnectのSync Rules Editorを開き、以下の通りルールを作成（編集）します。
| 方向 | ルール名 | Flow Type | Target Attribute | Source Attribute | Apply Once | Merge Type |
|---|---|---|---|---|---|---|
| Inbound | In from AD - User Common | Direct | extensionAttribute1 | description | チェックなし | Update |
| Outbound | Out to AAD - User Identity | Direct | extensionAttribute1 | extensionAttribute1 | チェックなし | Update |
※本番環境では既存のルールを編集するのではなく、追加ルールを新規作成することをお勧めします。
こちらがオンプレADの説明属性をMetaverseのextensionAttribute1へ同期するInboundルールです。
次にこちらがMetaverseのextensionAttribute1をAzure ADのextensionAttribute1へ同期するOutboundルールです。
◆準備２）オンプレADに属性値をセットする
同期ルールの設定が出来たので、対象の属性（今回は「説明」）に最終的にSAML AssertionのnameIdentifierに入れたい値を設定します。テストをGoogle Appsでやりたいので、このユーザのuserPrincipalNameとはドメイン名の異なるメールアドレスを説明属性に設定しました。
ついでにmail属性をnameIdentifierへマッピングするテストもしてみたいので、メール属性に説明属性とは異なる値を入れてみます。
これで、マッピングを変えればAzure ADに設定をしていないドメインのGoogle Appsへ、かつnameIdentifierへマッピングする属性をメールと説明で変えれば別のユーザとしてログインできるようになるはずです。
ちなみにこちらがuserPrincipalNameです。先のドメイン名とは異なることがわかります。Azure ADへのログインはこの名前で行います。
実際にこれで同期が完了するとAzure AD上のオブジェクトの状態は以下のようになります。
Azure AD ConnectのConnector Spaceで確認すると、userPrincipalName、mail、extensionAttribute1の値がそれぞれ異なっていることがわかります。
◆準備３）SAML Assertionへの属性マッピングを変更する
いよいよAzure AD上のアプリケーション向けのSAML Assertionに含める属性のマッピング変更を行います。今回はGoogle Appsを例に解説をします。アプリケーションをひらき、属性メニューからSingle Sign Onを見ると初期状態は以下のようにnameIdentifierにはuserPrincipalName属性のマッピングがされています。
このままだと、Azure AD上のuserPrincipalNameがそのままGoogle Appsへ渡るので、Azure ADとGoogle Appsのドメイン名が異なると動きません。
と、いうことで、ここを先に設定したextensionAttribute1にマッピング変更を行いたいと思います。
nameIdentifier属性の編集ボタンをクリックし、マッピングする属性としてextensionAttribute1を選択します。以前はここで拡張属性を設定することが出来ませんでしたが、今回のアップデートで選択できるようになりました。
※尚、mail属性とのマッピングは以前から出来ていたのですが、少なくとも私の環境ではマッピング変更を行っても実際のAssertionの中身を見ても正しくマッピングがされていませんでした。今回のアップデートでこの部分も解消されていました。
これで準備は完了です。
◆テスト１）Azure ADとは異なるドメインのGoogle AppsへSSOする
通常通り、Google AppsへアクセスするとAzure ADへリダイレクトされるので、Azure AD上のuserPrincipalName（今回だとGoogle Appsとは異なるユーザ名）でログインします。※当然事前にGoogle Apps側にSSO設定をしています。
すると、異なるドメインにも関わらずGoogle Appsへサインオンできました！
ログインユーザ名を見るとオンプレADの「説明」属性に設定したユーザ名になっていることがわかります。
◆テスト２）SAML Assertionの中身を見てみる
正常にサインオンできたので、SAML Tracerを使って実際にどんなAssertionが発行されているのかを確認してみます。想定通り、extensionAttribute1に入れた値がNameIDにマッピングされており、Assertionに含まれていることがわかります。
◆テスト３）別の属性にマッピングを変更して別ユーザとしてサインオンしてみる
先ほどはextensionAttribute1に入れた値をnameIdentifierにマッピングしましたが、メール属性にも別のメールアドレスを設定してあったのを思い出してください。
追加のテストとして、このメール属性をマッピングしてみます。うまくいけば、別のユーザとしてGoogle Appsへサインオンできるはずです。
やり方は簡単ですね。Azure ADのアプリケーションの設定で属性マッピングをmailに変更するだけです。
この状態で先ほどと同じAzure ADユーザでGoogle Appsへサインオンすると想定通り、別のユーザとして扱われました。
◆まとめ
今回は、同じGoogle Appsを使ってテストをしましたが、このアップデートで例えば以下のことが実現でき、Azure ADのSAML対応アプリ連携の可能性がぐっと広がりました。- Azure ADとは異なるドメインのSaaSアプリケーションへSSOができる
- これまではuserPrincipalNameにAzure ADのドメイン名が含まれてしまったので、アプリケーション側のドメイン名とAzure ADのドメイン名を一致させる必要があった。
- オンプレのアプリケーションなど、従業員番号などメールアドレス形式以外のnameIdentifier属性を要求するアプリケーションとのSSOがやりやすくなった
- これまでもExtractMailPrefix()関数でuserPrincipalnameのドメイン名を除いた値を使うことはできたが、必ずしもアプリケーションが要求する値がuserPrincipalNameのローカルパートになっているとは限らず、アプリケーション側でのID変更などが必要だった。
0 件のコメント:
コメントを投稿