You are viewing the documentation for Blueriq 17. Documentation for other versions is available in our documentation directory.
For best practices on security see: Security.
This article describes the default HTTP security configuration of the runtime as well as how to disable it and replace it with a custom configuration.
Warning
Please make sure you thoroughly test custom security configurations. By disabling the default security configuration you are fully responsible for HTTP security and thus of the security of the runtime.
In Blueriq 9, the HTTP security configuration was defined in the security-config.xml
file. In Blueriq 10 the HTTP security configuration is implemented in Java using a configurer bean:
@Configuration @Order(50) @ConditionalOnProperty(name = "blueriq.security.http.interactions.enabled", havingValue = "true", matchIfMissing = true) // 1 public class RuntimeWebSecurityConfigurer extends WebSecurityConfigurerAdapter { public static class Mappings { public static final String TRIGGER_SECURITY_CHECK = "/server/noaccess.html"; public static final String PERFORM_SECURITY_CHECK = "/server/securityCheck"; public static final String LOGIN_PAGE = "/server/session/login.html"; public static final String LOGOUT_PAGE = "/server/session/logout.html"; public static final String LOGIN_SUCCESS_URL= "/server/start?loginSuccess=true"; } @Autowired // 2 @Qualifier("blueriqAuthenticationManager") private AuthenticationManager authenticationManager; @Autowired // 3 private IConfiguration configuration; @Autowired private MvcRedirectHelper redirectHelper; // 4 @Override protected AuthenticationManager authenticationManager() throws Exception { return authenticationManager; // 2 } @Override protected void configure(HttpSecurity http) throws Exception { // @formatter:off http .csrf().disable() .headers() .defaultsDisabled() // 3 .and() .sessionManagement() .sessionFixation().none() .and() .authorizeRequests() // 4 .antMatchers(redirectHelper.getNoAccessPath()).authenticated() .antMatchers("/h2-console/**").permitAll() .and() .formLogin() .defaultSuccessUrl(Mappings.LOGIN_SUCCESS_URL, true) .loginPage(Mappings.LOGIN_PAGE) .loginProcessingUrl(Mappings.PERFORM_SECURITY_CHECK).permitAll() .failureUrl(Mappings.LOGIN_PAGE) .and() .anonymous() .key("doesNotMatter"); if (configuration.isClickJackingProtectionEnabled()) { // 3 http.headers() .frameOptions().sameOrigin() .addHeaderWriter(new StaticHeadersWriter("Content-Security-Policy","frame-ancestors 'self'")); } if (configuration.isStrictTransportProtectionEnabled()) { // 3 http.headers() .httpStrictTransportSecurity() .includeSubDomains(true) .maxAgeInSeconds(31536000); } if (configuration.isXContentTypeProtectionEnabled()) { // 3 http.headers().contentTypeOptions(); } else { http.headers().contentTypeOptions().disable(); } // @formatter:on } }
1. Disabling the default HTTP security configuration
The default HTTP security configuration can be disabled by setting the blueriq.security.http.runtime.enabled
property to false
. Once disabled, another configurer bean should be provided in the Spring Context.
blueriq.security.http.interactions.enabled=false
2. Overriding the authentication manager
The HTTP security configuration requires an authentication manager bean which is used to authenticate and authorize users when certain URL patterns are requested. In a custom configuration, it is possible to either use a custom authentication manager or use the default Blueriq authentication manager which supports the registration of custom authentication providers. See Runtime Authentication for more details about how to register a custom authentication provider with the Blueriq authentication manager. The following example illustrates how the authentication manager can be overridden while keeping the default HTTP security configuration:
@Configuration public class CustomWebSecurityConfigurer extends RuntimeWebSecurityConfigurer { @Autowired @Qualifier("customAuthenticationManager") private AuthenticationManager customAuthenticationManager; @Override public AuthenticationManager authenticationManager() throws Exception { return customAuthenticationManager } }
Warning
Apart from changing the authentication manager, the default security configuration is not suitable for extension.
3. Configurable security headers
The default Spring Security headers are disabled and re-added depending on properties in the Spring environment.
4. Configuring authentication and authorization for URL patterns
By default a single URL requires authentication. Internally, the Blueriq Runtime will redirect to this URL whenever a flow requires authentication. Custom configurations may add other URL patterns that require authentication and/or authorization, as in the following example:
@Configuration public class CustomWebSecurityConfigurer extends WebSecurityConfigurerAdapter { // 1. inject any required dependencies @Autowired private IAuthorisationManager authorisationManager; @Autowired @Qualifier("blueriqAuthenticationManager") private AuthenticationManager authenticationManager; // 2. specify the authenticationmanager @Override public AuthenticationManager authenticationManager() throws Exception { return authenticationManager; } // 3. configure HTTP security @Override protected void configure(HttpSecurity http) throws Exception { http() .authorizeRequests() .antMatchers(authorisationManager.getOnFlowAccessExceptionUrl()).authenticated() .antMatchers("/server/custom/controller").hasRole("CUSTOM_ROLE") } }
Please note that custom configurations should configure not only authorizations for URL patterns, but also the login mechanism, headers and any other applicable security settings. The URL patterns should be relative to the web application context.
5. Reserved Order values for Blueriq out of the box Spring Security filterchain
Out of the box the number of Blueriq entries in the Spring Security filterchain varies depending on the active profiles and property settings. To register these security entries Blueriq reserves the following org.springframework.core.annotation.Order
values:
Order | Security Configurer | Activation condition |
---|---|---|
10 | BaasWebSecurityConfigurer | always |
20 | BaarsWebSecurityConfigurer | always |
26 | H2ConsoleSecurityConfigurer | With the development-tools profile enabled |
30 | RestApiOAuthWebSecurityConfigurer | always |
40 | RestApiWebSecurityConfigurer | always |
50 | RuntimeWebSecurityConfigurer | default (property blueriq.security.http.interactions.enabled not set to false) |
6. Noaccess.html
Blueriq's http security is based on the assumption that users require themselves access through logging in. If a user's credentials fail to grant the user access, one is redirected from noaccess.html to the login page. This redirection requires the virtual page called noaccess.html that is further configured as follows:
.authorizeRequests() .antMatchers(redirectHelper.getNoAccessPath()).authenticated() .and()
If one chooses to configure a custom security approach, for instance by passing through credentials via http headers, noaccess.html is not in reach, and users are already logged in at the moment they reach Blueriq. A custom page that indicates that no access is allowed is in that case out of Blueriq's hands and the responsibility of the project.