In ACS unterstützte Tokenformate

Artikel
11/09/2015

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 `applies_to`, der zum Anfordern des Tokens verwendet wird. Dieser Wert lautet HTTP oder HTTPS URI.
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
Benutzerdefinierte Ansprüche	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).

Weitere Informationen

Konzepte

ACS-Architektur
ACS 2.0-Komponenten

Share via