OpenCTI supports several authentication providers. If you configure multiple strategies, they will be tested in the order you declared them.
Activation
You need to configure/activate only that you really want to propose to your users in term of authentication
The product proposes two kind of authentication strategy:
Form (asking user for a user/password)
Buttons (click with authentication on an external system)
Supported Strategies
Under the hood we technically use the strategies provided by PassportJS. We integrate a subset of the strategies available with passport we if you need more we can theatrically integrate all the passport strategies.
Local users (form)
This strategy used the OpenCTI database as user management.
OpenCTI use this strategy as the default but its not the one we recommend for security reason.
If you would like to use LDAP groups to automatically associate LDAP groups and OpenCTI groups/organizations:
"ldap":{"config":{..."group_search_base":"cn=Groups,dc=mydomain,dc=com","group_search_filter":"(member={{dn}})","groups_management":{// To map LDAP Groups to OpenCTI Groups"group_attribute":"cn","groups_mapping":["LDAP_Group_1:OpenCTI_Group_1","LDAP_Group_2:OpenCTI_Group_2",...]},"organizations_management":{// To map LDAP Groups to OpenCTI Organizations"group_attribute":"cn","groups_mapping":["LDAP_Group_1:OpenCTI_Organization_1","LDAP_Group_2:OpenCTI_Organization_2",...]}}}
SAML (button)
This strategy can be used to authenticate your user with your company SAML and is based on Passport - SAML.
The cert parameter is mandatory (PEM format) because it is used to validate the SAML response.
The private_key (PEM format) is optional and is only required if you want to sign the SAML client request.
Certificates
Be careful to put the cert / private_key key in PEM format. Indeed, a lot of systems generally export the the keys in X509 / PCKS12 formats and so you will need to convert them.
Here is an example to extract PEM from PCKS12:
opensslpkcs12-inkeystore.p12-outnewfile.pem-nodes
Here is an example of SAML configuration using environment variables:
OpenCTI support mapping SAML Roles/Groups on OpenCTI Groups. Here is an example:
"saml":{"config":{...,// Groups mapping"groups_management":{// To map SAML Groups to OpenCTI Groups"group_attributes":["Group"],"groups_mapping":["SAML_Group_1:OpenCTI_Group_1","SAML_Group_2:OpenCTI_Group_2",...]},"groups_management":{// To map SAML Roles to OpenCTI Groups"group_attributes":["Role"],"groups_mapping":["SAML_Role_1:OpenCTI_Group_1","SAML_Role_2:OpenCTI_Group_2",...]},// Organizations mapping"organizations_management":{// To map SAML Groups to OpenCTI Organizations"group_attributes":["Group"],"groups_mapping":["SAML_Group_1:OpenCTI_Organization_1","SAML_Group_2:OpenCTI_Organization_2",...]},"organizations_management":{// To map SAML Roles to OpenCTI Organizations"group_attributes":["Role"],"groups_mapping":["SAML_Role_1:OpenCTI_Organization_1","SAML_Role_2:OpenCTI_Organization_2",...]}}}
Here is an example of SAML Groups mapping configuration using environment variables:
This strategy allows to use the OpenID Connect Protocol to handle the authentication and is based on Node OpenID Client that is more powerful than the passport one.
"oic":{"identifier":"oic","strategy":"OpenIDConnectStrategy","config":{"label":"Login with OpenID","issuer":"https://auth.mydomain.com/auth/realms/mydomain","client_id":"XXXXXXXXXXXXXXXXXX","client_secret":"XXXXXXXXXXXXXXXXXX","redirect_uris":["https://opencti.mydomain.com/auth/oic/callback"]}}
Here is an example of OpenID configuration using environment variables:
OpenCTI support mapping OpenID Roles/Groups on OpenCTI Groups (everything is tied to a group in the platform). Here is an example:
"oic":{"config":{...,// Groups mapping"groups_management":{// To map OpenID Groups to OpenCTI Groups"groups_scope":"groups","groups_path":["groups","realm_access.groups","resource_access.account.groups"],"groups_mapping":["OpenID_Group_1:OpenCTI_Group_1","OpenID_Group_2:OpenCTI_Group_2",...]},"groups_management":{// To map OpenID Roles to OpenCTI Groups"groups_scope":"roles","groups_path":["roles","realm_access.roles","resource_access.account.roles"],"groups_mapping":["OpenID_Role_1:OpenCTI_Group_1","OpenID_Role_2:OpenCTI_Group_2",...]},// Organizations mapping "organizations_management":{// To map OpenID Groups to OpenCTI Organizations"organizations_scope":"groups","organizations_path":["groups","realm_access.groups","resource_access.account.groups"],"organizations_mapping":["OpenID_Group_1:OpenCTI_Group_1","OpenID_Group_2:OpenCTI_Group_2",...]},"organizations_management":{// To map OpenID Roles to OpenCTI Organizations"organizations_scope":"roles","organizations_path":["roles","realm_access.roles","resource_access.account.roles"],"organizations_mapping":["OpenID_Role_1:OpenCTI_Group_1","OpenID_Role_2:OpenCTI_Group_2",...]},}}
Here is an example of OpenID Groups mapping configuration using environment variables:
Then when accessing for the first time OCTI, the browser will ask for the certificate you want to use.
Automatically create group on SSO
The variable auto_create_group can be added in the options of some strategies (LDAP, SAML and OpenID). If this variable is true, the groups of a user that logins will automatically be created if they don’t exist.
More precisely, if the user that tries to authenticate has groups that don’t exist in OpenCTI but exist in the SSO configuration, there are two cases:
if auto_create_group= true in the SSO configuration: the groups are created at the platform initialization and the user will be mapped on them.
else: an error is raised.
Example
We assum that Group1 exists in the platform, and newGroup doesn’t exist. The user that tries to log in has the group newGroup. If auto_create_group = true in the SSO configuration, the group named newGroup will be created at the platform initialization and the user will be mapped on it. If auto_create_group = false or is undefined, the user can’t login and an error is raised.
In this example the users have a login form and need to enter login and password. The authentication is done on LDAP first, then locally if user failed to authenticate and finally fail if none of them succeded. Here is an example for the production.json file: