Passer au contenu principal
Documentation
Documentation
Adaptive Planning
Dernière mise à jour : 2024-03-08
Enregistrer des clients API

Enregistrer des clients API

Sécurité : les domaines suivants dans le domaine fonctionnel System :
  • Set Up: Tenant Setup - Security
  • Administration de la sécurité
Workday prend en charge OAuth 2.0 dans le cadre de l’infrastructure des API de Workday. OAuth 2.0 permet aux utilisateurs Workday d’autoriser des clients tiers à accéder en leur nom à leurs données Workday en toute sécurité.
Pour accéder à l’API Workday, enregistrez les clients OAuth 2.0 avec Workday. Vous pouvez autoriser les clients OAuth 2.0 à accéder à l’API Workday pour chaque locataire.
  1. Accédez à la tâche
    Modifier la configuration du locataire - Sécurité
     .
  2. Dans la section
    Paramètres de OAuth 2.0
     , cochez la case
    OAuth 2.0 Clients Enabled
     .
  3. Accédez à la tâche
    Register API Client
     .
  4. Entrez le
    nom du client
    .
  5. Sélectionnez le
    type d’octroi de client
    .
    Option Description
    Attribution de code d'autorisation
    Pour les clients qui peuvent rendre persistantes des données, comme les applications mobiles.
    Subvention implicite (ne pas utiliser)
    Nécessaire pour les applications qui n’incluent pas de composante côté serveur, telles que les applications Javascript.
    Workday prévoit retirer ce type d’octroi de client dans une version future. Nous vous recommandons d’utiliser plutôt les types d’octrois de clients suivants :
    • Octroi de code d’autorisation avec prise en charge de PKCE.
    • Octroi de type Porteur JWT.
    Octroi de type Porteur JWT
    Utilisez le jeton Web JSON (JWT) pour les clients tels que votre intégration Salesforce. Ce type d’octroi vous permet de limiter l’échange d’ assertions de sécurité pour les jetons d’accès et d’actualisation aux utilisateurs du système d’intégration (ISU) que vous sélectionnez dans le champ
    Utilisateur du système d’intégration
     . Fournissez un
    certificat x509
     pour valider les signatures. Vous pouvez également cocher la case Autoriser
    les messages d’intégration
     pour vous assurer que Workday reçoit les informations nécessaires concernant le statut de l’intégration.
    Octroi de type Porteur SAML
    Pour les applications qui utilisent l’authentification unique SAML SSO pour l’authentification.
    Sélectionnez également une
    vérification d'attestation
    . Sélectionnez :
    • Pour valider les signatures,
      utilisez les IdP configurées
       afin d’utiliser le certificat public X.509 de l’IdP SAML configuré dans
      Modifier la configuration du locataire - Sécurité
       . Dans ce cas, l’entité de délivrance est l’IdP.
    • Utilisez un certificat (option x509)
       pour préciser un
      certificat x509
       afin de valider les signatures. Dans ce cas, l’entité de délivrance est l’identifiant de client API. Vous pouvez également sélectionner des ISU dans le champ
      Utilisateur du système d’intégration
       pour limiter l’échange d’ assertions de sécurité pour les jetons d’accès et d’actualisation à ces ISU.
    Vous pouvez également :
    • Cochez la case Autoriser
      l’accès à tous les utilisateurs système
       pour permettre à tous les utilisateurs, plutôt qu’aux utilisateurs du système d’intégration (ISU), d’utiliser le flux d’ assertions des portants SAML.
    • Cochez la case
      Autoriser les messages d’intégration
       pour vous assurer que Workday reçoit les informations nécessaires concernant le statut de l’intégration.
  6. (Facultatif) Cochez la
    case Clé de preuve de soutien pour l’échange de codes (PKCE)
     lorsque vous utilisez le type de subvention de client
    Authorization Code Grant
     pour ajouter la prise en charge de PKCE à votre client.
    PKCE permet au client de réduire le risque d’interception du code d’autorisation. Cochez cette case si le client prend en charge les demandes multiorigines activées avec le partage de ressources avec différences d’origine.
  7. (Facultatif) Cochez la case
    Appliquer un délai d’expiration du jeton d’accès de 60 minutes
     pour permettre au client API de renvoyer des jetons de titulaire qui :
    • Avoir une expiration de 60 minutes.
    • Ne pas invalider la fin des sessions, tant qu’elles n’ont pas expiré.
    Une fois que vous avez coché cette case, puis cliqué sur
    OK
    , vous ne pouvez plus la décocher.
  8. Sélectionnez une clé publique X.509 dans le champ
    Certificat x509
     .
    Ce champ est actif lorsque vous sélectionnez :
    • Octroi de type Porteur JWT
       en tant que
      Type d'octroi de client
      .
    • SAML Porteur Grant
       comme
      Type d’octroi de client
       et
      Use Certificat (option x509)
       comme
      Vérification de l’audit
      .
  9. (Facultatif) Sélectionnez un ou plusieurs ISU dans le champ
    Utilisateur du système d’intégration
     .
    Ce champ s’affiche lorsque le champ
    Certificat x509
     est actif. Si vous ne sélectionnez aucun ISU dans ce champ, le client API ne limitera pas l’accès en fonction des comptes d’utilisateurs ISU. Si vous sélectionnez un ou plusieurs ISU, les tentatives d’ouverture de session par d’autres utilisateurs échoueront. Workday vous recommande de limiter l’accès du client à des ISU particuliers.
  10. Sélectionnez le
    type de jeton d'accès
    .
    Option Description
    Porteur
    Permet un développement plus simple.
    MAC (ne pas utiliser)
    Offre une sécurité accrue.
    Workday prévoit retirer ce type de jeton d’accès dans une version ultérieure. Nous vous recommandons d’utiliser plutôt des jetons de portant.
  11. Entrez l'
    adresse URI de redirection
    .
    • Utilisez une virgule comme délimiteur pour spécifier plusieurs URI de redirection.
    • Pour les types d’octroi de client
      Authorization Code Grant
       , seuls les adresses URI sécurisées commençant par https sont valides.
    • Pour
      les subventions implicites
       et
      les subventions par code d’autorisation
       avec
      clé de preuve pour l’échange de codes (PKCE)
       , seuls les URI sécurisés commençant par https et les URI de domaine personnalisé sont valides. Exemple : OfficeConnect://test.com et https://pages.com.
  12. (Facultatif) Sélectionnez le
    délai d’actualisation du jeton (en jours)
    . Vous pouvez sélectionner une valeur comprise entre 1 et 365 jours. La valeur par défaut est de 30 jours. Le taux d’actualisation des jetons est limité à un jeton par seconde, par utilisateur.
  13. (Facultatif) Cochez la case
    Jetons d’actualisation n’expirant pas
     pour empêcher l’expiration du délai d’actualisation du jeton.
  14. (Facultatif) Cochez la case
    Désactivé
     pour empêcher le client de demander l’accès à Workday.
  15. Cochez la case Autoriser
    le consentement administratif
     lorsque vous souhaitez accorder le consentement OAuth à un client API REST à l’échelle du locataire. Lorsque cette option est sélectionnée, les utilisateurs n’ont pas besoin d’accorder explicitement au client l’accès aux domaines fonctionnels Workday.
  16. À partir de l’invite
    Scope (Functional Areas)
     , sélectionnez les domaines fonctionnels auxquels votre client OAuth 2.0 doit accéder.
    Sélectionnez les domaines fonctionnels que Workday active pour l’API REST Workday. Sélectionnez également les domaines fonctionnels pour les domaines de tout objet personnalisé auquel vous pourriez devoir accéder. Faites preuve de vigilance pour présenter uniquement les domaines fonctionnels auxquels vous devez accéder.
  17. (Facultatif) Lorsque votre client OAuth 2.0 doit accéder à des domaines Workday principaux qui ne sont dans aucun domaine fonctionnel, cochez la case Inclure
    un champ d’application prédéfini par Workday
     .
  18. (Facultatif) Si vous souhaitez que Workday autorise l’accès au client OAuth 2.0 uniquement à partir des plages d’adresses IP précisées, sélectionnez les plages dans l’invite
    Limité aux plages d’adresses IP
     .
    Vous pouvez également sélectionner
    Create IP Range
     pour créer une liste d’adresses IP nommée, séparées par des virgules, en utilisant l’un des formats suivants :
    • X.X.X.X.
    • Notation CID. Exemple : 192.168.0.1/24.
    • X.X.X.X - Y.Y.Y.Y.
    Workday a une limite sur les plages d’adresses IP qui incluent un tiret. Si vous constatez des erreurs d’ouverture de session dans le rapport
    Ouvertures de session et tentatives d’ouverture de session
     après avoir commencé à utiliser une plage d’adresses IP que vous avez entrée dans ce format :
    1. Pour voir si la plage se décompose en une série de segments plus petits, utilisez un outil qui convertit les plages d’adresses IP en notation CID. De tels outils de calcul CID de tierce partie sont disponibles en ligne.
    2. Entrez de nouveau la
      Plage d’adresses IP
       dans Workday sous forme de liste de segments séparés par des virgules renvoyées par l’outil. Exemple : 199.67.128.0/18, 199.67.192.0/24 ou 199.67.128.0-199.67.191.255, 199.67.192.0-199.67.192.255.
  19. Ajoutez une rangée à la grille
    Origine autorisée
     pour chaque domaine activé pour les demandes multiorigines. Les domaines doivent commencer par
    https://
     ou
    chrome-extension://
     et utilisent le format CORS.
    Workday peut ajouter des en-têtes CORS lorsqu’il répond à des demandes multiorigines à partir des domaines
    Allowed Origin
     . Workday ne prend en charge que les demandes multi-origine pour les clients utilisant le type d’octroi Code d’autorisation avec la prise en charge de PKCE.
Workday génère un identifiant de client et une clé secrète client pour le client OAuth 2.0. Copiez la clé secrète client avant de quitter la page et stockez-la en toute sécurité. Si vous perdez la clé secrète client, vous pouvez en générer une nouvelle à l’aide de la tâche
Générer une nouvelle clé secrète client API
 .
Workday peut livrer des clients OAuth 2.0 dans le cadre d’une mise à jour. Tous les clients OAuth 2.0 fournis par Workday sont désactivés par défaut.
Si vous souhaitez générer une nouvelle clé secrète client pour un client OAuth 2.0 :
  1. Accédez à la tâche
    Générer une nouvelle clé secrète client API
     .
  2. Sélectionnez le
    client API
     dans l’invite.
  3. Cochez la case
    Confirmer
     .
Lorsque le client OAuth 2.0 est déjà en cours d’utilisation, la génération d’une nouvelle clé secrète client le rendra inutilisable.