I have several multi module spring web application each application like below, each of them differently develop no inter - connection.
war
|...webModule
|...coreModule
I want to integrate them with one admin module with security settings.
How can i do that?? is their any frameworks for that??
I go through the OSGI approach but it has lot migration work. What about component based (I never do that)... Can any one suggest some way to create my integration application which can handle common login & security for other sub application ? (need single sign on multiple war solution)
I strongly advise reading up on the Angular JS and Spring Security series, especially related is the https://spring.io/blog/2015/01/20/the-resource-server-angular-js-and-spring-security-part-iii
The approach that they describe seems completly viable for you. Key points
Spring Security uses the HttpSession to store authentication data by
default. It doesn’t interact directly with the session though: there’s
an abstraction layer (SecurityContextRepository) in between that you
can use to change the storage backend.
After authenticating through your admin module you should store your authentication data into a storage accessible to all your other modules, and using a session id as a key for the data. You can easily achieve this with a help of Spring Session where you can use an out-of-the-box supported Redis as your shared storage for authentication data.
Finally, the key will be set inside a custom header of the requests that target other modules, which will use this custom header and a changed session strategy to pull the authentication data from the storage and authenticated the user
There are quite a few details behind the approach, but the series come with the sample implementation so you should be able to find your way
Related
Im working on an Spring Boot application which should have two parts: One Admin UI-Part done in Vaadin and one part consisting of REST-API Endpoints for a native application to consume.
Authentication of the Admin UI (Form-Login) should be completely different from the REST API (e.g. Basic Auth with a fixed token, or a token from the database).
What would be the best way to achive this? Since it's basically two different applications having the Data-access in common would it make sense / be possible two instanciate two spring application contexts? Or is it enough to configure spring security in a special way for example? Just adding a RestController and excluding the URL from SpringSecurity already brings me halfway to the solution, but what if I also want authentication for my REST-API? But completely different with its own application provider basically.
Spring supports role based authorization and multiple authentication providers. So essentially you can give you admin users a special role and require this role in your Vaadin views to prevent ordinary users accessing the admin UI. You can also have separate authentication mechanisms in the same application, for example you could have your users authenticated via LDAP and you admins via a database. You shouldn't need to do separate application contexts.
I'm working on an project that implements user authentication through Spring Security using a spring session ID stored in a cookie on the client's browser. There's no authentication server, the same server manages authentication and the whole app as a monolith.
So we are now in the need of implementing SSO with a third party system, so far everything I've read on the matter requires OAuth or some other implementation of token based authentication that supports an external identity provider. I would prefer not to migrate the authentication strategy as we are kinda on the clock.
I work on another project that has OAuth authentication so I'm not new on that topic (though not really an expert either).
Can someone throw some light on this? I just need to know if it is possible or there's no other way to migrate the authentication strategy.
Cookie based SSO is only possible (in an easy way) if you are using a so called 'domain cookie'. Technically all applications need to share the same 'cookie domain' then. However from security point of view this is highly discouraged, due to cookie hijacking being possible.
Current Spring app requires to add additional authentication checking from a POJO library. The POJO library includes several customized authentication module to choose. Some can be quite simple, like check the username and encrypted password within a URL from database, or from a file, others can be LDAP authentication or Web Service authenticate.
The tricky part is current application has its own authentication method within security.xml, and we don't want to compromise either one.
My goal is make this work based on minimal change.
I think there might be several solutions for this but trying to get a good practice:
Customize a Spring authentication provider to handle the pojo authentication for the authentication manager
Customize a Spring pre-authentication(or something alike) bean for pojo and let app security do the next.
Extends a filter class and register in web.xml, so this can make minimal change to the existing spring security context, but I am not sure how to make this handle the LDAP and WS authentication.
and many other options if anyone can give a better hint. Thanks in advance.
Create a custom Spring Authentication manager that extends the one that already exists. Call super.authenticate() and if that goes through then add the extra authentication logic.
I am learning Java Security JCE/JAAS. I am not able to get a example where we need to implement JAAS login module in real word webapplication.
Can any one please guide me where I can implement JAAS in my web application. as much i know this is authentication and authorization service.
///
If my understanding is correct now, it means if there is any service(Like LDAP) is running in our webserver or any other webserver, and if we want to consume that service then we need to implement JAAS to authenticate our application.
JAAS is one way of implementing login on a container. JAAS main benefits come from the facts that it is a standard framework integrated in the JRE - so you get plenty of information, samples, connectors, etc - and that it properly separates the various concerns of user authentication.
In particular, it clearly separates authentication (validating the supplied credentials) and authorization (role and permissions granted to the user).
While authentication is very often "generic" or "external", for instance using an LDAP server, authorization is often tightly coupled with you application: roles and permissions are usually specific to the business problem the application addresses.
Implementing your own JAAS module is a simple way of addressing this issue, while staying within the boundaries of a well-defined framework and without having to provide a low level implementation to inject the module with the login cycle and session management of the container.
You don't need to implement your own JAAS login module with standard servlet containers unless you want to modify its standard behaviour as they provide you with several standard means to achieve it.
Here you will find a tutorial showing how to use the form login with Tomcat (no need for rolling you own LoginModule):
http://www.avajava.com/tutorials/lessons/how-do-i-use-form-authentication-with-tomcat.html
Generally, you, as the application developer, do not implement JAAS modules. instead, you choose which JAAS module you need to use for your application from pre-existing modules included in the app server you are using. most application servers come with a variety of implementations which allow you to do common things like authenticate using info from a database, ldap, active directory, kerberos, etc. you would determine which authentication source you need to use and configure your application appropriately.
The main advantage of JAAS is that its pam that is pluggable authentication module.. thus if an application wants to be separated from the authentication and authorization system you can use JAAS. moreover JAAS unlike java general security not only verifies the code source but also the person using the code source to access.. so thus if a web app needs pam and the authorization should be of code source as well as code handler then JAAS is better.
We are looking to use OpenAM/OpenSSO to act as a SSO provider. We need, however, to have OpenAM use our mongo datastore under the hood to manage its authentication needs.
With this in mind, I found this: http://www.badgers-in-foil.co.uk/notes/installing_a_custom_opensso_identity_repository/ which looks promising.
Apparently, this should allow me to add an "Access Manager Repository plugin", but I have since read this:
The Access Manager Repository plugin
is also called amSDK or legacy SDK as
it provides downward compatibility to
work with the existing Sun Access
Manager 7.x version deployment
identity stores. This repository is
tightly coupled with the Oracle DSEE
server; hence, will not work with any
other LDAP servers.
This makes me wonder whether this is really what I want to create, being as though I dont want to be tied to Oracle DSEE server (whatever this is).
Basically, where should I be looking to implement a custom Identity provider for openAM?
For a custom identity repository, specifically, this is likely what you'll want to do:
Develop and Deploy a Custom IdRepo Plugin
https://wikis.forgerock.org/confluence/display/openam/Develop+and+Deploy+a+Custom+IdRepo+Plugin
I'm also doing this for MongoDB - hopefully it will go well. If the logic of your login process is sufficiently unique, then a Custom 'Auth' module is necessary. I like keeping the data access layer separate from the auth process, however -rather than having connect statements in the Auth module.
See section 16.3 and beyond in the OpenAM Developer's Guide, http://openam.forgerock.org/doc/dev-guide/index/chap-identity-repo-spi.html
You can write a Custom Authentication Module in OpenAM.
This is an easy way to authenticate users against a custom datastore. You need to configure callbacks (Eg. username/password) which you need to process in a custom written com.sun.identity.authentication.spi.AMLoginModule. The runtime values for these callbacks will be provided as input to process the login module. Based on those values, you should decide whether the user can be authenticated or not.