2021-06-17 14:39:30 +00:00
|
|
|
=== Conditions in conditional flows
|
2020-11-20 07:21:34 +00:00
|
|
|
|
|
|
|
As was mentioned in <<_execution-requirements, Execution requirements>>, _Condition_ executions can be only contained in _Conditional_ subflow.
|
|
|
|
If all _Condition_ executions evaluate as true, then the _Conditional_ sub-flow acts as _Required_.
|
|
|
|
You can process the next execution in the _Conditional_ sub-flow.
|
|
|
|
If some executions included in the _Conditional_ sub-flow evaluate as false, then the whole sub-flow is considered as _Disabled_.
|
|
|
|
|
2021-06-17 14:39:30 +00:00
|
|
|
==== Available conditions
|
2020-11-20 07:21:34 +00:00
|
|
|
|
|
|
|
`Condition - User Role`::
|
|
|
|
This execution has the ability to determine if the user has a role defined by _User role_ field.
|
|
|
|
If the user has the required role, the execution is considered as true and other executions are evaluated.
|
|
|
|
The administrator has to define the following fields:
|
|
|
|
|
|
|
|
Alias:::
|
|
|
|
Describes a name of the execution, which will be shown in the authentication flow.
|
|
|
|
|
|
|
|
User role:::
|
|
|
|
Role the user should have to execute this flow.
|
|
|
|
To specify an application role the syntax is `appname.approle` (for example `myapp.myrole`).
|
|
|
|
|
|
|
|
`Condition - User Configured`::
|
|
|
|
This checks if the other executions in the flow are configured for the user.
|
|
|
|
The Execution requirements section includes an example of the OTP form.
|
|
|
|
|
|
|
|
`Condition - User Attribute`::
|
2023-06-19 13:22:35 +00:00
|
|
|
This checks if the user has set up the required attribute: optionally, the check can also evaluate the group attributes.
|
2020-11-20 07:21:34 +00:00
|
|
|
There is a possibility to negate output, which means the user should not have the attribute.
|
2024-02-09 12:45:30 +00:00
|
|
|
The link:#user-profile[User Attributes] section shows how to add a custom attribute.
|
2020-11-20 07:21:34 +00:00
|
|
|
You can provide these fields:
|
|
|
|
|
|
|
|
Alias:::
|
|
|
|
Describes a name of the execution, which will be shown in the authentication flow.
|
|
|
|
|
|
|
|
Attribute name:::
|
|
|
|
Name of the attribute to check.
|
|
|
|
|
|
|
|
Expected attribute value:::
|
|
|
|
Expected value in the attribute.
|
|
|
|
|
2023-06-19 13:22:35 +00:00
|
|
|
Include group attributes:::
|
|
|
|
If On, the condition checks if any of the joined group has one attribute matching the configured name and value: this option can affect performance
|
|
|
|
|
2020-11-20 07:21:34 +00:00
|
|
|
Negate output:::
|
|
|
|
You can negate the output.
|
|
|
|
In other words, the attribute should not be present.
|
2020-12-17 08:45:01 +00:00
|
|
|
|
|
|
|
==== Explicitly deny/allow access in conditional flows
|
|
|
|
|
|
|
|
You can allow or deny access to resources in a conditional flow.
|
|
|
|
The two authenticators `Deny Access` and `Allow Access` control access to the resources by conditions.
|
|
|
|
|
|
|
|
`Allow Access`::
|
|
|
|
Authenticator will always successfully authenticate.
|
|
|
|
This authenticator is not configurable.
|
|
|
|
|
|
|
|
`Deny Access`::
|
|
|
|
Access will always be denied.
|
|
|
|
You can define an error message, which will be shown to the user.
|
|
|
|
You can provide these fields:
|
|
|
|
|
|
|
|
Alias:::
|
|
|
|
Describes a name of the execution, which will be shown in the authentication flow.
|
|
|
|
|
|
|
|
Error message:::
|
|
|
|
Error message which will be shown to the user.
|
|
|
|
The error message could be provided as a particular message or as a property in order to use it with localization.
|
2022-10-19 06:47:23 +00:00
|
|
|
(i.e. "_You do not have the role 'admin'._", _my-property-deny_ in messages properties)
|
2020-12-17 08:45:01 +00:00
|
|
|
Leave blank for the default message defined as property `access-denied`.
|
|
|
|
|
|
|
|
Here is an example how to deny access to all users who do not have the role `role1` and show an error message defined by a property `deny-role1`.
|
|
|
|
This example includes `Condition - User Role` and `Deny Access` executions.
|
|
|
|
|
|
|
|
.Browser flow
|
2022-10-05 18:43:15 +00:00
|
|
|
image:images/deny-access-flow.png[Deny access flow]
|
2020-12-17 08:45:01 +00:00
|
|
|
|
2021-06-17 14:39:30 +00:00
|
|
|
.Condition - user role configuration
|
2022-10-05 18:43:15 +00:00
|
|
|
image:images/deny-access-role-condition.png[Deny access role settings]
|
2020-12-17 08:45:01 +00:00
|
|
|
|
2021-06-17 14:39:30 +00:00
|
|
|
.Configuration of the `Deny Access` is really easy. You can specify an arbitrary Alias and required message like this:
|
2022-10-05 18:43:15 +00:00
|
|
|
image:images/deny-access-execution-cond.png[Deny access execution settings]
|
2020-12-17 08:45:01 +00:00
|
|
|
|
|
|
|
The last thing is defining the property with an error message in the login theme `messages_en.properties` (for English):
|
|
|
|
|
|
|
|
[source]
|
|
|
|
----
|
|
|
|
deny-role1 = You do not have required role!
|
|
|
|
----
|