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.
Last updated