Is it possible to have a single API in APIM that either accepts AAD token or subscription, based on what product it belongs to?
Default, this does not work, since unchecking "require subscription" on API-level will override setting product to require subscription.
So, I see two solutions.. create two APIs in APIM and place them in separate products (same backend), or write a custom policy. Is there a way to check context.Subscription.Key and match with the product subscriptions?
Should be possible by adding your API to two products:
One with subscription requirement enabled
Another without subscription requirement enabled, but with validate-jwt policy added at product level to require AAD token
Related
I would like to show Identity providers dynamically based on the tenant[ i.e OIDC domain_hint] during the Azure B2C Sign In user journey. I have referred several examples on custom policies, however unable to find a way to display/hide an IdP based on tenant. I was able to use this good example to do Home Realm discovery in custom policy using an Azure Function, but it doesn't show 'list of IdP' applicable for the tenant/domain. Other SO questions, that came close to this but didn't answer are 1, 2. Even if I serve custom HTML file from blob storage, how to show only certain Identity providers and hide some based on the tenant/domain_hint ?
Depending on the number of domains/tenants permutations, you could put that logic on the application side to execute different PolicyID's. This is assuming the number is low therefore it would be a policyID : IdPs mapping.
This is a bad solution if you have a HIGH volume of hints.
Alternatively, you could perform an API call via JavaScript to delegate populating the list of Identity Providers. Then, it would execute another self-assertive page that would trigger that specific identity provider. The flow would look like:
App (passes domain hint)--> B2C login page (JavaScript REST API on page and request list of IdP's based on previous domain hint) --> 2nd Self-assertive page (value passed from first page to initiative the correct IdP) --> IdP pages load.
You can adjust the logic in different ways to meet your needs.
You could store the tenant in a claim using claim resolvers, then have an orchestration step for each possible combination of IdPs you want and use preconditions on those steps to only execute them depending on the tenant. Hopefully that works.
I have a product published that does not requires a subscription. The 4 APIs that compose it also does not. How can I define policies on a product level?
Such policies seem to work only when both the APIs AND the product require subscription AND the request is made using the product subscription key.
Prerequisites:
API subscription switched off:
Product subscription switched off:
Product added to API:
Product has policies defined, example:
If above points are true, just call your API without Ocp-Apim-Subscription-Key header and APIM will automatically execute API and attached product policies. If you provide Ocp-Apim-Subscription-Key with correct value, like for example administrator subscription key, APIM will only execute API policies.
To reduce the frustration it is important to understand policy order execution. Read the whole article here but in short the order is:
Global scope
Product scope
API scope
Operation scope
One last thing, if non subscription product is attached to non subscription API and its policies are executed automatically, you may wonder what happens if we add second open product to the API? Policies from which product will be executed? Turns out, this is not possible (what makes sense). Attempting to add second open product will result in following error:
Have been using Azure for Single Sign On.
For group claims, during the assertion we see only the security group object ID during the response.
e4feedb1-df0e-46ff-8a02-e63474015610
Is it possible to get Group name here in response instead of groups Object ID
If (and only if) the groups in question are groups which have been synced from on-premises AD, you can configure the groups claim to include the on-premises sAMAccountName or the on-premises SID.
Note: Including the display name is not supported. (Display names are not unique, and in most organization, any user is able to create and manage their own groups, making any sort of authorization decision based on group display names a very risky proposition.)
To issue group can be done both for gallery or non-gallery (i.e. custom) SAML apps (i.e. under Enteprise apps), through the app registration in the Azure portal (App registrations > Token configuration), or directly on the app registration's Application object by updating the optionalClaims property (e.g. via the manifest editor or through Microsoft Graph).
https://learn.microsoft.com/azure/active-directory/hybrid/how-to-connect-fed-group-claims
I'm afraid that it's only supported to get the object ids currently.
You need to call Microsoft Graph to get the Group name.
If you do need this feature, upvote this post on UserVoice and it may be implemented in the future.
A similar question which is answered by Microsoft Engineer here.
I can Authenticate user in Active directory but I need to know can we authenticate a specific user in group if we have multiple groups.
Basically I am redirecting to http://[mydirectory].onmicrosoft.com and validating the user but I need to know do we have mechanism to validate a user from specific group so that I can give access according to that.
Assuming this is Azure AD (and not on-premises Windows Server AD), then you have three options to restrict access to an application via groups.
Option 1: Require user/group assignment to application
This is the only option that does not require adding authorization logic in your application.
When configuring your application in the classic Azure portal, you can set the application to require user assignment:
Then, under "Users and Groups" for that application, you can choose which individual users or groups should have access to the application.
The most important thing to consider here is that this will only apply to direct members of the group, not to nested members.
Option 2: Request group claims
This option will allow you to request that the token returned to the application after a user has signed in contain the list of groups that the user is a member of. This includes groups that they are transitive members of (i.e. nested groups).
From your application's configuration page in the classic Azure portal, you can download and upload the app's manifest JSON file. In the manifest, locate the "groupMembershipClaims" attribute, and set it to "All" or "SecurityGroup" (the latter will exclude distribution lists).
Once this is set, after the user signs in, the resulting token will have a groups claim that contains a list of group object IDs that the user is a member of. Your application can then use these claims to decide whether or not the user should have access.
Dushyant Gill goes into group claims in detail in his blog post: http://www.dushyantgill.com/blog/2014/12/10/authorization-cloud-applications-using-ad-groups/ (archive.org link)
The important consideration here is that there is a limit to the number of groups that can be returned. If the user is a member of more groups that this limit, then an "overage" claim is issued, and your application will need to make an Azure AD Graph API call to get the full list. (This is also described in Dushyant's blog post.)
Option 3: Use the the Microsoft Graph API or the Azure AD Graph API directly
The final option is to simply call the Microsoft Graph API (or the Azure AD Graph API, they both act almost identically for this) to establish if the signed in user is a member of a given group. Your application can then make the authorization decision.
There are several approaches you can take (these are all transitive checks, so nested groups are supported):
isMemberOf to check whether a the user is a member of a specified (single) group. This is the simplest if a single group should grant access to your app.
checkMemberGroups to check if the user is a member of any groups in a list of groups. This is useful if different groups grant different roles or permissions in your application.
getMemberGroups to return the full list of groups the user is a member of. This is generally not particularly useful for doing authorization checks.
I am setting up Azure API Management with 2 different products that offer different access and restrictions to the underlying API.
Ideally I would like subscriptions for each product to have a different length of time that the user can access them for before it needs to be renewed. I am not finding any type of auto-expiration date for subscriptions when I approve them.
Is there a way to do this that I am missing?
You can create product specific policies that check the time since the subscription was created and deny access if necessary. See context.Subscription.StartDate here https://msdn.microsoft.com/en-ca/library/dn910913.aspx