Claims

Claims behandles først i autentificeringsmetoden og derefter i applikationsregistreringen, hvor det er muligt at beslutte, hvilke claims der sendes videre til næste trin og at lave claim transforms og claim tasks.

Alle claim sammenligninger er case sensitive.

Claim processen starter i autentificeringsmetoden når en bruger autentificerer. Her er det muligt at lave claim transforms og claim tasks og konfigurere hvilke claims der skal sendes videre til næste trin. Derefter fortsætter claim processen i applikationsregistreringen hvor det også er muligt at lave claim transforms og konfigurere hvilke claims der skal udstedes til applikationen / API'et.

I et Client Credentials Grant scenarie udføres claim processen kun i applikationsregistreringen. Det samme gælder claim transforms og konfigurationen af hvilke claims der skal udstedes til applikationen / API'et.

Til værdier, som benyttes internt i FoxIDs, vælges _local: til ét transformationssæt, _internal: til det aktuelle autentificeringsflow inklusive applikationens transforms eller _session: til senere browserlogins gennem samme autentificeringsmetode. Disse reserverede claims udstedes ikke til applikationer. Se Lokale, interne og sessionsclaims, herunder hvordan en sessionsværdi kopieres til et internt claim, som applikationens transforms kan benytte.

Authentication method

I både en OpenID Connect og SAML 2.0 autentificeringsmetode sendes claims videre ved at tilføje dem til listen Forward claims. Alle claims sendes videre hvis en wildcard * tilføjes til listen Forward claims.

Følgende claims identificerer den senest anvendte autentificeringsmetode. De videresendes som standard og kan læses i applikationsregistreringen og bruges i claim transforms og claim tasks:

  • auth_method indeholder autentificeringsmetodens navn, som er unikt i miljøet.
  • auth_method_type indeholder autentificeringsmetodens type: login, oidc, oauth2, saml2, wsfed, env_link eller ext_login.
  • auth_profile_method indeholder navnet på den valgte profil for autentificeringsmetoden. Dette claim medtages, når en profil benyttes.

Et sub claim og tokens modtaget fra en ekstern Identity Provider er indlejret med en pipe (|) efter autentificeringsmetodenavnet. Eksempler:

  • Et eksternt sub med værdien afeda2a3-c08b-4bbb-ab77-35138dd2ef2d får den indlejrede værdi the-auth-method|afeda2a3-c08b-4bbb-ab77-35138dd2ef2d
  • Et eksternt access token med værdien eyJhG.cRwczov...nNjb3B.lIjoi tilføjes i access_token claim med den indlejrede værdi 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 indlejrede værdi the-auth-method|refresh-token-value

Application registration

I både en OpenID Connect, OAuth 2.0 og SAML 2.0 applikationsregistrering udstedes claims til applikationen / API'et ved at tilføje dem til listen Issue claims. Alle claims udstedes til applikationen / API'et hvis en wildcard * tilføjes til listen Issue claims.

En OpenID Connect applikationsregistrering kan differentiere om et claim kun udstedes i access token eller også i ID token.

En OpenID Connect og OAuth 2.0 applikationsregistrering kan også sende claims videre via et scope. Dette gøres ved at tilføje claim(s) til et scopes liste Voluntary claims. Claims udstedes derefter hvis klient applikationen anmoder om scopet. En OpenID Connect applikationsregistrering kan også i de frivillige scope claims differentiere om et claim kun udstedes i access token eller også i ID token.

Claimværdiers typer

JWT claimværdiers typer, inklusive JSON-objekter, arrays, booleske værdier og tal, bevares, når claims kopieres af en Map transform eller føres gennem sessioner, Extended UI og OAuth grants. OpenID Connect UserInfo returnerer værdierne med deres tilsvarende JSON-typer.

Transforms, der producerer ny tekst, såsom regex mapping og sammenkædning, producerer strengværdier.

JWT/SAML claim mapping bevarer værdityper såsom booleske værdier og tal. Ved mapping fra JWT til SAML overføres JSON-værdier som tekst i strengattributter. Ved mapping fra SAML til JWT bliver strengværdier med gyldige JSON-objekter eller arrays til JSON-claims.

Impersonerede identiteter

En autentificeringsmetode kan vælge en anden bruger med en Impersonation transform. Applikationens transforms modtager derefter målbrugerens claims og et act claim, der identificerer den oprindeligt autentificerede bruger. _impersonate: claims forbereder valget i autentificeringsmetodens transforms; lokale hjælpeclaims bevarer deres reserverede navne under dette præfiks.

I JWT'er er act et JSON-objekt, f.eks. {"sub":"original-user"}. Standardmappingen i SAML er http://schemas.foxids.com/ws/identity/claims/act, som kan ændres i miljøets claim mappings. Vælg det mappede claim i SAML-applikationens Issue claims, eller brug *, for at udstede JSON-teksten. Når en SAML-attribut med denne JSON-tekst mappes tilbage til act, udsteder FoxIDs den som et JSON-objekt i JWT'et.

Beskyttede claims

FoxIDs administrerer claims, der styrer sessioner, tokens gyldighed og routing mellem autentificeringsmetoder. Disse beskyttede claims kan ikke konfigureres som output fra claim transforms, bruges i brugerdefinerede JWT/SAML claim mappings eller tildeles statiske værdier.

Navnene på de beskyttede JWT claims er:

  • 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 claimtyper for sessionsindeks, autentificeringstidspunkt, klient-ID og autentificeringsmetode er også beskyttede. FoxIDs' indbyggede protokolmappings er fortsat tilgængelige.

Transforms kan læse beskyttede claims og kopiere deres værdier til brugerdefinerede claims. En beskyttet claim kan også vælges i en liste over claims, der skal videresendes eller udstedes, uden at angive statiske værdier.

De samme begrænsninger gælder for brugerdefinerede claims på interne og eksterne brugere, indledende claims for tenantens bruger, claims på noder i adgangsstrukturen, outputclaims fra dynamisk UI samt statiske claims på applikationer og scopes.

Beskyttede claims, der returneres af et Claims API, et API til validering af Extended UI, et External Login API eller et Directory Connector API, fjernes. Eksisterende beskyttede claims i flowet bevares. Udvalgte beskyttede claims kan sendes til disse API'er som input.