Formatos token suportados em ACS
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 |
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 |
|
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).