I am looking for best architecture of authorization service, in application service layer, providing common authorization checks in services.
Ideally it should probably be single service, authorizing user to do actions on all aggregates. Things like browse lists, read/edit items, read/edit owned items, etc.
I am thinking about service with authorizing adaper for each agenda, reading solving by method on repository, but I feel I am reinventing the wheel. :-)
Have you any idea or good read/source?
What you are looking for is externalized dynamic authorization also known as attribute-based access control (ABAC). In ABAC, there is an architecture which defines a generic authorization service which you can query to obtain authorization decisions (Permit/Deny) based off of policies (typically written in alfa) and attributes such as user role, clearance, data sensitivity, etc...
NIST, the National Institute for Standards and Technology, has a great write-up on ABAC: https://csrc.nist.gov/publications/detail/sp/800-162/final
You can take a look at Keycloak, an open source tool for identity and access management:
https://www.keycloak.org/docs/latest/authorization_services/index.html
Related
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 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.
The new ASP.NET 4.5 code has "re-parented" the ASP.NET RoleProvider to a ClaimsProvider.
What I'm trying to figure out, is what would a "claims based" example of authorization look like (preferably in MVC4)? How does my Authorize attribute interact, or not, with this capability? The WebSecurity and Roles API havn't changed; there is no "DoesUserHaveClaim()" signature. Similarly, it is not clear how the Authorize attribute interacts with claims.
Was this "claims authorization" feature intended primarily for OAuth? If so, how are claims forwarded to my application? A cookie? Or was this claims-provider functionality intended for a broader use?
In short, what is the story for using a ClaimsPrincipal?
The closest thing I've seen to something that kinda makes sense, is this discussion. But I suspect that is dated - it should be compared to what the MVC4 internet project template produces. And even then, it still did not suggest how to use the Authorize attribute with the setup.
UPDATE
I've found the answers to my questions from these sources:
The remarks section of ClaimsPrincipal explains that WebSecurity, Roles, and AuthorizeAttribute APIs do in fact boil-down to claims checks as necessary.
A claims-based MVC4 example is here (along with others).
The basic SAML story is shown here.
Claims-based security helps decouple your security model from your application domain. A claim can be anything you want to attach to the identity of the user, such as an email, phone number, or flag indicating whether the user is a super user. This gives you the ultimate flexibility on how you want to setup your authorization process. Historically in an ASP.NET application you have to determine what roles you want to allow and apply them when programming your application. Then you check if the user is in the role to authorize them. This mingles your security model with your application. In claims-based you have much more flexibility and it is more typical to setup an authorization scheme that takes a resource (ex: Orders in an order management system) and an operation (ex: read, write, execute) as input parameters to your authorization process, effectively decoupling security from your application. See ClaimsPrincipalPermissionAttribute for an example of this technique.
Claims-based security is required with OAuth but it works well with other authorization schemes as well. The custom claims you use in your application are accessible from ClaimsPrincipal.Current. There are techniques to store this information in cookies as well, although the ASP.NET security pipeline does not do this by default.
The discussion you reference is for Windows Identity Foundation (WIF) which is now part of .NET in 4.5 and is why claims-based identity is a first class citizen. All of the Principal types inherit from ClaimsPrincipal. For a good overview of claims-based security look at this free ebook "A Guide to Claims-Based Identity and Access Control (2nd Edition)". A real expert in this area is Dominick Baier and his blog is chocked full of useful information on this topic. He also has a great online training course on Pluralsight called "Identity & Access Control in ASP.NET 4.5".
I'm currently developing an SOA solution, where each service in the architecture is a secure, authenticating hypermedia resource (as in really hypermedia, not RPC with pretty URLs).
Customer-facing, company-internal and customer-built applications will be built on top of this architecture (nothing unusual here). I cannot assume that there exists a common authentication pattern between applications because requirements for user identification and credential management can differ significantly.
It follows that services in the architecture must employ a separate authentication scheme. Ideally this would be completely consistent between services (for example HMAC), to allow as much client/server module re-use as possible.
My question to you is this: is there a common pattern for providing consistent authentication and credential management across decoupled services? If so, what is it?
I came up with a few ideas, but input from more experienced engineers would be appreciated:
1) Each service exposes a discrete but mechanically identical authentication interface, and is responsible for its own credential management.
2) As 1) but with shared credential management. A discrete authentication interface is still exposed for each service in the architecture, as in 1), but the underlying data medium is shared.
3) There is a single shared authentication service, which is responsible for authentication and credential management for itself and all other services.
I find idea 2) to be the most appealing, but it needs some refinement. Unless I am totally on the wrong track here.
Please criticise/suggest as much as you see fit. Bearing in mind of course that this is about design and not implementation; I'm not interested in framework/middleware/protocol XYZ at this point.
Apologies for the prose, and thanks for reading.
LDAP is --> that away to centralize credentials.
Amazons AWS authentication scheme is up and over yonder. Each app can implement that and refer to the LDAP for credentials.
OAuth is up and over here if you want to centralize the entire kit.
Just to clarify, this should NOT be a thought experiment. It's been done, no reason to redo it. Look around for standards and implement them. The things that talk to LDAP are legion. AWS is an ad hoc standard, but it does the job and answers most everyones questions, and has been vetted, found to be flawed and fixed, and is in use in the wild by many as we speak. OAuth helps solve the central authentication problems if you want to go there.
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