How does IDM (All versions) use anonymous access?
The purpose of this article is to provide information on the access available to the anonymous user in IDM, and to explain how to limit or remove this access if required.
Overview
The anonymous user renders the login page in IDM. Additionally, if enabled, anonymous is used to perform user self-registration and password reset. To accomplish these functions, anonymous needs access to the configuration files, including the user interface settings for language, color schemes and logos.
The anonymous user has the internal/role/openidm-reg role. In IDM 6, you do not need to include the full path; you can just refer to the role name, for example, openidm-reg. By default, this role has limited functionality as defined in the following files depending on version:
- IDM 7 and later: the access.json file (located in /path/to/idm/conf) and the router-authz.js file (located in /path/to/idm/bin/defaults/script). These files are explained in more detail in Authorization and roles.
-
IDM 6.x: the access.js file (located in /path/to/idm/script) and the router-authz.js file (located in /path/to/idm/bin/defaults/script). These files are explained in more detail
in How do I customize authorization rules for http requests in IDM 6.x?
Note
The authentication mechanism for the anonymous user uses the STATIC_USER authentication module to improve performance: STATIC_USER.
Understanding anonymous access
The anonymous user has access rights as determined by the internal/role/openidm-reg role in the access.json file or the access.js file.
For example, the internal/role/openidm-reg role is available for registration for the managed/user endpoint (http request) by default:
{ "pattern" : "managed/user", "roles" : "internal/role/openidm-reg", "methods" : "create", "actions" : "*", "customAuthz" : "checkIfAnyFeatureEnabled('registration') && isSelfServiceRequest() && onlyEditableManagedObjectProperties('user', [])" }Certain endpoints (such as the managed/user one) depend on additional authorization checks such as registration/selfRegistration or passwordReset being enabled. If you want to use the associated functionality, you must ensure these authorization checks are enabled in the ui-configuration.json file. This is described in more detail in Self-Registration and Password Reset.
The internal/role/openidm-reg role is also available to all endpoints that apply to all roles. For example, the config/ui/themeconfig endpoint:
{ "pattern" : "config/ui/themeconfig", "roles" : "*", "methods" : "read", "actions" : "*" }If you don't want to use the user interface (config/ui/themeconfig endpoint) or allow access to the customizable information service (info/* endpoint), you should update the relevant endpoint to implicitly state each individual role they are accessible to in order to remove access for the internal/role/openidm-reg role.
For example, if you only use the default roles supplied with IDM, you would update the roles definition as follows to remove the internal/role/openidm-reg role:
"roles" : "internal/role/openidm-admin,internal/role/openidm-authorized,internal/role/openidm-cert,internal/role/openidm-tasks-manager",See Also
Related Training
ForgeRock Identity Management Deep Dive (IDM-420)
Related Issue Tracker IDs
N/A