I have two Java wepapps potentially on different domains/servers using Spring Security for authentication. The first is handling authentication locally storing users in the application database. For the second, I would like to authenticate users using the same users accounts than the first webapp with single sign on (if a user is authenticated in the first webapp, it shouldn't have to enter his info again in the second).
I identified three potential ways to do this but it doesn't seem very straightforward:
Shared cookies: Using a shared session cookie and the same database for the two applications. It seem relatively easy to do but the two webapps need to be on the same domain which isn't necessarily the case for my applications.
Directory service: Using a central directory service (LDAP) which would be used by the two webapps to handle authentication. It seem pretty heavy to implement and the users can't be stored in the first webapp database anymore. The existing users accounts would need to be migrated into the LDAP and it would not be possible to create new users using the first webapp.
OAuth: It seem to be be possible to make the first webapp handle external authentications requests by providing an OAuth api (like Google sign on kind of service). That would allow the second webapp to use this api to authenticate the users, but I'm not sure that the signin process would be totally transparent to handle single sign on. It doesn't seem very easy to implement either, as it would necessitate the development of a complete OAuth api in the first webapp.
I also looked at this service https://auth0.com that seem to provide an authentication api that can be interfaced with an external database, but I'm not sure that it can be interfaced with Spring Security and it also mandate the use of an online solution which isn't ideal. I'm not sure that it would handle single sign on either, only shared accounts.
Is there any other way to handle this use case that would be more straightforward?
CAS is a good candidate indeed as a SSO system for your need and it has several CAS clients for Spring Security. You can try for free a CAS server v4.0 at CAS in the cloud: http://www.casinthecloud.com...
As you mentioned, a shared cookie won't work across domains.
LDAP would give you shared credentials (single name/pw works for both systems), but not single sign on, and you notice you'll have provisioning issues.
Not knowing anything about Spring Security, odds are high you won't find a painless solution to this. Integrating SSO is fraught with workflow issues (user provisioning, password recovery, user profile maintenance, etc.)
We had a classic DB managed authentication scheme. Later, when we added LDAP support, we added the capability for "auto-provisioning". This basically consisted of having the application pull down the relevant demographics from the LDAP store during login, and simply updating fields each time user logged in. If the user didn't exist, we'd create one on the fly.
This worked well, because the rest of the application had no awareness of LDAP. It simply worked with the user profile we managed already and if it needed something from the DB, the data was there.
Later, when we integrated SSO, we just leveraged the existing LDAP logic to pull from the SSO server and do the same thing.
This workflow helped a lot with provisioning and management. We could maintained the authoritative source (LDAP, SSO), and the app just kept up. What it hindered was local editing of the user profile, so we simply disabled that. Let them view the profile, but they could go to the other systems portal for management. Inelegant, but it's a rare use case anyway, so we just muddled through it. We eventually worked out two way pushing and replication, etc. but it's a real pain if you don't need it.
You can look here if you want an overview of how to do cross domain SSO: Cross Domain Login - How to login a user automatically when transferred from one domain to another
For our SSO, we use SAML v2 Web Profile, but we ended up writing our most of our own code to pull it off.
But, bottom line, no matter what the web sites say, integrating this is non-trivial. The edge cases and workflow/help desk issues that surround it are legion. And it can be a bear to debug.
Related
Good day community:
I am currently developing projects with MyBatis, Spring Security and JSF 2.2.
I've done with these frameworks, 3 projects. These projects have three different database developed in SQL Server 2008.
Then, users of each database are the same, but they are in a Users table each, ie there is a table users per database.
What we have asked is that there can be only one single sign, and thus a user only has a single username and password.
How could make for these three systems are unified into single login?
My current solution in which also I have problems is:
Create a view in SQL Server 2008 users to bring me a central database and from there access is obtained.
Create an authentication module, which at login, can see only those systems where the user has access; in this case, clicking on one of these systems, automatically enter without again login. I was thinking to login to web services.
I hope I can help with ideas or ways of solutions.
All users are retrieved from a database and systems can continue to increase, but henceforth depend on the database.
Greetings and thanks.
Have you come across the Spring SAML module before? This is Spring's implementation of SAML 2.0 authentication, designed specifically with single sign-on in mind.
One of your servers can act as the identity provider, which you can think of as the main system that the users access. They will enter their username and password into this system. The other two systems will need to be setup as service providers - when a user tries to access one of them, they do not enter their username and password. Instead, a request gets sent to your identity provider (main system), which receives and validates the request, and will then allow access if the user is signed in to the identity provider already. If they are not signed in already, it will re-direct them to the login page for the identity provider from which they can login, and will then be re-directed to the system they were attempting to access.
Sorry if that is confusing at all. Head over to here for more information about the Spring SAML module. I implemented SSO for one of my clients using this, and I can highly recommend it for ease of configuration and implementation.
I'm designing an SSO solution for my company using CAS. One requirement I'm facing that I'm not sure how to deal with is that one of the apps being fronted by CAS has a few pages considered "Highly Sensitive". While all apps should use CAS, when a user wants to access these particular pages, depending on business rules, they may be required to log in again.
I've seen something similar done in spring security using the "Remember Me" functionality to represent the broader idea of being logged in, but I would expect things to be different with CAS. For instance, assuming I've detected that reauthentication is required, forwarding a user back to the CAS login would simply allow the user to auto-login again. Or am I asking too much of CAS in this case and should I just write my own secondary login?
We are using Spring Security and it is working fine in the single web application. Now, I need to create another Web application with Spring security. In the first application the user can sell his/her stuff (e.g. EBay). The second app which I am creating now, it is for general users where he can save his general preferences, searches, save some items he looked at etc. He may/may not be the existing user. So the difference between the two users are:
User 1 (existing user): Can post his stuff for sale.
User 2: He/she should be able to login. Save his general activities etc. & if he/she wants to sell his/her item, he/she needs to go thru the additional steps for verification.
All this cannot be done in just one application due to some reasons. My question is on how to handle the security? Should I create separate security filters for each applications or is there a way to use common security implementation who can manager both of these application. Please provide your feedback, I would really appreciate it.
if you wrap both components in two different webapps, each will have his own spring security web filter infrastructure.
So in principle there will be a security session for each web application, to be backed by whatever authentication system you use.
If you use JDBC then the user would have to login twice.
If you want your customers to only login once, you can for example use a token based system.
When you cross link from webapp 1 to webapp 2, you could hook the links up to a redirect servlet.
The servlet then generates a token, persists it in a database and forwards the user with the token in the url to the other webapp.
In spring security you can then implement your own PRE_AUTH_FILTER which reads out the token, verifies if it is persisted in the Database.
For security reasons you should make these tokens only one use.
I have a couple of Java-based web applications developed. Both the applications have separate Authentication logic based on some ActiveX directory implementation.
Now, I need to change this to Windows authentication so that whenever the user hits the URLs of my web applications, instead of redirecting him to login page I need to check his Windows credentials.
I do not want to store his windows credentials in URL.
Is there any good way to do this ?
Depending on the level of integration you want your web application to have, Spring Security should have you covered in just about all aspects of what you are after.
If redirecting to a login page and authenticating the entered credentials against an Active Directory server via LDAP is acceptable, then the LDAP extension is the way to go.
If you want more of a Single Sign On (SSO) flow and your users are already authenticated against the authoritative Active Directory server in question (eg. they are logged in to the domain), then the Kerberos plugin for Spring Security may be more appealing, since your users will simply have to go to the web application and won't have to go through any other authentication steps. The systems will take care of it behind the scenes.
You can also combine / layer these approaches if you which and try Kerberos-based authentication first and if that falls through, fall back to a login form and LDAP-based authentication.
If you need to go beyond that, Spring Security is flexible enough to allow you to use OpenID or in-app authentication as well if needed.
I'd recommending using Active Directory to expose it's windows authentication layer over LDAP, which can then be hit by something like Spring Security.
This would effectively force anyone using your application to use their windows login.
I keep on facing this question from my manager how SSO will work if client disable cookies but I don't have any answer. We are currently using JOSSO for single sign on. Do we have any open source framework which support single sign on without using cooking mechanism.
In the absence of cookies, you're going to have to embed some parameter in each url request. e.g. after logging in you assign some arbitrary id to a user and embed that in every link such as http://mydomain.com/main?sessionid=123422234235235. It could get pretty messy since every link would have to be fixed up before it went out the door which slows down your content. It also has security, logging and session history implications which are not such a huge deal when the state is in a cookie.
It may be simpler to do a simple cookie test on logged in users and send them off to an error page if they do not have cookies enabled.
The CAS project passes a "ticket" from the sign on server to the consuming application as a url query parameter, the consuming app then makes a back channel request back to the sign on server to validate the ticket's authenticity. This negates the need for cookies and therefore works across domains however it is a bit "chatty"
Another arguably more robust solution is to use a product based on SAML which is an industry standard for cross domain single sign on. There are a couple of open source products out there which use SAML and CAS itself has a SAML extension however they are typically quite complex to setup. Cloudseal is also based on SAML and is much simpler to use. The Cloudseal platform itself is delivered as a managed service but all the client libraries are open source
Of course with all these solutions you are simply passing a security context from one server to another, the consuming application will no doubt create it's own local session so you would then need to use URL rewriting instead of cookies
Disclaimer: I work for Cloudseal :)