[Windows 10/Azure AD]ハイブリッド環境におけるドメイン参加とシングルサインオン①

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

Azure Active Directory（Azure AD）に参加したWindows 10デバイスでのデバイス・サービス間のシングルサインオンの仕組み（Microsoft Passport）については、これまでもidconや本ブログなどでも解説をしてきました。

　[Windows10]デバイス＆サービス間のシングルサインオンの仕組み
　　http://idmlab.eidentity.jp/2015/05/windows10.html
　[FIDO/Windows10]idcon vol.20（別名fidcon）が開催されました
　　http://idmlab.eidentity.jp/2015/05/fidowindows10idcon-vol20fidcon.html


しかし、現実のエンタープライズ・シナリオでは一気にAzure ADへPCを参加させて、クラウドだけで生きていく、ということは考えにくく、まずは現存のオンプレミスのドメインとWindows 10をどうやって組み合わせて活用していくのか？が焦点になっていくものと思われます。

と、いうことで今回はオンプレミスのドメインにWindows 10のPCを参加させて、Azure ADと連携することで得られる利点について解説していきたいと思います。いわゆるハイブリッドID基盤をWindows 10を使うことで更に活用できますよ、というシナリオです。

ちなみに、やれることは単純にデバイスへのログインと社内アプリ、社外アプリへのシームレスなログイン（シングルサインオン）ですが、この環境を実現するためのシナリオとしては複数の方法があります。

１）AD FSを構築してAzure ADとID連携する方法
　現在も主流となっているオーソドックスな方法です。PCはあくまでオンプレのAD DSに参加、ログインをして利用しますので、社外で利用する場合は社内ネットワークへVPN接続するか、Web Application Proxy（WAP）を用意してForm認証する必要があり、AD FSがダウンすると全滅するという弱点がありました。

２）Azure AD WAPを使う方法
　上記１のパターンと似ていますが、PCはAzure ADに参加して社内アプリへのアクセス時だけAzure AD WAPを使うため、可用性の面では改善されたものの、社内にいても社内アプリケーションへのアクセスはあくまでAzure AD WAP経由となるため、ファイルサーバなどの非Webアプリケーションへの対応ができない、など機能面で現実的な選択ではありませんでした。

３）Windows Server 2016のAD FSを使い、Microsoft Passport for Workを利用する方法
　おそらく今後の本命になると思います。社外はAzure ADを使ったMicrosoft Passport、社内はMicrosoft Passport for Work、社内外のつなぎはAzure ADとAD FSの連携という形になるので、オンプレのAD DSに参加したPCでもAzure ADに参加したPCでもシームレスに社内外のアプリケーションを利用できます。非WebアプリケーションについてもMicrosoft Passport for Workではカバーする予定らしいので、そうなると無敵です。弱点は基盤構築が超面倒なところですかね。SCCMとかIntuneとかのMDMが必要になりそうです。

４）Azure AD Connectを使いMicrosoft Passportに使うデバイス情報をオンプレ・クラウド間で同期する方法
　今回紹介する方法です。PCはオンプレのADへ参加するので従来通り社内リソースは統合Windows認証で利用し、社外アプリケーションはAzure ADとMicrosoft Passportで利用する形をとります。認証する局面においてクラウド・オンプレの間で連携がないので、完全に環境を切り離すことが可能なので、可用性はあんまり気にしなくても良いのが利点です。ただ、この後解説しますが現状はちょっと環境を選びます。


では、さっそく解説します。

◆実現すること
おさらいですが、以下を実現します。
・ドメイン参加したWindows 10 PCがAzure ADと連携されているアプリケーションへSSO（PCログインとアプリログインのSSO）できるようにする
・社内ファイルサーバなどへのログインは従来通り統合Windows認証を利用
　※つまり、Windows Server 2016のAD FSを使ったMicrosoft Passport for Workシナリオではありません。
・社外アプリ（Azure AD連携アプリ）へのログインはMicrosoft Passportを利用

◆前提および制限事項
実現するためには以下の前提や制限があります。
・Azure ADとAD DSはAzure AD ConnectでID同期を行っている
・Azure ADとAD DSはフェデレーションしていない（AD FSを使っていない）
・Azure ADとAD DSの間はパスワードハッシュ同期を行っている
・PCはWindows 10（TH2以降）
・ドメインコントローラはWindows Server 2012R2以降
・オンプレドメイン名とAzure ADドメイン名は同一であること
　（Azure AD ConnectでメールなどUPN以外の属性でオブジェクト・マッチングをするとNG。代替UPNでも良いので同一UPNが必要）
・実際にデバイスがAzure ADに登録されるまでには結構時間がかかります。（ログイン、Azure AD Connectによる同期、ログインの順で処理が走るので、同期の前後でログインをする必要があります）


◆準備作業
まず、準備として以下の2点を行います。
１．クライアントPCが自動的にデバイス登録（Workplace Join）を行うためのタスクの有効化

　グループポリシーの設定を行います。
　Windows Server 2016のドメインだと、
　　コンピューターの構成
　　　⇒ポリシー
　　　　⇒管理用テンプレート
　　　　　⇒Windowsコンポーネント
　　　　　　⇒デバイスの登録
　から「ドメインに参加しているコンピューターをデバイスとして登録する」を有効にします。
　※2012 R2サーバだと、「社内参加（Workplace Join）」という名前の項目になっています。

　このポリシーを有効にすることで、クライアントPCにユーザがログインしたタイミングでデバイスを登録するためのタスクスケジューラ（dsregcmd.exe）が起動するようになります。
　（このあたりの細かい動きは次回解説します）


２．有効化されたタスクがAzure AD DRSのドメイン、テナントを解決するためのエントリ（SCP：Service Connection Point）をAD DS上に登録

　１の作業で有効化したタスクがデバイスを登録する先となるAzure ADのサービス名（ドメイン名およびテナントID）をAD DS上に登録する作業です。
　実際の作業としてはAzure AD Connectに含まれるPowerShellのコマンドレット「Initialize-ADSyncDomainJoinedComputerSync」を実行することになります。

　こんな感じです。

　これを行うと、CN=62a0ff2e-97b9-4513-943f-0d221bd30080,CN=Device Registration Configuration,CN=Services,CN=Configuration,DC=example,DC=comにazureADNameとazureADIdという二つの情報が登録されます。先のタスクスケジューラはこの値を見てデバイス情報を登録する先のAzure ADを判別します。
　※ちなみに、Azure ADのディレクトリ内に複数のドメインが存在する場合、意図しないドメイン名が登録されてしまうことがありますので、その場合は直接AD DS上の値を修正する必要がありそうです。（これが原因かどうかはわかりませんが、うまく動かないことがありました）

◆PCをドメインに参加させ、ドメインユーザでログイン、そして同期する
ここは特に何もいりません。通常の手順です。

ただ、グループポリシーが正常に適用されると「Automatic-Device-Join」というタスクが自動的に実行されているはずです。

結果、いくつかのことが発生します。

まずは、初回ログインの際、ドメインに登録されたコンピュータオブジェクトのuserCertificate属性に証明書がセットされます。（タスクの中で自己証明書を発行します）

このあとAzure AD Connectでデバイス情報の同期を行います。Azure AD Connectの同期ルールを見るとuserCertificateに値が入っていないとAzure ADへコンピューターオブジェクトを同期しないので、この段階で初めて同期対象となるためです。

同期されるとAzure AD上にデバイスが登録されます。登録状態はGraph Exploreで確認するしか方法がありません。

そして、再度ドメインユーザでログインします。
するとAzure AD上に登録されたデバイスとログイン時に実行されるタスクによる登録要求の突合が行われ、Microsoft Passportに必要なKey Registration Serviceエンドポイントでの認証に必要なクライアント証明書がダウンロードされます。
この後、Windows 10はキーペアを生成し、秘密鍵をTPMに、公開鍵をKey Registration Serviceへ登録し、Microsoft Passportのデバイス登録フェーズが完了します。

次回Azure ADへログインする際はTPM上の秘密鍵で署名したリクエストによりPrimary Refresh Token（PRT）が取得できるので、そのあとは必要なアクセストークンを取得してアプリケーションを利用、という流れでシングルサインオンが実現します。

この際、ユーザのアカウント設定のページにはAADTokenBrokerが発現、紐づけられたAzure AD上のアカウント情報が表示されます。

◆Azure ADと連携したアプリケーションへアクセスする
ここまで来れば、これまで紹介したものと同じです。
アクセスパネルにアクセスするとAzure ADでのログインを求められることなく、アクセスできます。

かなりややこしいフローになるため、次回は少し深いところの仕組みを解説し、なぜこのような動きをするのか？を解説したいと思います。

[AD FS]連携アプリケーション毎に対応するIdPへ自動振り分けを行う

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

AD FSを使ってアプリケーションとのID連携を行う場合、基本はビルトインのActive Directoryでの認証および属性の提供を行うことになりますが、アプリケーションが増えてきたり、複数の企業でAD FSを使ったりし始めると、AD FSをHUBのように使いたくなってきます。
（他にもプロトコルの変換を行うために使うケースなんかでもHUB的にAD FSを使いたくなります。例えばアプリケーションがws-federationにしか対応していなくて、IdPがSAMLにしか対応していないような場合とかですね。Windows Server 2016のAD FSではOpenID Connectにも対応してくるので、OpenID Connectにしか対応していないアプリケーションをSAMLしかしゃべれないIdPに統合するケースなど、AD FSをHUBとして使うケースも出てくるかもしれません）

そんな場合、AD FSに登録するIdP（Claim Provider）が複数になってしまいますので、利用者自身がどのIdPを使うのかを選択する必要が出てきます。（少なくとも初回は。2回目以降はCookieでブラウザに記憶されます）

AD FSに複数のClaim Providerが設定されているケースです。
下の画面ではビルトインのActive DirectoryとAzure ADを設定しています。

この環境でアプリケーションからAD FSにリダイレクトされるとIdPを選択する画面が表示されます。
これをHome Realm Discovery（HRD）と呼びます。

これって結構面倒くさいですよね。
利用者が間違ったIdPを選択してしまうと一旦Cookieをリセットしてもらって、、、ということにもなりますのでサポートしなければならない情報システム部門からすると非常に頭の痛い問題にもなりかねません。


ということで、例えば絶対に特定のIdPでしか認証させないアプリケーションであれば選択画面（HRD画面）をスキップして直接IdPへリダイレクトさせたいのですが、そういう場合はAD FSに少々設定を行うことで実現可能です。

具体的にはAD FSのPowerShellコマンドレッド「Set-AdfsRelyingPartyTrust」を使って対象のRelying Party（アプリケーション）が指定したClaim Provider（IdP）のみを使うように設定を行います。

構文は以下の通りです。

AdfsRelyingPartyTrust -TargetName <アプリケーション名（RP名）> -ClaimsProviderName <IdP名>

尚、複数のIdPを指定したい場合は、@("AAA","BBB")という形で配列を指定することで対応できます。

詳細は以下のURLにありますので、参考にしてください。
　https://technet.microsoft.com/en-us/library/dn280950.aspx


早速設定してみます。WLSという名前のアプリケーションはAzure ADのみを使って認証する、という設定です。

この状態で先ほどのアプリケーションに再度アクセスしてみます。
（Cookieをクリアしてからアクセスするのをお忘れなく）

選択画面（HRD）が出ずに直接Azure ADへリダイレクトされました。
これで多少なりとも混乱を防ぐことが出来ると思われます。


尚、間違えてClaim Providerを制限しすぎてしまったので元に戻したい、という場合は先と同じコマンドレットに他のClaim Providerを指定してあげれば大丈夫です。

[告知]2月はJapan ComCampでAzure ADとWindows 10の話をします

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

先日告知させていただきました通り、今月（1月）は日本ネットワークセキュリティ協会（JNSA）のアイデンティティ管理WGの10周年記念イベントで「ID管理プロジェクトの進め方」について解説させていただきますが、2月は少し毛色を変えてAzure ADとWindows 10についてJapan ComCamp powered by MVPというイベントでお話しさせていただきます。

　イベントサイト：
　　　https://technet.microsoft.com/ja-jp/mt637807


国内の各拠点で同時に開催されるイベントでMicrosoft MVPが中心になって企画・運営をしているらしいです。

私はなぜか東京会場に呼ばれましたので、大阪ではなく東京で登壇させていただきます。

まだ内容は全然考えていませんが、以下がセッション概要です。

タイトル：
　Azure ADとWindows 10によるドメイン環境の拡張
内容：
　クラウドやモバイルを活用しようとすると、例えばPCへのログインだけで社内のアプリケーションへシングルサインオンできたり、グループポリシーでデバイスの制御を行う、といった従来の社内ドメイン環境でできていたことが不可能になってきています。
しかし、Windows 10とAzure AD/Intuneを活用することで従来のドメイン環境に近い利便性や管理レベルを維持しつつクラウドを利用することができるようになってきています。
本セッションではクラウド・モバイルをセキュアに利用するためのAzure ADやIntune、Windows 10の上手な活用方法を紹介します。


もちろん他の会場も含め興味深いセッションも多数あるようなので、ぜひ登録してみてください。
ちなみにストリーミングもやるそうです。

[AD FS]JavaアプリSPとSAML Artifact Bindingで連携する際の証明書ストア

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

小ネタです。
JavaでSAML SPとなるアプリケーションを開発した場合のSP⇒IdP間のバックエンド通信に使う証明書の登録に関するTIPSです。

◆SAML Arifact Bindingとは？

まず、SAML Artifact Bindingの通信フローのおさらいです。
簡単に言うと、POST Bindingではユーザのブラウザを経由してSAML AssertionをIdPからSPに渡すのに対して、Artifact Bindingでは認証後Artifactと言われるコードをユーザのブラウザを経由してSPへ渡し、SPはブラウザより受け取ったArtifactをIdPへ渡してSAML Assertionと交換する、という仕組みです。
ややこしいので、SPとIdPの間で直接の通信が行われるタイプのBindingと覚えておいてください。
OAuthやOpenID Connectがわかる人は、Code Flowと同じ考え方と理解すると早いかもしれません。

こんなイメージです。

昔はガラケーなどブラウザで扱えるデータサイズの問題があったので、SAML Assertionそのものをブラウザ経由でPOSTするのではなく、比較的サイズの小さいArtifactを使ってID連携をする必要があったのですが、最近は通信速度や端末性能の向上により、Artifact Bindingが使われることは減ってきています。SPとIdPの間で直接通信をさせなければならないので、クラウドサービスと社内IdPを連携させる場合などの通信の取り回しなども非常に面倒、というのも使われなくなってきた一因です。

ただ、今でもたまにArtifact Bindingしか使えないSAML SPが存在するので、仕方なく実装することがあります。（AD FSではArtifact Bindingをサポートしています。尚、Azure ADはPOST BindingのみなのでArtifact Bindingは使えません）


◆SPとIdP間のSSL通信に使う証明書の信頼設定

先述の通り、POST Bindingではすべての通信がブラウザを介して行われるため、SSL通信に使う証明書のチェックについてはブラウザが信頼している証明書であればなんの問題もありませんし、最悪オレオレ証明書でもユーザが警告を無視してくれさえすれば、ID連携することが可能でした。

しかし、Artifact BindingではSPとIdPの間でSSL通信をエラーなく成立させる必要があるので、SPがSSL通信に使う証明書を信頼している必要があります。

信頼をするための方法はミドルウェアによりさまざまで、例えばsimplesamlphpでは設定ファイルに通信で使う証明書が入っているストアを直接指定する、などの方法をとります。

今回は前回のポストで使ったWebLogic上にデプロイしたJavaアプリケーションの場合のTIPSです。
WebLogicが信頼する証明書ストアはサーバの構成よりキーストアの設定で設定・確認することが出来ます。

初期状態では、デモ用のキーストアおよびJava標準のキーストアが設定されていますので、このキーストアのどちらかにIdPがSSL通信で使う証明書がインストールされている必要がある、ということになります。

今回はAD FSをIdPとして使ったので、AD FSがSSL通信で使っている証明書をExportしてWebLogicが使うキーストアにインストールします。

まずは、AD FS管理コンソールより証明書を開き、Service Communicationに設定されている証明書を開き、DER encoded binary X.509（cer）形式でエクスポートします。

エクスポートしたcerファイルをSPにコピーし、以下のコマンドを実行して証明書ストアへインストールします。

keytool -keystore <ストアのファイル名> -importcert -file <証明書ファイル名>

こんな感じです。

これで、無事にSP⇒IdP間でSSL通信が成立するので、SAML Assertionの受け渡しが行えるようになります。

[AzureAD/Java]WebLogic/JavaアプリケーションとAzure ADを連携する

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

先日マイクロソフトの寺田さんがJavaアプリケーションでActive Directory Authentication Library for Java（ADAL4J）を使うコードをgithubに公開されていましたので、私はちょっと違う方法で。


エンタープライズでJavaを使ったWebアプリケーションを開発する場合、WebLogicやWebSphere、JBossなどの商用アプリケーション・サーバ上にデプロイするケースが殆どだと思います。

このような環境下だとアプリケーションの単位でADALを使って個別に連携するよりも、アプリケーション・サーバのレイヤでAzure ADと連携させてしまった方がメリットがある場合があります。特にアプリケーションのロジックとアイデンティティ基盤を完全に分離できるので、既存アプリケーションの修正が不要となる点や同一アプリケーション・サーバ上にデプロイされているアプリケーションであれば、アプリケーション毎に設定を行う必要がない点は大きなメリットと言えます。
（ASP.NETのアプリケーションを書くときに、IISサーバをドメイン参加させて統合Windows認証が使うのか、アプリケーション単位で認証ロジックを書くのか、の違いによく似ています）

今回、WebLogicをSAML SP（Service Provider）として構成し、Azure Active Directory（Azure AD）と連携させる環境を作ってみました。

おそらくエンタープライズ屋さんであれば自宅の仮想環境にOracle DBとWebLogicの環境の一つや二つ遊んでいると思うので、ぜひ試してみてください。


早速やってみます。

１．Azure ADでアプリケーションを作成する

　まずは、Azure AD側に連携するためのアプリケーションの設定を行います。Azure AD Premiumエディションを持っていれば、ギャラリーからカスタムのSAMLアプリケーションを追加できるので、今回はこちらを使っています。

　アプリケーションの追加を行います。

　アプリケーションが追加できたら、シングルサインオンの設定を行います。

　Microsoft Azure ADのシングルサインオンを選択します。

　アプリケーション設定の構成で以下を設定します。
・識別子：
　後でWebLogicに設定するSP Entity IDのURIを設定します。単なる識別子なので実際にアクセスできる必要はありません。
・応答URL：
　同じく後で設定するSAML AssertionのPOST先URLを設定します。こちらは実際にSAML AssertionをPOSTするので、クライアントがアクセスできるURLである必要があります。

　SAML Assertionの署名に使う証明書のダウンロードを行います。この証明書をSP（WebLogic）が知っている必要がありますので、後程FederationMetadataに埋め込んでアップロードします。

　WebLogicにIdP（Azure AD）の情報（エンドポイント、署名に使う証明書の情報など）を設定するためのFederationMetadataを作成します。
　まずは、元となるFederationMetadata.xmlをAzureよりダウンロードします。アプリケーション一覧の画面から[エンドポイント]を開くとFederationMetadata.xmlのURLが確認できるので、ブラウザでアクセスしxmlファイルを保存します。

　実は、ダウンロードしたFederationMetadata.xmlはそのままでは使えません。
　理由は、以下の2点なので、修正します。
　・ws-federation関係の情報が含まれている
　・アプリケーション用の証明書の情報が含まれていない

　先にダウンロードした証明書ファイルをメモ帳などで開き、実体部分をコピーし、FederationMetadata.xmlのX509Certificateのデータを書き換えます。

　同時に、ws-fedやRoleDiscripterなど不要なエレメントをすべて削除します。結果以下のようなxmlファイルが出来上がります。

　とりあえずここまででAzure AD側の設定は一旦終了です。



２．WebLogicの設定

　今度はWebLogic側の設定を行います。ざっと概要を説明すると大きくは次の3点を設定する必要があります。

①セキュリティ・レルムの設定
　連携するSAML IdP（ここではAzure AD）の参照設定を行います。
②サーバのSSLの有効化
　Azure ADは応答先URLにHTTPSしか設定できないので、WebLogic側のSSLエンドポイントを有効化します。
③サーバのフェデレーション設定
　WebLogicドメイン上のサーバをSAML SPとして設定します。


　順番に設定をしていきます。

①セキュリティ・レルムの設定
　WebLogicの管理コンソールで、ドメイン構造から[セキュリティ・レルム]を開き、レルム一覧から[myrealm]を開きます。

　[プロバイダ]から[認証]タブを開き、認証プロバイダを追加していきます。

　認証プロバイダの名前に任意の名前を、タイプに[SAML2IdentityAsserter]を設定します。

　認証プロバイダを作成後、一旦管理サーバを再起動します。

　その後、先ほど作成した認証プロバイダにAzure AD側の設定を入れていきます。作成した認証プロバイダを開き、[管理]タブを開き、アイデンティティ・プロバイダ・パートナーを新規作成します。この際、[新しいWebシングル・サインオンのアイデンティティ・プロバイダ・パートナー]を選択します。

　作成後、先ほど作成したAzure ADのFederationMetadata.xmlを読み込ませることでほぼ自動で設定ができます。

　作成が完了した後、有効化およびリダイレクトURL（このURLにマッチしたらIdPへリダイレクトする）を設定します。

　今回、あとでデプロイするアプリケーションのパスが/WebApp/となるので、今回は/WebApp/*を設定しています。

　ここまででセキュリティ・レルムの設定は完了です。次はサーバ設定です。
　今回は管理サーバ上にアプリケーションをそのままデプロイしていますが、実環境では管理サーバとは別に被管理サーバを作成すると思うので、実環境の場合はそちらに対して設定します。


②サーバのSSLの有効化

　[構成]、[サーバー]より対象のサーバを開き、SSLリスニング・ポートの有効化とポートの設定を行います。

③サーバのフェデレーション設定

　次に、ようやくSAML SPとしての構成を行います。
　サーバを開き、[構成]、[フェデレーション・サービス]、[SAML2.0サービス・プロバイダ]を開き、以下の設定を行います。
・有効：チェック
・アーティファクト・バインドの有効化：チェックなし
・優先バインド：POST
・デフォルトURL：アプリケーションのURL

　次にSAML同じく[SAML2.0全般]タブを開き、以下の設定を行います。
・公開サイトのURL：
　先にAzure ADに設定したSAML AssertionのPOST先（のパスの一部。/saml2まで）
・エンティティID：
　先にAzure ADに設定したアプリケーションの識別子
※他の情報（連絡先など）は任意です。

　ここまででWebLogic側も設定は終わりです。ようやくアプリケーションの作成とデプロイです。


３．アプリケーションの作成

　ここではEclipseを使って単にユーザ名を表示するだけのjspを作っていますが、むしろ大切なのはweb.xmlおよびweblogic.xmlに記載するセキュリティ設定です。

index.jspのソース。
単純にgetRemoteUser()でユーザ名を取得して表示しているだけです。

<%@ page language="java" contentType="text/html; charset=ISO-8859-1"
    pageEncoding="ISO-8859-1"%>
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
<title>Test Application</title>
</head>
<body>
    <h1>My Test App</h1>
    <h4>Hello <%= request.getRemoteUser() %></h4>
</body>
</html>

web.xml
・security-constraintで/*（アプリケーション全体）を保護対象としています。
・auth-constraintで対象領域にはAdminおよびUserロールに属しているユーザのみがアクセスできるようにしています。
・security-roleでAdminおよびUserロールを定義しています。

<?xml version="1.0" encoding="UTF-8"?>
<web-app xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://xmlns.jcp.org/xml/ns/javaee" xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee http://xmlns.jcp.org/xml/ns/javaee/web-app_3_1.xsd" id="WebApp_ID" version="3.1">
  <display-name>WebApp</display-name>
  <welcome-file-list>
    <welcome-file>index.jsp</welcome-file>
  </welcome-file-list>
  <security-constraint>
    <display-name>Protected Area</display-name>
    <web-resource-collection>
      <web-resource-name>Protected Area</web-resource-name>
      <url-pattern>/*</url-pattern>
    </web-resource-collection>
    <auth-constraint>
      <description></description>
      <role-name>Admin</role-name>
      <role-name>User</role-name>
    </auth-constraint>
  </security-constraint>
  <security-role>
    <role-name>Admin</role-name>
  </security-role>
  <security-role>
    <role-name>User</role-name>
  </security-role>
</web-app>

weblogic.xml
Security Role AssignmentでAdminロールに[nfujie]というPrincipalを割り当てています。
（このPrincipalがAzure ADから発行されるSAML AssertionのName Identifierの値と一致していればAdminロールが割り当たります）

　これでアプリケーションは完成ですので、デプロイします。
　今回はwarへデプロイしてWebLogicへインストールしていきます。

　まず、アプリケーションのプロジェクトを右クリックしてExport、WARを選択します。
　出力先のファイル名、ターゲットランタイムにWebLogicを選択してFinishをクリックします。

　続いてWebLogicの管理コンソールの[デプロイメイント]より[インストール]を行います。

　エクスポートしたwarファイルを指定し、次へ進めます。

　これでデプロイは完了です。


４．ユーザの割り当てとName Identifier属性の設定

　早速アプリケーションへアクセスしていきたいところですが、Azure ADにアプリケーション連携設定を作成した場合、対象アプリケーションにアクセスさせるユーザの割り当てを行っておく必要があります。

　また、先にアプリケーション（weblogic.xml）に設定したPrincipalと同じ値がAzure ADから発行されるようにSAML Assertion上の属性のマッピングを行う必要があります。

　まずは、ユーザの割り当てです。
　管理ポータルよりアプリケーションを開き、[ユーザおよびグループ]（Premium/Basicの場合。無償版の場合は[ユーザ]）よりアクセスさせたいユーザに割り当てを行います。

　次に属性の編集です。
　同じく管理ポータルより[属性]を開き、SAML Assertionの編集を行います。
　今回、割り当てたユーザがnfujie@pharaoh.onmicrosoft.comなのでそのままだとName Identifierにはnfujie@pharaoh.onmicrosoft.comが値として入ってしまいますが、WebLogicは単にnfujieという値を期待しているので、ドメインパートを削ってあげます。
　そのためにはExtractMailPrefix()という関数を使って値の成型をする必要がありますので、nameidentifier属性を開き、以下のように設定を変更して保存を行います。

　これで本当にすべて完了です。早速アクセスしてみます。

まずは、アプリケーションのURLへアクセスします。
https://wls:7002/WebApp/

するとAzure ADのログイン画面が出てくるので、先ほど割り当てたユーザでログインします。

うまく認証が完了すると、アプリケーションが開き、ユーザ名が取得できていることがわかります。

いかがでしたでしょうか？
ちなみに今回はユーザ名のみの取得でしたので、設定のみで連携させましたが、Assertion上の他の属性をWebLogic上のユーザ属性とマッピングさせるためにはカスタムの属性マッパークラスを実装することで対応が可能となります。
この辺りは別の機会にでも。