FoxIDs all'interno

FoxIDs è strutturata come una piattaforma di identità multi-tenant. La configurazione amministrativa, le identità operative e gli endpoint di protocollo sono suddivisi in ambiti ben definiti, consentendo a un'unica implementazione di ospitare numerose organizzazioni e molti provider di identità indipendenti.

Struttura della piattaforma FoxIDs, dei tenant e degli ambienti

Gerarchia della piattaforma

La gerarchia separa l'amministrazione della piattaforma dall'amministrazione dei tenant e dalla configurazione operativa delle identità.

Ambito Finalità Contiene
Tenant master della piattaforma Amministra l'implementazione di FoxIDs L'ambiente master della piattaforma, gli utenti amministratori di FoxIDs e la configurazione a livello di piattaforma
Tenant Isola un’organizzazione o un cliente Un ambiente master del tenant e un numero illimitato di ambienti regolari
Ambiente master del tenant Amministra un singolo tenant Configurazione master specifica del tenant e utenti amministratori del tenant
Ambiente Funziona come un’Identity Providere indipendente Endpoint, un repository utenti, certificati, metodi di autenticazione, registrazioni delle applicazioni e impostazioni dell’ambiente

Gli operatori di implementazioni cloud condivise possono inoltre definire piani nel tenant principale della piattaforma per associare i prezzi e l'utilizzo incluso ai tenant, in modo che vengano elaborati in un sistema di fatturazione esterno.

Gli ambienti regolari sono destinati agli utenti operativi e alle integrazioni. Gli ambienti master rimangono ambiti amministrativi e non devono essere utilizzati in sostituzione degli ambienti di sviluppo, di test o di produzione.

Isolamento dell'ambiente

Ogni ambiente ha un nome tecnico univoco che fa parte dei suoi endpoint. I dati di identità relativi alla configurazione e all'esecuzione sono limitati a quell'ambiente.

Ciò significa che:

  • Un utente presente in un ambiente non esiste automaticamente in un altro.
  • Certificati, criteri relativi alle password, mappature delle attestazioni, testi destinati agli utenti e strutture di accesso sono specifici per ciascun ambiente.
  • I metodi di autenticazione definiscono i provider di identità a monte e le opzioni di accesso locali per l’ambiente.
  • Le registrazioni delle applicazioni definiscono le applicazioni e le API che si fidano dell’ambiente.
  • La fiducia tra ambienti esiste solo quando viene configurato esplicitamente un Environment Link o una connessione OpenID Connect.

FoxIDs supporta un numero illimitato di tenant, un numero illimitato di ambienti per tenant e un numero illimitato di utenti per ambiente. La capacità effettiva dipende dalle risorse di implementazione e dall'archivio dati.

Aree di configurazione

Prosegui con l'area corrispondente a ciò che desideri configurare:

Percorso di richiesta tramite FoxIDs

FoxIDs determina il tenant e l'ambiente dall'URL della richiesta prima di elaborare una richiesta di autenticazione o di token. All'interno dell'ambiente selezionato:

  1. La registrazione dell'applicazione convalida la richiesta in entrata proveniente dall'applicazione o dall'API.
  2. FoxIDs seleziona un metodo di autenticazione consentito, direttamente o tramite home realm discovery.
  3. Il metodo di autenticazione effettua l'accesso dell'utente a livello locale oppure delega l'autenticazione a un provider di identità a monte.
  4. I claim vengono normalizzati, mappati e trasformati all’interno di FoxIDs.
  5. L’applicazione riceve la risposta nel protocollo configurato, consentendo a FoxIDs di effettuare il bridging tra i protocolli quando i due protocolli sono diversi.

L'applicazione e il metodo di autenticazione rimangono quindi configurabili in modo indipendente, mentre FoxIDs gestisce l'instradamento, le attestazioni e la traduzione dei protocolli tra di essi.

Limiti tecnici

FoxIDs applica limiti di lunghezza massima ai valori di protocollo forniti esternamente per proteggere la memoria, lo spazio di archiviazione e l'elaborazione delle richieste. A seconda del valore e del protocollo, i dati di dimensioni eccessive vengono rifiutati o troncati.

URL

  • Un URL può contenere al massimo 10.240 caratteri.
  • Una stringa di query può contenere al massimo 10.240 caratteri.

Claim

  • Un tipo di claim JWT può contenere al massimo 80 caratteri.
  • Un tipo di claim SAML 2.0 può contenere al massimo 300 caratteri.
  • La lunghezza massima elaborabile per un singolo valore di claim e per i valori di claim combinati è di 200.000 caratteri. I valori di claim di dimensioni eccessive presenti nei token ricevuti vengono troncati.

Se un JWT è presente come valore di claim, è soggetto allo stesso limite di valore di claim.

Token e messaggi SAML

  • Un messaggio JWT ricevuto da FoxIDs, che includa un token di accesso, un token ID o un token di aggiornamento, può contenere al massimo 256.000 caratteri.
  • FoxIDs può emettere un messaggio JWT più lungo, poiché vengono limitate le singole affermazioni (claim) anziché troncare l'intero token generato.
  • Una richiesta o una risposta SAML 2.0 può contenere al massimo 256.000 caratteri.
  • Anche un messaggio SAML che utilizza il binding HTTP Redirect è soggetto ai limiti relativi all’URL e alla stringa di query.
La tua privacy

La tua privacy

Usiamo i cookie per migliorare la tua esperienza sui nostri siti. Fai clic sul pulsante 'Accetta tutti i cookie' per acconsentire all'uso dei cookie. Per rifiutare i cookie non essenziali, fai clic su 'Solo cookie necessari'.

Visita la nostra pagina di Informativa sulla privacy per saperne di più