FoxIDs fra innsiden
FoxIDs er organisert som en identitetsplattform med flere leietakere. Administrativ konfigurasjon, operasjonelle identiteter og protokollendepunkter er delt inn i eksplisitte omfang, slik at én distribusjon kan være vert for mange organisasjoner og mange uavhengige identitetsleverandører.
Plattformshierarki
Hierarkiet skiller plattformadministrasjon fra leietakeradministrasjon og operativ identitetskonfigurasjon.
| Omfang | Formål | Inneholder |
|---|---|---|
| Plattformens hovedleietaker | Administrerer FoxIDs-distribusjonen | Plattformens hovedmiljø, FoxIDs administratorbrukere og plattformomfattende konfigurasjon |
| Leietaker | Isolerer en organisasjon eller kunde | Et leietaker-hovedmiljø og et vilkårlig antall vanlige miljøer |
| Leietaker-hovedmiljø | Administrerer én leietaker | Leietakerspesifikk hovedkonfigurasjon og leietakeradministratorer |
| Miljø | Fungerer som et uavhengig Identity Provider | Endepunkter, et brukerregister, sertifikater, autentiseringsmetoder, applikasjonsregistreringer og miljøinnstillinger |
Operatører av delte skyimplementeringer kan også definere planer i plattformens hovedleietaker for å knytte priser og inkludert bruk til leietakere for behandling i et eksternt faktureringssystem.
Vanlige miljøer er beregnet på operative brukere og integrasjoner. Hovedmiljøene forblir administrative grenser og bør ikke brukes som erstatning for utviklings-, test- eller produksjonsmiljøer.
Miljøisolasjon
Hvert miljø har et unikt teknisk navn som inngår i dets endepunkter. Konfigurasjons- og identitetsdata under kjøring er begrenset til dette miljøet.
Dette betyr at:
- En bruker i ett miljø finnes ikke automatisk i et annet.
- Sertifikater, passordretningslinjer, tilordninger av påstander, brukerrette tekster og tilgangsstrukturer er miljøspesifikke.
- Autentiseringsmetoder definerer oppstrøms identitetsleverandører og lokale påloggingsalternativer for miljøet.
- Applikasjonsregistreringer definerer applikasjonene og API-ene som stoler på miljøet.
- Tillit mellom miljøer eksisterer kun når en miljøkobling eller OpenID Connect-tilkobling er eksplisitt konfigurert.
FoxIDs støtter et ubegrenset antall leietakere, et ubegrenset antall miljøer per leietaker og et ubegrenset antall brukere per miljø. Den praktiske kapasiteten avhenger av distribusjonsressursene og datalageret.
Konfigurasjonsområder
Fortsett med området som passer til det du vil konfigurere:
- Miljøer og sertifikater: Miljøer, Sertifikater
- Brukere og kataloger: Brukere, Interne brukere, Eksterne brukere, Directory Connector, Directory Connector for AD, Last opp mange brukere
- Tilgang og claims: Tilgangsstruktur, Claims, Claim-transformasjoner og oppgaver
- Brukeropplevelse og meldinger: Utvidet UI, E-postleverandør, SMS-leverandør
- Drift og administrasjon: Logging, FoxIDs Control-klient og API
Forespørselsbane via FoxIDs
FoxIDs identifiserer leietaker og miljø fra forespørsels-URL-en før en autentiserings- eller tokenforespørsel behandles. Innenfor det valgte miljøet:
- Applikasjonsregistreringen validerer den innkommende applikasjons- eller API-forespørselen.
- FoxIDs velger en tillatt autentiseringsmetode, enten direkte eller gjennom home realm discovery.
- Autentiseringsmetoden logger brukeren inn lokalt eller delegerer autentiseringen til en oppstrøms identitetsleverandør.
- Krav normaliseres, tilordnes og transformeres inne i FoxIDs.
- Applikasjonen mottar svaret i det konfigurerte protokollet sitt, noe som gjør at FoxIDs kan brolegge mellom protokoller når de to sidene er forskjellige.
Applikasjonen og autentiseringsmetoden kan derfor fortsatt konfigureres uavhengig av hverandre, mens FoxIDs håndterer rutingen, påstandene og protokollkonverteringen mellom dem.
Tekniske begrensninger
FoxIDs setter maksimumsgrenser for lengden på eksternt tilførte protokollverdier for å beskytte minne, lagringsplass og forespørselsbehandling. Avhengig av verdien og protokollen blir data som overskrider grensen avvist eller avkortet.
URL-er
- En URL kan inneholde maksimalt 10 240 tegn.
- En spørringsstreng kan inneholde maksimalt 10 240 tegn.
Claims
- En JWT-kravtype kan inneholde maksimalt 80 tegn.
- En SAML 2.0-kravtype kan inneholde maksimalt 300 tegn.
- Maksimal behandlet lengde for en enkelt kravverdi og for kombinerte kravverdier er 200 000 tegn. Kravverdier som overskrider denne grensen i mottatte tokens blir avkortet.
Hvis en JWT oppgis som en påstandsverdi, er den underlagt den samme grensen for påstandsverdier.
Tokens og SAML-meldinger
- En JWT mottatt av FoxIDs, inkludert et tilgangstoken, ID-token eller oppdateringstoken, kan inneholde maksimalt 256 000 tegn.
- FoxIDs kan utstede en større JWT, fordi individuelle krav er begrenset i stedet for at det fullstendige genererte tokenet blir avkortet.
- En SAML 2.0-forespørsel eller -svar kan inneholde maksimalt 256 000 tegn.
- En SAML-melding som bruker HTTP Redirect-binding, er også underlagt begrensningene for URL og spørringsstreng.