カスタム承認ワークフローをセルフサービス サインアップに追加する

適用対象: ワークフォース テナント 外部テナント (詳細)

API コネクタを使用すると、セルフサービス サインアップを使用して独自のカスタム承認ワークフローと統合できるため、テナントに作成されるゲスト ユーザー アカウントを管理できます。

この記事では、承認システムと統合する方法の例を示します。 この例では、セルフサービス サインアップ ユーザー フローがサインアップ プロセス中にユーザー データを収集し、データを承認システムに渡します。 承認システムでは、次のことが可能です。

• ユーザーを自動的に承認し、Microsoft Entra ID にユーザー アカウントの作成を許可します。
• 手動レビューをトリガーします。 要求が承認された場合、承認システムは Microsoft Graph を使用してユーザー アカウントをプロビジョニングします。 承認システムは、アカウントが作成されたことをユーザーに通知することもできます。

承認システム用のアプリケーションを登録する

承認システムは Microsoft Entra テナントのアプリケーションとして登録する必要があります。登録すると、そのシステムは Microsoft Entra ID で認証されて、ユーザーを作成するアクセス許可が付与されます。 Microsoft Graph の認証と承認の基本について詳しく説明します。

1. Microsoft Entra 管理センターに、少なくともユーザー管理者としてサインインします。
2. Entra ID>App registrations に移動し、[新規登録] を選択します。
3. アプリケーションの 名前 (サインアップ承認など) を入力 します。
4. [ 登録] を選択します。 他のすべてのフィールドは既定値のままにすることができます。

1. 左側のメニューの [ 管理 ] で 、[ API のアクセス許可] を選択し、[ アクセス許可の追加] を選択します。
2. [ API のアクセス許可の要求 ] ページ で、Microsoft Graph を選択し、[ アプリケーションのアクセス許可] を選択します。
3. [ アクセス許可の選択] で [ ユーザー] を展開し、[ User.ReadWrite.All ] チェック ボックスをオンにします。 このアクセス許可は、承認システムが承認時にユーザーを作成することを許可します。 次に、[ アクセス許可の追加] を選択します。

9. [API のアクセス許可] ページで、[管理者の同意を付与する (テナント名)] を選択し、[はい] を選択します。
10. 左側のメニューの [ 管理 ] で[ 証明書とシークレット] を選択し、[ 新しいクライアント シークレット] を選択します。
11. シークレットの 説明 ( 承認クライアント シークレットなど) を入力し、クライアント シークレットの有効期限を選択 します。 次に、[ 追加] を選択します。
12. クライアント シークレットの値をコピーします。 クライアント シークレットの値を表示できるのは、作成直後のみです。 シークレットを作成したら、ページを離れる前に必ず保存してください。

13. アプリケーション ID をクライアント ID として使用し、Microsoft Entra ID で認証するために生成したクライアント シークレットを使用するように承認システムを構成します。

API コネクタを作成する

次に、セルフサービス サインアップ ユーザー フロー用 の API コネクタを作成 します。 承認システム API には、次に示す例のように、2 つのコネクタとそれに対応するエンドポイントが必要です。 これらの API コネクタは次の処理を実行します。

• 承認の状態を確認します。 ユーザーが既存の承認要求を持っているか、既に拒否されているかどうかを確認するために、ユーザーが ID プロバイダーでサインインした直後に承認システムに呼び出しを送信します。 承認システムが自動承認の決定のみを行う場合、この API コネクタは必要ないことがあります。 "承認状態の確認" API コネクタの例。

• 承認の要求 - ユーザーが属性コレクション ページを完了した後、ユーザー アカウントが作成される前に承認システムに呼び出しを送信して、承認を要求します。 承認要求は、自動的に許可したり手動で確認したりすることができます。 "要求の承認" API コネクタの例。

これらのコネクタを作成するには、 API コネクタを作成する手順に従います。

ユーザー フローで API コネクタを有効にする

ここで、次の手順を使用して、セルフサービス サインアップ ユーザー フローに API コネクタを追加します。

1. Microsoft Entra 管理センターに、少なくともユーザー管理者としてサインインします。

2. Entra ID>External Identities>User フローを参照し、API コネクタを有効にするユーザー フローを選択します。

3. API コネクタを選択し、ユーザー フローの次の手順で呼び出す API エンドポイントを選択します。

   • サインアップ中に ID プロバイダーとフェデレーションした後: 承認状態 API コネクタを選択します (承認 状態の確認など)。
   • ユーザーを作成する前に:承認要求 API コネクタ (承認 要求など) を選択します。

1. [保存] を選択します。

API 応答を使用してサインアップ フローを制御する

承認システムでは、呼び出し時にその応答を使用して、サインアップ フローを制御できます。

"承認状態の確認" API コネクタの要求と応答

API によって "承認状態の確認" API コネクタから受信した要求の例:

POST <API-endpoint>
Content-type: application/json

{
 "email": "johnsmith@fabrikam.onmicrosoft.com",
 "identities": [ //Sent for Google, Facebook, and Email One Time Passcode identity providers 
     {
     "signInType":"federated",
     "issuer":"facebook.com",
     "issuerAssignedId":"0123456789"
     }
 ],
 "displayName": "John Smith",
 "givenName":"John",
 "lastName":"Smith",
 "ui_locales":"en-US"
}

API に送信される正確な要求は、ID プロバイダーによって提供される情報によって異なります。 "email" は常に送信されます。

"承認状態の確認" の継続応答

承認状態の確認 API エンドポイントは、次の場合に継続応答を返す必要があります。

• ユーザーが以前承認を要求していない。

継続応答の例:

HTTP/1.1 200 OK
Content-type: application/json

{
    "version": "1.0.0",
    "action": "Continue"
}

"承認状態の確認" のブロック応答

承認状態の確認 API エンドポイントは、次の場合にブロック応答を返す必要があります。

• ユーザー承認が保留されている。
• ユーザーが拒否され、再度承認を要求することができない。

ブロック応答の例は次のとおりです。

HTTP/1.1 200 OK
Content-type: application/json

{
    "version": "1.0.0",
    "action": "ShowBlockPage",
    "userMessage": "Your access request is already processing. You'll be notified when your request has been approved.",
}

HTTP/1.1 200 OK
Content-type: application/json

{
    "version": "1.0.0",
    "action": "ShowBlockPage",
    "userMessage": "Your sign up request has been denied. Please contact an administrator if you believe this is an error",
}

"要求の承認" API コネクタの要求と応答

API によって受信された "要求の承認" API コネクタからの HTTP 要求の例:

POST <API-endpoint>
Content-type: application/json

{
 "email": "johnsmith@fabrikam.onmicrosoft.com",
 "identities": [ // Sent for Google, Facebook, and Email One Time Passcode identity providers 
     {
     "signInType":"federated",
     "issuer":"facebook.com",
     "issuerAssignedId":"0123456789"
     }
 ],
 "displayName": "John Smith",
 "givenName":"John",
 "surname":"Smith",
 "jobTitle":"Supplier",
 "streetAddress":"1000 Microsoft Way",
 "city":"Seattle",
 "postalCode": "12345",
 "state":"Washington",
 "country":"United States",
 "extension_<extensions-app-id>_CustomAttribute1": "custom attribute value",
 "extension_<extensions-app-id>_CustomAttribute2": "custom attribute value",
 "ui_locales":"en-US"
}

API に送信される正確な要求は、ユーザーから収集される情報または ID プロバイダーによって提供される情報によって異なります。

"要求の承認" の継続応答

要求承認 API エンドポイントは、次の場合に継続応答を返す必要があります。

• ユーザーは 自動的に承認できます。

継続応答の例:

HTTP/1.1 200 OK
Content-type: application/json

{
    "version": "1.0.0",
    "action": "Continue"
}

"要求の承認" のブロック応答

要求承認 API エンドポイントは、次の場合にブロック応答を返す必要があります。

• ユーザー承認要求が作成されて現在保留になっている。
• ユーザー承認要求が自動的に拒否された。

ブロック応答の例は次のとおりです。

HTTP/1.1 200 OK
Content-type: application/json

{
    "version": "1.0.0",
    "action": "ShowBlockPage",
    "userMessage": "Your account is now waiting for approval. You'll be notified when your request has been approved.",
}

HTTP/1.1 200 OK
Content-type: application/json

{
    "version": "1.0.0",
    "action": "ShowBlockPage",
    "userMessage": "Your sign up request has been denied. Please contact an administrator if you believe this is an error",
}

応答内の userMessage がユーザーに表示されます。次に例を示します。

手動承認後のユーザー アカウントの作成

カスタム承認システムは、手動承認を取得した後、Microsoft Graph を使用してユーザー アカウントを作成します。 承認システムがユーザー アカウントをプロビジョニングする方法は、ユーザーによって使用された ID プロバイダーによって異なります。

Google または Facebook のフェデレーション ユーザーおよび電子メール ワンタイム パスコードの場合

ユーザーが Google または Facebook アカウントでサインインした場合、またはワンタイム パスコードを電子メールで送信する場合は、 ユーザー作成 API を使用できます。

1. 承認システムはユーザー フローから HTTP 要求を受信します。

POST <Approvals-API-endpoint>
Content-type: application/json

{
 "email": "johnsmith@outlook.com",
 "identities": [
     {
     "signInType":"federated",
     "issuer":"facebook.com",
     "issuerAssignedId":"0123456789"
     }
 ],
 "displayName": "John Smith",
 "city": "Redmond",
 "extension_<extensions-app-id>_CustomAttribute": "custom attribute value",
 "ui_locales":"en-US"
}

2. 承認システムは、Microsoft Graph を使用してユーザー アカウントを作成します。

POST https://graph.microsoft.com/v1.0/users
Content-type: application/json

{
 "userPrincipalName": "johnsmith_outlook.com#EXT@contoso.onmicrosoft.com",
 "accountEnabled": true,
 "mail": "johnsmith@outlook.com",
 "userType": "Guest",
 "identities": [
     {
     "signInType":"federated",
     "issuer":"facebook.com",
     "issuerAssignedId":"0123456789"
     }
 ],
 "displayName": "John Smith",
 "city": "Redmond",
 "extension_<extensions-app-id>_CustomAttribute": "custom attribute value"
}

フェデレーションされた Microsoft Entra ユーザーまたは Microsoft アカウントユーザーの場合

ユーザーがフェデレーション Microsoft Entra アカウントまたは Microsoft アカウントでサインインする場合は、 招待 API を 使用してユーザーを作成し、必要に応じて ユーザー更新 API を使用してユーザーに属性を割り当てる必要があります。

1. 承認システムはユーザー フローから HTTP 要求を受信します。

POST <Approvals-API-endpoint>
Content-type: application/json

{
 "email": "johnsmith@fabrikam.onmicrosoft.com",
 "displayName": "John Smith",
 "city": "Redmond",
 "extension_<extensions-app-id>_CustomAttribute": "custom attribute value",
 "ui_locales":"en-US"
}

2. 承認システムは、API コネクタによって提供される email を使用して招待を作成します。

POST https://graph.microsoft.com/v1.0/invitations
Content-type: application/json

{
    "invitedUserEmailAddress": "johnsmith@fabrikam.onmicrosoft.com",
    "inviteRedirectUrl" : "https://myapp.com"
}

応答の例:

HTTP/1.1 201 OK
Content-type: application/json

{
    ...
    "invitedUser": {
        "id": "<generated-user-guid>"
    }
}

3. 承認システムは、招待されたユーザーの ID を使用して、収集されたユーザー属性でユーザーのアカウントを更新します (省略可能)。

PATCH https://graph.microsoft.com/v1.0/users/<generated-user-guid>
Content-type: application/json

{
    "displayName": "John Smith",
    "city": "Redmond",
    "extension_<extensions-app-id>_AttributeName": "custom attribute value"
}

次のステップ

• セルフサービス サインアップ ユーザー フローを追加する
• API コネクタを追加する
• API コネクタをセキュリティで保護する
• 手動承認のサンプルを使用したゲスト ユーザーのセルフサービス サインアップ。