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.
Related
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
I am studying Authentication and Authorization protocols for my master thesis and I found that probably the best 2 alternatives are OpenID Connect and SAML 2.0 (actually, an European, SAML-based project in which my company was involved 4 years ago called SENSEI).
The purpose of the thesis is the extension of an existing Internet of Things system, which is basically a catalog of streams with information fetched from millions of sensors, and provide AAA (including Accounting), transforming it into an actual Marketplace of streams where people might pay to be subscribed to some streams.
So far, I think OpenID Connect will be a better choice over Sensei and SAML. Reasons are the huge amount of information, documentation, libraries and the companies which support this standard. Also is more developer-friendly and recent. However, I read the following paragraph written by OWASP in this article
While OpenId has taken most of the consumer market, SAML is often the
choice for enterprise applications. The reason for this is often that
there are few OpenId identity providers which are considered of
enterprise class (meaning that the way they validate the user identity
doesn't have high standards required for enterprise identity). It is
more common to see SAML being used inside of intranet websites,
sometimes even using a server from the intranet as the identity
provider.
So I was wondering if you, please, could help me with the following questions:
Do you think also that SAML is maybe more suitable for enterprise projects like mine? Is it true that OpenID is more user-oriented?
I have to think also about the Trust model regarding the sensors in order to be sure that they are reliable sources of information. Therefore, do you think it is a good idea to use the same protocol for: 1) the users who want to be logged in the system and 2) the devices which should prove they are trusted sources with non-faked data?
Related to the previous issue, if I could use OpenID Connect for devices, how could I make them to be authenticated without an email or password? I was thinking in the UUID as identifier but I was told it is not a good idea and also read the same on this StackOverflow thread.
Does anyone know if there exists any well-known protocol to handle or support Accounting in a system? As far as I know OpenID Connect supports Session Management but not Accounting at 100%.
Thanks in advance.
I'm not sure I can answer all your questions here... But I'll give it my best shot, based on my experience and knowledge. And, I'll say that you're being somewhat nebulous with the question (maybe you need to, so as not to expose you billion dollar idea). As such, my answer is really (admittedly) more likely to be considered a discussion point, maybe, than an "answer".
OIDC (OpenID Connect) is new, as is the IoT (Internet of Things). Enterprises are rarely bleeding edge, unless they are dragged into it kicking and screaming by a bigger enterprise partner. That being said, OIDC is built on top of OAuth2.0, so it has understanding out there, and enterprises are really in the take-up phase (IMO), and many of the purchased platforms (like my company's) support it at [current draft-1].
What I think is important to point out is that neither SAML or OIDC is "authentication". It's a standards-based method by which you can carry attributes from an authentication point to an application point that needs to KNOW who or what is connecting to it. Your users could connect one way, your "sensors" another. Or maybe both. Or maybe the opposite. If you're building the next trillion dollar social media site, do you want to limit the ways that your users can join up?
In reference to your question about OIDC and Sensors... I would suggest a certificate-based authentication system, if these things are truly just sitting out there on their own. Again, however, OIDC (and SAML) isn't an authentication system, really. It doesn't do the "front line" of the authentication - it provides a method by which an identity can be carried to the relying party based on a validated claim with a trusted partner. UUID may well be a good choice for the "username" of the device, but it certainly shouldn't be the "password".
Finally, I'm not quite sure what you're asking for with accounting. Are you wanting to charge a user for access to your IoT device streams with, say, microtransactions (interesting concept, if so). Again, neither SAML nor OIDC provide for something like this, at least as far as I am aware of. Accounting (and billing) would have to be built into the application.
HTH -- Andy
I have made a simple WCF-REST-service, published it to Azure and activated SSL with a X.509-certificate.
I'd like to setup some authentication for this service as well. I could solve this very easily by sending a credentials-header in clear text since all traffic is now encrypted, but I am planning to use some kind of federated authentication instead so that users can take advantage of Single Sign-On.
This field is relatively new and yet seems to already be littered with obsolete technology, making it difficult for someone with little experience to find current best practices and solid toolsets. I'm hoping somebody with significant experience can provide some insight and give us all an up-to-date jumpstart.
What are the modern, state-of-the-art options for federated authentication?
Is OpenId the only technology for this?
Is it difficult to implement SSO?
Can a relatively inexperienced yet reasonably intelligent developer implement this based off a few tutorials? Or are the underlying technologies too complex, making a third-party API/framework more desirable? (like DotNetOpenAuth)
For Azure and WCF specifically, is "Windows Azure Active Directory Access Control" really necessary, or would that be like swatting a fly with a sledgehammer?
Authentication, Authorization and identity federation are HUGELY complex subjects and should not be taken lightly. The reason security is a big, complex problem is that its extraordinarily hard to get right!
If you don't already have a great deal of experience in internet identity & security, don't try and roll your own auth mechanism: Correctly and securely implementing an authentication mechanism is very, VERY hard.
For example, in your scenario above, you've not accounted for ensuring that the creds you pass in the HTTP header are anonymized for each site you want to present them to and that they expire after a period of time, that they cannot be replayed, that they cannot be synthesized by a malicious 3rd party, etc.
I strongly encourage you to use a pre-existing authn mechanism and supporting framework. In fact, since you're an Azure user, the easiest way to add end-user identity federation to your site is to use the new authn features of Windows Azure Mobile Services
If you still want to learn more about identity and identity federation, I encourage you to research this subject before choosing the right type of authentication to use:
Start with A Guide to Claims-Based Identity and Access Control (2nd Edition). This will give you most of the background and knowledge necessary to understand this subject sufficiently to make sound decisions.
Once you've got a good grip on this subject, I recommend reading everything that Vittorio Bertocci has written over at http://cloudidentity.com.
HTH.
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.
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