This element is part of multiple samples, e.g. https://learn.microsoft.com/en-us/azure/active-directory-b2c/add-ropc-policy?tabs=app-reg-ga&pivots=b2c-custom-policy
Yet it's not explained anywhere, and it's missing from reference documentation.
It is explained in the Azure B2C custom policy starterpack.
Claims are presented to the Relying Party Application in a token
generated by CPIM. However, a Technical Policy may state, using a true
or a false for this element, that the original assertion which was
returned from the Claims Provider(s) must also be preserved so that if
needed, it can be looked at by Relying Party for auditing or
diagnostic purposes.
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.
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 working on applying a custom company security policy in my company's application.
I use the AdalJs library and I see that even if I apply the my Azure policy to the AD application, because of the silent renewing tokens, I'm not able to comply with the policy requirements.
Is there a parameter to set in AdalJs library to disable the Renewing Tokens?
If not, I'll be forced to modify the library, but it is not what I'd like to do.
Thank u in advance.
OaicStef
No, there is no such parameter we can disable token renewing. If you have a common scenario require this feature, I suggest that you submit the feedback from here.
And if it is not a common scenario, you may need to modify the source code. For example, you can modify the acquireToken function to remove the relative code about _renewToken and modify it based on your special requirement.
This question is a continuation from How to pass required claims to OpenID identity provider with Azure ACS?
Its a slightly different take on the problem though, thus I'm posting this as a new question. Note: I'm also cross-posting this to the Azure Security forum but so far haven't gotten any useful input.
The Azure ACS samples shows that it is possible to add arbitrary OpenID identity providers to ACS. But for ACS to actually be helpful in our project as an STS for various popular providers we set out to get ACS working with MyOpenID.com (again, also used in the samples). The problem, as also the good Vittorio shows, is that MyOpenID will not give us claims like name and email address unless asked for. Vittorio and others states that this is because MyOpenID doesn't support Attribute Exchange.
I'm not so sure about that, though. Digging a bit deeper into the request url that ACS generates I can see that parameters like openid.ns.ax=http://openid.net/srv/ax/1.0 and openid.ax.required=email,fullname,firstname,lastname. Also, openid.ax.type.email is typed to the axschema.org/contact/email type. This is where things go wrong with MyOpenID. MyOpenID does not understand the axschema.org types and will thus not return an email value.
What I do know is that MyOpenID understands the schema.openid.net/contact/email type. So building on this I manually changed the ACS request url to use the openid.net schema instead of axschema. Lo and behold, MyOpenID reacts and shows that my email address in fact will be returned.
Here is a list of the parameters I'm trying to pass in to myopenid.com/server endpoint:
openid.ns=http://specs.openid.net/auth/2.0
openid.mode=checkid_setup
openid.claimed_id=http://specs.openid.net/auth/2.0/identifier_select
openid.identity=http://specs.openid.net/auth/2.0/identifier_select
openid.realm=https://myazurenamespace.accesscontrol.windows.net:443/v2/openid
openid.return_to=https://myazurenamespace.accesscontrol.windows.net:443/v2/openid...
openid.ns.ax=http://openid.net/srv/ax/1.0
openid.ax.mode=fetch_request
openid.ax.required=email,fullname
openid.ax.type.email=http://schema.openid.net/contact/email
openid.ax.type.fullname=http://schema.openid.net/namePerson
Unfortunately, when the response is returned back to ACS it isn't good enough, and ACS fails with the following error codes:
HTTP Error Code: 400 Message: ACS30000: There was an error processing an OpenID sign-in response.
Inner Message: ACS90014: Missing required field 'openid.ax.value.email'.
Trace ID: f8e09e6f-0765-4370-9f03-f744cce6fa2a
Timestamp: 2011-08-02 17:12:57Z
I've tried adding additional fields without changing the original email type, but only get the same errors. I'm starting to suspect that it is in fact ACS that is not supporting AX to its full extent and that it is somewhat hardcoded to only accept claims of certain types.
The question is: does my request parameters look right to you or am I missing something obvious here?
NOTE: my initial setup is working, if I leave the ACS request unchanged and in ACS only configures a single Passthrough rule for the identity provider, I can successfully authenticate my website through ACS using the MyOpenID identity provider. The problem remains though that MyOpenID will not hand over e.g. FullName or Email to ACS if the request from ACS does not explicitly ask for the claim types http://schema.openid.net/namePerson or http://schema.openid.net/contact/email
For security reasons, ACS can't allow callers to retype the email address claim. Effectively, what you're unknowingly doing is attempting is a variant of attack 4.5 (OpenID Data Type Confusion) from this paper. For security reasons, ACS has to ensure that email address and the other AX claims it supports exactly match the types it is aware of, otherwise malicious callers could trick ACS and substitute one claim for another. It's not that ACS doesn't support AX, it's that ACS only supports a single claim type as the email claim, and it's not the same one MyOpenID uses. In short, this isn't going to work.
I am trying to validate a SAML token that was created by our WIF-based custom STS inside a REST web service.
There are a couple of functions to do validation. One is SecurityTokenHandlerCollection.ValidateToken() and another is SamlSecurityTokenAuthenticator.ValidateToken().
Unfortunately the online Microsoft MSDN help for these classes and functions is worthless and does not describe at all what it is these functions are doing.
What are these functions validating and how are they doing it? What are the differences between them? Are they automatically looking up the certificate in the Windows Certificate Store to check the signature of the token, and validating the encrypted credentials object? Because I don't pass a certificate name in anywhere. Or are there other manual operations I need to do myself to validate the token?
I realize one returns a ClaimsIdentityCollection and the other returns a collection of IAuthorizationPolicy objects. But is that the only difference? I can't tell.
I can find plenty of information out on the web about the STS and claims and even validating claims, which I am doing successfully, but I can hardly find any information on validating the token itself to make sure it is one I created.
In most cases you don't need to worry about the token validation details. All this is taken care for you by WIF.
But if you really want to know, the best source of information is Vittorio's book: http://www.amazon.com/Programming-Windows%C2%AE-Identity-Foundation-Dev/dp/0735627185
There are some details here: http://msdn.microsoft.com/en-us/library/ff359114.aspx
Another good way of learning is by looking at the extensions built to handle non-SAML tokens (e.g SWT). Download the samples here and look for the REST services.