HTTP Security in Runtime

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 the HTTP security configuration is implemented in Java using a Configurer bean, as shown below.

Http security configuration

@Configuration
@Order(50)
@ConditionalOnProperty(name = "blueriq.security.http.interactions.enabled", havingValue = "true", matchIfMissing = true)
public class RuntimeWebSecurityConfigurer extends WebSecurityConfigurerAdapter {

  private static final Logger LOG = LoggerFactory.getLogger(RuntimeWebSecurityConfigurer.class);

  @Autowired
  @Qualifier("blueriqAuthenticationManager")
  private AuthenticationManager authManager;

  @Autowired
  private SecurityConfigProperties securityProperties;

  @Autowired
  private MvcRedirectHelper redirectHelper;

  @Autowired
  private SecurityContextRepository securityContextRepository;

  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";
    public static final String LOGIN_PAGE_ERROR = "/server/session/login.html?loginError=true";
  }

  @Override
  protected AuthenticationManager authenticationManager() throws Exception {
    return this.authManager;
  }

  @Override
  protected void configure(HttpSecurity http) throws Exception {
    http //
        .csrf().disable() //
        .headers() //
        .defaultsDisabled() //
        .addHeaderWriter(new ClickJackingProtectionHeaderWriter(this.securityProperties)) //
        .addHeaderWriter(new StrictTransportProtectionHeaderWriter(this.securityProperties)) //
        .addHeaderWriter(new ContentTypeOptionsHeaderWriter(this.securityProperties)) //
        .addHeaderWriter(new XssProtectionHeaderWriter(this.securityProperties)) //
        .and() //
        .sessionManagement() //
        .sessionFixation() //
        .none() //
        .and() //
        .authorizeRequests() //
        .antMatchers(this.redirectHelper.getNoAccessPath()) //
        .authenticated() //
        .and() //
        .formLogin() //
        .defaultSuccessUrl(Mappings.LOGIN_SUCCESS_URL, true) //
        .loginPage(Mappings.LOGIN_PAGE) //
        .loginProcessingUrl(Mappings.PERFORM_SECURITY_CHECK) //
        .permitAll() //
        .failureUrl(Mappings.LOGIN_PAGE_ERROR) //
        .and() //
        .anonymous() //
        .key("doesNotMatter").and() //
        .securityContext() //
        .securityContextRepository(securityContextRepository);
  }

  @Bean
  @ConditionalOnMissingBean(SecurityContextRepository.class)
  public SecurityContextRepository defaultSecurityContextRepository() {
    if (LOG.isInfoEnabled()) {
      LOG.info("Using default security context repository");
    }

    HttpSessionSecurityContextRepository repository = new HttpSessionSecurityContextRepository();
    repository.setDisableUrlRewriting(true);

    return repository;
  }

  @Autowired(required = false)
  public void registerXssWhitelist(IXssWhitelist whitelist) {
    XssSafeValueFormatter.register(whitelist);
  }

  @Autowired(required = false)
  public void registerXssBlacklist(IXssBlacklist blacklist) {
    XssSafeValueFormatter.register(blacklist);
  }

}

Before Blueriq 10, the HTTP security configuration was defined in XML configuration in the file security-config.xml.

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.

application.properties

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

Spring' Security headers are disabled by default and re-added based on how security is configured in application.properties. By default, http request methods are by default not restricted, HTTP strict transport security is disabled by default, content sniffing protection is disabled by default, Blueriq's controller are protected against cross-site request forgery, and click jacking protection is default enabled. Please also see Security.

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	Active?
10	BaasWebSecurityConfigurer	always
20	BaarsWebSecurityConfigurer	always
26	H2ConsoleSecurityConfigurer	When the `development-tools`profile is enabled
30	RestApiOAuthWebSecurityConfigurer	always
40	RestApiWebSecurityConfigurer	always
50	RuntimeWebSecurityConfigurer	By default (can be disabled by setting the property `blueriq.security.http.interactions.enabled` to `false`)

When the Blueriq RuntimeWebSecurityConfigurer is disabled in favour of a custom HTTP security configuration implementation for the Runtime it is advised to use Order 50

6. Noaccess.html

Blueriq uses a mechanism that whenever a flow is started, it is checked if the flow requires authentication and the current user has matching credentials. If this is not the case, the user is automatically redirected to the virtual page noaccess.html. This page does not exist, but is merely there to redirect to the login page as shown in the excerpt below from the HTTP security configuration.

.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 will not be presented to the end user because of the divergent authentication approach. 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.

Space shortcuts

Page tree

1. Disabling the default HTTP security configuration

2. Overriding the authentication manager

3. Configurable security headers

4. Configuring authentication and authorization for URL patterns

5. Reserved Order values for Blueriq out of the box Spring Security filterchain

6. Noaccess.html

4 Comments

Geert Graat

Geert Graat

Geert Graat

Antal van Kalleveen