Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed last year.
The community reviewed whether to reopen this question last year and left it closed:
Opinion-based Update the question so it can be answered with facts and citations by editing this post.
Improve this question
Warning! I'm on a bit of a fishing trip here, and I'm not even sure if the questions that I'm asking entirely make sense. Please be kind with your responses! :)
I recently took over a project that is currently based on a Java + Linux + Tomcat + MySQL. Right now, the system is basically just a website with a few cron jobs in the back-ground to move some data around, etc. In working with the product manager to develop a prioritized backlog, it’s clear from what he wants to do that I need to start developing a service-oriented architecture (SOA <-- buzz word warning!), and I will end up with a blend of web servers and application servers. Note: I’m strongly considering moving to Glassfish v3.
Currently, authentication and authorizations are handled in Java code with user information being stored in the MySQL database. At the bare minimum, it seems to me that I will need to split this out into a separate authentication service (otherwise, will end up with a bunch of duplicate code all over the place to handle user authentication and authorizations).
I’ve been looking into single sign-on (SSO) type solutions and doing some research. From what I can gather, OpenSSO has been officially dropped by Oracle, but picked up by ForgeRock and now is called OpenAM. This appears to be very close to what I want, but since I already have a MySQL-based system, I would prefer to have something that supports it (or some other kind of RDBMS). I found this on Stack Overflow and it seems to indicate that it’s basically LDAP or nothing.
Is there a way to make OpenSSO/OpenAM talk to Database for its authentication and authorization?
My questions are:
What other options are out there to OpenSSO/OpenAM? Is LDAP the way to go? Note: doing a “OpenAM vs” google search doesn’t yield much. Do people tend to just “roll their own”?
Any thoughts/suggestions/links on this topic that will help educate me will be greatly appreciated. Thanks in advance for your patience and help.
Are you integrating existing applications, or do you just want to support your own applications?
Are you looking for actual SSO or simply shared credentials? SSO is logging in to a single application, and having that credential propagate to another application (such as logging in to Gmail and being automatically logged in to Blogger). Shared credential is you can use the same login name and password across applications, but the credential itself is not automatically propagated.
LDAP is a common system used to manage a shared credential. Many systems allow you to point their authentication store to an existing LDAP server.
For example, if you had several apps deployed in a Java EE container, and also, say, an email server and web based email client, all of these diverse applications could be pointed to the same LDAP server and your users would have a single login and password for all of the different systems, all written in different languages, all deployed on different machines. This is a bread and butter use case of LDAP, and pretty much every system can handle this out of the box. Glassfish and Tomcat can both readily validate against an LDAP server. So can Apache (Web server), Postgres (Database), Postfix (email), etc. etc.
So if you want simply a shared credential, you get that "for free", right now, by installing an LDAP server. LDAP is a bit of a different beast than something like a DBMS, but once you study it a little and "get it", it's really quite nice. OpenLDAP is a popular LDAP server, but I'm partial to ApacheDS.
The way to set that up in a Java EE container is to set up a "Realm". GF and Tomcat both have LDAP realms out of the box, I imagine the rest do to. But the nut there is that you need to use Java EE security to leverage the Realm.
See, the detail with a Java EE Realm is that it's an aspect of the CONTAINER, not the application. Just like a connection pool is a container resource that your application leverages. Most people want security to be a part of their application, where they feel they have more control over it.
That's all well and good until you start getting a bunch of different applications and everyone is configured differently and has separate user lists, and password policies, etc. etc.
LDAP can fix a lot of that, since you configure them all to use the same credential store.
The Realm fills that need on a Java EE server. Your application is configured to use a Realm provided by the container. If you have several applications, and a single Realm, then they all get to share the credentials within that Realm (regardless of the Realm type).
Realms can be anything: file based, db based, LDAP, etc. Realms also cluster if the container clusters (which can be handy).
The dark side of Java EE security, and why most apps avoid it is that, since, again, the Realm is part of the container, and not the application, it can be a little ungainly to use, and perhaps not offer the features you like in terms of user management, password policies, etc.
But the bright side of Java EE security is that once you're under its umbrella, you can leverage the credential all over in your code easily. A person logs in to the web site, and that credential can be used there in the web app, or automatically propagated back to the EJB tier (ever a remote EJB tier), and the information is always handy.
You can point your web apps at a realm, you EJBs, your web services. They all leverage the same pieces.
In order to get kind of the best of both worlds is to leverage container specific mechanisms to access the containers security. This is the other dark side of Java EE security.
Things like Realms, and direct access to container security are not portable across containers. GF does it different than Tomcat does it different from WebLogic. It's all really close, but differs in details so your code won't port seamlessly.
The bright side is for in house apps, most folks simply leverage the container they have, put a reasonable abstraction around the container dependent code, and call it day noting that yes, they will have to port this if and when they move to a different container. But, in practice. much like a database, once a container platform is chosen, folks tend to snuggle in tight and stick with it.
Finally, Servlet 3.0 (In GF3 and Tomcat 7) standardizes more of the programmatic login issues to make them more portable across containers, but the underlying concepts are the same.
Now, SSO.
SSO is a different beast. But, out the gate, both GF and Tomcat support SSO for web apps. This lets you log in to one web app and have be able to easily access others without having to log in to them. But the SSO is a little bit limited since it relies more heavily on the container security and its lifecycle, rather than a more flexible one under the control of the application. Mind, not just on Realms (that's a given), but on the actual container based FORM login, rather than a custom programmatic login. FORM login is not spectacular, but it's functional and it works. Implement a Realm, deploy your apps to a single instance of Tomcat or GF (or a cluster in GF 3.1), and you get SSO for free, so if that's important, it's kind of nice really. It's usability is fine for back office apps, but not perhaps the public internet.
If you want a more sophisticated SSO solution, then you need look at custom implementations. OpenSSO is one of those, and it relies on SAML and the SAML web profile. However, there are others. There's CAS, Atlassian Cloud, Kerberos, and OAuth as well. Those are all using different protocols than SAML. If you want to stick with SAML you can also look at Shibboleth, or even SimpleSAML (SimpleSAML is a PHP server that acts as a SAML Identity Provider, among other things, but you still need a Service Provider within your applications).
Whatever protocol you choose, the process is basically the same (detailed here -- Cross Domain Login - How to login a user automatically when transferred from one domain to another).
But the devil is in the details. And, boy, are there devils.
All of these systems are complicated. SSO is complicated. For example, now that you have Single Sign On, what about Single Sign Out? What about Single Time Out? What about credential changes while users are logged in? What about an STS (Secure Token Service) for your Web Services? (STS offers a similar delegated authentication mechanism for web services.)
SAML introduces you to a whole lot of new vocabulary, and a lot of configuration. It's not readily picked up since the documentation isn't stellar and relies a lot on standards documents which talk to a higher level of generic things, and not to you and your application specifically.
If you don't need really need SSO, then you'll likely be content with something like a central LDAP store and going on from there.
All that said, as an example, our applications support both a DB and LDAP backend. They use Glassfish, and Java EE security. We completely control the user experience. We also support SSO via SAML (we wrote our own Identity and Service Providers), and we have both shared credentials via LDAP and SSO across Java and other applications, using our code and third party code. The bright side is this is all standards based. The dark side is that standards are communicated in english, and english is subject to interpretation.
I say this simply to say it can be done. I have also written ad hoc, back of the napkin SSO implementations, both same domain and cross domain (same domain is simple with a shared cookie) using simple Servlet Filters. Password policies, password recovery, keep alive timers, multiple window timeout and session management (that's a hoot), roles, privileges, etc. etc. Been there, done that.
Also, I would be remiss to not mention Spring and Spring Security which offers all of this on top of Spring. I have not used it (I'm not a Spring person), but those folks do know what they are doing so it's worth looking at.
Please note that "Is there a way to make OpenSSO/OpenAM talk to Database for its authentication and authorization?" is phrased wrong. The question details and answers only deal with the authorization aspect. OpenAM works great with a MySQL database of users and passwords (authentication), and can use it's hidden/embedded LDAP server for storing policies and other settings.
It sounds like you still need to flesh out your security model, but you will likely find you do not need something like OpenAM at all, and can just use container/framework provided security.
This list might provide a good starting point:
http://en.wikipedia.org/wiki/List_of_single_sign-on_implementations
with JOSSO and Shibboleth springing to mind.
OpenAM has two separate stores, a User Store, where users and all the accompanying properties are stored and a Configuration Store, which holds the configuration. There is a database User Store, which is available in OpenAM however I have never tried it. The SO question you were pointing to was referring primarily to the config store, which while LDAP only, is embedded in OpenAM (so doesn't require direct management).
Personally I am a fan of Tomcat over Glassfish, as it is a fast and light Servlet container, without all the associated bloat which goes with a full J2EE container.
You can use OpenAm with RDBMs. I am using JBDC based user store in OpenAm
OpenAM seems to have the ability to plug in your own authentication module.
Presumably, you can make your DB calls from within your extentsion of the AMLoginModule.
I have successfully build a custom user repository for OpenAm. Since this question have not been active for a while and because it would be too long to describe in details here how to do it, I will just give a few hints. If you need help on specifics, fell free to ask me.
Your basic entry point needs to extends com.sun.identity.idm.IdRepo.
You need to register your custom repository using ssoadm.jsp?cmd=add-sub-schema.
From this point, your repository type will be listed among the other types when you create a data store for a realm.
Good luck !
Related
Do people use Central authentication Service (CAS) on Banking / financial service projects ? Is it a reliable framework for production use.
Updated:-
The user details are stored on Active Directory but it is not related to windows logon.
We have around 5 different related web application (separate wars) which may have common users. We are planing to implement one common web application which takes care of the login mechanism using spring security. And this application would pass the Spring security context to all other web apps which would also use spring security.
Along with this we also use 2 factor authentication.
After making some searches it seems CAS would help to achieve SSO (along with Spring Security) but I am just trying to ensure if it can be used in a Financial services projects production system ??
Note there are two major types of Single Sign-On (SSO).
There is what I call "Enterprise SSO" which uses the Mircosoft Active Directoy credentials the user used to log into their workstation to also access other resources like websites using the builtin SSO feature of browsers like IE. The underlying protocol used is Kerberos or NTLMv2 (aka SPNEGO to NEGOtiate Kerberos or NTLMv2). This makes it true "single" sign on because the user only enters their password once when they log into their workstation. There are not many solutions that can do this type of SSO. Obviously IIS with IWA turned on is one.
Then there are numerous other solutions for websites that actually redirect the client to another central website that authenticates the client and then redirects them back to the original site with some kind of token. This type of SSO is commonly used on the Internet (like when you log into stackexchange using your google credentials) but it is also not entirely uncommon in an enterprise environment. It is popular in academic institutions where students use whatever computer they can find and aren't logged in with domain credentials in the first place.
So in an enterprise environment like a bank / financial institution my opinion is that "Enterprise SSO" is the most direct and therefore superior solution. With the non-Enterprise SSO solution the authentication step usually requires a password so it's not really true SSO. You have to log into the workstation and then also login to the SSO central website and then you have access to any sites that participate in that particular SSO solution. And it requires running an extra service.
But don't Google for "Enterprise SSO" because everything is marketed as "Enterprise". Use search terms like "Kerberos", "NTLMv2", "Active Directory" in concert with "SSO" and your server programming environment.
I work for a huge company in Germany (not the one currently listed in my profile), with 300k+ eployees. We use CAS for a number of applications but our main strategy is SAML. The main reason for SAML is the "front channel" - you can reliably pass assertions via browser.
This has huge advantages in a large enterprise since very often parts of the network are firewalled so the "back channel" solutions (like CAS) don't always work.
With SAML, you could for instance use a completely external service like Salesforce with your company's SAML identity provider. Almost out of the box.
Please note that my production knowledge of CAS is ~4 years old. I might be wrong about the "back channel" for CAS, please recheck that.
Ok, few further insight related to your question update.
We use AD as user directory too.
Our identity provider (basically where you login) implements x-factor auth (SMS and token services).
We use standard SAML solutions, we don't implement proprietary things.
Sorry I did not mention it before - I'm not in finance/banking but we have apps in a very wide range of security requirements.
I know peopla who use CAS in the financial sector. Howere, it's not the subject area that matters, it's seqcurity requirements that matter.
I have had positive experience with Spring Security in the past, but it is not the tech of choice in the current company (more JBoss).
CAS is surely a good thing and will definitely work. However it's normally not the technology which fails it's how you use it in context. If you don't have extensive experience, in the area, get a consulting or a professional pentest. Too many things can be done "a little bit wrong" and lead to severe consequences.
I'm writing all this - and I'm even not a security professional, I'm an architect who designs these apps to fulfill (among magnitude of other things) their security requirements.
I'm the Chairman of CAS and founder of CAS in the cloud (https://www.casinthecloud.com).
CAS is a web SSO and it supports Kerberos and SPNEGO. So yes, it can be an Enterprise SSO as well.
CAS is production ready: for a big company, I use it for millions of users and hundred of websites.
I'm not sure to fully agree with the "back channel" / "front channel" stuffs. SAML is a standard for federation so if you have two main organizations with their own SAML IdP, you'll be able to federate identities. For other use cases, I prefer CAS which is far more simple and has a large community with a lot of CAS clients.
You normally use a SSO inside a large organization. It allows members of the organization to login into any internal application with same credentials with a single place for password management. But in this use case, the organization has full control on the CAS server and can be confident in it.
I am currently using Oracle ADF (which is an end-to-end Java EE framework) for building my web applications and GlassFish 3.1 as application server.
The latter supports JAAS (declarative inside its admin console). So, I have created a security realm and mapped them with the roles declared in a configuration file and use JAAS to implement the authorization and authentication security features.
Everything fine, until now! This past weeks I have been researching on Java EE security.
What I've found is that JAAS is good enough if you stick with "basic" security. Moreover, it seems that JAAS (as part of the Java Security Framework) was meant just for Java SE (but since Java EE is built on Java SE, some of it’s modules are being reused, such as LoginMethod and Callbacks).
Then, I've found many posts about JASPIC, finding out that it can be implemented only by a programmatic manner (not a problem) and it's not yet fully supported by app servers vendors, and tried to make a comparison between both. Even if JASPIC1.1 release had resolved some issues, like:
The container will however not fully remember the authentication. The
SAM is still called at each request, and the SAM still has to
re-authenticate
(it doesn't sound so good to me).
Then, I've passed on looking for integrating some security framework. The most famous ones seems to be "Spring" and "Shiro". Of course each one of them has it's own characteristics (may be the first is more suitable on a specific situation while the second in another). What's more important to me at the more are:
Authentication
Authorization
Session Management (and possibly, encryption)
But, everywhere I found contradictory conclusions. The result: I'm more confused now then before searching.
I am just a novice in topics like security, and moreover I am a developer (I have stuff to implement), so it's kinda hard to keep up to date with every new release and the progress on security seems to keep going on every day galloping.
I'd like some facts based on personal experience if possible. Every hint or suggestion is appreciated. I want to be sure I'm confident before taking the implementation step.
JASPIC is the one technology that being a part of Java EE integrates really well with it.
The fact that JASPIC authentication modules don't automatically remember a session is an advantage too as it makes them suitable for stateless applications too (think APIs such as JAX-RS). When you authenticate and do want sessions, then just put the result (username + groups) into the session. Then at the start of each "validateRequest" method do a quick check if there's anything in the session and if so give these to the container again. No need to authenticate from scratch and certainly no need to remember any password!
Shiro and Spring Security are very full featured frameworks. You can barely compare that to JASPIC which is very low level and basic. Both Spring and Shiro don't perfectly integrate with Java EE. Spring Security is often said to be more complex than Shiro.
Hope this helps
The Servlet profile of JASPIC requires that the configured (for the app) Server Authentication module(s) (SAM) be called on every request; exactly so that the SAM will be able to manage authentication sessions (should that be desired)
The profile also supports the case, where a SAM is configured to perform authentication, but then wishes to delegate authentication session management to the encompassing container, which is enabled by the used of the registerSession callback property.
Also as noted by Mike Braun, the profile also supports a stateless mode wrt to authentication sessions, and is fully integrated with the container authorization system; such that JASPIC authentication must occur when the target request is covered by an authorization constraint (such as would be defined in web.xml or by use of the ServletSecurity annotation).
The JASPIC defined Callbacks and the container provided Callback handler, allow a portable SAM to set the container caller principal, to consult the container's user registry for password validation and group assignment, etc.
OAuth is obviously a godsend when it comes to doing single-sign on, although there are doubtless headaches involved in merging different applications' user databases, but we also have a customer requirement to support Active Directory. Can anyone suggest any suitable architectures (or indeed resources/information on the web) for having multiple websites achieve single sign on, using both OAuth and Active Directory? It's conceivable that one domain could be set to be either one or the other, but the ideal would be that we cope with both (e.g. attempt AD auth and fallback to OAuth if not, perhaps?).
We're a primarily Java-based development house, with rich-client web front-ends. We do use EC2 for some of our apps, but also host on our own servers. Ideally any solution would not care about the location of the application itself.
All suggestions and opinions welcome.
You might consider some form of identity federation using SAML-P or WS-Federation.
ADFS in Server 2012 R2 comes with OAuth2 support. Or you could look into AuthorizationServer.
But it might be worth reading this, first. Good luck!
I have been looking about SSO [Single Sign On] solutions around StackOverflow and in Google.
The concept is pretty much simple as "Once logged in, logged in everywhere"
Now my question is, as there are many different frameworks, do we really need such frameworks or can we implement simple SSO solution based on fundamental concepts or in which case we can choose what?
Two Cases:
Internet, where we expose our web applications over internet to
wide-range of people/customers, where we can have multiple domains,
multiple servers.
Intranet, where we expose out web applications over
intranet/internet to limited range of people. A better example could
be A SSO for Employees within Organization
A case where I am lying myself to find a solution.
I want to implement a SSO for employees of my organization, where they
can login to once, they will be automatically logged in all other
applications like [mail/chat etc..].
Primarily we use LDAP for User
Credentials Management. Being said that, now each application can
login by validating user against LDAP and go on.
Or
We can have a
single web application which will communicate with LDAP to login and
work as SSO with other applications talking to it.
I am making two options here.
Using one of the frameworks [OpenAM/JOSSO or any other if it's good
and fit enough for my requirement], which uses my own authentication
[my own jar which takes username and password and returns authorized
or not]
Using my own web application, which uses my own authentication as I
said and holds public/private key-mechanism [OpenPGP], and
communicates back and forth with other applications and cookie
management.
Which option is far better for my requirement, or an overview in which case we can opt for which framework?
Building your own implementation is a bad choice for at least two reasons:
others can't easily integrate with your sso provider
you can't be sure that your protocol has no hidden issues
Picking a builtin framework on the other hand is not as important as it sounds. The most important thing is to pick a well established protocol, to name three: OAuth2, SAML2 and WS-Federation.
Picking a protocol between these three leaves you with a decision: either to pick an existing implementation of the protocol or to write a custom one. The first option is of course easier to maintain and safer, create a custom implementation only when you are 100% sure that existing implementations do not fulfill your requirements.
All mentioned sso protocols work by making one particular application in your environment the identity provider. The IdP knows where to find the user backstore and how to validate credentials and other applications trust the identity provider. The difference between protocols is how the trust relation is implemented. In short, the trust in oauth2 consists in a direct calls between the application server and the identity provider server whereas ws-federation and saml consist in passing a digitally signed xml, a token which says who the user is and what roles he/she has.
I want to implement a SSO Framework. My requirement is thus:
Once a user log's into particular website and he clicks on an external link, he should not be asked to verify his credentials again.
EDIT: Here, I have control over the 'external link' that I speak of. The first link that the person sign's into can provide me credentials or other information that I require, but I have no control over it.
I researched a bit, and found CAS to be relevant for my requirement. But, I don't want the end user to login to CAS initially, I need a framework that receives the credentials from the currently logged in website and uses the same to login to the other external site. Security is, of course, an important factor. Can you please give me some pointers/ ideas as to how to go about designing such a framework?
Based on what you're describing, it sounds like an Identity Provider (IdP) initiated SAML profile would meet your requirements (a good visual representation of this is here). The original web site your user is logged in to will function as the Identity Provider. Once a user is authenticated with that application, they will then be able to access your external application by clicking a link. Instead of being directed to a log in page for your application, the original app will instead forward the user's authorization details via SAML to you where the signature will be verified and possibly checked with the identity provider. If everything checks out, the user will be redirected to the requested resource from your app without having to sign in.
Note, that the above describes the protocol of the SSO. There are many different frameworks that support SAML that you can use. Two that you can research are Shibboleth and, as already mentioned, OpenAM.
This is a rather simplified explanation based on limited details, but hopefully it will help lead you towards a solution. I would recommend doing a good bit of research on the protocols and frameworks available before making your decision. Also, a proof of concept never hurts to prove out the solution will work for you before investing in it to a point of no return.
Good luck.
OpenAM should help you:
OpenAM provides open source Authentication, Authorization, Entitlement
and Federation software. Through OpenAM, the community actively
continues development of OpenSSO.
OpenAM provides core identity services to simplify the implementation of transparent single sign-on (SSO) as a security
component in a network infrastructure. OpenAM provides the
foundation for integrating diverse web applications that might
typically operate against a disparate set of identity repositories and
are hosted on a variety of platforms such as web and application
servers.
On the wikipedia page List of single sign-on implementations you can find a list of SSO implementations, there is a column indicating the licence.
Read about jboss sso from here.