FoxIDs indefra
FoxIDs er opbygget som en identitetsplatform med flere brugere. Administrativ konfiguration, operationelle identiteter og protokolendepunkter er opdelt i eksplicitte omfang, hvilket gør det muligt for én installation at huse mange organisationer og mange uafhængige identitetsudbydere.
Platformshierarki
Hierarkiet adskiller platformadministration fra lejeradministration og operationel identitetskonfiguration.
| Omfang | Formål | Indeholder |
|---|---|---|
| Platformsmaster-tenant | Administrerer implementeringen af FoxIDs | Platformsmaster-miljøet, FoxIDs-administratorbrugere og platformsovergribende konfiguration |
| Lejer | Isolerer en organisation eller kunde | Et lejer-mastermiljø og et vilkårligt antal almindelige miljøer |
| Lejer-mastermiljø | Administrerer én lejer | Lejerspecifik masterkonfiguration og lejers administratorbrugere |
| Miljø | Fungerer som et uafhængigt Identity Provider | Endepunkter, et brugerregister, certifikater, autentificeringsmetoder, applikationsregistreringer og miljøindstillinger |
Operatører af delte cloud-implementeringer kan også definere planer i platformens master-tenant for at knytte priser og inkluderet forbrug til tenanterne med henblik på behandling i et eksternt faktureringssystem.
Standardmiljøer er beregnet til driftsbrugere og integrationer. Mastermiljøerne forbliver administrative grænser og bør ikke anvendes som erstatning for udviklings-, test- eller produktionsmiljøer.
Miljøisolering
Hvert miljø har et unikt teknisk navn, der indgår i dets slutpunkter. Konfigurations- og identitetsdata under kørsel er begrænset til det pågældende miljø.
Dette betyder, at:
- En bruger i ét miljø findes ikke automatisk i et andet.
- Certifikater, adgangskodepolitikker, claim-tilknytninger, brugertekst og adgangsstrukturer er miljøspecifikke.
- Autentificeringsmetoder definerer overordnede identitetsudbydere og lokale log-in-muligheder for miljøet.
- Applikationsregistreringer definerer de applikationer og API'er, der stoler på miljøet.
- Tillid mellem miljøer eksisterer kun, når en miljøforbindelse eller OpenID Connect-forbindelse er konfigureret eksplicit.
FoxIDs understøtter et ubegrænset antal lejere, et ubegrænset antal miljøer pr. lejer og et ubegrænset antal brugere pr. miljø. Den faktiske kapacitet afhænger af implementeringsressourcerne og datalageret.
Konfigurationsområder
Fortsæt med det område, der svarer til det, du vil konfigurere:
- Miljøer og certifikater: Miljøer, Certifikater
- Brugere og kataloger: Brugere, Interne brugere, Eksterne brugere, Directory Connector, Directory Connector til AD, Upload mange brugere
- Adgang og claims: Adgangsstruktur, Claims, Claim-transformationer og opgaver
- Brugeroplevelse og beskeder: Udvidet UI, E-mail-udbyder, SMS-udbyder
- Drift og administration: Logning, FoxIDs Control-klient og API
Anmodningssti via FoxIDs
FoxIDs bestemmer lejer og miljø ud fra anmodningens URL, inden en godkendelses- eller tokenanmodning behandles. Inden for det valgte miljø:
- Applikationsregistreringen validerer den indkommende applikations- eller API-anmodning.
- FoxIDs vælger en tilladt autentificeringsmetode, enten direkte eller via home realm discovery.
- Autentificeringsmetoden logger brugeren ind lokalt eller delegerer autentificeringen til en opstrøms identitetsudbyder.
- Krav normaliseres, kortlægges og transformeres i FoxIDs.
- Applikationen modtager svaret i det konfigurerede protokol, hvilket gør det muligt for FoxIDs at brokoble protokoller, når de to sider er forskellige.
Applikationen og autentificeringsmetoden kan derfor fortsat konfigureres uafhængigt af hinanden, mens FoxIDs håndterer routing, påstande og protokolkonvertering mellem dem.
Tekniske begrænsninger
FoxIDs anvender maksimumslængder på eksternt leverede protokolværdier for at beskytte hukommelse, lagerplads og forespørgselsbehandling. Afhængigt af værdien og protokollen afvises eller afkortes data, der overskrider længdegrænsen.
URL'er
- En URL må højst indeholde 10.240 tegn.
- En forespørgselsstreng må højst indeholde 10.240 tegn.
Claims
- En JWT-kravtype kan højst indeholde 80 tegn.
- En SAML 2.0-kravtype kan højst indeholde 300 tegn.
- Den maksimale behandlede længde for en enkelt kravværdi og for kombinerede kravværdier er 200.000 tegn. Kravværdier, der overskrider denne grænse i modtagne tokens, afkortes.
Hvis en JWT medføres som en claim-værdi, er den underlagt den samme grænse for claim-værdier.
Tokens og SAML-meddelelser
- En JWT, der modtages af FoxIDs, og som indeholder et adgangstoken, ID-token eller opdateringstoken, må højst indeholde 256.000 tegn.
- FoxIDs kan udstede en større JWT, da de enkelte krav er begrænset, i stedet for at det fuldt genererede token afkortes.
- En SAML 2.0-anmodning eller -svar må højst indeholde 256.000 tegn.
- En SAML-meddelelse, der bruger HTTP Redirect-binding, er også underlagt begrænsningerne for URL og forespørgselsstreng.