Formatos token suportados em ACS

Artigo
11/09/2015

Atualizado: 19 de junho de 2015

Aplica-se a: Azure

Quando as suas aplicações e serviços web lidam com a autenticação com Microsoft Azure Ative Directory Controlo de Acesso (também conhecido como Serviço de Controlo de Acesso ou ACS), o cliente deve obter um token de segurança emitido pela ACS para iniciar sessão na sua aplicação ou serviço. A ACS pode emitir fichas de segurança nos seguintes formatos:

Linguagem de marcação de afirmação de segurança (SAML) 1.1 e 2.0
Simples token web (SWT)
Ficha web JSON (JWT)

Nota

O ACS pode emitir fichas de segurança em qualquer um dos seguintes formatos. O formato simbólico que a ACS utiliza para uma aplicação ou serviço web é determinado pela configuração da aplicação do partido. Para obter informações sobre a configuração das candidaturas do partido, consulte as Aplicações do Partido De Relying.

Linguagem de marcação de afirmação de segurança (SAML) 1.1 e 2.0

Security Assertion Markup Language (SAML) é o formato mais antigo e comum de tokens em uso hoje para uma única identificação baseada em sign-on (SSO) e baseada em sinistros. A SAML especifica um formato XML, para tokens, bem como protocolos, para a realização de uma aplicação web ou de um serviço web SSO utilizando fichas SAML. Para obter mais informações sobre fichas SAML, consulte especificações SAML (https://go.microsoft.com/fwlink/?LinkID=213719).

Nota

Os tokens SAML 1.1 e SAML 2.0 são amplamente apoiados por várias plataformas de desenvolvimento, incluindo Windows Identity Foundation (https://go.microsoft.com/fwlink/?LinkID=213729).

Segue-se um exemplo de um símbolo 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>

Simples token web (SWT)

Os tokens Simples Web Token (SWT) cumprem a especificação SimpleWebToken. Os tokens SWT são expressos como pares chave/valor codificados por formulários assinados com uma chave criptográfica. A especificação determina a presença de alguns pares chave/valor, mas deixa espaço para pares de chaves/valor específicos da aplicação. As teclas que estão sempre presentes num token SWT emitido pela ACS são mostradas na tabela seguinte.

Chave	Descrição
Emissor	Uma representação do espaço de nome de serviço ACS que emitiu o símbolo. O padrão para este valor é https://< servicenamespace.accesscontrol.windows.net/>.
Audiência	O valor dos usados `applies_to` para pedir o token. Este valor é um HTTP ou HTTPS URI.
Expiraon	O tempo da época sobre o qual o símbolo expira.
HMACSHA256	A assinatura HMACSHA256 de todos os outros pares de chaves/valor. Este par chave/valor é sempre o último par chave/valor no token. A representação codificada por formulários dos outros pares chave/valor (incluindo pedidos específicos de aplicação) é assinada.

Além destes pares chave/valor, o ACS adiciona uma ou mais reclamações a um token antes da emissão. Estas alegações são impulsionadas pela configuração da regra presente na ACS no momento do pedido de token. Todas estas reivindicações têm um tipo e um ou mais valores, onde tanto o tipo como os valores são cordas. Quando uma reclamação contém mais de um valor, os valores são separados pelo caráter vírgula ("""). As reclamações são codificadas como pares chave/valor, exatamente como os pares chave/valor descritos na tabela anterior.

Segue-se um exemplo de um token ACS que contém reclamações representadas como pares chave/valor.

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

Com exceção do par de chaves/valor HMACSHA256, estes pares podem estar em qualquer ordem. O token ACS seguinte é equivalente ao token ACS anterior, com exceção das assinaturas que são diferentes.

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

A tabela seguinte mostra o conteúdo do token com valores descodificados URL.

Origem	Chave	Valor codificado url	Valor descodificado URL
Reclamações definidas pelo utilizador	papel	Administrador%2cUser	Administrador,Utilizador
Reclamações definidas pelo utilizador	nome do cliente	Contoso%20Corporação	Corporação Contoso
Reclamações definidas pelo sistema	Emissor	https%3a%2f%2fmyservice.accesscontrol.windows.net%2f	https://myservice.accesscontrol.windows.net/
	Audiência	http%3a%2f%2flocalhost%2fmyservice	https://localhost/myservice
	Expiraon	1255912922	1255912922
	HMACSHA256	yuVO%2fwc58%2ftYP36%2fDM1mS%2fHr0hswpsGTWwgfvAbpL64%3d	yuVO/wc58/tYP36/DM1mS/Hr0hswpsGTWwgfvAbpL64=

Ficha web JSON (JWT)

O suporte ao token JSON Web (JWT) está a ser adicionado em versão beta, o que significa que pode haver alterações sem aviso prévio.

A implementação acs do formato simbólico JWT segue o projeto 9 da especificação JWT. Para obter mais informações, consulte https://go.microsoft.com/fwlink/?LinkID=253666. Semelhante a fichas SWT, JWT é um formato de token compacto que é adequado para serviços web REST. Ao contrário do formato SWT, o JWT suporta uma variedade de opções de assinatura. A ACS suporta assinaturas simétricas e assimétricas para fichas JWT. As alegações que estão sempre presentes nos tokens JWT emitidos pela ACS são apresentadas no quadro seguinte.

Afirmação	Tipo de reclamação usado JWT	Description
Emissor	iss	Uma representação do Controlo de Acesso espaço de nome que emitiu o símbolo. O padrão para este valor é https://< namespace.accesscontrol.windows.net/>
Audiência	aud	O valor do âmbito utilizado para solicitar o token. Este valor é utilizado para identificar o destinatário pretendido do token.
Não Antes	nbf	O tempo de época antes do qual o símbolo não é válido.
Expiração	exp	O tempo da época sobre o qual o símbolo expira.

Os seguintes algoritmos são suportados para fichas JWT:

Identificador de algoritmo no cabeçalho JWT	Description
HS256	HMAC usando algoritmo de haxixe SHA-256. Para a assinatura do JWT com uma chave simétrica .
RS256	RSA usando algoritmo de haxixe SHA-256. Para a assinatura de uma chave assimétrica jWT, utilize um x509 com certificado.

Aqui está um exemplo de um símbolo JWT:

eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJhdWQiOiJodHRwczovL2NvbnRvc28uY29tL3JlbHlpbmdwYXJ0eSIsImlzcyI6Imh0dHBzOi8vY29udG9zby5hY2Nlc3Njb250cm9sLndpbmRvd3MubmV0LyIsIm5iZiI6MTMzNjA2NzMzOCwiZXhwIjoxMzM2MDcwOTM4LCJuYW1laWQiOiJjbGllbnRBcHAiLCJpZGVudGl0eXByb3ZpZGVyIjoiY29udG9zby5jb20ifQ._3dZQ6cmmFgrZ_-VmOLrr7CHne3Xdko_WtE6-Je5Ihw.

O JWT é composto por segmentos, que são delimitados utilizando '.'. A tabela a seguir mostra os segmentos descodificados de um símbolo JWT:

Segmento JWT	Valor
Cabeçalho JWT	{"typ":"JWT","alg":"HS256"}
Conjunto de reclamações JWT	{"aud":"https://contoso.com/relyingparty""iss":"https://contoso.accesscontrol.windows.net/""nbf":1336067338"exp":1336070938,"nameid":"clientApp","identityprovider":"contoso.com"}
Assinatura	_3dZQ6cmmFgrZ_-VmOLrr7CHne3Xdko_WtE6-Je5Ihw

Uma única reivindicação com múltiplos valores é representada como uma matriz JSON. Por exemplo, se um utilizador for membro de múltiplas funções, a alegação de função aparecerá da seguinte forma:

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

Fichas e Protocolos ACS

Quando um SAML 2.0, SAML 1.1, SWT, JWT token é emitido, a ACS utiliza vários protocolos padrão para devolver o token a uma aplicação ou serviço web. A ACS suporta as seguintes combinações de formato/protocolo simbólico:

A ACS pode emitir e devolver fichas SAML 2.0 ao longo dos protocolos WS-Trust e WS-Federation (dependendo do protocolo utilizado no pedido simbólico).
A ACS pode emitir e devolver fichas SAML 1.1 ao longo da WS-Federation e dos protocolos de WS-Trust relacionados (dependendo do protocolo utilizado no pedido simbólico).
A ACS pode emitir e devolver fichas SWT sobre os protocolos WS-Federation, WS-Trust e OAuth WRAP ou OAuth 2.0 (dependendo do protocolo utilizado no pedido simbólico).
A ACS pode emitir fichas JWT sobre os protocolos WS-Federation, WS-Trust e OAuth 2.0 (dependendo do protocolo utilizado no pedido simbólico).

Consulte também

Conceitos

Arquitetura ACS
Componentes ACS 2.0