Formatos de token admitidos en ACS

Artículo
11/09/2015

Actualizado: 19 de junio de 2015

Se aplica a: Azure

Cuando las aplicaciones web y los servicios controlan la autenticación con Microsoft Azure Active Directory Access Control (también conocido como servicio Access Control o ACS), el cliente debe obtener un token de seguridad emitido por ACS para iniciar sesión en la aplicación o el servicio. ACS puede emitir tokens de seguridad en los siguientes formatos:

Lenguaje marcado de aserción de seguridad (SAML) 1.1 y 2.0
Simple Web Token (SWT)
Token web JSON (JWT)

Nota

ACS puede emitir tokens de seguridad en cualquiera de los siguientes formatos. El formato de token que USA ACS para una aplicación web o servicio viene determinado por la configuración de la aplicación de usuario de confianza. Para obtener información sobre cómo configurar aplicaciones de usuario de confianza, consulte Aplicaciones de usuario autenticado.

Lenguaje marcado de aserción de seguridad (SAML) 1.1 y 2.0

El lenguaje marcado de aserción de seguridad (SAML) es el formato más antiguo y más común de los tokens que se usa actualmente para el inicio de sesión único (SSO) y la identidad basada en notificaciones. SAML especifica un formato XML, para tokens y para protocolos, para el SSO en una aplicación web o en un servicio web mediante tokens SAML. Para obtener más información sobre los tokens de SAML, consulte Especificaciones de SAML (https://go.microsoft.com/fwlink/?LinkID=213719).

Nota

Los tokens SAML 1.1 y SAML 2.0 son ampliamente compatibles con una serie de plataformas de desarrollo, como Windows Identity Foundation (https://go.microsoft.com/fwlink/?LinkID=213729).

A continuación se muestra un ejemplo de un token SAML.

<assertion id="_4fe09cda-cad9-49dd-b493-93494e1ae4f9" issueinstant="2012-09-18T20:42:11.626Z"
    version="2.0" xmlns="urn:oasis:names:tc:SAML:2.0:assertion">
<issuer>https://test05.accesscontrol.windows.net/</issuer>
<ds:signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
    <ds:signedinfo>
        <ds:canonicalizationmethod algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" />
        <ds:signaturemethod algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256" />
        <ds:reference uri="#_4fe09cda-cad9-49dd-b493-93494e1ae4f9">
            <ds:transforms>
                <ds:transform algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature" />
                <ds:transform algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" />
            </ds:transforms>
            <ds:digestmethod algorithm="http://www.w3.org/2001/04/xmlenc#sha256" />
            <ds:digestvalue>8qmfRKuATFuo4M96xuci7HCLUGUeO3eBxHOi9/HaFNU=</ds:digestvalue>
        </ds:reference>
    </ds:signedinfo>
<ds:signaturevalue>UWcXJElfrP8hfdNi8ipzSjfxCYGYzoylkn5HdSa8IhphvyZBvbZl1OFEbMSygoo8xNgnywUNPuzZP8nV7CwZNuSWVZZSrF2pHAswBKQoJoodpzrGRR0ruT+A2sjXfnLQqN+X/xanXqqg4ViUOR9xHvn8vzaRwYxPPsjI4OXq0hzLlyuBzhw42XHzZk1qknQr1wp/lZTMwrFnY38gziUZ+Ci1Duen5Xt9k+0ZFujtSBqJKIran1V263o8CkvoahNcNKT//OcXc3va7zeJf67V9/lwY34MkFoqqfeuTSzEuZfk7pYRNqwhOZGhokpR+1qHjEbJr3p6dOOPkuQp9p6zsQ==</ds:signaturevalue>
    <keyinfo xmlns="http://www.w3.org/2000/09/xmldsig#">
        <X509Data>       <X509Certificate>MIIDCDCCAfCgAwIBAgIQRmI8p7P/aphMv5Kr9vQpqTANBgkqhkiG9w0BAQUFADAtMSswKQYDVQQDEyJBQVJPTkJPT0subnRkZXYuY29ycC5taWNyb3NvZnQuY29tMB4XDTEyMDUyMTIzMjMxMFoXDTEzMDUyMTAwMDAwMFowLTErMCkGA1UEAxMiQUFST05CT09LLm50ZGV2LmNvcnAubWljcm9zb2Z0LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAI79l6EOSWswJn3d9i4yfZh9Cwo2XNhb4tOWvmljCKFlrWoz/Drch5aOzdmI/yFaqkyX7BXc/zoSmX1n3VkqHIeJkGECcZX2bD4jPuICVmKBcXo0SeQ+2vF6DoqjVKaegWrPsqmDrlCscnlMLb11Fg1Ffqkm8wyyWwbQvC5VnVf0i9DPE0n+i3NJi9cT57obrNRkQzwfBZy08I2JlpxLfaUUDhHlF99C1MtBduzn3au+S20gom1cHAcSvHBormXbjPZ5F6RJUz7kO/U+M5rYkiS+vtANtnBlUAK8fRmEUrYFRMr1tyiOXcRid/7UJP3e0EmAsneMnuD9WO/mK6MuzIECAwEAAaMkMCIwCwYDVR0PBAQDAgQwMBMGA1UdJQQMMAoGCCsGAQUFBwMBMA0GCSqGSIb3DQEBBQUAA4IBAQBCRM9maY5ZE+wIxefxjT0IAqp7H6l062PKOGdld5MapOJUWbng2CrfUV3YI5OSD9yhevgDne3jf2DUBv5QndHdms+FL260ydDmwet4A5kJi3ZBO4sR/PZTz3FdeeOwdTeUS2wAMJuphAZ1+PUVk25bbEu/DKmgeYzRn64CHWqk5sPKzH9jAszvX2EeoClI+8Sp/bXHTwzEUOFYcicPOO+tuFTqHOYBDT5bE42rAp/SaC1wXbmTCGS12gfCZCrlml6LZNTsKQWBF2szXOPGcFcInGkauZDUUtZd+921uy0E/sYwgNfi8phU1aGZjIESVFQ70LpfvIMwF6++BRX12icW</X509Certificate>
        </X509Data>
    </keyinfo>
</ds:signature>
<subject>
    <NameID>abc1def2ghi3jkl4mno5pqr6stu7vwx8yza9bcd0efg=</NameID>
    <SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer" />
</subject>
    <conditions notbefore="2012-09-18T20:42:11.610Z" notonorafter="2012-09-18T21:42:11.610Z">
        <AudienceRestriction>
            <Audience>https://localhost:63000/</Audience>
        </AudienceRestriction>
    </conditions>
    <attributestatement>
        <Attribute Name="https://schemas.microsoft.com/accesscontrolservice/2010/07/claims/identityprovider">
            <AttributeValue>uri:WindowsLiveID</AttributeValue>
        </Attribute>
    </attributestatement>
</assertion>

Simple Web Token (SWT)

Los tokens SWT cumplen con la especificación SimpleWebToken. Los tokens SWT se expresan como pares de clave/valor codificados por formulario, firmados con una clave criptográfica. La especificación exige la presencia de algunos pares de clave/valor, pero deja espacio para pares de clave/valor específicos de la aplicación. Las claves que siempre están presentes en un token SWT emitido por ACS se muestran en la tabla siguiente.

Clave	Descripción
Emisor	Representación del espacio de nombres del servicio ACS que emitió el token. El patrón de este valor es https://< servicenamespace.accesscontrol.windows.net/>.
Público	El valor de `applies_to` usado para solicitar el token. Este valor es un URI HTTP o HTTPS.
ExpiresOn	El tiempo base tras el cual expira el token.
HMACSHA256	La firma HMACSHA256 de todos los otros pares de clave/valor. Este par de clave/valor es siempre el último par de clave/valor del token. La representación codificada por formulario de los otros pares de clave/valor (incluidas las notificaciones específicas de la aplicación) está firmada.

Además de estos pares clave-valor, ACS agrega una o varias notificaciones a un token antes de la emisión. Estas notificaciones se controlan mediante la configuración de la regla presente en ACS en el momento de la solicitud de token. Todas estas notificaciones tienen un tipo y uno o varios valores, donde tanto el tipo como los valores son cadenas. Cuando una notificación contiene más de un valor, estos se separan mediante el carácter de coma (“,”). Las notificaciones se codifican como pares de clave/valor, exactamente como los pares de clave/valor descritos en la tabla anterior.

A continuación se muestra un ejemplo de un token de ACS que contiene notificaciones representadas como pares clave-valor.

Audience=http%3a%2f%2flocalhost%2fmyservice&ExpiresOn=1255913549Issuer=https%3a%2f%2fmyservice.accesscontrol.windows.net%2f&role=Admin%2cUser&role=Admin%2cUser&&HMACSHA256=sT7Hr9z%2b3t1oDFLpq5GOToVsu6Dyxpq7hHsSAznmwnI%3d

A excepción del par de clave/valor HMACSHA256, estos pares pueden estar en cualquier orden. El siguiente token de ACS es equivalente al token de ACS anterior, excepto las firmas que son diferentes.

role=Admin%2cUser&customerName=Contoso%20Corporation&Issuer=https%3a%2f%2fmyservice.accesscontrol.windows.net%2f&Audience=http%3a%2f%2flocalhost%2fmyservice&ExpiresOn=1255912922&HMACSHA256=yuVO%2fwc58%2ftYP36%2fDM1mS%2fHr0hswpsGTWwgfvAbpL64%3d

En la tabla siguiente se muestra el contenido del token con los valores de dirección URL descodificados.

Source	Clave	Valor de URL codificado	Valor de URL descodificado
Notificaciones definidas por el usuario	rol	Admin%2cUser	Admin,User
Notificaciones definidas por el usuario	customerName	Contoso%20Corporation	Contoso Corporation
Notificaciones definidas por el sistema	Emisor	https%3a%2f%2fmyservice.accesscontrol.windows.net%2f	https://myservice.accesscontrol.windows.net/
	Público	http%3a%2f%2flocalhost%2fmyservice	https://localhost/myservice
	ExpiresOn	1255912922	1255912922
	HMACSHA256	yuVO%2fwc58%2ftYP36%2fDM1mS%2fHr0hswpsGTWwgfvAbpL64%3d	yuVO/wc58/tYP36/DM1mS/Hr0hswpsGTWwgfvAbpL64=

Token web JSON (JWT)

En la versión beta se agrega la compatibilidad de los token web JSON (JWT), es decir, que puede haber cambios bruscos sin previo aviso.

La implementación de ACS del formato de token JWT sigue el borrador 9 de la especificación JWT. Para obtener más información, vea https://go.microsoft.com/fwlink/?LinkID=253666. Al igual que los tokens SWT, JWT es un formato de token compacto que es idóneo para los servicios web REST. A diferencia del formato SWT, JWT admite una variedad de opciones de firma. ACS admite firmas simétricas y asimétricas para tokens JWT. Las notificaciones que siempre están presentes en los tokens JWT emitidos por ACS se muestran en la tabla siguiente.

Notificación	Tipo de notificación usado por JWT	Descripción
Emisor	iss	Representación del espacio de nombres Access Control que emitió el token. El patrón de este valor es https://< namespace.accesscontrol.windows.net/>
Público	aud	El valor del ámbito usado para solicitar el token. Este valor se usa para identificar el destinatario del token.
No antes de	nbf	El tiempo base antes del cual el token no es válido.
Expiration	exp	El tiempo base tras el cual expira el token.

Se admiten los algoritmos siguientes para los tokens JWT:

Identificador de algoritmos en el encabezado de JWT	Descripción
HS256	HMAC que usa el algoritmo de hash SHA-256. Para firmar JWT con una clave simétrica .
RS256	RSA que usa el algoritmo de hash SHA-256. Para firmar el JWT con una clave asimétrica, mediante un certificado x509.

A continuación se muestra un ejemplo de token JWT:

eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJhdWQiOiJodHRwczovL2NvbnRvc28uY29tL3JlbHlpbmdwYXJ0eSIsImlzcyI6Imh0dHBzOi8vY29udG9zby5hY2Nlc3Njb250cm9sLndpbmRvd3MubmV0LyIsIm5iZiI6MTMzNjA2NzMzOCwiZXhwIjoxMzM2MDcwOTM4LCJuYW1laWQiOiJjbGllbnRBcHAiLCJpZGVudGl0eXByb3ZpZGVyIjoiY29udG9zby5jb20ifQ._3dZQ6cmmFgrZ_-VmOLrr7CHne3Xdko_WtE6-Je5Ihw.

JWT se compone de segmentos, que se delimitan mediante ‘.’. En la tabla siguiente se muestran los segmentos descodificados de un token JWT:

Segmento del JWT	Valor
Encabezado del JWT	{"typ":"JWT","alg":"HS256"}
Conjunto de notificaciones del JWT	{"aud":"https://contoso.com/relyingparty","iss":"https://contoso.accesscontrol.windows.net/","nbf":1336067338,"exp":1336070938,"nameid":"clientApp","identityprovider":"contoso.com"}
Firma	_3dZQ6cmmFgrZ_-VmOLrr7CHne3Xdko_WtE6-Je5Ihw

Una única notificación con varios valores se representa como una matriz JSON. Por ejemplo, si un usuario es miembro de varios roles, la notificación de rol aparecería del modo siguiente:

{
 "aud":"https://contoso.com/relyingparty",
"iss":"https://contoso.accesscontrol.windows.net/",
"nbf":1336067338,"exp":1336070938,
"nameid":"frankm",
"identityprovider":"contoso.com",
“role”: [ “admin”, “user” ]
}

Tokens y protocolos de ACS

Cuando se emite un token SAML 2.0, SAML 1.1, SWT, JWT, ACS usa varios protocolos estándar para devolver el token a una aplicación web o servicio. ACS admite las siguientes combinaciones de formato o protocolo de token:

ACS puede emitir y devolver tokens SAML 2.0 a través de los protocolos de WS-Trust y WS-Federation (según el protocolo usado en la solicitud de token).
ACS puede emitir y devolver tokens SAML 1.1 a través de la WS-Federation y los protocolos de WS-Trust relacionados (según el protocolo usado en la solicitud de token).
ACS puede emitir y devolver tokens SWT a través de los protocolos WS-Federation, WS-Trust y OAuth WRAP o OAuth 2.0 (según el protocolo usado en la solicitud de token).
ACS puede emitir tokens JWT a través de los protocolos WS-Federation, WS-Trust y OAuth 2.0 (según el protocolo usado en la solicitud de token).

Consulte también

Conceptos

Arquitectura de ACS
Componentes de ACS 2.0