Formats de jeton pris en charge dans ACS
Réduire la table des matières
Développer la table des matières

Formats de jeton pris en charge dans ACS

Publication: avril 2011

Mis à jour: juin 2015

S'applique à: Azure

Lorsque vos applications et services web gèrent l'authentification avec Microsoft Azure Active Directory Access Control (également appelé Access Control Service 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é aux formats suivants :

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

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 (http://go.microsoft.com/fwlink/?LinkID=213719).

noteRemarque
Les jetons SAML 1.1 et SAML 2.0 sont largement pris en charge par un grand nombre de plateformes de développement, dont Windows Identity Foundation (http://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>http://localhost:63000/</Audience>
        </AudienceRestriction>
    </conditions>
    <attributestatement>
        <Attribute Name="http://schemas.microsoft.com/accesscontrolservice/2010/07/claims/identityprovider">
            <AttributeValue>uri:WindowsLiveID</AttributeValue>
        </Attribute>
    </attributestatement>
</assertion>

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 toujours présentes dans les jetons SWT émis par ACS s'affichent dans le tableau suivant.

 

de l'agent Description

Issuer

Une représentation de l'espace de noms de service ACS qui a émis le jeton. Le modèle de cette valeur est https://<espacenomsservice>.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.

Outre ces paires clé/valeur, ACS ajoute une ou plusieurs revendications à un jeton avant son émission. Ces revendications sont pilotées par la configuration des règles présentes dans ACS au moment de la demande de jetons. 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 les 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 sauf pour les 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 de l'agent Valeur encodée d'URL Valeur décodée d'URL

Revendications définies par l'utilisateur

rôle

Admin%2cUser

Admin,User

customerName

Contoso%20Corporation

Contoso Corporation

Revendications définies par le système

Issuer

https%3a%2f%2fmyservice.accesscontrol.windows.net%2f

https://myservice.accesscontrol.windows.net/

Public visé

http%3a%2f%2flocalhost%2fmyservice

http://localhost/myservice

ExpiresOn

1255912922

1255912922

HMACSHA256

yuVO%2fwc58%2ftYP36%2fDM1mS%2fHr0hswpsGTWwgfvAbpL64%3d

yuVO/wc58/tYP36/DM1mS/Hr0hswpsGTWwgfvAbpL64=

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 http://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, le format JWT prend en charge plusieurs 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 SWT émis par ACS s'affichent dans le tableau suivant.

 

Revendication Type de revendication utilisé pour les jetons JWT Description

Issuer

iss

Représentation de l'espace de noms Access Control qui a émis le jeton. Le modèle de cette valeur est https://<espacenoms>.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.

Not Before

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. À utiliser pour la signature d'un jeton 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” ]
}

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

  • ACS peut émettre et renvoyer les jetons SAML 2.0 sur les protocoles WS-Trust et WS-Federation (en fonction du protocole utilisé dans la demande de jetons).

  • ACS peut émettre et renvoyer les jetons SAML 1.1 sur les protocoles WS-Federation et les protocoles WS-Trust liés (en fonction du protocole utilisé dans la demande de jetons).

  • ACS peut émettre et renvoyer les jetons SWT sur les protocoles WS-Federation, WS-Trust et OAuth WRAP ou OAuth 2.0 (en fonction du protocole utilisé dans la demande de jetons).

  • ACS peut émettre et renvoyer les jetons JWT sur les protocoles WS-Federation, WS-Trust et/ou OAuth 2.0 (en fonction du protocole utilisé dans la demande de jetons).

Voir aussi

Afficher:
© 2016 Microsoft