Clause de non-responsabilité: Cet article a été généré par traduction automatique.

Configuration de JWT SSO

Prev Next

Plans prenant en charge l’authentification unique (SSO)

Professional
Business
Enterprise






Qu’est-ce qu’unJWT?

Un jeton Web JSON (JWT) est un format de jeton chiffré qui transfère en toute sécurité des données telles que des informations d’identification (authentification et autorisation) entre deux applications. JWT est spécifiquement utilisé pour authentifier les connexions des lecteurs dans Document360. Cliquez ici pour en savoir plus sur JWT.


SSO d’entreprise à l’aide deJWT

Document360 utilise une approche similaire à PKCE (Proof Key for Code Exchange, une méthode OAuth sécurisée) pour générer le jeton JWT.

Le diagramme de haut niveau ci-dessous montre comment réaliser JWT flux d’authentification dans Document360.

Picture1.png

Étapes du flux d’authentificationJWT

  1. Lorsque l’utilisateur final tente d’accéder à la base de connaissances configurée avec JWT, la base de connaissances Document360 redirige l’utilisateur final vers l’URL de connexion que le compte d’équipe a configurée dans les paramètres de JWT Document360.

    En supposant que l’URL de connexion configurée réside dans l’application client, ce qui nécessitera une authentification.

  2. En appelant le point de terminaison de connexion dans l’application client, il appellera la logique de connexion, qui enverra une requête avec :

    • Détails de l’utilisateur

    • ID client et clé secrète client vers l’URL de génération du code du serveur d’identité pour obtenir le code d’authentification

      Ce processus se fait via le canal arrière.

  3. L’URL de génération de code acceptera les requêtes POST avec la charge utile JSON indiquée ci-dessous :

    L’ID client et la clé secrète doivent être envoyés en tant qu’en-tête d’autorisation de base.

Suivez ce lien pour savoir comment l’en-tête doit être formé pour l’authentification de base.

Charge utile JSON

{
"username": "firstname + lastname",
"firstName": "firstname",
"lastName": "lastname",
"emailId": "user emailId",
"readerGroupIds": ["Obtain from Reader groups overview page in the Document360 portal (Optional)"],
"tokenValidity": 15 //minutes *()*
}

NOTE

Assurez-vous que la syntaxe JSON est correcte pour éviter les erreurs de configuration.

  1. Le serveur d’identité génère le code en fonction des détails de l’utilisateur, de l’ID client et de la clé secrète client, puis renvoie le code généré à l’application client.

    Cela se fait via le canal arrière.

  2. Une fois que l’application client reçoit le code d’authentification du serveur d’identité,

    • L’application client ajoutera le code à l’URL de rappel trouvée dans les paramètres deJWT et redirigera l’utilisateur vers l’URL de rappel avec le code.

    • Par exemple: HTTPS://{project_name}.document360.io/jwt/authorize?code={code}

NOTE

Le code d’authentification est un code à usage unique et ne peut pas être réutilisé.

  1. Une fois que la base de connaissances reçoit le code d’authentification dans le paramètre de requête, elle envoie le code au serveur d’identité via le canal retour pour le jeton d’ID et le jeton d’accès.

  2. Une fois que la base de connaissances a reçu le jeton d’ID, elle crée une session pour le compte de l’utilisateur mentionné dans les détails de l’utilisateur précédents.

    • Par défaut, cette session sera valide pendant 15 minutes. Une fois le cookie de session expiré, l’utilisateur final sera redirigé vers l’URL de connexion (hébergée dans l’application client) pour obtenir un nouveau code, et le flux se répétera.

    • Le renouvellement de la session se fera sans heurts puisque l’utilisateur est déjà authentifié auprès de l’application client

Validité du jeton

La valeur minimale qui peut être définie est de 5 minutes et la valeur maximale qui peut être définie est de 1440 minutes (1 jour).

friser

Pour tester la configuration JWT, vous pouvez utiliser la commande cURL avec les spécifications suivantes. La version HTTP doit être spécifiée (HTTP2 sur TLS et version de SSL sur TLS 1.2. Sans cela, la cURL échouerait.

NOTE

Contrairement à d’autres options IdP disponibles (Okta, Azure AD, etc.), l’utilisateur n’a pas besoin d’un compte de lecteur distinct sur Document360. Un compte sur l’application client suffit.

Après avoir activé la connexion JWT, le lecteur peut utiliser l’application cliente pour se connecter en tant que compte de lecteur sur le site de la base de connaissances Document360.

NOTE

Actuellement, Document360 fournit une fonctionnalité de l’un ou l’autre pour les normes SSO. Une fois que l’IdP est configuré à l’aide d’une norme SSO (SAML, OpenID ou JWT) pour un projet, l’utilisateur ne peut pas créer une autre session simultanée.

Par ex. Si un projet est configuré dans la norme OpenID avec Okta comme fournisseur d’identité, les options SAML et JWT sont désactivées.


Configuration de l’authentification unique

Création d’un JWT

Pour créer un jeton Web JSON (JWT), procédez comme suit :

  1. Connectez-vous au portail Document360.

  2. Allez à Settings (> Users & security > JWT.

  3. Créez un JWT (Client secret) à partir d’ici en cliquant sur le bouton Créer JWT .

  4. Copiez la clé secrète client générée en cliquant sur l’icône de copie et en cliquant sur Fermer.

image.png

NOTE

La même clé secrète client générée ne sera pas disponible lorsque vous reviendrez sur cette section. Si nécessaire, le secret du client doit être régénéré.

La page de configuration de JWT avec toutes les données sera disponible dès maintenant.


Configuration de JWT

Une fois qu’un JWT est créé, la page de configuration du JWT est visible.

  • Configurez votre application : Copiez l’ID client, l’URL de rappel, l’URL de génération de code, la clé secrète client et collez-les dans les champs appropriés de l’application cliente

image.png

  • État JWT : activez ou désactivez la connexion JWT SSO pour les lecteurs à l’aide de cette bascule. Si la bascule est désactivée, les lecteurs ne pourront pas se connecter au site de la base de connaissances à l’aide de leurs informations d’identification d’application cliente.

  • Supprimer JWT : cliquez sur le bouton Supprimer pour supprimer le JWT configuré. Vous ne pouvez pas annuler cette action.

  • Configuration de base de JWT : collez l’URL de connexion obtenue à partir de l’application du client.

    • Les lecteurs atterriront sur la page de déconnexion dédiée aux lecteurs JWT SSO si un lien de déconnexion personnalisé n’est pas fourni.

image.png


Redirection vers d’autres pages au lieu de la page d’accueil

Par défaut, après s’être connectés, les utilisateurs sont redirigés vers la page d’accueil de votre base de connaissances.

  • Si votre page d’accueil n’est pas publiée, les utilisateurs seront redirigés vers la page /docs .

  • Pour rediriger les utilisateurs vers une autre page de votre base de connaissances (autre que les pages d’accueil ou /docs ), configurez la redirection lors de l’installation de JWT à l’aide du code suivant.

Modèle d’URL

https://<Knowledge base URL>/jwt/authorize?code=<code>&redirectUrl=<redirect path>

Paramètres

  • URL de la base de connaissances : l’URL principale de votre site de base de connaissances.

  • Code : L’ID du client.

  • URL de redirection : la nouvelle URL où vous souhaitez que les utilisateurs atterrissent après la connexion.

Exemple

https://example.document360.io/jwt/authorize?code=FOTaS_SW6dLGytQXvrG_rRFGhyPvrDDrgxJAZzYvJcY&redirectUrl=/docs/5-basic-things-to-get-started

NOTE

Document360 enverra l’URL de redirection vers RedirectPath le point de terminaison de connexion. Lorsque le point de terminaison de connexion redirige vers la base de connaissances avec le code d’authentification, il doit renvoyer l’URL de redirection en tant que RedirectUrl paramètre.


Dépannage

Si vous rencontrez des problèmes lors de la configuration de l’authentification unique JWT, reportez-vous à l’erreur courante suivante et à sa solution :

Erreur 401-non autorisée lors du test de JWT dans Postman

Erreur : Erreur 401 non autorisée

Si vous rencontrez une erreur 401 non autorisé lors du test de JWT (JSON Web Token) à l’aide de Postman, cela se produit généralement parce que les paramètres d’autorisation ne sont pas configurés correctement.

Étapes à résoudre :

Pour résoudre cette erreur, procédez comme suit :

  1. Dans Postman, ouvrez la demande que vous testez.

  2. Accédez à l’onglet Autorisation .

  3. Définissez le type d’autorisation sur Authentification de base.

  4. Dans le champ Nom d’utilisateur , entrez l’ID client.

  5. Dans le champ Mot de passe , entrez la clé secrète client.

  6. Allez dans l’onglet Corps .

  7. Sélectionnez l’option raw dans la liste déroulante et assurez-vous que le format est défini sur JSON.

  8. Ajoutez la charge utile JSON requise pour la demande d’API.

  9. Cliquez sur Envoyer pour exécuter la demande.

Vérifiez la réponse pour les résultats attendus. Si la demande aboutit, vous devriez recevoir un code d’authentification ou un jeton dans la réponse.


Foire aux questions

Puis-je utiliser un seul identifiant JWT pour prendre en charge plusieurs instances de mon application sur le même site de la base de connaissances Document360 ?

Non, actuellement, Document360 prend en charge une seule configuration de connexion JWT par projet.

  • Une connexion JWT commune ne peut pas être partagée entre plusieurs instances de votre application pour la même base de connaissances Document360.

  • Chaque projet ne peut authentifier qu’une seule instance d’application JWT à la fois.

Si un utilisateur JWT configuré se déconnecte de l’application cliente, cela signifie-t-il qu’il sera également déconnecté de Document360 ?

Non, la session sur Document360 est indépendante après l’authentification unique initiale. Les utilisateurs peuvent continuer à utiliser Document360 jusqu’à l’expiration de la validité du jeton, même après s’être déconnectés de l’application cliente.

Exemple: Si la validité du jeton est définie sur 1 jour, la session Document360 restera active jusqu’à l’expiration du jeton. Une fois que c’est le cas, l’utilisateur sera déconnecté.

Quelles sont les tranches de validité minimale et maximale des jetons ?

La valeur minimale qui peut être définie est de 5 minutes et la valeur maximale qui peut être définie est de 1440 minutes (1 jour).

Puis-je fournir une valeur qui dépasse la bande de validité du jeton autorisée ?

Non, si une valeur en dehors de la plage est fournie, le système attribuera automatiquement la valeur autorisée la plus proche :

  • 5 minutes pour les valeurs inférieures au minimum.

  • 1440 minutes pour les valeurs supérieures au maximum.

Quelle est la différence entre JWT et SSO ?

Vous pouvez consulter une comparaison entre JWT (JSON Web Token) et SSO (Single Sign-On) dans le tableau ci-dessous :

Aspect

JWT

SSO

Authentification

Jetons générés par session/demande de l’utilisateur.

Authentification centralisée entre les applications.

Expiration du jeton

Les jetons expirent généralement après une période définie.

Pas de jeton, session gérée par le fournisseur d’identité.

Sécurité

Nécessite un stockage sécurisé des jetons.

Stockage centralisé des informations d’identification plus sécurisé.

Usage

Utilisé pour l’authentification sans état à usage unique.

Utilisé pour plusieurs applications avec une connexion unique.

Intégration

Plus facile à mettre en œuvre dans les applications personnalisées.

Nécessite l’intégration avec un fournisseur d’identité.

Les lecteurs peuvent-ils se connecter avec OpenID ou SAML si JWT est configuré pour le projet ?

Non, les lecteurs ne peuvent pas se connecter avec OpenID ou SAML si JWT est configuré pour le projet. Document360 n’autorise qu’une seule norme SSO (JWT, OpenID ou SAML) à être active par projet à la fois.

Quelles fonctionnalités ne sont pas prises en charge lorsque JWT est configuré pour le projet ?

Les fonctions suivantes ne sont pas prises en charge lorsque JWT est configuré pour le projet :

  1. Paramètres avancés : enregistrez automatiquement l’authentification unique et ignorez la page de connexion commune de Document360.

  2. Lecteurs : Auto-inscription.