Claims

Claims behandles først i autentiseringsmetoden og deretter i applikasjonsregistreringen, hvor det er mulig å bestemme hvilke claims som sendes videre til neste steg og å gjøre claim transforms og claim tasks.

Alle claim sammenligninger er case sensitive.

Claim prosessen starter i autentiseringsmetoden når en bruker autentiserer. Der er det mulig å gjøre claim transforms og claim tasks og konfigurere hvilke claims som skal sendes videre til neste steg. Deretter fortsetter claim prosessen i applikasjonsregistreringen hvor det også er mulig å gjøre claim transforms og konfigurere hvilke claims som skal utstedes til applikasjonen / APIet.

I et Client Credentials Grant scenario gjøres claim prosessen bare i applikasjonsregistreringen. Det samme gjelder claim transforms og konfigurasjonen av hvilke claims som skal utstedes til applikasjonen / APIet.

For verdier som brukes internt i FoxIDs, velger du _local: for ett transformasjonssett, _internal: for den aktuelle autentiseringsflyten inkludert applikasjonens transforms eller _session: for senere nettleserinnlogginger gjennom samme autentiseringsmetode. Disse reserverte claims utstedes ikke til applikasjoner. Se Lokale, interne og sesjonsclaims, inkludert hvordan en sesjonsverdi kopieres til et internt claim for applikasjonens transforms.

Authentication method

I både en OpenID Connect og SAML 2.0 autentiseringsmetode sendes claims videre ved å legge dem til i listen Forward claims. Alle claims sendes videre hvis en wildcard * legges til i listen Forward claims.

Følgende claims identifiserer den sist brukte autentiseringsmetoden. De videresendes som standard og kan leses i applikasjonsregistreringen og brukes i claim transforms og claim tasks:

  • auth_method inneholder autentiseringsmetodens navn, som er unikt i miljøet.
  • auth_method_type inneholder autentiseringsmetodens type: login, oidc, oauth2, saml2, wsfed, env_link eller ext_login.
  • auth_profile_method inneholder navnet på den valgte profilen for autentiseringsmetoden. Dette claimet tas med når en profil brukes.

Et sub claim og tokens mottatt fra en ekstern Identity Provider er nestet med en pipe (|) etter autentiseringsmetodenavnet. Eksempler:

  • Et eksternt sub med verdien afeda2a3-c08b-4bbb-ab77-35138dd2ef2d får den nestede verdien the-auth-method|afeda2a3-c08b-4bbb-ab77-35138dd2ef2d
  • Et eksternt access token med verdien eyJhG.cRwczov...nNjb3B.lIjoi legges til i access_token claim med den nestede verdien the-auth-method|eyJhG.cRwczov...nNjb3B.lIjoi
  • Hvis den eksterne OpenID Provider returnerer et refresh token, kan det videresendes i refresh_token claim med den nestede verdien the-auth-method|refresh-token-value

Application registration

I både en OpenID Connect, OAuth 2.0 og SAML 2.0 applikasjonsregistrering utstedes claims til applikasjonen / APIet ved å legge dem til i listen Issue claims. Alle claims utstedes til applikasjonen / APIet hvis en wildcard * legges til i listen Issue claims.

En OpenID Connect applikasjonsregistrering kan skille om et claim kun utstedes i access token eller også i ID token.

En OpenID Connect og OAuth 2.0 applikasjonsregistrering kan også sende claims videre via et scope. Dette gjøres ved å legge claim(s) til en scopes Voluntary claims liste. Claims utstedes da hvis klient applikasjonen ber om scopet. En OpenID Connect applikasjonsregistrering kan også i frivillige scope claims skille om et claim kun utstedes i access token eller også i ID token.

Typer for claimverdier

JWT claimverdier beholder typene sine, inkludert JSON-objekter, arrayer, boolske verdier og tall, når claims kopieres av en Map transform eller føres gjennom sesjoner, Extended UI og OAuth grants. OpenID Connect UserInfo returnerer verdiene med de tilsvarende JSON-typene.

Transforms som lager ny tekst, for eksempel regex mapping og sammenkobling, lager strengverdier.

JWT/SAML claim mapping bevarer verdityper som boolske verdier og tall. Ved mapping fra JWT til SAML overføres JSON-verdier som tekst i strengattributter. Ved mapping fra SAML til JWT blir strengverdier med gyldige JSON-objekter eller arrayer til JSON-claims.

Impersonerte identiteter

En autentiseringsmetode kan velge en annen bruker med en Impersonation transform. Applikasjonens transforms mottar da målbrukerens claims og et act claim som identifiserer den opprinnelig autentiserte brukeren. _impersonate: claims forbereder valget i autentiseringsmetodens transforms; lokale hjelpeclaims beholder sine reserverte navn under dette prefikset.

I JWT-er er act et JSON-objekt, for eksempel {"sub":"original-user"}. Standardmappingen i SAML er http://schemas.foxids.com/ws/identity/claims/act, som kan overstyres i miljøets claim mappings. Velg det mappede claimet i SAML-applikasjonens Issue claims, eller bruk *, for å utstede JSON-teksten. Når et SAML-attributt med denne JSON-teksten mappes tilbake til act, utsteder FoxIDs det som et JSON-objekt i JWT-et.

Beskyttede claims

FoxIDs administrerer claims som styrer økter, tokens gyldighet og ruting mellom autentiseringsmetoder. Disse beskyttede claims kan ikke konfigureres som utdata fra claim transforms, brukes i egendefinerte JWT/SAML claim mappings eller gis statiske verdier.

Følgende JWT claims er beskyttet:

  • sid, iss, aud, exp, nbf, iat og auth_time.
  • client_id, azp, scope, nonce, at_hash og c_hash.
  • auth_method, auth_method_type, auth_profile_method og auth_method_issuer.

De tilsvarende SAML claimtypene for øktindeks, autentiseringstidspunkt, klient-ID og autentiseringsmetode er også beskyttet. FoxIDs' innebygde protokolltilordninger er fortsatt tilgjengelige.

Transforms kan lese beskyttede claims og kopiere verdiene deres til egendefinerte claims. En beskyttet claim kan også velges i en liste over claims som skal videresendes eller utstedes, uten å angi statiske verdier.

De samme begrensningene gjelder for egendefinerte claims på interne og eksterne brukere, innledende claims for tenantens bruker, claims på noder i tilgangsstrukturen, utdataclaims fra dynamisk UI samt statiske claims for applikasjoner og scopes.

Beskyttede claims som returneres av et Claims API, et API for validering av Extended UI, et External Login API eller et Directory Connector API, fjernes. Eksisterende beskyttede claims i flyten beholdes. Utvalgte beskyttede claims kan sendes til disse API-ene som inndata.