Partilhar via

Federação de identidades em um mundo de serviços Web

  • Artigo

Aviso de direitos autorais

 

© 2001-2003 International Business Machines Corporation, Microsoft Corporation. Todos os direitos reservados.

Abstrair

Este documento descreve os problemas em torno do gerenciamento de identidade federada e descreve uma solução abrangente com base nas especificações de serviços Web descritas no roteiro WS-Security e outras especificações relacionadas de serviços Web.

A abordagem descrita neste white paper, que será definido ainda mais na especificação WS-Federation, apresenta um provedor de identidade como uma classe de serviço de token de segurança. Dessa forma, ele usa os mecanismos de WS-Trust e WS-Federation para criar e intermediar a confiança dentro e entre federações. Além disso, os mecanismos são definidos para logon único e saída, compartilhamento de atributos com base em políticas de autorização e privacidade e processamento integrado de pseudônimos (aliases usados em diferentes sites/federações).

Juntos, as especificações identificadas neste artigo fornecem um conjunto abrangente e integrado de protocolos para mensagens transacionadas confiáveis seguras dentro e entre federações compondo com outras especificações de segurança e serviço Web.

Resumo

Nos últimos anos, os aplicativos Web evoluíram de aplicativos de entrega de conteúdo simples para ferramentas sofisticadas de produtividade de negócios e um mecanismo de integração de aplicativos dentro e entre empresas. O crescimento dos serviços Web e Web demonstrou a necessidade de soluções abertas e interoperáveis para muitos problemas técnicos.

Neste documento, nos concentramos em um conjunto específico de problemas relacionados à segurança. Estes incluem:

Como determinar os serviços Web de identidade e localização corretos: as organizações precisam de uma maneira padrão para que os solicitantes de serviço (clientes e parceiros) encontrem os serviços Web certos de uma determinada empresa e para que os provedores de serviços de negócios identifiquem e exponham com segurança o Serviço Web correto a apenas solicitantes autorizados.

Como determinar o conjunto de credenciais para habilitar a invocação segura de serviços Web: um meio padronizado para que os solicitantes de serviços corporativos invoquem com segurança os Serviços Web com o conjunto certo de autenticação, autorização e direitos.

Como federamos com segurança os serviços Web: uma maneira padrão de permitir que as empresas forneçam serviços diretamente para clientes registrados em outras empresas ou instituições (parceiras). Dentro de uma federação de serviços, uma empresa pode obter informações confiáveis sobre um usuário da organização inicial do usuário (ou serviço de fornecimento de informações). A empresa não precisa registrar e manter a identidade desse usuário, e o usuário é impedido de ter que obter e lembrar de um novo logon para interagir com a empresa.

Como habilitar ode Confiança Entre Empresas e Entre Domínios: uma maneira padrão de estabelecer e refletir a confiança entre as organizações. Esse é um problema fundamental para os Serviços Federados.

Como habilitar a identidade federada e o mapeamento de atributos: mecanismos e procedimentos bem compreendidos para mapear informações confiáveis sobre um usuário estrangeiro (por exemplo, usuários de parceiros de negócios) em informações de autenticação e autorização utilizáveis pelos serviços existentes de uma empresa.

Como habilitar transações seguras e confiáveis: uma maneira padrão de trocar mensagens em um contexto seguro, confiável e transacionado. Especificações anteriores (por exemplo, WS-ReliableMessaging e WS-Transaction) fornecem suporte para troca de mensagens confiáveis e transações comerciais. Neste documento, discutimos o suporte federado à segurança.

IBM, Microsoft e nossos parceiros pretendem trabalhar com clientes, parceiros e entidades de padrões para desenvolver as especificações descritas aqui e garantir que essas especificações se componham bem com outros elementos da arquitetura de serviços Web. Para garantir a interoperabilidade e a implementação consistente das várias especificações propostas descritas neste artigo, a IBM, a Microsoft e nossos parceiros trabalharão em estreita colaboração com as organizações de padrões, a comunidade de desenvolvedores e com organizações do setor, como WS-I.org para desenvolver perfis e testes de interoperabilidade que fornecerão diretrizes aos fornecedores de ferramentas.

Como a terminologia varia entre tecnologias, este documento define vários termos que podem ser aplicados consistentemente entre os diferentes formatos e mecanismos de segurança. Consequentemente, a terminologia usada aqui pode ser diferente de outras especificações e é definida para que o leitor possa mapear os termos para seu vocabulário preferido. Consulte o Terminologia seção para um resumo desses termos e sua definição e uso.

1 Introdução e motivação

O gerenciamento federado de identidades representa um desafio significativo para indivíduos e empresas. Este capítulo explora o problema, identifica as partes afetadas por ele e conclui com as principais metas para soluções viáveis.

Qual é o problema do Gerenciamento federado de identidades?

A rede de valor de uma empresa abrange muitas organizações, sistemas, aplicativos e processos de negócios. Vários componentes diferentes compõem essa rede de valores, incluindo clientes, funcionários, parceiros, fornecedores e distribuidores. Não há uma única entidade ou empresa que possa pretender gerenciar ou controlar centralmente as informações de identidade sobre seus constituintes nesta rede de valores de ponta a ponta. Mesmo em uma única empresa, pode haver várias fontes autoritativas de dados de identidade que precisam ser gerenciados de forma independente e autônoma dentro das unidades de negócios.

Essa abordagem de centralização como o princípio subjacente à colaboração entre empresas introduz um atrito significativo na colaboração, integração e automação de negócios eletrônicos, resultando em altos custos de gerenciamento de identidade e redução da eficiência. Com a centralização, o custo de gerenciamento do ciclo de vida das identidades de usuário é muito alto. A maioria das empresas precisa gerenciar identidades de funcionários, parceiros de negócios e clientes. Além disso, as relações entre a empresa e esses indivíduos mudam com bastante frequência e cada alteração requer uma ação administrativa.

Em alguns casos, as empresas gostariam de terceirizar algumas funções de segurança para as partes que gerenciam a identidade (como fazem hoje para empresas de cartão de crédito em contextos transacionais), mas elas não podem fazer isso por dois motivos: primeiro, não há provedores de identidade de terceiros atendendo a mercados diferentes de transações financeiras do consumidor, e segundo, não há modelos de negócios e responsabilidade que tornem seguro depender dos serviços de um provedor de identidade de terceiros para serviços diferentes de transações financeiras do consumidor.

Outras empresas querem aproveitar as identidades que mantêm para habilitar interações comerciais adicionais. No entanto, é difícil estabelecer os mecanismos de confiança para permitir que as entidades sejam federadas entre os limites empresariais. Além disso, as empresas que gerenciam cada vez mais a identidade correm o risco de danos à reputação ou responsabilidade regulatória se suas ações de gerenciamento de identidade liberarem ou usarem informações de maneiras que entram em conflito com os direitos de privacidade individuais. Isso aumenta muito o risco de gerenciar a identidade.

Da perspectiva de um indivíduo, existem várias identidades, tanto pessoais quanto profissionais. O indivíduo também tem um problema de gerenciamento de identidade causado pela incapacidade de reutilização de identidades.

O Gerenciamento federado de Identidade oferece flexibilidade entre empresas e, ao mesmo tempo, permite que as empresas desabilitem a carga e simplifiquem os custos de gerenciamento de identidade. Isso permite que as empresas busquem metas de integração de negócios que melhor se alinhem com seu modelo de negócios, política de TI e metas e requisitos de segurança e governança.

Quem tem o problema do Gerenciamento federado de identidades?

A principal barreira de integração está na integração entre empresas devido à falta de modelos de comunicação seguros. O problema afeta uma ampla gama de empresas, incluindo:

  • Organizações médias e grandes que usam informações de identidade para fornecer serviços aos consumidores (por exemplo, provedores de serviços de viagem baseados na Web).
  • Organizações médias e grandes que fazem negócios entre si e precisam trocar informações sobre identidades de indivíduos (por exemplo, uma companhia aérea e uma agência de aluguel de carros, ou um hospital e um provedor de seguro de saúde)
  • As organizações que precisam integrar aplicativos empresariais em toda a empresa e a cadeia de valores de clientes e fornecedores (por exemplo, uma cadeia de fornecedores) e precisam autorizar seus funcionários a realizar transações em nome da organização.
  • Organizações que terceirizam serviços, como RH e benefícios, a terceiros, mas aplicam suas próprias marcas a esses serviços terceirizados (por exemplo, uma organização que fornece a seus funcionários várias opções de plano de aposentadoria ou plano médico por meio de seu próprio portal de RH interno) e que, portanto, devem compartilhar informações de identidade dos funcionários com os provedores de serviços.
  • Organizações (intermediários, agentes, agregadores) cujo modelo de negócios é orientado por "possuir a experiência do cliente" por motivos de desintermediação.
  • Organizações que fornecem portais de negócios integrados baseados em identidade de serviço completo (serviços financeiros, serviços de seguro, assinatura etc.) agregando serviços em vários provedores de terceiros.

Como observado anteriormente, os indivíduos envolvidos em atividades baseadas na Web também sofrem esse problema, pois normalmente têm um grande número de identidades independentes que devem criar e gerenciar.

Objetivos

As principais metas dos Serviços federados de identidade são as seguintes:

  • Reduza o custo do gerenciamento de identidade reduzindo a duplicação de esforço; A identidade de cada indivíduo quase sempre é gerenciada por uma organização confiável (como o banco, o empregador ou o médico do indivíduo).
  • Aproveite o trabalho que esses gerentes de identidade existentes já fizeram dando a outras partes acesso (conforme necessário e com proteção de privacidade apropriada) às informações de identidade relevantes.
  • Preservar a autonomia de todas as partes - a escolha da tecnologia de autenticação por um gerente de identidade não deve impor essa tecnologia às partes que dependem de suas informações de identidade. A escolha de um sistema operacional ou protocolo de rede ou banco de dados por um gerenciador de identidades não deve impor a mesma opção aos seus parceiros.
  • Respeite as estruturas e contratos de confiança pré-existentes dos negócios. Inscrever-se para receber informações de identidade de um provedor de identidade não deve exigir que uma organização estabeleça uma relação de confiança com qualquer outra parte que não seja o provedor de identidade e não deve exigir a adoção de nenhuma tecnologia de autenticação de usuário específica.
  • Proteja a privacidade dos indivíduos respeitando e impondo fortemente as preferências do usuário que regem o uso de informações individualmente identificáveis, observando regras de privacidade governamentais e regionais, buscando o consentimento do usuário para novos usos e implementando mecanismos fortes de manutenção de registros e responsabilidade para garantir que as práticas de privacidade sejam seguidas.
  • Crie padrões abertos para habilitar transações confiáveis seguras para empresas e indivíduos.

2. Logon único federado e gerenciamento de identidade

O apelo das federações é que elas se destinam a permitir que um usuário percorra perfeitamente diferentes sites dentro de uma determinada federação. Este documento se concentra especificamente na questão do gerenciamento federado de identidades e não na maior questão da federação geral (além da segurança). Devido às relações de confiança estabelecidas entre os participantes da federação, um participante é capaz de autenticar um usuário e, em seguida, atuar como um de parte emissora para esse usuário. Outros participantes da federação tornam-se partes confiáveis. Ou seja, eles dependem de informações fornecidas sobre o usuário pela parte emissora, sem o envolvimento direto do usuário. Em alguns casos, o usuário pode ser anônimo para a terceira parte confiável, por exemplo, devido aos diferentes mecanismos de autenticação e ao uso de mecanismos de autenticação de terceiros.

A flexibilidade e o apelo do modelo de Serviços Web são sua base de blocos de construção em que as empresas podem facilmente criar novos serviços para fornecer modelos de negócios inovadores ou vincular sua rede de cadeia de valores de forma mais eficiente por meio de relacionamentos rígidos com parceiros, fornecedores, clientes e funcionários. Esse modelo só poderá ser bem-sucedido se permitir que clientes, parceiros e usuários finais naveguem facilmente entre sites da Web que dão suporte a esses serviços sem precisar se autenticar ou se identificar constantemente nos vários sites ou manter com redundância informações pessoais em cada membro dentro da federação de negócios.

Infelizmente, os esquemas atuais para autenticar usuários e obter informações de atributo do usuário (por exemplo, informações de cartão de crédito) normalmente forçam o usuário a se registrar em cada empresa de interesse, exigindo constantemente que o usuário se identifique e se autentique (normalmente com um nome de usuário e senha) e forçando a empresa a administrar uma base grande e rápida de identidades que não estão sob o controle da empresa. Esse modelo é um enorme impedimento para a adoção dos Serviços Web - e é uma dor de cabeça para usuários e empresas.

Outra desvantagem do modelo predominante é que uma determinada empresa pode não estar disposta a "dar" partes de suas informações do cliente a um parceiro de negócios, desejando, em vez disso, manter e controlar a relação do cliente.

As federações fornecem um mecanismo flexível simples para identificar e validar usuários de organizações parceiras e fornecer-lhes acesso contínuo a sites da Web dentro dessa federação confiável sem a necessidade de autenticação nova com uma senha. Além disso, os padrões de federação também lidam com a questão de fornecer atributos confiáveis (por exemplo, certificados X509, certificados de atributo X509v3, tokens Kerberos, declarações SAML) sobre usuários (por exemplo, incluindo funções e informações de grupo) permitindo regras de privacidade e específicas aos negócios.

O conceito e a noção de Logon Único Federado e Identidades podem ser ilustrados usando um exemplo simples:

O usuário John Doe trabalha para uma empresa farmacêutica chamada Pharma456.com; John tem uma conta com Pharma456.com e é necessário se autenticar no Pharma456.com para acessar seus recursos. Como funcionário, João tem alguns benefícios com a empresa, como contas e serviços em empresas parceiras. Neste exemplo, os serviços de poupança da empresa são gerenciados por uma empresa de serviços financeiros chamada RetireAccounts.com (um provedor de serviços) e os serviços de investimento são gerenciados por uma empresa chamada InvestAccounts.com (um provedor de serviços). Para acessar os recursos em um parceiro, por exemplo, o portal de poupança hospedado pelo RetireAccounts.com, um usuário deve se autenticar no RetireAccounts.com. A autenticação para RetireAccounts.com requer que um usuário forneça seu SSN (Número de Seguridade Social), um Identificador de Funcionário (um identificador exclusivo emitido pelo empregador - neste caso Pharma456.com) e um número de PIN pessoal (específico para RetireAccounts.com).

Sem federação, John Doe tem que se autenticar explicitamente no site RetireAccounts.com para acessar sua conta poupança, embora ele já tenha se autenticado para Pharma456.com e acessado os serviços Web RetireAcounts.com por meio do portal de funcionários do Pharma456.com.

No entanto, com o logon único federado, o John Doe pode fazer logon no Portal do funcionário, clicar em um link do portal para acessar suas informações de conta poupança no site do parceiro (RetireAccounts.com) e não precisar se autenticar novamente ou fornecer informações adicionais no site do parceiro.

A federação também garante que identidades distintas para o mesmo usuário entre empresas possam ser vinculadas com segurança entre duas empresas usando técnicas federadas de gerenciamento. Os participantes da federação podem trocar informações de identidade de modo que a empresa confiável possa validar independentemente a identidade do usuário em seu domínio.

O logon único federado entre um domínio emissor (Pharma456.com) e um domínio confiável (o provedor de serviços federado RetireAccounts.com) facilita a transferência segura e confiável de identificadores de usuário e outras informações relacionadas a atributos (como funções de autorização e associações de grupo e direitos de usuário, como EmployeeID, SSN e PIN #). O Gerenciamento de Identidade Federado define o processo pelo qual a terceira parte confiável (RetireAccounts.com) é capaz de determinar um identificador localmente válido para o usuário com base nas informações (confiáveis) recebidas da parte emissora. Os detalhes da transferência podem envolver várias mensagens entre a empresa e a empresa de origem do usuário (e mensagens para serviços auxiliares), mas elas são tratadas de forma transparente para o usuário.

Para habilitar a federação, apresentamos provedores de identidade, serviços de atributo e serviços de pseudônimo que são exemplificados na figura acima.

Provedores de identidade, como aqueles em Pharma456.com, InvestAccounts.com e RetireAccounts.com, fornecem identidades que são usadas para mapeamento/indexação local (por exemplo, informações da conta). Usando mecanismos de confiança e federação, juntamente com políticas de confiança, essas identidades permitem que as federações compartilhem e mapeiem identidades automaticamente.

Os serviços de atributo fornecem uma maneira de federar o acesso a atributos autorizados para identidades federadas. No exemplo acima, à medida que John Doe visita o portal de cada parceiro, o serviço de portal pode acessar os atributos de João (aqueles aos quais ele está autorizado) para obter as informações necessárias e personalizar a experiência. Para garantir a privacidade, John Doe tem controle total sobre quais atributos estão autorizados a quais serviços. Esses acessos de atributo podem ser monitorados e registrados para garantir a conformidade com as políticas de privacidade declaradas estabelecidas com Pharma456.com funcionários. Não determinamos um tipo específico de serviço de atributo, mas, em vez disso, permitimos que serviços diferentes, como UDDI, sejam usados.

Os mecanismos de confiança fornecem uma maneira de as partes confiáveis associarem um nível de confiança a uma autoridade ou identidade e usá-lo para mapeamentos locais. No entanto, há situações em que as preocupações com a privacidade desejam que esse mapeamento seja opaco para o serviço de destino. Ou seja, o alvo sabe consistentemente que é "John Doe" baseado na persona local de John, mas não entende ou conhece a identidade global. Os serviços de pseudônimo fornecem um mecanismo de mapeamento que pode ser usado para facilitar esse mapeamento de identidades confiáveis entre federações para proteger a privacidade e a identidade.

O Gerenciamento federado de identidade (incluindo o Logon Único Federado) é um conceito muito mais amplo do que as soluções de Logon Único da Web. Embora este exemplo realce um caso de uso para o cenário B2C, em que o SSO da Web é um recurso importante, o Logon Único Federado é um conceito mais amplo que permite que as empresas criem uma estrutura completa para negócios eletrônicos B2B e B2C seguros.

3. Modelo de identidade federada

O modelo de identidade federado se baseia e integra as especificações de infraestrutura e segurança dos serviços Web para formar um modelo de segurança consistente e extensível. O modelo de federação estende o modelo de WS-Trust para descrever como os provedores de identidade atuam como serviços de token de segurança e como atributos e pseudônimos podem ser integrados ao mecanismo de emissão de token para fornecer mecanismos federados de mapeamento de identidade.

Em resumo, as entidades de segurança entrarão e sairão dos Provedores de Identidade (ou serviços de token de segurança). Isso pode ser feito por meio de mensagens explícitas ou implicitamente como tokens de solicitação de entidades de segurança. Uma entidade de segurança solicita tokens para recursos/serviços e os tokens emitidos podem representar a identidade primária da entidade de segurança ou algum pseudônimo apropriado para o escopo. O Provedor de Identidade (ou STS) emite mensagens para destinatários interessados (e autorizados). As entidades de segurança são registradas com os serviços de atributo/pseudônimo e atributos e pseudônimos são adicionados e usados. Os serviços podem consultar serviços de atributo/pseudônimo usando as identidades fornecidas (potencialmente anônimas, o que significa que a parte que solicita as informações tem um token opaco e não está ciente da identidade real) para obter informações autorizadas sobre a identidade.

Especificações de segurança dos Serviços Web

O modelo e a abordagem descritos neste artigo aproveitam as especificações descritas no white paper, Security em um mundo de serviços Web: uma arquitetura e um roteiro propostos. Cada uma das principais especificações é resumida abaixo:

  • WS-Security descreve como anexar cabeçalhos de assinatura e criptografia a mensagens SOAP. Além disso, descreve como anexar tokens de segurança, incluindo tokens de segurança binários, como certificados X.509 e tíquetes Kerberos, a mensagens.
  • WS-Policy representa um conjunto de especificações que descrevem os recursos e restrições das políticas de segurança (e outras empresas) em intermediários e pontos de extremidade (por exemplo, tokens de segurança necessários, algoritmos de criptografia compatíveis, regras de privacidade) e como associar políticas a serviços e pontos de extremidade.
  • WS-Trust descreve uma estrutura para modelos de confiança que permite que os serviços Web interoperem com segurança solicitando, emitindo e trocando tokens de segurança.
  • WS-Privacy descreverá um modelo de como os serviços Web e solicitantes declaram preferências de privacidade e declarações de prática de privacidade organizacional.
  • WS-SecureConversation descreve como gerenciar e autenticar trocas de mensagens entre partes, incluindo trocas de contexto de segurança e estabelecer e derivar chaves de sessão.
  • WS-Federation descreve como gerenciar e intermediar as relações de confiança em um ambiente federado heterogêneo, incluindo suporte para identidades federadas, compartilhamento de atributos e gerenciamento de pseudônimos.
  • WS-Authorization descreverá como gerenciar dados de autorização e políticas de autorização.

Além disso, várias outras especificações importantes dos serviços Web completam a camada de base das especificações:

  • WS-Addressing descreve como especificar informações de identificação e endereçamento para mensagens.
  • WS-MetadataExchange descreve como trocar metadados, como WS-Policy informações e WSDL entre serviços e pontos de extremidade.
  • WS-ReliableMessaging descreve como garantir a entrega confiável de mensagens na presença de redes não confiáveis.
  • WS-Transactions e WS-Coordination descrevem como habilitar operações transacionadas como parte das trocas de mensagens do serviço Web.

A combinação das especificações acima e perfis de interoperabilidade permitirá que os clientes criem facilmente serviços Web transacionados confiáveis e seguros interoperáveis que se integram dentro e entre federações compondo especificações de federação e segurança com outras especificações de serviços Web.

Perfis

Este artigo descreve um modelo geral que pode ser usado em ambientes diferentes. Especificamente, esse modelo pode ser usado em ambientes que consistem em solicitantes passivos, como navegadores da Web ou solicitantes ativos, como solicitantes SOAP.

As especificações de federação fornecem um modelo e uma estrutura gerais; os perfis descrevem como o modelo é aplicado nesses diferentes ambientes. Perfis adicionais podem ser especificados para integrar o modelo em outros ambientes.

Cada especificação de perfil define como os mecanismos em WS-Federation são aplicados, se em tudo, a um determinado ambiente, como solicitantes passivos ou ativos.

Consequentemente, os mecanismos descritos neste artigo (provedores de identidade, entrada/saída, tokens de segurança, atributos, pseudônimos, . . . ) se aplicam a solicitantes passivos (como navegadores da Web) e solicitantes ativos (como serviços Web que atuam como clientes e serviços), bem como a outros perfis que podem ser definidos no futuro.

Provedores de identidade

A federação começa com uma noção de identidade. Ou seja, o solicitante ou o representante do solicitante (um provedor de identidade que é o proprietário autoritativo para esses dados de identidade) declara uma identidade e o Provedor de Identidade verifica essa declaração. Em seguida, a federação torna-se uma função de confiança (direta, agenciada e delegada) entre provedores de identidade e aqueles que dependem da determinação de identidade do provedor. Às vezes, a terceira parte confiável precisa da capacidade de correlacionar as identidades de vários provedores - por exemplo, correlação de uma identidade em uma verificação, em um cartão de crédito e em uma carteira de motorista.

Um STS (serviço de token de segurança) é um serviço genérico que emite/troca tokens de segurança usando um modelo comum e um conjunto de mensagens. Dessa forma, qualquer serviço Web pode, por si só, ser um STS simplesmente dando suporte à especificação de WS-Trust. Consequentemente, há diferentes tipos de serviços de token de segurança que fornecem diferentes serviços complementares. Um de provedor de identidade (IP) é um tipo especial de serviço de token de segurança que, no mínimo, executa a autenticação de entidade par e pode fazer declarações de identidade ou afiliação em tokens de segurança emitidos. Observe que, em muitos casos, um IP e STS são intercambiáveis e muitas referências neste documento identificam ambas.

O modelo de federação baseia-se na estrutura definida em WS-Trust aproveitando o mecanismo de emissão e troca de tokens para incluir identidades de emissão e federação.

O exemplo a seguir ilustra uma possível combinação de um IP e STS para acessar um serviço. Neste exemplo, (1) um solicitante obtém um token de segurança de identidade de seu IP (Business456.com) e, em seguida, apresenta/fornece a declaração (token de segurança) para o STS para Fabrikam123. Se Fabrikam123.com confiar Business456.com e a autorização for aprovada, o STS retornará um token de acesso ao solicitante. O solicitante (3) usa o token de acesso em solicitações para Fabrikam123.com.

Neste exemplo, a resposta na etapa 1 é assinada por Business456.com (o IP confiável) e o token de segurança retornado na resposta é relativo a Fabrikam123.com (por exemplo, eles o emitiram).

Um modelo alternativo, que é discutido abaixo, permite que o serviço Fabrikam123.com registrar um token de segurança com um serviço de pseudônimo e buscar esse pseudônimo quando necessário. Isso permite que o serviço gerencie o mapeamento e ainda forneça um nível de privacidade para o solicitante.

Logon Único e Sign-Out

O modelo descrito neste artigo e nas especificações de WS-Federation permite diferentes noções de sessões de usuário como gerenciadas por serviço e gerenciadas por solicitantes. Um exemplo de uma sessão gerenciada pelo serviço seria a criação e o gerenciamento de cookies em uma sessão do navegador da Web. Um exemplo de uma sessão gerenciada pelo solicitante é um solicitante de serviço Web que obtém um token e o usa por um período de tempo e, em seguida, descarta o token antes de sua expiração. As noções de de saída são introduzidas para permitir que perfis diferentes especifiquem como essas transições se aplicam a cada perfil.

A finalidade de de Logon Único é estabelecer tokens de segurança necessários para acessar um recurso na Web de domínio/realms federados. Da mesma forma, de saída federada é usado para limpar qualquer estado armazenado em cache e tokens de segurança que possam existir dentro da federação. Para habilitar isso, os mecanismos são necessários para fornecer mensagens de entrada e saída federadas emitidas pelo Provedor de Identidade para partes autorizadas de ações de entrada e saída (permitindo que elas executem todas as ações de instalação/limpeza necessárias).

Atributos e pseudônimos

Como discutido anteriormente, há um desejo de obter informações sobre uma identidade (ou qualquer recurso federado) - como fornecer uma saudação "olá" ou obter o cep do solicitante para personalizar uma experiência - e isso pode ser fornecido por um serviço de atributo. Essa especificação permite que diferentes tipos de serviços de atributo, como UDDI, sejam usados.

É fundamental que essas informações sejam regidas por regras de autorização e semântica de privacidade. Da mesma forma, espera-se que diferentes atributos sejam compartilhados de forma diferente e tenham diferentes graus de privacidade e proteção (por exemplo, nome versus sobrenome). Consequentemente, cada expressão de atributo deve ser capaz de expressar sua própria política de controle de acesso e a política deve levar em conta os escopos e entidades de segurança associados que podem falar pelos escopos. Por exemplo, um usuário final (pessoa) pode querer configurar o seguinte: "meus serviços na minha intranet podem ter acesso ao meu sobrenome, enquanto outros serviços não podem sem permissão expressa de mim".

Um serviço de atributo pode aproveitar os repositórios existentes e pode fornecer algum nível de organização ou contexto. No namespace organizacional, as entidades de segurança individuais são registradas e um conjunto de propriedades de atributo (essencialmente pares nome/valor em que o nome é um nome de propriedade de cadeia de caracteres e o valor é um elemento XML) representado em XML são associados à entidade de segurança.

É importante observar que cada atributo pode ter suas próprias regras de autorização de segurança e política de privacidade, permitindo que as entidades de segurança controlem a quem e como as informações são divulgadas.

Diferentes serviços de atributo têm recursos diferentes que são expressos em seu documento de política.

Além dos serviços de atributo, também pode haver serviços de pseudônimo. Um serviço de pseudônimo permite que uma entidade de segurança tenha diferentes aliases em diferentes recursos/serviços ou em domínios/reinos diferentes. Alguns provedores de identidade usam identidades fixas em seus tokens de segurança. Em alguns cenários, é desejado garantir o anonimato dos tokens; pseudônimos fornecem um mecanismo para habilitar esse anonimato. Geralmente, há uma compensação da capacidade de gerenciamento que deve ser determinada pela entidade de segurança (ou seja, quanto mais identidades, maior o potencial para problemas de gerenciamento).

Deve-se observar que, em alguns casos, os serviços de atributo e pseudônimo serão combinados e, em alguns casos, serão serviços separados.

Por exemplo, um solicitante autentica-se para Business456.com com sua identidade primária "Fred.Jones". No entanto, no Fabrikam123.com, ele é conhecido como "Freddo". Para preservar o anonimato, Business456.com pode emitir uma identidade diferente sempre que Fred.Jones entrar, aparecendo assim "anônimo" como ilustrado na etapa 3 na figura abaixo. Fabrikam123.com pode definir "Freddo" como o nome local desse solicitante em Fabrikam123.com (etapa 4) e ter o serviço de pseudônimo, que entende o nome anônimo, fornecer o mapeamento para "Freddo".

Na próxima vez que o solicitante entrar no IP Business456.com (etapa 1 abaixo), ele poderá receber um novo identificador, como "XYZ321@Business456.com" (etapa 2 abaixo). Como Business456.com IP tem o mapeamento discutido acima, o serviço Web em Fabrikam123.com agora pode solicitar um pseudônimo para XYZ321@Business456.com em Fabrikam123.com (etapa 4 abaixo) e obter de volta o que eles definiram anteriormente - nesse caso, é "Freddo@Fabrikam123.com" (etapa 5 abaixo).

O serviço de pseudônimo é capaz de fazer isso porque tem a capacidade de fazer o back-map "XYZ321@Business456.com" em uma identidade conhecida em Business456.com que tenha associado a ele pseudônimos para domínios/reinos diferentes. Esse mapeamento de back-mapping ocorre com base em uma relação de confiança entre o IP e o serviço de pseudônimo. Da mesma forma, há uma relação de confiança entre o recurso e o serviço de pseudônimo (possivelmente inicializado pelo IP) que permite que o recurso seja autorizado a obter e definir pseudônimos.

Como alternativa, o Provedor de Identidade (ou STS) pode operar lado a lado com o serviço de pseudônimo. Ou seja, o solicitante solicita seu Provedor de Identidade (ou STS) para um token para um domínio/realm ou recurso/serviço de confiança especificado. O STS procura pseudônimos e emite um token que pode ser usado no recurso/serviço especificado, conforme ilustrado abaixo:

Conforme ilustrado, há várias abordagens diferentes com suporte neste modelo de Identidade Federada em que os pseudônimos podem ser usados para ajudar a manter a privacidade. Cada um tem características diferentes de capacidade de gerenciamento e privacidade, permitindo que cada provedor e entidade escolham a solução apropriada para atender a seus requisitos específicos.

Resumo 4

Neste documento, propomos um modelo integrado de federação de serviços Web que permite que as partes emitam e confiem em informações de outros membros de federações e para intermediar a confiança e os atributos entre federações de maneira segura que mantenha a privacidade individual e empresarial.

Esse modelo se integra à segurança dos serviços Web e às especificações relacionadas para habilitar transações confiáveis seguras entre solicitantes e serviços dentro e entre federações.

A IBM e a Microsoft acreditam que essa é uma etapa importante na definição de uma estratégia abrangente de segurança de serviços Web.  Isso reflete os desafios e soluções que identificamos até agora. À medida que continuamos a trabalhar em conjunto com clientes, parceiros e organizações de padrões para proteger os serviços Web, esperamos que haja ideias e especificações adicionais necessárias para concluir a estratégia. 

Terminologia

Como a terminologia varia entre tecnologias, este documento define vários termos que podem ser aplicados consistentemente entre os diferentes formatos e mecanismos de segurança. Consequentemente, a terminologia usada aqui pode ser diferente de outras especificações e é definida para que o leitor possa mapear os termos para seu vocabulário preferido.

do Navegador Passivo – um navegador passivo é um navegador HTTP capaz de ter ampla suporte http (por exemplo, HTTP/1.1).

do Solicitante Ativo – um solicitante ativo é um aplicativo (possivelmente um navegador da Web) capaz de emitir mensagens de serviços Web, como as descritas em WS-Security e WS-Trust.

de Perfil – um perfil é um documento que descreve como esse modelo é aplicado a uma classe específica de solicitante (por exemplo, passivo ou ativo).

de Declaração – uma declaração é uma declaração feita por uma entidade (por exemplo, nome, identidade, chave, grupo, privilégio, funcionalidade, atributo etc).

token de segurança – um token de segurança representa uma coleção de declarações.

token de segurança assinado – um token de segurança assinado é um token de segurança declarado e assinado criptograficamente por uma autoridade específica (por exemplo, um certificado X.509 ou um tíquete Kerberos)

- prova de posse são dados de autenticação fornecidos com uma mensagem para provar que a mensagem foi enviada e ou criada por uma identidade reivindicada.

token de prova de posse - um token de prova de posse é um token de segurança que contém dados que uma parte de envio pode usar para demonstrar prova de posse. Normalmente, embora não exclusivamente, as informações de prova de posse são criptografadas com uma chave conhecida apenas para o remetente e as partes de destinatário.

Digest – uma de resumo é uma soma de verificação criptográfica de um fluxo de octeto.

Assinatura – uma assinatura é um valor computado com um algoritmo criptográfico e associado a dados de forma que os destinatários pretendidos dos dados possam usar a assinatura para verificar se os dados não foram alterados desde que foram assinados pelo signatário.

do STS (Serviço de Token de Segurança) – um serviço de token de segurança é um serviço Web que emite tokens de segurança (consulte WS-Security e WS-Trust). Ou seja, faz afirmações baseadas em evidências de que confia, para quem confia nela. Para comunicar a confiança, um serviço requer uma prova, como um token de segurança ou um conjunto de tokens de segurança, e emite um token de segurança com sua própria instrução de confiança (observe que, para alguns formatos de token de segurança, isso pode ser apenas uma nova emissão ou co-assinatura). Isso forma a base da intermediação de confiança.

de Serviço de Atributo – um serviço de atributo é um serviço Web que mantém informações (atributos) sobre entidades de segurança dentro de um realm de confiança ou federação. O termo principal, nesse contexto, pode ser aplicado a qualquer entidade do sistema, não apenas a uma pessoa.

de Serviço de Pseudônimo – um de serviço de pseudônimo é um serviço Web que mantém informações de identidade alternativas sobre entidades de segurança dentro de um domínio ou federação de confiança. O termo principal, nesse contexto, pode ser aplicado a qualquer entidade do sistema, não apenas a uma pessoa.

Trust - Trust é a característica de que uma entidade está disposta a contar com uma segunda entidade para executar um conjunto de ações e/ou para fazer um conjunto de declarações sobre um conjunto de assuntos e/ou escopos.

domínio de confiança – um de domínio de confiança é um espaço de segurança administrado no qual a origem e o destino de uma solicitação podem determinar e concordar se determinados conjuntos de credenciais de uma fonte atendem às políticas de segurança relevantes do destino. O destino pode adiar a decisão de confiança para terceiros, incluindo o terceiro confiável no Domínio de Confiança.

do Serviço de Validação – um serviço de validação é um serviço Web que usa os mecanismos de WS-Trust para validar tokens fornecidos e avaliar seu nível de confiança (por exemplo, declarações confiáveis).

Direct Trust - de confiança direta é quando uma terceira parte confiável aceita como true all (ou algum subconjunto) as declarações no token enviado pelo solicitante.

Direct Brokered Trust - Direct Brokered Trust é quando uma parte confia em uma segunda parte que, por sua vez, confia ou atesta, as reivindicações de terceiros.

Indirect Brokered Trust - Indirect Brokered Trust é uma variação da relação de confiança intermediada direta em que o segundo não pode validar imediatamente as declarações de terceiros para o primeiro e negocia com terceiros, ou outras partes, para validar as declarações e avaliar a confiança de terceiros.

autenticação de mensagem - autenticação de mensagem é o processo de verificar se a mensagem recebida é a mesma que a enviada.

Autenticação do Remetente - autenticação do Remetente é uma evidência de autenticação comprobatório possivelmente entre atores/funções do serviço Web indicando o remetente de uma mensagem de serviço Web (e seus dados associados). Observe que é possível que uma mensagem tenha vários remetentes se houver intermediários autenticados. Observe também que ele é dependente do aplicativo (e fora do escopo) sobre como é determinado quem primeiro criou as mensagens como o originador da mensagem pode ser independente ou oculto atrás de um remetente autenticado.

Realm ou domínio – um de realm ou domínio representa uma única unidade de administração ou confiança de segurança.

de Federação – uma de federação é uma coleção de domínios/domínios que estabeleceram a confiança. O nível de confiança pode variar, mas normalmente inclui autenticação e pode incluir autorização.

provedor de identidade - provedor de identidade é uma entidade que atua como um serviço de autenticação de entidade par para usuários finais e serviço de autenticação de origem de dados para provedores de serviço (normalmente é uma extensão de um serviço de token de segurança).

SSO (Logon Único) - de Logon Único é uma otimização da sequência de autenticação para remover a carga de ações repetidas colocadas no usuário final. Para facilitar o SSO, um elemento chamado Provedor de Identidade pode atuar como um proxy em nome de um usuário para fornecer evidências de eventos de autenticação para terceiros solicitando informações sobre o usuário. Esses Provedores de Identidade são de terceiros confiáveis e precisam ser confiáveis tanto pelo usuário (para manter as informações de identidade do usuário, pois a perda dessas informações pode resultar no comprometimento da identidade dos usuários) quanto pelos serviços Web que podem conceder acesso a recursos e informações valiosos com base na integridade das informações de identidade fornecidas pelo IP.

mapeamento de identidade - de mapeamento de identidade é um método de criação de relações entre propriedades de identidade. Alguns Provedores de Identidade podem usar o mapeamento de ID.

de saída – um de saída é o processo pelo qual os tokens de segurança são destruídos para um domínio/domínio ou federação.

Association - Association é o processo pelo qual as entidades de segurança se tornam associadas ou afiliadas a um realm ou federação de confiança.

Contribuintes

Este documento foi criado em conjunto pela IBM e pela Microsoft.

As principais contribuições incluem (em ordem alfabética): Giovanni Della-Libera, Microsoft; Brendan Dixon, Microsoft; Mike Dusche, Microsoft; Don Ferguson, IBM; Praerit Garg, Microsoft; Tim Hahn, IBM; Heather Hinton, IBM; Maryann Hondo, IBM; Chris Kaler, Microsoft; Frank Leymann, IBM; Brad Lovering, Microsoft; Hiroshi Maruyama, IBM; Anthony Nadalin, IBM; Nataraj Nagaratnam, IBM; Venkat Raghavan, IBM; John Shewchuk

Referências

© 2001-2003 International Business Machines Corporation, . Todos os direitos reservados.

Este é um documento preliminar e pode ser alterado substancialmente ao longo do tempo. As informações contidas neste documento representam a exibição atual da International Business Machine e da Microsoft Corporation sobre os problemas discutidos a partir da data da publicação. Como a IBM e a Microsoft devem responder às mudanças nas condições do mercado, ela não deve ser interpretada como um compromisso por parte da IBM e da Microsoft, e a IBM e a Microsoft não podem garantir a precisão de qualquer informação apresentada após a data da publicação.

A apresentação, distribuição ou outra divulgação das informações contidas neste documento não é uma licença, expressa ou implícita, para qualquer propriedade intelectual de propriedade ou controlada pela IBM ou Pela Microsoft e\ou por qualquer outro terceiro.  IBM, Microsoft e\ou qualquer outro terceiro pode ter patentes, pedidos de patentes, marcas comerciais, direitos autorais ou outros direitos de propriedade intelectual que abrangem assunto neste documento.  O fornecimento deste documento não lhe dá nenhuma licença para patentes, marcas comerciais, direitos autorais ou outra propriedade intelectual da IBM ou da Microsoft ou de qualquer outro terceiro. As empresas de exemplo, organizações, produtos, nomes de domínio, endereços de email, logotipos, pessoas, locais e eventos descritos aqui são fictícios.  Nenhuma associação com qualquer empresa real, organização, produto, nome de domínio, endereço de email, logotipo, pessoa, locais ou eventos é pretendida ou deve ser inferida.

Este documento e as informações contidas aqui são fornecidas em uma base "AS IS" e, na extensão máxima permitida pela lei aplicável, a IBM e a Microsoft fornecem o documento COMO ESTÁ E COM TODAS AS FALHAS e, portanto, isentam todas as outras garantias e condições, expressas, implícitas ou estatutárias, incluindo, mas não se limitando a, quaisquer garantias implícitas (se houver), funções ou condições de comercialização, de aptidão para uma finalidade específica, de precisão ou integridade de respostas, de resultados, de esforço de trabalho, de falta de vírus e de falta de negligência, tudo em relação ao documento. ALÉM DISSO, NÃO HÁ GARANTIA OU CONDIÇÃO DE TÍTULO, GOZO SILENCIOSO, POSSE TRANQUILA, CORRESPONDÊNCIA À DESCRIÇÃO OU NON-INFRINGEMENT DE QUAISQUER DIREITOS DE PROPRIEDADE INTELECTUAL EM RELAÇÃO AO DOCUMENTO.

EM NENHUM CASO, A IBM OU A MICROSOFT SERÃO RESPONSABILIZADAS POR QUALQUER OUTRA PARTE PELO CUSTO DA COMPRA DE BENS OU SERVIÇOS SUBSTITUTOS, LUCROS PERDIDOS, PERDA DE USO, PERDA DE DADOS OU QUAISQUER DANOS INCIDENTAIS, CONSEQUENCIAIS, DIRETOS, INDIRETOS OU ESPECIAIS, SEJA SOB CONTRATO, TORT, GARANTIA OU DE OUTRA FORMA, DECORRENTES DE QUALQUER SAÍDA DESTE OU DE QUALQUER OUTRO CONTRATO RELACIONADO A ESTE DOCUMENTO, SE ESSA PARTE TINHA OU NÃO AVISO PRÉVIO SOBRE A POSSIBILIDADE DE TAIS DANOS.