IDMaaSシリーズ第三弾として今回はAzure Active Directory(AAD)をやってみます。
AADはざっくり言うと認証連携のIdPのクラウドサービスで
任意のアプリケーションに対してOpenID ConnectやSAML、WS-Federation等の
認証連携プロトコルを使ってシングルサインオンができるようになるサービスです。
また、これらの認証連携プロトコルのRP/SPとして対応していない特定のサービスに対しても
シングルサインオンができるような仕組みを持っています。
既存のActive DirectoryからAADに同期することで既存のActive Directoryを
ユーザーリポジトリとして利用することも可能です。
ということで、今回はAADを使ってSalesforceとのシングルサインオンをやってみます！
Azure Active Directoryに関する説明は以下のサイトが詳しいです↓
Windows Azure Active Directoryことはじめ （1/8）：CodeZine
クラウド時代のActive Directoryの使い方 - IT、IT製品の情報なら【キーマンズネット】
1. Microsoft Azureポータルで対象のAADを選択
まずはアカウントにログインしてポータルトップへアクセスしActive Directory＞既定のディレクトリを選択します。
ドメイン変更等の理由で規定のディレクトリを利用しない場合は
下メニューの”新規”からAzure Active Directoryを新規に追加します。
Auth0だとドメイン名の32文字の文字数制限があったりするので
外部アプリの制限に引っかかった等の場合は新しくAADを作成してください。
2. 作成したディレクトリにユーザを追加
Azure Active Directory用のユーザを作成します。このユーザに対してログインすることで他のサービスにシングルサインオンすることができます。
Microsoftアカウント（設定時にログインしているユーザ）でもシングルサインオンが可能です。
まずは、ユーザタブで”ユーザの追加”をクリック。
作成するユーザ情報を入力。
一時パスワードを発行します。（初回ログイン時にパスワードを設定するフロー）
3. SalesforceアプリをAAD上に作成
アプリケーションから新規のアプリケーションを追加
ダイアログで”ギャラリーからアプリケーションを追加します”を選択
ギャラリー選択画面が出てくるのでSalesforceを選択
アプリケーションが作成され、クイックスタートメニューが表示されます
4. アプリケーションの設定（シングルサインオンの構成）
”シングルサインオンの構成”から”Windows Azure ADのシングルサインオン”を選択
アプリケーションURLの構成ではSP(Salesforce)側のEntityIDを設定。
重複がなければhttps://{マイドメイン}やhttps://saml.salesforce.com等でOK。
次に証明書のダウンロードを行い、発行者のURL、リモートログインURL、リモートログアウトURLをコピー。
下記のチェックボックスにチェックを付けて終了
5. Salesforceでシングルサインオン設定を作成
以下のようにシングルサインオン設定を新規に作成する。
発行者、ID プロバイダのログイン URL、ID プロバイダのログアウト URLにはAADで発行した値を入力し
IDプロバイダの証明書にはダウンロードした証明書をセット。
エンティティIDは4で設定した値を入力。
ちなみにAADからのSAMLアサーションは以下のようになっており
MicrosoftアカウントなどのユーザはNameIdentifierにユーザ名が入ってこなかったりしたので
AAD以外のユーザに対してシングルサインオンさせたい場合には
メールアドレス属性値等のNameID以外の属性をマッピングするのが良さそうです。
<samlp:Response ID="_56ff1917-5256-4597-9883-53d6a887454d" Version="2.0" IssueInstant="2014-09-21T03:08:36.604Z" Destination="https://*******-developer-edition.my.salesforce.com?so=***********" InResponseTo="_2HjQveb6w8_W.CMtK885n14nFSl26ppL4M7tNnaaFebO8928GDWhzDi38ano3l.a2sZSObobG5l._vcVfJsvhJ3rmyfKO6nqiBdTpZYJtu3ntDTZE4QBnODTyRjV48Q3vHcpDmL16Yt8jOZfMdiYM_P_m2fNONBJUUjTkZimumvGDV_tP8P8f8Y5oqxumMPrRgPp.kI_jZFpSg1q7Oo2pwwC_g0.4ZA" xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol">
<Issuer xmlns="urn:oasis:names:tc:SAML:2.0:assertion">https://sts.windows.net/************/</Issuer>
<samlp:Status>
<samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success"/>
</samlp:Status>
<Assertion ID="_c4cfc562-f8cf-4350-8dd0-9ccfe4d72e70" IssueInstant="2014-09-21T03:08:36.588Z" Version="2.0" xmlns="urn:oasis:names:tc:SAML:2.0:assertion">
<Issuer>https://sts.windows.net/******************/</Issuer>
<ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
....
</ds:Signature>
<Subject>
<NameID Format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress">test@tzmfreedom.onmicrosoft.com</NameID>
<SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">
<SubjectConfirmationData InResponseTo="_2HjQveb6w8_W.CMtK885n14nFSl26ppL4M7tNnaaFebO8928GDWhzDi38ano3l.a2sZSObobG5l._vcVfJsvhJ3rmyfKO6nqiBdTpZYJtu3ntDTZE4QBnODTyRjV48Q3vHcpDmL16Yt8jOZfMdiYM_P_m2fNONBJUUjTkZimumvGDV_tP8P8f8Y5oqxumMPrRgPp.kI_jZFpSg1q7Oo2pwwC_g0.4ZA" NotOnOrAfter="2014-09-21T03:13:36.588Z" Recipient="https://******developer-edition.my.salesforce.com?so=*********"/>
</SubjectConfirmation>
</Subject>
<Conditions NotBefore="2014-09-21T03:03:36.588Z" NotOnOrAfter="2014-09-21T04:03:36.588Z">
<AudienceRestriction>
<Audience>https://*******developer-edition.my.salesforce.com</Audience>
</AudienceRestriction>
</Conditions>
<AttributeStatement>
<Attribute Name="http://schemas.microsoft.com/identity/claims/objectidentifier">
<AttributeValue>c95ddf62-e312-4dcb-b479-60b26a8a5123</AttributeValue>
</Attribute>
<Attribute Name="http://schemas.microsoft.com/identity/claims/tenantid">
<AttributeValue>a1b803d6-e508-4360-b1bb-d98c5b3c2530</AttributeValue>
</Attribute>
<Attribute Name="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name">
<AttributeValue>test@tzmfreedom.onmicrosoft.com</AttributeValue>
</Attribute>
<Attribute Name="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname">
<AttributeValue>てすと</AttributeValue>
</Attribute>
<Attribute Name="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname">
<AttributeValue>ゆーざ</AttributeValue>
</Attribute>
<Attribute Name="http://schemas.microsoft.com/identity/claims/identityprovider">
<AttributeValue>https://sts.windows.net/***********/</AttributeValue>
</Attribute>
</AttributeStatement>
<AuthnStatement AuthnInstant="2014-09-21T03:07:19.000Z" SessionIndex="_c4cfc562-f8cf-4350-8dd0-9ccfe4d72e70">
<AuthnContext>
<AuthnContextClassRef>urn:oasis:names:tc:SAML:2.0:ac:classes:Password</AuthnContextClassRef>
</AuthnContext>
</AuthnStatement>
</Assertion>
</samlp:Response>
設定のマイドメインから認証サービスを追加するのもお忘れなく！
この設定でシングルサインオン自体は可能ですが
AADのユーザ情報とSFDCのユーザ情報を同期させたい場合は以下の設定で対応可能です。
6. アプリケーションの設定（自動ユーザプロビジョニング）
AADのSalesforceアプリのクイックスタートから”ユーザプロビジョニングの構成”を行います。同期処理はAPIを使ってバッチ処理で行われるので
同期用のユーザID・パスワード及びセキュリティトークンを設定します。
セキュリティトークンも必須らしいのでSFDCで発行しないといけないっぽいです。
これでAADからSFDCへユーザ情報の同期処理が行われます。
7. アプリケーションの設定（ユーザの割り当て）
同期にはプロファイル情報が必要なので、割り当てるユーザのプロファイルを設定していきます。まずはアプリのユーザ一覧から割り当てをクリック
ダイアログが出てくるので、任意のSalesforceプロファイルを割り当てると
SFDCへの同期対象として処理されます。
ダイアログでは最初はSFDCのデフォルト？のプロファイル一覧が表示されますが
同期が取られると実SFDC環境に存在するプロファイルが選択できるようになります。
また、最初の同期は10分くらい要するみたいらしいです。
あと、6でユーザプロビジョニングの設定をしてしまうと、設定の無効化ができなくなります。
シングルサインオン設定ガチャガチャいじってたら無効化できたりしたんですが
再現性が全くないのでプロビジョニングを無効化するときはアプリごと再作成するのが良さそう。
所感的なこと
AAD使った感想（って言っても一週間くらいしか触ってない）ですが簡単にSAMLのIdPあるいはOIDCのOPをホスティングできちゃうのは良いなーと思いました。
また、無料のプランでもMFAは使えないものの、ディレクトリオブジェクトの制限が500,000個で
かなりの数のユーザが作成できることになります。
プランと料金に関しては本家の価格表を参照ください。
まだ属性のマッピングとか細かい制御ができないっぽいのがアレですが、今後の機能拡張に期待大！
