リモートワークで組織外の方々とのコラボレーションが大きなテーマになっている方々も多いと思いますが、そういう時はAzure ADの外部連携（B2B）の機能ですよね。
そう言えばAzure ADのDirect FederationがGoogle以外にもSAML/ws-federationの外部IdPをサポートした、という会話をfacebookで某安納さんがしていたのを思い出したのと、先日 Alex Simons が色々と新しい機能が出たよ、というもはや個別の機能リリースの紹介だと無理だから一気にまとめて発表、みたいなポストをしていた中に、Azure AD B2CのSAMLサポートが正式リリースされた、という話があったので、もしやこれは繋がる？？？ということでやってみました。
いわゆるBYOD（Bring Your Own Identity）ってやつです。
当然、Azure ADのカスタムドメインを使った外部ID連携でも良いわけですが、この辺は後で比較をしてきます。
まず関連する記事、ドキュメント類を。
- Alex Simonsの発表いろいろ（世間的にはギャラリーがSAMLアプリの利用の無料化とかOffice365付属のAzure ADでも出来ることが増えた、というあたりがニュースなんだとは思いますが）
- Azure AD B2Bの外部IdPとの直接フェデレーション（Preview）
- Azure AD B2CのSAML対応（AlexはGAって言ってますが、ドキュメント上は未だPreview）
とりあえず完成イメージを
言葉で説明しても伝わりにくいと思うので、どういうことが出来るようになるのか？を動画にしています。
Azure AD B2Bで招待した外部ユーザでログインしようとすると、Azure AD B2Cにリダイレクトされ、LINEでログインすると、Azure ADにゲストユーザとして登録されてアプリケーションが使えるようになる、というシナリオです。
Azure AD B2CのSAMLサポート
先に書いた公式ドキュメント通りに設定していくと、Azure AD B2CがSAML IdPとして動作出来るようになります。（カスタムポリシーを使います。慣れると非常に簡単です）
大きな流れは以下の通りです。
Azure AD B2C側の設定
- アサーション署名用の証明書（PFX）を作ってポリシーキーとしてアップロードする
- ClaimsProviderとして、SAML2AssertionIssuerを作成する
- MetadataにIssuerUriとして設定したものがIdPのEntityIDになります
- CryptographicKeysに先にアップロードした証明書コンテナを指定するとアサーション署名をしてくれます（暗号化用証明書もアップロードすれば暗号化もできます）
こんな感じの設定になります。
<ClaimsProvider>
<DisplayName>Token Issuer</DisplayName>
<TechnicalProfiles>
<!-- SAML Token Issuer technical profile -->
<TechnicalProfile Id="Saml2AssertionIssuer_SAMPLE">
<DisplayName>Token Issuer</DisplayName>
<Protocol Name="SAML2"/>
<OutputTokenFormat>SAML2</OutputTokenFormat>
<Metadata>
<Item Key="IssuerUri">https://nfpoc.b2clogin.com/nfpoc.onmicrosoft.com/B2C_1A_SI_SAML_SAMPLE</Item>
</Metadata>
<CryptographicKeys>
<Key Id="MetadataSigning" StorageReferenceId="B2C_1A_samlsampleapp"/>
<Key Id="SamlAssertionSigning" StorageReferenceId="B2C_1A_samlsampleapp"/>
<Key Id="SamlMessageSigning" StorageReferenceId="B2C_1A_samlsampleapp"/>
</CryptographicKeys>
<InputClaims/>
<OutputClaims/>
<UseTechnicalProfileForSessionManagement ReferenceId="SM-Saml-issuer"/>
</TechnicalProfile>
<!-- Session management technical profile for SAML based tokens -->
<TechnicalProfile Id="SM-Saml-issuer">
<DisplayName>Session Management Provider</DisplayName>
<Protocol Name="Proprietary" Handler="Web.TPEngine.SSO.SamlSSOSessionProvider, Web.TPEngine, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null"/>
</TechnicalProfile>
</TechnicalProfiles>
</ClaimsProvider>
- UserJourneyを定義する
- この辺は通常のカスタムポリシーと同じです
- RelyingPartyの定義を行う
- 公式ドキュメントだとSAML SPに関するパラメータはAzure AD B2Cにアプリケーション定義を作ってマニフェストで設定する、ということになっていますが、Azure ADとB2Bとして連携する場合は、ちょっと工夫が必要です（後述します）
Azure AD側の設定
Azure ADの直接フェデレーションの設定を行います。
- プロトコルはSAMLを選ぶ
- IdPのドメイン名はSAML IdPの認証エンドポイントと同一ドメインである必要があるため、Azure AD B2Cのドメイン名（～.b2clogin.com）を指定する
- 上記でAzure AD B2Cの設定が上手くいっていればSAML Metadataのダウンロードが出来るようになっていますので、保存したMetadataをアップロードして解析を行う
直接フェデレーションの設定画面。ここで「新しいSAML/WS-Fed IdP」を選びます。
こんな感じで設定します。
設定としては非常にシンプルです。
ただ、何点かクセがありますので、その部分を重点的に書いておきます。
設定のポイント
Azure AD B2Cのアプリケーション設定
- ドキュメントを見ると、Azure AD B2Bと直接連携するためには以下の情報を設定する必要があることがわかります。
- AssertionConsumerService
- https://login.microsoftonline.com/login.srf
- Audience（日本語ドキュメントだと「対象ユーザー」となっていますが。。。SAML SPのEntityIDのことです）
- urn:federation:MicrosoftOnline
- しかし、現状のAzure AD B2Cのアプリケーション登録ではカスタムスキームのAudience（urn:federation:MicrosoftOnline）をマニフェスト編集をしても登録することが出来ません。
- ということで、SP（Azure AD）のMetadataを作って適当なところ（今回はbob）にアップロードし、カスタムポリシーから参照する形をとります。
こんな感じです。
<RelyingParty>
<DefaultUserJourney ReferenceId="SI_SAML_SAMPLE" />
<TechnicalProfile Id="PolicyProfile">
<DisplayName>PolicyProfile</DisplayName>
<Protocol Name="SAML2"/>
<Metadata>
<Item Key="PartnerEntity">https://nfpoccontent.blob.core.windows.net/root/aad_sp_meta.xml</Item>
手動で作ったSP Metadataはこんな感じです。単純にEntityIDとエンドポイントさえ書いてあれば最低限はOKです。
<?xml version="1.0"?>
<md:EntityDescriptor
xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata"
xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
entityID="urn:federation:MicrosoftOnline"
validUntil="2031-12-31T00:00:00.000Z">
<md:SPSSODescriptor
protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol">
<md:SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect" Location="https://login.microsoftonline.com/login.srf"/>
<md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="https://login.microsoftonline.com/login.srf" index="0"/>
</md:SPSSODescriptor>
</md:EntityDescriptor>
Azure AD B2CのSAML Metadata
- 一応ドキュメントを漁ると出てくるのですが、見落としがちなので書いておきますが、以下のルールでMetadata URLが生成されます。
- https://ドテナント名.b2clogin.com/テナント名.onmicrosoft.com/B2C_1A_ポリシー名/Samlp/metadata
Azure AD B2CからAzure ADへ渡す属性（SAML AssertionのAttributeStatement）
- ドキュメントを見るとnameidがpersistentであること、emailaddressを属性として渡すこと、とありますので、それに合わせてAzure AD B2CのRelyingParty設定を行います。具体的にはOutputClaimsの設定です。
- また、標準的なAzure AD B2CのSAML設定だと結構冗長な感じでAttributeStatementが書かれるので、TechnicalProfileのMetadataにSaml11AttributeEncodingInfo（Saml20～でもOK）を指定することで少しすっきりします。
こんな感じのRelyingParty定義になります。
<RelyingParty>
<DefaultUserJourney ReferenceId="SI_SAML_SAMPLE" />
<TechnicalProfile Id="PolicyProfile">
<DisplayName>PolicyProfile</DisplayName>
<Protocol Name="SAML2"/>
<Metadata>
<Item Key="PartnerEntity">https://nfpoccontent.blob.core.windows.net/root/aad_sp_meta.xml</Item>
<Item Key="Saml11AttributeEncodingInfo">
<![CDATA[
<saml:AttributeStatement xmlns:saml="urn:oasis:names:tc:SAML:1.0:assertion">
<saml:Attribute AttributeName="emailaddress" AttributeNamespace="http://schemas.xmlsoap.org/ws/2005/05/identity/claims">
<saml:AttributeValue>
</saml:AttributeValue>
</saml:AttributeStatement>]]></Item>
</Metadata>
<OutputClaims>
<OutputClaim ClaimTypeReferenceId="objectId" PartnerClaimType="objectId"/>
<OutputClaim ClaimTypeReferenceId="b2cmail" PartnerClaimType="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress" />
</OutputClaims>
<SubjectNamingInfo ClaimType="objectId" ExcludeAsClaim="true"/>
</TechnicalProfile>
</RelyingParty>
</TrustFrameworkPolicy>
※この辺りは早くAzure AD B2Cがカスタムドメインをサポートしてくれないと実利用するには辛いですね。
いざ、動作確認
設定はこれでおしまいです。しかし、あくまでこれはAzure AD B2Bにおける「外部ユーザの招待において独自のパスワードを払い出さずに済ませるための機能（これ重要）」なので、あらかじめユーザを招待しておく必要があります。
ここは通常の招待と同じなので詳細は割愛しますが、Azure AD B2Cのドメインと同じドメインのユーザを指定して招待する、というところがポイントです。
つまり、メールは届きません。（少なくともb2clogin.comを使っている限り、一般人はこのドメインでメールは届かないと思います）
ただ、招待されている状態であれば招待元のアプリケーションにアクセスすれば招待の承認と同じことが起きますので、運用でカバーです。
そして、これも公式ドキュメントに記載されていますが、現状B2Bの直接フェデレーションはマルチテナントアプリケーションでのホームレルムディスカバリが使えないので、招待元ディレクトリのテナントIDやドメイン名が明示的に指定されているアプリケーションしか動きません。
例えば、
- https://myapps.microsoft.comはダメ
- https://myapps.microsoft.com/?tenantid=xxxxxxxxはOK
という感じです。
ここまで行けば、冒頭に動画で紹介した動きが再現できるはずです。
ちなみに動画内では条件付きアクセスを使ってゲストユーザの初回ログイン時に利用規約に同意させる様にしています。
カスタムドメイン単位でのフェデレーションと何が違うのか？
ここで疑問が出てくるのが、元々Azure ADにはカスタムドメイン単位で外部のSAML/WS-FederationのIdPと連携する機能があります。ちょっと前に多くの企業がAD FSをオンプレにおいてOffice365とSSOをやっていた構成ですね。
もちろんこのケースは社内ユーザを想定した話ですが、技術的に言うとB2Bの直接フェデレーションとほぼ変わりません。
ただ、細かく見るとちょっとずつ違います。
非常に雑な比較ですが、こんな感じです。
ということで、実用的かどうかはユースケース次第というところですが、日々色々な機能が拡張されてきているな、というところです。
もちろんこのケースは社内ユーザを想定した話ですが、技術的に言うとB2Bの直接フェデレーションとほぼ変わりません。
ただ、細かく見るとちょっとずつ違います。
非常に雑な比較ですが、こんな感じです。
| カスタムドメインのID連携 | B2Bの直接フェデレーション | |
|---|---|---|
| フェデレーション単位 | ドメイン単位 | ドメイン単位 |
| ユーザの管理 | あらかじめ作成が必要（Azure AD Connectでの同期など） ImmutableIdでのマッチング | あらかじめ招待が必要 メールアドレスでのマッチング |
| アプリケーションの制限 | マルチテナントでも可 また、WS-Fedでwindowstranportエンドポイントの整備などの条件を満たせばWindows 10 PCログオンも可（Webサインイン設定不要） | マルチテナントアプリは不可 当然Windows 10 PCログインには使えない |
ということで、実用的かどうかはユースケース次第というところですが、日々色々な機能が拡張されてきているな、というところです。
投稿
