There is a sample that shows how to do this but you will see many comments along the lines of "I can authenticate but when I call the API I get "Authorization has been denied for this request" ".
This error is typically invoked when either the "audience" or the "issuer" is wrong.
Once you have authenticated, look at the token you received under the "User" tab e.g.
aud:https://localhost:44326/
iss:https://some-adfs/adfs
Ensure these are the values configured for "Audience" and "Issuer" in the "appSettings".
They are case-sensitive!
The sample is a badly hacked Azure AD one and still has references to this all over the place.
It is also confusing because it refers to constructs like "tenant" which mean nothing in the ADFS world.
Also the clientID is a string (as in Azure AD) rather than a GIUD that is automatically generated for you when you create the application.
It needs to be rewritten to make it ADFS centric!
The other problem is that it uses implicit flow and there are contradictory articles that mention that you cannot get extra or custom claims with this flow because it would make the query string too long?
My understanding is that to get the custom claims, you need to do a POST whereas adal.js does a GET. This requires the claims to be in the URL which is not secure and may make the URL too long.
This is a restriction of adal.js; not a restriction of the protocol.
This post suggests that you can fix the problem by proxying the GET to a POST.
Also of interest is that using the identityserver oidc-client-js stack instead of adal.js does not have have this problem. But then you lose the goodness of ADAL.
Claims rules are a huge part of the advantage of ADFS. It's a pity that they can't be used in this scenario.
Enjoy!
No comments:
Post a Comment