1.4.5.9.1.4. Pagina della scheda "Login

Nella pagina "Login [Login] " del registro sono presenti quattro sottopagine:

Pagina "Login"

Figura 1.266. Pagina "Login"

1.4.5.9.1.4.1.  Metodi di accesso al sito web

Pagina della scheda "Login

Figura 1.267. Pagina della scheda "Login

Metodi di login web consentiti [Allowed web login methods]:

  1. Creare nuove righe facendo clic sul pulsante più.

  2. Inserire il nome di un computer o di un dominio nella colonna Nome host [Host name].

  3. Fare clic su un campo della colonna Metodi [Methods], aprire il campo elenco con le opzioni base, ntlm e openid e attivare quella desiderata.

Esempio:

Solo Windows (ntlm) Autenticazione

Figura 1.268. Solo Windows (ntlm) Autenticazione

Nome utente/password (basico) e autenticazione Windows (ntlm)

Figura 1.269. Nome utente/password (basico) e autenticazione Windows (ntlm)

1.4.5.9.1.4.2.  Metodi di accesso per i clienti

Pagina della scheda "Login

Figura 1.270. Pagina della scheda "Login

Metodi di accesso client consentiti [Allowed client login methods]:

  1. Creare nuove righe facendo clic sul pulsante più.

  2. Inserire nella colonna "Regola" [Rule] (campo di inserimento libero) un dominio (ad es. "CNS") o un nome host (ad es. DE-AGB-NAME-01).

  3. Fare clic nella colonna "Database [Databases] " su un campo, aprire l'elenco a discesa con le opzioni WINDOWS, ERP, OPENIDC, SQL, FILE e LDAP e selezionare quelle desiderate.

    La configurazione delle opzioni qui elencate avviene nella categoria Gestione dei diritti [Rights administration].

    Figura 1.271. 

1.4.5.9.1.4.3.  Provider OpenID

Autenticazione OpenID avanzata

Le estensioni sono ora disponibili tramite un'interfaccia utente grafica . In questo modo non è più necessario modificare manualmente i file di configurazione.

Figura 1.272. 

Consenti l'autenticazione di base senza richiesta al server (Non sicuro) [Enable Basic Authentication without a server request (Insecure)]: se l'opzione è attivata, il nome utente e la password vengono trasmessi in chiaro.

Provider di accesso [Login Provider]: per le soluzioni AppServer esiste un solo provider OpenID, che va configurato qui. Si tratta del provider OpenID visualizzato durante la procedura di accesso a 3Dfindit.

Oltre al provider di accesso [Login Provider] standard , cliccando sul pulsante + è possibile configurare un numero illimitato di provider OpenID [OpenID Provider] aggiuntivi. In questo modo è possibile supportare in parallelo diverse fonti di identità, il che è particolarmente importante per le integrazioni e gli scenari di automazione.

La configurazione comprende le seguenti impostazioni:

  • Emittente

  • ClientId

  • CientSecret

  • Ambiti

  • UserNameClaim

  • Gruppi obbligatori

  • RolesAsPermission: impostazione da applicare quando nel token API sono inclusi dei ruoli

  • Utente basato su sessione

  • MergeUserInfo

In questo modo è possibile configurare ulteriori provider indipendentemente dalle impostazioni presenti in Gestione dei diritti [Rights administration] > Banche dati utenti [User databases] > OpenID .

Figura 1.273. 

1.4.5.9.1.4.4.  Token API

Servizio AppServer [AppServer Service] > Pagina di registrazione "Login" > Pagina di registrazione "Token API [API tokens]"

Figura 1.274.  Servizio AppServer [AppServer Service] > Pagina di registrazione "Login" > Pagina di registrazione "Token API [API tokens]"

Token API Autenticazione per un accesso semplice e sicuro alle API web

Panoramica

Per supportare gli accessi automatizzati all’API del server è stata introdotta una procedura basata su token API. L’obiettivo è consentire a script e integrazioni un’autenticazione sicura senza dover utilizzare direttamente le password degli utenti . Inoltre, l’ infrastruttura di autenticazione è stata ampliata in modo da consentire la configurazione parallela di più provider OpenID. Il vantaggio di un token API separato risiede anche nel fatto che la chiave API può essere facilmente cancellata senza compromettere l’utente in questione.

Token API per accessi automatizzati

I token API rappresentano il metodo di autenticazione consigliato per gli accessi alle API REST gestiti da script. Sono associati a un account utente esistente e ne ereditano le autorizzazioni. Ciò consente alle applicazioni automatizzate di accedere all’API per conto di un utente senza dover conoscere o memorizzare la sua password.

A differenza dell'autenticazione di base, in cui vengono trasmessi nome utente e password, i token API possono essere gestiti indipendentemente dalla password dell'utente. Se un token viene compromesso, è possibile revocarlo e generarne uno nuovo senza che siano necessarie modifiche all' account utente.

Piano di sicurezza

Un token API è costituito da un ID token pubblico e da un segreto [Secret].

AppServer Servizio > Pagina di registrazione "Login"

Figura 1.275. AppServer Servizio > Pagina di registrazione "Login"

Generare utilizzando il pulsante "Casuale [Random] " un ID e un codice segreto.

È necessario inserire un utente. Tutti gli utenti registrati nella sezione “Gestione dei diritti” [Rights administration] possono essere inseriti qui.

Inoltre, i token API possono essere soggetti a limitazioni facoltative, ad esempio a:

  • determinati intervalli di indirizzi IP

  • definiti User-Agent

Queste restrizioni riducono il rischio di abuso e consentono un utilizzo controllato degli accessi automatizzati.

Copiare utilizzando il pulsante " Copia [Copy]" l'ID, il segreto e le altre impostazioni negli appunti.

Il codice segreto [Secret] viene visualizzato esclusivamente al momento della creazione e in seguito non può più essere letto. In questo modo si impedisce che i dati di accesso vengano divulgati in un secondo momento.

[Nota]Nota

Salvare la stringa ApiToken prima di chiudere la finestra di dialogo.

Dopo aver confermato con OK, la voce viene inserita.

"Secret" non viene più visualizzato.

Figura 1.276. "Secret" non viene più visualizzato.

Autenticazione OpenID avanzata

Le estensioni sono ora disponibili tramite un'interfaccia utente grafica. In questo modo non è più necessario modificare manualmente i file di configurazione.

Figura 1.277. 

Consenti l'autenticazione di base senza richiesta al server (Non sicuro) [Enable Basic Authentication without a server request (Insecure)]: se l'opzione è attivata, il nome utente e la password vengono trasmessi in chiaro.

Provider di accesso [Login Provider]: per le soluzioni AppServer esiste un solo provider OpenID, che va configurato qui. Si tratta del provider OpenID visualizzato durante la procedura di accesso a 3Dfindit.

Oltre al provider di accesso [Login Provider] standard , cliccando sul pulsante + è possibile configurare un numero illimitato di provider OpenID [OpenID Provider] aggiuntivi. In questo modo è possibile supportare parallelamente diverse fonti di identità, il che è particolarmente importante per le integrazioni e gli scenari di automazione.

La configurazione comprende le seguenti impostazioni:

  • Emittente

  • ClientId

  • CientSecret

  • Ambiti

  • UserNameClaim

  • Gruppi obbligatori

  • RolesAsPermission: impostazione da applicare quando nel token API sono inclusi dei ruoli

  • Utente basato su sessione

  • MergeUserInfo

In questo modo è possibile configurare ulteriori provider indipendentemente dalle impostazioni presenti in Gestione dei diritti [Rights administration] > Banche dati utenti [User databases] > OpenID .

Figura 1.278. 

1.4.5.9.1.4.5. Requisiti per l'autenticazione in Windows
  1. Il servizio viene eseguito come sistema locale e non richiede l'accesso alle condivisioni di rete (richiede l'accesso alle condivisioni di rete tramite percorso UNC).

    La configurazione standard di Microsoft per l'autenticazione di Windows (Kerberos) funziona. Solo il nome del computer deve essere aggiunto alla Local Intranet Zone nelle impostazioni del browser dei client.

  2. Il servizio richiede l'accesso a condivisioni di rete esterne. Deve quindi essere eseguito come utente del servizio e la voce SPN (Service Principal Name) deve essere impostata correttamente nell'AD. Il nome del computer deve essere incluso nella zona Intranet locale nelle impostazioni del browser dei client.

    Esempi:

    setspn -S HTTP/servername.domain.name DOMAIN\serviceuser