Uncategorized

Azure AD (Entra ID) : Role の使用

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

こんにちは。

使用する Application で Role を使用した権限チェックが必要な場合、Azure AD (Azure Active Directory) のスキーマ拡張 (カスタム属性の追加) や、専用の Group を設定する方法を思いつくかもしれません。しかし、こうした場合は、ここで解説する Application Role を使用してください。

例えば、ある会計アプリでは、財務担当者、与信管理者などの Role が必要になるかもしれません。また、ある経費管理ソフトでは、経費承認者、代行入力者などの Role が必要になるかもしれません。
Group 情報は JWT (Access Token) から取得して Application で利用できますが、こうした Application ごとの権限を Group などを使って Directory 単位で設定し、Application で理解させると、運用が煩雑になります。
ここで解説する Applicatioin Role を使うと、こうした Application 固有の情報を、Application 側で定義して Application 内部で利用することで、Portability (Application の可搬性) を維持できます。(特に Multi-Tenant 対応の Application では必須の考え方です。)

補足 : こうした Application 固有の権限情報を、ここで紹介する Application Role を使用せず、Application 側で独自にデータベースなどを準備して管理するアプローチもあります。
この場合、例えば、ユーザーが削除された際の情報のクリーンアップなど、整合を維持するための何らかの仕組み (同期、バッチなど) も必要になります。

 

Application への Role 定義 (Define)

Application に Role を定義するには、Manifest (設定の記述されたテキスト ファイル) を編集します。
Azure AD を使った API 連携の Client 開発 (OAuth)」で解説した手順で Azure AD に Application を登録したら、下図の通り、Manifest 編集を開始します。(マニフェストのエディターを起動します。)

下記の通り、マニフェストの appRoles に要素を追記します。
今回は、BizOwner という Role を追加しています。(複数の Role を設定できます。)

なお、id には GUID を新規作成して設定してください。

{  "allowActAsForAllClients": null,  "appId": "97cff508-1b4a-40a0-8fc1-7882ffac57b1",  "appMetadata": {"version": 0,"data": []  },  "appRoles": [{  "allowedMemberTypes": [  "User"  ],  "description": "This is Business Owner (Sample User Role)",  "displayName": "BizOwner",  "id": "7b1e298c-3b1d-42b5-9dd5-3b54775cc7f4",  "isEnabled": true,  "value": "bizowner"}  ],  . . .}

なお、今回は、上記の通り、allowedMemberTypes に User を設定し、ユーザー単位に設定可能な Role としていますが、allowedMemberTypes に下記の通り Application を指定できます。

{  "allowActAsForAllClients": null,  "appId": "97cff508-1b4a-40a0-8fc1-7882ffac57b1",  "appMetadata": {"version": 0,"data": []  },  "appRoles": [{  "allowedMemberTypes": ["Application"  ],  "description": "Manage Service01 App (Sample App Role)",  "displayName": "Service01Manage",  "id": "a4a6c767-53f6-432b-a314-137598e4d119",  "isEnabled": true,  "value": "service01manage"}  ],  . . .}

この場合、下図の通り、Application Permission (アクセス許可) の箇所に表示され、Application 単位で Role 割り当てができます。
この Application 単位の Role の使い方は、次回、解説しようと思います。(次回は、Backend service からの OAuth フローの方法を紹介します。)

 

User への Role の付与 (Assign)

User や Group に Application Role を割り当てる (Assign) には、「Azure Active Directory の Graph API の活用」で解説した Graph API を使用します。実際の開発では、Application 側で Role 割り当てのための専用の画面などを構築し、内部で Graph API を呼び出すと良いでしょう。
[追記] User への Role 割り当てが、Azure Portal (画面) で可能になりました。Azure Active Directory の管理画面の [Enterprise Application] からアプリケーションを選択し、[Users and groups] から割り当てが可能です。(本投稿 (以下) では、API を使用して割り当てています。)

例えば、ある User に上記の BizOwner Role を割り当てるには、「Azure Active Directory の Graph API の活用」で解説した方法で access token を取得し、下記の通り HTTP Request を出します。(Graph API の使用自体にも Permission 設定が必要ですので注意してください。)

下記の premiumaad.onmicrosoft.com には皆さんが使用している Directory のドメインを、demouser01@premiumaad.onmicrosoft.com には Role を付与する User を設定します。
また、Body の id には上記のロール (appRole) の id, principalId には User の objectId, resourceId には登録した service application (上述) の ServicePrincipal の objectId を設定します。(これらの値は、Graph API や Azure AD の Windows PowerShell で確認してください。)

HTTP Request :

POST https://graph.windows.net/premiumaad.onmicrosoft.com/users/demouser01@premiumaad.onmicrosoft.com/appRoleAssignmentsContent-Type: application/jsonAccept: application/jsonAuthorization: Bearer {access token}api-version: 1.5{  "id": "7b1e298c-3b1d-42b5-9dd5-3b54775cc7f4",  "principalId":  "3eb43867-4458-48b1-ad26-175452ae67b2",  "principalType": "User",  "resourceId":  "902ebf17-c960-46ab-a06c-d021588bd569"}

HTTP Response :

HTTP/1.1 201 CreatedContent-Type: application/json;odata=minimalmetadata;streaming=true;charset=utf-8Access-Control-Allow-Origin: *Content-Length: 616{  "odata.metadata": "https://graph.windows.net/premiumaad.onmicrosoft.com/$metadata#directoryObjects/Microsoft.DirectoryServices.AppRoleAssignment/@Element",  "odata.type": "Microsoft.DirectoryServices.AppRoleAssignment",  "objectType": "AppRoleAssignment",  "objectId": "Zzi0PlhEsUitJhdUUq5nsgcY-XUzDPRGjjnwtrCPCMk",  "deletionTimestamp": null,  "creationTimestamp": "2015-03-31T05:43:41.4916047Z",  "id": "7b1e298c-3b1d-42b5-9dd5-3b54775cc7f4",  "principalDisplayName": null,  "principalId": "3eb43867-4458-48b1-ad26-175452ae67b2",  "principalType": "User",  "resourceDisplayName": "service01",  "resourceId": "902ebf17-c960-46ab-a06c-d021588bd569"}

Role の割り当てを解除 (削除) するには、上記の Response で返された objectId を使って、下記の通り HTTP 要求を出します。

DELETE https://graph.windows.net/premiumaad.onmicrosoft.com/users/demouser01@premiumaad.onmicrosoft.com/appRoleAssignments/Zzi0PlhEsUitJhdUUq5nsgcY-XUzDPRGjjnwtrCPCMkAuthorization: Bearer {access token}api-version: 1.5

補足 : 上述した Application への Role (appRoles) 定義自体も Graph API でおこなうことができます。(ただし、api-version 1.5 以上を使用する必要があります。)

 

Claim を使用した Role の確認 (Check)

あとは、上記の Application Role を持つ Service Application を呼び出す Client Application を「Azure AD を使った API 連携の Client 開発 (OAuth)」で説明した手順で (OAuth を使って) 作成します。

OAuth のフローで返される Access Token には、「Azure AD : Service 開発 (access token の validation check)」で解説したように、ユーザーの属性情報が Claim として設定されていますが、Application Role を付与したユーザー (上記の User) でログイン (SignIn) をおこなうと、下記の roles の通り、Claim の一部として User に付与された Application Role も設定されます。
Service Application では、この値を確認して Application 固有の処理 (権限チェックなど) をおこなうことができます。

{  "aud": "https://tsmatsuz-sv01.azurewebsites.net/",  "iss": "https://sts.windows.net/7698d4ed-6610-4807-977c-b19ab9e111b5/",  "iat": 1427784998,  "nbf": 1427784998,  "exp": 1427788898,  "ver": "1.0",  "tid": "7698d4ed-6610-4807-977c-b19ab9e111b5",  "amr": ["pwd"  ],  "roles": ["bizowner"  ],  "oid": "3eb43867-4458-48b1-ad26-175452ae67b2",  "upn": "demouser01@premiumaad.onmicrosoft.com",  "sub": "fzc1ATTBBVrFbumDt9VCZqI6-L3ynZbTvQMirGWFoAY",  "given_name": "Taro",  "family_name": "Demo",  "name": "Demo Taro",  "unique_name": "demouser01@premiumaad.onmicrosoft.com",  "appid": "32f3e42d-ab1e-4043-b23d-9134dd36bb4e",  "appidacr": "0",  "scp": "user_impersonation",  "acr": "1"}

 

※ 変更履歴 :

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

Categories: Uncategorized

Tagged as: , ,

2 replies»

Leave a Reply