SAML Protocol and Umbraco Backoffice
•Download as PPTX, PDF•
0 likes•448 views
This document discusses SAML, the Citizen Card, and Umbraco Identity Extensions for single sign-on authentication. It provides an overview of SAML as an open standard for exchanging authentication data between an identity provider and service provider using XML. It describes how SAML can enable single sign-on functionality. It also outlines the requirements and process for configuring the Portuguese government authentication service and demonstrates how to integrate it with Umbraco for backend user authentication.
Recommended
Recommended
More Related Content
Similar to SAML Protocol and Umbraco Backoffice
Similar to SAML Protocol and Umbraco Backoffice (20)
Recently uploaded
Recently uploaded (20)
SAML Protocol and Umbraco Backoffice
- 1. SAML & CCARD UMBRACO Authentication Gov.pt
- 2. Checklist for take-off ■ What is SAML ? – Request – Response – Certificates – SSO ■ autenticacao.gov.pt – Citizen Card – Chave móvel digital ■ Umbraco Identity Extensions – OauthVS SAML – Owin
- 3. SAML stands for: SecurityAssertion Markup Language ■ “… is an open standard for exchanging authentication and authorization data between parties, in particular, between an identity provider and a service provider. As its name implies,SAML is an XML-based markup language for security assertions (statements that service providers use to make access-control decisions” (fromWikipedia) ■ SAML 1.0 (11/2002) ■ SAML 1.1 (09/2003) ■ SAML 2.0 (03/2005) ■ http://saml.xml.org/saml-specifications
- 4. SAML design ■ XML – format – Old school xml ;) ■ XML Schema (aka xsd) – Assertions and protocol specification – Integrity ■ XML Signature – Identity / Authenticity – V1.1 and v2.0 compliant with digital signature ■ XML Encryption (only on v2.0) – X.509 / RSA / Certificate chain ■ Http(s) as communication protocol ■ SOAP – protocol, binding and profile ■ 10% Enterprise adoption
- 5. Single Sign On (remember?) ■ Multiple Identity Provider (google, facebook, autenticacao gov pt, etc) ■ One identity cross application ■ Reduce Password fatigue ■ Reduce costs ■ Empower affiliated apps ■ Wide usage ■ Multiple formats (smartcard, user/pwd, Kerberos, Ad, etc)
- 6. SAML as SSO Traditional approach SSO Provider Request/Redirect Response/Redirect
- 8. AUTH REQUEST
- 11. CITIZEN CARD • Smart card • Authentication • Signature • Address
- 12. https://www.autenticacao.gov.pt/ SSO Provider Mobile Number Email Twitter Identities Attributes PIN Aut h PIN Aut h Personal Card Digital Key Demo at https://preprod.autenticacao.gov.pt/cliente/
- 13. Requirements of: autenticacao.gov.pt Autenticação Gov Request doc template (data of contacts, etc) Para a configuração do Service Provider no Autenticação.Gov de PRODUÇÃO necessitamos que: 1. Nos forneçam um certificado digital , emitido por entidade certificadora reconhecida e exportado com a sua cadeia de certificação. 2. Nos informem: - a. O “valor” que será utilizado no atributo "Issuer" - b. O “valor” que será usado no atributo "ProviderName" - 3.Nos forneçam um logótipo de dimensão 195*97 (com fundo preferencialmente transparente) - 4. Nos forneçam um endereço para onde o Autenticação.Gov vai redirecionar as respostas aos pedidos de logout (opcional) ou em alternativa fornecer o endereço de logout no pedido de logout (Source ama.pt)
- 14. Umbraco backoffice authVS SAML ASP.NET Identity: 1. OWIN ready 2. “Oauth-ish” 3. Claims 4. Cookie /Token SAML SSO Authgov: 1. Request/Response 2. SOA Principles 3. Attributes 4. Relay State Umbraco.Identity.Extensions 1. Custom OAuth 2. Custom Password Checker MyPasswordChecker <IBackofficeUserPasswordChecker> 1. C# CustomCode 2. ReturnValidCredentials
- 15. Autenticacao.gov.pt => Umbraco Backoffice api Get SAML Request SAML POST / Auth Auth PinSAML POST / Response
- 20. Q&A “No one is an atheist on a turbulent plane.” Thank you @gchaves
- 21. References ■ https://www.ama.gov.pt/ ■ http://en.wikipedia.org ■ https://autenticacao.gov.pt ■ https://www.ubisecure.com/uncategorized/difference-between-saml-and-oauth/ ■ https://github.com/gfchaves/AuthGovPTSaml ■ Images:Airbus, aironline.com, airlines.net, @bristo
Editor's Notes
- Olá, Esta apresentação tem como objectivo principal, dar a conhecer os resultados do desafio proposto pelo portaldacultura, isto é, autenticação em backoffice Umbraco através do nosso cartão de cidadão. Quais os desafios que se propuseram. Quais as dificuldades e incompatibilidades. Quais as novas noções e conhecimentos envolvidos.
- Para vos pilotar sobre esta apresentação e sobre os tópicos principais de forma a melhor compreensão, foram aqui reunidos alguns exemplos e explicações. Contudo as palavras chaves envolvidas passam pela utilização e compreensão do protocolo de segurança para autenticação SSO (single sign on) SAML 2.0, serviço prestado pelo autenticação.gov.pt (cartão de cidadão e chave móvel digital) e por último a autenticação interna para backoffice em Umbraco v7.x
- O protocolo SAML, pela sua definição das iniciais dadas, assenta sobre os princípios de segurança e identidade definidos em linguagem markup, muito em semelhança a outros protocolos mais conhecidos como por ex. SOAP. Através da definição de sintaxe XML, é possível descrever as mensagens sobre estrutura SAML para solicitar pedidos de identidade (autenticação) bem como outras operações que o serviço (provider) de SSO possa disponibilizar. Seja eles: Asserção de queries ou de pedidos (aplicação de filtros, acesso dinâmico a dados…) Pedidos de autenticação (SSO login, normal como é mais conhecido) Resolução de artfactos (transmissão de dados concretos, encapsulados em pedido, Http Artifact binding) Gestão de nomes identificativos (nomes de atributos, namespaces, etc) Pedido para Logout Mapeamento de nomes identificativos (atributo idade, do tipo int, etc) e muitas outras especificações que possam ser ou não compreendidas pelo standard definido ao protocolo. Apesar da idade do protocolo em si, e da sua evolução se mostrar um pouco tímida, as evoluções introduzidas no protocolo foram claramente determinantes para a sua utilização inclusive aos dias de hoje. Falamos mais concretamente da inclusão de suporte para certificados de segurança, de forma a garantir integridade de mensagem, identidade e a própria cifra para garantir a confidencialidade das mensagens trocadas. Concentrando a nossa atenção para a versão 2.0 do protocolo, é importante notar que o seu objectivo é dar suporte a: Asserção para autenticação (afirmação de confiança para autenticação) Asserção de atributos (por ex: dados de perfil do utilizador, ou de uma determinada entidade Asserção de decisão de autorização ( ou seja, através do conceito de claim, identificar a autorização concreta para um determinado recurso ou conjunto de funcionalidades)
- O formato XML amplamente conhecido e utilizado em inúmeras utilizações semelhantes por outros protocolos é também adoptado no SAML, e com o recurso a à definição de estrutura indicada através da utilização de XSDs, é possível de determinar a utilização correcta e a validação da sua especificação em toda a sua definição. Isto é, seja para pedidos e atributos. Através da introdução das capacidades de assinatura de XML (XML Signature ) é conseguida a possibilidade de assinatura correcta para garantir a identidade que está a solicitar ou a responder aos pedidos SAML. Por outro lado, e com recurso às capacidades de cifra (encriptação) através da utilização de certificados X.509, é garantida previamente a integridade e confidencialidade do pedido, ou resposta e a segurança durante a sua transmissão entre as entidades envolvidas. Uma vez que os conteúdos apenas serão passíveis de leitura ao detentores das chaves privadas. O protocolo SAML está associado por definição ao protocolo de comunicação Http/https. E uma vez esta associação são herdados conceitos e funcionalidades do protocolo http para o SAML, especialmente as ligações (bindings) a recursos, ex: 1) (Reverse) SAML SOAP binding 2) Http redirect 3) Http POST 4) Http Artifact 5) SAML Uri (Defines a means for retrieving an existing SAML assertion by resolving a URI (uniform resource identifier).) Uma vez a utilização desta arquitectura no protocol SAML, é também herdado os conceitos de perfil (profiling) permitindo a definição de comportamentos/fluxos esperados para cada tipo durante as suas múltiplas utilizações. Ex: Web Browser SSO Profile Enhanced Client or Proxy (ECP) Profile Identity Provider Discovery Profile Single Logout Profile Name Identifier Management Profile Artifact Resolution Profile Assertion Query/Request Profile Name Identifier Mapping Profile SAML Attribute Profiles Basic Attribute Profile X.500/LDAP Attribute Profile UUID Attribute Profile DCE PAC Attribute Profile XACML Attribute Profile Como se pode constactar a versatilidade deste protocol é claramente ampla e permite a sua utilização em múltiplos cenários. Adopção moderada, e em ênfase nas aplicações empresariais de maior escala.
- Apenas para nos relembrarmos todos, o que é a autenticação SSO e como é que a mesma se processa. Portanto existe uma entidade central (identity provider) que detém a informação sobre a identidade dos utilizadores e dados de perfil. O nosso fornecedor de autenticação, apenas nos permite realizar pedidos de autenticação se a nossa aplicação (cliente) está previamente autorizada a fazê-lo. Para além de autorizar/reconhecer individualmente as aplicações, e as respectivas identidades dos utilizadores, permite naturalmente definir contextos individualizados e especificados para cada uma. O melhor exemplo, é o caso do Facebook. Não só a necessidade de diferenciar as origem de autenticação, como também a versatilidade de acesso a determinados dados da nossa identidade serem negociados por meios providos de autorização extra. Benefícios vs integridade de autenticação. Se o SSO provider não estiver a funcionar, todas as funcionalidades pendentes de autenticação das aplicações estarão também comprometidas. (single point of failure) Confiança e integridade da informação e da identidade. Ou seja, o nosso SSO provider deverá ter a capacidade de determinar e garantir não só a autenticidade da informação como também o seu nível de confiança da mesma.
- A implementação SSO do portal autenticacao.gov.pt, segue uma aproximação standard para este cenário. Descrição do fluxo: O utilizador acede ao nosso website/aplicação O utilizador solicita login com authgov.pt O nosso site gera o primeiro SAML Request O utilizador é redireccionado (vis post de página) para o nosso SSO login page O portal authgov.pt solicita as credenciais e certificados registados em CC através de leitura via smartcard. Pin de autenticação O portal authgov.pt valida os dados e emite a reposta para o nosso website/aplicação O nosso website/aplicação procede à validação da resposta e segue o seu fluxo de autenticação interna.
- Após a introdução e definição do protocolo SAML, o nosso foco centra-se nas funcionalidades de autenticação SSO. Significa que para que seja possível solicitar uma autenticação via SSO com a utilização do SAML para os nossos pedidos e respostas. Ou seja, o processo de negociação com o nosso identity provider.
- Este exemplo é o pedido SAML AuthRequest gerado pelo nosso método GetSamlAuthRequest (API). O que é importante destacar/notar: Geração de IDs por pedido (tracking, autenticidade); ProtocolBinding, qual é o perfil de ligação do protocol que estamos à espera na resposta (POST); AssertionConsumerServiceURL, ou seja, qual é o endereço para o qual queremos receber a resposta por parte do SSO provider; Provider Name, a identificação do nosso SSO provider; Elemento de assinatura, detém a “nossa” assinatura devidamente identificada e cifrada com o certificado emitido para o efeito (X.509) negociado com o SSO; Passagem do certificado para o SSO verificar a sua validade e autenticidade perante a sua realidade; Extensions. Conjunto de pedidos de atributos específicos, neste caso, NIC como obrigatório e o nome como opcional. Atributos do nosso SSO (autenticacao.gov.pt) FAAALevel, atributo especial que define o grau de segurança disponível para a autenticação. Neste caso o default é 4 (verificar a doc do SSO), contudo a indicação “2” define a opção para solicitar autenticação através da CMD por opção do utilizador. (Ou seja, é apresentada as duas hipóteses ao utilizador no momento de auth)
- Estamos agora a visualizar o exemplo de resposta ao nosso pedido (slide anterior). A destacar: InResponseTo, ID do nosso pedido original (novamente tracking e integridade) Destination, url de envo deste pedido (POST) Issuer, dado como uma afirmação (assertion) do cartão de cidadão português Novamente a presença da assinatura do pedido e do respectivo certificado Elemento Status e Status Code. Neste caso requestDenied porque o nosso SSO não reconheceu no nosso pedido original a entidade definida em na propriedade Issuer
- Estamos agora a visualizar o exemplo de resposta ao nosso pedido (slide anterior). A destacar: InResponseTo, ID do nosso pedido original (novamente tracking e integridade) Destination, url de envio deste pedido (POST) Issuer, dado como uma afirmação (assertion) do cartão de cidadão português Novamente a presença da assinatura do pedido e do respectivo certificado Elemento Status e Status Code. Neste caso Success Elemento Audience, o url do nosso portal Elementos de atributos em reposta ao pedido de autenticação Retorna o seu tipo e o seu valor Ausência do attr nome neste exemplo, apesar de ter sido pedido no request (retirado para efeitos de visualização).
- Conheçem o nosso cartão de cidadão ou o bilhete de identidade? Quem chegou a ter o BI “antigo” ? E os mitos sobre os números e teorias sobre os nomes? Quem sabe o que contém o cartão de cidadão? Tem 11 anos de vida Fornece a nossa identidade de cidadania e a nossa identidade digital Formato em smartcard, capaz de armazenar os certificados digitais e respectivas cadeias Pin de autenticação, para autorizar a leitura do nosso certificado individual de identidade para quem está a solicitar a sua leitura Pin de morada, permite alterar/ler os dados da nossa morada, mas mediante pin Pin de assinatura, permite a leitura do nosso certificado para ser utilizado como assinatura digital de documentos, etc Validade e equicidade (perante a lei) digital vs presencial
- Então o que é que o SSO service provider do portal autenticação gov pt nos oferece? Autenticação com o cartão de cidadão Requer presença física do cartão Leitura de dados através de smartcard Autorizações via PIN Consulta de dados; Autenticação via Chave Móvel Digital A chave móvel é uma autenticação mais simples, Não requer o leitor smarcard Não requer presença física do cartão Emissão de token de autorização via número de telemóvel ou email Envio de autorização (tokenizer) com janela de 5 minutos; SMS Email Twitter Com a CMD, conseguimos acelerar o processo de autenticação, eliminando a barreira de software/hardware e com o recurso à utilização de meios digitais já amplamente conhecidos pelos utilizadores. Contudo é necessário a utilização do cartão cidadão físico para activar/criar a CMD. Com base nestas duas opções, é possível ser a nossa aplicação a determinar qual o método de autenticação a ser utilizado (cc ou cmd, ou um individualmente), bem como no grau de confiança dos atributos solicitados.
- Os requisitos mais importantes solicitados pela ama.pt para uma determinada aplicação cliente e consumidora do serviços SSO de autenticação, são: 1) Certificado, com toda a sua cadeia. Uma vez que toda a cadeia é validada pelo SSO nos pedidos… (não sei se isto é um facto, mas não encontrei mais informações) 2) Issuer value (mais uma vez, este valor serve para dar garantia de identididade da propria aplicação) 3) ProviderName, outro indicador e identificador da nossa aplicação, que no momento de SSO irá aparecer no portal autenticacao.gov.pt 4) Sobre a questão de logout, nesta implementação não houve a opurtunidade de ensaiar. Contudo cremos pela documentação, que se quando o utilizador faz logout no portal authgov.pt, o mesmo transmite a acção para todos os clients que detêm pedidos de autenticação emitidos.
- O modelo de autenticação utilizado pelo backoffice Umbraco é baseado em ASP.NET Identity, por sua vez este modelo é baseado nos princípios de autenticação Oauth com recurso à implementação da sua interface via OWIN; Por outro lado o Sistema de autenticação oferecido pela AMA, baseado em SSO via SAML não é compatível de todo com o protocol Oauth. Não creio que haja forma de colar estas duas realidades sem que seja a recurso a alguma forma de adaptação. Isto é, a criação de um middle-ware específico que permita a transpocisão entre a emissão de tokens oauth e a negociação dos pedidos SAML. Ref: https://www.ubisecure.com/uncategorized/difference-between-saml-and-oauth/ Desta forma, pensámos em duas formas para atacar o problema: Implementação de um middleware, ex: IdentityServer4 com recurso a um adapter para realizar a negociação com o SSO… tempo vs custo Criar um adapter local, que resolva a negociação SSO, e que crie um token e o injecte no formulário de autenticação. Depois e atráves da extensibilidade que o Umbraco.Identity.Extensions nos trás, pela implementação de um custom password checker, realizar a validação do token e a consequente autenticação. A concretização desta segunda opção será mostrada mais à frente.
- Sequência de pedidos do processo: Para aparecer o butão da autenticação gov Request à nossa API para gerar um SAML Request com os atributos que queremos (nic, nome, etc) | autenticação normal e/ou com cmd Injectar o SAML e relay state em base 64 em <form > da página Clique => post do form para o authgov.pt (estamos a solicitar um pedido de autenticação para o nosso “site” O user resolve o processo de autenticação no portal authgov.pt com o cc ou cmd O resultado do processo de autenticação é enviado de volta via POST para o indicado no request Valida-se o resultado SAML, avalia-se os dados de resultado Gera-se um token nosso com atributos e data de validade Preenche-se o form automáticamente para “simular” a autenticação.
- Ver vídeo
- Ver vídeo
- Isolámos o código respeitante à autenticação/negociação SSO SAML, em projecto próprio Desenvolvimento de um conjunto de serviços e helpers que facilitem o processo de solicitação de um pedido SAML e de validação e processamento de resposta SAML Enums com os atributos disponíveis pelo SSO AuthGov.pt para o Cartão de cidadão; Schemas, ficheiros que definem a estrutura válida para os pedidos SAML para validação via xsd Desenvolvimento de serviço em classes parciais que detém dois métodos principais: GetSAMLResquest (para solicitar um pedido de autenticação) e ProcessSAMLResponse, para validar e processar uma resposta SAML Class SAML Protocol que define a estrutura de um pedido SAML Class SAML Request, um wrapper que determina a junção de um pedido/resposta SAML com propriedades próprias para dar apoio ao fluxo de SSO + autenticação API – Controller que detêm o método que devolve um pedido de autenticação SAML e outro método que recebe via POST a resposta SAML emitida via SSO do authgov.pt
- Demo com o VS + cartão de cidadao + Umbraco Explicação dos passos e dos conceitos no código
- Referências e links úteis com mais informações sobre os temas abordados.