In Azure AD i have a multi-tenant Enterprise Application and App registration that are accessed through SAML2. I receive a limited set of users attributes, including tenant-id, email, first name, last name. But the organisation that the user belongs to, has defined extension attributes in their on-premise AD that i want to consume in my application. Also i would like to receive the jobTitle and Department in the application. The organisation says they have set up synchonisation of the attributes from their on-premise AD to Azure.
I have added the attributes i want under the Enterprise Application -> Single sign-on -> User Attributes and Claims -> Additional claims. But i am obviously still missing some configuration somewhere because they do not appear in the SAML2 token.
Which API permissions do i need to grant my application to pass these attributes through to the SAML2 token? Do i need to add something else to map these attributes?
when you set up a multitenant app, when your client's users / tenant signs in, it actually creates an "enterprise application" (service principal) in their tenant for your app. https://learn.microsoft.com/en-us/azure/active-directory/develop/howto-convert-app-to-be-multi-tenant#understand-user-and-admin-consent
As per that, your client would have to go into the SSO (saml) setup screens for your app in their own tenant and customize the claims that they will emit to your application. It doesn't matter if you add the attribute claims to your own SSO setup. thats for your tenant, not theirs.
It turns out that the Single Sign On properties are not visible in the Service Principal, because the proper tags are not set in the Application registration.
After using Microsoft Graph Explorer to see the properties of a working Service Principal with SSO properties, i noticed that it had a tag set that was absent in the Service Principal without SSO properties in the portal.
In the Application Registration manifest i set:
"signInAudience": "AzureADMultipleOrgs",
"tags": [
"WindowsAzureActiveDirectoryCustomSingleSignOnApplication",
"webApp",
"notApiConsumer"
],
Then recreated the service principal in a guest tenant using an adminconsent link (https://login.microsoftonline.com/[guest tenant domain]/v2.0/adminconsent?client_id=[app registration id]...) the portal displayed the Single Sign On settings in the guest tenant.
The Azure portal seems to display SSO properties for Service Principals associated with Application registrations that have the WindowsAzureActiveDirectoryCustomSingleSignOnApplication tag.
To summarise:
Set the WindowsAzureActiveDirectoryCustomSingleSignOnApplication tag in the Application registration manifest.
Create a Service Principal in the Owning Tenant if you haven't done that already.
Use an adminconsent url to create a Service Principal in the Guest tenant.
Have the Guest Tenant Administrator fill in the single sign on properties to add the required attributes.
The attributes are returned to the application in the SAML2 token
Related
I have an app that is implementing SCIM 2.0.
I have connected this app to my Azure AD and I am succeeding to provision users and groups to my app from from Azure AD.
I want to add a custom attribute and manage the value of that attribute in Azure AD for every user or a group and add that data to my provisioning mapping - to send it to my app as part of the provisioning process.
I can't find where in Azure AD I can do that.
I have tried to add a custom security attributes, I have assigned it to my app. But when I go to the provisioning mapping - the attribute is not in the list of source attributes that I can choose from.
I have also tried to add a custom attribute (which I was able to choose in the provisioning mapping), but I did not find where I can manage the value of this attribute to a user in the Azure AD .It looks like it can only be filled in a user flow (login with SSO) - which is not my case.
I did not find a way to create a custom attribute for a group and manage its values in the Azure AD and then add to provisioning group mapping.
I saw that there are extension attributes, but where in Azure AD I can enter data to these attributes for a specific users or groups?
Can anyone help?
Is there a completely different way to add extra information to user / group and send it from Azure AD to my app using SCIM?
• When you provision an application in Azure AD through SCIM (System for Cross-Domain Identity Management) for the purpose of provisioning the Azure AD users to the ‘Enterprise application’ created in Azure AD tenant, you enter the URL of the application’s SCIM endpoint as ‘https://api.contoso.com/scim/’ and since it requires an OAuth bearer token from an issuer other than Azure AD as it can validate this token issued by the Azure AD itself. Therefore, in the ‘Mappings’ section of the ‘Provisioning’ section for the Azure AD enterprise application, you have the option for reviewing the attributes that are synchronized from Azure AD to the SCIM provisioned app. These attributes are selected as ‘Matching’ properties and are used to match the users and groups in your app for update operations.
Also, to add the extension attributes to the user in Azure AD for them to be exported to the SCIM provisioned application, you will need to create a dynamic group with members added to them via a dynamic query as shown below. Before that, you will have to synchronize the extension attributes through Azure AD connect utility from the on-premises AD that were created there already. Then, these already created extension attributes can be selected to be mapped with the SCIM provisioned app as below: -
Complete the expression to suit your requirements. As above, the rule is set to ‘(user.extension_9d98ed114c4840d298fad781915f27e4_division -eq "Sales and marketing")’.
• Secondly, you can also create extension attributes for users that are to be synchronized from Azure AD to the SCIM provisioned application through Microsoft Graph API as shown below: -
First, create a ‘GET’ request to the object ID of the SCIM provisioned application to check the request sent status success. Then, send a ‘POST’ request to the object ID of the SCIM provisioned application as shown below with the custom extension attribute in the body of the request: -
Now, since this custom extension attribute is created without any value, you will have to update this attribute with a value so that this attribute is synchronized to the SCIM provisioned application accordingly as shown below: -
Thus, as shown above, you can add custom extension attributes to any Azure AD user and synchronize these attribute values to the SCIM provisioned app.
For more detailed information on the above, please refer to the below links: -
https://learningbydoing.cloud/blog/getting-started-with-azuread-extension-attributes/#:~:text=Go%20to%20the%20Azure%20AD,settings%20default%20and%20click%20Register.
https://learn.microsoft.com/en-us/azure/active-directory/hybrid/how-to-connect-sync-feature-directory-extensions
TL;DR
To grant admin consent to a newly created single-tenant app I need to know its Service Principal Id. Is there a way of getting the Service Principal Id of a newly created app registration when it is not listed in the results from a call to the MS Graph API ServicePrincipals endpoint?
I am using the Microsoft Graph Beta SDK to add functionality that enables users of our application to create and maintain SDS Sync Profiles.
I have a multi-tenant app registration which, given user consent, enables me to create a single-tenant app registration in the user's tenant using the graphClient.Applications.Request().AddAsync({application}) method. The process I have works fine and the single-tenant app registration is created with the necessary permissions but these require admin consent. Currently I am sending users to the adminconsent endpoint: (https://login.microsoftonline.com/{tenantId}/adminconsent) where the user can grant the necessary permissions. This is also working fine but it requires the user to log in again, having already logged in once to grant consent to the multi-tenant app. This is clearly not great from a UX point of view so I would like to avoid the necessity of the user having to log in again if possible.
I came across this post: https://winsmarts.com/how-to-grant-admin-consent-to-an-api-programmatically-e32f4a100e9d which explains how to grant the admin consent programmatically . This involves creating an oAuth2PermissionGrant object with the scopes listed that admin consent is required for.
The issue I have is that in order to add the oAuth2PermissionGrant I need to know the Service Principal Id of the single-tenant app registration just created. However, when I make a call to the Graph API to list the Service Principals (graphClient.ServicePrincipals.Request().GetAsync()) the single tenant app registration is not listed, so I have no way of getting the Service Principal Id and thus cannot create the oAuth2PermissionGrant.
Once I grant admin consent to the permissions on the single-tenant app registration, either manually in Azure AD or via the adminconsent endpoint, the single-tenant app registration shows in the results from the call to ServicePrincipals endpoint.
Additionally, if I haven't granted admin consent, and just make a call to any Graph endpoint, and, when (having logged in again) the grant permissions page is shown, I don't tick the "consent for my organization" box, the permissions remain (as expected) in "require admin consent" status, however the single-tenant app registration now shows amongst the Service Principals list.
Sorry for the long question but any advice would be most appreciated.
Thanks
David.
However, when I make a call to the Graph API to list the Service Principals (graphClient.ServicePrincipals.Request().GetAsync()) the single tenant app registration is not listed, so I have no way of getting the Service Principal Id and thus cannot create the oAuth2PermissionGrant.
That's because a service principal is not created automatically when you create an application through the APIs or with PowerShell. Azure Portal creates it for you at the same time when using it for convenience, but the raw APIs don't do that. You need to create the service principal, the only mandatory parameter is the appId (your app id/client id) if I recall correctly. Here is the documentation page for that: https://learn.microsoft.com/en-us/graph/api/serviceprincipal-post-serviceprincipals?view=graph-rest-1.0&tabs=http
Once the service principal has been created, you should be able to create the oauth2PermissionGrant objects that grant the permissions you want for all users in your directory.
I'm trying to migrate user accounts from our database to Azure AD B2C following an article and simple app that's coupled with the article -- see below.
All user accounts we have in our database used social login e.g. Google, LinkedIn and Facebook. I'm looking at the code in the migration app and I don't see any reference to user's social login. I don't see any properties for login type or anything like that.
How will I specify how the user registered in our system and has been using his/her social account to log into our app? The migration structure seems very simple i.e. just name, last name, email, etc.
I do NOT have to use this app but not sure if there's a simpler way to handle this.
The article I'm following is: https://learn.microsoft.com/en-us/azure/active-directory-b2c/active-directory-b2c-user-migration
And here's a link to the simple migration app: https://github.com/Azure-Samples/active-directory-b2c-custom-policy-starterpack/tree/master/scenarios/aadb2c-user-migration
For a social account, Azure AD B2C finds the user object using a composite key that includes the social user identifier (e.g. the "id" claim that is issued by the social identity provider) and the social identity provider name (e.g. "facebook.com").
This composite key is stored in the "alternativeSecurityId" attribute of the user object.
Currently, you can't read or write this "alternativeSecurityId" attribute of the user object using the Azure AD Graph API, which means you can't migrate the social accounts from your existing identity store using a similar method to that described in the user migration guide.
I don't see any reference to user's social login. I don't see any
properties for login type or anything like that.
About migration: Azure AD B2C can let social accounts to sign up and sign in . For your scenario, after migrating users to Azure AD B2C, the users from any social identities can sign in the Application in your Azure AD B2C. (You can also change your policy to check and set the user migration status.)
About where users information are stored: After migrating, all the users can be seen in the Users and Groups of Azure AD B2C. Additional,There is an App called b2c-extensions-app, is visible in App registrations. It is used by the Azure AD B2C service to store information about users and custom attributes.
About Login type: Also, you may want to know which properties for login type you can choose, Email address or Username. This configuration can be done in Azure Portal.
Go to Azure Portal > You B2C tenant > Identity providers > local accounts > Choose Email or User name for sign-up and sign-in.
How will I specify how the user registered in our system and has been
using his/her social account to log into our app? The migration
structure seems very simple i.e. just name, last name, email, etc.
Yes, the migration is very simple. If you want to specify how the users to sign-up and sign-in , you need to built-in Sign-up or Sign-in policies for those users. Also, you can use Custom policies.
I am developing a multi-tenant Office 365 daemon that requires access to user calendars.
I have successfully registered in the company tenant (Tenant1) that has deployed this app using certificates and I am able to get access tokens.
Now I created a separate AAD tenant (Tenant 2) and logged in to daemon app using administrator account of Tenant 2, it prompted the Admin Consent screen and I provided consent. There was no errors returned.
When I tried to get an app token however, I am able to get a token but with blank permissions. If I call the Office 365 API using this token, I get a 401.
I was of the view that service principal objects should be created. Also I am unable to see this app in Tenant 2 app registrations.
Do all my consumers have to register this app manually in their AD tenant and modify application manifest file to add certificate details?
I am not sure about the benefit of multi tenancy if that's the case.
I found the follow in the Azure Active Directory documentation:
The following diagram illustrates the relationship between an application's application object and corresponding service principal objects, in the context of a sample multi-tenant application called HR app. There are three Azure AD tenants in this scenario:
Adatum - the tenant used by the company that developed the HR app
Contoso - the tenant used by the Contoso organization, which is a consumer of the HR app
Fabrikam - the tenant used by the Fabrikam organization, which also consumes the HR app
You do not need to have each tenant register your application. In fact, you shouldn't since having dozens (or hundreds) of unique App IDs floating around would only create headaches for you.
Each tenant does however need to execute the Admin Consent workflow. This will authorize the App ID you've registered on your end to access the scopes you've requested.
Generally, I recommend using the v2 Endpoint and the apps.dev.microsoft.com portal for registering your app. While you can also register your app in your own Active Directory, the portal makes it a lot easier to manage.
The general process is:
Register you application in the Registration Portal
Populate the "Application Permissions" in the Microsoft Graph Permissions section.
Launch the Admin Consent workload using https://login.microsoftonline.com/common/adminconsent?client_id=[APPLICATION ID]&redirect_uri=[REDIRECT URI]
Get a beer
A couple of tips:
The Registration Portal only supports MSA (i.e. personal) accounts at the moment. I'd suggest creating a new Outlook.com account for this purpose so you can easily share the credentials with folks who need them internally.
If you create a shared Outlook.com account, you should also set up forwarding rules for all of the interested parties internally. This is in case something should every go wrong or change down the road and you need to recover the account.
I wrote a v2 Endpoint and Admin Consent primer that you might find helpful. They assume you're using the Authorization Code flow but the concepts remain the same for Client Credentials.
We have a multi-tenant Saas application providing sign in using our username/pwd authentication system and using Azure AD (OAuth 2.0 flows). When a user signs in using Azure AD, we can get the user's profile using https://graph.windows.net/{tenantid}/me. We want however to get more information using the memberOf or getMemberGroups operations to retrieve the user's groups in the tenants directory, to map specific groups from the tenant to an organizational structure in our application. However these operations always fail with a Forbidden statuscode. Are we missing required permissions or is it just not possible to query for the groups and roles of another tenant.
Thanks in advance
This is totally possible, but today requires that you request the "Read Directory" permission. This permission does require and admin of the tenant to consent. We are looking at adding some additional fine grained permissions for Graph API that will allow users to consent (to get group membership information).
Another option for you is to configure your application to request group membership claims (which should appear in any user or JWT token). You can do this by going to the azure management portal and getting to your app's config page. From there download the application manifest file and update the groupMembershipClaims property. You can see most of the properties in the application manifest described here: https://msdn.microsoft.com/en-us/library/azure/dn151677.aspx. Once updated, you can upload this app manifest file, and this will configure your application accordingly. Once done, AAD will issue group membership claims in the token. Dushyant has written a nice blog about authorizing access to a web app, using group membership claims or app roles. You can find it via Alex Simons blog post here: http://blogs.technet.com/b/ad/archive/2014/12/18/azure-active-directory-now-with-group-claims-and-application-roles.aspx
HTHs