Uncategorized

Azure AD (Entra ID) の Common Consent Framework – Service 側

By on • ( 2 Comments )

開発者にとっての Azure Active Directory (Microsoft Entra ID)

こんにちは。

前回の投稿「Azure Active Directory の Common Consent Framework (Client 側)」で Common Consent Framework を紹介しました。投稿のタイトルからお分かりの通り、つぎに、Service 側の実装について紹介するつもりでしたが放置してましたので、続きとして記載します。

Office 365 API で例えると、Exchange Online や SharePoint Online などの Permission (Scope) を持った Service 側の構築手法です。(一方、「Azure Active Directory の Common Consent Framework (Client 側)」では、こうした Service を利用する Client 側の構築手法を紹介しました。)

 

Permission を持つ Service (Web API) の作成

今回、ある Client Application (TestClient1 とします) から Service (TestService とします) にアクセスするサンプルを構築します。

まず、いつものように Microsoft Azure Portal を使って、Microsoft Azure Active Directory (Azure AD) に Service 側 (TestService) を登録します。(手順については 前回 と同様なので省略します。今回、このサービスの App ID URI を「https://o365demo02.onmicrosoft.com/TestService」と仮定します。)
なお、このあとで、Client ID と Client Secret が必要になるので、登録したアプリケーションの [Keys] (キー) メニューを選択して、この Service の Client Secret を作成して値をメモしておきます。また、この後の動作検証のため、TestService を Multi-Tenant のアプリケーションとして設定しておきましょう。(Multi-Tenant の設定方法は 前回の投稿 を参照してください。)

では、いよいよ、この TestService に Permission を設定します。Permission 設定は、まだ専用の UI はないため、Manifest を直接 メモ帳などで編集します。
Azure AD の Application 管理の画面 (Azure Portal) で [Manifest] (マニフェスト) をクリックします。(マニフェストのエディターが表示されます。)

今回、下記の oauth2Permissions の箇所を追記してみましょう。
ここでは、テスト用の Permission を定義しており、Consent UI が表示される際の Description などを定義しています。また、Id には、新規の GUID (任意) を設定してください。(追記 : 現在、この oauth2Permissions は、Azure AD へのアプリ登録の際に自動で設定されるようになりました。下記では、その値を変更しています。)

今回、単一の Permission を設定していますが、例えば、「参照権限」、「編集権限」のように複数の Permission を定義できます。

{  "allowActAsForAllClients": null,  "appId": "737e841f-7151-4db9-a4e6-55b767cb614c",  "appMetadata": {"version": 0,"data": []  },  "appRoles": [],  . . .  "oauth2AllowImplicitFlow": false,  "oauth2AllowUrlPathMatching": false,  "oauth2Permissions": [{  "adminConsentDescription": "Allow the application test access",  "adminConsentDisplayName": "This is a test permission.",  "id": "C531F284-02F7-40E7-A2BA-130D72BBC9EC",  "isEnabled": true,  "type": "User",  "userConsentDescription": "Allow the application test access grant",  "userConsentDisplayName": "Now I am testing. This is a test permission.",  "value": "MyTest.AllPermisison"}  ],  "oauth2RequirePostResponse": false,  . . .}

補足 : 上記で type を Admin にすると、User Consent を抑制 (Administrator Consent を強制) できます。

さいごに、「Azure AD : Service の開発 (access token の verify)」に従って TestService を実装 (プログラミング) します。

この際、付与された Permission の内容を参照して、この Service の利用権限を確認しますが、この方法は「Azure AD : Service の開発 (access token の verify)」で取得した JWT の scp (Scope) の値を確認すれば OK です。
例えば、編集権限が必要な Service に対し、scp として参照権限しか付与されていなかった場合、Error の Status を返すようにします。
上記のサンプルの場合、Permission を 1 つしか定義しなかったので、scp には「MyTest.AllPermisison」の値が設定されるはずです。

なお、「Azure AD : Service の開発 (access token の verify)」で紹介した方法で .NET (C#) を使って Web API を作成した場合、この Scope 情報は Claim と設定されているので、下記の通り取り出すことができます。
下記の「http://schemas.microsoft.com/identity/claims/scope」は scp と同じ意味です。

using System.Threading;using System.Security.Claims;. . .[Authorize]public class ValuesController : ApiController{  public IEnumerable Get()  {string scopeValue =  ((ClaimsPrincipal)Thread.CurrentPrincipal).Claims  .Where(c => c.Type == "http://schemas.microsoft.com/identity/claims/scope")  .Select(c => c.Value).FirstOrDefault();if (scopeValue == "MyTest.AllPermisison"){  // having permissions  . . .}else{  // not having permissions  . . .}. . .  }  . . .}

 

Permission を利用する Client の作成

今度は、「Azure Active Directory の Common Consent Framework (Client 側)」と同じ手順で、Client Application を Azure AD に登録します。(登録手順は省略します。この Client を TestClient1 とします。また、忘れずに Multi-Tenant の Application として登録しておきましょう。)

登録の際、下図の通り、Permission として、TestService と、上記で設定したテスト用の Permission が選択できますので、この Permission を設定してください。(重要)

なお、今回は、Client 側のプログラミングはおこなわず、以下に述べるように Web Browser を使ってトレースしてみます。

 

Consent UI の Test (動作確認)

Consent UI を確認するため、上記とは別の Tenant (TestService や TestClient1 とは異なる Tenant) で検証します。

今回は、TestClient1 が TestService を利用するため、まず検証用の新しい Tenant で Service 側 (TestService) の Subscribe をおこないます。
ブラウザーで下記にアクセスしてください。(今回は、下記太字の通り Admin Consent を使って Tenant 全体で TestService を Subscribe します。Admin Consent については、前回の投稿を参照してください。)

https://login.microsoftonline.com/common/oauth2/authorize?response_type=code&client_id={Client Id of TestService}&redirect_uri={Url of TestService}&prompt=admin_consent(例えば、https://login.microsoftonline.com/common/oauth2/authorize?response_type=code&client_id=737e841f-7151-4db9-a4e6-55b767cb614c&redirect_uri=https%3a%2f%2ftestsvc.azurewebsites.net%2f&prompt=admin_consent)

上記にアクセスすると、リダイレクトされ、Azure AD の SignIn 画面が表示されます。上述の検証用の Tenant のユーザーでログインすると、下図の Consent UI が表示されるので、[OK] ボタンを押して、この TestService を Subscribe します。

つぎに、TestClient1 (Client 側) を Subscribe します。(この際、はじめて、上記で設定した Custom の Permission 設定が表示されます。)
今度は、Web Browser を使って下記の Url にアクセスします。

https://login.microsoftonline.com/common/oauth2/authorize?response_type=code&client_id=&resource=&redirect_uri=(例えば、https://login.microsoftonline.com/common/oauth2/authorize?response_type=code&client_id=0dba02e5-55ba-45cf-b3bd-19fdb1f71a5f&resource=https%3a%2f%2fo365demo02.onmicrosoft.com%2fTestService&redirect_uri=http%3a%2f%2flocalhost%2fcallback)

この場合も SignIn 画面にリダイレクトされ、検証用の Tenant のユーザーでログインすると、下図の通り、「Now I am testing. This is a test permission」と書かれた Consent UI が表示されます。ここに書かれている Permission (Scope) は、上記で Manifest に設定した Permission です。

この画面で [OK] ボタンを押すと、ちゃんと code (Autorization code) が返ってくるのが確認できるはずです。

 

※ 変更履歴 :

2015/03/19  エンドポイントを https://login.windows.net から https://login.microsoftonline.com (新エンドポイント) に変更

2017/05/26  画面を新ポータル (https://portal.azure.com) に変更

 

Categories: Uncategorized

Tagged as: , ,

2 replies»

  1. Pingback: Azure Active Directory の SSO 開発 (Node.js 編) – tsmatz
  2. Pingback: Azure Active Directory の SSO 開発 (PHP 編) – tsmatz

Leave a Reply