I need ADFS 2.0 to tell my relying party application when current user's password will expire. Basically, I need to extract all the data from AD, using ADFS claim rules, to repeat logic of this article: http://blogs.msdn.com/b/adpowershell/archive/2010/08/09/9970198.aspx
I can access user-level AD attribute "Pwd-Last-Set" without problems (other than changed value caching for around 20 minutes), but:
I can not access domain-level attributes (like Max-Pwd-Age) from claim rules. How can I do that?
I can not find appropriate attributes for some of the data, like DomainMode.
May be there is some ready solution to this problem, which my googling skills where too weak to find?
You can only access AD attributes that pertain to the logged-in user.
For this kind of thing, I would suggest writing a custom attribute store which returns the info. you require.
Related
I need some help in understanding a basic thing or two with Token-based authentication.
My setup is a backend asp.net core app with openiddict for token auth. It's all working well so far - I now need to add user-permissions. I will have a lot of them (e.g. User can view xy, user can edit xy, user can delete xy, with many different xy-components). Backend is working well so far, my problem is now: How to get these permissions via token to my client side app..
As far as I understood these are not classical "claims" as a claim would describe "who" you are rather "what you are allowed to do" . Right?
But how can I pack them into my id_token/ How can I add them to my payload?
Second thing: Do I need to validate the token (signature) in my case? Every Api-request ist validated at server side, so basically I don't need to care if my client side permissions are tempered with, right? (As they are only for UI-Display purposes)
Thanks for your help!
As far as I understood these are not classical "claims" as a claim would describe "who" you are rather "what you are allowed to do" . Right?
In theory, nothing prevents you from representing permissions as claims, just like you'd do with roles or any other claim. In practice tho', it's rarely the best approach, because the number of actions a user can do is usually important (and often unlimited: can the user A update the product 124? And this other product?).
A possible alternative is to catch the 403 responses returned by your API when a user is not allowed to execute a specific action so you can display an adequate error message. Another one is to create an API endpoint that dynamically determines whether a user is allowed to execute the action, according to your own policy.
Second thing: Do I need to validate the token (signature) in my case? Every Api-request ist validated at server side, so basically I don't need to care if my client side permissions are tempered with, right? (As they are only for UI-Display purposes)
Both access tokens and identity tokens are digitally signed, so they can't be tempered with (at least, not easily). You don't need to validate signatures yourself, as it's already done by the validation/JWT middleware.
I'm using Thinktecture Identity Server for SSO with some apps. The idea is that account information will be stored on the server in the claims information. So groups user membership and other hierarchies can exist on the SSO server. Then when some one authenticates they would get their membership and rights passed down through claims.
My question is how can my authentication subscriber perform a user.memberOf(x) kind of lookup? I can't imagine that the whole permission hierarchy gets passed down in a users claims. I imagine that additional queries would be performed against the sign on server like LDAP. How does this work for Thinktecture? Would it be the same generally for other SSO servers? If so what's the patterns name?
A general pattern is that, yes, you pass all roles in claims. This causes issues if there is too many groups but if this is so then it could be that the role model should be revisited.
Switching to oauth2-style authorization solves the issue: you don't pass claims in roles but then the relying party queries roles with an extra call. The drawback is that if the STS is further feredated with yet another STS, such extra calls become tricky as the call would require another internal call which would possibly require yet another call etc. Passing roles in claims means that there is no need for this extra call.
Yet another idea is switching to a custom STS that would issue claim roles filtered depending on the relying party or other user attributes. This could work as usually a single RP is not interested in all roles but rather a subset that makes sense there. Your filter is then implemented at the custom STS side.
Well - IdSrv is a custom STS. You can issue claims per RP - check this article (especially the part about IClaimsRepository):
http://leastprivilege.com/2013/05/17/customizing-identityserver/
I am new to claim based authentication. I have gone throught several aricles and could not able to figure out the exact use of claim based authentication. Here are some doubts I have about claim based authentication.
I would like to know what is the difference and advantages of claim based over role based authentication.
Can we connect to Sql Server 2008 R2 using claim based authentication instead of ADFS? If, so how?
Advantage of using claim based authentication in WCF?
Can anyone provide me with some explanations, so that I can understand Claim based authentication and use with my application?
In addition - claims have nothing to do with authentication.
There is no such thing as claims- or role-based authentication. It is about modeling identity in a way your application can work with.
Roles are also claims (with a fixed true/false value) - claims just give you more expressiveness with key/value pairs.
Ultimately the main benefits to using claims include:
providing a consistent programming model for your services - you
don't need to know how to implement a particular security mechanism,
one site might use username and password
authentication/authorisation, another Active Directory. You services
don't care either way because all you are doing is processing the
claims in all instances.
You don't need to concern your self with the security
implementation. This is done by a third party.
you can customise claims to suit your domain, and treat them as an
extension to your authorisation logic - standard security properties
usually only provide you only with basic information such as roles.
You can of course extend this but then your doing much more work and
is often difficult to implement (eg. extending AD is often not so much a technical challenge but a policy constraint - admins are reluctant to modify the AD schema to accomodate a specifioc application).
Interopable - because the claims [format] are based on standards they become much more interopable between services of different languages and domains as the underlying technology for the security is abstracted.
If you are creating new .NET 4.5 WCF Services you can already start using claims as the namespace is backwards compatible with earlier security implementations, so even if you did decide claims wasn't for you now, you would be in a better position to upgrade later.
There is much more to claims than I can write here and I'm sure there will be others with additionbal reasons why considering claims might be a good thing.
Hope this helps.
We are currently looking into implementing our own STS (Microsoft WIF) for authenticating our users, and in that process we have come up with a few questions that we haven’t been able to answer.
We have different kinds of users, using different kinds of applications. Each kind of user needs some special types of claims only relevant for that kind of users and the application belonging.
Note that we do not control all the clients.
Let’s say that all users are authorized using simple https using username and password (.NET MVC3). A user is uniquely identified by its type, username and password (not username and password alone). So I will need to create an endpoint for each user type, to be able to differentiate between them. When a user authorize, I’ll issue a token containing a claim representing the user type. Is there an easier way for doing this? Can I avoid an endpoint for each user type (currently there are three)?
My token service can then examine the authorized users’ token and transform the claims, issuing a token containing all the users’ type specific claims. So far so good, except for the multiple endpoints I think?
If I need to have multiple endpoints, should I expose different metadata documents as well, one for each endpoint? Having one big metadata document containing a description of all claims, doesn’t make any sense since there is no application that needs all claims.
Update
Some clarifications.
Certain applications are only used by certain types of users. Not one application can be used by multiple user types.
Depending on what type of application the request is coming from, username and passwords needs to be compared for that user type. There are user stores for each type of application. That is why I need to know what application type the request is coming from. I can't resolve the type by the username and password alone.
Based on your problem description, it sounds like you have three indepent user "repositories" (one for each user type).
So imho this would be a valid scenario for three STS or a STS with multiple endpoints.
Another way to solve this could be to distinguish the user type by the indentifier of the replying party redirecting the user to the sts. This identifier is submitted in the wtrealm parameter.
The processing sequence could look like the following:
Get configuration for relying party (wtrealm) from configuration store (I'd suggest a database for your rather complex case)
Validate user with username, password and user type (from relying party configuration)
Add claims depending on user type or relying party specific configuration.
The datasbase/class structure for this could look similiar to this:
Need some more information to answer:
Are certain applications only used by certain types of users? Or can any user type access any application? If the former, you can configure the STS for that application to pass that user type as a claim. Each application can be configured to have its own subset of claims.
Where is the user type derived from? If from a repository, could you not simply construct a claim for it?
Update:
#Peter's solution should work.
Wrt. the 3 STS vs. 3 endpoints,
Many STS - can use same standard endpoint with different "code-behind". Would still work if you migrated to an out-the box solution . Extra work for certificate renewals.
One STS - custom endpoints won't be able to be migrated. Only one STS to update for certificate renewals.
Metadata - given that it can be generated dynamically, doesn't really matter. Refer Generating Federation Metadata Dynamically.
I've been reading about Azure's Access Control Service and claims-based authorization in general for a while now, and for whatever reason, I still don't see the rationale behind moving from role/permission-based authorization to a claims-based model. The models seem similar to me (and they probably are), except that the list of what the client can and can't do comes from a third party and is wrapped up in some sort of token, instead of from some sort of database that the server has to query. What's the advantage of getting a third party (the token issuer) involved?
I fully understand the advantages of outsourcing authentication to a third party. It allows apps to not have to create new users all the time, worry about storing passwords, etc. when they can just push that off to some other service that already has the infrastructure set up. It's essentially the DRY principle for authentication.
However, in my mind, that same logic doesn't work for authorization. Each app has its own resources it has to protect, and therefore its own rules for authorizing users to perform certain actions. The infrastructure seems simple enough that each app could create it on its own (a table mapping users to roles, and possibly another mapping roles to permissions), and even if you wanted to outsource it, it seems that the claims-based model is doing something more complicated than that.
The only partial explanation I've seen comes from Building a Claims-Based Security Model in WCF, and it gives two main advantages to claims-based auth: more flexibility, and someone to "vouch" that the information in a claim is correct. When would you need either of those?
Claims-based authorization seems to be gaining popularity, so I assume there must be some good rationale for it; I just haven't figured out what that is yet. Can someone please provide a concrete example of a situation where claims-based auth works better than role-based, and why it works better in that case?
(EDIT: I missed a third benefit listed in the article: supporting single sign-on/federation. But doesn't authentication deal with that on its own without getting authorization involved?)
I guess the main promise of a benefit from federated security / claims-based system would be one fewer area you have to deal with different systems.
Imagine a site where you have local users authenticating with Windows credentials, a bunch of internet users using username/password, others using certificates, and maybe another group of users with biometric authentication.
In today's system, you have to set up and deal with all different kinds of authentication schemes and their different ways of doing things. That can get pretty messy.
The promise of a federated security solution would be to handle all those chores for you - the STS (security token server) would handle all different kinds of authentication systems for you, and present to you a uniform and trusted set of claims about a caller - no matter from where and on which path he's arriving at your site.
Of course, just examining and reacting to a single set of claims rather than having to understand four, five, ten different and disparate authentication systems looks like a really compelling promise to me!
The purpose of claims based authorization is to allow fine grained access control based on Boolean expressions that evaluate characteristics of the accessing entity and the resource. This reduces or eliminates the need to provision groups. As with federated identity, claims also provide a vehicle for an Identity provider to manage their users wile allowing a resource provider to gate users access to assets.
Note: Claims can be used within a single enterprise and provide the following benefits:
1) Access grants and revocations do not require provisioning or de-provisioning
2) Thus changes are instantaneous
3) Resource owners can define the scope and requirements for access rather than having admins create groups manage group memberships - this moves the access control decisions into the hands of the folks best suited to make such decisions (the data owner)
4) This results in fewer groups being required and fewer member in the groups
5) There can be issues creating a single group to accommodate a large community having access (for
example all full time employees can read a HR policy) - Claims avoids this problem
6) Audit is more informative - the reason a grant or deny took place is clearly visible
7) Claims support dynamic attributes, such as 2-factor authentication, time of day, or network restrictions
There are a lot more reasons, but those ones come to mind. There will shortly be a video at www.cionsystems.com that showcases this (disclaimer - I work there and recorded the video - I still need to post it) Also, for reference, claims aware apps and platforms include SharePoint 2010 on, Windows 2012 (file shares), Azure, many SaaS services (Facebook and Salesforce)
Also, with claims you can blend information from multiple sources (say Facebook and your local AD) etc. - which is increasingly important
Not sure if the rules allow this, but feel free to ping me with your questions or comments. I'll happily edit the post to make any corrections or add pertinent info.
Claims can come from AD, databases tables, SAML, OAuth, algorithms, XACML or any other trusted provider. Harnessing claims requires a bit of kit - with apps and platforms evolving rapidly in this space.
All the Best,
Paul
Claims-based access control also helps build up attribute-based access control and policy-based access control. If you standardize on a set of pre-agreed claims that can be assigned to users based on their other attributes (e.g. a US manager can have claim U_M; a European manager can have claim E_M).
In an attribute-based and policy-based environment, it's possible to achieve fine-grained authorization (also known as fine-grained entitlements) using XACML.
In this case, you can have authorization that depends on who the user is (claims) but also what they want to do (resource information) and under which circumstances (context).
CBAC with XACML will let you express rules like:
managers can edit notes they created themselves or notes that their
direct reports created.
Role based security is a limited security model
Authorization is:
Based on role membership only
Claims based security is much more flexible and expressive
Authorisation can be:
Based on role membership
Based on Age
Based on Geographic Location
Based on an account balance
Based on a size
Based on pre-defined securtiy levels
Based on any combination of the above