SOLUÇÕES DE SOFTWARE DE GESTÃO DE IDENTIDADES

Transcrição

1 SOLUÇÕES DE SOFTWARE DE GESTÃO DE IDENTIDADES INFORMATION CARDS(IC) IC são identidades digitais pessoais que as pessoas podem usar online. Visualmente, cada IC tem uma imagem e um nome de cartão associado a ela que permite às pessoas organizarem as suas identidades digitais e facilmente escolherem uma que queiram usar para uma dada interacção. Interacção: Provedores de identidade emitem identidades digitais. Relying Parties aceitam identidades. O Sujeito é a pessoa, o partido que controla as interacções Pode escolher qual das suas identidades digitais usar junto do relying party. Sign-In com IC Um utilizador, usando IC, pode-se autenticar sem precisar de username e password para cada site. Um IC pode ser usado em múltiplos sites. Cada IC utiliza uma chave digital para cada realm onde a chave é pedida. Um realm pode ser um site ou um conjunto de sites. O uso de chaves distintas por realm significa que mesmo que uma pessoa seja enganada e faça login num site malicioso com o seu IC, uma chave diferente será usada para o site verdadeiro pelo que o atacante não consegue obter informação. Para maior segurança, muitos Identity Selectores providenciam métodos de detecção de phishing, onde o certificado HTTPS do site relying party é verificado e comparado contra uma lista de sites nos quais o utilizador tinha previamente usado o seu IC. Quando um novo site é visitado o utilizador é informado de que não tinha anteriormente usado o seu IC nesse site. Tipos de IC o Identity Selector Interoperability Profile especifica dois tipos de IC que um identity selector tem que suportar: IC Pessoal (ou auto-emitido): Estes cartões permitem emitir afirmações sobre nós mesmo aos sites que estão dispostos a aceitá-las. Estas afirmações podem incluir nome, morada, e- , telefones, site, data de nascimento, sexo e uma chave gerada para casa site onde o cartão é usado. IC Controlado: Permitem que provedores de identidade (que não nós mesmos) façam afirmações sobre nós aos sites dispostos a aceitá-las. Estas afirmações podem incluir qualquer informação que um relying party queira, que um identity provider consiga emitir e que o utilizador permita que seja enviada. Este tipo de cartões pode implementar qualquer um dos 4 métodos para autenticação do utilizador como dono do cartão: IC pessoal, certificado X.509, bilhete kerberos ou conjunto username/password.

2 É possível ter cartões costumizados. [Ver Projectos Bandit e Higgins] HIGGINS Higgins é uma framework open source que permite aos utilizadores e outros sistemas integrar informação de identidade, perfil e relacionamento nos múltiplos sistemas heterogéneos. Unificando as interacções de identidade (independentemente do protocolo/ formato) numa interface de utilizador i-cards- Higgins permite a existência de uma API de controlo de identidade. Assim os programadores podem escrever para uma API comum e não de forma individual para cada sistema de gestão de identidade. As aplicações de software escritas para Higgins permitem que as pessoas armazenem as suas identidades digitais e informação de perfil num local de sua escolha e a partilha dessa informação com companhias e outros partidos de forma controlada. Objectivos: 1. Providenciar uma experiência de utilizador consistente, baseada em i-cards para controlo e libertação dos dados de identidade. Isto é necessário de forma a garantir um mecanismo de confiança para autenticação e outras interacções menos vulnerável a phishing e outros ataques e que funcione para uma grande variedade de utilizadores e sistemas. 2. Dar aos utilizadores mais conveniência e controlo sobre informação pessoal distribuída. Higgins permite que os utilizadores tenham um único ponto de controlo sobre todas as suas identidades, preferências e relacionamentos. A falta de uma infraestrutura de confiança que permita que as pessoas partilhem a sua informação na internet garantindo, ao mesmo tempo, privacidade, está a limitar o crescimento e o uso da internet. O Projecto Higgins está a criar uma parte chave da infraestrutura necessária para garantir privacidade e controlo pessoal sobre a informação de identidade. 3. Providenciar uma API e modelo de dados para a integração virtual e federada de identidades e informação de segurança de uma grande variedade de fontes. Higgins define vários tipos de plugins para os provedores que permitem aos programadores a criação de adaptadores para sistemas, protocolos e tipos de tokens de segurança. 4. Providenciar adaptadores na forma de plugins, para que as fontes de dados existentes, cada uma usando protocolos e cenários diferentes, possam ser integradas na framework. Modelo de Dados: Fornece uma representação comum para dados de identidade, perfil e relacionamento para permitir interoperabilidade e portabilidade de dados pelos múltiplos sistemas. O modelo é descrito nas secções::

3 a) Information Cards A metáfora I-Card inclui o conceito de I-Card para o utilizador e o selector de identidade para os controlar. b) Tokens e afirmações Higgins suporta conceitos como afirmações, identidade digital, token de segurança e outros objectos usados pelos provedores de identidade, relying parties, provedores de serviços e selectores de identidade, c) Modelo de contexto de dados Descreve o modelo de dados que os torna portáteis e interoperáveis entre várias fontes de dados como directórios, bases de dados, redes de comunicação e redes sociais. Soluções: Uma solução Higgins é uma combinação específica de componentes Higgins que, quando são unidos e iniciados, resultam num serviço de infraestrutura ou numa aplicação. Entre elas estão serviços web provedores de identidades [STS IdP - WS-Trust Identity Provider (webapp e web service) e SAML2 IdP - SAML2 Identity Provider (webapp e web service) ] e serviços ou websites Relying Party [Extensible Protocol RP Website I- Card-enabled Relying Party site (webapp) ] Componentes: São blocos que permitem construir soluções. BANDIT O projecto Bandit é uma colecção open source de componentes para providenciar serviços de identidade consistentes. Implementa protocolos e especificações standards e abertos de tal forma que os serviços de identidade possam ser construídos, acedidos e integrados a partir de múltiplas fontes de identidade. Porções dos serviços de identidade são uma implementação da framework Higgins. O sistema Bandit suporta muitos métodos de autenticação e providencia controlo de credenciais centrado no utilizador. Está a construir serviços adicionais necessários ao controlo de acesso baseado em perfis e à emissão de registos para verificar o cumprimento de políticas alto nível. OPENID É um serviço partilhado de identidade que permite o uso de um único login em diferentes

4 sites usando uma única identidade digital, eliminando a necessidade de ter diferentes usernames e passwords para cada site. É um standard descentralizado, gratuito e aberto que permite que os utilizadores controlem a quantidade de informação pessoal que dão. Não é necessária a existência de uma autoridade central para confirmar a identidade digital do utilizador. Um identificador OpenID pode ser um URL ou um XRI. Para obter um URL o utilizador tem que se registar junto de um provedor de identidades. Um XRI é um identificador de internet desenhado especialmente para identidade digital. Como usar OpenID para autenticação: Um utilizador, para obter um identificador OpenID, apenas tem que se registar num provedor de identidades. Aí pode definir conjuntos de atributos (Personas) que pode depois usar em diferentes contextos. Estes conjuntos de atributos definem diversos perfis que podem conceder diferentes deveres e direitos ao utilizador, Um utilizador quer-se autenticar num site que permite autenticação com OpenID. Para o fazer, o terá que introduzir o seu identificador OpenID na caixa de login. Este site redirecciona o browser para o site do provedor de identidades onde o utilizador terá que fazer login, autenticando-se, assim, junto do provedor. Este login pode ser feito com um conjunto username/password ou com métodos mais seguros como o uso de smart cards. O site envia também para o provedor de identidades as informações de que precisa para poder autenticar o utilizador. O provedor pergunta ao utilizador se deseja partilhar essas informações com o site. Se o utilizador recusar, o browser é redireccionado de novo para o site mas este irá recusar a autenticação do utilizador pois este não lhe forneceu os dados necessários. Se o utilizador aceitar o pedido do provedor para confiar no site, o browser é redireccionado para esse site, juntamente com as credenciais do utilizador anteriormente pedidas. O site Relying party irá confirmar que as credenciais vieram realmente do provedor de identidades. Depois do identificador OpenID ser confirmado, a autenticação com OpenID é considerada bem sucedida e o utilizador fica com sessão iniciada no site. O protocolo OpenID não providencia, por si só, uma forma de autenticação mas se o provedor de identidades usar autenticação forte o OpenID pode ser usado para transacções seguras. SAML Security Assertion Markup Language. É uma linguagem baseada em XML para marcar asserções relacionadas com segurança sobre um security principal que é uma entidade que tem um identidade que pode ser autenticada. Especifica protocolos que usam a linguagem para tarefas como Web-based Single Sign On e data attribute exchange (Para autorização). Especifica Bindings (determinam como pedidos e respostas SAML são mapeados para

5 protocolos standard) e Perfis (Manifestação concreta de um caso-uso definido usando uma combinação particular de protocolos, asserções e bindings). As asserções SAML contêm afirmações sobre um sujeito que tem um identificador associado (endereço de e- , URL ou URI). As Asserções e variadíssimos mecanismos de segurança garantem autenticação mútua, integridade e confidencialidade SHIBBOLETH O sistema Shibboleth é uma arquitectura e implementação open source para uma infraestrutura de autenticação e autorização para identidade digital baseada em SAML. Identidades federadas permitem que a informação de um utilizador num domínio de segurança seja partilhada a outras organizações na federação. Isto permite single sign on por múltiplos domínios e remove a necessidade de manutenção de usernames e passwords. Os provedores de identidades fornecem informação sobre o utilizador e os provedores de serviços consomem essa informação, controlando o acesso ao conteúdo seguro. O controlo de acesso é feito comparando os atributos fornecidos pelo provedor de identidades com as regras definidas no provedor de serviços. Um atributo é qualquer informação sobre um utilizador, como por exemplo, o cargo que ocupa ou o nome. A identidade do utilizador é considerada um atributo e só é passada quando é explicitamente pedida, o que preserva a privacidade do utilizador. Os atributos podem ser escritos em Java ou retirados de directórios ou bases de dados. Os atributos mais usados normalmente são os standard X.520 mas novos atributos podem ser definidos arbitrariamente desde que sejam compreendidos e interpretados de igual forma pelo provedor de identidades e pelo provedor de serviços numa transacção Confiança A confiança entre domínios é implementada usando criptografia de chave pública (normalmente certificados de servidor SSL) e meta dados que descrevem provedores. O uso da informação passada é controlado através de acordos. As federações são usadas normalmente para simplificar estes relacionamentos, agregando um grande número de provedor que concordam com o uso de regras e contratos comuns. WSO2 IDENTITY SOLUTION A solução de identidade WSO2 permite que sites Java e LAMP providenciem autenticação forte baseando-se na tecnologia Microsoft CardSpace. Também inclui OpenID e OpenID Information Cards o que permite que possa ser adoptada facilmente para autenticação web based. Esta tecnologia assenta nos standards abertos SAML (suporta 2.0) e WS-Trust.

6 Oferece características de segurança como um provedor de identidades simples de usar, controlado por uma consola web e suporte a interoperabilidade com componentes de CardSpace de múltiplos vendedores, incluindo os providenciados pela Microsoft.NET. Trabalha com Lightweight Directory Access Protocol (LDAP) e Microsoft Active Directory o que permite que seja implementado como solução de controlo de identidades em empresas. Fornece um conjunto de componentes Relying Party que funcionam com os webservers mais comuns, para permitir autenticação CardSpace e OpenID em aplicações web. Estes componentes englobam um provedor de identidades e um conjunto de componentes Relying Party. Provedor de Identidades: O Provedor de identidades tem um consola de controlo simples. Além de ter capacidade para conexão às user stores comuns -LDAP/Active Directory, JDBC -, tem uma user store incluída. Suporta o conjunto default de afirmações CardSpace e os dialectos e tipos comuns de afirmações. Permite manter registos de auditoria. Tem capacidade para revogar Information Cards e para emitir Information Cards baseados numa credencial username-token e em credencial auto-emitida. Tem suporte a OpenID e pode emitir OpenID Information cards. Também suporta SAML 2.0. Componentes Relying Party: O conjunto de componentes Relying Party inclui um módulo APACHE HTTPD e um filtro Java Sevlet. O módulo Apache HTTPD (mod-cspace) adiciona suporte a autenticação CardSpace para conteúdo web estático e suporte para qualquer linguagem de scripting suportada pelo Apache2. Inclui também uma interface para fácil integração para os programadores. Suporta frameworks para controlo de conteúdo como Drupal. Tem um componente Java Servlet Filter relying party que providencia uma plugin intuitiva para permitir aos programadores de aplicações web J2EE usar autenticação CardSpace. Suporta afirmações multi valor e suporta OpenID relying party. Provedor de Identidades OpenID: Suporta os standards OpenID 1.1 e 2.0 e o suporte basea-se na biblioteca JAVA OpenID4Java. Implementa as extensões ao modelo OpenID, incluindo Attribute Exchange e Provider Authentication Policy Extension and Simple Registration(PAPE).