One Identity Manager uses different authentication modules for logging into the REST API. Authentication modules identify the system users to be used and load the user interface and database resource editing permissions depending on their permission group memberships.
NOTE:
-
After initial schema installation, only the System user and Component Authenticator authentication modules and the role-based authentication modules are enabled in One Identity Manager.
-
Authentication modules are defined in the modules and are not available until One Identity Manager modules are installed.
-
To access the REST API from external applications you can use the OAuth 2.0/OpenID Connect and OAuth 2.0/OpenID Connect (rolebased) authentication modules. For more detailed information, see the One Identity Manager Authorization and Authentication Guide.
-
To access the REST API in the application server, users need the program function Enables access to the REST API in the application server (AppServer_API).
Related topics
The authentication string is formatted as follows:
Module=<name>;<property1>=<value1>;<property2>=<value2>,…
Example:
Module=DialogUser;User=<user name>;Password=*****
The initial data is one part of the authentication string (parameter-value pair without module ID). Initial data from the authentication string is pre-allocated by default for each authentication instance. Some authentication modules are not requiring any parameter besides specifying the authentication module.
For more detailed information about authentication modules, see the One Identity Manager Authorization and Authentication Guide.
The list of supported, respectively activated authentication modules can be retrieved using the URL <BaseURL>/appserver/authmodules.
Table 2: List authentication modules request
|
Get |
<BaseURL>/appserver/authmodules |
None |
Response schema:
{
"passwordBased": Boolean,
}
Example:
https://<Hostname>/AppServer/appserver/authmodules
Response:
[{
"id": "RoleBasedManualADS",
"caption": "Active Directory user account (manual input/role based)",
"passwordBased": false,
"isDefault": false
},
{
"id": "RoleBasedADSAccount",
"caption": "Active Directory user account (role based)",
"passwordBased": false,
"isDefault": false
},
{
"id": "DialogUser",
"caption": "System user",
"passwordBased": false,
"isDefault": true
},
{
"id": "RoleBasedPerson",
"caption": "Employee (role based)",
"passwordBased": false,
"isDefault": false
},
{
"id": "OAuthRoleBased",
"caption": "OAuth 2.0 (role based)",
"passwordBased": false,
"isDefault": false
},
{
"id": "OAuth",
"caption": "OAuth 2.0",
"passwordBased": false,
"isDefault": false
},
{
"id": "ADSAccount",
"caption": "Active Directory user account",
"passwordBased": false,
"isDefault": false
},
{
"id": "DynamicPerson",
"caption": "Employee (dynamic)",
"passwordBased": false,
"isDefault": false
}]
To get the details for a specific authentication module, use the URL <baseURL>/appserver/authmodules/{id}
Table 3: Get authentication module request
|
Get |
<BaseURL>/appserver/authmodules/{id} |
None |
Table 4: Get authentication module parameters
|
id |
Authentication module (required) |
path |
string |
Response schema:
[{
"authTemplate": String,
"passwordBased": Boolean,
"isDefault": Boolean
}]
Example:
https://<Hostname>/AppServer/appserver/authmodules/DialogUser
Response:
[{
"id": "DialogUser",
"caption": "System user",
"authTemplate": "Module=DialogUser;User[VI.DB_USER]=;(Password)Password[VI.DB_Password]=",
"passwordBased": true,
"isDefault": false
}]
The values in the property authTemplate can be used to identify the format of the authString needed to authenticate against the application server. You can ignore the parts in [] and () as those are the caption keys and value types used in the front ends only.
For example, a valid authentication string would be Module=DialogUser;User=MyUser;Password=$ecret.
