Passa al contenuto principale
Documentazione
Documentazione
Adaptive Planning
Ultimo aggiornamento: 2024-03-08
Registrare i client API

Registrare i client API

Criteri di sicurezza: i seguenti domini nell'area funzionale System:
  • Set Up: Tenant Setup - Security
  • Amministrazione della sicurezza
Workday supporta OAuth 2.0 come parte dell'infrastruttura API Workday. OAuth 2.0 consente agli utenti di Workday di autorizzare i client di terze parti ad accedere ai dati di Workday in modo sicuro per loro conto.
Per accedere all'API di Workday, registrare i client OAuth 2.0 con Workday. È possibile consentire ai client OAuth 2.0 di accedere all'API Workday per ogni tenant.
  1. Accedere all'attività
    Modifica configurazione tenant - Sicurezza
     .
  2. Nella sezione
    Impostazioni OAuth 2.0
     , selezionare la casella di controllo
    OAuth 2.0 Clients Enabled
     .
  3. Accedere all'attività
    Registrazione client API
     .
  4. Immettere il
    Nome client
    .
  5. Selezionare il
    Tipo di sovvenzione cliente
    .
    Opzione Descrizione
    Assegnazione codice di autorizzazione
    Utilizzare per i client che possono rendere persistenti i dati, ad esempio le applicazioni mobili.
    Concessione implicita (non utilizzare)
    Necessario per le applicazioni che non includono un componente lato server, come le applicazioni JavaScript.
    Il sistema prevede di ritirare questo tipo di assegnazione client in una versione futura. Si consiglia invece di utilizzare i seguenti tipi di assegnazione client:
    • Concessione codice di autorizzazione con supporto PKCE.
    • JWT Bearer Grant.
    JWT Bearer Grant
    Utilizzare il token Web JSON (JWT) per i client come l'integrazione di Salesforce. Questo tipo di assegnazione consente di limitare lo scambio di asserzioni di sicurezza per l'accesso e i token di aggiornamento agli utenti del sistema di integrazione (ISU) selezionati nel campo
    Utente del sistema di integrazione
     . Fornire un
    certificato x509
     per la convalida delle firme. È anche possibile selezionare la casella di controllo
    Consenti messaggi di integrazione
     per assicurarsi che il sistema riceva le informazioni necessarie sullo stato dell'integrazione.
    Concessione al portatore SAML
    Utilizzare per le applicazioni che utilizzano SSO SAML per l'autenticazione.
    Selezionare anche una
    verifica asserzione
    . Selezionare:
    • Utilizzare IdP configurati
       per utilizzare il certificato pubblico X.509 dell'IdP SAML configurato in
      Modifica configurazione tenant - Sicurezza
       per la convalida delle firme. L'autorità emittente in questo caso è l'IdP.
    • Utilizzare Certificato (opzione x509)
       per specificare un
      Certificato x509
       per la convalida delle firme. L'autorità emittente in questo caso è l'ID client API. Facoltativamente, è anche possibile selezionare ISU nel campo
      Utente sistema di integrazione
       , per limitare lo scambio di asserzioni di sicurezza per l'accesso e i token di aggiornamento a tali ISU.
    È anche possibile:
    • Selezionare la casella di controllo
      Consenti accesso a tutti gli utenti del sistema
       per consentire a tutti gli utenti, anziché solo agli utenti del sistema di integrazione, di utilizzare il flusso di asserzioni di tipo bearer SAML.
    • Selezionare la casella di controllo
      Consenti messaggi di integrazione
       per assicurarsi che il sistema riceva le informazioni necessarie sullo stato dell'integrazione.
  6. (Facoltativo) Selezionare la casella di controllo
    Support Proof Key for Code Exchange (PKCE)
     quando si utilizza il tipo di concessione client
    Authorization Code Grant
     per aggiungere il supporto PKCE al client.
    PKCE consente al client di ridurre il rischio di intercettazione del codice di autorizzazione. Selezionare questa casella di controllo se il client supporterà le richieste multiorigine abilitate per Cross Origin Resource Sharing (CORS).
  7. (Facoltativo) Selezionare la casella di controllo
    Imponi scadenza token di accesso di 60 minuti
     per consentire al client API di restituire token di trasporto che:
    • Hanno una scadenza di 60 minuti.
    • Non invalidano al termine delle sessioni, a condizione che non siano scadute.
    Dopo aver selezionato questa casella di controllo e aver fatto clic su
    OK
    , non è possibile deselezionarla.
  8. Selezionare una chiave pubblica X.509 nel campo
    Certificato x509
     .
    Questo campo è attivo quando si selezionano:
    • Concessione al portatore Jwt
       come
      tipo di assegnazione cliente
      .
    • Concessione al portatore SAML
       come
      Tipo di assegnazione client
       e
      Usa certificato (opzione x509)
       come
      Verifica asserzione
      .
  9. (Facoltativo) Selezionare uno o più ISU nel campo
    Utente sistema di integrazione
     .
    Questo campo viene visualizzato quando il campo
    Certificato x509
     è attivo. Se non si selezionano ISU in questo campo, il client API non limiterà l'accesso in base agli account utente ISU. Se si selezionano uno o più ISU, i tentativi di accesso da parte di altri utenti avranno esito negativo. È consigliabile limitare l'accesso del client a utenti di terze parti specifici.
  10. Selezionare il
    Tipo di token di accesso
    .
    Opzione Descrizione
    Al portatore
    Consente uno sviluppo più semplice.
    MAC (non utilizzare)
    Fornisce una maggiore sicurezza.
    Il sistema prevede di ritirare questo tipo di token di accesso in una versione futura. È consigliabile utilizzare invece i token al portatore.
  11. Immettere l'
    URI di reindirizzamento
    .
    • Utilizzare una virgola come delimitatore per specificare più di un URI di reindirizzamento.
    • Per i tipi di assegnazione client
      con assegnazione codice di autorizzazione
       , sono validi solo gli URI di sicurezza che iniziano con https.
    • Per
      la Concessione implicita
       e
      la Concessione codice di autorizzazione
       con
      chiave di prova per scambio di codice
       abilitata, sono validi solo gli URI di sicurezza che iniziano con https e gli URI di dominio personalizzati. Esempio: officeconnect://test.com e https://google.com.
  12. (Facoltativo) Selezionare
    Timeout aggiornamento token (in giorni)
    . È possibile selezionare un valore compreso tra 1 e 365 giorni. Il valore predefinito è 30 giorni. La frequenza dei token di aggiornamento è limitata a 1 token al secondo, per utente.
  13. (Facoltativo) Selezionare la casella di controllo
    Token di aggiornamento senza scadenza
     per impedire il timeout del token di aggiornamento.
  14. (Facoltativo) Selezionare la casella di controllo
    Disabilitato
     per impedire al client di richiedere l'accesso a Workday.
  15. Selezionare la casella di controllo
    Grant Administrative Consent
     quando si desidera concedere il consenso OAuth a un client API REST a livello di tenant. Se questa opzione è selezionata, gli utenti non devono concedere esplicitamente l'accesso client alle aree funzionali di Workday.
  16. Dall'elenco di valori
    Ambito (aree funzionali)
     , selezionare le aree funzionali a cui il client OAuth 2.0 richiede l'accesso.
    Selezionare le aree funzionali abilitate dal sistema per l'API REST di Workday. Selezionare anche le aree funzionali per i domini di eventuali oggetti personalizzati a cui potrebbe essere necessario accedere. Prestare attenzione per esporre solo le aree funzionali a cui è specificamente richiesto l'accesso.
  17. (Facoltativo) Quando il client OAuth 2.0 richiede l'accesso a domini Workday principali che non si trovano in aree funzionali, selezionare la casella di controllo
    Includi ambito di proprietà di Workday
     .
  18. (Facoltativo) Se si desidera che il sistema autorizzi l'accesso del client OAuth 2.0 solo da intervalli di indirizzi IP specificati, selezionare gli intervalli dall'elenco
    di valori Limitato a intervalli IP
     .
    È anche possibile selezionare
    Crea intervallo IP
     per creare un elenco di indirizzi IP con nome e separati da virgole utilizzando uno dei seguenti formati:
    • X.X.X.X.
    • Notazione CIDR Esempio: 192.168.0.1/24.
    • X.X.X.X - Y.Y.Y.Y.
    Il sistema prevede una limitazione per gli intervalli IP che includono un trattino. Se si verificano errori di accesso nel report
    Accesso e tentativi di accesso
     dopo aver iniziato a utilizzare un intervallo IP immesso in quel formato:
    1. Per vedere se l'intervallo si scompone in una serie di segmenti più piccoli, utilizzare uno strumento che converta gli intervalli di indirizzi IP in notazione CIDR. Tali strumenti di calcolo CIDR di terzi sono disponibili online.
    2. Immettere nuovamente l'
      Intervallo IP
       in Workday come elenco separato da virgole dei segmenti restituiti dallo strumento. Esempio: 199.67.128.0/18, 199.67.192.0/24 o 199.67.128.0-199.67.191.255, 199.67.192.0-199.67.192.255.
  19. Aggiungere una riga alla griglia
    Origine consentita
     per ogni dominio abilitato per le richieste tra origini diverse. I domini devono iniziare con
    https://
     o
    chrome-extension://
     e utilizzare il formato CORS.
    Il sistema potrebbe aggiungere intestazioni CORS quando si risponde a richieste con origini diverse da domini
    di origine consentiti
     . Il sistema supporta solo le richieste multiorigine per i client che utilizzano il tipo di concessione Codice di autorizzazione con supporto PKCE.
Il sistema genera un ID client e un Segreto client per il client OAuth 2.0. Copiare il Client Secret prima di uscire dalla pagina e archiviarlo in modo sicuro. Se si perde il segreto client, è possibile generarne uno nuovo utilizzando l'attività
Generazione segreto client nuovo API
 .
Il sistema può fornire client OAuth 2.0 come parte di un aggiornamento. Tutti i client OAuth 2.0 forniti da Workday sono disabilitati per impostazione predefinita.
Se si desidera generare un nuovo Client Secret per un client OAuth 2.0:
  1. Accedere all'attività
    Generazione nuovo segreto client API
     .
  2. Selezionare il
    client API
     dall'elenco di valori.
  3. Selezionare la casella di controllo
    Conferma
     .
Quando il client OAuth 2.0 è già in uso, la generazione di un nuovo Client Secret renderà il client inutilizzabile.