Claims

Claims behandlas först i autentiseringsmetoden och sedan i applikationsregistreringen, där det är möjligt att avgöra vilka claims som skickas vidare till nästa steg och att göra claim transforms och claim tasks.

Alla claim jämförelser är case sensitive.

Claim processen startar i autentiseringsmetoden när en användare autentiserar. Där är det möjligt att göra claim transforms och claim tasks och konfigurera vilka claims som ska skickas vidare till nästa steg. Därefter fortsätter claim processen i applikationsregistreringen där det också är möjligt att göra claim transforms och konfigurera vilka claims som ska utfärdas till applikationen / API.

I ett Client Credentials Grant scenario görs claim processen endast i applikationsregistreringen. Detsamma gäller claim transforms och konfigurationen av vilka claims som ska utfärdas till applikationen / API.

För värden som används inom FoxIDs väljer du _local: för en transformationsuppsättning, _internal: för det aktuella autentiseringsflödet inklusive applikationens transforms eller _session: för senare webbläsarinloggningar via samma autentiseringsmetod. Dessa reserverade claims utfärdas inte till applikationer. Se Lokala, interna och sessionsclaims, inklusive hur ett sessionsvärde kopieras till ett internt claim för applikationens transforms.

Authentication method

I både en OpenID Connect och SAML 2.0 autentiseringsmetod skickas claims vidare genom att lägga till dem i listan Forward claims. Alla claims skickas vidare om en wildcard * läggs till i listan Forward claims.

Följande claims identifierar den senast använda autentiseringsmetoden. De vidarebefordras som standard och kan läsas i applikationsregistreringen och användas i claim transforms och claim tasks:

auth_method innehåller autentiseringsmetodens namn, som är unikt inom miljön.
auth_method_type innehåller autentiseringsmetodens typ: login, oidc, oauth2, saml2, wsfed, env_link eller ext_login.
auth_profile_method innehåller namnet på den valda profilen för autentiseringsmetoden. Detta claim tas med när en profil används.

Ett sub claim och tokens mottagna från en extern Identity Provider nästlas med ett pipe (|) efter autentiseringsmetodens namn. Exempel:

Ett externt sub med värdet afeda2a3-c08b-4bbb-ab77-35138dd2ef2d får det nästlade värdet the-auth-method|afeda2a3-c08b-4bbb-ab77-35138dd2ef2d
Ett externt access token med värdet eyJhG.cRwczov...nNjb3B.lIjoi läggs till i access_token claim med det nästlade värdet the-auth-method|eyJhG.cRwczov...nNjb3B.lIjoi
Om den externa OpenID Provider returnerar ett refresh token kan det vidarebefordras i refresh_token claim med det nästlade värdet the-auth-method|refresh-token-value

Application registration

I både en OpenID Connect, OAuth 2.0 och SAML 2.0 applikationsregistrering utfärdas claims till applikationen / API genom att lägga till dem i listan Issue claims. Alla claims utfärdas till applikationen / API om en wildcard * läggs till i listan Issue claims.

En OpenID Connect applikationsregistrering kan skilja om ett claim endast utfärdas i access token eller också i ID token.

En OpenID Connect och OAuth 2.0 applikationsregistrering kan också skicka claims vidare via ett scope. Detta görs genom att lägga till claim(s) i ett scopes lista Voluntary claims. Claims utfärdas då om klient applikationen begär scopet. En OpenID Connect applikationsregistrering kan också i de frivilliga scope claims skilja om ett claim endast utfärdas i access token eller också i ID token.

Typer för claimvärden

JWT claimvärden behåller sina typer, inklusive JSON-objekt, arrayer, booleska värden och tal, när claims kopieras av en Map transformation eller förs genom sessioner, Extended UI och OAuth grants. OpenID Connect UserInfo returnerar värdena med motsvarande JSON-typer.

Transformationer som skapar ny text, såsom regexmappning och sammanfogning, skapar strängvärden.

JWT/SAML claimmappning bevarar värdetyper som booleska värden och tal. Vid mappning från JWT till SAML överförs JSON-värden som text i strängattribut. Vid mappning från SAML till JWT blir strängvärden med giltiga JSON-objekt eller arrayer till JSON-claims.

Impersonerade identiteter

En autentiseringsmetod kan välja en annan användare med en Impersonation transformation. Applikationstransformationer får då målanvändarens claims och ett act claim som identifierar den ursprungligen autentiserade användaren. _impersonate: claims förbereder valet i autentiseringsmetodens transformationer; lokala hjälpclaims behåller sina reserverade namn under detta prefix.

I JWT:er är act ett JSON-objekt, exempelvis {"sub":"original-user"}. Dess standardmappning i SAML är http://schemas.foxids.com/ws/identity/claims/act, vilket kan ändras i miljöns claimmappningar. Välj det mappade claimet i SAML-applikationens Issue claims, eller använd *, för att utfärda JSON-texten. När ett SAML-attribut med denna JSON-text mappas tillbaka till act utfärdar FoxIDs det som ett JSON-objekt i JWT:n.

Skyddade claims

FoxIDs hanterar claims som styr sessioner, tokens giltighet och routning mellan autentiseringsmetoder. Dessa skyddade claims kan inte konfigureras som utdata från claim transforms, användas i anpassade JWT/SAML claim mappings eller tilldelas statiska värden.

Följande JWT claims är skyddade:

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

Motsvarande SAML claimtyper för sessionsindex, autentiseringstidpunkt, klient-ID och autentiseringsmetod är också skyddade. FoxIDs inbyggda protokollmappningar är fortsatt tillgängliga.

Transforms kan läsa skyddade claims och kopiera deras värden till anpassade claims. En skyddad claim kan också väljas i en lista över claims som ska vidarebefordras eller utfärdas, utan att ange statiska värden.

Samma begränsningar gäller för anpassade claims på interna och externa användare, inledande claims för tenantens användare, claims på noder i åtkomststrukturen, utdataclaims från dynamiskt UI samt statiska claims för applikationer och scopes.

Skyddade claims som returneras av ett Claims API, ett API för validering av Extended UI, ett External Login API eller ett Directory Connector API tas bort. Befintliga skyddade claims i flödet behålls. Utvalda skyddade claims kan skickas till dessa API:er som indata.