We Keep Coding

SSO - Central authentication Service (CAS) - for production?

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.

SSO Frameworks, which one to use? when we need?

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.

Help choosing authentication method

I need to choose an authentication method for an application installed and integrated in customers environment. There are two types of environments - windows and linux/unix. Application is user based, no web stuff, pure Java. The requirement is to authenticate users which will use my application against customer provided user base. Meaning, customer installs my app, but uses his own users to grant or deny access to my app. Typical, right?
I have three options to consider and I need to pick up the one which would be a) the most flexible to cover most common modern environments and b) would take least effort while stay robust and standard.
Option (1) - Authenticate locally managing user credentials in some local storage, e.g. file. Customer would then add his users to my application and it will then check the passwords. Simple, clumsy but would work. Customers would have to punch every user they want to grant access to my app using some UI we will have to provide. Lots of work for me, headache to the customer.
Option (2) - Use LDAP authentication. Customers would tell my app where to look for users and I will walk their directory resolving names into user names and trying to bind with found password. This is better approach IMO, but more fragile because I will have to walk an unknown directory structure and who knows if this will be permitted everywhere. Would be harder to test since there are many LDAP implementation out there, last thing I want is drowning in this voodoo.
Option(3) - Use plain Kerberos authentication. Customers would tell my app what realm (domain) and which KDC (key distribution center) to use. In ideal world these two parameters would be all I need to set while customers could use their own administration tools to configure domain and kdc. My application would simply delegate user credentials to this third party (using JAAS or Spring security) and consider success when third party is happy with them.
I personally prefer #3, but not sure what surprises I might face. Would this cover windows and *nix systems entirely? Is there another option to consider?

Go with LDAP. Access is very easy, and the only parameter you need is the LDAP Server (and ActiveDirectory is one). If the user exists and the password is correct, he will always be able to log into the LDAP server.

Solutions for Java User Account Management

I currently work on a Java web application that has relies on a permissions mechanism to manage user content. This of course means that we need to manage users. Our current user management system is an in house system that manage info about users, groups, and user and permissions in an RDBMS. The system works but is a hassle to maintain. I'd like to find a way to simplify things.
It seems that packages to manage users must be commonly used out there on the internet machine given that user management is a core piece of functionality of many web apps. What solution to you use to manage users? It seems that something like the Spring Security package may work, but I'd like to get a handle on what's available before locking myself into Spring Security.
Thanks.

You are looking for something like LDAP or Active Directory to manage your users. You would use Spring Security to apply/enforce your security information that you store in LDAP. Pretty sure you can configure any App Server to use LDAP for basic authentication and authorization features out of the box.

LDAP Best Practices

I'm interested in the best practices of using LDAP authentication in a Java-based web application. In my app I don't want to store username\password, only some ids. But I want to retrieve addition information (Name, Last name) if any exists in an LDAP catalog.

My team uses LDAP as a standard way of authentication. Basically, we treat LDAP as any another database.
To add user to application, you have to pick one from LDAP or create it in LDAP; when user is deleted from application, it stays in LDAP but has no access to application.
You basically need to store only LDAP username locally. You can either read LDAP data (e-mail, department etc) from LDAP each time, or pull it in application in some way, though reading it from LDAP is probably simpler and smarter since LDAP data can change. Of course, if you need reporting or use LDAP data extensively, you might want to pull it from LDAP (manually or with batch task).
The nice thing is that once a user is disabled in LDAP, it's disabled in all applications at once; also, user has same credentials in all applications. In corporate environment, with a bunch of internal applications, this is a major plus. Don't use LDAP for users for only one application; no real benefits in that scenario.

For general best practices with LDAP, see "LDAP: Programming practices".

If you have more than one web based application and want to use LDAP authentication then a prepackaged single sign on solution might be better than creating your own LDAP authentication. CAS supports LDAP authentication and can pull back the data you need for your application.
At my college we actually have implemented CAS as a single sign on against our Active Directory server. We also utilize CAS to authenticate our J2EE applications and are working on using CAS to authenticate our PHP applications.
We use AD to hold the users for the domain. There are certain OUs for based on the type of user. The users each have a unique ID which happens to be their student/employee ID, so applications can use that as a primary key in their databases. We have a database driven authorization method for our PHP applications. Authorization for the J2EE application comes from a value in LDAP.
Good luck with your application.

So, you want user to enter ID only, and then grab the rest of their info from LDAP? That's quite easy.
Create LdapInitial context and connect to LDAP
Do a search for the ID (it should be stored as some attribute value) -- e.g. (&(userid=john)(objectClass=user)) -- which means "userid=john AND objectClass=user"
SearchResult object would contain all Attributes (or the ones you asked)
Some LDAP implementations (notable MS ActiveDirectory LDAP) do not let you connect with anonymous user. For those you need to have a technical userid/password to connect.
As said above, LDAP is normally makes sense when you have many applications.
P.S. For feeling what LDAP is try Apache Directory Studio.