I've been reviewing some example custom policies that revolve around account linking which I would like to integrate in to my own set of policies. I've found the Azure B2C documentation lacking when it comes to explaining the difference between an 'alternative security' and 'user identities'.
The account linking policies I've been reviewing interact with a user's collection of identities via a handful of claims transformations (e.g. CreateUserIdentity, AddItemToUserIdentityCollection, RemoveItemToUserIdentityCollection and GetIssuersFromUserIdentityCollectionTransformation). The only place these claims transformations appear to be documented is in a random github issue comment posted more than two years ago. All the sample account linking policies also haven't been touched in a couple of years.
On the other hand, the base policy from the default starter packs use documented claims transformations to interact with a user's collection of identities (or at least to add an entry there when a user signs up via social idp). There are claims transformations documented here that match all the user identity ones above (e.g. CreateAlternativeSecurityId, AddItemToAlternativeSecurityIdCollection, RemoveAlternativeSecurityIdByIdentityProvider and GetIdentityProvidersFromAlternativeSecurityIdCollectionTransformation).
The distinction between these two concepts is really not clear to me. Why are there seemingly two ways (along with a parallel set of claims transformations), to interact with identities?
Can account linking can be achieved using the documented alternative security claims transformations? This would go against what appears to be the recommendation to use userIdentities claims transformations with account linking, but using years-old samples employing undocumented features really doesn't fill me with much confidence.
Yes, you can use either.
They are essentially two different naming conventions that refer to the same base structure.
Refer this and this.
Related
While the Azure Starter Pack for B2C is helpful for getting started with creating custom policies, is there an actual list of built-in claims that one can reference? There are several claims that are referred in several of the files, though I have no clue of their purpose or why they're needed (for example upnUserName, nca, resource_id, etc.).
I did find some pages, such as Graph API reference or Customize Claims, though I'm not sure if these are the goto page for getting all built-in claims.
You can find list of all such claims from two places
User profile attributes documentation - https://learn.microsoft.com/en-us/azure/active-directory-b2c/user-profile-attributes#azure-ad-user-resource-type
User attributes blade in Azure Portal. The Built in user attributes are almost same for user flows and custom policies.
My team and I are handling hundreds of subscriptions that are belonging to different teams.
Many of them have different needs in terms of security, services to be used, etc whereas we, as a central platform, also make sure that everyone work with the same baseline (security, monitoring, automation, etc.).
We of course have a need to handle RBAC and we are using custom roles a lot. I was wondering if there was a way to create a custom role based on another one to benefit from "classic inheritance".
So I could create for example a role named "basic_user" that would contains a set of "Actions" and an "advanced_user" could have "basic_user" accesses plus additional ones, and so on with "super_advanced_user".
I know that Microsoft has designed it the opposite way so far, allowing us to assign multiple roles to a given individual/group, but for internal design reasons, we would like to stick to one role assignment for a given recipient (one AAD group containing all people accordingly to their role).
Is this something technically feasible/reproducible or does anyone heard about such a feature ? Or maybe is it something we should not consider because of some reasons you'd want to highlight ?
The feature that you would like to implement as you described is not currently not available as you were already aware of this. But however you can post about this feature directly via this link. It will reviewed directly by the Microsoft engineering teams and will respond.
I need users to enter a date when signing-up or editing their profile in Azure AD B2C. Is there any way to do this without using Custom Policies?
I see two options:
Use a string extension attribute with a text input. But you cannot do client-side validation...
Use 3x string extension attributes (day, month, year) with 3x single-select drop-down inputs. I think this is the way I will need to do it.
Is there a simpler way? Am I missing something?
Why not use Custom Policies? This is the only functionality I am missing using the built-in policies, so it seems like overkill to introduce the additional complexity of getting everything working with Custom Policies, just to get a valid date. Plus Custom Policies are in preview at the time of asking, so are subject to change etc.
Many thanks!
I opened a question on the MSDN forums to see if I could get an answer there.
To sum it up, you need to use Custom Policies.
My concern regarding using features in Public Preview was addressed like so:
We recommend built-in policies for most scenario's. However, for specific requirement (scenario) built-in policies may not fetch you the actual results. In that situation, you have to use custom policies. Yes, you're right, Microsoft does not recommend using preview features in production environment. It is good to be cautious and follow the recommendations.
Where can I find a list of all supported Azure AD B2C Custom Policy Claims Transformation Methods?
I have searched Google, Bing, DuckDuckGo and GitHub for such list, but can't find it.
And TrustFrameworkPolicy_0.3.0.0.xsd schema doesn't contain it.
https://github.com/Azure-Samples/active-directory-b2c-advanced-policies/blob/master/Documentation/Features%20part%206.md - does have an outdated list - some of methods like AddParameterToStringCollection can't be used - policy can't be imported when I use it.
No such list exists at this time. You should request it via the Azure AD B2C feedback forum.
Your best bet is to go through all the starter packs and see which transformations are included in those. While there might be others, if they are not referenced in the starter packs or docs, they are unsupported and not recommended for broad use.
Update!
We have released a full documentation of the schema here:
https://learn.microsoft.com/en-us/azure/active-directory-b2c/claimstransformations
All elements of custom policies for b2c, also known as Identity Experience Framework or IEF are published.
I'm trying to get my head around SSO concepts and how they fit to my situation, and I've got to the point where I'm a bit stuck. Assuming we use something like Azure AD, or Ping Identity or something along those lines, we want to enable social login (google account / facebook etc) - that is all fine. The bit I keep getting stuck on is how do I control the claims to attach to that identity?
Process (in my head) overview:
- User logs in with google (facebook etc) account, they associate the google account with their 'legacy' account (i.e. link up their social login with their internal identifier that we as a business identify them as) what what ever that process is, does not matter for this discussion (i dont think).
Now when a user logs in with their social account, how do I perform the lookup of that mapping to their internal identifier to add it as a claim, and add the related other claim for that user based on information my organisation knows about them (e.g. If they are over 21, what 'level' of a member they are etc).
I get that if we had one RP using SSO, it as the RP could perform this logic, but we have the situation where we have several internal (and potentially externally managed) systems (4-5 currently) we want to tie together using SSO - which will rely on these claims for access / personalisation etc.
The closest I have seen to this is the concept of a RP-STS - which would effectively from what I could work out sit in front of Ping / AZ AD to form part of the chain, so so it can do the internal lookup and add additional claims as necessary - does that make sense as a concept? Is that the right approach?
I'm sure this can't be un-common - but i can't seem to find any good example / documentation around the full integration (plenty on just AZ AD / Ping etc) that we need. There must be off the shelf products that can do this? (We really dont want custom SSO implementation / components if possible)
The closest I have seen to this is the concept of a RP-STS - which
would effectively from what I could work out sit in front of Ping / AZ
AD to form part of the chain, so so it can do the internal lookup and
add additional claims as necessary - does that make sense as a
concept? Is that the right approach?
That is exactly the role of an RP-STS (or "Federation Provider" in some of the literature). It sits in between your apps and multiple "Identity Providers" and is usually responsible for 2 things:
Protocol transition (e.g. your app might be WS-Fed or SAML, but Facebook is OAuth2)
Claims transformation and enrichment (e.g. add, remove, transform claims based on some logic).
There are several implementations of this with various degrees of sophistication/flexibility, and trade-offs:
Azure Access Control Service can do #1 and (somewhat limited) #2. But it is unclear whether the service has any future or if it will be subsumed by Azure AD.
IdentityServer can do all. It is OSS so you "own" it (e.g. host, operate, customize, etc). It's a great implementation, used in production, written by experts (Dominick Baier & Brock Allen) and very flexible.
ADFS can do some (limited # of protocols, proprietary claim transformation language that is complex to debug, but works). You have to host ADFS yourself. This is a MSFT product.
The company I work for offers similar capabilities too.