A current application running in Wildfly (Jboss) uses its own Authentication system that internally verifies passwords and credentials on its Database.
This system is no longer viable for the future as we migrate to a microservices pattern, therefore requiring a distributed login system using OpenId Connect protocol for Authentication initially, authorization will come later.
This has been implemented fine with a new Spring boot microservice using Spring security and Spring OAuth2 client, however integrating those libraries with the old Jakarta EE application is proving a challenge.
Implementation
Spring version - 5.3.13
Spring Security version - 5.5.3
Omnifaces version - 3.11.2
Jakarta EE version - 8
Wildfly application container - 23
There is an existing Authentication system using Java EE HttpAuthenticationMechanism with a AuthenticatedUser bean which acts like a principal.
I added Spring security and OAuth2 client to the Java EE application. It works fine and redirects people to an AWS Cognito SSO page and redirects back with authorization code after they login.
Here is a diagram summarizing what is currently hacked together
Testing
I created two basic JSF pages with backing beans, one secured with old Javax Security rules defined in web.xml and the other defined in Spring security configuration bean.
With the Spring secured page, I can get the Security context in the bean (I think this uses ThreadLocal)
e.g.
Helloworld Backing Bean
#Named
#ViewScoped
public class HelloWorldBacking implements Serializable
{
private static final long serialVersionUID = 1L;
public String getAuthDetails() {
SecurityContext context = SecurityContextHolder.getContext();
Authentication authentication = context.getAuthentication();
return authentication.getName();
}
}
Spring Security Config
#Configuration
#EnableWebSecurity
#PropertySource("classpath:application.properties")
public class SecurityConfiguration extends WebSecurityConfigurerAdapter {
private final String clientSecret;
private final String clientId;
private final String issuerUri;
#Autowired
public SecurityConfiguration(#Value("${oauth.issuer-uri}") String issuerUri,
#Value("${oauth.client-id}") String clientId,
#Value("${oauth.client-secret}") String clientSecret) {
this.issuerUri = issuerUri;
this.clientId = clientId;
this.clientSecret = clientSecret;
}
#Override
protected void configure(HttpSecurity http) throws Exception {
http.sessionManagement()
.sessionCreationPolicy(SessionCreationPolicy.ALWAYS)
.and()
.csrf()
.csrfTokenRepository(CookieCsrfTokenRepository.withHttpOnlyFalse())
.and()
.cors()
.and()
.authorizeRequests()
.antMatchers("/helloworld-spring").hasAuthority("Admin")
.and()
.oauth2Login()
.and()
.oauth2ResourceServer()
.jwt();
}
...
However if I don't protect that JSF page with Spring security I cannot get any context.
Problem
When a JSF page has been secured with the old security way, it seems to go down a different path with contexts that are all managed by CDI.
I want to integrate Spring security principal into all parts of the JSF app. So that JSF is aware of it in its context.
Debugging
When debugging some existing pages, it appears that both Auth systems are activated but are divergent and not aware of each other.
Solutions?
As someone who has been spoiled by the luxury of spring boot auto configuration, I am a bit stuck on what to do.
Potentially its an easy fix with just overriding a class, or:
Do I need to just rip out the old Authentication system that uses Java EE spec?
Do I override some part of Spring security so that it is aware of Java EE and JSF?
Does JSF need to be configured to talk to Spring security?
Is there something higher level abstracted away in the Wildfly application server that needs to be configured?
tl;dr
How do I get Spring security to pass its security context to JSF in a Jakarta EE application?
Thanks
A current application running in Wildfly (Jboss) uses its own Authentication system that internally verifies passwords and credentials on its Database.
From your diagram, it looks like it's not "its own Authentication system", but it uses Java EE Security. There's no need to replace this with anything Spring.
The best way to make this work is to keep it as is. Java EE Security was specifically designed to work with JSF, and the two integrate together quite well. Bringing your own security system into the mix here is probably asking for problems later.
p.s.
OpenId Connect is currently being included in what's now called Jakarta EE Security, see https://github.com/jakartaee/security/pull/185
Java EE Security on WildFly works really well with the MicroProfile APIs, which includes a JWT Authentication Mechanism. See for example
https://github.com/wildfly/quickstart/blob/main/microprofile-jwt/README.adoc
Related
Hello I recently received a demand to migrate the ldap authentication service to oauth2 from a jsf project, but I have no idea where to start, from what I've been seeing in the project I have an ldap security domain configured in wildfly where I can make use of some features that comes from FacesContext as:
.login(username, password)
.getUserPrincipal()
.isUserInRole(rule)
.logout()
.invalidateSession()
What I would like to know is if there is a possibility to make my own security domain the same as the configured ldap, where I would implement the methods above, any content where I can start is welcome
I made an implementation of org.jboss.security.auth.spi.UsernamePasswordLoginModule;
I am in desperate need of help. So as a prerequisite I am tasked with creating a simple web application. The application requirements are to create a simple web form that collects user data and then sends an email verification to the user that just provided information. The difficult aspect of this project is CAS Integration with the Marist College CAS authentication system. A requirement of this project was that I use Spring Boot to create the project. At the moment I have already implemented Spring Security to authenticate users. I have been trying everything online to integrate CAS with my existing project. I was hoping that someone on StackOverflow may have more knowledge on how to integrate CAS with SpringSecurtiy. Also please don't be harsh on me I have never used the spring framework before this project and this is all new to me. The Url of the CAS server is "https://login.marist.edu/cas/". I have looked into https://github.com/apereo/java-cas-client spring support I just don't know how to integrate it with my current application. Thank you to anyone in advance that lends me a hand with this.
As I previously stated I would provide the solution to the problem that I experienced during the processes of integrating a spring application with the Marist CAS 2.0 Authentication System. As Stated above there is a Spring Boot AutoConfiguration that can be used. While this may not be the best method for securing your application it satisfied my needs for the project that I was working on. The Steps to configure your spring application with CAS 2.0 are bellow.
Add Maven Dependency
Maven:
<dependency>
<groupId>org.jasig.cas.client</groupId>
<artifactId>cas-client-support-springboot</artifactId>
<version>${java.cas.client.version}</version>
</dependency>
Add the following required properties in Spring Boot's application.properties or application.yml
cas.server-url-prefix=https://cashost.com/cas
cas.server-login-url=https://cashost.com/cas/login
cas.client-host-url=https://casclient.com
3)Annotate Spring Boot application (or any #Configuration class) with #EnableCasClient annotation
#SpringBootApplication
#Controller
#EnableCasClient
public class MyApplication { .. }
4)For CAS3 protocol (authentication and validation filters) - which is default if nothing is specified
cas.validation-type=CAS3
For CAS2 protocol (authentication and validation filters)
cas.validation-type=CAS
For SAML protocol (authentication and validation filters)
cas.validation-type=SAML
I have rest API where I need to secure some (UI facing) endpoints with OKTA authentication, and others (backend-facing) with Azure Active Directory. I managed to do it separately (either I can secure the endpoints with OKTA or AAD), but they don't want to work together. As soon as I add okta-spring-boot-starter to POM (or okta-spring-security-oauth2) - AAD security stops working and endpoints are either open or secured with OKTA only. I am trying to do it using WebSecurityConfigurerAdapter implementations for okta and aad:
#Configuration
#EnableWebSecurity
public class WebSecurityConfig {
#Configuration
#Order(1)
public static class OktaAdapter extends WebSecurityConfigurerAdapter {
#Override
protected void configure(HttpSecurity http) throws Exception {
http.authorizeRequests()
.antMatchers("/v1/endpoint1").authenticated()
.antMatchers("/v1/endpoint2/**").authenticated();
}
}
#Configuration
#Order(2)
public static class ActiveDirectoryAdapter extends WebSecurityConfigurerAdapter {
#Autowired
private AADAppRoleStatelessAuthenticationFilter filter;
#Override
protected void configure(HttpSecurity http) throws Exception {
http.csrf().disable()
.authorizeRequests()
.antMatchers("/v1/endpoint3/**").authenticated()
.antMatchers("/v1/endpoint4/**").authenticated()
.and()
.addFilterBefore(filter, UsernamePasswordAuthenticationFilter.class);
}
}
}
This configuration however works only for endpoint1 and endpoint2 (secured with okta), other rest points are open (as if 2nd implementation of WebSecurityConfigurerAdapter was ignored). If I remove okta package from pom, AAD configuration starts working. If I switch orders of above configurations then nothing is secured. I suspect okta package does some autoconfiguration, but can't find any information about it. What am I missing?
The Okta Spring Boot Starter is mostly just a light wrapper to help configure the existing Spring Security OAuth autoconfig with a few Okta specific bits.
My first suggestion (if possible) is to try to use Spring Security OAuth for both IdPs, as it doesn't look like the AAD starter works Spring Security's built-in OAuth support (I could be wrong, I only took a quick look). Assuming AAD is just OAuth/OIDC it will just work with a little bit of configuration.
You will still need a solution to protect your given routes 1 & 2 -> Okta 3 & 4 AAD. There are a few ways to do this. You could use scopes (assuming they are different) or some other type of "authority":
http.authorizeRequests()
.antMatchers("/your/route").hasAuthority("SCOPE_custom");
The Okta Spring Boot Starter should work with other IdPs configured with Spring Security OAuth properties: https://docs.spring.io/spring-security/site/docs/current/reference/html5/#oauth2login-boot-property-mappings
I cannot speak 100% to what the ADD starter adds, but I'm guessing it's similar to Okta. Which is:
A common set of properties (inline with other vendor offerings)
Vendor-specific JWT validation (Spring Security only does basic JWT validation, and each vendor has its own recommendations, assuming you are using JWT access tokens)
A little sugar (for example the Okta starter adds a mapping of Okta groups to Spring Authorities)
As far as JWT validation goes Okta recommends validating JWTs like this:
https://scotch.io/tutorials/jwt-vs-opaque-access-tokens-use-both-with-spring-boot#toc-better-jwt-validation
A similar technique could be used (if needed).
Keep us posted!
I am using Spring4 with Spring Security 3.2.4.
I have some http configurations in my security configuration in order to host form based authentication and REST services (with authentication) together.
For the pages and REST services which require app-authentication everything works fine with my current configuration but for the pages which does not require authentication, such as login and register, the anonymous authentication is not initialised somehow. Speaking in Java:
SecurityContextHolder.getContext().getAuthentication() returns null.
I expect that anonymous authentication is initialised as the documentation (http://docs.spring.io/spring-security/site/docs/3.2.4.RELEASE/reference/htmlsingle/#introduction) refers:
Anonymous authentication support is provided automatically when using the HTTP configuration Spring Security 3.0 and can be customized (or disabled) using the element. You don’t need to configure the beans described here unless you are using traditional bean configuration.
Does anyone have an idea why does it not happen although the documentation refers? (Beside the fact, that the documentation for 3.2.4 refers to 3.0 version and some of the given configuration suggestions refer deprecated implementation)
NOTE: My application uses the latest version of the Spring framework, 4.0.6, 3.2.4 for security, and, it uses no xml but only Java-Config to configure the application.
I have a set of services which I would like to secure with roles and other business specific authorization conditions. This services are grouped into a module (a jar) which is used by a REST application and a web application. I already have an AuthenticationProvider in the web application (REST application is in initial phase). I use #EnableGlobalMethodSecurityin the web application. Having said that, I now need to secure the methods in the services too. In that case, do I need to provide another authentication provider? Or, is right to move the authentication provider to the services module so that the web/rest apps uses the authentication provider in the services jar? If I configure #EnableGlobalMethodSecurity in the ApplicationServiceConfig.java of the services module, I get the blow exception.
com.name.mvoice.project.service.ApplicationServiceConfig: Invocation of init method failed; nested exception is java.lang.IllegalArgumentException: An AuthenticationManager is required
How do I configure the security if the application requires double authentication, one from the RDBMS and the other from the LDAP. The condition should be that the user information should be present and be enabled in both the systems. Do I need to write this in the existing authentication manager itself or shall I provide separate auth provider for the LDAP? If so how?
WebSecurityConfig.java
#Autowired
public void configureGlobal(AuthenticationManagerBuilder auth)
throws Exception {
AuthenticationProvider dbAuthenticationProvider = new DatabaseAuthenticationProvider();
auth.authenticationProvider(dbAuthenticationProvider );
// is it right to do like this
AuthenticationProvider ldapAuthenticationProvider = new LDAPAuthenticationProvider();
auth.authenticationProvider(ldapAuthenticationProvider );
}
Though, I seeAuthenticationManagerBuilder.authenticationProvider adds the supplied authenticationprovider to a list!
No, this won't give you the desired result. The default Spring Security implementation uses only one AuthenticationProvider at a time. Your second call to auth.authenticationProvider() would force Spring Security to use just the LDAP provider.
To achieve what you want
Step 1: Create a class of your own, say
public class CompositeAuthenticationProvider implements AuthenticationProvider {}
Step 2: Then, inject the Database and LDAP providers into it.
Step 3: In the authenticate method of the class CompositeAuthenticationProvider, orchestrate the request between the Database and LDAP providers as you see fit. Return a response based on the results you obtain from both the providers.