I´m using OpenAM as hosted SP and need to evaluate the value of one attribute in the remote IdP assertion in order to replicate the same behavior seen in LDAP authentication chain, when user filter is set to ("SpecialAttribute"="TRUE"). The attribute is available in the assertion, and I added it in SP/Assertion Processing/Attribute Mapper ,
Now I don´t know what to do. Is this, at least, the right direction ?
Any help is very welcome!
From your description I suspect you want to achieve that when the SAML response includes the attribute SpecialAttribute with value TRUE, the SAML SSO flow should be successfull and when the value is different or when the attribute is missing, the SAML SSO flow should fail.
Given this suspicion, you need to create an SAML2 Service Provider Adapter implementation and check the SAML response in the preSingleSignOnProcess method. If the attribute does not meet the criteria, throw a proper SAML2Exception
Related
I'm trying to include "groups" claims in what is returned by Okta after a user authenticates. It returns them when the response_type is 'id_token' but not when response_type is 'code'. For the Authorization Code flow I would expect to get the groups claims from the userinfo endpoint but they're not there.
However I've read that the authorization code flow is more secure than the hybrid flow (id_token) so I'd like to ensure there is not a way to do this?
My webapp is built on ASPNET Core 3 and I've tried the Okta.AspNetCore Nuget package.
One thing that might trip you up is that Okta do return the tokens you ask for, but the OpenIDConnect handler in your client blocks them.
You need to explicitly map those extra claims in your client, using code like:
options.ClaimActions.MapUniqueJsonKey("website", "website");
options.ClaimActions.MapUniqueJsonKey("gender", "gender");
options.ClaimActions.MapUniqueJsonKey("birthdate", "birthdate");
There is also this option you can set:
options.GetClaimsFromUserInfoEndpoint = true;
Do verify using tools like Fiddler the the claims actually is returned or not.
And yes, authorization code flow is what you should aim to use.
/userinfo response should contain all claims (for all flows including authorization code flow) including 'groups' as long as the groups scope is sent in the requests to mint the token.
Could you make sure the user is part of this group and the right scope is passed in the request ?
You can easily add 'groups' claim in access token as well. You can refer to the guide below:
https://developer.okta.com/docs/guides/customize-tokens-groups-claim/overview/
I am using IdentityServer4 via ASPNET Core, and I want users to access my API both by the web browser via their identity (Implicit and Hybrid), and by clients programatically (Client Credentials). I realize all I have to do is add AddIdentityServerAuthentication and I am done. However, that only solves the authentication aspect of this problem, not the authorization.
Authorization:
With ASPNET Core, you can just use Role based auth (or PolicyServer permissions which is similar) but only if you have an identity with role claims, that does not work for client credentials. So that brings us to needing to secure by role, or policies AND by scopes. How can I do this?
You cant have multiple policies, if you do, they both must pass.
You can't have multiple auth schemes, because my call to AddIdentityServerAuthentication will have to use the same authority, so how would IdentityServer4.AccessTokenValidation/JwtBearer know which you scheme challenge you are trying to pass?
Multiple requirements could work, but you need to add extra requirements on the condition that you are dealing with a non-identity access token. How can you detect what type of token you are dealing with? Is it safe to just say "If no sub, this is client creds."
Should I scrap this design and force device code flow on my users? Look at az cli it magically opens a browser, and then you can start scripting away to your hearts content. IS4 supports this with ease, especially with verficationUrlComplete
I think I have a working POC, but I am far from happy with it. https://gist.github.com/VictorioBerra/8c333a228c55d86a7c15f7f300284634
It involves basically re-implementing the default scope claim requirement handler and policyservers permission requirement handler. But thats the only way to conditionally apply the requirement handlers based on the token type.
There are at least a couple of ways of how to go around your problem of implementing role based authentication:
You might have misunderstood the fact that a client can have role claims in the client_credentials flow.
You could even have sub claim if you implemented client_credentials_custom flow and essentially bind a client to a particular user account (think of this as a service account)
I'm using Thinktecture Identity Server V3 for authentication and having a problem getting the information from HttpContext.Current.User.
I'm using an API to handle calls but when I call HttpContext.Current.User the ID is not avilable only the claims set by Identity server.
Also when I make a call through signalR the hubs HttpContext.Current.User is null and I can't get the users ID or even look at the cliams.
I'm currently using a custom user service hooked into AspNetIdentity and overriding PostAuthenticateLocalAsync and trying to use the user manager to CreateIdentityAsync but this fails.
Is there any way to populate the default claims on login and retrieve the details on a signalr connection and Web API call?
Thanks
Did you end up solving this?
I'm still pretty new to Thinktecture Identity Server, but I'm going to take a stab at this.
There is an option IncludeAllClaimsForUser on the Scope which is set to false by default. Based on what I'm reading, this option will remove the filter when calling the GetProfileAsync() endpoint.
Here's some links on where I found this info:
http://identityserver.github.io/Documentation/docs/configuration/scopesAndClaims.html
https://github.com/IdentityServer/IdentityServer3/issues/621
No I had to park it until I had time to figure it out.
I did use the IncludeAllClaimsForUser property on the scope which would populate the claims. The issue I had was that User.Identity.GetUserId() would always return null as this is now set within the claim "sub".
This was not such a big issue but when I passed through a bearer token on a signalR connection, Current.User is always null and I can't even read the "sub" claim.
Its like the bearer token is not being validated on a signalR connection so I can't get the users details.
Thanks for the help, its much appreciated.
I have a couple of identity providers that require some info set from the end user to be entered for authentication.
When user clicks on a 'Authenticate with ... ' button in Service Provider web page he gets redirected with SAML AuthnRequest to a chosen identity provider.
Then Identity Provider shows a web page where he asks to submit a form with some fields for example: Firsname, Lastname, Address and then checks if a person really lives by that address.
If check succeeded, then SAML response is returned with status Success and Firsname, Lastname, Address are returned as attributes.
If check fails, then SAML response is returned with status AuthnFailed having same attributes.
My question is whether it is a correct usage of SAML or not?
How should I properly configure it to ask for authentication every time (no session with identity provider should be established)?
You are essentially correct and it is valid use case. However, if Auth fails at the IDP, you will get a SAMLResponse message with a "failed" status (probably "urn:oasis:names:tc:SAML:2.0:status:AuthnFailed" and no user information is returned (since Auth failed).
In your AuthnRequest your SP generates, you can set the optional ForceAuthn=true attribute. If it is supported by the IDP and set to, ""true", the identity provider MUST authenticate the presenter directly rather than rely on a previous security context. If a value is not provided, the default is "false". However, if both ForceAuthn and IsPassive are "true", the identity provider MUST NOT freshly authenticate the presenter unless the constraints of IsPassive can be met." (from Sect 3.4.1 Element in the SAML 2.0 Core spec).
HTH - Ian
OK, so I'm quite new to the whole world of claims aware applications. I was able to get up and running very quickly using Azure ACS but it's been a bit of a different story when trying to use ADFS 2.0 as the identity provider (I want to actually use it as a federated provider, but for the time being I'm just trying to get a sample running using it as an identity provider).
I've been looking at the guides here and have tried to follow the AD FS 2.0 Federation with a WIF Application Step-by-Step Guide guide listed there. It takes you through setting up ADFS 2.0 along with a little claims aware sample application that you can use just to view the claims that are getting sent through.
So I can get that up and running, passing through the claims defined in the guide (just the windows account name). The problem is when I try to add any more. I can go to the relying party application in the ADFS GUI and add an Issuance Transform Rule, using the Pass Through or Filter Incoming Claim rule template. However, when I run my application, unless the added claim type is Name, it won't pass the claim through to my application.
One of the ones that I wanted passed through was the email address for the user who logged in to the application. So I added a rule to pass through the email address, then updated the web.config of the sample application to uncomment this line under the claimTypeRequired section:
<claimType type="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress" optional="false" />
Note that I'm setting it as non-optional. I also updated the federation metadata of the application to add in the following:
<auth:ClaimType Uri="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress" Optional="false" xmlns:auth="http://docs.oasis-open.org/wsfed/authorization/200706" />
I then went into the ADFS GUI, went to the Relying Party Trusts and selected Update from Federation Metadata on my sample application. So it now lists the email as one of the accepted claims.
I then went into the Claims Provider Trusts and added the email claim rule into the Acceptance Transform Rules for the Active Directory provider trust (the only one listed).
When I run the app however, it's not passing through the email claim (or any others that I try). Can somebody tell me what I'm missing here?
I should also note, I ran a test to change my application to only accept the email claim rule, and not only did it not pass through the email, but it's still passing through the Windows Account Name and the Name claims, despite the fact that I don't even list them as accepted claims for my application.
If anybody could point out where I'm going drastically wrong here, it would be seriously appreciated.
After enabling logging as per the blog post before, here are the relevant entries from the log:
Event ID 1000, "Input claims of calling principal included in details":
So you can see, the information that I'm requesting is quite clearly missing. I have the logging output set to verbose but there's really nothing of any other interest. You'll see trace records for the NETWORK SERVICE user (with the same set of claims), but nothing striking. All the log entries are informational, there aren't any errors.
If you using ADFS as Identity Provider and want it to issue an email claim, then you have to use Send LDAP Attributes as Claims or a Custom Claim Rule which access AD as the attribute store and issues an email claim. Pass through is used on the incoming claims, assuming the user is already authenticated somewhere. In case of Windows Authentication Windows account name is issued from the Kerberos token and that's why you have to pass it through, but others you have to issue.
Does Active Directory issue E-Mail Address claims? I'm not sure how to check this, but if it doesn't, it's irrelevant that you're passing them through. In this case, you'll want to try a "Send LDAP Attributes as Claims" rule; based on what I see in my ADFS instance, try mapping the "E-Mail-Addresses" attribute to an "E-Mail Address" claim.
I had to do something similar to get UPN claims to come over, in circumstances similar to yours. I'm not sure whether it will matter that the LDAP attribute is potentially plural.