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
Related
I am currently developing a codebase for all mobile projects developed by our team.
One of the main services I'm working on is the authentication service, but I am unsure about whether to treat authentication and the user together or separated, understanding authentication as all the process of obtaining and storing the authentication token (sign in, sign up and sign out), and user as the instance of that user, all its data and all the methods linked to it (CRUD of the user and related content).
You really want to think about authentication and authorization separately if you can. For small enough project's it's worth consolidating, but the more separation you can include the better for the future.
Just to baseline:
Authentication => Who are you?
Authorization => What can you do?
Authentication paradigms are almost always (these days) external, from SAML, to FIDO2, to whatever comes next... It's going to be a moving target, and you DON'T want your authorization scheme tightly tied to it. Authorization is almost always an internal concern, and should not be tied to the flavor of the week that is authentication. Not to mention the fact that it is a near certainty that you will soon be supporting multiple authentication protocols simultaneously (you aren't already?), and embedding roles based on that auth is a messy thing at best.
Also, you are at some point going to need to do something horrible, like dumping your user database and moving to a new provider. Don't make that even messier by putting all your authorization logic in there.
Finally, testing is immensely easier when you can mock authorization without authentication. Test cases will dramatically simplify if you can "impersonate" a different role on demand.
In any reasonably large/complex product you will have multiple domain views onto a user.
Each of these views will translate into separately stored data and logic/services for each view. The key being separation of concerns.
In order to make sure the different views can be connected it is useful to have a common identifier for a user that you may want to pass between services. But you may not need to pass a lot of additional information across the services. For example the domain services do not need to know about passwords etc.
Even in your question an authentication service may be separate from an authorization service may be separate from anything else, etc.
I'm in a real build or buy struggle. GCP identity platform would serve almost all our needs.
Basically I want to build usermanagement on my own (including rbac and groups) and ONLY want to solve Login and tokens with the below requirements. I know quite a bit about jwt and authentication in general. The question I'm asking my self is just of its better to build a solution on my own or to use one existing.
Is there any alternative which supports the following:
multi tenancy (at scale >10k tenants)
MFA
social login
SSO with oidc and saml
and of course persistence (using refresh tokens)
Are there any tipps for self building? Are there any alternatives? Any direction is greatly appreciated 🙏
PS:
None of these are what I need: Ory, keycloak, okta, auth0, fusionauth, gluu
USER DATA
When you integrate OAuth there are always 2 sources of user data:
The identity data's view of users
Your own business data's view of users
I think what you are saying is that you want finer control over user data, while also externalising difficult security work.
TOKENS AND CLAIMS
The identity system should be able to include values such as Tenant ID in access tokens, regardless of which data source each value is stored in.
Similarly the User ID in your business data is also likely to be needed in tokens. This value should be provided to your APIs in a consistent way, regardless of how the user signs in, and this is managed via account linking.
DESIGNING END-TO-END FLOWS
The main thing is to think through how these will work, for both new and existing users. This detailed Curity article provides some worked examples.
CHOOSING A SOLUTION
Don't choose a third party identity system until you've designed your end to end flows and clarified your requirements. The key thing about OAuth is that it requires extensible building blocks, rather than being an out of the box solution.
Some companies start with home grown identity microservices, which can become a lot of work, but may be ok in the early days. I always recommend keeping application code portable, so that you can migrate to a better provider in future, if needed.
Are you only considering open source solutions? Azure AD ticks all of your boxes.
You should not implement security logic like authorization or authentication or encryption yourself. IMO its always better to use an existing solution - especially features like MFA are not trivial to implement.
None of these are what I need: Ory, keycloak, okta, auth0, fusionauth, gluu
Why is that? It seems to me most of those are a good option for you - especially the open source ones
I'm designing a system with REST API. REST API will be implemented using Spring Boot. The system should manage employee, product, orders information. It can be used as a standalone or as a part of some existing product ecosystem. I'm looking for some resource (book, blog, online course, etc.) to help me decide how to implement authentication and authorisation.
It's quite obvious how to do it if the system is used as a standalone product. User credentials/authorisation data can be stored in the same database next to product/employee and other data.
I'm not sure how to handle everything when the application is a part of some existing ecosystem. What if:
Someone wants to reuse existing User data store for authentication or third party service like Okta or Auth0.
Use existing data to build authorisation rules. For example authorise a person to modify product data if the person belongs to some User group.
I'm thinking about Oauth2+OIDC solution. For example Okta allows add a Claim based on Expression. User groups can be provided as Claims too. It seems Okta could be a source of both Authentication and Authorisation information. I'm not sure if it's a correct way to use Oauth2 and OIDC? What are potential pitfalls storing the authorisation data this way?
I've checked Keycloak and it seems authorisation data. can be stored there. So it's not an unusual practice to manage such a data in an authorisation server.
Maybe I should use Oauth2/OIDC for authentication only? Authorisation data (assigned roles, groups, etc.) can be stored in my application database. The application should provide means to manage the information.
I'd like to get some advice or source of information for this topic.
Thank you.
I would aim to keep OAuth data fairly small - the Authorization Server (AS) typically only needs a few fields to manage login such as Name / Email and a generated user id.
When data becomes domain specific it can become a burden to manage it in the AS, whereas in your product data it is easier to spin up custom UIs etc.
Instead the AS can reach out during token issuing to an API to include important claims in access tokens - such as roles etc. Meanwhile you don't want to expose detailed access tokens to internet clients.
The Curity web site has some good resources on patterns to meet the above requirements - here are a couple of links:
IAM Primer
Claims Best Practices
I know design is subjective. But I wanted to know if this is a good idea?
Suppose I implement OpenID connect in my application. I support sign in through multiple platforms. But now, suppose I need to maintain a database of my users for authorisation of resources on my server; or let's just say I need to store user preferences.
Is it a good idea to maintain a user's table and push data into it every time a user signs in using OpenID, or using my sign up/sign in API, using email ID of the user as the primary key (since that doesn't change) provided by OpenID?
What are some good ways to combine the two? What are some pros and cons of this?
What are the best ways to support authorisation (of resources on my server) along with authentication using OpenID/oAuth?
It is a really good question and not covered well in many places.
TRACKING USERS
In terms of sign in via multiple platforms a common pattern is to use the same authorization server for all types of login and 'federate' to different identity providers, with the following benefits:
Simpler code in your UIs and APIs
A single user id per user regardless of the sign in method
USER DATA
In the real world of business apps you often need to manage users and authorize requests via 2 sources of user data, as you indicate. A couple of my articles may provide some useful techniques:
User Data Management
Authorization Design
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.