SSO Deepser Configuration
SSO (Single Sign On) is the technology that allows you to use delegated authentication to access Deepser.
In Deepser you can configure the sso using “Google” or “Azure” as the preconfigured provider.
Alternatively, you can also configure other delegated authentication providers using the Client OAuth configurations, but in this case you will need to manually configure the authentication parameters.
Configure SSO
To configure a new ss integrationor you will need to go to the System->Tools->OAuth->Client menu
Here you will need to click on the “Add Client” button:
As a first step you will need to assign a name to the client and click on the “Save” button to get the “Redirect Uri” that will be needed to configure the provider->side SSO.
After that, you can continue the configuration.
In the screen that will open you will be able to implement the configurations to implement SSO.
Below are the fields with their meaning:
Field | Description |
Name | Identification name of the OAuth Client |
Provider | OAuth provider. This field can take 3 values: Google, Azure, Generic. In case this field is set to Google or Azure it will be possible to ignore the configuration of the fields: {{Insert list of fields already configured}}. If the field is configured to Generic you will need to manually specify the configuration of the fields. |
Type | This field indicates the type of Client that is configured. The possible types are: User, Mail or Calendar. The type to be used for sso providers is: user. The Mail type is used to indicate an OAuth client that will interface with a mail provider. The Calendar type Is used to interface Deepser with an OAuth provider that provides a Calendar service. |
Client ID | This field must be enhanced with the client id that will be provided by the Delegated Authentication provider. |
Client Secret | This Field must be configured with the client secret that will be provided by the delegated authentication provider. |
Scope | This field indicates the scopes to which the client will request access to the resources. |
Url Authorize | Authorization url. this parameter is the endpoint to call to obtain authorization this parameter must be provided by the authentication provider |
Url Access Token | It is the ‘URL base’ to which the parameters are added to request the authentication token (post-authorization step). You do not need to compile it for Google or Azure providers, the default values will be used. |
Url Resource Owner Details | Base url of the server responsible for managing resources. This parameter must be formed by the provider. |
Proxy | This field, if enhanced, will use the proxy indicated to forward requests for Delegated authentication. |
Verify | If you have configured a proxy you can enable or disable SSL check. You do not need to compile it for Google or Azure providers, the default values will be used |
Status | This field indicates whether the client is Deepser enabled or whether the client is disabled. Please note that if the client is disabled Deepser will not use it nor will it display it among the usable clients. |
Scope Separator Char | Scope separator character, indicates which character the provider uses to indicate the end of one scope and the beginning of another. |
User Data Source | Users’s data source url. |
Endpoint User Data | The endpoint to which Deepser will make requests to obtain user data. |
Related LDAPs | Indicates whether LDAP integrations are connected to this client |
Username Attribute | This field indicates the name of the object field returned by the identity provider that will contain the username. |
User Fields | Maps the user’s internal attributes with those retrieved from the specified user data endpoint. You do not need to compile it for Google or Azure providers, the default values will be used. |
User Create Expression | Scripting area that allows you to specify how Deepser should behave when creating a new user and how to synchronize this user on the sso provider. |
User Update Fields | Scripting area that allows you to customize the update of a user in case it is modified on the sso provider. |
User Update Expression | PHP script to customize a user’s update,in the case of an SSO integration, for example. It is not necessary to fill it in for the Email Box type. |
Login Button Caption | Text that will be displayed on the login button that will be created on the deepser login screen. |
Login Button Icon | Image on the login button that will be displayed on the Deepser login page |
At this point the client verification key will be displayed, it will be necessary to click the validate button.
At the end of this configuration, you will need to click on the “Apply” button
You will then be redirected to the login screen of the Delegated authentication provider you are configuring.
At the end of the wizard if everything went well you will be redirected to the Deepser OAuth client screen with a message that will indicate that the configuration has taken place successfully.
In case of errors on the same page the error message will appear at the top.
CONFIGURE PROVISIONING
The Provisioning functionality allows you to automatically create in Deepser the users and groups registered within your Microsoft Azure environment, if the latter have been enabled for the SSO application.
Therefore, instead of being created/updated only at each login, it is possible to perform a synchronization between the users present in Azure who must log into Deepser, and the related User records in Deepser.
This functionality can be performed only once, by clicking on the “Provision” button at the top right (mainly used for testing the configuration), or even be scheduled to run several times a day by configuring the Cron expression.
To configure this functionality in Deepser, in addition to what is seen in the “Configure SSO” section, within an Azure SSO client, it will be necessary to go to the “Provisioning” tab and configure the necessary parameters.
Below are the fields with their meaning:
Field | Description |
Provisioning enabled | If toggled on, provisioning is enabled |
Provisioning Provider | If “Azure” is selected, |
Cron Expression | If “Azure” is selected, some specific fields will appear and others will become required |
Tenant ID | Azure Tenant ID. Required for Azure provisioning provider. |
User Provisioning Mode | You can select the way in which users will be synchronized. Required for Azure provisioning provider. |
Disable Users | If toggled on, local user status will be updated with provisioned user status. |
Disable Deleted Users | If enabled, if the provided user has been deleted, or does not match the filters, or is removed from the users assigned to the application, disables the relative users in Deepser. |
User Filter | If provisioning provider is Azure, write filters in query string format, ie: $filter=surname eq ‘Foo’ $filter=jobTitle eq null $filter=userPrincipalName in (“Foo”,”Bar”) $search=”surname:Foo” For documentation, see Microsoft Graph documentation |
User Group Filter | Only provision users which are members of these specific groups. Groups are filtered by the field specified in Group Name Attribute |
Group Name Attribute | Specify which group data attribute will be used as the name of the group. It is also the name of the group attribute to filter by in the User Group Filter and in the Group Filter.If no value is provided: Azure provisioning provider, will use displayName by default. |
Group Provisioning Mode | You can select the way in which groups will be synchronized. Required for Azure provisioning provider. |
Group Provisioning Enabled | If toggled on, groups will also be synchronized. |