LDAP vs MYSQL.. JA-SIG CAS with LDAP vs CAS with MySQL.
Right now we have user id, password and roles in LDAP and is working with CAS and Spring Secuirty. My firm is looking to remove the data from LDAP and to put it into MySQL. I would love to hear comments on why we should stay with LDAP.
LDAP is a directory service. It's primary purpose for existence is as a repository of security information. Trying to store this same kind of information in MySQL would basically mean replicating alot of the functionality that LDAP already provides. Typically you see corporations migrating from custom database solutions to directory services - not the other way around.
More systems, particularly legacy systems, especially on Unix, can easily use LDAP as their credential store. If you use or plan to use any of those systems, you can gain the benefit of a single source of truth and offer your users a shared credential (i.e. same username/password) across these systems.
Interfacing with SQL systems in this regard is not as prevalent.
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 trying to build a web application that will use an LDAP server on an Apache Tomcat 7.0 . Looking over the internet i have not find sufficient articles to justify why use one rather another server.
So I have turned to the more experienced guys here that have sufficient experience with more than one LDAP server.
My requirements are: To be free, easy to install and use (good gui) and sufficient API's so that i will be able to insert users, groups, perform lookups etc from a java based application. It should also provide a good level of security.
Thank you in advance for your attention
I will recommend going with openLDAP as server, UnboundID as LDAP SDK, JXPlorer or ApacheDirectoryStuido as GUI control over the ldap - this covers probably all of your requirements.
All of the above software is free:
openLDAP is probably the widely used LDAP server, if you don't count ActiveDirectory. It's well documented and can be easily supported.
the UnboundID lib is the best I have experience with, and in my opinion - most friendly and feature rich lib for LDAP out there at this moment. Check out this feature comparison matrix.
the UI tools differ in complexity - JXplorer is the simpler one.
There's plenty of LDAP servers around. I am using OpenDJ, that has been developed on the older OpenDS, and I have never had problems on both.
If you like Apache you can use Apache Directory, but perhaps the most famous around is OpenLDAP.
Concerning the API for accessing to the directory using Java, this is not a feature to be looked for in a particular LDAP server implementation, because it's standard in Java SDK: the magic word is JNDI:
JNDI does for LDAP what JDBC does for Oracle -- it provides a standard API for interacting with naming and directory services using a service provider interface (SPI), which is analogous to an JDBC driver
(source: LDAP and JNDI: Together forever, I recommend to check out this excellent tutorial)
On a Windows environment, you can also consider using Lightweight Directory Services, a small and free (as in beer) LDAP server.
Pros:
Installation is pretty straightforward
Multi master replication out of the box
It can chain authentication requests to Active Directory, usign the userProxy or userProxyFull object class.
Administrator accounts can be Windows domain accounts
Cons:
Be prepare to implement password policy yourself. It relies on the effective machine password policy, which might be more strict in a production environment for your administrators than for your users.
Ties that part of your infrastructure to Windows.
I want to know the simplest way to authenticate an application user on a database table using jaas.
Since a database table with username/hashed password is probably the most common solution, is there a "provided" LoginModule for this kind of auth?
The JDBCRealm support in Tomcat 6, comes out-of-the-box. This is probably sufficient for most needs. Note, that Tomcat also provides the DataSourceRealm to allow for authentication via a JNDI based JDBC datasource; this is better suited for applications that need a dedicated connection pool to access the authentication data source. Note that the realm implementations support the use of digested/hashed passwords; but not by default. This would require additional configuration via the digest attribute of each realm.
Glassfish also supports authentication of principals using a JDBC realm. Details for creating the realm can be found in the Glassfish Administration Guide. The guide might provide pitiful documentation on the allowed values for managing the realm - you'll these in a blog post.
If you are looking for ways to manage the underlying users in the realms, then most/all containers do not come with management tools for the same. You would have to write these tools on your own.
Also, if you wish to support digest algorithms not supported by these Realm implementation, or have the implementations work in a different manner (like adding a salt to the password, or locking out users based on a policy), then you'll need to roll out your own implementations.
Now, if you wish to use these in your application, this is usually done by specifying the realms in the appropriate deployment descriptor of your application. Assuming this is a web application, you can specify the realm used (for form, basic and digest authentication schemes) in the web.xml file.
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.
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.