I've configured a Spring-based application with ADFS2.0, but I cannot retrieve users' groups.
I think it's a ADFS problem, but any ideas?
Regards
You need to configure a claims rule:
Token-Groups - Unqualified Names --> Roles
Refer: ADFS : Sending groups as claims.
Related
What's the difference between LDAP and Oauth2? Which one is easier to use and to understand?
LDAP is a protocol to access directories. You can use it, for example, to access user information for authorization before granting user access to certain resources or data.
Check the answer here to understand LDAP better: What is LDAP used for? .
If you have LDAP implemented, you can add OAuth 2 to give a user (or application), access to your resources (depending on the rules in the LDAP directory) and provide her with a token that must be sent by the user on each request.
Know that you can also use one without the other.
I'm new to OAuth2 and trying to figure out what is the best practice for the following scenario:
I'm implementing 'ToDo' web service (CRUD for 'tasks')
I'm using OAuth2 and Google as auth provider to get user details (email, name)
Now I need to implement project-specific roles for users ('admin', 'user')
Speaking in terms of OAuth2 - Google doesn't 'own' my service, so it cannot help me with storing/providing 'ToDo'-specific roles, is it correct?
What is the common/best approach to implement it, do I need to create my own authorization service where I'll need to store relations like userinfo -> project-specific role?
Well, it depends what, exactly, you're looking to do.
If you have users, and those users have specific roles that you have assigned to them already, then you're just using Google's OAuth service as an identity service. You don't need to implement your own authorization service, but you will need to keep track (typically in your own database) a relationship between the userid and the roles for that users.
If the goal is to create a service where the user can delegate specific permissions they have to a third-party service, then you will certainly need to implement your own OAuth server. This will allow the user to limit the scopes that are necessary for the third-party service to do its job.
It is easy for you to setup your own authorization and resource server rather than depending on google services. In your own authentication server you have more control over your roles and users you specify.
You can setup and authentications server using spring boot app and using dependencies like Spring-starter-security, spring-security-oauth2 and etc.
Yes, you'll have to use your own Authorization Server that can then issue tokens that have realm-specific roles associated with them.
I am running an MVC5 project that authenticates with claims received from ADFS.
For a specific claim type, I need to include a list of organizations that the user has access to see.
Can this be done by including the list as properties of the Claim, or can it be done in any other way?
If so, how can I set up this Claim in ADFS?
The easiest way is to create a multi-valued attribute in AD for each user that contains the list of organizations.
Then have a normal AD mapping claim rule.
Note that this will not produce a list in one claim, rather multiple claims.
Refer: ADFS : Multi-valued attributes from AD.
The other way is to have each organization as a security group and then make the users membersOf each group as appropriate.
You can then create a group claim rule.
Refer: ADFS : Sending groups as claims.
Spring security gurus,
I am new to spring security so please bear with me if my questions are not clear.
I am trying to implement role based access control using spring security 3.x. Individual users are stored in Windows AD without groups so we cannot simply map groups to authorities as some samples demonstrated.
So my plan is to use Windows AD for authentication purpose only, but the user <-> roles relationship to be maintained by Spring security itself.
However, mapping individual user to roles would be very tedious so my question is if possible to configure users <-> groups <-> roles in spring security but the authentication part has to be done by Windows AD?
As spring security is highly flexible I believe my requirements are achievable. Can someone give some pointers on where I should look at please?
The more details the better for newbies like me :=)
Thank you in advance.
Aaron Li
EDIT 1: To add onto my question in particular, can I utilize the Spring database tables authorities, groups, group_authorities, group_members to implement a simple role based authroization logic? But I can't use "users" table as ealier explained the user details will have to be stored in Windows AD so the authentication of the users need to be done using Windows AD.
Any advices?
Thanks
Aaron
First some clarification on the terminology: Authorities, usually consisting of roles in Spring Security, are application-wide permissions. ACLs (Access Control Lists) on the other hand, specify permissions on specific domain objects. Just as you understand the difference. AD usually contains authorities/roles, but not ACLs.
If you don't want to use the authorities from AD, you can do your own implementation of UserDetailsContextMapper and inject it in your instance of ActiveDirectoryLdapAuthenticationProvider. See the Spring Security reference documentation how to specify a custom authentication-provider.
If you want to use the tables (authorities etc) of reference schema, you can use JdbcDaoImpl to load the user details. You then have to insert the users in the users table but not any passwords since authentication is done through AD. If you want to get rid of the users table however, you must customize the implementation.
Our chain goes:
ASP.NET app with WIF -> ADFS -> and maybe Azure ACS -> Facebook, Google etc.
We have users configured in AD with roles etc. These users can log-on to AD via ADFS and get their roles as per normal.
Optionally, they can log-on to one of the ACS providers and we have a use case that stores the ACS provider's unique ID in AD. If they use more than one provider, we have more than one mapping.
So we can map the user who log ins in via ACS to their "real" identity in AD.
What we are battling with is how to deliver the full set of claims to the users who login via ACS? Typically, you just get a name, email address and unique id.
Is there a claim rule that can search AD using the unique ID? This rule would have to establish which provider they used in order to use the correct unique ID in AD.
I guess we could query AD from the application but that means we have to add the code to all such applications?
We could probably do the conversion in a custom STS as well?
Any ideas, good links, articles etc?
Your scenario might have less friction if your chain looked like this instead:
ASP.NET app with WIF -> Azure ACS -> (ADFS or Google or Facebook)
Is this a viable option?
ACS integrates best with ADFS when ADFS is acting as an identity provider rather than a relying party. Furthermore, in one hand ADFS will happily federate with external identity providers to grant access to users from foreign directories, but I don't think you can get ADFS to authenticate users from its own local AD directory using a token issued from ACS.
You can achieve this by creating a custom rule in ADFS using the Claim Rule Language in the Claims Provider Trust for ACS (see here and here for some language documentation).
But: I'm not sure if you can search the AD with the unique ID right away, as the param type used to query the AD isn't specified in the Claim Rule Language. The rule templates use the windows account name (layout: DOMAIN\USERNAME) to search, thus I'd recommend using a (custom) attribute store instead of AD itself and map the unique ID to a windows account name.
Assuming you have your attribute store set up, you can create custom rules that set the windows account name claim and enables you to query AD with the template rules of ADFS.
The custom rule would look something like this:
c:[Type == "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier"]
=> add(store = "YourAttributeStore",
types = ("http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname"),
query = "{0}", param = c.Value);
To really enable the template rules you also need to set the issuer on the newly generated claim, because they check if it comes from "AD AUTHORITY". I don't know if this is a legit approach but I do this for convenience. This requires a second rule that will look something like this:
c:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname"]
=> issue(Issuer = "AD AUTHORITY", OriginalIssuer = "AD AUTHORITY",
Type = "http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname",
Value = c.Value);
Regarding the distinction of different unique ID providers, it's your choice on how to handle it. You could create a custom rule for every provider, let the attribute store make the distinction or make generic queries to your attribute store. The documentation of the Claim Rule Language should help you here.
Note: This seems to be a topic commonly avoided in books about ADFS/WIF/Claims based Identity. This is my personal solution and it may not be best practice, it's just the most convenient I came up with. If anyone knows coverage of this particular topic: please share.
Also note: rule order matters in ADFS, the claim(s) created in the first rule are available in the following rules and so on, this is what makes this possible.
Edit: didn't see this Question was asked one year ago ... hope this answer is helpful to someone anyway.