I am working on a java application having Database authentication using spring-security.
It is very usual that, this application is used with other applications on similar domain.
Requirement: The need is that all such partner apps should be able to share common authentication with my application.
Also it is required to continue supporting DB authentication as well.
One way I found is to embed LDAP server like ApacheDS in my application so that other partner apps can use it to get authenticated.
In this case, I need to load ApacheDS with related Database records and keep it in sync programmatically.
But disadvantage on this is to have redundant copy of authentication data - one at DB and another at ApacheDS LDAP.
Question: Is there any way to avoid such duplication. By googling, I found option of having virtual directory server Penrose or Oracle Virtual Directory. But unfortunately they cannot be embedded in application. Is there any way to provide embedded LDAP support on top of existing Database authentication?
Disclaimer: I know very little about Spring Framework and even less of Spring Security
Having said that. I did face a similar situation, in my case, it was Apache DS as my app authentication source and client AD as the other.
My deployment environment was Tomcat and I used Tomcat Combined realm, which nests more than one realm for authentication. My app realm was configured to be one and client's AD was configured to be another.
Users could authenticate from any one of the realm, it worked. However, I did have to replicate client's AD users every night (including AD tombstones to mark them inactive), for authentication is one thing but other client information was also required, e.g. email, roles etc. and inclusion of new users.
I am kind of sure that Spring Security will also have the concept of Combined Realm.
I understand that this answer is not really an answer and more of design approach and many years too late at that; however, I wished to share my experience.
Related
I am using Websphere Application Server, that has administrative and application security enabled, which uses LDAP to interface an Active Directory for authentication.
The web application that is deployed to the server is required to be able to retrieve information from this AD, as well as modify information in this AD (such as adding a new user to the AD). I could use JNDI to achieve this, however I need the application to use the settings configured in Websphere to do the connection so that I don't have to maintain multiple sets of LDAP information (one in the application and one in Websphere).
I have searched around but couldn't find anything concrete. The closest I saw was I can configure it as a federated user repository instead of standalone LDAP registry, after which I can retrieve some attribute values, but it does not explain if I am able to modify them.
Any help would be appreciated. Thanks!
If you will use federated repository, then you can use VMM API. It is quite complex comparing to JNDI or ldap related libraries, but should provide you with features you need.
Start by looking at this page - Developing with virtual member manager - and subpages, you will find some code examples there also.
I've created my own JDBC realm (using WildFly 8.2) as described at paragraph 50.3 of the JavaEE 7 tutorial. My understanding is that JDBC realm authentication implies that user credentials are read and checked by the server, the application doesn't even know the coordinates for the auth-reserved DB.
For a "new user sign up", the only thing I can imagine is to implement a classic solution from the inside of my application: accessing auth DB, check if chosen username is already present, insert row in the table... but doesn't this violate the whole paradigm of "container managed authentication", and maybe insert security holes?
Is there some server-implemented mechanism that I ignore?
but doesn't this violates the whole paradigm of "container managed authentication", and maybe insert security holes?
Yes, more or less. The container managed security concept, where the application is totally unaware of the authentication mechanism and the identity store (location where the user data is actually stored) doesn't really take the use case into account where an application has its own user sign up/register functionality.
The idea seems to be more intended for integrating externally obtained applications (e.g. say a Sonar or JIRA instance) into an existing enterprise structure. There the users are created by an admin using a central system like LDAP, or in some situations even an admin UI of the application server.
Unfortunately many of your typical public web applications aren't of this variety. They are standalone apps (don't integrate with existing internal enterprise infrastructure) and they effectively manage their own users.
The classical concept is an ill fit there, and that's why the Java EE Security EG is currently exploring how to best address this.
You basically have three "solutions" in the mean time:
Just define your DB connection details twice, once at the server level, once at the app. It looks like you were indeed already doing this.
Use JASPIC, which is a container provided authentication API which has the option to let the application contain the auth module. It can use the exact same data source and possible JPA entity manager and such that the application is also using.
Do your security using an external security framework, e.g. DeltaSpike Security or Shiro, that's totally implemented in "user space".
From a Java EE perspective, none is really ideal. The first has the duplicate definition and indeed somewhat violates the principle, the second is by itself okay, but JASPIC is a tad low level, and the second is a rich solution but doesn't integrate well with existing Java EE security.
For a current application, the customer has given us the following requirements:
Use of Glassfish 4 Application Server
JEE7
PrimeFaces
Allowing for Authorization against both LDAP and JDBC database, which can be switched between after the application has been deployed
I am wondering if anyone has any ideas about how I could accomplish this as I have only worked with glassfish using the predefined realms, never having to create one. The flow of this is that after the application has been deployed, the admins can choose whether the users accessing the site authenticate against an LDAP or a local JDBC Database. This decision should not effect the flow of the front end, meaning that there should only be one login page, that goes to one function, that would then, based on the configuration, determine which realm to use to authenticate against.
Any help would be greatly appreciated.
i think you have three alternatives:
configure both glassfish realms and switch between them in web.xml:/web-app/login-config/auth-realm
pros: very simple, you can configure them with administration ui (server-config -> security -> realms) or asadmin
cons:
can only use one at a time
must be configured outside application
switch REQUIRES application reload (no redeploy, just reload)
deveop your own glassfish realm which encapsulates the jdbc realm and ldap realm
pros:
you can use both at the same time (no switch)
you can still configure them with ui or asadmin, but support is limited
cons:
requires knowledge and external development for realm and module classes
must be configured outside application
glassfish specific implementation (will not work on other containers)
some reference here and here
deveop a pluggable authentication architecture (JASPIC)
pros:
programmatic approach: maximum liberty & freedom
can be deployed within application (no external config and no reloads)
standard, can be reused in (almost) all JEE containers
cons:
VERY hard to develop, need knowledge about JASPIC and (optional, but suggested) JAAS
lacking JASPIC documentation
if you really want a pluggable auth, some references are here and the excellent article from Arjan Tijms
good luck!
What I am looking for is a Java servlet implementation of an OpenId provider for LDAP ... something I can plug into TomCat, point it at an LDAP directory server, and provide OpenId style authentication from those user accounts in the directory server.
I have been using OpenID4Java for years and it works fine, but it is just an API, and does not provide the user interface required for a complete OpenID provider.
I want to be able to write a large number of small web-based utilities, and allow people SSO access to all of them using OpenID, but these people already have accounts in the directory server, and I do not want to make them create a new password. They should use the same old password they are used to.
I tried OpenID-LDAP, but it is based on PHP. I am looking for one I can install into TomCat and manage consistently with other JSP based applications. I looked at JOIDS which seems to have capability to register and manage users, but nothing to link to LDAP. This excellent Wiki Page lists other options, like Atlassian Crowd, but I need open source.
I am asking at this time to see if I have missed anything. If there is nothing, I will probably write one.
You may try using WSO2 Identity Server which provides OpenID provider that can be plug in with LDAP and provides UI as well.
I am currently trying to implement a single sign on solution across multiple JVM based (Grails, Servlets) web applications currently all deployed in the same servlet container (currently Tomcat, but don't want to limit my solution to just Tomcat). All web applications share a common database.
I've looked at various options from using CAS or other third party libraries to creating a new web service to handle Single Sign On, but none seem to really satisfy the business. My current implementation involves creating a new jar library which has a common implementation of AuthenticationProviders, and Pre-Authentication Filters based on Spring Security.
In this approach I have multiple AuthenticationProviders (currently Active Directory, and Database) for the application to authenticate against. Upon successful authentication a row would be inserted in a session table that contains the user, an expiration time, and a token. The token would be also stored as a cookie on the user's machine and that would be used to validate they have a current session in the Pre-Authentication Filters.
Having never done this before I want to make sure I'm not creating a huge security problem, and I'd also like to know what I would need to create the token? At this point a simple GUID seems to be sufficent?
Currently we are working on Spring Security 3.0.x, and haven't upgraded to 3.1 yet.
Thanks in advance.
I ended up solving this problem by doing the following:
I created a AuthenticationSuccessHandler which would add a cookie to the user's session which had identifying information as well as the hostname to try to secure it as much as possible. (The application was running internally at most customer sites so the risks here were determined to be minimal, but be careful about cookie jacking.)
Then on each application that needed to have SSO I implemented a AbstractPreAuthenticatedProcessingFilter, and placed in before the authentication filter which would pull the cookie out and create an Authentication object. Lastly I created an AuthenticationProvider which validated the information from the cookie.
Hopefully that helps someone else in the future for this type of request.
There are extensions available for KERBEROS, OAuth and SAML available on the Spring Security Extensions website. Here is the blog entry which provides an example: SpringSource Blog
If you are using NTLM as your SSO Provider, take a look at the jespa-spring project.
Or you might want to look at the Java Open Single Sign-On Project