Configurer une application OIDC générique

Ce guide explique comment connecter une application à UserLock Single Sign-On (SSO) en utilisant OpenID Connect (OIDC), une couche d’authentification bâtie sur OAuth 2.0. UserLock SSO joue le rôle de fournisseur OpenID, et l’application celui de partie de confiance.

Utilisez ce guide lorsque l’application prend en charge un fournisseur OIDC générique ou personnalisé. Si l’application figure déjà dans la liste des applications UserLock, utilisez son guide dédié. Si elle prend en charge SAML 2.0 plutôt que OIDC, consultez Configurer une application SAML générique.

Lorsqu’un utilisateur se connecte, l’application le redirige vers la page de connexion UserLock SSO. UserLock l’authentifie via Active Directory et le renvoie vers l’application, connecté. Les administrateurs peuvent alors appliquer les stratégies d'accés UserLock (MFA, restrictions temporelles, machines, ou localisation) à ces sessions.

1. Dans la console UserLock, accédez à ⚙️ Paramètres du serveur ▸ Authentification unique (SSO).

2. Dans la liste des applications disponibles, cliquez sur CustomOidc.

3. Ajoutez un nouveau profil et renseignez les champs suivants :

   Paramètre	Valeur
   Client ID	Un identifiant de votre choix pour le client OIDC, par exemple myapp-oidc. Toute valeur acceptée comme identifiant client standard convient
   ACS URL	La Redirect URI de l’application, aussi appelée callback URL ou redirect URL. Copiez-la exactement telle que l’application l’affiche : une redirection qui ne correspond pas est rejetée
   Client secret	Un secret sécurisé est généré automatiquement. Conservez la valeur proposée

4. Enregistrez le profil.

Gardez le Client ID et le Client secret à portée de main. Vous les saisirez tous les deux dans l’application à l’étape suivante.

L’URL de votre SSO UserLock est affichée dans ⚙️ Paramètres du serveur ▸ Authentification unique (SSO). Dans ce guide, <SSO_address> désigne cette URL sans le protocole. Pour https://sso.contoso.com, l’adresse SSO est sso.contoso.com. Si l’URL utilise un port personnalisé, incluez-le dans tous les endpoints : https://sso.contoso.com:450 donne sso.contoso.com:450.

Dans les paramètres d’authentification de l’application, ouvrez le fournisseur OIDC générique ou personnalisé et renseignez les valeurs suivantes :

Les applications nomment ces champs différemment. Un authorization endpoint peut apparaître sous le nom Auth URL ou Authorization URL, et un userinfo endpoint sous le nom API URL ou User info URL. Certaines applications ne demandent que l’issuer ou une URL de découverte, et récupèrent elles-mêmes tous les endpoints.

Enregistrez la configuration, et activez le fournisseur si l’application l’indique comme désactivé.

1. Ouvrez la page de connexion de l’application dans une fenêtre de navigation privée.

2. Sélectionnez l’option de connexion UserLock. Son libellé correspond au nom d’affichage configuré dans l’application.

3. Vérifiez que vous êtes redirigé vers la page de connexion UserLock SSO.

4. Connectez-vous avec les identifiants de domaine d’un compte Active Directory de test dont l’attribut mail est renseigné.

5. Vérifiez que vous êtes redirigé vers l’application, connecté, et que le compte affiche l’adresse e-mail attendue.

Pour les problèmes courants, consultez la page Dépannage du SSO. Si le problème persiste, contactez le support IS Decisions.

Les journaux UserLock SSO indiquent une authentification réussie, mais l’application refuse l’utilisateur. Deux causes sont fréquentes :

• La claim email est vide, car le compte Active Directory n’a pas d’attribut mail renseigné. Renseignez-le, puis reconnectez-vous.

• L’adresse e-mail appartient déjà à un autre compte dans l’application, qui refuse de les associer. Utilisez une autre adresse, ou supprimez ou renommez le compte en conflit.

Ouvrez https://<SSO_address>/.well-known/openid-configuration depuis un navigateur situé hors de votre réseau d’entreprise. L’URL doit être joignable en HTTPS et renvoyer le document de découverte. Si ce n’est pas le cas, vérifiez l’enregistrement DNS public, la liaison HTTPS et le certificat SSL, ainsi que toute règle réseau bloquant l’accès externe.

Une connexion qui atteint la page de connexion UserLock mais échoue au retour signifie que UserLock SSO est joignable depuis les navigateurs de vos utilisateurs, mais pas depuis les serveurs de l’application.

L’ACS URL du profil UserLock ne correspond pas à la Redirect URI envoyée par l’application. Comparez les deux valeurs caractère par caractère, y compris le protocole, le port éventuel, le chemin final et la présence ou non d’une barre oblique finale.

Vous pouvez étendre la sécurité des sessions SaaS en appliquant les stratégies d’accès UserLock, en complément de l’authentification.

• Appliquer la MFA sur les sessions SaaS : exiger une authentification renforcée.

• Restrictions horaires : définir quand les utilisateurs sont autorisés à se connecter.

• Règles de géolocalisation : appliquer des politiques en fonction de l’emplacement de l’utilisateur.

• Limites de sessions : autoriser ou interdire totalement l’ouverture de sessions SaaS pour certains utilisateurs.