Reclamaciones
Las reclamaciones se procesan primero en el método de autenticación y luego en el registro de la aplicación, donde es posible decidir qué reclamaciones se pasan al siguiente paso y realizar transformaciones de reclamaciones y tareas de reclamaciones.
Todas las comparaciones de reclamaciones distinguen mayúsculas y minúsculas.
El proceso de reclamaciones comienza en el método de autenticación cuando un usuario se autentica. Allí es posible realizar transformaciones de reclamaciones y tareas de reclamaciones y configurar qué reclamaciones deben pasar al siguiente paso. Luego el proceso de reclamaciones continúa en el registro de la aplicación donde también es posible hacer transformaciones de reclamaciones y configurar qué reclamaciones deben emitirse a la aplicación / API.
En un escenario de Client Credentials Grant, el proceso de reclamaciones solo se realiza en el registro de la aplicación. Lo mismo aplica a las transformaciones de reclamaciones y a la configuración de qué reclamaciones deben emitirse a la aplicación / API.
Para valores usados dentro de FoxIDs, elija _local: para un conjunto de transformaciones, _internal: para el flujo de autenticación actual, incluidas las transformaciones de aplicación, o _session: para inicios de sesión posteriores del navegador mediante el mismo método. Estos claims reservados no se emiten a las aplicaciones. Consulte Claims locales, internos y de sesión, incluido cómo copiar un valor de sesión a un claim interno para las transformaciones de aplicación.
Método de autenticación
En un método de autenticación OpenID Connect y SAML 2.0, las reclamaciones se transfieren agregándolas a la lista Forward claims. Todas las reclamaciones se transfieren si se agrega un comodín * a la lista Forward claims.
Las siguientes reclamaciones identifican el último método de autenticación utilizado. Se reenvían de forma predeterminada y pueden leerse en el registro de la aplicación y usarse en transformaciones de reclamaciones y tareas de reclamaciones:
auth_methodcontiene el nombre del método de autenticación, que es único dentro del entorno.auth_method_typecontiene el tipo de método de autenticación:login,oidc,oauth2,saml2,wsfed,env_linkoext_login.auth_profile_methodcontiene el nombre del perfil seleccionado del método de autenticación. Esta reclamación se incluye cuando se utiliza un perfil.
Una reclamación sub y tokens recibidos de un proveedor de identidad externo se anidan con un símbolo de barra vertical (|) después del nombre del método de autenticación.
Ejemplos:
- Un
subexterno con el valorafeda2a3-c08b-4bbb-ab77-35138dd2ef2dobtiene el valor anidadothe-auth-method|afeda2a3-c08b-4bbb-ab77-35138dd2ef2d - Un token de acceso externo con el valor
eyJhG.cRwczov...nNjb3B.lIjoise agrega en la reclamaciónaccess_tokencon el valor anidadothe-auth-method|eyJhG.cRwczov...nNjb3B.lIjoi - Si el OpenID Provider externo devuelve un refresh token, se puede reenviar en la reclamación
refresh_tokencon el valor anidadothe-auth-method|refresh-token-value
Registro de la aplicación
En un registro de aplicación OpenID Connect, OAuth 2.0 y SAML 2.0 las reclamaciones se emiten a la aplicación / API agregándolas a la lista Issue claims. Todas las reclamaciones se emiten a la aplicación / API si se agrega un comodín * a la lista Issue claims.
Un registro de aplicación OpenID Connect puede diferenciar si una reclamación se emite solo en el token de acceso o también en el token de ID.
Un registro de aplicación OpenID Connect y OAuth 2.0 también puede llevar las reclamaciones adelante mediante un scope. Esto se hace agregando la reclamación o reclamaciones a la lista Voluntary claims de un scope. Y las reclamaciones se emiten si la aplicación cliente solicita el scope.
Un registro de aplicación OpenID Connect también puede, en las reclamaciones de scope voluntario, diferenciar si una reclamación se emite solo en el token de acceso o también en el token de ID.
Tipos de valores de claims
Los tipos de valores de claims JWT, incluidos objetos JSON, matrices, booleanos y números, se conservan al copiar claims mediante una transformación Map o transmitirlos a través de sesiones, Extended UI y grants OAuth. OpenID Connect UserInfo devuelve estos valores con sus tipos JSON correspondientes.
Las transformaciones que generan texto nuevo, como el mapeo regex y la concatenación, producen valores de cadena.
El mapeo de claims JWT/SAML conserva tipos de valores como booleanos y números. Al mapear de JWT a SAML, los valores JSON se transmiten como texto en atributos de cadena. Al mapear de SAML a JWT, las cadenas con objetos o matrices JSON válidos se convierten en claims JSON.
Identidades suplantadas
Un método de autenticación puede seleccionar otro usuario con una transformación Impersonation. Las transformaciones de la aplicación reciben entonces los claims del usuario de destino y un claim act que identifica al usuario autenticado original. Los claims _impersonate: preparan la selección en las transformaciones del método de autenticación; los claims auxiliares locales conservan sus nombres reservados bajo este prefijo.
En los JWT, act es un objeto JSON, por ejemplo {"sub":"original-user"}. Su mapeo SAML predeterminado es http://schemas.foxids.com/ws/identity/claims/act, que puede modificarse en los mapeos de claims del entorno. Seleccione el claim mapeado en Issue claims de la aplicación SAML, o use *, para emitir su texto JSON. Cuando un atributo SAML con este texto JSON se mapea de nuevo a act, FoxIDs lo emite como objeto JSON en el JWT.
Reclamaciones protegidas
FoxIDs administra las reclamaciones que controlan las sesiones, la validez de los tokens y el enrutamiento entre métodos de autenticación. Estas reclamaciones protegidas no se pueden configurar como salidas de transformaciones de reclamaciones ni utilizar en asignaciones personalizadas de reclamaciones JWT/SAML, y no se les pueden asignar valores estáticos.
Los nombres de las reclamaciones JWT protegidas son:
sid,iss,aud,exp,nbf,iatyauth_time.client_id,azp,scope,nonce,at_hashyc_hash.auth_method,auth_method_type,auth_profile_methodyauth_method_issuer.
Los tipos de reclamaciones SAML correspondientes al índice de sesión, al instante de autenticación, al ID de cliente y al método de autenticación también están protegidos. Las asignaciones de protocolos integradas en FoxIDs siguen disponibles.
Las transformaciones pueden leer las reclamaciones protegidas y copiar sus valores a reclamaciones personalizadas. Una reclamación protegida también se puede seleccionar en una lista de reclamaciones que se deben reenviar o emitir sin proporcionar valores estáticos.
Las mismas restricciones se aplican a las reclamaciones personalizadas de usuarios internos y externos, a las reclamaciones iniciales del usuario del inquilino, a las reclamaciones de los nodos de la estructura de acceso, a las reclamaciones de salida de la interfaz de usuario dinámica y a las reclamaciones estáticas de aplicaciones y ámbitos.
Las reclamaciones protegidas devueltas por una Claims API, una API de validación de Extended UI, una External Login API o una Directory Connector API se descartan. Se conservan las reclamaciones protegidas existentes en el flujo. Las reclamaciones protegidas seleccionadas se pueden enviar a estas API como entrada.