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.
Related
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 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.
What is the best way to design a user login mechanism using Java? What are the best practices to be followed to architect a secure and robust login mechanism?
What is the difference between JAAS, JNDI and GSSAPI? How do you decide which one to choose?
Single sign on (SSO) is one of hte best practices. Using one set of credentials for authentication (not necessarily authorization) for a group of applications.
Sun's java based open source -- OpenSSO solution is available at https://opensso.dev.java.net/. This includes OpenDS, an open source LDAP server.
few things you need to consider is
1) is it OK to let the user login simultaneously from multiple computers
2) how to mix authentication and authorization info in the same LDAP server
Some patterns in this area can be obtained from the book : http://www.coresecuritypatterns.com/patterns.htm
It depends on your user referential.
You need to be able to connect your login java module with that base. it is is LDAP, you might consider framework like OpenLDAP.
Plus you have to consider what is include in your "login" perimeter: It is is an "habilitation" login process, you need to have more that just the user name, but also other parameters helping your java module to grant him access (its group, which might be in LDAP, but also the kind of action he wants to make, in order to check if he has the required accreditation level)
I really like Spring Security. It's pretty easy to set up if you've got a Spring project, of course, but I've seen parts of it integrated into other implementations.