Formats de jeton pris en charge dans ACS

Article
11/09/2015

Mise à jour : 19 juin 2015

S’applique à : Azure

Lorsque vos applications web et services gèrent l’authentification avec Microsoft Azure Active Directory Access Control (également appelé service Access Control ou ACS), le client doit obtenir un jeton de sécurité émis par ACS pour se connecter à votre application ou service. ACS peut émettre des jetons de sécurité dans les formats suivants :

SAML (Security Assertion Markup Language) 1.1 et 2.0
Clé d’authentification Web simple (SWT)
Jeton web JSON (JWT)

Notes

ACS peut émettre des jetons de sécurité dans l’un des formats suivants. Le format de jeton utilisé par ACS pour une application web ou un service est déterminé par la configuration de l’application de partie de confiance. Pour plus d’informations sur la configuration des applications de partie de confiance, consultez Applications de partie de confiance.

SAML (Security Assertion Markup Language) 1.1 et 2.0

Security Assertion Markup Language (SAML) est le format le plus ancien et le plus courant des jetons utilisés aujourd'hui pour l'authentification unique (SSO) et l'identité basée sur des revendications. SAML spécifie un format XML, pour les jetons ainsi que pour les protocoles, pour l'exécution d'une application web ou d'un service web SSO à l'aide des jetons SAML. Pour plus d’informations sur les jetons SAML, consultez spécifications SAML (https://go.microsoft.com/fwlink/?LinkID=213719).

Notes

Les jetons SAML 1.1 et SAML 2.0 sont largement pris en charge par un certain nombre de plateformes de développement, notamment Windows Identity Foundation (https://go.microsoft.com/fwlink/?LinkID=213729).

Voici un exemple de jeton 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>

Clé d’authentification Web simple (SWT)

Les jetons SWT sont conformes à la spécification SimpleWebToken. Ils sont exprimés sous forme de paires clé/valeur dans un format codé signées avec une clé de chiffrement. La spécification mandate la présence de certaines paires clé/valeur, mais elle laisse de la place aux paires clé/valeur spécifiques aux applications. Les clés qui sont toujours présentes dans un jeton SWT émis par ACS sont affichées dans le tableau suivant.

Clé	Description
Émetteur	Représentation de l’espace de noms de service ACS qui a émis le jeton. Le modèle de cette valeur est https://< servicenamespace.accesscontrol.windows.net/>.
Public visé	La valeur de `applies_to` utilisée pour demander le jeton. La valeur est soit un URI HTTP ou HTTPS.
ExpiresOn	Date à laquelle le jeton expire.
HMACSHA256	Signature HMACSHA256 de toutes les autres paires clé/valeur. Cette paire clé/valeur est toujours la dernière paire clé/valeur dans le jeton. La représentation au format codé des autres paires clé/valeur (y compris les revendications spécifiques à l'application) est signée.

En plus de ces paires clé/valeur, ACS ajoute une ou plusieurs revendications à un jeton avant l’émission. Ces revendications sont pilotées par la configuration de règle présente dans ACS au moment de la demande de jeton. Toutes ces revendications ont un type et une ou plusieurs valeurs, où le type et les valeurs sont des chaînes. Lorsqu'une revendication contient plusieurs valeurs, les valeurs sont séparées par une virgule (« , »). Les revendications sont codées comme des paires clé/valeur, exactement comme les paires clé/valeur décrites dans le tableau précédent.

Voici un exemple de jeton ACS qui contient des revendications représentées en tant que paires clé/valeur.

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

À l'exception de la paire clé/valeur HMACSHA256, ces paires peuvent être dans n'importe quel ordre. Le jeton ACS suivant équivaut au jeton ACS précédent, à l’exception des signatures qui sont différentes.

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

Le tableau suivant représente le contenu du jeton avec des valeurs décodées d'URL.

Source	Clé :	Valeur encodée d'URL	Valeur décodée d'URL
Revendications définies par l'utilisateur	rôle	Admin%2cUser	Admin,User
Revendications définies par l'utilisateur	customerName	Contoso%20Corporation	Contoso Corporation
Revendications définies par le système	Émetteur	https%3a%2f%2fmyservice.accesscontrol.windows.net%2f	https://myservice.accesscontrol.windows.net/
	Public visé	http%3a%2f%2flocalhost%2fmyservice	https://localhost/myservice
	ExpiresOn	1255912922	1255912922
	HMACSHA256	yuVO%2fwc58%2ftYP36%2fDM1mS%2fHr0hswpsGTWwgfvAbpL64%3d	yuVO/wc58/tYP36/DM1mS/Hr0hswpsGTWwgfvAbpL64=

Jeton web JSON (JWT)

La prise en charge des jetons web JSON (JWT) a été ajoutée dans la version bêta. Cela signifie que des modifications majeures pourront être ajoutées sans préavis.

L’implémentation ACS du format de jeton JWT suit le brouillon 9 de la spécification JWT. Pour plus d’informations, consultez https://go.microsoft.com/fwlink/?LinkID=253666. De la même manière que les jetons SWT, les jetons JWT utilisent un format compact adapté aux services web REST. Contrairement au format SWT, JWT prend en charge diverses options de signature. ACS prend en charge les signatures symétriques et asymétriques pour les jetons JWT. Les revendications toujours présentes dans les jetons JWT émis par ACS sont indiquées dans le tableau suivant.

Revendication	Type de revendication utilisé pour les jetons JWT	Description
Émetteur	iss	Représentation de l’espace de noms Access Control qui a émis le jeton. Le modèle de cette valeur est https://< namespace.accesscontrol.windows.net/>
Public visé	aud	Valeur de l'étendue utilisée pour demander le jeton. Cette valeur est utilisée pour identifier le destinataire souhaité du jeton.
Pas avant	nbf	Date avant laquelle le jeton n'est pas valide.
Expiration	exp	Date à laquelle le jeton expire.

Les algorithmes suivants sont pris en charge pour les jetons JWT :

Identificateur d'algorithme dans l'en-tête JWT	Description
HS256	HMAC qui utilise un algorithme de hachage SHA-256. Pour signer JWT avec une clé symétrique .
RS256	HMAC qui utilise un algorithme de hachage SHA-256. À utiliser pour la signature d'un jeton JWT avec une clé asymétrique utilisant un certificat X.509.

Voici un exemple de jeton JWT :

eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJhdWQiOiJodHRwczovL2NvbnRvc28uY29tL3JlbHlpbmdwYXJ0eSIsImlzcyI6Imh0dHBzOi8vY29udG9zby5hY2Nlc3Njb250cm9sLndpbmRvd3MubmV0LyIsIm5iZiI6MTMzNjA2NzMzOCwiZXhwIjoxMzM2MDcwOTM4LCJuYW1laWQiOiJjbGllbnRBcHAiLCJpZGVudGl0eXByb3ZpZGVyIjoiY29udG9zby5jb20ifQ._3dZQ6cmmFgrZ_-VmOLrr7CHne3Xdko_WtE6-Je5Ihw.

Un jeton JWT est composé de segments délimités par ‘.’. Le tableau suivant montre les segments décodés d'un jeton JWT :

Segment JWT	Valeur
En-tête JWT	{"typ":"JWT","alg":"HS256"}
Ensemble de revendications JWT	{"aud »: »https://contoso.com/relyingparty","iss »: »https://contoso.accesscontrol.windows.net/""nbf »:1336067338,"exp »:1336070938,"nameid »:"clientApp »,"identityprovider »:"contoso.com"}
Signature	_3dZQ6cmmFgrZ_-VmOLrr7CHne3Xdko_WtE6-Je5Ihw

Une seule revendication avec plusieurs valeurs est représentée comme un tableau JSON. Par exemple, si un utilisateur est membre de plusieurs rôles, la revendication de rôle apparaîtra ainsi :

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

Protocoles et jetons ACS

Lorsqu’un jeton SAML 2.0, SAML 1.1, SWT, JWT est émis, ACS utilise différents protocoles standard pour retourner le jeton à une application web ou à un service. ACS prend en charge les combinaisons de format/protocole de jeton suivantes :

ACS peut émettre et retourner des jetons SAML 2.0 sur les protocoles WS-Trust et WS-Federation (en fonction du protocole utilisé dans la demande de jeton).
ACS peut émettre et retourner des jetons SAML 1.1 sur les WS-Federation et les protocoles WS-Trust associés (en fonction du protocole utilisé dans la demande de jeton).
ACS peut émettre et retourner des jetons SWT sur les protocoles WS-Federation, WS-Trust et OAuth WRAP ou OAuth 2.0 (selon le protocole utilisé dans la demande de jeton).
ACS peut émettre des jetons JWT sur les protocoles WS-Federation, WS-Trust et OAuth 2.0 (selon le protocole utilisé dans la demande de jeton).

Voir aussi

Concepts

Architecture ACS
Composants ACS 2.0