Rules

Last updated 1 year ago

Rules

Rules are used to map controls to clients (applications); they provide the following use cases:

Enforce consent before accessing the application (i.e. required legal control). If the legal control in question has a zero (0) score then its consent will be required with the start of a signup. If the legal control has a non-zero score, or during a login, its consent will be required prior to redirecting to the application.
Request consent before accessing the application (i.e. optional legal control). The same logic holds as to when it's asked as in the above case for required legal controls, though it can be skipped prior to redirecting to the application (it will depend on the login UI to show it or not).
Allow certain API scopes for the application (i.e. optional scope controls). This will make sure that in the OAuth 2.0 configuration the scopes are now listed as allowed. If consent is required for such scopes this will be required prior to redirecting to the (external) application.
Mandate API scopes for the application (i.e. required scope controls). This will also make sure that in the OAuth 2.0 configuration the scopes are now listed as allowed. If consent is required for such scopes this will be required prior to redirecting to the (external) application. As opposed to optional scopes these will always be required to gain access to the application.

Having no rules configured on a client , or only rules for controls with a zero (0) score, means that anyone can acces it, without any need to actually signup and enroll with factors. Hence the user will not be able to login again once the session has expired (unless they have added factor enrollments to their account). This is considered as anonymous access.

Configuring required scopes with a non-zero score provides security for your application as users will now be forced to signup and enroll with factors, or login and validate enrollments. If you add certain required scopes that require a permission, then you'll basically shield the application from public use and only those users with permissions will be able to use it (e.g. Admin UI). We highly recommend adding at least 1 required scope, such as openid which will be required to support OpenID Connect 1.0, and issue identity tokens to the application.

PreviousConsents NextAttributes

Last updated 1 year ago

Rules are used to map controls to clients (applications); they provide the following use cases:

Enforce consent before accessing the application (i.e. required legal control). If the legal control in question has a zero (0) score then its consent will be required with the start of a signup. If the legal control has a non-zero score, or during a login, its consent will be required prior to redirecting to the application.
Request consent before accessing the application (i.e. optional legal control). The same logic holds as to when it's asked as in the above case for required legal controls, though it can be skipped prior to redirecting to the application (it will depend on the login UI to show it or not).
Allow certain API scopes for the application (i.e. optional scope controls). This will make sure that in the OAuth 2.0 configuration the scopes are now listed as allowed. If consent is required for such scopes this will be required prior to redirecting to the (external) application.
Mandate API scopes for the application (i.e. required scope controls). This will also make sure that in the OAuth 2.0 configuration the scopes are now listed as allowed. If consent is required for such scopes this will be required prior to redirecting to the (external) application. As opposed to optional scopes these will always be required to gain access to the application.