IdM実験室: Azure AD B2B

ラベル Azure AD B2B の投稿を表示しています。すべての投稿を表示

2024年5月3日金曜日

Entra External IDがGAされています

こんにちは、富士榮です。

長らくPreviewだったEntra External ID（旧Azure AD B2B、およびCIAM）がGAされました。（といっても特にCIAMはまだまだPreviewの機能だらけなんですけどね・・・）

https://techcommunity.microsoft.com/t5/microsoft-entra-blog/announcing-general-availability-of-microsoft-entra-external-id/ba-p/3974961

個人的にポイントだと思っているのは、いわゆるワークフォースIDであるEntra ID（Azure AD）との機能面での統合が進んだこと、そしてEntra Verified IDとの連携ですね。

しかし、もうここまでくると単なるID基盤という枠には収まらず、他のAzureリソースとの組み合わせを意識した統合的なアイデンティティ・プラットフォームになってきていますね。いよいよインフラとしての設計も難しくなってきてますので、ちゃんとプロ（国井さんとか）の教育を受けて使うことをお勧めします。

個人的にも気になってきたAzure AD B2Cからのトランジションについてはまだまだ情報が不足していますが、現状のCIAMの機能ではとてもじゃないけどAzure AD B2Cの自由度のカバーはできないので、まだしばらくは並行してサポートされていくことになると思います。本社の開発チームの話ではマイグレーションパスなどもゆくゆくは用意していくということなので、こちらも継続ウォッチですね。

2020年5月20日水曜日

Build速報！FacebookでAzure ADへログインする

こんにちは、富士榮です。

Buildですね。リモート開催になって日本からでも参加しやすくなって睡眠時間が削られる日々をお過ごしだと思います。

今回も色々とAzure ADに関する新機能の発表がありました。

詳しくはAlexのBlogを参照してもらえれば良いのですが、今回はAzure AD B2Bの直接フェデレーションへのFacebookログインの登場（Public Preview）の話です。

AlexのBlog）
https://techcommunity.microsoft.com/t5/azure-active-directory-identity/build-2020-fostering-a-secure-and-trustworthy-app-ecosystem-for/ba-p/1257360

Azure AD B2Bの直接フェデレーションについてはこれまでも取り上げてきましたが、Googleに対応してから約2年、ここに来てFacebookに対応しました。

Googleとの連携の件
https://idmlab.eidentity.jp/2018/08/azure-ad-b2bgoogleid.html

カスタムドメイン vs 直接フェデレーションの件
https://idmlab.eidentity.jp/2020/05/azure-adbyoid.html

もはやB2Bとは？というしかない状態なのですが、早速触ってみましょう。

外部アイデンティティプロバイダの設定

これまでも紹介したことのある画面です。Azure ADのポータルを開き、External Identitiesメニューから「すべてのIDプロバイダー」を開くと「Google」に加えて新たに「Facebook」が選べるようになっています。

ここでFacebookを追加して、AppIdとAppSecretを追加すれば基本は終わりなのですが、設定前に外部ユーザによるサインアップを許可しておく必要があります。
「外部コラボレーションの設定」メニューを見ると、新しく「ユーザーフローによるゲストセルフサービスサインアップを有効にする」という設定が追加されているので有効にしておきましょう。

後はFacebook Developerコンソールで作成したアプリケーションのAppIdとAppSecretを設定すれば終わりです。

Facebook側の設定方法はAzure AD B2Cのドキュメントに記載がありますので、1点を除いてこちらをそのまま使って大丈夫です。
https://docs.microsoft.com/en-us/azure/active-directory-b2c/identity-provider-facebook

その1点とは、そうですredirect_uriです。
直接フェデレーションの場合にFacebookに設定するredirect_uriはどうなるのか？というと、
https://login.microsoftonline.com/te/{テナントID}/oauth2/authresp
となります。

ここまで設定を進めると、ユーザーフローからAzure ADにアクセスするためのアプリケーション「aad-extensions-app」が自動的に登録されます。

ちなみに、このアプリケーションを削除すると面倒なことになるので、消さないようにしてください。
万一消してしまったらAzure AD B2Cでのb2c-extension-appと同じように回復をしてください。
参考）B2Cでの回復手順
https://docs.microsoft.com/ja-jp/azure/active-directory-b2c/extensions-app

ユーザーフローの登録

外部IDプロバイダの設定が終わったら、次はユーザーフローの登録です。
基本この辺りもAzure AD B2Cと同じです。

ユーザーフローの名称（ポリシー名となります）、利用するIDプロバイダ、連携する属性を設定していきます。
尚、属性は標準で用意されているもの以外に「カスタムのユーザー属性」メニューから自分で好きな属性を追加することもできます。

これでIDプロバイダとユーザーフローの登録はおしまいです。

アプリケーションの登録

次に、先ほど作成したユーザーフローを使ってサインアップやサインインを行う対象となるアプリケーションを登録します。
ポイントは、APIのアクセス許可で「User.Read」スコープに対して管理者による同意をしておくこと、です。現状のユーザーフローでのユーザ作成やログイン時にユーザ自身による同意が上手く取れない？のでこの設定は入れておく必要がありそうです。

ユーザーフローとアプリケーションの紐づけ

アプリケーションを作成したら、先に作成しておいたユーザーフローを使う様に構成をします。
先ほどのExternal Identitiesメニューに戻り、先ほど作成したユーザーフローを開きます。アプリケーションに関する設定項目がありますので、ここで作成したアプリケーションを指定します。

これで一通りの設定は終了です。

動作確認

では早速動かしてみます。

このアプリケーションにアクセスする為には、以下のパラメータをつけてAuthorizationエンドポイント（https://login.microsoftonline.com/{テナントID}/oauth2/authorize）へアクセスする必要があります。（通常のOpenID Connectのアプリケーションと同じです）

client_id={登録したアプリのClient Id}
response_type=id_token
scope=openid
nonce={生成したnonceの値。テストなら何でもOK}
redirect_uri={登録したアプリのredirect_url}

今回、アプリケーションとしてはhttps://jwt.msを使ったのでこんなURLになります。
https://login.microsoftonline.com/{テナントID}/oauth2/authorize?client_id={クライアントID}&response_type=id_token&scope=openid&nonce=hoge&redirect_uri=https:%2F%2Fjwt.ms

実行してみると、いつものサインイン画面になるので、まずはアカウントを作成します。

アカウントの作成画面に「Facebookアカウントでサインイン」というメニューが出来ています。
ここでFacebookアカウントでサインインすると、Azure ADへのアカウント登録を行う際に追加で登録するアカウントを入力する画面が出てきます。

続行するとアカウントがAzure AD上に登録されます。
アカウントタイプはゲスト、ソースはFacebookになっているのがわかります。

ちなみに登録後、サインインする場合はサインインオプションをクリックするとFacebookログインのメニューが出ていますので、そちらを使ってサインインします。

いかがでしょうか？
基本はAzure AD B2Cの機能の一部を通常のAzure ADの直接フェデレーション向けに開放しただけなので、Azure AD B2Cに慣れている方は直感的に理解できると思います。

しかし、冒頭にも書きましたが、こうなってくると「B2Bとは？」という疑問がやはり出てきますが大人しくしておきましょう。

おまけ

たまたまテストに使ったAzure ADにG-SuiteとのSSO設定があったので、SAMLの属性マッピングの調整をちょこっとして、GmailにAzure ADの直接フェデレーションを使ってFacebookアカウントでログインする、というくだらないものを作ってみたので動画を貼っておきます。

2020年5月2日土曜日

Azure ADの外部コラボレーションとBYOID

こんにちは、富士榮です。

リモートワークで組織外の方々とのコラボレーションが大きなテーマになっている方々も多いと思いますが、そういう時は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でも出来ることが増えた、というあたりがニュースなんだとは思いますが）

https://techcommunity.microsoft.com/t5/azure-active-directory-identity/unlimited-sso-and-new-azure-ad-features-to-simplify-secure/ba-p/1257358

Azure AD B2Bの外部IdPとの直接フェデレーション（Preview）

https://docs.microsoft.com/ja-jp/azure/active-directory/b2b/direct-federation

Azure AD B2CのSAML対応（AlexはGAって言ってますが、ドキュメント上は未だPreview）

https://docs.microsoft.com/ja-jp/azure/active-directory-b2c/connect-with-saml-service-providers

とりあえず完成イメージを

言葉で説明しても伝わりにくいと思うので、どういうことが出来るようになるのか？を動画にしています。

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>

ちなみにClaimType「b2cmail」は適当に適宜した属性なので自由に定義してもらえれば良いかと思います。重要なのは、「Azure AD B2Cのドメインと同じドメイン名を持つメールアドレスが設定されていること」です。例えば、hoge.b2clogin.comというAzure AD B2Cドメインを使っている場合は、fuga@hoge.b2clogin.comという値を返す必要があります。
※この辺りは早く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の直接フェデレーションとほぼ変わりません。

ただ、細かく見るとちょっとずつ違います。
非常に雑な比較ですが、こんな感じです。

	カスタムドメインのID連携	B2Bの直接フェデレーション
フェデレーション単位	ドメイン単位	ドメイン単位
ユーザの管理	あらかじめ作成が必要（Azure AD Connectでの同期など） ImmutableIdでのマッチング	あらかじめ招待が必要メールアドレスでのマッチング
アプリケーションの制限	マルチテナントでも可また、WS-Fedでwindowstranportエンドポイントの整備などの条件を満たせばWindows 10 PCログオンも可（Webサインイン設定不要）	マルチテナントアプリは不可当然Windows 10 PCログインには使えない

ということで、実用的かどうかはユースケース次第というところですが、日々色々な機能が拡張されてきているな、というところです。

2019年5月11日土曜日

European Identity & Cloud Conference 2019でBYOID＋DIDの話をします

こんにちは、富士榮です。

昨年に引き続き今年もミュンヘンで開催されるEuropean Identity & Cloud Conferenceでお話させていただくことになりました。

公式サイト
　https://www.kuppingercole.com/events/eic2019

アジェンダを見ていると、AIとDecentralized Identity（ブロックチェーン）が半々くらいですかね。

私は昨年に引き続きBYOID（Bring Your Own Identity）のテーマでケーススタディ＋昨年シンガポールで開催されたConsumer Identity World APACで少し頭出しをしたBYOID＋Decentralized Identityのテーマで、動くものを少しお見せしようと思っています。

こんな感じの仕組みです。

外部ユーザを招待してOffice365（Teamsとか）を使ってもらうシナリオの一種ではあるんですが、通常のAzure AD B2Bでゲストの招待だとドメインのホワイトリストやTOU（Term of Use/利用規約）への同意くらいしか相手を確認する方法が無いので、その部分でDecentralized IdentityのVerifiable Claimsを使って証明書を提出させて本人確認を行う、というシナリオです。

このことにより、外部ユーザは組織アカウントでもLINEやFacebookなどの個人アカウントでのサインアップ＋証明書を提出することによりTeamsやAzure ADに参加したPCへのログインなどが出来るようになります。この辺りをAzure AD B2CやAzure Functionsなどを使って自動化をしています。
外部IDを受け入れる側の組織ではID管理やパスワード管理をする必要が全くありませんので、組織の形態にもよると思いますが使える場面も出てくると考えています。

こんなことも出来るようになります。

ちなみにID Proofing周りはOSSテクノロジー社のLibJeIDとuPortを使って実装しています。

おいおいこの辺りの話しも解説したいと思います。
（月末に開催されるde:code 2019でも触れる予定です）

2018年8月30日木曜日

[Azure AD B2B]GoogleとのID連携によりユーザの招待が簡単になりました

こんにちは、富士榮です。

Azure AD B2Bを使うと外部のユーザを招待し、組織のアプリケーションへのアクセスを付与することが出来ます。
この招待は
・Azure ADテナントを持っている組織の人
・Azure ADテナントを持っていない組織の人や個人
に対して送信することが出来、これまでAzure ADテナントを持っていない人は招待メールを受け取ったら、招待元のディレクトリにサインアップする際にログイン・パスワードを設定する必要がありました。

つまり、滅多にアクセスしない外部組織のアプリケーション専用にアカウントを作らなければならない、ということが発生するのでゲストユーザからすると非常に面倒くさい話ですし、パスワード忘れなども発生しやすいので管理上の問題も発生しやすい状況でした。

今回、Azure AD B2Bの新しく公開（現状パブリック・プレビュー）されたのが、Googleアカウントを持っている個人（G Suiteではなく、gmail.comのユーザ）を対象に、Google側の認証でAzure AD B2Bのテナントへログインできるようにする機能です。

　公式Blog）
　Azure AD B2B Collaboration support for Google IDs is now in public preview
　https://cloudblogs.microsoft.com/enterprisemobility/2018/08/28/azure-ad-b2b-collaboration-support-for-google-ids-is-now-in-public-preview/

やっていることは非常に単純でAzure ADに外部Identity ProviderとしてGoogleを設定、ゲストアカウントのドメインがgmail.comならGoogleにリダイレクトする、という仕組みです。

では、やってみましょう。
詳細は公式ドキュメントを参照してください。

◆GoogleにOAuthのクライアント登録を行う

結局のところ、Azure AD B2BがGoogleに対するOAuthクライアントとなるので、クライアント登録をしてあげる必要があります。

GoogleのDeveloper Consoleより作業を行います。
　https://console.developers.google.com/

必要な作業は、
・プロジェクトの作成
・OAuth同意画面

・OAuthクライアントの登録

の3点です。

ポイントは、OAuthクライアント登録時のリダイレクトURIの設定くらいだと思いますので、詳細は省きますが以下の通り設定を行います。

リダイレクトURIとしてセットする値

　https://login.microsoftonline.com

　https://login.microsoftonline.com/te/{Azure ADのテナントID}/oauth2/authresp

こんな感じで登録されますので、Client IdとClient Secretをメモしておきます。

◆Azure ADに外部Identity Providerを設定する

次は、Azure AD側の設定です。

ポータルからAzure ADを開くと、「Organizational relationships」という見慣れないメニューが出てきているので、こちらを開いていきます。

続いてIdentity ProvidersからGoogleを追加します。

すると、GoogleのClient IDとClient Secretを求められるので、入力して保存します。

これでおしまいです。

◆Googleアカウントを招待する

これは従来のAzure AD B2Bの操作と全く同じです。

Gmailのメールアドレスで招待するだけですね。

これで招待メールが飛んでくるのでディレクトリへアクセスします。

従来はココでゲストユーザにパスワードを登録する様に求められましたが、今回の機能を使っているとパスワードは不要なのでそのままユーザが作成されます。

上手くいくとアクセス・パネルが表示されます。

アプリケーションも使え、属性が取得できています。

ちなみに、自組織にAzure ADテナントが無いゲストユーザがアクセス・パネルにアクセスする時は、https://myapps.microsoft.com が使えません。どのテナントにユーザがいるのかが判別できない＆組織アカウントなのかマイクロソフト・アカウントなのかの判別が出来ないためです。（マルチテナントアプリケーションも同様です）

そこで、招待元のテナントを決めうちでアクセスする必要があるので、以下のように招待元ディレクトリのテナントIDをパラメータにつけてアクセスしてください。
https://account.activedirectory.windowsazure.com/r?tenantid={招待元のテナントID}

取り敢えず個人のGmailアカウントはこれで便利になりました。
ちなみにG Suiteの場合はこの機能ではなく、G SuiteをSAML IdPとして構成、ドメイン単位でのID連携を構成すれば動くはずです。（やってませんが。。また紹介します）

2018年5月8日火曜日

[Azure AD] Build 2018( #msbuild )に合わせてAzure AD PIMとTerm of UseがGA

こんにちは、富士栄です。

事前にアナウンスが合った通り、昨日より開催されているBuild 2018に合わせてAzure AD関係の以下の機能が一般リリース（GA）されました。

Privileged Identity Management（PIM）
Conditional Access - Term of Use（ToU）

公式Blogでのアナウンス
https://cloudblogs.microsoft.com/enterprisemobility/2018/04/17/password-less-sign-in-to-windows-10-azure-ad-using-fido2-is-coming-soon-plus-other-cool-news/
※主題はFIDO2の話ですが、しれっとBuildでGAされるよ！という話が書いてあります。

PIMはいわゆる特権管理ですね。Azure AD上の特権を承認を得て一時的に取得するための機能で、Azure AD Premium P2で使えます。

ToUは条件付きアクセスの条件の一つとして設定ができるもので、使用条件に同意をしないとアプリケーションを使わせない、というような条件を設定することが可能です。

こちらは以前、Azure AD B2Bのゲストユーザへの同意を求める、というシナリオで紹介しましたね。
https://idmlab.eidentity.jp/2017/12/azure-ad-b2bterms-of-use.html

他にもIdentity関連のセッションが色々と用意されているようなので、期間中に良い情報が出てくれば紹介したいと思います。

2017年12月4日月曜日

[Azure AD B2B]ゲストユーザに使用条件（Terms of Use）への同意を求める

こんにちは、富士榮です。

前回はAzure AD B2Bを使って外部ユーザを招待し、組織のアプリケーションを利用させる方法を紹介しました。

しかし、ゲストユーザを招待する際に、利用規約や使用条件などへの同意を取得したいケースが多々あると思います。

そこで、今回は現在Preview版が公開されている条件付きアクセスのTOU（Terms of Use）を使い、ゲストユーザがアプリケーションへアクセスする前に使用条件へ同意を求める、ということを実現していきます。

手順は以下の通りです。

Terms of Useを定義する
自動的に条件付きアクセスのポリシーが生成されるので、適用対象をゲストユーザに絞る
ゲストを招待、アプリケーションへアクセスさせる

◆設定してみる

早速やってみましょう。

まずは、条件付きアクセスの設定を開くとTerms of Useの設定が出来るようになっていますので、開きます。

Newをクリックして使用条件を定義します。

名称、表示名、使用条件として表示するドキュメント（PDF）、言語を設定します。また、ちゃんとドキュメントを表示させないと先に進まない様にするための設定、および自動的に条件付きアクセスのポリシーを作成させるための設定を行います。

尚、自動的にポリシー作成をさせるとゲスト以外を含む全ユーザ、全アプリケーションに対するポリシーがいきなり有効な状態で出来上がってしまうので、要注意です。ポリシーは自動作成はせずに手動の方が良いかも知れません。

ここでは自動で出来上がったポリシーを見ていきます。

条件の部分で先ほど作成したTOUが出てきています。

全員に適用されてしまっていたので、ゲストユーザだけに適用する様に変更します。All Guestという動的グループを作成してゲストユーザだけがメンバ登録されるようにしてあるので、こちらを使います。

これで、ゲストユーザだけがTOUに同意しないとアプリケーションにアクセスできない様になりました。

◆アクセスしてみる

前回の手順に則り、外部ユーザでサインアップしアプリケーションへアクセスしようとするとTOUが表示されます。

TOUを展開すると先ほどアップロードしたPDFが表示されます。

尚、一回同意すると同意済みとしてマークされるので、次回以降は同意は求められることはありません。

また同意状況については監査ログから確認することが出来ます。

Azure AD B2Bと条件付きアクセスを上手く使って外部ユーザの管理をしっかりしていきましょう。

2017年11月29日水曜日

[Azure AD B2B]アプリケーション管理者によるゲストユーザの招待

こんにちは、富士榮です。

Azure Active Directoryには無印（いわゆるAzure AD）の他に、

組織外のユーザ向けのAzure AD B2B
コンシューマ向けのAzure AD B2C

と言われるオプションというか機能があります。

Azure AD B2CについてはTech Summitなどでお話しさせていただいたり、このブログでも取り上げてきたLINEやYahoo! JAPANなどのIDを使ったサービスへのログインの話ですが、今回はAzure AD B2Bの話です。

実はOffice365を使っている方は以前からAzure AD B2Bの機能を使っていました。いわゆる外部共有（招待）の機能の事です。

この機能を使うと組織のディレクトリ内に存在しない人を招待してゲストユーザとしてディレクトリへ登録し、組織のリソース（アプリケーションなど）へアクセスさせることが可能になります。

注意して使わないと危ないよ、という話は以前書かせていただいた通りですので、一読いただけるとよいと思います。

Office365管理者は要対応。外部共有により不要なアクセス権が付与される
http://idmlab.eidentity.jp/2017/01/office365.html

本日は、Office365ではないアプリケーションを外部ユーザへ共有したい、という場合のAzure AD B2Bの使い方を紹介したいと思います。

具体的には、

外部のコンサルや開発ベンダのアカウントをアプリケーションを使わせたい
アプリケーションのSSOを構成するとAzure ADで全員を認証しないといけなくなってしまい、全ユーザがAzure AD上に登録されている必要がある
外部ユーザのID管理を管理者が行うのは面倒なので、責任範囲を明確にする意味でも当該のアプリケーションの管理者に権限委譲をしたい（Azure ADの管理者権限は渡さずに）

というようなケースを想定した使い方です。

早速やってみたいと思います。

◆必要なステップ

全体の流れとして、以下のステップで準備を行う必要があります。

[全体]招待するユーザを入れるためのセキュリティ・グループの作成
[全体]セルフサービスグループ管理の有効化
[アプリケーション単位]セルフサービスアクセス要求の有効化
[アプリケーション単位]セキュリティ・グループの割り当て

後は、アプリケーション管理者でアクセスパネルから外部ユーザを招待するとメールで招待が行き、外部ユーザがサインアップしてアプリケーションが使えるようになります。

◆設定してみる

では、早速やってみましょう。

１．[全体]招待するユーザを入れるためのセキュリティ・グループの作成

手動でメンバ管理を行うグループを作成します。

２．[全体]セルフサービスグループ管理の有効化

次に、ディレクトリのセルフサービス設定で、グループ管理を有効化します。（無効の場合は有効にします）

３．[アプリケーション単位]セルフサービスアクセス要求の有効化

次はゲストに使わせたいアプリケーションの設定で、セルフサービスアクセス要求と承認の設定を行います。ここで承認者として設定した人がアプリケーション管理者となり、ゲストを招待することが出来るようになります。

４．[アプリケーション単位]セキュリティ・グループの割り当て

後は、３で指定したグループをアプリケーションへ割り当てます。

これで準備は完了です。割とシンプルですね。

◆招待しゲストにアクセスさせる

では、早速動かしてみましょう。

まずは、アプリケーション管理者でアクセスパネル（https://myapps.microsoft.com）を開き、ゲストに使わせたいアプリケーションを選択して「アプリの管理」を開きます。

するとアプリケーションへユーザを追加することが出来るようになっているので、「＋」をクリックしてゲストを招待します。

外部ユーザのメールアドレスを入力すると招待メールの文面を入れる画面が自動的に出てきますので、何かメッセージを入れて招待を行います。

これで外部ユーザには招待メールが届きます。

「はじめに」というリンクをクリックするとサインアップ画面へ遷移します。

パスワード、表示名、国を指定してゲストユーザ登録を完了します。

メールへ確認コードが飛んでくるので確認画面で入力してアカウント確認を行います。

登録が完了すると登録したパスワードで認証が走り、アクセスパネルが表示され、アプリケーションが利用できるようになります。

今回は、アプリケーション管理者により外部ユーザをAzure AD上に招待することにより少なくとも認証は全員Azure ADを使う様に構成することが出来ました。このことで条件付きアクセスなど、アプリケーション利用ポリシーをAzure ADで一括で管理することが出来るので、セキュリティ面でも安心できると思います。

ちなみに、管理者によりゲストユーザを作成したり招待することも可能ですし、APIを使って一括で外部のディレクトリからユーザを引き込む、というようなことも可能です。（大規模なM&Aや業務提携などの場合はカスタムアプリケーションを作って自動同期をするように構成することが多いようです）

登録: 投稿 (Atom)

2024年5月3日金曜日

2020年5月20日水曜日

外部アイデンティティプロバイダの設定

ユーザーフローの登録

アプリケーションの登録

ユーザーフローとアプリケーションの紐づけ

動作確認

おまけ

2020年5月2日土曜日

とりあえず完成イメージを

Azure AD B2CのSAMLサポート

Azure AD側の設定

設定のポイント

いざ、動作確認

カスタムドメイン単位でのフェデレーションと何が違うのか？

2019年5月11日土曜日

2018年8月30日木曜日

◆GoogleにOAuthのクライアント登録を行う

◆Azure ADに外部Identity Providerを設定する

◆Googleアカウントを招待する

2018年5月8日火曜日

2017年12月4日月曜日

◆設定してみる

◆アクセスしてみる

2017年11月29日水曜日

◆必要なステップ

◆設定してみる

◆招待しゲストにアクセスさせる

IdM実験室 - 別館（MSDN/Channel9）など

Translate

ブログ アーカイブ

Twitter Updates

オススメ書籍

FIM / AD 関連リソース

Identity関連Blog

FIM/ILM関連Blog

AD FS/WIF/ACS関連Blog

Award

Award

自己紹介

登録

プライバシーポリシー

ブログアーカイブ