Page History
...
Note |
---|
The Blueriq Runtime delivers an out-of-the-box in-memory authentication provider. These default implementations should only be used for development purposes as they may store the credentials in plain text on the filesystem. |
Runtime configuration
The
...
Runtime reads the authentication configuration from Spring environment properties, under the covers Spring Security is used. In the
...
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
...
Code Block |
---|
# format: USERNAME=PASSWORD,ROLE1,ROLE2
admin=welcome,dcm,administrator
jane=welcome02,dcm,operator
john=welcome03,dcm |
Defining a customBean
authentication provider
In the application.properties
file only one property is expected for a customBean
authentication provider:
...
be in-memory
...
Defining an in-memory
authentication provider
In the application.properties
file two properties are expected for an in-memory
authentication provider:
Code Block |
---|
blueriq.security.auth-providers.local01.type=in-memory
blueriq.security.auth-providers.local01.users.location=users.properties
|
auth-providers
is the property name of the authentication providers property- After the property name, the name of the authentication provider is specified. In this example the name is
local01
.
...
, 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
An implementation example of a custom AuthenticationProvider:
Code Block |
---|
@Component
public class MyCustomAuthenticationProvider implements AuthenticationProvider {
@Override
public Authentication authenticate(Authentication authentication)
throws AuthenticationException {
String name = authentication.getName();
String password = authentication.getCredentials().toString();
if (shouldAuthenticateAgainstThirdPartySystem()) {
// use the credentials and authenticate against the third-party system
return new UsernamePasswordAuthenticationToken(name, password, new ArrayList<>());
} else {
return null;
}
}
@Override
public boolean supports(Class<?> authentication) {
return authentication.equals(UsernamePasswordAuthenticationToken.class);
}
}
@Configuration
public class SecurityConfigurationMyAuthProviderConfig {
@Bean
public AuthenticationProvider myAuthProvider01() {
return new MyCustomAuthenticationProvider();
}
} |
...
:
Code Block | ||
---|---|---|
| ||
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 ldap / in-memory / customBean / openid-connect, or a single jwt chain blueriq.security.auth-providers-chain=myAuthProvider01,local01 |
.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 | ||||
---|---|---|---|---|
| ||||
<?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> |
...
Logout
Example request:
Code Block | ||
---|---|---|
| ||
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 | ||
---|---|---|
| ||
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 | ||
---|---|---|
| ||
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 |