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
Related
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 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'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
I wrote an application recently, which relies on OpenID for authentication. A lot of web applications these days are moving to OpenID, insofar that they already have userid/password authentication scheme, and OpenID is just an add-on. Since my application is a new one, I decided that it makes no sense to program separate authentication mechanism based on userid/password, when I can rely on OpenID for all the authentication altogether.
But sure as hell, once I presented the application to a customer, she asked "well, how do we create user accounts, and reset their passwords"? Conceptually, she didn't want to make the users create their own OpenID if they don't already have one.
I kind-of had a pre-made response to that, which was: "You can always run your own OpenID server". I guess I didn't put too much thought into this answer though, since many implementations of OpenID server are pretty raw and need a lot of work before they could be run in production.
So, my question is: does anyone here have an experience of running private OpenID server purely for authenticating of her own users. Here are the features I'm looking for it to support out of the box:
Ability to bulk-load user accounts
Self-served password resets through verification email
Administrative features (lock/unlock/disable accounts, troubleshoot, etc)
Presentable look
This doesn't directly answer their question, but how many folks are on the internet and don't have an account with Yahoo, Flickr, AIM, WordPress, Myspace, Google, or MSN? They're all OpenID providers.
I'd argue that for the tiny % of the 'net population who uses none of those services, just point them to Vidoop or MyOpenID and let them get an account with someone who already has a secure infrastructure.
This was my thought initially... But the application is for non-internet-geek type of users, so the expectation is that they may or may not have any of above mentioned accounts.
Another thing is: MyOpenID gives a neat, nice URL for you, when Yahoo (for example) doesn't. Even if you know that a person has a yahoo account, you can't just use username.yahoo.com. Google is same thing - you must first use your google account to activate a blogspot account, and then you have an OpenID, which may or many not correlate to your gogle id. So, if you have a list of users and even if you know they are all on google or yahoo - even then you can't make assumptions about their OpenID url
there are ready to use frameworks.
you only need to put them together. this can be fast done.
you didn't wrote about your platform, but if you like to use php then a look at "zend framework" or "php openid"
I'm using OpenID in my own applications but if I was to go to a customer and they raised the issue about having the passwords and stuff, I'd probably just tell them that the providers would handle that for them. If they didn't like that idea, I'd charge them the extra hours that it would take to setup the membership system. That way you get to charge more and you have a happy customer. I don't think the general public will grok OpenId for some years to come.