I have external customers with their own intranet sites that have links to our web application. Once their employees have logged into their intranet they don't want them to have to enter separate credentials when they follow the links to us.
What are some options for offering a single sign on for them such that we bear the majority of the technical cost for setup and that we can use with as many customers as we want. Seems like it should be a solved problem but I have not been able to find an appropriate solution (other than coming up with something completely custom).
To be clear, employees already have accounts on our application.
You don't specify which platform you are on, but you should look into authentication federation. The idea is that their intranet site produces a security token that you trust to authenticate their users on your site.
On the Windows platform, WS-Federation is typically used. On non-Windows platforms, the SAML protocol is more popular. Security protocol can use different token formats like SAML or JWT.
After further investigation, I finally found some standard protocols for doing this:
JWT - http://www.intridea.com/blog/2013/11/7/json-web-token-the-useful-little-standard-you-haven-t-heard-about
SAML - http://wso2.com/library/articles/2014/02/introduction-to-security-assertion-markup-language-2.0/
For my purposes, I think JWT is best because it requires the least amount of effort to integrate.
Related
Kerberos, NTLM, forms, claims based, use of active directory?
Going through the difficult process of analyzing which authentication method to use for a Sharepoint build-out, and I must be honest in saying that I'm confused as to which the best use-case would be. It's going to be used as an intranet and extranet, and am wondering what authentication methods other people are using and why they chose the authentication method they did.
Many thanks!
We use claims based kerberos.
Claims based because we started with Windows authentication, but want to leave the option for enabling forms based authentication open. (Forms based authentication is not available in classic mode)
Kerberos because it allows us to overcome the double-hop problem.
Setting up Kerberos brings some additional configuration requirements. Although it may seem intimidating at first, it is well documented: http://www.microsoft.com/downloads/en/details.aspx?FamilyID=1a794fb5-77d0-475c-8738-ea04d3de1147&displaylang=en
Also claims based authentication has it's problems/limitations, but until now I didn't encounter something that made me change my mind about it.
In your case, if you want to make your SharePoint available as an extranet environment, you may want to go for claims based authentication. That way you can use Windows authentication for internal people and forms authentication for external people (customers/suppliers/...).
When making integrations NTLM is the preferred one, Kerberos is nice (and safer) but if the AD goes down your intranets and extranets wont be accessible.
So, Kerberos if you are paranoid, NTLM if you want high availability and good enough security.
Is this something that can be used for highly secure information or should it be bypassed for a single site authentication system? This may be a stupid question (as it does not sound secure) but I would like some advice.
OpenID itself is no less secure than the traditional username+password login.
Obviously, you're entrusting a large part of the security to the provider - e.g. brute force prevention, password size policy, etc.
Wouldn't use it for online banking for example, not while the OpenID protocol itself is insecure, but due to the use case.
highly secure information
Financial info? DoD Top Secret? Really secure information isn't available via the internet, only on the local network or through a VPN, which is moving a chunk of the security to the network level. Really really secure information is on a computer with no network connection...
There is the theory that the user, having just one password to use for their OpenID account, has the possibility to choose a decent strength password, less likely when they have to remember x passwords.
OpenID is technically sound, but can be baffling for some users. I recommend browsing through the responses to this question. For very private information I would be cautious about using OpenID because:
Since the login is being used so widely and so frequently there are more opportunities for the password to be accidentally disclosed. A particular worry would be if another OpenID-enabled site which the user is registered on one day asks them for their actual password...some users might enter it without thinking, not realizing that they are circumventing the OpenId security model.
If you have doubts about the security of OpenID, users might also have these doubts. From a business point of view, is it worth the risk of being perceived as insecure? (Of course, this is at least better than the other way around -- bad security being perceived as safe!)
There is a trend towards offering OpenID login on social networking sites and such, but I doubt we will see it being adopted very much for protecting extremely sensitive data.
OpenID itself is secure, however due to its decentralised nature it often assumes that three servers are "trusted". If these servers are not trustworthy then your security is gone.
For instance, if you use your own website as an identifier but delegate authentication to a 3rd party provider, then if your website, or the identity provider, or the consumer server is penetrated, then the information is not secure.
If you want to use OpenID internally, and use only your own secure server as an OpenID provider, then you should be pretty secure. But if you want people to "bring their own OpenID account" then OpenID is not the right choice.
In general, it's not really any more o less secure than normal user/password authentication, but with one major difference (IMO). OpenID allows a user to login via multiple different methods (Google, AOL, Yahoo, etc..). If someone were to crack it, they'd have to go after each individual service. You have the option to not allow certain services to participate, in the event you found one of them to be less secure.
I need to work out a way to setup the validation of the users of a web application before they've actually arrived at the site. That is, someone browses to a url, enters a username and password which is then validated against a db or whatever. They are then automatically redirected to the real web application, on a different domain out across the internet, which is passed the details of the user and which then lets them through to the site without asking for the credentials again. And this must be done as securely as possible.
What are the options available for this sort of problem?
Thanks,
What you are describing is a typical use case of intern-domain web authentication. There are multiple ways to do it,
If both domains belong to the same application/company, you can just do your authentication and then pass some token/secret to the other domain in your redirect. The other domain can drop another cookie to maintain the session. This is practically how it's done between different domains all popular websites. For example, flickr.com uses yahoo.com to login.
You can use Identity Federation if the domains are closely related (partners). Most popular mechanism to achieve this is through SAML.
OpenID can also be used (That's how you arrived at this site) if the sites are loosely connected. OpenID uses arcane login URL so it only makes sense for tech-savvy users. The regular user may easily get confused by its complicated login process and consent page.
OAuth is an authorization scheme. It's not designed for federated login but you might be able to use it.
Look up OAuth or OpenID.
Are there any open source centralized authorization services available? There are lots of solutions for centralizing the authentication information (eg: CAS and JOSSO), but what about the authorization information?
There are some really good authorization frameworks (eg: Spring Security (formerly Acegi) and Seam Security), but it seems that I have to composite these into individual tiers or services. In other words, I can't run them standalone very easily. With a SOA, it seems like it would be very valuable to centralize not just the authentication but the authorization information as well (ie: roles, permissions, rules, etc.).
Any suggestions?
Are you looking for something that supports XACML? If so, the closest to open source you can get is the OpenSSO project which has portions of what you seek.
The openly available Kerberos implementations provide Client Service Authorization as well as Client Authentication.
Read about Using Kerberos 5 on Red Hat Linux.
Hum, maybe you can use a SSO solution and create a service which returns all the authorization information (roles, permissions, rules, etc) and make each application use this service to get each authenticated user authorization information.
So I like the OpenID idea. I support it on my site, and use it wherever it's possible (like here!). But I am not clear about one thing.
A site that supports OpenID basically accepts any OpenID provider out there, right? How does that work with sites that want to reduce bot-signups? What's to stop a malicious OpenID provider from setting up unlimited bot IDs automatically?
I have some ideas, and will post them as a possible answer, but I was wondering if anyone can see something obvious that I've missed?
You have confused two different things - identification and authorization. Just because you know who somebody is, it doesn't mean you have to automatically give them permission to do anything. Simon Willison covers this nicely in An OpenID is not an account! More discussion on whitelisting is available in Social whitelisting with OpenID.
The short answer to your question is, "It doesn't." OpenID deliberately provides only a mechanism for having a centralized authentication site; it's up to you to decide which OpenID providers you personally consider acceptable. For example, Microsoft recently decided to allow OpenID on its Healthvault site only from a select few providers. A company may decide only to allow OpenID logins from its LDAP-backed access point, a government agency may only accept OpenIDs from biometrics-backed sites, and a blog might only accept TypePad due to their intense spam vetting.
There seems to be a lot of confusion over OpenID. Its original goal was simply to provide a standard login mechanism so that, when I need a secure login mechanism, I can select from any or all OpenID providers to handle that for me. Allowing anyone anywhere to set up their own trusted OpenID provider was never the goal. Doing the second effectively is impossible—after all, even with encryption, there's no reason you can't set up your own provider to securely lie and say it's authenticating whomever you want. Having a single, standardized login mechanism is itself already a great step forward.
OpenId isn't much more than the username and password a user selects when registering for your site. You don't rely on the OpenId framework to weed out bots; your registration system should still be doing that.
Possible solution - you can still ask new IDs to pass a CAPTCHA test. Just like bots can sign up with fake/multiple email addresses to any site, but fail the "verification" step there as well.
Or are we going to have to start maintaining provider blacklists? Those won't really work very well, given how trivially easy it is to set up a new provider.
As far as I can tell, OpenID addresses only identification, not authorization. Stopping bots is a matter of authorization.
Notice that unlike conventional "per site" logins, OpenID gives you an identity that potentially transcends individual sites. Better yet, this identity is even a URI so its perfect for using with RDF to exchange or query arbitrary metadata about the identity.
You can do a few things with an OpenID that you can't do with a conventional username from a new user.
Firstly you can do some simple whitelist operations. If *.bigcorp.example are OpenIDs from Big Corp employees and you know Big Corp aren't spammers, then you can whitelist those OpenIDs. This ought to work well for sites that are semi-closed, maybe it's a social site for current and past employees.
Better though, you can make inferences from the other places that specific OpenID has been used. Suppose you have a map of OpenIDs to reputation values from Stackoverflow.com. When someone shows up at your web forum with an OpenID, you can see if they have decent reputation at Stackoverflow and skip the CAPTCHA or probationary period for those users.