In ACS unterstützte Tokenformate
Aktualisiert: 19. Juni 2015
Gilt für: Azure
Wenn Ihre Webanwendungen und Dienste die Authentifizierung mit Microsoft Azure Active Directory Access Control (auch als Access Control Service oder ACS bezeichnet) behandeln, muss der Client ein von ACS ausgestelltes Sicherheitstoken abrufen, um sich bei Ihrer Anwendung oder Ihrem Dienst anzumelden. ACS kann Sicherheitstoken in den folgenden Formaten ausstellen:
SAML (Security Assertion Markup Language) 1.1 und 2.0
Einfaches Webtoken (Simple Web Token, SWT)
JSON-Webtoken (JWT)
Hinweis
ACS kann Sicherheitstoken in einem der folgenden Formate ausstellen. Das Tokenformat, das ACS für eine Webanwendung oder einen Dienst verwendet, wird durch die Konfiguration der Anwendung der vertrauenden Partei bestimmt. Informationen zum Konfigurieren von Anwendungen von vertrauenden Parteien finden Sie unter "Anwendungen für vertrauende Parteien".
SAML (Security Assertion Markup Language) 1.1 und 2.0
SAML (Security Assertion Markup Language) ist das älteste und am häufigsten verwendete Tokenformat, das heute für SSO (Single Sign-On, einmaliges Anmelden) und anspruchsbasierte Identität in Gebrauch ist. SAML gibt ein XML-Format (für Token und für Protokolle) zum Ausführen von einmaligem Anmelden einer Webanwendung oder eines Webdiensts mithilfe von SAML-Token an. Weitere Informationen zu SAML-Token finden Sie unter SAML-Spezifikationen (https://go.microsoft.com/fwlink/?LinkID=213719).
Hinweis
SAML 1.1- und SAML 2.0-Token werden von einer Reihe von Entwicklungsplattformen unterstützt, einschließlich Windows Identity Foundation (https://go.microsoft.com/fwlink/?LinkID=213729).
Das folgende Beispiel zeigt ein SAML-Token.
<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>
Einfaches Webtoken (Simple Web Token, SWT)
SWT-Token entsprechen der SimpleWebToken-Spezifikation. SWT-Token liegen als formularcodierte Schlüssel-Wert-Paare vor, die mit einem kryptografischen Schlüssel signiert sind. Die Spezifikation verlangt das Vorhandensein einiger Schlüssel-Wert-Paare, lässt jedoch auch Raum für anwendungsspezifische Schlüssel-Wert-Paare. Die Schlüssel, die immer in einem ACS-ausgestellten SWT-Token vorhanden sind, werden in der folgenden Tabelle angezeigt.
| Schlüssel | BESCHREIBUNG |
|---|---|
Issuer (Aussteller) |
Eine Darstellung des ACS-Dienstnamespaces, der das Token ausgestellt hat. Das Muster für diesen Wert ist https://< servicenamespace.accesscontrol.windows.net/>. |
Zielgruppe |
Der Wert von |
ExpiresOn |
Die Epochenzeit, nach der das Token abläuft. |
HMACSHA256 |
Die HMACSHA256-Signatur aller anderen Schlüssel-Wert-Paare. Dieses Schlüssel-Wert-Paar ist immer das letzte Schlüssel-Wert-Paar im Token. Die formularcodierte Darstellung der anderen Schlüssel-Wert-Paare (einschließlich anwendungsspezifischer Ansprüche) ist signiert. |
Zusätzlich zu diesen Schlüssel-Wert-Paaren fügt ACS vor der Ausstellung einen oder mehrere Ansprüche zu einem Token hinzu. Diese Ansprüche werden durch die Regelkonfiguration gesteuert, die zum Zeitpunkt der Tokenanforderung in ACS vorhanden ist. Alle diese Ansprüche weisen einen Typ und mindestens einen Wert auf. Typ und Wert sind Zeichenfolgen. Wenn ein Anspruch mehrere Werte enthält, werden diese durch ein Komma (",") getrennt. Ansprüche werden als Schlüssel-Wert-Paare kodiert, und zwar genau wie die in der Tabelle oben beschriebenen Schlüssel-Wert-Paare.
Im Folgenden finden Sie ein Beispiel für ein ACS-Token, das Ansprüche enthält, die als Schlüssel-Wert-Paare dargestellt werden.
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
Mit Ausnahme des HMACSHA256-Schlüssel-Wert-Paars können diese Paare eine beliebige Reihenfolge aufweisen. Das folgende ACS-Token entspricht dem vorherigen ACS-Token mit Ausnahme der Signaturen, die unterschiedlich sind.
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
Die folgende Tabelle zeigt den Inhalt des Tokens mit URL-decodierten Werten.
| `Source` | Schlüssel | URL-codierter Wert | URL-decodierter Wert |
|---|---|---|---|
|
Benutzerdefinierte Ansprüche |
Rolle (role) |
Admin%2cUser |
Administrator, Benutzer |
|
customerName |
Contoso%20Corporation |
Contoso Corporation |
|
|
Systemdefinierte Ansprüche |
Issuer (Aussteller) |
https%3a%2f%2fmyservice.accesscontrol.windows.net%2f |
https://myservice.accesscontrol.windows.net/ |
|
Zielgruppe |
http%3a%2f%2flocalhost%2fmyservice |
https://localhost/myservice |
|
|
ExpiresOn |
1255912922 |
1255912922 |
|
|
HMACSHA256 |
yuVO%2fwc58%2ftYP36%2fDM1mS%2fHr0hswpsGTWwgfvAbpL64%3d |
yuVO/wc58/tYP36/DM1mS/Hr0hswpsGTWwgfvAbpL64= |
JSON-Webtoken (JWT)
Unterstützung für JSON-Webtoken (JWT) wird in der Betaversion hinzugefügt. Dies bedeutet, dass Änderungen ohne vorherige Ankündigung auftreten können.
Die ACS-Implementierung des JWT-Tokenformats folgt dem Entwurf 9 der JWT-Spezifikation. Weitere Informationen finden Sie unter https://go.microsoft.com/fwlink/?LinkID=253666. Ähnlich wie SWT-Token bietet auch JWT ein kompaktes Tokenformat, das für REST-Webdienste geeignet ist. Im Gegensatz zum SWT-Format unterstützt JWT eine Vielzahl von Signaturoptionen. ACS unterstützt symmetrische und asymmetrische Signaturen für JWT-Token. Die Ansprüche, die immer in ACS-ausgestellten JWT-Token vorhanden sind, werden in der folgenden Tabelle angezeigt.
| Anspruch | Von JWT verwendeter Anspruchstyp | BESCHREIBUNG |
|---|---|---|
Issuer (Aussteller) |
iss |
Eine Darstellung des Access Control Namespace, der das Token ausgestellt hat. Das Muster für diesen Wert ist https://< namespace.accesscontrol.windows.net/> |
Zielgruppe |
aud |
Der Wert des Bereichs, der zum Anfordern des Tokens verwendet wird. Dieser Wert wird zum Identifizieren des beabsichtigten Empfängers des Tokens verwendet. |
Nicht vor |
nbf |
Die Epochenzeit, vor der das Token nicht gültig ist. |
Ablauf |
exp |
Die Epochenzeit, nach der das Token abläuft. |
Die folgenden Algorithmen werden für JWT-Token unterstützt:
| Algorithmusbezeichner im JWT-Header | BESCHREIBUNG |
|---|---|
HS256 |
HMAC mit dem SHA-256-Hashalgorithmus. Für das Signieren von JWT mit einem symmetrischen Schlüssel . |
RS256 |
RSA mit dem SHA-256-Hashalgorithmus. Zum Signieren von JWT mit einem asymmetrischen Schlüssel mithilfe eines x509-Zertifikats. |
Das folgende Beispiel zeigt ein JWT-Token:
eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJhdWQiOiJodHRwczovL2NvbnRvc28uY29tL3JlbHlpbmdwYXJ0eSIsImlzcyI6Imh0dHBzOi8vY29udG9zby5hY2Nlc3Njb250cm9sLndpbmRvd3MubmV0LyIsIm5iZiI6MTMzNjA2NzMzOCwiZXhwIjoxMzM2MDcwOTM4LCJuYW1laWQiOiJjbGllbnRBcHAiLCJpZGVudGl0eXByb3ZpZGVyIjoiY29udG9zby5jb20ifQ._3dZQ6cmmFgrZ_-VmOLrr7CHne3Xdko_WtE6-Je5Ihw.
JWT besteht aus Segmenten, die mithilfe von "." getrennt werden. Die folgende Tabelle zeigt die decodierten Segmente eines JWT-Tokens:
| JWT-Segment | Wert |
|---|---|
JWT-Header |
{"typ":"JWT","alg":"HS256"} |
JWT-Anspruchsgruppe |
{"aud":";"iss":";,"nbf":1336067338,"exp":1336070938,"nameid":"clientApp","identityprovider":https://contoso.com/relyingparty"https://contoso.accesscontrol.windows.net/""contoso.com"} |
Signatur |
_3dZQ6cmmFgrZ_-VmOLrr7CHne3Xdko_WtE6-Je5Ihw |
Ein einzelner Anspruch mit mehreren Werten wird als ein JSON-Array dargestellt. Wenn ein Benutzer z. B. Mitglied mehrerer Rollen ist, wird der Rollenanspruch wie folgt dargestellt:
{
"aud":"https://contoso.com/relyingparty",
"iss":"https://contoso.accesscontrol.windows.net/",
"nbf":1336067338,"exp":1336070938,
"nameid":"frankm",
"identityprovider":"contoso.com",
“role”: [ “admin”, “user” ]
}
ACS-Token und -Protokolle
Wenn ein SAML 2.0, SAML 1.1, SWT, JWT-Token ausgestellt wird, verwendet ACS verschiedene Standardprotokolle, um das Token an eine Webanwendung oder einen Dienst zurückzugeben. ACS unterstützt die folgenden Tokenformat-/Protokollkombinationen:
ACS kann SAML 2.0-Token über die WS-Trust und WS-Federation Protokolle zurückgeben (abhängig vom Protokoll, das in der Tokenanforderung verwendet wird).
ACS kann SAML 1.1-Token über die WS-Federation und die zugehörigen WS-Trust Protokolle zurückgeben (abhängig vom Protokoll, das in der Tokenanforderung verwendet wird).
ACS kann SWT-Token über die WS-Verbund-, WS-Trust- und OAuth-WRAP- oder OAuth 2.0-Protokolle (abhängig vom Protokoll, das in der Tokenanforderung verwendet wird) ausstellen und zurückgeben.
ACS kann JWT-Token über die WS-Verbund-, WS-Trust- und OAuth 2.0-Protokolle ausstellen (abhängig vom Protokoll, das in der Tokenanforderung verwendet wird).