Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Introduction

Blueriq (exposed) flows can be protected by setting allowed roles on them. When a flow is started that requires the user to have an explicit role, this (by default) will redirect the user to the Blueriq login page. This article describes how to configure the authentication mechanism in the runtime that is 'behind' the login page. The Java and .NET runtime have similar functionality but are configured in a different way.

Table of Contents

Note

The Blueriq Runtime deliveres delivers an out-of-the-box in-memory authentication provider in Java and a DefaultProvider in .NET. These default implementations should only be used for development purposes as they may store the credentials in plain text on the filesystem.

 

Java

Runtime configuration

The Java Runtime reads the authentication configuration from Spring environment properties, under the covers Spring Security is used. In the Java Runtime one Spring Security AuthenticationManager bean named blueriqAuthenticationManager is registered, defined in com.aquima.web.boot.SecurityConfiguration. An anonymous authentication provider is added by default (hardcoded), this is used for anonymous access.

Blueriq supports an in-memory authentication provider type and a customBean authentication provider type for custom authentication needs. Multiple authentication providers can be chained. Every authentication provider must have a unique name, this name is also used in the auth-providers-chain property to determine the order of the authentication providers in the chain.

Properties

Like all security properties, the authentication properties are prefixed with blueriq.security. For every authentication provider a type must be specified,

it can be in-memory or customBean or LDAP, customBean, LDAP, openid-connect or jwt. Checkout these pages on how it works:

Children Display

 


Chain: Specifying which authentication providers to use

Only authentication providers specified in the blueriq.security.auth-providers-chain property will be used by the Blueriq Runtime. The providers will be tried in the order they are specified in the chain. A warning will appear in the Blueriq Runtime log when no authentication providers are specified in the chain.

Example of authentication providers chain using two out of three specified providers:

Code Block
titleapplication.properties
blueriq.security.auth-providers.local01.type=in-memory
blueriq.security.auth-providers.local01.users.location=users.properties
blueriq.security.auth-providers.myAuthProvider01.type=customBean
blueriq.security.auth-providers.myAuthProvider02.type=customBean

# add any provider to this chain, can be multiple LDAPldap / in-memory / customBean / openid-connect, or a single jwt chain
blueriq.security.auth-providers-chain=myAuthProvider01,local01

Logout

Example request:

Code Block
title

.NET Runtime configuration

The .NET Runtime reads the authentication configuration from Web.config using the ASP.NET standard mechanisms for membership and role services. Blueriq has a DefaultMembershipProvider and DefaultRoleProvider that will read its users and roles from Web.config sections.

Example of using the Blueriq providers:

Code Block
languagexml
titleWeb.config
<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <configSections>
    <section name="defaultMembership" type="Aquima.WebApplication.Foundation.Security.DefaultMembershipProviderHandler" />
    <section name="defaultRoleProvider" type="Aquima.WebApplication.Foundation.Security.DefaultRoleProviderHandler" />
    ...
  </configSections>
  <defaultMembership>
    <users>
      <user name="admin" password="welcome" />
      <user name="user" password="welcome" />
    </users>
  </defaultMembership>
  <defaultRoleProvider>
    <users>
      <user name="admin">
        <roles>
          <role name="admin" />
        </roles>
      </user>
    </users>
  </defaultRoleProvider>
  <system.web>
    <authentication mode="Forms" />
    <membership defaultProvider="defaultProvider">
      <providers>
        <add name="defaultProvider" type="Aquima.WebApplication.Foundation.Security.DefaultMembershipProvider" />
      </providers>
    </membership>
    <roleManager enabled="true" defaultProvider="defaultProvider">
      <providers>
        <add name="defaultProvider" type="Aquima.WebApplication.Foundation.Security.DefaultRoleProvider" />
      </providers>
    </roleManager>
    ...
  </system.web>
  ...
</configuration>
Sample request
POST https://localhost/runtime/api/v1/logout HTTP/1.1

The response will be a simple 204 status code.


For version 2 of the API, the logout endpoint can support redirect URL parameter, and if the parameter is set then the endpoint will send a 302 status code with the location to the redirect parameter instead of the normal 204 status code.

Example request without redirect URL:

Code Block
titleSample request
POST https://localhost/runtime/api/v2/logout HTTP/1.1

The response will be a simple 204 status code.


Example request with redirect URL:

Code Block
titleSample request
POST https://localhost/runtime/api/v2/logout?redirect_uri=https://example.frontend.com/logged-out.html HTTP/1.1


The response will be a 302 status code and the location will be set to the value received in the redirect_uri parameter:

Code Block
HTTP/1.1 302 Found
Location: https://example.frontend.com/logged-out.html


If OpenID Connect is used in the Runtime and SSO Logout is enabled, then Runtime will redirect to the identity provider's logout endpoint and send the redirect_uri parameter to the identity provider.

Code Block
HTTP/1.1 302 Found
Location: https://identity.example.com/sso/logout?post_logout_redirect_uri=https://example.frontend.com/logged-out.html

After the identity provider logs out the user, it will redirect to the original URL:

Code Block
HTTP/1.1 302 Found
Location: https://example.frontend.com/logged-out.html


Logout URL whitelist

For security reasons a property where all the allowed redirect URLs can be specified:

Code Block
blueriq.security.logout-redirect-url-whitelist = url1, url2
Note

The URLs specified in the whitelist are case sensitive and represent only the prefix of the URL.

Warning

If the login type is set to openid-connect, then a redirect_uri parameter must be present when calling the logout endpoint

It is also possible to configure ASP.NET built-in providers (for example ActiveDirectoryMembershipProvider and/or AuthorizationStoreRoleProvider) or create your own implementations of System.Web.Security.MembershipProvider and/or System.Web.Security.RoleProvider

.