Single Sign-On (SSO) authentication
Configuring SSO as a Delegated Administrator
Single Sign-On (SSO) simplifies access to Hopex by enabling users to authenticate through your organization's identity provider (IdP), such as Google Workspace or Azure AD, using SAML2 or OpenID Connect protocols.
Users can then access multiple applications (including Hopex) without having to authenticate again.
To configure Single Sign-On (SSO):
1. Access the HAS Console as a Delegated Administrator.
2. Select Modules > Authentication > Identity providers navigation menu.
3. Select the appropriate protocol (SAML2 or OpenID Connect) based on your identity provider.
You can configure both.
4. Click create.
5. Enter the required parameters for the selected protocol (see corresponding tables below).
6. Click Save.
The HAS instance and all related nodes are restarted. All users are disconnected.
SAML2 parameters
Tab | Parameter | Description |
|---|
General | Active | Select to activate |
Display Name | Name of the button displayed on the login page for the SAML2 Identity Provider. |
Entity Identifier (Entity Id) | Identity of the Service Provider used when sending requests to the Identity Provider and in metadata. |
Metadata location | Location of the Identity Provider metadata (URL, absolute path, or relative path) E.g.: ~/App_Data/IdpMetadata.xml By default, the Entity Id is interpreted as the metadata location. |
Groups Authorized | Allows filtering of Hopex-related groups. Without filtering, you may encounter HTTP 400 errors due to large cookies generated from retrieved claims. |
ClaimForRoles | Name of the claim used for the role. |
ClaimForSub | Name of the claim used for the sub. |
ModulePath | Application root relative path for the Saml2 Assertion Consumer EndPoint (default: AuthServices). Each configured SAML2 must have a distinct value. |
Certificate and Signature | Certificate friendly name | Certificate used by the Service Provider for signing or decryption. |
Want assertion signed | Select if you want assertions to be signed. |
Want AuthnRequests signed | Select if you want AuthRequests sent to the Identity Provider to be signed. |
Authenticate Request Signing Behavior | Defines AuthRequest signing behavior: • "IfIdpWantAuthnRequestsSigned" (default): sign only if required by the IdP • "Always": always sign AuthRequests (AuthnRequestsSigned set to true in metadata) • "Never": never sign AuthRequests |
Certificate use | Defines certificate usage: • Both (default) • Signing • Encryption |
Organization | Name / Email / Url | Information (name, email, URL) describing the organization responsible for the entity. |
Contact | Email | Collection of contacts for the SAML2 entity. |
OpenID Connect parameters
Parameter | Description |
|---|
Display Name | Name of the button displayed on the login page for the OpenID Connect provider. Also used in the calculation of the RedirectURL (specific to OpenID Connect), which is displayed on the login page. |
Authority server URL | Defines the location of the OpenID server. |
Proxy URL | If a proxy is configured on the same server as UAS, this URL defines the outgoing address for the protocol to reach its endpoints. E.g.: DiscoveryEndPoint, TokenEndPoint |
Client Identifier | Identifier of your application. |
Secret client | Authentication method for the client: • Client Secret (less secure) • Certificate defined by a Thumbprint and an Audience (TokenEndPoint URL of your IdentityServer) to read the Access Token via the certificate. |
Scopes | Required scopes for the OpenID server: • openid (mandatory, provides JWT claims) • Additional scopes (e.g., email, profile) for extra claims. |
ClaimForRoles | Name of the claim used for the role. |
ClaimForSub | Name of the claim used for the sub. |
MetadataAddress server URL | DiscoveryEndPoint URL providing metadata of the OpenID Connect provider (token endpoints, scopes, etc.). Typically: [AuthorityServerURL]/.well-known/openid-configuration. Usually not required if Authority Server URL is set. |
Groups Authorized | Allows filtering of Hopex-related groups. Without filtering, you may encounter HTTP 400 errors due to large cookies generated from retrieved claims. |
Resolving Duplicate User Issues in SSO Migration
Common scenarios
Duplicate user records are commonly observed in the following scenarios:
• Migration from an on-premise solution (e.g.: Windows authentication) to a SaaS solution
• Transition from username/password authentication to SSO
Issue
During a migration to Single Sign-On (SSO), the login identifier often changes. This can result in the creation of two separate user records (Person System) in the system for the same physical person—one using the legacy login and one using the new SSO login.
As a result, users may experience issues such as unexpected password expiration prompts or loss of access rights due to mismatched identities.
Solution
To prevent duplication and preserve existing identity attributes (IdAbs) and access assignments, update the original login identifiers to match the SSO format.
To update login identifiers:
1. Access the login characteristics.
2. Update the Name of the login according to the SSO format.