(0) exportieren Drucken
Alle erweitern

In ACS unterstützte Tokenformate

Veröffentlicht: April 2011

Letzte Aktualisierung: November 2014

Betrifft: Azure

Wenn Ihre Webanwendungen und -dienste die Authentifizierung mit Zugriffssteuerung für Microsoft Azure Active Directory (auch Zugriffssteuerungsdienst oder ACS) verarbeiten, muss der Client ein von ACS ausgestelltes Sicherheitstoken abrufen, damit er sich bei Ihrer Anwendung oder Ihrem Dienst anmelden kann. ACS kann Sicherheitstoken in den folgenden Formaten ausstellen:

noteHinweis
ACS kann Sicherheitstoken in jedem der folgenden Formate ausstellen. Das Tokenformat, das ACS für eine Webanwendung oder einen -dienst verwendet, wird durch die Anwendungskonfiguration der vertrauenden Seite festgelegt. Weitere Informationen zum Konfigurieren von Anwendungen der vertrauenden Seite finden Sie unter Anwendungen der vertrauenden Seite.

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

noteHinweis
SAML 1.1- und SAML 2.0-Token werden von einer Vielzahl von Entwicklerplattformen unterstützt, z. B. von Windows Identity Foundation (http://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>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>

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 von ACS ausgestellten SWT-Token vorhanden sind, werden in der folgenden Tabelle aufgeführt.

 

Key Beschreibung

Issuer

Eine Darstellung des ACS Dienstnamespaces, der das Token ausgestellt hat. Das Muster für diesen Wert lautet https://<Dienstnamespace>.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.

Neben diesen Schlüssel-Wert-Paaren fügt ACS dem Token vor der Ausstellung mindestens einen Anspruch hinzu. Diese Ansprüche werden durch die Regelkonfiguration gesteuert, die in ACS zum Zeitpunkt der Tokenanforderung 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.

Das folgende Beispiel zeigt ein ACS-Token, das als Schlüssel-Wert-Paare dargestellte Ansprüche enthält.

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. Nur die Signaturen unterscheiden sich.

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.

 

Quelle Key URL-codierter Wert URL-decodierter Wert

Benutzerdefinierte Ansprüche

Rolle

Admin%2cUser

Administrator, Benutzer

customerName

Contoso%20Corporation

Contoso Corporation

Systemdefinierte Ansprüche

Issuer

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

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

Zielgruppe

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

http://localhost/MeinDienst

ExpiresOn

1255912922

1255912922

HMACSHA256

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

yuVO/wc58/tYP36/DM1mS/Hr0hswpsGTWwgfvAbpL64=

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 http://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 einem von ACS ausgestellten JWT-Token vorhanden sind, werden in der folgenden Tabelle aufgeführt.

 

Anspruch Von JWT verwendeter Anspruchstyp Beschreibung

Issuer

iss

Eine Darstellung des Namespace für die Zugriffssteuerung, der das Token ausgestellt hat. Das Muster für diesen Wert lautet 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. Zum 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":"https://contoso.com/relyingparty","iss":"https://contoso.accesscontrol.windows.net/","nbf":1336067338,"exp":1336070938,"nameid":"clientApp","identityprovider":"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” ]
}

Wenn ein SAML 2.0-, SAML 1.1-, SWT- oder 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-Verbundprotokolle ausstellen und zurückgeben (abhängig von dem Protokoll, das in der Tokenanforderung verwendet wird).

  • ACS kann SAML 1.1-Token über die WS-Verbund- und die verwandten WS-Trust-Protokolle ausstellen und zurückgeben (abhängig von dem 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 ausstellen und zurückgeben (abhängig von dem Protokoll, das in der Tokenanforderung verwendet wird).

  • ACS kann JWT-Token über die WS-Verbund- WS-Trust- und/oder OAuth 2.0-Protokolle ausstellen (abhängig von dem Protokoll, das in der Tokenanforderung verwendet wird).

Siehe auch

Community-Beiträge

HINZUFÜGEN
Anzeigen:
© 2014 Microsoft