In BAMOE 8.0.x, authentication and authorization were handled internally using WildFly and JAAS. This tightly coupled approach has been replaced in BAMOE 9 with a more modern and flexible model that delegates all Authentication, Authorization, and Access Control (AAA) responsibilities to external systems.
For detailed guidance on securing Business Service API endpoints, refer to the official Securing Business Service API endpoints.
Security in BAMOE Components
In BAMOE v9, security is implemented using OpenID Connect (OIDC) across all major components, including Business Services, the BAMOE Management Console, and both Quarkus and Spring Boot runtimes. REST and GraphQL APIs are protected using JWT bearer tokens, while Kafka integration supports SASL and OAuth2 for secure communication. Unlike BAMOE v8, direct LDAP integration is no longer supported in version 9.
These components rely on an API Gateway for routing and enforcing security policies. Authentication and role-based authorization are handled by an OIDC-compliant identity provider.
Quarkus runtime
Quarkus uses the OIDC extension for authentication, configured through the application.properties file. This setup supports bearer token authentication and role-based access control.
The example below uses a Keycloak as IdP:
quarkus.oidc.auth-server-url=https://keycloak.example.com/auth/realms/kie-realm
quarkus.oidc.client-id=bamoe-app
quarkus.oidc.credentials.secret=my-secret
quarkus.http.auth.permission.authenticated.paths=/*
quarkus.http.auth.permission.authenticated.policy=authenticated
quarkus.oidc.roles.role-claim=realm_access.roles
To enable this, add the following Maven dependency:
<dependency>
<groupId>io.quarkus</groupId>
<artifactId>quarkus-oidc</artifactId>
</dependency>
More details are available in the Quarkus security properties guide and the OIDC bearer token guide.
Spring Boot runtime
Spring Boot uses Spring Security with OAuth2 support. Security is configured via application.properties, and Spring Boot provides a default security configuration when the spring-boot-starter-security dependency is included:
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-security</artifactId>
</dependency>
Default credentials can be set as follows:
spring.security.user.name
spring.security.user.password
If not configured, a random password is generated and printed in the console log.
Using default security password: c8be15de-4488-4490-9dc6-fab3f91435c6
To disable the default security configuration, either exclude the SecurityAutoConfiguration class in your main application:
@SpringBootApplication(exclude = { SecurityAutoConfiguration.class })
public class SpringBootSecurityApplication {
public static void main(String[] args) {
SpringApplication.run(SpringBootSecurityApplication.class, args);
}
}
Or use the following property:
spring.autoconfigure.exclude=org.springframework.boot.autoconfigure.security.SecurityAutoConfiguration
NOTE: Disabling may cause issues if other components (like Actuator) depend on the excluded configuration.
For custom security, define a configuration class using @EnableWebSecurity and @Configuration. This allows you to define multiple users and roles using InMemoryUserDetailsManager.
@Configuration
@EnableWebSecurity
public class BasicConfiguration {
@Bean
public InMemoryUserDetailsManager userDetailsService(PasswordEncoder passwordEncoder) {
UserDetails user = User.withUsername("user")
.password(passwordEncoder.encode("password"))
.roles("USER")
.build();
UserDetails admin = User.withUsername("admin")
.password(passwordEncoder.encode("admin"))
.roles("USER", "ADMIN")
.build();
return new InMemoryUserDetailsManager(user, admin);
}
@Bean
public SecurityFilterChain filterChain(HttpSecurity http) throws Exception {
return http.authorizeHttpRequests(request -> request.anyRequest()
.authenticated())
.httpBasic(Customizer.withDefaults())
.build();
}
@Bean
public PasswordEncoder passwordEncoder() {
PasswordEncoder encoder = PasswordEncoderFactories.createDelegatingPasswordEncoder();
return encoder;
}
}
NOTE: The @EnableWebSecurity annotation is crucial if we disable the default security configuration.
To support OAuth2, include the following dependencies:
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-oauth2-resource-server</artifactId>
</dependency>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-oauth2-client</artifactId>
</dependency>
Example OAuth2 configuration using Keycloak:
spring.security.oauth2.client.registration.keycloak.client-id=bamoe-app
spring.security.oauth2.client.registration.keycloak.client-secret=my-secret
spring.security.oauth2.client.registration.keycloak.authorization-grant-type=authorization_code
spring.security.oauth2.client.registration.keycloak.scope=openid,profile,email
spring.security.oauth2.client.provider.keycloak.issuer-uri=https://keycloak.example.com/auth/realms/kie-realm
BAMOE Management Console additional configuration
To enable secure service-to-service communication between the Business Service and the BAMOE Management Console, an additional setup using an OIDC proxy is required.
Add the following dependencies to your pom.xml:
<dependency>
<groupId>io.quarkiverse.oidc-proxy</groupId>
<artifactId>quarkus-oidc-proxy</artifactId>
<version>0.2.2</version>
</dependency>
<dependency>
<groupId>io.quarkus</groupId>
<artifactId>quarkus-resteasy-client-oidc-token-propagation</artifactId>
</dependency>
Then configure the application with the following properties in application.properties:
quarkus.oidc.tenant-enabled=true
quarkus.http.auth.permission.unsecure.paths=/health/*
quarkus.http.auth.permission.unsecure.policy=permit
quarkus.http.auth.permission.secure.paths=/*
quarkus.http.auth.permission.secure.policy=authenticated
This setup ensures that the BAMOE Management Console can securely authenticate and propagate identity tokens when communicating with Business Services, maintaining a consistent and trusted identity context across the BAMOE architecture.
Example: process-security
A working example of BAMOE security integration using Keycloak (as the IdP) and OIDC is available in the process-security example. This example demonstrates:
-
Keycloak realm and client setup
-
Token-based authentication
-
Role-based access control
-
Secure endpoint configuration