Seems like there are two ways to define optional claims to be included in a token. You can do it, with some restrictions (which claims) using App registrations app manifest file as per: https://learn.microsoft.com/en-us/azure/active-directory/develop/active-directory-optional-claims. However, New-AzureADPolicy can also do it and more - I was not able to add employeeId claim using the first method - but it applies to the ServicePrincipal, not the Application.Apart from what seems like a more restrictive claim list, what other differences are there between? Why are there two methods?
Related
We've created an application using SCIM 2 SDK from PingIdentity for provisioning with Azure AD. Custom mapping is set up and working.
However, when the user is CREATED, all of the fields are included in the import, but only a few fields are included in the provisioning step and sent to our application. Provisioning needs to run a second time on that user to UPDATE in order for all the fields to be included. Amongst other things, this means that first and last name are not split and it only sends the displayname (which ends up as firstname on our end).
For some users in normal provisioning, it can take days between the create and update runs so we're missing data for a long time.
Anyone know how can we can test for what's causing this and solve it so all the fields are included in the initial CREATE run for a user?
Here are the attribute mapping settings: https://imgur.com/ypfAAmD
And an example log of when the user is created with only basic fields: https://imgur.com/iOXACJh
vs. when the user is updated with all the other fields: https://imgur.com/UqDNyCv
I'm a product manager at Microsoft that works on the provisioning service and our SCIM client.
The behavior you're seeing occurs when you have attributes that are not part of the SCIM core schema included as "short" names. Attributes not defined in the SCIM core schema (RFC 7643) should have full URN syntax. Something to the effect of urn:ietf:params:scim:schemas:extension:appName:2.0:User:attributeName is commonly used by other implementations. The shaky behavior you're seeing where the AAD provisioning service fails to send these attribute values via a POST but later includes them in a PATCH comes down to different code paths in the AAD provisioning service, and the PATCH code happens to handle this differently than the POST code. This is purely by chance, however, and isn't an intentional design choice. At some future point I'm hoping we'll make this more consistent and disallow incorrectly structured attribute names entirely.
If you adjust your attribute names to align with the guidance in the SCIM spec's schema RFC and provide the attributes with fully defined URNs, you should see consistent behavior that works on both POST and PATCH.
I am using Functions version 3 with the Authentication preview.
It works well and properly validates incoming tokens against the AAD, however, I need one endpoint to be public (or with code) and this is not possible at the moment at all as authLevel in function does not have any effect on the built-in authentication.
Is it possible to make one endpoint to be excluded from the Auth?
As far as I know, we cannot set different authentication levels for different functions in the same Function App`.
As Stanley mentioned in the comments, you can create a publicly accessible Function App. You can choose consumption plan, which is billed according to the number of executions, and there will not be more costs.
I have a query about adding extension claims to an idToken using MSAL.JS 1.1.3 – it seems to work where an extension attribute was added into an AAD application but not via AAD Connect.
Is there something I need to do to ensure the AAD Connect synchronized extension attribute is included in the token?
I have the following setup with 2 extension attributes (extension_{id}customOptionalclaimApplicationUserCode (added in AAD) and extension{id}_stuExtensionAttriibute1 (added to AAD via AAD Connect from on-prem AD):
PowerShell displaying attributes
Customer wants to use manifest so I set this up.
The decoded token only includes extn.CustomOptionalClaimApplicationUserCode as per this image
The customer prefers to use manifest optional claims as per the example for least privilege per application instead of claims mapping policy.
To repeat the question: Is there something special I need to do to ensure the AAD Connect synchronized extension attribute is included in the token claims?
From your screenshot, extension_{id}_customOptionalclaimApplicationUserCode 's id is different from extension_{id}_stuExtensionAttriibute1's id.
One of the two ids is the id of the app itself. The other one is the app id used by AD Connect.
Now, the fact is that, from the API , one extension attribute is lying on an application.
However, you can only get the extension claim value from its application in a token. In other words, the resource id should be the same as the id in the extension, then you can get the extension value. For more details, you may refer to: Configuring optional claims
So, the result you got is expected. The extension synced from on premise will not be included in token.
I've got AngularJS and Web.API WAAD authentication up and running. For client side I use great library ADAL.JS. For backend I use Microsoft.Owin.Security.OAuth. This part went quite smooth.
Now I want to implement authorization based on roles (which will be mapped to WAAD groups). Groups are not included in authentication token so I must ask Azure Graph API for them. I saw various ways to do it, using custom claims providers, adding web services to project, etc. Some examples already providing mapping between groups and roles to use in [Authorize] attribute.
But what is just the simplest example of how to get a list of group ids/names from WAAD providing User ID or username, when I'm already authenticated?
Also, is there any way to get this data in JS to use in Angular frontend, or should I create an API service which Angular should call for roles info?
In the non-JS case, the simplest way of getting groups in the token is by opting in. Download your application’s manifest, locate the “groupMembershipClaims” entry, change its value to “SecurityGroup” or “All”, upload back the manifest.
However note that this won't work for your scenario, because it uses the implicit grant - here the token is returned in an URI fragment, hence a big token would risk blowing past the URL length limits of the browser.
You can always request groups to the Graph and make it available to your frontend via custom action on your API, but from what you wrote you are already familiar with that. Let me discuss the matter here - if there's a simpler route to make this work in SPAs, I'll get back to this thread.
HTH
V.
Update: I verified and in the implicit grant case you will receive groups always via the overage claim. Please refer to https://github.com/AzureADSamples/WebApp-GroupClaims-DotNet/tree/master/WebApp-GroupClaims-DotNet - it will show you how to process the overage claim to retrieve groups. All you need to do is apply the same guidance to a web API instead, and if you need to make the info available to the client expose one or more actions doing so.
I'm trying different ways of implement multi tenant AppEngine web RESTful interface.
One of them is to use part of the URL as the tenant name.
The problem is that I'm using Jersey as JAX-RS implementation for RESTful interface and I would like a url such as /tenant1/res1 to first be parsed by something that will take the /tenant1 part, set the namespace to tenant1 and then pass the rest of the URL to Jerseys' servlet for regular handling.
The something maybe either ServletFilter or Servlet or something I can't think of.
How can I implement such thing?
What are the possible problems of such implementation?
Thank you,
Ido.
I do exactly that but using Restlet. The namespace uniquely identifies the customer that a user belongs to.
The first URL fragment contains the namespace. I verify the namespace in a RESTLET authenticator (basically a filter) and when the authenticated user does not belong to the given namespace/customer I refuse to proceed.
I use the primary key of the customer as the namespace. This has the added advantage that a valid namespace/customer can be easily (mem-)cached, and I refuse any calls containing invalid namespaces.
Very happy with this setup and no problems encountered.