Skip to content

Commit db2d402

Browse files
authored
Merge pull request #103594 from MicrosoftDocs/master
2/06 PM Publish
2 parents 56d7739 + aab2cbf commit db2d402

File tree

158 files changed

+1525
-699
lines changed

Some content is hidden

Large Commits have some content hidden by default. Use the searchbox below for content that may be hidden.

158 files changed

+1525
-699
lines changed

articles/active-directory-b2c/identity-provider-azure-ad-multi-tenant-custom.md

Lines changed: 14 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -9,7 +9,7 @@ manager: celestedg
99
ms.service: active-directory
1010
ms.workload: identity
1111
ms.topic: conceptual
12-
ms.date: 09/13/2019
12+
ms.date: 02/06/2020
1313
ms.author: marsma
1414
ms.subservice: B2C
1515
---
@@ -60,6 +60,19 @@ You need to store the application key that you created in your Azure AD B2C tena
6060
1. For **Key usage**, select `Signature`.
6161
1. Select **Create**.
6262
63+
## Configuring optional claims
64+
65+
If you want to get the `family_name` and `given_name` claims from Azure AD, you can configure optional claims for your application in the Azure portal UI or application manifest. For more information, see [How to provide optional claims to your Azure AD app](../active-directory/develop/active-directory-optional-claims.md).
66+
67+
1. Sign in to the [Azure portal](https://portal.azure.com). Search for and select **Azure Active Directory**.
68+
1. From the **Manage** section, select **App registrations**.
69+
1. Select the application you want to configure optional claims for in the list.
70+
1. From the **Manage** section, select **Token configuration (preview)**.
71+
1. Select **Add optional claim**.
72+
1. Select the token type you want to configure.
73+
1. Select the optional claims to add.
74+
1. Click **Add**.
75+
6376
## Add a claims provider
6477
6578
If you want users to sign in by using Azure AD, you need to define Azure AD as a claims provider that Azure AD B2C can communicate with through an endpoint. The endpoint provides a set of claims that are used by Azure AD B2C to verify that a specific user has authenticated.

articles/active-directory/app-provisioning/index.yml

Lines changed: 4 additions & 4 deletions
Original file line numberDiff line numberDiff line change
@@ -1,16 +1,16 @@
11
### YamlMime:Landing
22

3-
title: Application provisioning documentation
4-
summary: Azure Active Directory provides secure and seamless access to cloud and on-premises applications. Plus, there's no need to manage passwords. Your end-users can sign in once to access Office 365 and thousands of other applications. Learn how to manage and deploy applications with our quickstarts, tutorials, and guidance.
3+
title: Application and HR provisioning documentation
4+
summary: Azure Active Directory app provisioning lets you automatically create and manage user identities in your cloud (SaaS) apps. Azure AD also offers provisioning with cloud-based human resources (HR) applications. Learn how to manage and deploy cloud app and HR provisioning with our quickstarts, tutorials, and guidance.
55

66
metadata:
77
title: Application provisioning documentation
8-
description: Azure Active Directory provides secure and seamless access to cloud and on-premises applications. Plus, there's no need to manage passwords. Your end-users can sign in once to access Office 365 and thousands of other applications. Learn how to manage and deploy applications with our quickstarts, tutorials, and guidance.
8+
description: Azure Active Directory app provisioning lets you automatically create and manage user identities in your cloud (SaaS) apps. Azure AD also offers provisioning with cloud-based human resources (HR) applications. Learn how to manage and deploy cloud app and HR provisioning with our quickstarts, tutorials, and guidance.
99
ms.service: active-directory
1010
ms.subservice: app-mgmt
1111
ms.workload: identity
1212
ms.topic: landing-page
13-
ms.date: 10/10/2019
13+
ms.date: 02/06/2020
1414
author: msmimart
1515
ms.author: mimart
1616
manager: celested

articles/active-directory/app-provisioning/toc.yml

Lines changed: 3 additions & 4 deletions
Original file line numberDiff line numberDiff line change
@@ -1,12 +1,11 @@
1-
- name: Application provisioning documentation
1+
- name: Application and HR provisioning documentation
22
href: index.yml
33
- name: Overview
44
expanded: true
55
items:
66
- name: What is application provisioning?
77
href: user-provisioning.md
88
- name: Tutorials
9-
expanded: true
109
items:
1110
- name: G Suite
1211
href: /azure/active-directory/saas-apps/google-apps-provisioning-tutorial?context=azure/active-directory/app-provisioning/context/app-provisioning-context
@@ -54,8 +53,6 @@
5453
href: check-status-user-account-provisioning.md
5554
- name: Export and import your configuration
5655
href: export-import-provisioning-configuration.md
57-
- name: Build a SCIM endpoint and configure provisioning
58-
href: use-scim-to-provision-users-and-groups.md
5956
- name: Troubleshoot application provisioning
6057
items:
6158
- name: Troubleshoot app provisioning
@@ -74,6 +71,8 @@
7471
href: application-provisioning-when-will-provisioning-finish.md
7572
- name: Provisioning logs
7673
href: /azure/active-directory/reports-monitoring/concept-provisioning-logs?context=azure/active-directory/app-provisioning/context/app-provisioning-context
74+
- name: Build a SCIM endpoint and configure provisioning
75+
href: use-scim-to-provision-users-and-groups.md
7776
- name: Automate configuration using MS Graph
7877
href: application-provisioning-configure-api.md
7978
- name: Reference

articles/active-directory/app-provisioning/use-scim-to-provision-users-and-groups.md

Lines changed: 69 additions & 10 deletions
Original file line numberDiff line numberDiff line change
@@ -1,6 +1,6 @@
11
---
2-
title: Build a SCIM endpoint for user provisioning to apps from Azure AD
3-
description: Learn to build a SCIM endpoint, integrate your SCIM API with Azure Active Directory, and start automating provisioning users and groups into your cloud applications.
2+
title: Develop a SCIM endpoint for user provisioning to apps from Azure AD
3+
description: System for Cross-domain Identity Management (SCIM) standardizes automatic user provisioning. Learn to develop a SCIM endpoint, integrate your SCIM API with Azure Active Directory, and start automating provisioning users and groups into your cloud applications.
44
services: active-directory
55
documentationcenter: ''
66
author: msmimart
@@ -12,7 +12,7 @@ ms.workload: identity
1212
ms.tgt_pltfrm: na
1313
ms.devlang: na
1414
ms.topic: conceptual
15-
ms.date: 11/15/2019
15+
ms.date: 2/7/2019
1616
ms.author: mimart
1717
ms.reviewer: arvinh
1818
ms.custom: aaddev;it-pro;seohack1
@@ -46,15 +46,53 @@ Automating provisioning to an application requires building and integrating a SC
4646

4747
## Step 1: Design your user and group schema
4848

49-
Every application requires different attributes to create a user or group. Start your integration by identifying the objects (users, groups) and attributes (name, manager, job title, etc.) that your application requires. You can then use the table below to understand how the attributes your application requires could map to an attribute in Azure AD and the SCIM RFC. Note that you can [customize](customize-application-attributes.md) how attributes are mapped between Azure AD and your SCIM endpoint.
49+
Every application requires different attributes to create a user or group. Start your integration by identifying the objects (users, groups) and attributes (name, manager, job title, etc.) that your application requires. The SCIM standard defines a schema for managing users and groups. The core user schema only requires three attributes: **id** (service provider defined identifier), **externalId** (client defined identifier), and **meta** (read-only metadata maintained by the service provider). All other attributes are optional. In addition to the core user schema, the SCIM standard defines an enterprise user extension and a model for extending the user schema to meet your application’s needs. If, for example, your application requires a user’s manager, you can use the enterprise user schema to collect the user’s manager and the core schema to collect the user’s email. To design your schema, follow the steps below:
50+
1. List the attributes your application requires. It can be helpful to break down your requirements into the attributes needed for authentication (e.g. loginName and email), attributes needed to manage the lifecycle of the user (e.g. status / active), and other attributes needed for your particular application to work (e.g. manager, tag).
51+
2. Check whether those attributes are already defined in the core user schema or enterprise user schema. If any attributes that you need and aren’t covered in the core or enterprise user schemas, you will need to define an extension to the user schema that covers the attributes you need. In the example below, we’ve added an extension to the user to allow provisioning a “tag” on a user. It is best to start with just the core and enterprise user schemas and expand out to additional custom schemas later.
52+
3. Map the SCIM attributes to the user attributes in Azure AD. If one of the attributes you have defined in your SCIM endpoint does not have a clear counterpart on the Azure AD user schema, there is a good chance the data isn’t stored on the user object at all on most tenants. Consider whether this attribute can be optional for creating a user. If the attribute is critical for your application to work, guide the tenant administrator to extend their schema or use an extension attribute as shown below for the “tags” property.
5053

51-
User resources are identified by the schema identifier, `urn:ietf:params:scim:schemas:extension:enterprise:2.0:User`, which is included in this protocol specification: https://tools.ietf.org/html/rfc7643. The default mapping of the attributes of users in Azure AD to the attributes of user resources is provided in Table 1.
54+
### Table 1: Outline the attributes that you need
55+
| Step 1: Determine attributes your app requires| Step 2: Map app requirements to SCIM standard| Step 3: Map SCIM attributes to the Azure AD attributes|
56+
|--|--|--|
57+
|loginName|userName|userPrincipalName|
58+
|firstName|name.givenName|givenName|
59+
|lastName|name.lastName|lastName|
60+
|workMail|Emails[type eq “work”].value|Mail|
61+
|manager|manager|manager|
62+
|tag|urn:ietf:params:scim:schemas:extension:2.0:CustomExtension:tag|extensionAttribute1|
63+
|status|active|isSoftDeleted (computed value not stored on user)|
5264

53-
Group resources are identified by the schema identifier, `urn:ietf:params:scim:schemas:core:2.0:Group`. Table 2 shows the default mapping of the attributes of groups in Azure AD to the attributes of group resources.
65+
The schema defined above would be represented using the Json payload below. Note that in addition to the attributes required for the application, the JSON representation includes the required “id,” “externalId,” and “meta” attributes.
5466

55-
Note that you don't need to support both users and groups or all the attributes shown below. They are a reference for how attributes in Azure AD are often mapped to properties in the SCIM protocol.
56-
57-
### Table 1: Default user attribute mapping
67+
```json
68+
{
69+
"schemas": ["urn:ietf:params:scim:schemas:core:2.0:User",
70+
"urn:ietf:params:scim:schemas:extension:enterprise:2.0:User",
71+
"urn:ietf:params:scim:schemas:extension:CustomExtensionName:2.0:User"],
72+
"userName":"bjensen",
73+
"externalId":"bjensen",
74+
"name":{
75+
"familyName":"Jensen",
76+
"givenName":"Barbara"
77+
},
78+
"urn:ietf:params:scim:schemas:extension:enterprise:2.0:User": {
79+
"Manager": "123456"
80+
},
81+
"urn:ietf:params:scim:schemas:extension:CustomExtensionName:2.0:CustomAttribute:User": {
82+
"tag": "701984",
83+
},
84+
"meta": {
85+
"resourceType": "User",
86+
"created": "2010-01-23T04:56:22Z",
87+
"lastModified": "2011-05-13T04:42:34Z",
88+
"version": "W\/\"3694e05e9dff591\"",
89+
"location":
90+
"https://example.com/v2/Users/2819c223-7f76-453a-919d-413861904646"
91+
}
92+
```
93+
94+
### Table 2: Default user attribute mapping
95+
You can then use the table below to understand how the attributes your application requires could map to an attribute in Azure AD and the SCIM RFC. You can [customize](customize-application-attributes.md) how attributes are mapped between Azure AD and your SCIM endpoint. Note that you don't need to support both users and groups or all the attributes shown below. They are a reference for how attributes in Azure AD are often mapped to properties in the SCIM protocol.
5896

5997
| Azure Active Directory user | "urn:ietf:params:scim:schemas:extension:enterprise:2.0:User" |
6098
| --- | --- |
@@ -78,7 +116,7 @@ Note that you don't need to support both users and groups or all the attributes
78116
| user-PrincipalName |userName |
79117

80118

81-
### Table 2: Default group attribute mapping
119+
### Table 3: Default group attribute mapping
82120

83121
| Azure Active Directory group | urn:ietf:params:scim:schemas:core:2.0:Group |
84122
| --- | --- |
@@ -89,6 +127,20 @@ Note that you don't need to support both users and groups or all the attributes
89127
| objectId |externalId |
90128
| proxyAddresses |emails[type eq "other"].Value |
91129

130+
There are several endpoints defined in the SCIM RFC. You can get started with the /User endpoint and then expand from there. The /Schemas endpoint is helpful when using custom attributes or if your schema changes frequently. It enables a client to retrieve the most up-to-date schema automatically. The /Bulk endpoint is especially helpful when supporting groups. The table below describes the various endpoints defined in the SCIM standard.
131+
The /Schemas endpoint is helpful when using custom attributes or if your schema changes frequently. It enables a client to retrieve the most up to date schema automatically. The /Bulk endpoint is especially helpful when supporting groups. The table below describes the various endpoints defined in the SCIM standard.
132+
133+
### Table 4: Determine the endpoints that you would like to develop
134+
|ENDPOINT|DESCRIPTION|
135+
|--|--|
136+
|/User|Perform CRUD operations on a user object.|
137+
|/Group|Perform CRUD operations on a group object.|
138+
|/ServiceProviderConfig|Provides details about the features of the SCIM standard that are supported, for example the resources that are supported and the authentication method.|
139+
|/ResourceTypes|Specifies metadata about each resource|
140+
|/Schemas|The set of attributes supported by each client and service provider can vary. While one service provider might include “name,” “title,” and “emails,” while another service provider uses “name,” “title,” and “phoneNumbers.” The schemas endpoint allows for discovery of the attributes supported.|
141+
|/Bulk|Bulk operations allow you to perform operations on a large collection of resource objects in a single operation (e.g. update memberships for a large group).|
142+
143+
92144
## Step 2: Understand the Azure AD SCIM implementation
93145
> [!IMPORTANT]
94146
> The behavior of the Azure AD SCIM implementation was last updated on December 18, 2018. For information on what changed, see [SCIM 2.0 protocol compliance of the Azure AD User Provisioning service](../manage-apps/application-provisioning-config-problem-scim-compatibility.md).
@@ -1371,6 +1423,13 @@ If you're building an application that will be used by more than one tenant, you
13711423
### Authorization for provisioning connectors in the application gallery
13721424
The SCIM spec does not define a SCIM-specific scheme for authentication and authorization. It relies on the use of existing industry standards. The Azure AD provisioning client supports two authorization methods for applications in the gallery.
13731425

1426+
|Authorization method|Pros|Cons|Support|
1427+
|--|--|--|--|
1428+
|Username and password (not recommended or supported by Azure AD)|Easy to implement|Insecure - [Your Pa$$word doesn't matter](https://techcommunity.microsoft.com/t5/azure-active-directory-identity/your-pa-word-doesn-t-matter/ba-p/731984)|Supported on a case-by-case basis for gallery apps. Not supported for non-gallery apps.|
1429+
|Long-lived bearer token (supported by Azure AD currently)|Long-lived tokens do not require a user to be present. They are easy for admins to use when setting up provisioning.|Long-lived tokens can be hard to share with an admin without using insecure methods such as email. |Supported for gallery and non-gallery apps. |
1430+
|OAuth authorization code grant (supported by Azure AD currently)|Access tokens are much shorter-lived than passwords, and have an automated refresh mechanism that long-lived bearer tokens do not have. A real user must be present during initial authorization, adding a level of accountability. |Requires a user to be present. If the user leaves the organization, the token is invalid and authorization will need to be completed again.|Supported for gallery apps. Support for non-gallery apps is underway.|
1431+
|OAuth client credentials grant (not supported, on our roadmap)|Access tokens are much shorter-lived than passwords, and have an automated refresh mechanism that long-lived bearer tokens do not have. Both the authorization code grant and the client credentials grant create the same type of access token, so moving between these methods is transparent to the API. Provisioning can be completely automated, and new tokens can be silently requested without user interaction. ||Not supported for gallery and non-gallery apps. Support is in our backlog.|
1432+
13741433
**OAuth authorization code grant flow:** The provisioning service supports the [authorization code grant](https://tools.ietf.org/html/rfc6749#page-24). After submitting your request for publishing your app in the gallery, our team will work with you to collect the following information:
13751434
* Authorization URL: A URL by the client to obtain authorization from the resource owner via user-agent redirection. The user is redirected to this URL to authorize access.
13761435
* Token exchange URL: A URL by the client to exchange an authorization grant for an access token, typically with client authentication.

articles/active-directory/develop/msal-net-xamarin-android-considerations.md

Lines changed: 5 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -68,16 +68,19 @@ That line ensures that the control goes back to MSAL once the interactive portio
6868

6969
## Update the Android manifest
7070
The `AndroidManifest.xml` should contain the following values:
71-
```csharp
71+
```xml
7272
<activity android:name="microsoft.identity.client.BrowserTabActivity">
7373
<intent-filter>
7474
<action android:name="android.intent.action.VIEW" />
7575
<category android:name="android.intent.category.DEFAULT" />
7676
<category android:name="android.intent.category.BROWSABLE" />
77-
<data android:scheme="msal{client_id}" android:host="auth" />
77+
<data android:scheme="msauth"
78+
android:host="Enter_the_Package_Name"
79+
android:path="/Enter_the_Signature_Hash"/>
7880
</intent-filter>
7981
</activity>
8082
```
83+
Substitute the package name you registered in the Azure portal for the `android:host=` value. Substitute the key hash you registered in the Azure portal for the `android:path=` value. The Signature Hash should **not** be URL encoded. Ensure that there is a leading `/` at the beginning of your Signature Hash.
8184

8285
Or, you can [create the activity in code](https://docs.microsoft.com/xamarin/android/platform/android-manifest#the-basics) and not manually edit `AndroidManifest.xml`. For that, you must create a class that has the `Activity` and `IntentFilter` attribute. A class that represents the same values of the above xml would be:
8386

0 commit comments

Comments
 (0)