Gestão de Identidade e
Aplicações Federativas
Capítulo IV
José Rogado
[email protected]
Universidade Lusófona
Mestrado Eng.ª Informática e Sistemas de Informação
1º Semestre 11/12
Programa da Cadeira
1. Introdução
Introdução ao Identity Management (IM)
Necessidades, Objectivos e Evolução
Elementos de Segurança
Terminologia e Conceitos Básicos
Algoritmos de Encriptação
Certificação
2. Gestão de Identidade
Identificação e Autenticação
Autorização e Controle de Acessos
Políticas, modelos e mecanismos
Modelos de Gestão de Identidade
Dez-11
Sistemas de autenticação
Contextos de segurança
Modelos locais
Gestão de identidade em ambientes empresariais
Modelos em rede, federados e globais
Gestão de Identidade e Aplicações
Federativas
2
Programa da Cadeira
3. Modelos de Confiança
Estabelecimento de Confiança
Confiança Baseada em Terceiros (Third-Party)
Confiança Implícita: Kerberos
Confiança Explícita: Infraestruturas de Chave-Pública (PKI)
Modelo Web-of-trust, reputação e comunidades de confiança
Modelo Federativo: necessidades, requisitos e implicações
4. Tecnologias de Suporte à Federação
Dez-11
XML Security: XML encryption, XML Signature, XML Key Management
Web Service Security: Secure SOAP Messages
SAML: Profiles, Bindings, Assertions
XACML: Especificação de Atributos, noções de RBAC
Web Services Security Framework
Liberty Alliance Framework
Gestão de Identidade e Aplicações
Federativas
3
Programa da Cadeira
5. Plataformas de Federação de Identidade
Shibboleth
OpenID
Modelo de Funcionamento
Arquitectura
Caso Prático
Dez-11
Modelo de Funcionamento
Arquitectura: IdP (Identity Provider), SP (Service Provider), WAYF
(Where Are You From)
Definição, Especificação e Implementação
Comparação de Tecnologias e Conceitos
Gestão de Identidade e Aplicações
Federativas
4
Características do Modelo Federado
Os modelos de IM abordados podem ser generalizados de forma a permitir a
agregação de domínios de confiança heterogéneos
• As tecnologias apresentadas permitem estabelecer relações entre entidades diversas,
com modelos internos distintos, desde que sigam um conjunto de princípios
Ao agregado de domínios assim criados, dá-se geralmente o nome de Federação, e
deverá obedecer às seguintes regras:
• A homogeneização da gestão de identidade entre domínios é realizada com base num
mecanismo de confiança acordado, para o estabelecimento do qual é estabelecido um
protocolo de autenticação
O tipo de relação de confiança pode ser mono ou bidireccional
• Os sujeitos autenticam-se nos seus respectivos domínios de registo mas podem
aceder a serviços disponibilizados por outros domínios com base na relações de
confiança estabelecidas
• Informação sobre os perfis dos sujeitos pode ser transferida entre domínios, na
condição de serem estabelecidas regras de conversão de formatos distintos
• Os sujeitos devem poder escolher quais o conjunto de atributos que é veiculado do seu
domínio de registo para qualquer outro que requeira esse tipo de informação
• A informação de identidade de um sujeito permanece ligada ao seu domínio de registo,
e está intimamente ligada à identificação respeitante ao domínio
• Devem ser utilizados protocolos de transporte baseados em standards de criptografia
forte para todas as trocas de mensagens entre domínios
Existem tecnologias específicas para realizar a maior parte dos aspectos acima
referidos, que iremos abordar neste capítulo
Dez-11
Gestão de Identidade e Aplicações
Federativas
5
Tecnologias de Suporte à Federação
Os requisitos de segurança dos ambientes federativos são mais
complexos do que os dos ambiente Cliente/Servidor
tradicionalmente usados em computação distribuída e na Web
A implementação de um determinado serviço pode ser realizada por
várias entidades através de múltiplas interacções
• A segurança deve persistir através das várias mensagens
• A identificação do end-user pode (ou não) ser propagada até ao
destinatário
• Cada entidade deve poder introduzir ou retirar as suas
credenciais específicas utilizadas na comunicação com os seus
parceiros directos
Assim são necessárias tecnologias que permitam às diversas
entidades envolvidas gerir de forma flexível a propagação dos
contextos de confiança estabelecidos entre elas
Dez-11
Gestão de Identidade e Aplicações
Federativas
6
Contexto de Segurança Composto
Contexto de Segurança Ponto-a-Ponto
Contexto de Segurança 1
Contexto de Segurança 2
SOAP
Browser
SSL/HTTPS
Web
Server
Appl.
Server
Domínio A
Web
Service
Platform
Data
Domínio B
O contexto de segurança entre um utilizador e um Service Provider pode
ser composto por múltiplos sub-contextos intermédios
Dez-11
Gestão de Identidade e Aplicações
Federativas
7
Standards de Federação
Emergência de standards suportados pela W3C, OASIS e
fornecedores de plataformas de middleware
• Para permitir a gestão de múltiplos contextos de segurança embebidos
na estrutura dos dados e das mensagens
XML Security: standard que permite encriptar e/ou assinar documentos em
XML
WS-Security: standard que permite encriptar e assinar as mensagens SOAP
(headers e body), ou transmitir credenciais.
• Para permitir trocar informações sobre a autenticação e autorização de
utilizadores entre Identity e Service Providers
SAML (Security Assertion Markup Language): standard que permite
propagar condições de autenticação e autorização entre entidades federadas
Outros standards propostos por organizações e software houses
para criar ambientes de autenticação federados
• Liberty Alliance (Sun, SUN, HP, Nokia, ...)
• WS-* (IBM-Microsoft)
Dez-11
Gestão de Identidade e Aplicações
Federativas
8
XML Security
Standard utilizado maioritariamente para permitir a
interoperabilidade e propagação de credenciais de segurança entre
os vários intervenientes em Federações e Web Services.
• Segurança ponto a ponto
• Segurança entre intermediários
• O facto do SOAP ser baseado em XML permite a generalização
desta tecnologia
XML Encryption
• Recomendação de 2002 da W3C (www.w3.org/Encryption)
• Permite a encriptação de todo ou parte de um documento XML
XML Signature
• Recomendação de 2008 da W3C (www.w3.org/Signature)
• Permite a assinatura digital de um documento em XML
Dez-11
Gestão de Identidade e Aplicações
Federativas
9
XML Encryption - estrutura
O tipo de dados encriptados pode ser
de diferentes tipos, incluindo
estruturas XML
O algoritmo de encriptação utilizado,
geralmente de chave simétrica
Informação opcional sobre a chave
de encriptação utilizada, que pode
ser enviada encriptada ou obtida por
referência
Os dados encriptados podem ser
incluídos na estrutura ou
referenciados
Informações adicionais sobre a
encriptação podem ser incluídas
(timestamp, encryption device, ...)
Especificação W3C: www.w3.org/TR/xmlenc-core
Dez-11
Gestão de Identidade e Aplicações
Federativas
10
XML Encryption - exemplo
Dados a encriptar:
um elemento XML
Dez-11
Gestão de Identidade e Aplicações
Federativas
11
XML Encryption – exemplo 1
Dados Encriptados:
um elemento XML
Dez-11
Gestão de Identidade e Aplicações
Federativas
12
XML Encryption – exemplo 2
Dados Encriptados:
Conteúdo de um elemento
específico da estrutura XML
A encriptação XML permite proteger selectivamente partes específicas de
um documento ou mensagem
Dez-11
Gestão de Identidade e Aplicações
Federativas
13
XML Signature - estrutura
Especificação W3C: www.w3.org/TR/xmldsig-core
Dez-11
Gestão de Identidade e Aplicações
Federativas
14
XML Signature - exemplo 1
Informação sobre o método de assinatura
Neste caso os dados assinados estão contidos no documento XML
(enveloped)
Dez-11
Gestão de Identidade e Aplicações
Federativas
15
XML Signature - exemplo 2
Informação sobre o método de assinatura
Certificado X509 identifica o assinante
A assinatura refere-se a um documento através do seu URI (detached)
Dez-11
Gestão de Identidade e Aplicações
Federativas
16
WS-Security
Web Services Security: especificação
desenvolvida pela IBM, Microsoft e VeriSign
• msdn2.microsoft.com/en-us/library/ms977312.aspx
Agora suportada pelo OASIS Web Services
Security (WSS) Technical Committee.
• www.oasis-open.org/committees/wss
Define extensões de segurança ao SOAP
para assegurar integridade de dados e
confidencialidade das mensagens
• Utilizando XML signature e XML encryption
Inserção de Security Headers na
mensagem, permitindo:
• Envio de Security Tokens
Certificados X.509
Tickets Kerberos
Assertions SAML
• Encriptação e Assinatura de partes
seleccionadas do message body
Com base nos artefactos contidos nos
Security Tokens
Dez-11
Gestão de Identidade e Aplicações
Federativas
17
WS-Security - exemplo
Security Token
Security Header
Dez-11
Gestão de Identidade e Aplicações
Federativas
18
Standards de Federação – SAML
SAML - Security Assertions Markup Language
• Definida pelo OASIS SSTC (IBM, SUN, AOL, Boeing, Nokia, ...)
A versão 1.0 aprovado como Standard em Novembro de 2002.
• Utilizada com enorme sucesso em inúmeros plataformas de SSO,
autenticação e standards de segurança (WS-Security, Liberty, ...)
A versão SAML 2.0 (Março 2005) introduz novas funcionalidades
essenciais para a federação:
•
•
•
•
Definição de novos perfis (Identity Provider, Service Provider, ...)
Utilização de pseudónimos dinâmicos para designar as identidades
Gestão de fim de sessão (single-logout)
Federação avançada, com suporte de:
IdP Discovery
Gestão de Atributos
Esta versão permite a convergência com outros standards de
federação (i.e.: Liberty Alliance).
Dez-11
Gestão de Identidade e Aplicações
Federativas
19
Componentes SAML
O SAML é constituído por um conjunto de componentes que em
conjunto permitem transferir identidade, autenticação, atributos e
autorização entre entidades que estabeleceram uma relação de
confiança
Source: SAML V2.0 Technical Overview - OASIS
Dez-11
Gestão de Identidade e Aplicações
Federativas
20
Assertions
Uma Assertion é um documento XML com uma estrutura própria,
que pode ser veículada por HTTP ou SOAP
As assertions permitem veicular declarações (statements) sobre
sujeitos, que podem ser de vários tipos:
• <AuthnStatement> declaração sobre a autenticação realizada
por um sujeito
• <AttributeStatement> declaração sobre os atributos de um sujeito
• <AuthzDecisionStatement> declaração sobre decisões
relacionadas com possíveis acções que o sujeito pode realizar
As assertions podem ser assinadas e ser parcial ou totalmente
encriptadas
Utilizando XML Signature e XML Encryption
Pode conter uma ou várias chaves ou certificados digitais
Dez-11
Gestão de Identidade e Aplicações
Federativas
21
Estrutura Genérica de uma Asserção
Identificador da
Asserção
Identificador do IdP
Validade da Asserção
Restrições
Características e
instante da autenticação
Correspondência entre
os perfis no IdP e no SP
Assinatura da Asserção
com a CP do issuer
Dez-11
Gestão de Identidade e Aplicações
Federativas
22
Exemplo
Source: SAML V2.0 Basics – Eve Maler (SUN)
Dez-11
Gestão de Identidade e Aplicações
Federativas
23
Protocolos SAML
Conjunto de protocolos de tipo Request/Response que governam as
interacções entre as várias entidades SAML
• Authentication Request Protocol
Conjunto de interacções que permitem obter declarações de identidade e
opcionalmente declarações de atributos
• Assertion Query and Request Protocol
Protocolo para obtenção de asserções
• Artifact Resolution Protocol
Mecanismo para passar mensagens através de referências, designadas
por artifacts
Por exemplo, uma forma de obter uma assertion com base numa
referência
• Name Identifier Mapping Protocol
Permite mapear dois identicadores SAML entre domínios distintos
• Name Identifier Management Protocol
Permite mudar os valores e formatos dos identificadores associados aos
sujeitos
• Single Logout Protocol
Define um mecanismo para permitir terminar de forma simultânea todas
as sessões associadas com um determinado sujeito
Dez-11
Gestão de Identidade e Aplicações
Federativas
24
Bindings
Os bindings determinam a forma como as mensagens dos
protocolos SAML são veiculadas pelos protocolos de transporte
• HTTP Redirect Binding:
Utilização da directiva redirect HTTP (302) para transportar
mensagens SAML
• HTTP Post Binding:
Transporte de mensagens SAML no conteúdo de uma form HTML
• HTTP Artifact Binding:
Define a forma de propagar um artifact usando forms ou URL query
strings
• SAML SOAP Binding:
Utilização do protocolo SOAP para veicular mensagens SAML
• SAML URI Binding:
Permite identificar uma assertion através de um URI
Dez-11
Gestão de Identidade e Aplicações
Federativas
25
Profiles
Definem a utilização dos vários componentes do SAML (asssertions,
protocolos e bindings) para estabelecer as interacções entre as
entidades envolvidas em vários cenários possíveis
• Web Browser SSO Profile:
Define a utilização do Authentication Request Protocol para
implementar Web SSO
• Identity Provider Discovery Profile:
Define uma forma para os Service Providers descobrirem o Identity
Provider associado a um dado utilizador
• Single Logout Profile:
Define a implementação do Single Logout Protocol com os vários
bindings possíveis
• Assertion Query/Request Profile
• Artifact Resolution Profile
Dez-11
Gestão de Identidade e Aplicações
Federativas
26
SSO Profile w/ Redirect/POST Bindings
Source: SAML V2.0 Technical Overview - OASIS
Dez-11
Gestão de Identidade e Aplicações
Federativas
27
SSO Profile w/ Redirect/Artifact Bindings
Source: SAML V2.0 Technical Overview - OASIS
Dez-11
Gestão de Identidade e Aplicações
Federativas
28
Browser SSO Profile w/ Artifact
Define um conjunto de interacções SAML necessárias para transferir a
autenticação do Identity Provider para o Service Provider.
1: O User Agent (browser) acede ao Service
Provider(SP) sem contexto de autenticação para
esse serviço.
2 e 3: O SP redirecciona o Browser para o Identity
Provider (IdP) associado de autenticação, com
um pedido de AuthnRequest.
4 e 5: O IdP autentica o principal e redirige o
Browser de novo para o SP, com um artifact que
referencia essa autenticação.
6 e 7: O SP utiliza faz um request SAML para pedir
a assertion referenciada pelo artifact recebido.
8: O IdP satisfaz o pedido de acesso ao browser,
baseado na autorização contida na assertion
recebida.
SAML Browser/Artifact dialog
Dez-11
Gestão de Identidade e Aplicações
Federativas
29
Browser SSO Profile (Redirect/Artifact)
A asserção é enviada do IdP para o
SdP em resposta ao envio do artifact
Dez-11
Gestão de Identidade e Aplicações
Federativas
30
Browser SSO Profile (Redirect/POST)
A asserção passa do IdP para
o SP transitando pelo User
Agent
Dez-11
Gestão de Identidade e Aplicações
Federativas
31
Referências
OASIS: Organization for the Advancement of Structured Information
Standards
• www.oasis.org
XML Security Library
• www.aleksey.com/xmlsec
SAML
• http://identitymeme.org/doc/draft-hodges-learning-saml-00.html
• http://saml.xml.org/saml-specifications
Web Services Security
• msdn2.microsoft.com/en-us/library/ms977312.aspx
Liberty Federation
• www.projectliberty.org
Shibboleth
• http://shibboleth.internet2.edu
SourceID (PingIdentity)
• http://www.sourceid.org
Dez-11
Gestão de Identidade e Aplicações
Federativas
32