KEYCLOAK-15856 Conditions in Conditional flow
This commit is contained in:
parent
5675da5ac3
commit
4b0e30c9bc
3 changed files with 45 additions and 0 deletions
|
@ -32,6 +32,7 @@ include::topics/authentication/flows.adoc[]
|
|||
include::topics/authentication/kerberos.adoc[]
|
||||
include::topics/authentication/x509.adoc[]
|
||||
include::topics/authentication/webauthn.adoc[]
|
||||
include::topics/authentication/conditions.adoc[]
|
||||
include::topics/sso-protocols.adoc[]
|
||||
include::topics/sso-protocols/oidc.adoc[]
|
||||
include::topics/sso-protocols/saml.adoc[]
|
||||
|
|
43
server_admin/topics/authentication/conditions.adoc
Normal file
43
server_admin/topics/authentication/conditions.adoc
Normal file
|
@ -0,0 +1,43 @@
|
|||
=== Conditions in Conditional flows
|
||||
|
||||
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_.
|
||||
|
||||
==== Available Conditions
|
||||
|
||||
`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`::
|
||||
This checks if the user has set up the required attribute.
|
||||
There is a possibility to negate output, which means the user should not have the attribute.
|
||||
The <<_user-attributes,User Attributes>> section shows how to add a custom attribute.
|
||||
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.
|
||||
|
||||
Negate output:::
|
||||
You can negate the output.
|
||||
In other words, the attribute should not be present.
|
|
@ -1,3 +1,4 @@
|
|||
[[_user-attributes]]
|
||||
|
||||
=== User Attributes
|
||||
|
||||
|
|
Loading…
Reference in a new issue