Applikationers requestparametre

En applikation kan sende værdier til claim transforms, f.eks. et profil-ID eller en liste over afdelinger. Konfigurer Allowed request parameters på applikationsregistreringen for at gøre udvalgte værdier tilgængelige som _local:params:{name} claims.

Konfigurer parametre

Aktivér Show advanced, og konfigurer Allowed request parameters på applikationsregistreringen.

Tilføj hvert tilladt parameternavn. Listen er som standard tom. Navne gemmes med små bogstaver; brug understregninger mellem ord, f.eks. profile_id.

FoxIDs opdeler automatisk parameterværdier ved mellemrum. En værdi uden mellemrum giver én claim; en liste adskilt af mellemrum giver én claim pr. element. Værdier bevarer store og små bogstaver. Eksempel:

profile_id=16b66fb6-9f88-4a10-b489-8e54f48f76a4&departments=Sales%20Support

Når profile_id og departments er konfigureret som tilladte parameternavne, modtager transforms:

_local:params:profile_id = 16b66fb6-9f88-4a10-b489-8e54f48f76a4
_local:params:departments = Sales
_local:params:departments = Support

Indledende, afsluttende og gentagne mellemrum ignoreres. Anførselstegn har ingen særlig betydning. Send listen i én forekomst af parameteren.

Understøttede requests

Request Parameterkilde Tilgængelig i claim transforms
OpenID Connect autorisation Query string Autentificeringsmetode og applikation
SAML 2.0 autentificering Query string eller formularfelter med HTTP-POST Autentificeringsmetode og applikation
WS-Federation passivt login Query string eller formularfelter med HTTP-POST Autentificeringsmetode og applikation
OAuth 2.0 / OpenID Connect client credentials Tokenrequestets formular Applikation
OAuth 2.0 / OpenID Connect token exchange Tokenrequestets formular Valgt autentificeringsmetode ved validering af et eksternt subject token samt applikation

Indløsning af authorization code og refresh token requests bruger de eksisterende grant-claims; yderligere requestparametre gøres ikke tilgængelige for transforms.

For SAML sendes parametrene sammen med protokolmeddelelsen. Ved HTTP-Redirect tilføjes de efter oprettelsen af den signerede redirect-URL, så meddelelsen for SAML og signaturen forbliver intakte. Disse ekstra parametre ligger uden for den signerede meddelelse for SAML.

Grænser

Indstilling Grænse
Konfigurerede parameternavne 10
Navnelængde 30 tegn: bogstaver fra ASCII, cifre, understregninger eller bindestreger
Modtagne værdier på tværs af alle parametre 10
Hver afkodet værdi 500 tegn
Alle afkodede værdier tilsammen 1.000 tegn

Parameternavne matches uden forskel på store og små bogstaver. Ikke-konfigurerede navne ignoreres. Konfigurerede parametre skal forekomme én gang og indeholde værdier, der hverken er tomme eller kun består af blanktegn. En gentaget parameter, herunder samme navn i både query og form, eller en værdi, der overskrider grænserne, får requestet afvist med en protokolfejl. Listeseparatorer tæller ikke med i den samlede værdilængde.

Brug parametre i transforms

Ved browserlogin er parametrene tilgængelige fra autentificeringsmetodens first-level claim transforms. De er fortsat tilgængelige i efterfølgende transform-sæt, herunder Extended UI og applikationens transforms, gennem hele loginflowet. Hvert sæt modtager de oprindeligt accepterede værdier som lokale claims.

Brug en Map-transform til at kopiere en værdi til en almindelig claim til output eller til en _internal: claim til senere behandling. For at bevare et autoriseret valg til senere applikationslogins mappes det til en _session: claim i autentificeringsmetoden. Et efterfølgende login kan bruge den medsendte parameter eller, hvis den mangler, den gemte sessionsclaim. Se lokale, interne og sessionsclaims.

Parametre er input leveret af den kaldende part. Før et profil-ID bruges til impersonering eller en anden privilegeret handling, skal den autentificerede brugers rettigheder og målbrugerens egnethed kontrolleres. Et medsendt ID identificerer det ønskede mål; det giver ikke adgang. Undgå at sende hemmeligheder i queryparametre.