Multiple WebSeciurityConfig in one Spring application - java

We are maintaining two versions of our application from security perspective
1. SAML based spring security
2. Spring and JDBC based application security.
As some of our customers already have SAML IDP (like ADFS and GLUU) which they want us to integrate for SSO and some customer doesn't have SAML IDP.
Is there a way that both configurations can coexist and based on the customer using the application, security is imposed on the user.
For ex: if the request is coming for customer a.myserverhost.com SAML based security configurations are imposed. and if the request is form b.myserverhost.com the other webSeciurityConfig is imposed

Yes, all of this is possible. What I would suggest is implementing your own AuthenticationManager which manages multiple AuthenticationProviders (e.g. SAML, JDBC).
That's where you can insert your conditional logic for choosing the correct provider based on certain criteria.
For inspiration, look at the default implementation ProviderManager.
Out of the box the ProviderManager will iterate over all of your AuthenticationProviders and attempt to authenticate the User. If it doesn't find the User it moves on to the next one. If that's all you need then you don't need any custom implementations.

Related

Combining Vaadin Admin UI and a REST API

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.

Concept behind how java clients authenticate with JEE server like weblogic, jboss etc

I have been going through lot of documentation to understand what is the standard way (if there is any) in which the java client authenticates themselves with the applications deployed on server container like weblogic, jboss etc.
After reading about JAAS & JNDI authentication documentation for weblogic, I am able to understand the flow, but no documentation answers the below queries
Are JAAS and JNDI the only available methods for authenticating java clients ?
What I understood so far is, that each application server can provide its own abstraction layer to perform authentication, for example OPSS in weblogic, but eventually they all depend on native authentication methods available in JEE framework. Please point out if this assumption is not correct.
The confusion is greatly amplified as some article mention that JAAS security doesn't exists in JEE. Is that valid for java 7+ too?
The oracle weblogic documentation I have been going through clearly states JNDI & JAAS as the standard authentication approaches, and even goes to the extent to specifying JAAS as being preferred over JNDI authentication.
https://docs.oracle.com/cd/E28280_01/web.1111/e13711/fat_client.htm#SCPRG225/
Here is clarification I got based on the material read during last two days.
Most basic thing - All application servers provided provide an identity store, that can store users & groups. Applications can refer to this identity store, as when it is deployed on the server.
A Caller or User is an individual named identity defined in an identity store.
https://dzone.com/refcardz/getting-started-java-ee?chapter=1
How the applications execute authentication?
Based on pure JEE framework, the authentication methods can be classified based on the type of application it secures:
Web Application Authentication
Declarative:
We use either deployment descriptors or #annotations to specify these authentication enablers:
a. Which options to use for rendering authentication i.e. basic (browser popup), custom form, SSL, etc.
b. Which resources(URL patterns) need authentication and authorization.
c. Which users or roles (via groups) are permitted authentication or authorization.
Programmatic
Here we make use of security methods() in built in interface HttpServletRequest.
The application(e.g. servlet) call following methods to instigate authentication from within an "unconstrained" resource.
a. request. Authenticate: A login box pops up to collect credentials.
b. request. login: This methods takes login/password without the pop
c. request. logout: Resets the user/caller identity
There are several other methods also available, that provides more details of the authenticated user like isUserInRole(whether it's in given role), GetRemoteUser(gives user name), etc.
EJB Authentication
How EJBs are authenticated??
EJBs are can also be secured in the same way, as web based apps. i.e. Either with Declarative or programmatic security. Some caveats to this statement, but those are not relevant to current discussion.
So why do we need JAAS, and what is JAAS?
To appreciate this, let's understand a practical scenario for any:
An application may have multiple authentication requirements e.g. password, certificate, authentication users from multiple security realms, perimeter authentication, etc. Do we have to code so much for every application, and type of authentication? Now, it can be cumbersome and complex create & maintain code for authenticating users based on these different techno-business requirements.
To address above situation, there has to be a Pluggable way to writing code for authentication, wherein, developers would only be responsible for mentioning(not coding) which AuthenticationProvider has to be used, and writing code to call the loginModule of that particular provider, which eventually has code to authenticate the given user/caller.
This framework of providing pluggable authentication is called Pluggable Authentication Module in LDAP world.
"JAAS" is java implementation of PAM framework. With JAAS, either updated, or additional authentication technologies can be plugged under an application, without modifying the application code as such.
After Authentication, JAAS also enforces authorization.
JEE provides libraries to implement JAAS in applications!
Is JAAS implemented in same way across different enterprise application servers like Weblogic, JBoss, etc.
Well, "It can be", "but is usually not" implemented in same way across different application servers.
This is because application server may provide its own libraries, which can be used to implement JAAS.
Hope this clarifies the JEE security model to folks who do not have development background.

Two mechanisms of authentication: Kerberos and HTTP basic

I have a springboot application which uses usual HTTP basic authentication using spring-security-ldap.
Later I modified it to use Single Sign On (Kerberos) authentication using spring-security-kerberos-core and spring-security-kerberos-web.
Everything is working fine so far.
Now I need to use both mechanisms. The idea is to use SSO for the front-end application, so that users are logged in automatically. And to use HTTP basic (username/password) for REST interface or for testing.
Probably I need to have two entry points (e.g. '/login' for SSO and '/login-userpass' for HTTP basic). Is it a correct approach? Or are there other ways to implement it?
It seems to me a common requirement but I'm not able to find examples of how to implement this.
EDIT:
Actually, it's a duplicated question. And the accepted answer works perfectly.
I have not used Kerberos with Spring, but I have previously implemented an application with both basic, form and CA SSO. However without looking at some code, particularly WebSecurityConfigurerAdapter I can only give general guidlines.
With Spring you need a number of authentication filteres mapped to different URLs, these will intercept the login, do 401 challenge if needed, and then create an unauthenticated Authentication instance. The typical filters are BasicAuthenticationFilter and UsernamePasswordAuthenticationFilter, and you need to find the one for KerBeros.
Later the unauthenticated authentications are give to the AuthenticationProviderManager which find the appropriate AuthenticationProvider to perform the authentication. This is where you do you database query with password hash (potentially SSO callback) and if the user is authenticated you create a new Authentication, typically you would want to extend AbstractAuthenticationToken or select one of the existing authentication. Remember to copy the details for the unauthenticated Authentication.
In Spring 4 AuthenticationProvider are configured using AuthenticationManagerBuilder, this is done in the configure method of WebSecurityConfigurerAdapter which you need to override.
Remember that you can have a single filter and many AuthenticationProviders or many filters and a single AuthenticationProvider, depending on your needs.
The application I have access to at the moment has a single form login, but some additional hidden fields (and stuff in the session), controls which of the 4 available AuthenticationProviders will be responsible for authentication, and different Authentication classes are created based on which provider authenticated the user, so we can restrict some areas of the application to specific Authentication types.

SSO using SAML in multi tenant application

I need to enable SSO in my and one more application. Both applications are multi-tenant applications. (to log in, user must provide user name, password and tenant name).
Every tenant will have it's own directory in identity provider or use different IDP.
Does it make sense to authenticate the user on identity provider using tenant name beside user name and password?
Is there a IDP solution capable of providing this service? (3 parameter log in)
I would think many of the IDPs out there can be made to take in three parameters. If you are using the common SAML Web SSO spec, I don't see any problem in using SAML.
As an example OpenAM is quite customizable, free and supports SAML.
This is probably of help
https://wikis.forgerock.org/confluence/display/openam/Write+a+custom+authentication+module

Why should i use JAAS against hand-written security?

I got hand-written security, simple servlet-filter which redirect not-authorized user to their login pages. Login controller redirect them to the requested URL after successfull authentication or their main page. This approach work fine, the only disadvantage, that I have to pass User object which is stored in the HttpSession through stacktrace to EJB beans.
Now I rewrote some code and use Spring-security as http based authentication. It is integrated automatically with Glassfish JAAS.
I don't need to pass User through stacktrace anymore, invocation sessionContext.getCallerPrincipal() is enough. But the principal object return me only userName, not userId, so i have to perform addition select if i need userId for example.
1) Is there anyway to extend Principal object, so it can store more properties ?
2) Why i should use JAAS or Spring Security or another security framework, why not just hand writen servlet filter ?
2) Using a standard security mechanism like JAAS has many advantages:
You can easily change the way user authenticates solely by configuring your server - without need to change anything inside your code.
You can be sure your security is up-to-date, supporting strongest algorithms, storing Principal in a secure manner and so on. Again just by staying up-to-date with your server, framework etc. Having a hand-written security module is prone to errors and to be outdated soon.
You can leverage framework security - eg. web.xml security tags, EJB security annotations. Because JAAS is a standard way to authenticate, you can be sure adopting future technologies will be easier, because all serious technologies will support JAAS (Spring security etc.). If your software is planned to grow, you will definitely need a standard.
It will save you time and effort. JAAS provides both authentication and authorization, neatly packed and configurable within minutes.
I recommend futher reading on J2EE security or you can find more resources in OWASP guides.
1) I don't know if you can extend the class Principal. But note, in your LoginModule, before you finish the authentication calling the commit() (probably in your login() method), it is possible to add credentials in the Subject. For this, just add the object to one of the lists: Subject.getPrivateCredentials() or Subject.getPublicCredentials() (with no arguments). You can add many objects like your own class, a String, or whatever you want.
To retrieve the objects in your application, use the procedure detailed in my other answer.
import javax.security.jacc.PolicyContext;
Subject subject = (Subject) PolicyContext.getContext("javax.security.auth.Subject.container");

Categories