Authentication Authorization OpenIDM currently provides a simple, yet flexible authentication and authorization mechanism based on REST interface URLs and on roles stored in the repository.

Authentication Internal users Authentication Managed users OpenIDM distinguishes between internal users and managed users.

OpenIDM sets up two internal users by default, anonymous and openidm-admin. OpenIDM separates these accounts from all other accounts to protect them from any reconciliation or sync processes. You can add or remove internal users at any time. anonymous This user serves to access OpenIDM anonymously, for users who do not have their own accounts. The anonymous user is primarily intended to allow self-registration. OpenIDM stores the anonymous user's password, amonymous, in clear text in the repository internal user table. The password is not considered to be secret. openidm-admin This user serves as the super administrator. After installation, the openidm-admin user has full access, and provides a fall back in case other users are locked out. Do not use openidm-admin for normal tasks. Usually no one is associated with the openidm-admin user, so audit log records pertaining to openidm-admin do not reflect the actions of any real person. OpenIDM encrypts the password, openidm-admin, by dfault. Change the password immediately after installation. For instructions, see To Replace the Default User & Password. OpenIDM stores internal users and their role membership in a table in the repository called internaluser when implemented in MySQL.

Objects Managed objects External users that OpenIDM manages are referred to as managed users. OpenIDM stores managed users in the managed objects table of the repository, called managedobjects when implemented in MySQL. A second table, managedobjectproperties in MySQL, serves as the index table. By default, the attribute names for managed user login and password are email and password, respectively.

OpenIDM does not allow access to the REST interface unless you authenticate. If a project requires anonymous access, to allow users to self-register for example, then allow access by user anonymous, password anonymous, as described in . In production, only applications are expected to access the REST interface. OpenIDM supports an improved authentication mechanism on the REST interface. The reason for not using standards, like basic authentication or form based authentication, is their leak of compatibility with AJAX. OpenIDM authentication with standard header fields $ curl --user userName:password This authentication is compatible with standard basic authentication except that it will not prompt for credentials if they are missing in the request. OpenIDM authentication with OpenIDM header fields $ curl --header "X-OpenIDM-Username: openidm-admin" --header "X-OpenIDM-Password: openidm-admin" For more details about the OpenIDM authentication mechanism please see Use Message Level Security . You can change the attributes OpenIDM uses to store user login and password values. The attribute names are shown in a database query defined in openidm/conf/repo.repo-type.json. Two queries are defined by default. credential-internaluser-query Uses the user object ID for login credential-query Uses the user email attribute for login The openidm/conf/authentication.json file defines the currently active query as the value of the queryId property. In the following example, credential-query is active. { "queryId": "credential-query", "queryOnResource": "managed/user", "defaultUserRoles": [ "openidm-authorized" ] }

Authentication Roles Roles OpenIDM sets up the following roles by default. openidm-reg Role for users accessing OpenIDM with the default anonymous account openidm-admin OpenIDM administrator role openidm-authorized Default role for any user authenticated with a user name and password openidm-cert Default role for any user authenticated with mutual SSL authentication You configure default roles assigned to successfully authenticated users authentication using the defaultUserRoles property in openidm/conf/authentication.json, which takes a list. The default value is openidm-authorized. { "queryId": "credential-query", "queryOnResource": "managed/user", "defaultUserRoles": [ "openidm-authorized" ] }

Authorization OpenIDM access control can be based on REST interface URLs. The openidm/script/router-authz.js script controls access to REST interface URLs. OpenIDM calls the script for each request. The script either throws the string Access denied, or nothing. If it throws Access denied, then OpenIDM denies the request. The default script is shown below. const allowCert = false; function contains(a, o) { if (typeof(a) != 'undefined' && a != null) { for (var i = 0; i <= a.length; i++) { if (a[i] === o) { return true; } } } return false; } function allow() { if (typeof(request.parent) === 'undefined' || request.parent.type != 'http') { return true; } var roles = request.parent.security['openidm-roles']; if (contains(roles, 'openidm-admin')) { return true; } else if (allowCert && contains(roles, 'openidm-cert')) { return true; } else { return false; } } if (!allow()) { throw "Access denied"; } The script can be seen as having three parts: constants, functions, and a decision. constants The constants can function as global switches, for example to toggle whether certificate-based authentication is allowed. The example that follows shows a constant used to toggle whether anonymous authentication is allowed. functions The default script defines two functions. The allow() function is called by the final if-statement. The contains() function takes the list of roles assigned to an authenticated user, and checks whether the list contains the role specified as the second argument. If the list does contain the role, then contains() returns true. decision The if-statement at the end of the script executes first. It calls the allow() function, which calls other functions. The allow() function returns true or false, triggering the behavior of the final if-statement. The following example extends the script to filter out requests not under /openidm/config or /openidm/managed. const allowCert = false; const allowAnon = false; function contains(a, o) { if (typeof(a) != 'undefined' && a != null) { for (var i = 0; i <= a.length; i++) { if (a[i] === o) { return true; } } } return false; } function matchesContext(path, context, allowRoot, allowSubcontext) { if (allowRoot && path === context) { return true; } if (allowSubcontext && path.substring(0, context.length + 1) === context + "/") { return true; } return false; } function allow() { if (typeof(request.parent) === 'undefined' || request.parent.type != 'http') { return true; } // Restrict the URLs that are accessible externally var path = request.parent.path; if (!(matchesContext(path, "/openidm/config", true, true) || matchesContext(path, "/openidm/managed", false, true))) { return false; } var roles = request.parent.security['openidm-roles']; if (contains(roles, 'openidm-admin')) { return true; } else if (allowCert && contains(roles, 'openidm-cert')) { return true; } else if (allowAnon && contains(roles, 'openidm-reg')) { return true; } else { return false; } } if (!allow()) { throw "Access denied"; } Compared to the default, this example has a second global constant, allowAnon, used to allow or deny anonymous access. The new constant serves in the allow() function when checking for openidm-reg membership, the role for anonymous users. Furthermore this example includes an additional function, matchesContext(), called from the allow() function before the role test. The additional test filters out all requests not to /openidm/config or below /openidm/managed. The context root itself is excluded in theh latter call to avoid actions like patch by query on /openidm/managed/user.