FORNECEDOR DE AUTENTICAÇÃO DA
ADMINISTRAÇÃO PÚBLICA PORTUGUESA
VERSÃO 1.2
AGOSTO DE 2011
Índice
1 INTRODUÇÃO.......................................................................................................................................... 4
1.1 ENQUADRAMENTO.................................................................................................................................... 4
1.2 ESTRUTURA DO DOCUMENTO...................................................................................................................... 5
1.3 DEFINIÇÕES.............................................................................................................................................. 6
2 PRINCIPAIS FUNCIONALIDADES..................................................................................................... 7
3 VISÃO GERAL DA SOLUÇÃO.............................................................................................................. 9
4 INTEGRAÇÃO COM O FORNECEDOR DE AUTENTICAÇÃO DO CARTÃO DE CIDADÃO
13
4.1 ENTIDADE NO PAPEL DE UTILIZADORA DA AUTENTICAÇÃO WEB.................................................................... 13
4.2 ENTIDADE NO PAPEL DE FORNECEDOR DE ATRIBUTOS................................................................................... 18
5 UTILIZAÇÃO DA FUNCIONALIDADE DE SINGLE SIGN-ON.................................................. 22
5.1 VERIFICAÇÃO DE AUTENTICAÇÃO PRÉVIA................................................................................................... 23
5.2 LOGOUT PELO PORTAL DA ENTIDADE....................................................................................................... 26
6 UTILIZAÇÃO DE OUTROS CERTIFICADOS.................................................................................. 28
6.1 ATRIBUTOS DISPONÍVEIS........................................................................................................................... 28
6.2 ATRIBUTOS GENÉRICOS............................................................................................................................. 31
7 AUTENTICAÇÃO DE CIDADÃOS COMUNITÁRIOS VIA STORK........................................... 33
7.1 FLUXO DE DADOS.................................................................................................................................... 33
7.2 CONFIGURAÇÕES NECESSÁRIAS.................................................................................................................. 36
7.3 UTILIZAÇÃO DO CLIENTE DE DEMONSTRAÇÃO............................................................................................. 37
8 UTILIZAÇÃO DE ASSINATURAS DIGITAIS................................................................................. 39
9 EXEMPLO DE AUTENTICAÇÃO........................................................................................................ 41
9.1 AUTENTICAÇÃO COM CARTÃO DE CIDADÃO.............................................................................................. 41
9.2 AUTENTICAÇÃO COM OUTROS CERTIFICADOS.............................................................................................. 45
9.3 AUTENTICAÇÃO COM PEDIDO DE ATRIBUTOS GENÉRICOS.............................................................................. 46
10 ESPECIFICAÇÕES TÉCNICAS.......................................................................................................... 48
10.1 CONFIGURAÇÕES................................................................................................................................... 48
©2011 AMA.
2/83
10.2 AUTENTICAÇÃO.................................................................................................................................... 49
10.3 FECHO DE SESSÃO.................................................................................................................................. 75
11 REFERÊNCIAS....................................................................................................................................... 83
©2011 AMA.
3/83
1 INTRODUÇÃO
1.1
Enquadramento
Este documento tem como objectivo apresentar as principais funcionalidades e benefícios do
Fornecedor de Autenticação.
O Fornecedor de Autenticação surge na necessidade de identificação unívoca de um utilizador
portador de um Cartão de Cidadão junto dos sítios Web de cada Entidade, com a obtenção da
respectiva identificação e atributos sectoriais. Cabe a esta solução o processo de autenticação do
Utilizador e o fornecimento dos atributos necessários a que cada Entidade possa efectuar a
identificação do Utilizador.
O Fornecedor de Autenticação em conjunto com o Cartão de Cidadão permite também fazer uso da
funcionalidade de Federação de Identidades da Plataforma de Interoperabilidade da Administração
Pública para a identificação sectorial de um Cidadão. É também responsável pela gestão dos vários
fornecedores de atributos disponíveis e possui uma estreita ligação com a infra-estrutura de chave
pública do Cartão de Cidadão, com o intuito de manter elevados níveis de segurança e privacidade
no processo de autenticação e identificação.
Através do Fornecedor de Autenticação é possível a criação de credenciais comuns a todos os sites
da Administração Pública, assegurando que o Utilizador se necessita de autenticar apenas uma
única vez para executar um ou vários serviços que podem ser iniciadas em portais transversais
(como o Portal do Cidadão ou o Portal da Empresa).
Permite também proceder à autenticação de um utilizador com recursos a outros certificados
digitais que não o Cartão de Cidadão, possibilitando e alargando o leque de autenticação disponível
para as Entidades que pretendam delegar a autenticação nesta componente.
©2011 AMA.
4/83
1.2
Estrutura do documento
O presente documento encontra-se organizado nos seguintes capítulos:
•
Principais Funcionalidades – onde se descreve os principais objectivos e funcionalidades da
solução;
•
Visão Geral da Solução – onde é apresentada de forma sumária, a visão geral da solução,
bem como os diversos actores no fluxo de autenticação de um Utilizador;
•
Integração com o Fornecedor de Autenticação do Cartão de Cidadão – onde se descrevem as
adaptações necessárias à utilização do Fornecedor de Autenticação;
•
Utilização da funcionalidade de Single Sign On – onde é descrito o funcionamento em modo
de sessão, com o Fornecedor de Autenticação;
•
Utilização de outros certificados – descreve a utilização do Fornecedor de Autenticação com
certificados digitais associados à Ordem dos Advogados, Notários ou Solicitadores;
•
Autenticação de cidadãos comunitários via plataforma europeia de identificação electrónica
STORK – onde se descreve as adaptações necessárias à utilização da plataforma de
identificação europeia STORK;
•
Exemplo de assinatura digital – onde se exemplifica a utilização da assinatura electrónica a
usar nos pedidos de autenticação;
•
Exemplo de utilização – demonstrativos da utilização dos processos de autenticação com o
Fornecedor de Autenticação;
•
Especificações Técnicas – onde se encontram as definições técnicas para integração com o
Fornecedor de Autenticação.
©2011 AMA.
5/83
1.3
Definições
•
FA – Fornecedor de Autenticação;
•
Fornecedor de Atributos - Entidade que, com base na identificação unívoca do
Cidadão pode fornecer dados qualificados do mesmo.
•
PI – Plataforma de Interoperabilidade;
•
Identificação sectorial – identificação de um Cidadão numa entidade participativa da
iniciativa do Cartão de Cidadão (e.g. Número de Identificação Fiscal do Cidadão na
entidade Finanças).
•
SSO – Single sign On;
•
STORK – Secure identity across borders linked. Iniciativa europeia de identificação
electrónica transfronteiriça;
©2011 AMA.
6/83
2 PRINCIPAIS FUNCIONALIDADES
Assumindo-se como componente base para autenticação (particularmente com o Cartão de
Cidadão) a nível nacional e internacional, a introdução das funcionalidades do Fornecedor de
Autenticação permitem a normalização do acto de autenticação electrónica para as Entidades que
dela necessitem. Esta autenticação realiza-se com a possibilidade de transmissão de informação
adicional do Utilizador, informação esta que o Utilizador explicitamente autoriza.
As principais funcionalidades e objectivo do Fornecedor de Autenticação são:
•
Identificação sectorial com base no Cartão de Cidadão – Baseado na credenciação do
Cidadão durante a emissão do Cartão de Cidadão, aliado à Federação de Identidades da
Plataforma de Interoperabilidade da Administração Pública, o processo de autenticação no
FA permite a identificação sectorial e segura de um Cidadão;
•
Disponibilização de atributos sectoriais – A utilização do Cartão de Cidadão permite a
obtenção de identificadores (NIF, NISS, NSNS) ou outros atributos sectoriais, através da
utilização da Plataforma de Interoperabilidade;
•
Simplificação do processo de autenticação – O processo de autenticação do Utilizador pode
ser delegado ao FA, que será responsável pela validação de certificados, obtenção de
atributos qualificados, devolvendo o valor dos mesmos à Entidade que solicitou a
autenticação;
•
Normalização do processo de autenticação – Todo o Processo de autenticação é realizado
com os mesmos níveis de segurança e qualidade de serviço, independentemente do
certificado usado na autenticação. Será garantido a utilização da estrutura de chave pública
do Cartão, com recurso à validação OCSP (Online Certificate Status Protocol) dos certificados
de autenticação, sempre que esta se encontre disponível. Será efectuada validação contra
©2011 AMA.
7/83
CRL (Certificate Revogation List) sempre que o OCSP não se encontre tecnicamente
disponível;
•
O Utilizador possui pleno conhecimento e opção sobre os dados a serem fornecidos – O
Utilizador é parte activa na transmissão de atributos às Entidades que os solicitam. Para que
a troca de informação seja realizada, o Utilizador tem que dar a sua confirmação explícita.
Em qualquer altura, o Utilizador pode cancelar o processo de autenticação para a Entidade
requisitante ou consultar o histórico de autenticações realizadas com o FA.
©2011 AMA.
8/83
3 VISÃO GERAL DA SOLUÇÃO
A figura seguinte pretende exemplificar, de forma sumária e transversal, a utilização do Fornecedor
de Autenticação com base num caso de uso de autenticação de um Utilizador junto de uma
entidade.
Entidade – Portal
institucional
Internet
Autenticação
com Cartão de
Cidadão
Portal Web da Entidade
Sistemas de Suporte à Identificação
do Cidadão
Fornecedor de Autenticação
a
Serviços de validação do
Cartão de Cidadão
Fornecedor de
Autenticação
Fornecedor de
dados qualificados A
b
1
4
2
3
Plataforma de
Interoperabilidade
Fornecedor de
Circuito de autenticação
(sobre norma SAML )
Smart Card Reader
dados qualificados B
Interacção entre sistemas
via web browser
Interacção com utilizador
Cidadão Nacional
(c/Cartão da Cidadão)
No diagrama acima identificam-se as seguintes interacções:
1. Utilizador pretende aceder à área privada do portal de uma Entidade, ao qual é necessário
que comprove a sua identidade;
2. Portal da Entidade delega a autenticação e redirecciona o Utilizador para o Fornecedor de
Autenticação, juntamente com um pedido de autenticação assinado digitalmente;
3. Cabe ao FA validar o pedido de autenticação recebido e solicitar a autenticação do
Utilizador com Cartão de Cidadão, através da inserção do PIN. Durante este processo, o FA
efectua as seguintes operações internas:
a) Validação das credenciais do Utilizador com recurso à PKI do Cartão de Cidadão via
OCSP;
©2011 AMA.
9/83
b) Obtenção de atributos que sejam solicitados através dos vários fornecedores de
atributos qualificados, via Plataforma de Interoperabilidade. Este processo pode
incluir a obtenção de dados da Federação de Identidades ou de outras Entidades.
4. A identificação e atributos do Utilizador são validados e assinados digitalmente pelo FA,
que redireccionará o Utilizador de volta ao portal da Entidade original. Cabe à Entidade a
validação e utilização dos mesmos.
Dado que no processo de autenticação poderão ser solicitados mais dados que os presentes na
certificado digital do Cartão de Cidadão (Nome e Número de Identificação Civil), mostra-se
necessário a obtenção destes dados junto de fornecedores de atributos qualificados para o efeito.
Define-se como um Fornecedor de Atributos, uma entidade que possua e disponibilize, de acordo
com a identificação e autorização (explícita ou implícita) do Utilizador, dados qualificados sobre o
mesmo.
A utilização do mecanismo de autenticação centralizada com o Fornecedor de Autenticação permite
também a simplificação do procedimento de autenticação seguinte do mesmo utilizador, quando
interage com diversos portais da Administração Pública. Permite-se assim a autenticação dos
Cidadãos entre sites da Administração Pública (ou Entidades privadas) solicitando apenas uma
única credencial, revalidando a credencial junto do Fornecedor de Autenticação.
Neste contexto, aplicam-se as seguintes etapas e funcionalidades:
•
Primeira Autenticação – O FA irá solicitar a credencial para autenticação e fornecimento de
atributos, devolvendo o resultado ao Portal que a requereu;
•
Revalidação da Autenticação – Caso o Utilizador já se tinha autenticado com sucesso no
Fornecedor de Autenticação, sempre que seja solicitada uma nova autenticação, o
Fornecedor de Autenticação irá simplificar esse processo:
o
Se forem solicitados os mesmos atributos da última autenticação, não será necessária
nova introdução de PIN;
o
Caso sejam pedidos atributos diferentes, então o Fornecedor de Autenticação irá
requisitar ao Utilizador, nova inserção de PIN.
©2011 AMA.
10/83
O Utilizador será sempre informado explicitamente deste processo, necessitando de dar a
sua autorização para a recolha dos atributos;
•
Terminar Sessão (Logout) – Caso o Utilizador já se encontre autenticado e pretenda
terminar a sua sessão, o Fornecedor de Serviço terá de delegar o término de sessão para o
Fornecedor de Autenticação.
De forma a assegurar a autenticação comum entre o Portal do Cidadão (ou outro Portal) e os vários
sites das entidades (onde poderão residir os serviços e formulários electrónicos), as entidades
deverão ainda implementar o mecanismo de SSO descrito na figura seguinte.
PortalEntidde
FornecedordeA
utenticação
Autenticação
comCartãode
C
idadão
Internet
Fornecedor de
Autenticação
Portal W
ebdaEntidade
1
2
4
3
7
6
8
Smart Card Reader
via web browser
5
PortalEntidade
Cidadão
(c/Cartão da Cidadão)
SiteEntidade
Circuito de autenticação
(sobre norma SAML )
Interacção com utilizador
Na figura supra, as mensagens 1 a 4 são similares às indicadas na secção anterior.
As mensagens 5 a 8 têm por objectivo:
5. Portal da Entidade redirecciona para site da Entidade (diferente) com pedido de
autenticação;
6. Site da Entidade revalida credencial electrónica junto do Fornecedor de Autenticação;
©2011 AMA.
11/83
7. Cabe ao Fornecedor de Autenticação reemitir uma credencial específica para o site da
Entidade e caso estejam a ser solicitados diferentes atributos ou atributos adicionais aos
inicialmente disponibilizados, solicitar uma autenticação adicional do Utilizador;
8. Site de Entidade valida a nova credencial e autentica Utilizador (e executa o serviço
electrónico).
©2011 AMA.
12/83
4 INTEGRAÇÃO COM O FORNECEDOR DE AUTENTICAÇÃO DO CARTÃO DE
CIDADÃO
Na utilização do fornecedor de autenticação, as Entidades podem assumir duas vertentes distintas,
decorrente da sua utilização:
•
Agir como utilizadores da autenticação Web – utilização do FA como componente de
autenticação e de obtenção de atributos (de implementação obrigatória no âmbito do
objectivo definido neste documento);
•
Participar como fornecedores de atributos – utilização do FA como entidade que fornece,
de acordo com a autorização do utilizador, dados qualificados sobre o mesmo (de
implementação opcional no âmbito do objectivo definido neste documento – relevante para
disponibilização de atributos do cidadão geridos pelas Entidades).
Os próximos capítulos detalham cada uma destas vertentes.
4.1
Entidade no papel de utilizadora da autenticação web
O formato de dados trocados entre o FA e o Entidades é baseado em SAML v2.0 (Security Assertion
Markup Language), de forma a assegurar a autenticidade e integridade de todas as transacções. A
utilização do SAML HTTP Post Binding associado ao SAML Web Browser SSO Profile permite que a
autenticação seja efectuada tecnicamente pelo browser do Utilizador, sem necessidade de ligação
física entre as Entidades e o FA.
As comunicações entre o Fornecedor de Autenticação e Entidades são efectuadas sobre HTTP em
canal cifrado – Secure Socket Layer (SSL) ou Transport Layer Security(TLS). Esta comunicação é
realizada sobre Internet.
©2011 AMA.
13/83
Pedido de Autenticação
Fornecedor de
Autenticação (FA)
Portal Web do Organismo
Resposta de Autenticação
O Fornecedor de Autenticação responde à Entidade com informação autorizada pelo Utilizador. A
resposta inclui os atributos solicitados no pedido de autenticação. Esta ligação é também efectuada
sobre HTTP em canal cifrado – SSL ou TLS.
A utilização de canais cifrados, associado ao formato específico SAML garante que a troca de dados
seguir as seguintes considerações:
•
Privacidade de dados – a utilização de canais cifrados garante que os dados do Utilizador se
mantêm privados, impedindo a sua visualização por terceiros (ex. Visualização de dados por
sniffer de rede);
•
Integridade de dados – o protocolo SAML, através de assinatura digital nos pedidos e
respostas de autenticação SAML, garante a integridade de dados de modificações não
autorizadas (ex. Ataque por Man-in-the Middle).
De acordo com o descrito no capítulo Visão Geral da Solução, a utilização da autenticação pelo FA é
efectuado somente através de ambiente Web e sobre Internet.
©2011 AMA.
14/83
Entidade – Portal
institucional
Fornecedor de Autenticação
Portal Web da Entidade
1
Internet
Autenticação
com Cartão de
Cidadão
4
Smart Card Reader
via web browser
Fornecedor de
Autenticação
2
3
Circuito de autenticação
(sobre norma SAML )
Interacção com utilizador
Cidadão Nacional
(c/Cartão da Cidadão)
A imagem acima descreve as interacções entre o Portal da Entidade e o Fornecedor de Autenticação,
usando o browser do Utilizador como intermediário.
As adaptações a realizar pela Entidade recaem nos pontos 2 e 4, que correspondem respectivamente
à criação do pedido de autenticação SAML e no consumo da resposta proveniente do FA:
•
Pedido de autenticação - Corresponde ao pedido de identificação por parte da Entidade.
Permite reconhecer a origem do pedido, através da assinatura digital por um certificado
digital x.509v3 associado à Entidade. O pedido contém quais os atributos que devem ser
obtidos (ex. NIF);
•
Resposta de autenticação – contém o resultado da autenticação efectuada pelo FA.
Encontra-se na resposta os atributos solicitados previamente pela Entidade. Esta mensagem
é assinada digitalmente pelo FA de forma a garantir a integridade da informação.
©2011 AMA.
15/83
Nos próximos subcapítulos apresentam-se exemplos de pedidos de autenticação SAML, sendo que
as especificações técnicas detalhadas encontram-se no capítulo 10.
4.1.1 Exemplo de mensagem de pedido de autenticação SAML
A mensagem seguinte exemplifica um pedido de autenticação proveniente do portal da Entidade,
junto do FA, onde é solicitado um atributo, neste caso AttributeName:
<samlp:AuthnRequest
ID="_1e736a31-a41c-4c35-b17f-0f9ab4c741b3"
Version="2.0"
IssueInstant="2011-02-17T11:15:24Z"
Destination="https://autenticacao.cartaodecidadao..ptDefault.aspx"
ProtocolBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"
AssertionConsumerServiceURL="https://www.ServiceProvider.pt/HandleRequest"
ProviderName="Service Provider Name"
xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol">
<saml:Issuer xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">https://www.ServiceProvider.pt</saml:Issuer>
<Signature xmlns="http://www.w3.org/2000/09/xmldsig#">
<SignedInfo>
<CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
<SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>
<Reference URI="#_1e736a31-a41c-4c35-b17f-0f9ab4c741b3">
<Transforms>
<Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>
<Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#">
<InclusiveNamespaces PrefixList="#default samlp saml ds xs xsi"
xmlns="http://www.w3.org/2001/10/xml-exc-c14n#"/>
</Transform>
</Transforms>
<DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
<DigestValue>oypLiC5MkXdKFbs0pA25Z/mt4jk=</DigestValue>
</Reference>
</SignedInfo>
<SignatureValue>...signatureValue...</SignatureValue>
<KeyInfo>
<X509Data>
<X509Certificate>...x509Data...</X509Certificate>
</X509Data>
</KeyInfo>
</Signature>
<samlp:Extensions>
<fa:RequestedAttributes xmlns:fa="http://autenticacao.cartaodecidadao.pt/atributos">
<fa:RequestedAttribute
Name="AttributeName"
NameFormat="urn:oasis:names:tc:SAML:2.0:attrnameformat:uri" isRequired="true"/>
</fa:RequestedAttributes>
</samlp:Extensions>
</samlp:AuthnRequest>
Nota: O elemento de assinatura digital foi retirado para efeitos de simplificação.
4.1.2 Exemplo de mensagem de resposta a pedido de autenticação SAML
A mensagem seguinte exemplifica a resposta a um pedido de autenticação, fornecendo a resposta
ao atributo AttributeName, com o valor AttributeValue:
©2011 AMA.
16/83
<saml2p:Response xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion" xmlns:fa="http://autenticacao.cartaodecidadao.pt/atributos"
xmlns:saml2p="urn:oasis:names:tc:SAML:2.0:protocol" ID="_0314efee-a385-4ca9-afab-4bffbb6a788b" InResponseTo="_1e736a31-a41c-4c35b17f-0f9ab4c741b3" Version="2.0" IssueInstant="2011-02-17T11:17:14.6349444Z"
Destination="https://www.ServiceProvider.pt/HandleResponse" Consent="urn:oasis:names:tc:SAML:2.0:consent:unspecified">
<saml2:Issuer>https://autenticacao.cartaodecidadao.pt</saml2:Issuer>
<Signature xmlns="http://www.w3.org/2000/09/xmldsig#">
<SignedInfo>
<CanonicalizationMethod Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"/>
<SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>
<Reference URI="#_0314efee-a385-4ca9-afab-4bffbb6a788b">
<Transforms>
<Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>
<Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
</Transforms>
<DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
<DigestValue>qqC76JmDP+2i1s0oxY8EsSD4tic=</DigestValue>
</Reference>
</SignedInfo>
<SignatureValue>...signatureValue...</SignatureValue>
<KeyInfo>
<X509Data>
<X509Certificate>...x509Data...</X509Certificate>
</X509Data>
</KeyInfo>
</Signature>
<saml2p:Status>
<saml2p:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success"/>
</saml2p:Status>
<saml2:Assertion Version="2.0" ID="_b1c88f11-50fd-4a22-988e-9ce4573049e0" IssueInstant="2011-02-17T11:17:14.6349444Z">
<saml2:Issuer>https://autenticacao.cartaodecidadao.pt</saml2:Issuer>
<saml2:Subject>
<saml2:NameID Format="urn:oasis:names:tc:SAML:1.1:nameidformat:unspecified">urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified</saml2:NameID>
<saml2:SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">
<saml2:SubjectConfirmationData NotOnOrAfter="2011-02-17T11:22:14Z"
Recipient="https://www.ServiceProvider.pt" InResponseTo="_1e736a31-a41c-4c35-b17f-0f9ab4c741b3" Address="127.0.0.1"/>
</saml2:SubjectConfirmation>
</saml2:Subject>
<saml2:Conditions NotBefore="2011-02-17T11:17:14Z" NotOnOrAfter="2011-02-17T11:22:14Z">
<saml2:AudienceRestriction>
<saml2:Audience>https://www.ServiceProvider.pt</saml2:Audience>
</saml2:AudienceRestriction>
<saml2:OneTimeUse/>
</saml2:Conditions>
<saml2:AuthnStatement AuthnInstant="2011-02-17T11:17:14.6349444Z">
<saml2:AuthnContext/>
</saml2:AuthnStatement>
<saml2:AttributeStatement>
<saml2:Attribute Name="AttributeName" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"
fa:AttributeStatus="Available">
<saml2:AttributeValue xmlns:q1="http://www.w3.org/2001/XMLSchema"
xmlns:d5p1="http://www.w3.org/2001/XMLSchema-instance" d5p1:type="q1:string">AttributeValue</saml2:AttributeValue>
</saml2:Attribute>
</saml2:AttributeStatement>
</saml2:Assertion>
</saml2p:Response>
Nota: O elemento de assinatura digital foi retirado para efeitos de simplificação.
©2011 AMA.
17/83
4.2
Entidade no papel de fornecedor de atributos
Numa fase do fluxo de autenticação, já posterior à verificação da autenticidade do Cartão de
Cidadão, o FA irá obter os atributos necessários para responder ao pedido de autenticação da
Entidade requisitante.
Caso os dados solicitados não se encontrem no certificado público do Cartão de Cidadão (que
contém o Nome e Número de Identificação Civil), o FA irá promover a sua obtenção junto de
Fornecedores de Atributos externos, conforme ilustrado na figura seguinte.
Sistemas de Suporte à Identificação
do Cidadão
Fornecedor de Autenticação
Autenticação
com Cartão de
Cidadão
Fornecedor de
dados qualificados A
b
Fornecedor de
Autenticação
Plataforma de
Interoperabilidade
Fornecedor de
dados qualificados B
Interacção entre sistemas
O pedido de obtenção de um atributo será gerado pelo FA, com o consentimento do Utilizador e
posteriormente enviado ao fornecedor de atributos respectivo. Este pedido materializa-se na
invocação de um serviço electrónico no respectivo Fornecedor de Atributos que contem a seguinte
informação:
•
Número de Pedido – Identificador unívoco do pedido de atributos. Este dado é interno ao
FA e é usado como forma de identificação e localização dos vários pedidos de atributos
realizados;
•
Identificador do Cidadão – O pedido de atributos é acompanhado pelo respectivo
identificador sectorial cifrado, proveniente da Federação de Identidades da Plataforma de
Interoperabilidade. Este assegura a identificação unívoca junto do fornecedor de atributos;
©2011 AMA.
18/83
•
Prestador de Serviços Requerente – Representa o URL como descrição do prestador de
serviços que solicitou originalmente os dados;
•
Data e hora – Identificação temporal da criação do pedido de atributos;
•
Nome do Cidadão – Nome do cidadão sobre a qual os atributos se referem. Este valor é
retirado do certificado público presente no Cartão de Cidadão usado para autenticação;
•
Atributos solicitados – Lista de atributos que são solicitados pelo prestador de serviços e
consentidos pelo Cidadão.
Os atributos são autorizados pelo Utilizador no decorrer do processo de autenticação junto do FA,
cujo pedido aos respectivos fornecedores será assinado digitalmente por este. Com base na
assinatura digital do pedido, os fornecedores de atributos podem comprovar a sua autenticidade e
validade.
Após recepção e validação digital de um pedido de atributos, o respectivo fornecedor deverá
responder a este serviço electrónico, com a seguinte informação:
•
Número de Pedido – Identificador unívoco do pedido de atributos. Este valor será igual ao
Número de Pedido da mensagem original. Serve como elemento de relação e de apoio à
localização dos vários pedidos de atributos realizados;
•
Data e hora – Identificação temporal da criação da resposta ao pedido de atributos;
•
Atributos – Lista de atributos original, com preenchimento dos respectivos valores. A cada
atributo encontra-se associado um estado que identifica o resultado da operação de obtenção
do valor:
o
Disponível – O valor do atributo foi encontrado e devolvido. Este valor é obrigatório
sempre que um atributo é devolvido com valor.
o
Não Disponível – Não foi possível encontrar o valor de atributo para o Utilizador em
causa.
o
Não Permitido – O fornecedor de serviços não permitiu, activamente, a obtenção de
atributos com base no Prestador de Serviços Requerente.
©2011 AMA.
19/83
Devido à utilização de assinatura digital como forma de validação do pedido de atributos, o
conjunto de dados validados desta forma não poderá ser alterado ou adulterado. Por esta razão, os
elementos que foram alvo de validação por assinatura digital não podem ser alterados, nem mesmo
pela Plataforma de Interoperabilidade, o que impossibilita a normalização de dados, vulgo
“mapeamentos”.
4.2.1 Exemplo de mensagem de pedido de Atributos - “FAObterAtributos”
A mensagem seguinte exemplifica um pedido de atributos, neste caso NIC e Nome, realizada pelo
Fornecedor de Autenticação a um Fornecedor de Atributos, via Plataforma de Interoperabilidade.
<fa:FAObterAtributos xmlns:fa="http://autenticacao.cartaodecidadao.pt/servicos"
xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
<fa:IdentificadorCidadao>UjBsR09EbGhjZ0dTQUxNQUFBUUNBRU1tQ1p0dU1GUXhEUzhi</fa:IdentificadorCidadao>
<fa:PedidoAtributos>
<fa:NumeroPedido>ED6F7BBC-1A42-11DF-A5E3-C17D56D89593</fa:NumeroPedido>
<fa:NomeCidadao>José Manuel Silva</fa:NomeCidadao>
<fa:PrestadorServicosRequerente>http://www.portaldocidadao.pt</fa:PrestadorServicosRequerente>
<fa:DataHora>2001-12-17T09:30:47.0Z</fa:DataHora>
<fa:Atributos>
<fa:Atributo
Nome="http://autenticacao.cartaodecidadao.pt/atributos/2010/01/cidadao/NomeCompleto"/>
<fa:Atributo Nome="http://autenticacao.cartaodecidadao.pt/atributos/2010/01/cidadao/NIC"/>
</fa:Atributos>
<ds:Signature xmlns="http://www.w3.org/2000/09/xmldsig#">
(...)
</ds:Signature>
</fa:PedidoAtributos>
</fa:FAObterAtributos>
Nota: O elemento de assinatura digital foi retirado para efeitos de simplificação.
4.2.2 Exemplo de mensagem de resposta a pedido de atributos - “FARespostaObterAtributos”
A mensagem seguinte exemplifica a resposta a um pedido de atributos, neste caso NIC e Nome.
Este serviço será realizado pelo fornecedor de atributos com destino ao Fornecedor de Autenticação,
via Plataforma de Interoperabilidade.
<fa:FARespostaObterAtributos mlns:fa="http://autenticacao.cartaodecidadao.pt/servicos">
<fa:NumeroPedido>ED6F7BBC-1A42-11DF-A5E3-C17D56D89593</fa:NumeroPedido>
<fa:DataHora>2001-12-17T09:30:47.0Z</fa:DataHora>
<fa:Atributos>
<fa:Atributo Nome="http://autenticacao.cartaodecidadao.pt/atributos/2010/01/cidadao/NomeCompleto"
Resultado="Disponivel">José Manuel Silva</fa:Atributo>
<fa:Atributo Nome="http://autenticacao.cartaodecidadao.pt/atributos/2010/01/cidadao/NIC"
Resultado="Disponivel">123456789</fa:Atributo>
</fa:Atributos>
©2011 AMA.
20/83
</fa:FARespostaObterAtributos>
4.2.3 Atributos disponíveis – Cartão de Cidadão
Dado que existem atributos que não se encontram presentes no certificado digital do Cartão de
Cidadão, o FA irá promover a sua obtenção junto dos fornecedores de atributos qualificados
correspondentes.
A listagem seguinte resume os atributos (e respectivos fornecedores) que se encontram disponíveis
no FA, sendo que se prevê a adição de novos atributos brevemente:
Atributo
Identificador
Nome Completo
Apelido
Nome Próprio
Número de Identificação Civil
Número
de
http://interop.gov.pt/MDC/Cid
Cartão de Cidadão
adao//NomeCompleto
(via Certificado Público)
http://interop.gov.pt/MDC/Cid
Cartão de Cidadão
adao//NomeApelido
(via Certificado Público)
http://interop.gov.pt/MDC/Cid
Cartão de Cidadão
adao//NomeProprio
(via Certificado Público)
http://interop.gov.pt/MDC/Cid
Cartão de Cidadão
adao//NIC
(via Certificado Público)
Identificação http://interop.gov.pt/MDC/Cid
Fiscal
Fornecedor de Atributo
adao//NIF
Ministério das Finanças
(via Federação de Identidades)
Número de Identificação na http://interop.gov.pt/MDC/Cid
Ministério da Segurança Social
Segurança Social
(via Federação de Identidades)
adao//NISS
Número de Identificação no http://interop.gov.pt/MDC/Cid
Ministério da Saúde
Serviço Nacional de Saúde
adao//NSNS
(via Federação de Identidades)
Data de Nascimento
http://interop.gov.pt/MDC/Cid
Cartão de Cidadão
adao//DataNascimento
(via Certificado Público)
http://interop.gov.pt/MDC/Cid
Cartão de Cidadão
adao//Nacionalidade
(via Certificado Público)
Nacionalidade
Número
certificado
©2011 AMA.
de
série
do http://interop.gov.pt/MDC/Cid
adao// NumeroSerie
Cartão de Cidadão
(via Certificado Público)
21/83
5 UTILIZAÇÃO DA FUNCIONALIDADE DE SINGLE SIGN-ON
De forma a assegurar a autenticação comum entre o Portal do Cidadão (ou outro Portal) e outros
Portais onde poderão residir os serviços e formulários electrónicos, as Entidades deverão ainda
implementar funcionalidades que permitam a utilização do Cartão de Cidadão como forma de
autenticação simplificada entre sites, numa lógica de single sign-on.
Após correcta autenticação Web por parte do Cidadão, conforme descrito no capítulo 4.1 - Entidade
no papel de utilizadora da autenticação web, o FA manterá internamente, informação de que o
mesmo foi autenticado com sucesso. Torna-se assim possível a aplicação de uma lógica de single
sign-on, demonstrada na figura seguinte:
PortaldoCidadão
FornecedordeA
utenticação
Autenticação
comCartãode
C
idadão
Internet
Fornecedor de
Autenticação
Portal W
ebdaEntidade
1
2
4
3
7
6
8
Smart Card Reader
via web browser
5
SiteEntidade
Cidadão
(c/Cartão da Cidadão)
SiteEntidade
Circuito de autenticação
(sobre norma SAML )
Interacção com utilizador
As mensagens 1 a 4 são similares às indicadas nas secções anteriores, sendo que as restantes têm por
objectivo a validação do mecanismo de SSO. Utiliza-se o Portal do Cidadão como exemplo do Portal
que inicia o fluxo de autenticação:
5. Portal do Cidadão redirecciona para zona de acesso restrito no site da Entidade;
©2011 AMA.
22/83
6. Durante a verificação de permissões de acesso à zona de acesso restrito, o portal da Entidade
deve verificar junto do FA, se o Cidadão já se encontra autenticado com o seu cartão de
Cidadão:
•
Caso se encontre já autenticado, o Portal da Entidade deve redireccionar o utilizador para o
FA de forma automática;
•
Caso não tenha sido previamente autenticado, o Portal da Entidade pode dar a possibilidade
de efectuar login local ou via FA, de acordo com a escolha do Cidadão.
7. O Fornecedor de Autenticação irá validar e reemitir uma credencial específica para o site da
entidade e, opcionalmente, solicitar autenticação adicional do cidadão (e.g., caso estejam a ser
solicitados dados adicionais aos inicialmente disponibilizados);
8. Site de entidade valida credencial e autentica cidadão (e executa serviço electrónico).
Em situações específicas, poderá ser necessário evitar, para efeitos de usabilidade, a exibição da
página de pedido de consentimento do FA ao utilizador. Incluem-se nestes casos, situações onde
haja uma página de um Portal embebida noutro Portal.
De forma a contemplar o caso acima, o Portal que pretende autenticação sem exibir a página de
consentimento,
deve
solicitar
um
atributo
específico
(http://interop.gov.pt/MDC/FA/PassarConsentimento) de forma a garantir que a página não é
exibida.
5.1
Verificação de autenticação prévia
O ponto de verificação a ser realizado pelo Portal da Entidade tem como objectivo facilitar e
melhorar a interface de autenticação entre o Utilizador, o Portal onde o Utilizador se encontra e o
Fornecedor de Autenticação.
Esta verificação deverá ser efectuada pelo Portal da Entidade e consistirá na consulta do retorno
http de uma página alojada no FA. Esta verificação junto do FA deve ser executada sempre que se
encontrem reunidas as seguintes condições:
•
Tentativa de acesso a uma zona restrita do Portal da Entidade;
•
Utilizador não se encontra autenticado no Portal da Entidade.
©2011 AMA.
23/83
Para melhorar a experiência de utilização, aconselha-se que a verificação seja realizada por AJAX.
Esta chamada baseia-se no protocolo Cross-Origin Resource Sharing1 (CORS) sempre que o mesmo
seja suportado pelo browser do cliente. Nas restantes situações deverá ser usado um proxy flash para
garantir a máxima compatibilidade, baseado na biblioteca flXHR2.
O exemplo abaixo demonstra a lógica que deve ser adicionada na zona de acesso restrito no portal
do fornecedor de serviço:
var req;
var flproxy;
var isCors = false;
// Verifica o estado de autenticação junto do FA do Cartão de Cidadão
// Se não possuír sessão no portal da entidade e já se encontrar autenticado no FA,
redirecciona automaticamente para o FA para revalidação da autenticação
function VerifyFASSO() {
//Verifica se utilizador já se encontra autenticado no portal da entidade
if (querySt('IsAuthenticated') == undefined) {
try {
//Verifica utilização da norma CORS
req = new XMLHttpRequest();
if (req && "withCredentials" in req) {
isCors = true;
}
}
catch (e) {
}
if (!isCors) {
//Caso CORS não seja suportado, faz 'fallback' para flXHR
flproxy = new flensed.flXHR({ autoUpdatePlayer: true, instanceId: "myproxy1",
xmlResponseText: false, onreadystatechange: processFlash, noCacheHeader: false });
}
if (isCors && req != null) {
//Usa CORS para efectuar o pedido AJAX
req.open("GET",
"https://autenticacao.teste.cartaodecidadao.gov.pt/FA/IsUserAuthenticated.aspx", true);
req.onreadystatechange = process;
req.withCredentials = "true";
req.send(null);
}
else {
//Caso CORS não seja suportado, faz 'fallback' para flXHR
flproxy.open("GET",
"https://autenticacao.teste.cartaodecidadao.gov.pt/FA/IsUserAuthenticated.aspx");
flproxy.send();
}
}
}
//Processa resposta proveniente do FA, via CORS
function process() {
1
http://www.w3.org/TR/cors/
2
http://flxhr.flensed.com/ - Licenciamento MIT: http://flxhr.flensed.com/license.php
©2011 AMA.
24/83
if (req.readyState == 4) {
if (req.status == 200) {
var response = req.responseText;
if (response == "1") {
//procedimento de redireccionamento automático para o FA;
}
}
}
}
//Processa resposta proveniente do FA, via flXHR
function processFlash(XHRobj) {
if (XHRobj.readyState == 4) {
if (XHRobj.status == 200) {
var response = XHRobj.responseText;
if (response == "1") {
//procedimento de redireccionamento automático para o FA;
}
}
}
}
VerifyFASSO();
Caso o retorno seja o valor 1, significará que o utilizador já se encontra autenticado perante o FA,
devendo o Portal da entidade redireccionar o utilizador para o mesmo, solicitando uma
autenticação. O FA efectuará a gestão e lógica de pedido de PIN, de acordo com as regras definidas:
•
Será pedido um novo PIN, caso os atributos solicitados incluam atributos não solicitados na
última autenticação;
•
Não será pedido PIN caso os atributos sejam iguais ou estejam contidos na última
autenticação.
Caso o retorno seja 0, significará que o Cidadão não se encontra autenticado perante o FA, pelo que
o Portal da entidade poderá seguir a sua lógica de autenticação própria, optando mesmo assim por
autenticação via FA.
Nas situações em que se detecte que o browser do utilizador não suporte Javascript , deverá ficar o
Portal da Entidade agir de acordo com as suas normas internas, sendo que se aconselha a que seja
efectuado um pedido de autenticação ao FA, para emissão (ou revalidação) do pedido de
autenticação.
©2011 AMA.
25/83
5.2
Logout pelo Portal da Entidade
Decorrente da utilização de mecanismo de SSO com o Cartão de Cidadão, o FA disponibiliza um
método que permite que o Portal da entidade desencadeie o logout no FA. O Portal da entidade
necessitará, à semelhança do pedido de autenticação, redireccionar o utilizador para o FA, com
indicação de pedido de logout.
O formato de dados trocados entre o FA e a Entidade é idêntico à usada pela autenticação (ver
capítulo 4.1), a diferença é o formato de SAML que é usado para o efeito, neste caso é usado o
formato de SAML Logout.
Pedido de Logout
Fornecedor de
Autenticação (FA)
Portal Web do Organismo
Resposta de Logout
Tal como no processo de autenticação mantém-se toda a vertente de segurança nas transacções
entre o Portal da Entidade e o Fornecedor de Autenticação.
©2011 AMA.
26/83
PortalE
ntidade
FornecedordeA
utenticação
A
utenticação
comC
artãode
C
idadão
Internet
Fornecedor de
Autenticação
Portal W
ebdaEntidade
1
3
2
via web browser
Cidadão (s/ Cartão de
Cidadão)
Circuito de Logout (sobre
norma SAML)
Interacção com utilizador
A imagem acima descreve as interacções entre o Portal da Entidade e o Fornecedor de Autenticação
num pedido de Logout.
As adaptações a realizar pela Entidade recaem nos pontos 2 e 3, que correspondem respectivamente
à criação do pedido de Logout SAML e no consumo da resposta proveniente do FA:
•
Pedido de Logout - Corresponde ao pedido de identificação por parte da Entidade.
Permitirá reconhecer a origem do pedido, através da assinatura digital por um certificado
digital x.509v3 associado à Entidade;
•
Resposta de Logout – contém o resultado do Logout efectuado pelo FA. Esta mensagem é
assinada digitalmente pelo FA de forma a garantir a integridade da informação.
©2011 AMA.
27/83
6 UTILIZAÇÃO DE OUTROS CERTIFICADOS
Quando o Fornecedor de Serviços requisitar a autenticação ou a obtenção de atributos junto do
Fornecedor de Autenticação, o utilizador terá de apresentar um certificado válido para proceder à
sua autenticação ou recolha de atributos. Todo o mecanismo de autenticação bem como a lógica de
Single Sing On manter-se-ão para estes certificados.
O Fornecedor de Autenticação será também capaz de autenticar um utilizador num Fornecedor de
Serviços com base noutros certificados válidos, como é exemplo o certificado da Ordem dos
Advogados. Nesta vertente o Fornecedor de Autenticação irá proceder à autenticação e obtenção de
atributos do utilizador, de forma idêntica ao que é efectuado com o Cartão de Cidadão.
Quando um Fornecedor de Serviços solicitar atributos terá de especificar quais os atributos e qual o
certificado que o Utilizador deverá fornecer na autenticação Por predefinição será usada a cadeia de
certificação do Cartão de Cidadão.
À data, são aceites os certificados emitidos ou credenciados pelas seguintes entidades:
1
Cartão de Cidadão
2
Ordem dos Advogados
3
Ordem dos Notários
4
Câmara dos Solicitadores
Apenas o Cartão de Cidadão está apto a fazer uso do Fornecedor de Atributos e da Plataforma de
Interoperabilidade, com a obtenção de atributos que não se encontrem no certificado digital.
Outro recurso fornecido pelo FA consiste em pedido de atributos genéricos. Estes atributos podem
ser solicitado pelos Fornecedores de Serviços sem especificar o certificado a usar, ficando o
utilizador responsável pela escolha do certificado para fazer a autenticação.
6.1
Atributos disponíveis
A selecção do certificado a ser usada é da responsabilidade do Portal da Entidade, que deverá
indicar, explicitamente, qual a forma de autenticação que pretende que seja usada no Fornecedor de
Autenticação. Por sua vez, o Fornecedor de Autenticação irá solicitar ao utilizador, a identificação
digital correspondente.
©2011 AMA.
28/83
Na utilização de outros certificados que não os do Cartão de Cidadão encontram-se disponíveis os
atributos específicos descritos nos capítulos seguintes.
De realçar que a utilização de outros certificados que não os do Cartão de Cidadão apenas poderão
obter atributos que se encontrem nesse mesmo certificado, não sendo possível a obtenção de
atributos via Plataforma de Interoperabilidade.
6.1.1 Ordem dos Advogados
Atributos associados ao certificado digital credenciado pela Ordem dos Advogados:
Atributo
Nome Professional
Identificador
http://interop.gov.pt/MDC/Ad
Descrição
Nome Professional
vogado/NomeProfessional
Nome Completo
http://interop.gov.pt/MDC/Ad
Nome completo
vogado/NomeCompleto
Número
de http://interop.gov.pt/MDC/Ad
identificação
Número de identificação na Ordem
vogado/NumeroIdentificacao
profissional
Sociedade
http://interop.gov.pt/MDC/Ad
Sociedade que representa
vogado/NomeSociedade
Número
de http://interop.gov.pt/MDC/Ad
Número de identificação da Sociedade
identificação
da vogado/IdentificacaoSociedade
na Ordem
Sociedade
Correio
electrónico http://interop.gov.pt/MDC/Ad
profissional
vogado/CorreioElectronico
Número de série do http://interop.gov.pt/MDC/Ad
certificado digital
Correio
electrónico
registado
na
Ordem
Número de série do certificado digital
vogado/NumeroSerie
6.1.2 Ordem dos Notários
Atributos associados ao certificado digital credenciado pela Ordem dos Notários:
©2011 AMA.
29/83
Atributo
Identificador
Nome próprio
http://autenticacao.cartaodecid
Descrição
Nome próprio
adao.gov.pt/atributos/notarios/
NomeProprio
Apelido
http://interop.gov.pt/MDC/Not
Apelido
ario/NomeApelido
Nome completo
http://interop.gov.pt/MDC/Not
Nome completo
ario/NomeCompleto
Número
de http://interop.gov.pt/MDC/Not
identificação
Número de identificação profissional
ario/NumeroIdentificacao
na Ordem
http://interop.gov.pt/MDC/Not
Nome do Cartório onde actua
profissional
Nome do cartório
ario/NomeCartorio
Distrito do cartório
http://interop.gov.pt/MDC/Not
Localidade do cartório onde actua
ario/DistritoCartorio
Localidade do cartório
http://interop.gov.pt/MDC/Not
Distrito do cartório onde actua
ario/LocalidadeCartorio
Correio
electrónico http://interop.gov.pt/MDC/Not
profissional
Correio electrónico profissional
ario/CorreioElectronico
Número de série do http://interop.gov.pt/MDC/Not
certificado digital
Número de série do certificado digital
ario/NumeroSerie
6.1.3 Ordem dos Solicitadores
Atributos associados ao certificado digital credenciado pela Ordem dos Solicitadores:
Atributo
Nome completo
Identificador
http://interop.gov.pt/MDC/Soli
Descrição
Nome completo
citador/NomeCompleto
Número
de http://interop.gov.pt/MDC/Soli
identificação
Número de identificação na Ordem
citador/NumeroIdentificacao
profissional
Correio
electrónico http://interop.gov.pt/MDC/Soli
profissional
citador/CorreioElectronico
Número de série do http://interop.gov.pt/MDC/Soli
certificado digital
©2011 AMA.
Correio
electrónico
registado
na
Ordem
Número de série do certificado digital
citador/NumeroSerie
30/83
6.2
Atributos genéricos
O Fornecedor de Autenticação será capaz de fornecer ou autenticar um Utilizador com atributos
genéricos perante um Fornecedor de Serviços. Se existir um pedido por parte do Fornecedor de
Serviços de atributos genéricos, o Fornecedor de Autenticação irá permitir ao utilizador a escolha do
certificado para proceder à recolha desses atributos.
Aquando
da
utilização
de
atributos
genéricos,
o
atributo
"Certificado"
(http://interop.gov.pt/MDC/Generico/Certificado) deve ser indicado no pedido de autenticação pelo
Fornecedor de Serviços. Caso não se encontre presente, o FA irá responder com erro. Este atributo
será devolvido na resposta, com indicação do certificado seleccionado pelo utilizador para efectuar
a autenticação.
A tabela seguinte apresenta os valores disponíveis para utilização no atributo “Certificado”, que
deve ser verificado para identificar qual certificado foi usado pelo utilizador na sua autenticação:
Certificado
Resposta FA
Cartão de Cidadão
Citizen
Advogados
Lawyer
Notários
Notary
Solicitadores
Bailiff
A tabela seguinte mostra os atributos que podem ser fornecidos a partir de qualquer Certificado
seleccionado pelo Utilizador:
Atributo
Nome do utilizador
Identificador
Descrição
http://interop.gov.pt/MDC/Gen
Nome
erico/NomeCompleto
utilizador,
Professional
do
presente
no
certificado digital seleccionado.
Número de identificação
http://interop.gov.pt/MDC/Gen
Número de identificação do
erico/NumeroIdentificacao
utilizador,
presente
no
certificado digital seleccionado.
©2011 AMA.
31/83
Atributo
Número
de
série
Identificador
Descrição
do http://interop.gov.pt/MDC/Gen
certificado
erico/NumeroSerie
Número de série identificativo
do
certificado,
presente
no
certificado digital seleccionado.
Os atributos genéricos serão obtidos de acordo com o certificado digital seleccionado. Este
determina o contexto dos valores destes atributos. Por exemplo, caso seja apresentado um
certificado da Ordem dos Advogados, o atributo genérico “Número de Identificação” levará à
recolha do atributo que corresponde à identificação do utilizador na Ordem dos Advogados.
O quadro seguinte apresenta a correspondência entre atributos genéricos e as entidades
credenciadoras validadas pelo Fornecedor de Autenticação:
Entidade Credenciadora
Atributo
Genérico
Nome
Cartão Cidadão
do Nome Completo
Advogados
Nome Completo
Notários
Solicitadores
Nome Completo
Nome Completo
utilizador
Número
identificação
de Número
de Número da Ordem Número
identificação civil
dos Advogados
Ordem
Notários
da Número
dos Ordem
da
dos
Solicitadores
Número de série Número de série Número de série Número de série Número de série
do certificado
©2011 AMA.
do certificado
do certificado
do certificado
do certificado
32/83
7 AUTENTICAÇÃO DE CIDADÃOS COMUNITÁRIOS VIA STORK
A iniciativa STORK (Secure identity across borders linked) visa a implementação, à escala da União
Europeia, do reconhecimento da identidade electrónica entre os vários Estados-Membros,
permitindo às empresas, aos Cidadãos e aos funcionários das administrações públicas utilizarem as
suas identidades electrónicas nacionais em qualquer estado da União Europeia.
Complementando os sistemas nacionais do Fornecedor de Autenticação do Cartão de Cidadão, a
iniciativa STORK permite a um cidadão identificar-se electronicamente, de um modo seguro, na sua
interacção com Portal de outro Estado-Membro. À laia de exemplo ilustrativo, um estudante poderá
inscrever-se numa universidade estrangeira utilizando a identidade electrónica que lhe tenha sido
atribuída no seu país de origem.
A materialização do Cartão de Cidadão exibe-se como peça de identidade preferencial na
identificação de um Cidadão português. As suas capacidades para permitir a identificação e
autenticação digital, aliado ao respectivo Fornecedor de Autenticação, tornam o Cartão de Cidadão
a forma preferencial de acesso à identidade digital na iniciativa STORK.
Por outro lado, para a realização de determinados serviços electrónicos torna-se imprescindível o
enriquecimento da identidade de um cidadão com dados de identificação pessoal validados (e.g.,
data de nascimento, sexo, morada ou e-mail). Só dessa forma se torna possível a execução de acções
de valor acrescentado para o consumidor de informação e para o Cidadão.
7.1
Fluxo de dados
A utilização da plataforma de identificação europeia STORK requer a utilização de uma
componente adaptadora específica a cada país. Este tem como objectivo a abstracção da
complexidade e especificidade da infra-estrutura de identificação electrónica de cada país, criando
uma rede de confiança entre todas as infra-estruturas de identidade electrónica dos países
participantes na plataforma STORK.
Todas as autenticações efectuadas na plataforma STORK baseiam-se na utilização de um PEPS (Pan
European Proxy Services) específico de cada país. A nível de Portugal, esta componenta é gerida pela
©2011 AMA.
33/83
AMA e possibilita que qualquer portal Português possa ser ligado à rede de identidade electrónica
europeia.
A imagem seguinte exemplifica um processo de autenticação e de obtenção de atributos de um
cidadão comunitário, através da plataforma STORK:
STORK – Outro Estado
Membro
STORK – Componente
nacional
7
Sistemas no âmbito
da Administração
Pública
3
2
a
6
PEPS Estado Membro
(ou outro adaptador )
4
Internet
8
Serviço electrónico
estrangeiro
Serviços de validação do
Cartão de Cidadão
PEPS
Nacional
Autenticação
com Cartão de
Cidadão
Fornecedor de
Identidade
b
Plataforma de
Interoperabilidade
5
1
Circuito de autenticação
(sobre norma SAML )
Interacção entre sistemas
Smart Card Reader
via web browser
Interacção com utilizador
Cidadão Nacional
(c/Cartão da Cidadão)
Encontram-se identificadas as seguintes interacções:
1. Um cidadão pretende aceder a um fornecedor de serviços num portal estrangeiro. O portal
encontra-se no âmbito de confiança da iniciativa STORK;
2. Ao detectar que se trata de um cidadão estrangeiro, o portal redirecciona o pedido de
autenticação para o PEPS específico do país, identificado por Service-PEPS. Este irá, com
base no pedido de autenticação proveniente do Portal, redireccionar o pedido para o PEPS
do país da nacionalidade do Cidadão, identificado como Citizen-PEPS;
©2011 AMA.
34/83
3. O Citizen-PEPS verifica a validade do pedido de autenticação proveniente do Service-PEPS e
redirecciona o utilizador para o Fornecedor de Autenticação da origem do Cidadão;
4. O Fornecedor de Autenticação reconhece o pedido de autenticação proveniente do CitizenPEPS e solicita autenticação electrónica forte ao Cidadão;
5. O Cidadão efectua o processo de autenticação com o seu cartão de identidade electrónica
(Cartão de Cidadão, no caso de se tratar de um Cidadão Português), via o respectivo
Fornecedor de Autenticação;
a. O Fornecedor de Autenticação valida as credenciais do Cidadão com recurso à PKI
respectiva, via OCSP (Online Certificate Status Protocol) ou CRL (Certificate Revokation
List);
b. Possíveis atributos que sejam solicitados (e autorizados pelo Cidadão) são obtidos.
No caso de Portugal, os atributos são obtidos com recurso à Plataforma de
Interoperabilidade Portuguesa.
6. A identidade e atributos obtidos no Fornecedor de Autenticação são assinados digitalmente,
sendo redireccionados para o Citizen-PEPS;
7. Após o fluxo chegar ao Citizen-PEPS, este retorna a resposta de autenticação ao Service-PEPS
que de origem, autenticando o pedido na plataforma STORK. O Service-PEPS valida o
retorno e devolve a resposta ao portal que originou o pedido;
8. O portal que solicitou a autenticação valida a proveniência da resposta, ou seja, do ServicePEPS e retira os valores de identidade e atributos solicitados. É da responsabilidade do
portal efectuar o seu próprio processo de autenticação com base nestes atributos.
A imagem acima que ilustra o fluxo de dados refere-se à autenticação de um Cidadão português
num site estrangeiro. A situação oposta, isto é, de um Cidadão estrangeiro proceder à autenticação
num portal português, seguirá um fluxo de dados igual, diferindo na forma de autenticação
específica a cada país.
Importa referir que a utilização das componentes PEPS (nas vertentes Service ou Citizen) abstrai toda
a complexidade ou especificidade na implementação técnica entre os vários países da iniciativa
STORK.
©2011 AMA.
35/83
7.2
Configurações necessárias
Os portais que pretendam efectuar a autenticação de um cidadão necessitam de estabelecer uma
relação de confiança com o Service-PEPS português. As configurações são necessárias e obrigatórias
entre ambas as partes.
Para configurar um portal nacional junto do Service-PEPS português, é necessárias a seguinte
informação:
1
Chave pública do certificado X.509 que assina o pedido de autenticação SAML, com destino
ao Service-PEPS português;
2
Identificador do portal que requer a autenticação. Este valor é combinado entre o PEPS e o
portal (ex. http://www.portaldocidadao.pt/);
3
Domínio a partir do qual, o portal irá efectuar os pedidos de autenticação (ex.
http://www.portaldocidadao.pt/).
Estes dados devem ser fornecidos à AMA, para que se possa proceder à configuração do portal
junto PEPS português.
O portal deve conter as seguintes configurações:
1. Endereço de envio do pedido SAML para o Service-PEPS:
•
Ambiente de teste: https://eu-id.teste.cartaodecidadao.gov.pt/PEPS/ServiceProvider;
•
Ambiente de produção: https://eu-id.cartaodecidadao.gov.pt/PEPS/ServiceProvider
2. Chave pública do certificado X.509, que assina o SAML proveniente do Service-PEPS
português.
Estes dados serão fornecidos pela AMA, à entidade que gere o portal.
©2011 AMA.
36/83
7.3
Utilização do cliente de demonstração
Para verificar o funcionamento da componente portuguesa da plataforma STORK, encontra-se
disponível um portal de demonstração que pode ser acedido no endereço: https://euid.teste.cartaodecidadao.gov.pt/SP/populateIndexPage.
Adicionalmente, encontra-se disponível abaixo, um componente Java de exemplo, que poderá ser
englobado no portal da entidade, como forma de simplificação à integração com o Service-PEPS
português.
Dem oSP-PT .zip
storkDem oKeys.jks
PT_Cert.zip
Antes de qualquer acção, é necessário garantir a existência dos seguintes pré-requisitos:
•
Tomcat 6;
•
JAVA 6;
•
Maven.
Para instalar o portal de demonstração português, é necessário efectuar os seguintes passos:
•
Entrar na directoria DemoSP;
•
Copiar a keystore em src/main/keystore para uma directoria à escolha;
•
Editar o ficheiro src/main/resources/SignModule_SP.xml e alterar o path da keystore;
•
Alterar os valores relativos ao certificado que irá assinar o SAML (serial number, issuer,
password da chave privada do certificado, ...);
•
Enviar o certificado para ser configurado no PEPS de Certificação;
•
Executar o comando "mvn clean install";
•
Copiar o war target/SP.war para $TOMCAT_HOME/webapps/;
Nota: Foi assumido que o tomcat local funciona porto 8080.
Para testar a instalação, devem ser efectuados os seguintes passos:
•
Abrir a página: http://localhost:8080/SP/;
•
Escolher PT como SP Country e Citizen Country;
•
Escolher os atributos a pedir ao IdP;
•
Carregar no botão Submit;
©2011 AMA.
37/83
•
Carregar no botão Submit.
Para criar um projecto eclipse, de forma a iniciar desenvolvimento, devem ser seguidos os passos:
•
Entrar na directoria DemoSP;
•
Executar o comando "mvn eclipse:eclipse";
•
Importar o projecto no eclipse.
©2011 AMA.
38/83
8 UTILIZAÇÃO DE ASSINATURAS DIGITAIS
A utilização da assinatura digital em XML encontra-se totalmente definida nas normas W3C XML
Signature3. Este capítulo evidencia as principais características que o Fornecedor de Autenticação irá
usar e que podem ser comprovadas em cada pedido de atributos recebido pelas Entidades.
A forma de assinatura será do tipo Enveloped (http://www.w3.org/2000/09/xmldsig#enveloped-
signature), que usará o algoritmo SHA-1 (http://www.w3.org/2000/09/xmldsig#rsa-sha1) como
forma de digest.
É usado RSA como suporte à criação e verificação da assinatura, sendo assumido Exclusive
Canonicalization
[Excl-C14N]
(http://www.w3.org/TR/2001/REC-xml-c14n-20010315)
para
normalização de dados. Não serão usadas outras transformações à excepção da indicação de
Enveloped ou Exclusive Canonicalization.
O elemento X509Data pertencente a KeyInfo conterá informação específica do certificado usado na
assinatura (i.e. uma cópia do certificado) e deverá ser usado para a sua validação.
A mensagem seguinte apresenta um exemplo de uma assinatura digital efectuada sobre a
mensagem FAObterAtributos:
<fa:FAObterAtributos xmlns:fa="http://autenticacao.cartaodecidadao.pt/servicos"
xmlns:ds="http://www.w3.org/2000/09/xmldsig#" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://autenticacao.cartaodecidadao.pt/servicos
C:\DOCUME~1\Administrator\Desktop\CitizenConsent\APINTE~2.XSD">
<fa:IdentificadorCidadao>UjBsR09EbGhjZ0dTQUxNQUFBUUNBRU1tQ1p0dU1GUXhEUzhi</fa:IdentificadorCidadao>
<fa:PedidoAtributos>
<fa:NumeroPedido>ED6F7BBC-1A42-11DF-A5E3-C17D56D89593</fa:NumeroPedido>
<fa:NomeCidadao>José Manuel Silva</fa:NomeCidadao>
<fa:PrestadorServicosRequerente>http://www.portaldocidadao.pt</fa:PrestadorServicosRequerente>
<fa:DataHora>2001-12-17T09:30:47.0Z</fa:DataHora>
<fa:Atributos>
<fa:Atributo
Nome="http://autenticacao.cartaodecidadao.pt/atributos/2010/01/cidadao/NomeCompleto"/>
<fa:Atributo Nome="http://autenticacao.cartaodecidadao.pt/atributos/2010/01/cidadao/NIC"/>
</fa:Atributos>
<ds:Signature xmlns="http://www.w3.org/2000/09/xmldsig#">
<ds:SignedInfo>
<ds:CanonicalizationMethod Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n20010315"/>
<ds:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>
<ds:Reference URI="">
<ds:Transforms>
3
http://www.w3.org/TR/xmldsig-core/
©2011 AMA.
39/83
<ds:Transform
Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>
</ds:Transforms>
<ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
<ds:DigestValue>MWCfrbhhIkxTFAFjWDLz1UsJWUE=</ds:DigestValue>
</ds:Reference>
</ds:SignedInfo>
<ds:SignatureValue>uVaWld4GEO6W9KFuc2O7HRbukJvsxqvIvjWJXi9XQ2n2kHV9DsKa4MPSVGT5rsAlDPe0oHQdhX7aEU+
oyBX8O1vPHh7LwnDp61D53GrtNcQbPbkRBFpobljuX9UCQlhDJnPNkjFe8EJoeO2Geus02JOkZw+Z0zTgWrk9fRhOevI=</ds:S
ignatureValue>
<ds:KeyInfo>
<ds:X509Data>
<ds:X509Certificate>MIIB8zCCAVwgAwIBAgIQgfzbrIjhLL9FobStI2ub3zANCgYJKoZIhvcNCgEBBAUwEzERMA8GA1UEAx
MIVGVzdGUwHhcNCjAwMDEwMTAwMDAwMFoXDQozNjAxMDEwMDAwMDBaMBMxETAPBgNVBAMTCFRlc3RlMIG
fMA0KBgkqhkiG9w0KAQEBBQOBjTCBiQKBgc77IBnz+oluFJUf/7bAybOLHeMz8ITFvqxOBqI/B7rKVweAXjnN5AOrTo5IlkJ
Kezfh6b9Qsg0KZddDf8z0b9uk/2sOGr1pYqsunLLBvw0KhZL1iUA5Icdksw0Kby/jEZfaTJc1uOJj8rnqg84yOlrIqhZ575O6dohQM
TWSv+paWe8CAwEBo0gwRjBEBgNVHQEEPTA7gBCOOHcajwnATYZ0t6w7LVU0oRUwEzERMA8GA1UEAxMIVGVzdGW
CEIH826yI4Sy/RaG0rSNrm98wDQoGCSqGSIb3DQoBAQQFA4GBBL9Qhi6f1Z+/t8oNClwUBcd1FLDRfTdqOJOqtXNwimWK
sdhP4p/pwESGEXYeZG3i36JouhiMlRXlxMafHK6G9zAMzkDL13/fgcrns4pjDyBw779Lt5JpniE136Gaxwg8S6FlpREjdaNfKPqe7
JKAuu9ORDC0pUiUfCHWxCoqNos=</ds:X509Certificate>
</ds:X509Data>
</ds:KeyInfo>
</ds:Signature>
</fa:PedidoAtributos>
</fa:FAObterAtributos>
©2011 AMA.
40/83
9 EXEMPLO DE AUTENTICAÇÃO
As imagens seguintes pretendem demonstrar o funcionamento do Fornecedor de Autenticação nas
várias vertentes de autenticação.
9.1
Autenticação com Cartão de Cidadão
A principal vertente de autenticação consiste na utilização do Cartão de Cidadão. Para efeitos de
demonstração da autenticação, usou-se o Portal do Cidadão como portal de exemplo.
Adicionalmente e de forma opcional, é realçado o funcionamento do mecanismo de SSO, onde o
portal da Entidade necessita de efectuar as devidas adaptações ao seu funcionamento.
De realçar que os pedidos de autenticação de diferentes portais poderão diferenciar nos tipos de
atributos solicitados ao FA.
1. Utilizador pretende aceder à área privada de um portal de uma Entidade, ao qual é necessário
que apresente a sua identidade;
1.1. (Opcional SSO) - Caso o Utilizador seja redireccionado para uma zona de acesso privado, o
portal da Entidade deve efectuar os passos descritos no capítulo 5.1 e, se necessário,
redireccionar o Utilizador para o FA;
©2011 AMA.
41/83
1.1.1.Caso a sessão se mantenha válida, será exibido o ecrã do ponto 6) e não será necessária
a introdução de PIN;
1.1.2.Caso a sessão não se encontre válida, o utilizador continuará o processo de
autenticação normal, de acordo com o ponto 2) .
2. Portal da Entidade delega a autenticação e redirecciona o Cidadão para o Fornecedor de
Autenticação:
3. FA solicita a selecção do certificado de autenticação do Cartão de Utilizador:
©2011 AMA.
42/83
4. Identidade do Utilizador é comprovada pela introdução do PIN:
5. São obtidos os atributos autorizados pelo Utilizador, junto dos respectivos fornecedores:
©2011 AMA.
43/83
6. (Opcional) Dependendo das configurações junto do Fornecedor de Autenticação, poderá ser
solicitada a confirmação para envio dos dados para o portal de destino:
7. Utilizador é redireccionado para o Portal da Entidade original, já autenticado:
©2011 AMA.
44/83
9.2
Autenticação com outros certificados
Caso o Fornecedor de Serviços requisite outro certificado que não o Cartão de Utilizador, o
Fornecedor
de
Autenticação
identifica
na
interface
o
certificado
esperado
para
a
autenticação/obtenção de atributos:
Todo o processo de autenticação é semelhante ao Cartão de Cidadão, descrito no capítulo anterior.
©2011 AMA.
45/83
9.3
Autenticação com pedido de atributos genéricos
Caso um Fornecedor de Serviços requisite atributos genéricos, o Fornecedor de Autenticação irá
apresentar o seguinte ecrã ao utilizador, para que este possa optar pelo certificado pretendido:
Por pré-definição, o Fornecedor de Autenticação apresenta o Cartão de Cidadão. Na imagem abaixo
pode-se ver os certificados suportados pelo Fornecedor de Autenticação, neste caso o utilizador
escolhe o certificado da Ordem dos Advogados:
©2011 AMA.
46/83
Ao escolher o certificado pretendido a página é recarregada com os respectivos campos preenchidos
de acordo com o certificado escolhido:
É possível que alguns atributos genéricos pedidos pelos Fornecedor de Serviços não estejam
disponíveis no certificado escolhido. O Fornecedor de Autenticação identifica esses atributos e
coloca um alerta para o utilizador.
©2011 AMA.
47/83
10 ESPECIFICAÇÕES TÉCNICAS
A troca de dados sobre o FA baseia-se em Security Assertion Markup Language (SAML) para
garantir a autenticidade e privacidade de todas as transacções.
SAML é um padrão XML que permite aos domínios web uma troca de dados de autenticação e
autorização do utilizador de forma segura. Usando SAML, um Fornecedor de Serviços pode
contactar um fornecedor de identidade on-line, para autenticar um utilizador que pretende aceder a
conteúdo protegido.
Além da autenticação do Cartão Cidadão, o FA suporta a autenticação com outros certificados
(Ordem dos Advogados, Notários e Solicitadores). O processo de autenticação é o mesmo usado no
Cartão de Cidadão Português.
O público-alvo deste capítulo são as equipas técnicas que implementam a integração com o
Fornecedor de Autenticação. As interacções entre o Fornecedor de Autenticação e Fornecedor de
Serviço são baseadas em SAML 2.0 e na experiência portuguesa no projecto de identidade
electrónica transfronteiriça STORK (1).
10.1 Configurações
Para que se possa proceder à correcta configuração do portal junto do Fornecedor de Autenticação,
torna-se necessário o fornecimento dos seguintes dados:
•
Chave pública do certificado X.509 que assinará o pedido SAML proveniente do portal;
•
Identificador do portal (ou Issuer) para efeitos de identificação unívoca no pedido SAML
(ex. http://www.portaldocidadao.pt/);
•
Descritivo institucional ou identificador do portal (ou ProviderName) para identificação
textual pelo cidadão, durante a fase de autenticação com Cartão de Cidadão junto do FA (ex.
“Portal do Cidadão”);
©2011 AMA.
48/83
•
Logótipo institucional ou identificador do portal , para identificação visual pelo cidadão,
durante a fase de autenticação com Cartão de Cidadão junto do FA.
Este deve possuir, preferencialmente, as seguintes características:
•
o
Dimensão 195x97px (ou de tamanho proporcional);
o
Formato PNG, JPEG ou GIF;
o
Fundo transparente (preferencialmente).
Endereço Web onde o portal recebe as respostas dos pedidos de logout
A equipa responsável pelo FA fornecerá os dados necessários à integração do portal,
nomeadamente:
•
Chave pública do certificado X.509 , que deverá ser usada para validar e identificar
univocamente as respostas SAML provenientes do Fornecedor de Autenticação;
•
Endereço para recepção de pedidos SAML, para onde devem ser direccionados os pedidos
de autenticação:
10.2
o
Ambiente de teste: https://autenticacao.teste.cartaodecidadao.gov.pt/fa/Default.aspx
o
Ambiente de produção: https://autenticacao.cartaodecidadao.gov.pt/fa/Default.aspx
Autenticação
10.2.1 Fluxo de processo
O pedido de autenticação irá usar SAML 2.0 Authentication Request Protocol de acordo com as
especificações SAML 2.0. As comunicações entre o browser do utilizador e o FA devem ser
efectuadas sobre SSL V3+ ou TLS 1.0+.
Authentication Request
Fornecedor de
Autenticação (FA)
Service Provider (SP)
Authentication Response
©2011 AMA.
49/83
O FA irá responder ao Fornecdor de Serviços, com a informação de autenticação, verificada e
confirmada pelo utilizador. Adicionalmente, o FA irá incluir na resposta, os atributos que foram
solicitados no pedido de autenticação inicial. Esta ligação é também suportada sobre SSL V3+ ou
TLS 1.0+.
O processo seguinte demonstra a perspectiva do utilizador, no acesso a uma área restrita do
Fornecedor de Serviços, com utilização do FA.
O processo de autenticação segue os seguintes passos:
1) Utilizador tenta aceder a área privada, que requer autenticação. O Fornecedor de Serviços
delega a autenticação no FA;
2) Fornecedor de Serviços gera pedido SAML. Este pedido identifica unicamente o Fornecedor
de Serviços perante o FA. Para além dos dados específicos SAML, o pedido inclui o
parâmetro RelayState, que será retornado na resposta, sem qualquer modificação. Este
parâmetro pode e deve ser usado para persistência de estado do Fornecedor de Serviços;
3) O Fornecedor de Serviços redirecciona o utilizador para a página de autenticação do FA,
submetendo o pedido ao motor SAML desta componente;
©2011 AMA.
50/83
4) FA valida o pedido SAML, garantindo que o Fornecedor de Serviços se encontra autorizado
a efectuar o processo de autenticação. São também validados todos os dados pressentes no
pedido SAML, incluindo o timestamp do pedido;
5) FA solicita a autenticação e autorização do utilizador, para a obtenção dos dados dos
atributos solicitados pelo Fornecedor de Serviços. O utilizador tem a possibilidade de
confirmar (ou negar!) alguns ou todos os atributos solicitados pelo Fornecedor de Serviços;
6) FA gera resposta SAML, com identificação e atributos solicitados no pedido de autenticação
e redirecciona o utilizador para o Fornecedor de Serviços;
7) O Fornecedor de Serviços é responsável pela validação e extracção de atributos da resposta
SAML. Deve garantir a correcta interpretação e normalização das credenciais fornecidas pelo
FA para as suas credenciais internas, de forma a permitir o acesso pelo utilizador;
8) Após conclusão de todo o processo com sucesso, é permitido acesso à área restrita.
Todos os dados SAML são assinados digitalmente. A utilização de assinatura digital irá garantir a
privacidade e a correcta identificação de todos os participantes no processo de autenticação.
10.2.1.1 Pedido de autenticação
O modelo de comunicação entre o Fornecedor de Serviços e o FA baseia-se nos protocolos SAML 2.0
profiles and bindings:
•
HTTP Post Binding (1);
•
Web Browser SSO Profile (2) (O FA apenas suporta um conjunto limitado de funcionalidades)
O pedido de autenticação SAML 2.0 é enviado do SP para o FA usando o HTTP POST binding:
<form action="https:// autenticacao.cartaodecidadao.gov.pt/fa/Default..aspx "method="post">
<input type="hidden" name="SAMLRequest” value="[Base64 encodedAuthentication Request]" />
<input type="hidden" name="RelayState" value="State information to be persisted across operation" />
</form>
©2011 AMA.
51/83
Nota: o parâmetro RelayState pode e deve ser usado pelo Fornecedor de Serviços, para persistir uma
referência opaca do estado do Fornecedor de Serviços. Não deve exceder os 80 caracteres e deve
possuir mecanismos próprios de integridade. Se presente, o FA irá devolver o mesmo parâmetro
inalterado ao Fornecedor de Serviços.
10.2.1.2 Resposta de autenticação
O modelo de comunicação entre o SP e o FA baseiam-se nos protocolos SAML 2.0 profiles and
bindings:
•
HTTP Post Binding (1);
•
Web Browser SSO Profile (2) (FA apenas suporta um conjunto limitado de funcionalidades)
A resposta ao de autenticação SAML 2.0 é enviada do FA para o SP usando o HTTP POST binding:
<form action=" https://www.FornecedorDeServiços.xx /validar_resposta"method="post">
<input type="hidden" name="SAMLResponse” value="[Base64 encodedAuthentication Response]" />
<input type="hidden" name="RelayState" value="State information persisted across operation" />
</form>
Nota: o parâmetro RelayState pode e deve ser usado pelo Fornecedor de Serviços, para persistir uma
referência opaca do estado do Fornecedor de Serviços. Não deve exceder os 80 caracteres e deve
possuir mecanismos próprios de integridade. Se presente, o FA irá devolver o mesmo parâmetro
inalterado ao Fornecedor de Serviços.
10.2.2 Pedido de autenticação
A especificação SAML 2.0 para pedido de autenticação será usada para solicitar a autenticação do
Utilizador de qualquer SP.
O elemento estendido <samlp:AuthnRequest> será usado para permitir que os atributos adicionais
possam ser solicitados
no momento da autenticação.
Os
elementos
de
meta dados
<fap:RequestedAttributes> <fa:RequestedAttribute> serão usados para esta finalidade, ou seja, o
transporte de informações complementares necessárias para completar o processo de autenticação
do Fornecedor de Serviços.
10.2.2.1 <samlp:AuthnRequest>
<sequence>
©2011 AMA.
52/83
<element ref="saml:Issuer" minOccurs="0"/>
<element ref="ds:Signature" minOccurs="0"/>
<element ref="samlp:Extensions" minOccurs="0"/>
<element ref="saml:Subject" minOccurs="0"/>
<element ref="samlp:NameIDPolicy" minOccurs="0"/>
<element ref="saml:Conditions" minOccurs="0"/>
<element ref="samlp:RequestedAuthnContext" minOccurs="0"/>
<element ref="samlp:Scoping" minOccurs="0"/>
</sequence>
<attribute name="ID" type="ID" use="required"/>
<attribute name="Version" type="string" use="required"/>
<attribute name="IssueInstant" type="dateTime" use="required"/>
<attribute name="Destination" type="anyURI" use="Opcional"/>
<attribute name="Consent" type="anyURI" use="Opcional"/>
<attribute name="ForceAuthn" type="boolean" use="Opcional"/>
<attribute name="IsPassive" type="boolean" use="Opcional"/>
<attribute name="ProtocolBinding" type="anyURI" use="Opcional"/>
<attribute name="AssertionConsumerServiceIndex" type="unsignedShort"use="Opcional"/>
<attribute name="AssertionConsumerServiceURL" type="anyURI"use="Opcional"/>
<attribute name="AttributeConsumingServiceIndex" type="unsignedShort"use="Opcional"/>
<attribute name="ProviderName" type="string" use="Opcional"/>
Atributo
Obrigatório
Valores
Notas
A definição de ID5 (ver nota de rodapé 4) permite o uso
ID
Obrigatório
Tipo de dados
de UUID6 iniciado ou precedido por um dos caracteres
xs:ID4
permitidos
em(7)
(e.g.
“_0dec26dd-fc3b-47c6-af9d-
1cd38db10c55”)
Version
Obrigatório
IssueInstant
Obrigatório
2.0
Versão SAML
UTC como definido em
http://www.w3.org/TR/xmlschema-2/#dateTime
(ecemplo: 2011-08-09T18:43:09.6882193Z)
Destination
URI indicando o endereço para onde o pedido
Obrigatório
SAMLRequest é enviado.8
urn:oasis:names:t
Consent
Opcional
c:SAML:2.0:cons
ent:unspecified
ForceAuthn
Obrigatório
true
The user must be actively authenticated by the FA
4
Definido em http://www.w3.org/TR/xmlschema-2/#ID, garantindo as proprieades referidas em
http://docs.oasis-open.org/security/saml/v2.0/saml-core-2.0-os.pdf 1.3.4 ID and ID ReferenceValues
5
Definição de ID no protocolo SAML em http://www.w3.org/TR/xmlschema-2/#ID e
http://www.w3.org/TR/1999/REC-xml-names-19990114/#NT-NCName
Internet Engeneering Task Force RFC4112 (http://www.ietf.org/rfc/rfc4122.txt)
http://www.w3.org/TR/REC-xml/#NT-Lette
http://docs.oasis-open.org/security/saml/v2.0/saml-core-2.0-os.pdf
3.2.1
Complex
Type
RequestAbstractType
6
7
8
©2011 AMA.
53/83
Atributo
Obrigatório
IsPassive
Obrigatório
ProtocolBindin
g
Valores
Notas
False
Passive authentication is not permitted
urn:oasis:names:t
Obrigatório
c:SAML:2.0:bindi
Currently only HTTP-Post binding is supported
ngs:HTTP-POST
AssertionCons
umerServiceIn
Não usado
dex
AssertionCons
umerServiceU
Obrigatório
RL
AttributeCons
umingServiceI
Não usado
ndex
This is unsupported and its use will result in an
urn:oasis:names:tc:SAML:2.0:status:RequestUnsupported
URL to which Authentication Response must be sent.
This must be via a secure SSL connection i.e. Https
This is unsupported and its use will result in an
urn:oasis:names:tc:SAML:2.0:status:RequestUnsupported
Human readable name of the original service provider
ProviderName
Obrigatório
requesting the authentication. This value will be mutually
agreed in the connection proposal phase between the SP
and the FA.9
10.2.2.2 <samlp:issuer>
<element name="Issuer" type="saml:NameIDType"/>
<complexType name="NameIDType">
<simpleContent>
<extension base="string">
<attributeGroup ref="saml:IDNameQualifiers"/>
<attribute name="Format" type="anyURI" use="Opcional"/>
<attribute name="SPProvidedID" type="string" use="Opcional"/>
</extension>
</simpleContent>
</complexType>
Obrigatoriedade: Obrigatório
O elemento <Issuer> contém um URI que identifica o Fornecedor de Serviços e deve ser mutuamente
acordada com o FA.
9
http://docs.oasis-open.org/security/saml/v2.0/saml-core-2.0-os.pdf
RequestAbstractType
©2011 AMA.
3.2.1
Complex
Type
54/83
Atributo
Obrigatório
NameQualifier
Não usado
SPNameQualif
ier
Não usado
Valores
Notas
The security domain that qualifies that name.
2.0
Qualifying the name with a name of a service provider.
URI representing the classification of the identifier.
Format
Opcional
Default
is
urn:oasis:names:tc:SAML:2.0:nameid-
format:entity.
SPProvidedID
Name identifier if different from the name in the contents
Não usado
of the element.
10.2.2.3 <ds:signature>
Obrigatoriedade: Obrigatório
A assinatura digital XML autentica o Fornecedor de Serviços e garante a integridade da mensagem
(sobre todo o pedido de autenticação). A assinatura deve ser uma enveloped signature e aplicada ao
elemento <samlp:AuthnRequest> e todos os seus filhos.
A assinatura deve conter um único elemento <ds:Reference> contendo o valor do atributo ID do
elemento
<samlp:AuthnRequest>.
<ds:Signature>
encontra-se
definida
em
http://www.w3.org/TR/xmldsig-core/#sec-Reference. O valor do atributo URI em <ds:Reference>
terá que conter o mesmo valor do ID do documento em < samlp:AuthnRequest>, procedido do
carácter ‘#’10 (e.g. <Reference URI="#_2e19be9c-37bc-475c-93fd-b05e1970ba4d">…)
10.2.2.4 <samlp:extensions>
Obrigatoriedade: Obrigatório
Este elemento contém uma extensão para o padrão SAML 2.0 pedido de autenticação. No FA essas
extensões incluem:
•
Todos
Um elemento <RequestedAttributes> opcional para permitir o pedido de atributos adicionais;
os
atributos
estendido
no
FA
serão
identificados
no
âmbito
do
namespace
http://autenticacao.cartaodecidadao.pt/atributos.
10
http://docs.oasis-open.org/security/saml/v2.0/saml-core-2.0-os.pdf - 5.4.2 References
©2011 AMA.
55/83
10.2.2.4.1 <fap:RequestedAttributes>
Obrigatoriedade: Opcional
Este elemento contém zero ou mais <fa:RequestedAttribute>. Permite solicitar ao FA atributos
adicionais a serem adicionados à resposta de autenticação.
10.2.2.4.1.1 < fa:RequestedAttribute>
<complexType name="RequestedAttributeType">
<sequence>
<element ref="saml:AttributeValue" minOccurs="0" maxOccurs="unbounded"/>
</sequence>
<attribute name="Name" type="string" use="required"/>
<attribute name="NameFormat" type="anyURI" use="Opcional"/>
<attribute name="FriendlyName" type="string" use="Opcional"/>
<anyAttribute namespace="##other" processContents="lax"/>
<attribute name="isRequired" type="boolean" use="Opcional"/>
</complexType>
Obrigatoriedade: Opcional
Um elemento <fa:RequestedAttribute> é necessário para cada atributo solicitado ao FA no decurso de
uma autenticação.
Atributo
Name
NameFormat
Obrigatório
Valores
Obrigatóri
Notas
Agreed name of attribute required
o
Obrigatóri
Agreed format of attribute required
o
A friendly name for the attribute that can be displayed to
FriendlyName
Opcional
a user e.g. when requesting confirmation to send to SP.
The friendly name should be in Portuguese.
isRequired
Opcional
boolean value
Indicates if the attribute is Obrigatório for the SP
authentication purpose.
10.2.2.4.1.2 <saml:AttributeValue>
Obrigatoriedade: Opcional
©2011 AMA.
56/83
O elemento <saml:AttributeValue> permite que o SP indique que o atributo pedido deve ter um dos
valores especificados ou seja, retornar apenas este atributo se o valor deste atributo é um dos
valores solicitados.
10.2.2.5 <saml:Subject>
Obrigatoriedade: Não usado
10.2.2.6 <saml:NameIdPolicy>
<element name="NameIDPolicy" type="samlp:NameIDPolicyType"/>
<complexType name="NameIDPolicyType">
<attribute name="Format" type="anyURI" use="Opcional"/>
<attribute name="SPNameQualifier" type="string" use="Opcional"/>
<attribute name="AllowCreate" type="boolean" use="Opcional"/>
</complexType>
Obrigatoriedade: Opcional
Pedidos de formatos específicos e qualificação para o identificador que representa o sujeito - Nota: o
<NameIdPolicy> na resposta pode não ter os formatos específicos solicitados e qualificadores.
Atributo
Obrigatório
Valores
Notas
A URI defining the requested format of the NameId in
the Response.
Format
Não usado
FA will not use NameId to contain the user’s eId, it will
be a separate attribute.
SPNameQualif
ier
AllowCreate
Não usado
Não usado
Requests that the assertion’s subject identifier be returned
in the namespace other than the requestor’s.
Allows the SAML responder to create a new identifier for
the subject.
10.2.2.7 <saml:Conditions>
Obrigatoriedade: Não usado
©2011 AMA.
57/83
10.2.2.8 <samlp:RequestedAuthnContext>
Obrigatoriedade: Não usado
10.2.2.9 <samlp:Scoping>
Obrigatoriedade: Não usado
10.2.2.9.1 <samlp:IDPList>
Obrigatoriedade: Não usado
10.2.2.9.2 <samlp:RequesterID>
Obrigatoriedade: Não usado
10.2.2.10
Exemplo de pedido de autenticação
<samlp:AuthnRequest
ID="_1e736a31-a41c-4c35-b17f-0f9ab4c741b3"
Version="2.0"
IssueInstant="2011-02-17T11:15:24Z"
Destination="https://autenticacao.cartaodecidadao.gov.pt/fa/default.aspx"
ProtocolBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"
AssertionConsumerServiceURL="https://www.ServiceProvider.pt/HandleRequest"
ProviderName="Service Provider Name"
xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol">
<saml:Issuer
xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">https://www.ServiceProvider.pt</saml:Issuer>
<Signature xmlns="http://www.w3.org/2000/09/xmldsig#">
<SignedInfo>
<CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
<SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>
<Reference URI="#_1e736a31-a41c-4c35-b17f-0f9ab4c741b3">
<Transforms>
<Transform Algorithm="http://www.w3.org/2000/09/xmldsig#envelopedsignature"/>
<Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#">
<InclusiveNamespaces PrefixList="#default samlp saml ds xs
xsi" xmlns="http://www.w3.org/2001/10/xml-exc-c14n#"/>
</Transform>
</Transforms>
<DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
<DigestValue>oypLiC5MkXdKFbs0pA25Z/mt4jk=</DigestValue>
</Reference>
</SignedInfo>
<SignatureValue>...signatureValue...</SignatureValue>
<KeyInfo>
©2011 AMA.
58/83
<X509Data>
<X509Certificate>...x509Data...</X509Certificate>
</X509Data>
</KeyInfo>
</Signature>
<samlp:Extensions>
<fa:RequestedAttributes xmlns:fa="http://autenticacao.cartaodecidadao.pt/atributos">
<fa:RequestedAttribute
Name="
http://interop.gov.pt/MDC/Cidadao/NomeCompleto"
NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri" isRequired="true"/>
</fa:RequestedAttributes>
</samlp:Extensions>
</samlp:AuthnRequest>
10.2.3 Resposta de autenticação
<sequence>
<element ref="saml:Issuer" minOccurs="0"/>
<element ref="ds:Signature" minOccurs="0"/>
<element ref="samlp:Extensions" minOccurs="0"/>
<element ref="samlp:Status"/>
<choice minOccurs="0" maxOccurs="unbounded">
<element ref="saml:Assertion"/>
<element ref="saml:EncryptedAssertion"/>
</choice>
</sequence>
<attribute name="ID" type="ID" use="required"/>
<attribute name="InResponseTo" type="NCName" use="Opcional"/>
<attribute name="Version" type="string" use="required"/>
<attribute name="IssueInstant" type="dateTime" use="required"/>
<attribute name="Destination" type="anyURI" use="Opcional"/>
<attribute name="Consent" type="anyURI" use="Opcional"/>
Obrigatoriedade: Obrigatório
Atributo
Obrigatório
Valores
Notas
A definição de ID12 (ver nota de rodapé 4) permite o uso
ID
Obrigatório
Tipo de dados
de UUID13 iniciado ou precedido por um dos caracteres
xs:ID11
permitidos
em(14)
(e.g. “_0dec26dd-fc3b-47c6-af9d-
1cd38db10c55”)
InResponseTo
Obrigatório
The identifier (ID) of the request this response refers to.
11
Definido em http://www.w3.org/TR/xmlschema-2/#ID, garantindo as proprieades referidas em
http://docs.oasis-open.org/security/saml/v2.0/saml-core-2.0-os.pdf 1.3.4 ID and ID ReferenceValues
12
Definição de ID no protocolo SAML em http://www.w3.org/TR/xmlschema-2/#ID
http://www.w3.org/TR/1999/REC-xml-names-19990114/#NT-NCName
Internet Engeneering Task Force RFC4112 (http://www.ietf.org/rfc/rfc4122.txt)
http://www.w3.org/TR/REC-xml/#NT-Lette
13
14
©2011 AMA.
e
59/83
Atributo
Obrigatório
Version
Obrigatório
IssueInstant
Obrigatório
Valores
Notas
2.0
UTC Date & time when the response was issued.
URI reference of the SP SAML Response processor this
Destination
response is being sent to. Should be the same as
Obrigatório
AssertionConsumerServiceURL
in
the
associated
Authentication Request.
urn:oasis:names:t
c:SAML:2.0:cons
ent:obtained
urn:oasis:names:t
c:SAML:2.0:cons
ent:prior
urn:oasis:names:t
c:SAML:2.0:cons
Consent
Opcional
ent:curentimplicit
Defines the type of user consent obtained from the user
for this authentication and data transfer.
urn:oasis:names:t
c:SAML:2.0:cons
ent:curentexplicit
urn:oasis:names:t
c:SAML:2.0:cons
ent:unspecified
10.2.3.1 <saml:Issuer>
<element name="Issuer" type="saml:NameIDType"/>
<complexType name="NameIDType">
<simpleContent>
<extension base="string">
<attributeGroup ref="saml:IDNameQualifiers"/>
<attribute name="Format" type="anyURI" use="Opcional"/>
<attribute name="SPProvidedID" type="string" use="Opcional"/>
</extension>
</simpleContent></complexType>
©2011 AMA.
60/83
Obrigatoriedade: Obrigatório
O elemento <Issuer> contém um URI que identifica o SP e deve ser mutuamente acordada com o FA.
Atributo
Obrigatório
NameQualifier
Não usado
The security domain that qualifies that name.
Não usado
Qualifying the name with a name of a service provider.
SPNameQualif
ier
Format
SPProvidedID
Opcional
Valores
Notas
urn:oasis:names:t
URI representing the classification of the identifier.
c:SAML:2.0:name
Default
idformat:entity
format:entity.
Não usado
is
urn:oasis:names:tc:SAML:2.0:nameid-
Name identifier if different from the name in the contents
of the element.
10.2.3.2 <ds:Signature>
Obrigatoriedade: Não usado
10.2.3.3 <samlp:Extensions>
Obrigatoriedade: Não usado
10.2.3.4 <samlp:Status>
<element name="Status" type="samlp:StatusType"/>
<complexType name="StatusType">
<sequence>
<element ref="samlp:StatusCode"/>
<element ref="samlp:StatusMessage" minOccurs="0"/>
<element ref="samlp:StatusDetail" minOccurs="0"/>
</sequence>
</complexType>
<element name="StatusCode" type="samlp:StatusCodeType"/>
<complexType name="StatusCodeType">
<sequence>
<element ref="samlp:StatusCode" minOccurs="0"/>
</sequence>
<attribute name="Value" type="anyURI" use="required"/>
</complexType>
<element name="StatusMessage" type="string"/>
<element name="StatusDetail" type="samlp:StatusDetailType"/>
<complexType name="StatusDetailType">
<sequence>
<any namespace="##any" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>
</sequence>
©2011 AMA.
61/83
</complexType>
Obrigatoriedade: Obrigatório
10.2.3.4.1 <samlp:StatusCode>
Obrigatoriedade: Obrigatório
Atributo
Obrigatório
Valores
Notas
Values of section
value
Obrigatório
3.2.2.2 in (OASIS
Consortium,
A URI reference representing the status code value.
2005)
Especifica um conjunto de códigos de estado opcional e um valor de atributo que representa o
estado do Pedido de Autenticação.
Uma lista de códigos de estados são definidos pela OASIS em SAML 2.0 e estes serão adoptadas
sempre que pertinente. Adicionalmente são usados códigos para situações específicas FA.
O código de status será composto de dois elementos:
•
Código de primeiro nível, indicando o estado da operação de autenticação. Este estado é
incluído como um URI no atributo "Valor" do elemento <samlp:StatusCode>:
•
Um código de status subordinado que fornece informações mais específicas sobre uma
condição de erro. Este estado é incluído como um elemento filho <samlp:StatusCode>.
O estado de primeiro nível é Obrigatório. O código de estrado subordinado também é obrigatório,
se o erro produzido durante a operação de FA é coberta por um dos códigos de estado subordinado
a seguir definidos. Caso contrário é opcional.
Os valores para os dois níveis de códigos de estado estão listadas abaixo. Para mais informações,
consulte a especificação SAML 2.0 (OASIS Consortium, 2005).
a) Estados de primeiro nível:
a. urn:oasis:names:tc:SAML:2.0:status:Success – Efectuado com sucesso..
©2011 AMA.
62/83
b. urn:oasis:names:tc:SAML:2.0:status:Requester – Operação não efectuada, devido a uma
falha do SP.
c. urn:oasis:names:tc:SAML:2.0:status:Responder - Operação não efectuada, devido a uma
falha por parte do FA.
b) Estados subordinados:
a. urn:oasis:names:tc:SAML:2.0:status:AuthnFailed – Autenticação do utilizador falhou /
não foi realizada com sucesso.
b. urn:oasis:names:tc:SAML:2.0:status:InvalidAttrNameOrValue – Valor ou conteúdo
inválido no pedido de atributos associados aos elementos <saml:Attribute>
ou<saml:AttributeValue>.
c. urn:oasis:names:tc:SAML:2.0:status:RequestDenied – O FA encontra-se funcional, mas
optou por não responder ao pedido de autenticação. Este código pode ser usado
sempre que existe uma falha em validações de segurança associadas ao pedido
SAML ou ao próprio SP.
10.2.3.4.2 <samlp:Status-Message>
Obrigatoriedade: Opcional
Explica o valor de estado em termos perceptíveis. A tabela abaixo define as mensagens de estado
em Português (e Inglês para o contexto).
Se o código de estado subordinado é incluído na resposta, então a mensagem de estado deve ser o
correspondente ao código de estado subordinado, e não o código de estado de primeiro nível.
Código Retorno
urn:oasis:names:tc:SAML:2.0:statu
s:Success
Mensagem (PT)
Mensagem (EN)
-
-
O
ser
The request could not be performed
urn:oasis:names:tc:SAML:2.0:statu
executado devido a um erro no
due to an error on the SAML
s:Requester
pedido SAML proveniente do
requester side (SP) identified by its
SP, identificado pelo seu URI
URI.
©2011 AMA.
pedido
não
pode
63/83
Código Retorno
Mensagem (PT)
O
pedido
não
Mensagem (EN)
ser
The request could not be performed
urn:oasis:names:tc:SAML:2.0:statu
executado devido a um erro no
due to an error on the SAML
s:Responder
pedido
responder side (FA) identified by its
SAML
pode
no
FA,
identificado pelo seu URI
URI.
urn:oasis:names:tc:SAML:2.0:statu
Não foi possível autenticar o
It
s:AuthnFailed
Cidadão (ou Utilizador)
authenticate the user
Conteúdo
inválido
ou
não
urn:oasis:names:tc:SAML:2.0:statu
esperado
nos
elementos
s:InvalidAttrNameOrValue
<saml:Attribute>
ou
urn:oasis:names:tc:SAML:2.0:statu
s:RequestDenied
was
unable
to
successfully
Unexpected or invalid content was
encountered
within
<saml:Attribute>
a
or
<saml:AttributeValue>
<saml:AttributeValue> element
O pedido não foi processado
The request has not been processed.
10.2.3.4.3 <samlp:Status-Detail>
Obrigatoriedade: Não usado
10.2.3.5 <saml:Assertion>
Obrigatoriedade: Obrigatório
A resposta de uma autenticação SAML deve conter o elemento <Assertion>.. O elemento <Assertion>
conterá um único elemento <Subject> indicando ao Utilizador qual a <Assertion> que o relaciona. Irá
também conter um único elemento <AuthnStatement > contendo os resultados da autenticação de
Utilizador e um único elemento <AttributeStatement> contendo zero ou mais elementos <attribute>.
Uma descrição detalhada do elemento <Assertion> é dada na secção abaixo.
10.2.3.6 <saml:EncryptedAssertion>
Obrigatoriedade: Não usado
O FA não implementa asserções cifradas, dado que se baseia no canal cifrado suportado sobre SSL
V3+ ou TLS v1.0+.
©2011 AMA.
64/83
10.2.3.7 Exemplo de resposta de autenticação
<saml2p:Response
xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion"
xmlns:fa="http://autenticacao.cartaodecidadao.pt/atributos"
xmlns:saml2p="urn:oasis:names:tc:SAML:2.0:protocol"
ID="_0314efee-a385-4ca9-afab-4bffbb6a788b"
InResponseTo="_1e736a31-a41c-4c35-b17f-0f9ab4c741b3"
Version="2.0"
IssueInstant="2011-02-17T11:17:14.6349444Z"
Destination="https://www.ServiceProvider.pt/HandleResponse"
Consent="urn:oasis:names:tc:SAML:2.0:consent:unspecified">
<saml2:Issuer>https://autenticacao.cartaodecidadao.pt</saml2:Issuer>
<Signature xmlns="http://www.w3.org/2000/09/xmldsig#">
<SignedInfo>
<CanonicalizationMethod Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"/>
<SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>
<Reference URI="#_0314efee-a385-4ca9-afab-4bffbb6a788b">
<Transforms>
<Transform
Algorithm="http://www.w3.org/2000/09/xmldsig#envelopedsignature"/>
<Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
</Transforms>
<DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
<DigestValue>qqC76JmDP+2i1s0oxY8EsSD4tic=</DigestValue>
</Reference>
</SignedInfo>
<SignatureValue>...signatureValue...</SignatureValue>
<KeyInfo>
<X509Data>
<X509Certificate>...x509Data...</X509Certificate>
</X509Data>
</KeyInfo>
</Signature>
<saml2p:Status>
<saml2p:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success"/>
</saml2p:Status>
<saml2:Assertion
Version="2.0"
ID="_b1c88f11-50fd-4a22-988e-9ce4573049e0"
IssueInstant="2011-0217T11:17:14.6349444Z">
…
</saml2:Assertion>
</saml2p:Response>
10.2.4 SAML Assertion
Uma asserção SAML é um pacote de informações de segurança. Especifica que essa afirmação foi
emitida por uma entidade num determinado momento e atesta a identidade da entidade da mesma,
desde que as condições especificadas de validação tenham sido satisfeitas.
©2011 AMA.
65/83
10.2.4.1 <saml:Assertion>
<element name="Assertion" type="saml:AssertionType"/>
<complexType name="AssertionType">
<sequence>
<element ref="saml:Issuer"/>
<element ref="ds:Signature" minOccurs="0"/>
<element ref="saml:Subject" minOccurs="0"/>
<element ref="saml:Conditions" minOccurs="0"/>
<element ref="saml:Advice" minOccurs="0"/>
<choice minOccurs="0" maxOccurs="unbounded">
<element ref="saml:Statement"/>
<element ref="saml:AuthnStatement"/>
<element ref="saml:AuthzDecisionStatement"/>
<element ref="saml:AttributeStatement"/>
</choice>
</sequence>
<attribute name="Version" type="string" use="required"/>
<attribute name="ID" type="ID" use="required"/>
<attribute name="IssueInstant" type="dateTime" use="required"/>
</complexType>
Obrigatoriedade: Obrigatório
Atributo
Obrigatório
Valores
Notas
A definição de ID16 (ver nota de rodapé 4) permite o uso
ID
Obrigatório
Tipo de dados
de UUID17 iniciado ou precedido por um dos caracteres
xs:ID15
permitidos
em(18)
(e.g. “_0dec26dd-fc3b-47c6-af9d-
1cd38db10c55”)
Version
Obrigatório
IssueInstant
Obrigatório
2.0
SAML Version
UTC date & time assertion was issued
10.2.4.2 <saml:Issuer>
<element name="Issuer" type="saml:NameIDType"/>
<complexType name="NameIDType">
<simpleContent>
<extension base="string">
<attributeGroup ref="saml:IDNameQualifiers"/>
<attribute name="Format" type="anyURI" use="Opcional"/>
<attribute name="SPProvidedID" type="string" use="Opcional"/>
</extension>
</simpleContent>
</complexType>
15
Definido em http://www.w3.org/TR/xmlschema-2/#ID, garantindo as proprieades referidas em
http://docs.oasis-open.org/security/saml/v2.0/saml-core-2.0-os.pdf 1.3.4 ID and ID ReferenceValues
16
Definição de ID no protocolo SAML em http://www.w3.org/TR/xmlschema-2/#ID
http://www.w3.org/TR/1999/REC-xml-names-19990114/#NT-NCName
Internet Engeneering Task Force RFC4112 (http://www.ietf.org/rfc/rfc4122.txt)
http://www.w3.org/TR/REC-xml/#NT-Lette
17
18
©2011 AMA.
e
66/83
Obrigatoriedade: Obrigatório
Este elemento identifica a entidade que gerou o <saml:Assertion>. O elemento <saml:Issuer> é
obrigatório dentro de um <saml:Assertion> e contém um valor de string (URI), referindo-se à
entidade emissora.
O elemento <Issuer> deve conter um URI que identifica o FA emissor. Este URI deve ser
mutuamente acordado com o Fornecedor de Serviços que o receber. Este valor mantém-se para
qualquer resposta fornecida pelo FA.
Atributo
Obrigatório
NameQualifier
Não usado
The security domain that qualifies that name.
Não usado
Qualifying the name with a name of a service provider.
SPNameQualif
ier
Format
SPProvidedID
Opcional
Não usado
Valores
Notas
urn:oasis:names:t
URI representing the classification of the identifier.
c:SAML:2.0:name
Default
idformat:entity
format:entity.
is
urn:oasis:names:tc:SAML:2.0:nameid-
Name identifier if different from the name in the contents
of the element.
10.2.4.3 <ds:Signature>
Obrigatoriedade: Opcional
Se o HTTP POST Binding é usado, a asserção SAML deve estar assinada.
A assinatura digital XML autentica o Fornecedor de Serviços e garante a integridade da mensagem
(sobre todo o pedido de autenticação). A assinatura deve ser uma enveloped signature e aplicada ao
elemento <samlp:AuthnRequest> e todos os seus filhos.
A assinatura deve conter um único elemento <ds:Reference> contendo o valor do atributo ID do
elemento <samlp:AuthnRequest>. O formato de <ds:Signature> encontra-se definido em
http://www.w3.org/TR/xmldsig-core/#sec-Reference. O valor do atributo URI em <ds:Reference>
terá que conter o mesmo valor do ID do documento em < samlp:AuthnRequest>, procedido do
carácter ‘#’19 (e.g. <Reference URI="#_2e19be9c-37bc-475c-93fd-b05e1970ba4d">…)
19
http://docs.oasis-open.org/security/saml/v2.0/saml-core-2.0-os.pdf - 5.4.2 References
©2011 AMA.
67/83
10.2.4.4 <saml:Subject>
<complexType name="SubjectType">
<choice>
<sequence>
<choice>
<element ref="saml:BaseID"/>
<element ref="saml:NameID"/>
<element ref="saml:EncryptedID"/>
</choice>
<element ref="saml:SubjectConfirmation" minOccurs="0" maxOccurs="unbounded"/>
</sequence>
<element ref="saml:SubjectConfirmation" maxOccurs="unbounded"/>
</choice>
</complexType>
Obrigatoriedade: Obrigatório
Indica a quem as asserções são dirigidas. No contexto do FA, apenas o element <saml:NameID> será
suportado.
10.2.4.4.1 <saml:NameId>
Obrigatoriedade: Obrigatório
Reprensenta o sujeito.
Atributo
NameQualifier
SPNameQualif
ier
Obrigatório
Valores
Security or Admin Domain that qualifies the name.
Obrigatório
This should be the namespace of the FA.
Further qualifies the name with a [group of] Service
Opcional
Provider. This should be the namespace of the original
Service Provider
urn:oasis:names:t
Format
Obrigatório
c:SAML:2.0:name
idformat:unspeci
fied
SPProvidedID
©2011 AMA.
Notas
Não usado
A URI defining the format of the NameId. The User’s eID
is provided in a separate attribute.
NameId should not be used to assert the subject’s identity
but may be used to assert return visits from a user using
the same authentication.
Name identifier if different from the name in the contents
of the element.
68/83
10.2.4.4.1.1 <saml:EncryptedID>
Obrigatoriedade: Não usado
10.2.4.4.1.1.1
<xenc:EncryptedData>
Obrigatoriedade: Não usado
10.2.4.4.1.1.2
<xenc:EncryptedKey>
Obrigatoriedade: Não usado
10.2.4.4.2 <saml:SubjectConfirmation>
<complexType name="SubjectConfirmationType">
<sequence>
<choice minOccurs="0">
<element ref="saml:BaseID"/>
<element ref="saml:NameID"/>
<element ref="saml:EncryptedID"/>
</choice>
<element ref="saml:SubjectConfirmationData" minOccurs="0"/>
</sequence>
<attribute name="Method" type="anyURI" use="required"/>
</complexType>
Obrigatoriedade: Obrigatório
Atributo
Obrigatório
Valores
urn:oasis:names:t
Method
Obrigatório
c:SAML:2.0:cm:b
earer
Notas
Bearer is mandatory to allow in one SubjejctConfirmation
to support the Browser SSO profile.
10.2.4.4.2.1 <saml:BaseId>, <saml:NameId>, <saml:EncryptedID>
Obrigatoriedade: Não usado
10.2.4.4.3 <saml:SubjectConfirmationData>
<complexType name="SubjectConfirmationDataType" mixed="true">
<complexContent>
<restriction base="anyType">
<sequence>
<any
namespace="##any"
processContents="lax"
maxOccurs="unbounded"/>
<element ref="ds:KeyInfo" minOccurs="0"/>
</sequence>
©2011 AMA.
minOccurs="0"
69/83
<attribute name="NotBefore" type="dateTime" use="Opcional"/>
<attribute name="NotOnOrAfter" type="dateTime" use="Opcional"/>
<attribute name="Recipient" type="anyURI" use="Opcional"/>
<attribute name="InResponseTo" type="NCName" use="Opcional"/>
<attribute name="Address" type="string" use="Opcional"/>
<anyAttribute namespace="##other" processContents="lax"/>
</restriction>
</complexContent>
</complexType>
Obrigatoriedade: Obrigatório
Atributo
NotBefore
Obrigatório
Opcional
Valores
Notas
Not allowed under Browser SSO Profile i.e. where
SubjectConfirmation method is bearer.
Subject cannot be confirmed on or after this time. If
NotOnOrAfter
Obrigatório
SubjectConfirmation method is holder-of-key then this
value must be less than or equal to the NotBefore
attribute in the X.509 certificate.
URI reference of the SP this assertion is being sent to. This
Recipient
Obrigatório
should
be
the
same
AssertionConsumerServiceURL
value
attribute
as
in
the
the
Authentication Request
InResponseTo
Obrigatório
Id of the Request that requested this assertion
IP address of user that this assertion was issued to.
Address
Opcional
Obrigatório for bearer SubjectConfirmation method as it
allows
Relying Parties to mitigate against a Man-In-The-Middle.
10.2.4.4.3.1 <ds:KeyInfo>
<element name="KeyInfo" type="ds:KeyInfoType"/>
<complexType name="KeyInfoType" mixed="true">
<choice maxOccurs="unbounded">
<element ref="ds:KeyName"/>
<element ref="ds:KeyValue"/>
<element ref="ds:RetrievalMethod"/>
<element ref="ds:X509Data"/>
<element ref="ds:PGPData"/>
<element ref="ds:SPKIData"/>
<element ref="ds:MgmtData"/>
<any processContents="lax" namespace="##other"/>
</choice>
<attribute name="Id" type="ID" use="Opcional"/>
</complexType>
©2011 AMA.
70/83
<ds:KeyInfo> encontra-se definido em XML Signature (W3C Consortium, 2009).
Obrigatoriedade: Opcional
Atributo
Obrigatório
ID
Não usado
Valores
Notas
10.2.4.4.3.2 <ds:X509Data>
Obrigatoriedade: Não usado
10.2.4.5 <saml:Conditions>
<complexType name="ConditionsType">
<choice minOccurs="0" maxOccurs="unbounded">
<element ref="saml:Condition"/>
<element ref="saml:AudienceRestriction"/>
<element ref="saml:OneTimeUse"/>
<element ref="saml:ProxyRestriction"/>
</choice>
<attribute name="NotBefore" type="dateTime" use="Opcional"/>
<attribute name="NotOnOrAfter" type="dateTime" use="Opcional"/>
</complexType>
Obrigatoriedade: Obrigatório
Este elemento especifica as condições que devem ser validadas quando se utiliza o elemento < Assertion>.
Essas condições devem ser as mesmas que as condições especificadas no pedido <AuthnRequest>.
Atributo
Obrigatório
Valores
Notas
NotBefore
Obrigatório
Assertion not valid before this time
NotOnOrAfter
Obrigatório
Assertion not valid on or after this time
10.2.4.6 <saml:Condition>
Obrigatoriedade: Não usado
©2011 AMA.
71/83
10.2.4.7 <saml:AudienceRestriction>
<complexType name="AudienceRestrictionType">
<complexContent>
<extension base="saml:ConditionAbstractType">
<sequence>
<element ref="saml:Audience" maxOccurs="unbounded"/>
</sequence>
</extension>
</complexContent>
</complexType>
Obrigatoriedade: Obrigatório
Restringe a audiência desta asserção para o SP e contém a referência URI do SP para o qual está a
ser enviado.
10.2.4.7.1.1 <saml:Audience>
<element name="Audience" type="anyURI"/>
Obrigatoriedade: Obrigatório
10.2.4.7.2 <saml:OneTimeUse>
Obrigatoriedade: Obrigatório
Define que esta asserção tem que ser utilizado de imediato e não pode ser mantida para uso futuro.
10.2.4.7.3 <saml:ProxyRestrictions>
Obrigatoriedade: Não usado
10.2.4.8 <saml:Advice>
Obrigatoriedade: Não usado
10.2.4.9 <saml:AuthnStatement>
<complexType name="AuthnStatementType">
<complexContent>
<extension base="saml:StatementAbstractType">
<sequence>
<element ref="saml:SubjectLocality" minOccurs="0"/>
<element ref="saml:AuthnContext"/>
</sequence>
<attribute name="AuthnInstant" type="dateTime" use="required"/>
<attribute name="SessionIndex" type="string" use="Opcional"/>
©2011 AMA.
72/83
<attribute name="SessionNotOnOrAfter" type="dateTime" use="Opcional"/>
</extension>
</complexContent>
</complexType>
Obrigatoriedade: Obrigatório
Atributo
Obrigatório
Valores
Notas
AuthnInstant
Obrigatório
SessionIndex
Opcional
Date & Time User was actually authenticated
Index of the User’s FA session. Allow for increased
interoperability with other profiles.
Não usado
When the User’s IdP session is deemed to have expired.
SessionNotOn
OrAfter
10.2.4.9.1 <saml:SubjectLocality>
<complexType name="SubjectLocalityType">
<attribute name="Address" type="string" use="Opcional"/>
<attribute name="DNSName" type="string" use="Opcional"/>
</complexType>
Obrigatoriedade: Obrigatório
Este elemento deve conter o nome de domínio DNS e endereço IP do sistema a partir do qual o
utilizador foi autenticado.
Atributo
Obrigatório
Valores
Notas
Address
Obrigatório
IP address of authenticating user’s client system
DNSName
Opcional
DNS Name of authenticating user’s client system
10.2.4.9.2 <saml:AuthnContext>
Obrigatoriedade: Não usado
10.2.4.10
<saml:AttributeStatement>
Obrigatoriedade: Opcional
Este elemento contém vários elementos <attribute> contendo informações de atributo associado com
o tema SAML. Para cada atributo solicitado no elemento <AuthnRequest> o elemento
<AttributeStatement> contém um elemento único <attribute> disponível.
©2011 AMA.
73/83
10.2.4.10.1<saml:Attribute>
<complexType name="AttributeType">
<sequence>
<element ref="saml:AttributeValue" minOccurs="0" maxOccurs="unbounded"/>
</sequence>
<attribute name="Name" type="string" use="required"/>
<attribute name="NameFormat" type="anyURI" use="Opcional"/>
<attribute name="FriendlyName" type="string" use="Opcional"/>
<anyAttribute namespace="##other" processContents="lax"/>
</complexType>
Um elemento <attribute> é necessário para cada atributo FA solicitado no pedido original.
A lista de atributos disponíveis FA, incluindo seus nomes e formatos, é descrita no capítulo
seguinte.
Atributo
Obrigatório
Valores
Notas
Name
Obrigatório
Agreed Name of Attribute Required
NameFormat
Obrigatório
FriendlyName
Não usado
Agreed Format of the Attribute Name
A friendly name for the attribute that can be displayed to
a user. FA is responsible for user consent so probably not
required by SP.
Available
fa:AttributeSta
tus
Opcional
NotAvailable
Withheld
Used to signify whether or not the <Attribute> requested
was ”Available”, ” NotAvailable” or “Withheld”. The
default value is “Available” i.e. attribute value has been
returned.
10.2.4.10.1.1 <saml:AttributeValue>
Obrigatoriedade: Opcional
Valor do atributo, se disponível. Este valor será codificado na base64 para interoperabilidade
máxima (a validar em sede de integração).
10.2.4.10.2<saml:EncryptedAttribute>
Obrigatoriedade: Não usado
10.2.4.10.2.1 <xenc:EncryptedData>
Obrigatoriedade: Não usado
©2011 AMA.
74/83
10.2.4.10.2.2 <xenc:EncryptedKey>
Obrigatoriedade: Não usado
10.2.4.11
Exemplo de asserção SAML
<saml2:Assertion Version="2.0" ID="_b1c88f11-50fd-4a22-988e-9ce4573049e0" IssueInstant="2011-02-17T11:17:14.6349444Z">
<saml2:Issuer>https://autenticacao.cartaodecidadao.pt</saml2:Issuer>
<saml2:Subject>
<saml2:NameID
Format="urn:oasis:names:tc:SAML:1.1:nameidformat:unspecified">urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified</saml2:NameID>
<saml2:SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">
<saml2:SubjectConfirmationData
NotOnOrAfter="2011-02-17T11:22:14Z"
Recipient="https://www.ServiceProvider.pt" InResponseTo="_1e736a31-a41c-4c35-b17f-0f9ab4c741b3" Address="127.0.0.1"/>
</saml2:SubjectConfirmation>
</saml2:Subject>
<saml2:Conditions NotBefore="2011-02-17T11:17:14Z" NotOnOrAfter="2011-02-17T11:22:14Z">
<saml2:AudienceRestriction>
<saml2:Audience>https://www.ServiceProvider.pt</saml2:Audience>
</saml2:AudienceRestriction>
<saml2:OneTimeUse/>
</saml2:Conditions>
<saml2:AuthnStatement AuthnInstant="2011-02-17T11:17:14.6349444Z">
<saml2:AuthnContext/>
</saml2:AuthnStatement>
<saml2:AttributeStatement>
<saml2:Attribute Name="AttributeName" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"
fa:AttributeStatus="Available">
<saml2:AttributeValue
xmlns:q1="http://www.w3.org/2001/XMLSchema"
xmlns:d5p1="http://www.w3.org/2001/XMLSchema-instance" d5p1:type="q1:string">AttributeValue</saml2:AttributeValue>
</saml2:Attribute>
</saml2:AttributeStatement>
</saml2:Assertion>
10.3
Fecho de sessão
10.3.1 Fluxo de processo
O pedido de fecho de sessão usa SAML 2.0 logout protocol de acordo com as especificações SAML
2.0. As comunicações entre o browser do utilizador e o FA devem ser efectuadas sobre SSL V3+ ou
TLS 1.0+.
Logout Request
Fornecedor de
Autenticação (FA)
Service Provider (SP)
Logout Response
Figure 1 – Fluxo autenticação SAML
©2011 AMA.
75/83
O FA irá responder ao SP, com a informação de logout. Esta ligação é também suportada sobre SSL
V3+ ou TLS 1.0+.
A figura seguinte representa o processo de logout com recurso ao FA, na perspectiva do utilizador.
O processo de logout seguirá os seguintes passos:
1) Utilizador pretende fechar a sessão no FA;
2) Fornecedor de Serviços gera pedido SAML para o FA. À semelhança do pedido de
autenticação, este irá identificar o Fornecedor de Serviços;
3) Fornecedor de Serviços redirecciona utilizador para o logout do FA, submetendo o pedido
SAML no motor do FA;
4) FA valida o pedido e caso o utilizador possua sessão, termina-a;
5) FA gera resposta SAML e redirecciona o utilizador para o Fornecedor de Serviços;
6) O Fornecedor de Serviços deve validar a resposta SAML para assegurar que o pedido foi
realizado com sucesso. Deve também efectuar o fecho de sessão específico no seu portal;
©2011 AMA.
76/83
7) Após conclusão do processo com sucesso, o utilizador deixará de ter sessão activa no FA.
10.3.2 Logout Request
10.3.2.1 <samlp:LogoutRequest>
<sequence>
<element ref="saml:Issuer" minOccurs="0"/>
<element ref="ds:Signature" minOccurs="0"/>
<element ref="samlp:Extensions" minOccurs="0"/>
<element ref="samlp:SessionIndex" minOccurs="0"/>
<element ref="saml:NameID"/>
</sequence>
<attribute name="ID" type="ID" use="required"/>
<attribute name="Version" type="string" use="required"/>
<attribute name="IssueInstant" type="dateTime" use="required"/>
<attribute name="Destination" type="anyURI" use="Opcional"/>
<attribute name="Consent" type="anyURI" use="Opcional"/>
<attribute name="NotOnOrAfter" type="dateTime" use="Opcional"/>
<attribute name="Reason" type="string" use="Opcional"/>
Obrigatoriedade: Obrigatório
Atributo
Obrigatório
Valores
Notas
A definição de ID21 (ver nota de rodapé 4) permite o uso
ID
Obrigatório
Tipo de dados
de UUID22 iniciado ou precedido por um dos caracteres
xs:ID20
permitidos
em(23)
(e.g. “_0dec26dd-fc3b-47c6-af9d-
1cd38db10c55”)
Version
Obrigatório
2.0
SAML Version
IssueInstant
Obrigatório
UTC date & time request was issued
Destination
Obrigatório
URI reference of SAML Request is being sent to
urn:oasis:names:t
Consent
Opcional
c:SAML:2.0:cons
ent:unspecified
NotOnOrAft
er
Não usado
20
Definido em http://www.w3.org/TR/xmlschema-2/#ID, garantindo as proprieades referidas em
http://docs.oasis-open.org/security/saml/v2.0/saml-core-2.0-os.pdf 1.3.4 ID and ID ReferenceValues
21
Definição de ID no protocolo SAML em http://www.w3.org/TR/xmlschema-2/#ID
http://www.w3.org/TR/1999/REC-xml-names-19990114/#NT-NCName
22
Internet Engeneering Task Force RFC4112 (http://www.ietf.org/rfc/rfc4122.txt)
23
http://www.w3.org/TR/REC-xml/#NT-Lette
©2011 AMA.
e
77/83
Atributo
Reason
Valores
Obrigatório
Notas
Não usado
10.3.2.2 <samlp:issuer>
Obrigatoriedade: Obrigatório
Igual à especificação AuthnRequest.
10.3.2.3 <ds:signature>
Obrigatoriedade: Obrigatório
Igual à especificação AuthnRequest.
10.3.2.4 <samlp:extensions>
Obrigatoriedade: Não usado
10.3.2.5 <saml:NameID>
<element name="NameID" type="samlp:NameIDType"/>
<complexType name="NameIDType">
<simpleContent>
<attributeGroup ref=”saml:IDNameQualifiers”/>
<attribute name="Format" type="anyURI" use="Opcional"/>
<attribute name="SPProviderID" type="string" use="Opcional"/>
</simpleContent>
</complexType>
Obrigatoriedade: Obrigatório
Atributo
Obrigatório
NameQualifier
Não usado
The security domain that qualifies that name.
Não usado
Qualifying the name with a name of a service provider.
SPNameQualif
ier
Format
SPProvidedID
©2011 AMA.
Opcional
Não usado
Valores
Notas
urn:oasis:names:t
URI representing the classification of the identifier.
c:SAML:2.0:cons
Default
ent:unspecified
urn:oasis:names:tc:SAML:2.0:consent:unspecified
is
Name identifier if different from the name in the contents
of the element.
78/83
10.3.2.6 <samlp:SessionIndex>
Obrigatoriedade: Não usado
10.3.2.7 Exemplo de pedido de fecho de sessão
<saml2p:LogoutRequest
xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion"
xmlns:fa="http://autenticacao.cartaodecidadao.pt/atributos"
ID="_5936a065-8ed5-4cb8-9fd4-3c808acbfb7b"
Version="2.0"
IssueInstant="2011-02-09T11:39:01.0343448Z"
Destination="https://autenticacao.cartadecidadao.pt/Default.aspx"
Consent="urn:oasis:names:tc:SAML:2.0:logout:user"
xmlns:saml2p="urn:oasis:names:tc:SAML:2.0:protocol">
<saml2:Issuer>http://www.serviceprovider.pt/</saml2:Issuer>
<Signature xmlns="http://www.w3.org/2000/09/xmldsig#">
<SignedInfo>
<CanonicalizationMethod Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"/>
<SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>
<Reference URI="#_5936a065-8ed5-4cb8-9fd4-3c808acbfb7b">
<Transforms>
<Transform
Algorithm="http://www.w3.org/2000/09/xmldsig#envelopedsignature"/>
<Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
</Transforms>
<DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
<DigestValue>KivtKyBDpS4v9OECsXY6l1aTBNg=</DigestValue>
</Reference>
</SignedInfo>
<SignatureValue>...signatureValue...</SignatureValue>
<KeyInfo>
<X509Data>
<X509Certificate>...x509Data...</X509Certificate>
</X509Data>
</KeyInfo>
</Signature>
<saml2:NameID
Format="urn:oasis:names:tc:SAML:1.1:nameidformat:unspecified">urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified</saml2:NameID>
</saml2p:LogoutRequest>
10.3.3 Logout Response
<sequence>
<element ref="saml:Issuer" minOccurs="0"/>
<element ref="ds:Signature" minOccurs="0"/>
<element ref="samlp:Extensions" minOccurs="0"/>
<element ref="samlp:Status"/>
</sequence>
<attribute name="ID" type="ID" use="required"/>
<attribute name="InResponseTo" type="NCName" use="Opcional"/>
©2011 AMA.
79/83
<attribute name="Version" type="string" use="required"/>
<attribute name="IssueInstant" type="dateTime" use="required"/>
<attribute name="Destination" type="anyURI" use="Opcional"/>
<attribute name="Consent" type="anyURI" use="Opcional"/>
Obrigatoriedade: Obrigatório
Atributo
Obrigatório
Valores
ID
Obrigatório
UUID24
InResponseTo
Opcional
Version
Obrigatório
IssueInstant
Obrigatório
Destination
Não usado
Notas
Random 128 bit value. The format is based on UUID
standard format
The identifier (ID) of the request this response refers to. If
the request message expired, this field is not used.
2.0
UTC Date & time response was issued.
urn:oasis:names:t
Consent
Opcional
c:SAML:2.0:cons
ent:unspecified
10.3.3.1 <saml:Issuer>
Obrigatoriedade: Obrigatório
Igual à especificação AuthnResponse.
10.3.3.2 <ds:Signature>
Obrigatoriedade: Não usado
10.3.3.3 <samlp:Extensions>
Obrigatoriedade: Não usado
24
Internet Engineering Task Force - RFC4112 (http://www.ietf.org/rfc/rfc4122.txt). UUID example value:
f81d4fae-7dec-11d0-a765-00a0c91e6bf6
©2011 AMA.
80/83
10.3.3.4 <samlp:Status>
<element name="Status" type="samlp:StatusType"/>
<complexType name="StatusType">
<sequence>
<element ref="samlp:StatusCode"/>
<element ref="samlp:StatusMessage" minOccurs="0"/>
<element ref="samlp:StatusDetail" minOccurs="0"/>
</sequence>
</complexType>
<element name="StatusCode" type="samlp:StatusCodeType"/>
<complexType name="StatusCodeType">
<sequence>
<element ref="samlp:StatusCode" minOccurs="0"/>
</sequence>
<attribute name="Value" type="anyURI" use="required"/>
</complexType>
<element name="StatusMessage" type="string"/>
<element name="StatusDetail" type="samlp:StatusDetailType"/>
<complexType name="StatusDetailType">
<sequence>
<any namespace="##any" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>
</sequence>
</complexType>
Obrigatoriedade: Obrigatório
10.3.3.4.1 <samlp:StatusCode>
Obrigatoriedade: Obrigatório
Igual à especificação AuthnResponse.
10.3.3.5 Exemplo de resposta ao pedido de fecho de sessão
<saml2p:LogoutResponse
xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion"
xmlns:fa="http://autenticacao.cartaodecidadao.pt/atributos"
ID="_f171c8a1-0616-421b-9fbf-34be422c414f"
InResponseTo="_49800585-b491-46d3-b8c8-efc743eccd52"
Version="2.0"
IssueInstant="2011-02-08T17:51:17.7593424Z"
Destination="http://www.serviceProvider"
Consent="urn:oasis:names:tc:SAML:2.0:consent:unspecified"
xmlns:saml2p="urn:oasis:names:tc:SAML:2.0:protocol">
<saml2:Issuer>http://www.ServiceProvider.pt/</saml2:Issuer>
<Signature xmlns="http://www.w3.org/2000/09/xmldsig#">
©2011 AMA.
81/83
<SignedInfo>
<CanonicalizationMethod Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"/>
<SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>
<Reference URI="#_f171c8a1-0616-421b-9fbf-34be422c414f">
<Transforms>
<Transform
Algorithm="http://www.w3.org/2000/09/xmldsig#envelopedsignature"/>
<Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
</Transforms>
<DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
<DigestValue>cX/NPb/aoCOcUK+4GOPwsndZ5rE=</DigestValue>
</Reference>
</SignedInfo>
<SignatureValue>...signatureValue...</SignatureValue>
<KeyInfo>
<X509Data>
<X509Certificate>...x509Data...</X509Certificate>
</X509Data>
</KeyInfo>
</Signature>
<saml2p:Status>
<saml2p:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success"/>
</saml2p:Status>
</saml2p:LogoutResponse>
©2011 AMA.
82/83
11 REFERÊNCIAS
1. STORK Consortium. STORK Framework - D5.8.1 Technical design. Stork eId - Secure Identity
Across Borders Linked. [Online] September 8, 2009. https://www.eid-stork.eu/.
2. OASIS Consortium. Assertions and Protocols for the OASIS Security Assertion Markup
Languange (SAML) v2.0. OASIS - Organization for the Advancement of Structured Information
Standards. [Online] March 2005. http://docs.oasis-open.org/security/saml/v2.0/saml-core-2.0-os.pdf.
3. —. Security Assertion Markup Language (SAML) v2.0. OASIS - Organization for the Advancement
of Structured Information Standards. [Online] March de 2005. http://www.oasisopen.org/specs/index.php#saml.
4. W3C Consortium. XML Signature Syntax and Processing (Second Edition) - W3C
Recommendation 10 June 2008. W3C - World Wide Web Consortium. [Online] June 10, 2009.
http://www.w3.org/TR/xmldsig-core/.
5. —. XML Encryption Syntax and Processing. W3C - World Wide Web Consortium. [Online] 2 de
December de 2002. http://www.w3.org/TR/xmlenc-core/.
©2011 AMA.
83/83