O princ´ıpio b´asico de seguranc¸a em um sistema computacional consiste em garantir os recursos somente aos sujeitos autorizados pela pol´ıtica de seguranc¸a do sistema. Nos mode- los de autorizac¸˜ao discricion´arios, o sistema de controle de acesso a um recurso, ao receber uma requisic¸˜ao de acesso, verifica quem est´a requisitando, qual o recurso que est´a sendo requisitado e, atrav´es de uma consulta a uma matriz de acesso, verifica quais os direitos que este requerente possui sobre o recurso. Segundo Blaze et al. [1999], apesar de tal tipo de soluc¸˜ao ser amplamente adotada, esta n˜ao ´e a ideal para os sistemas atuais, devido a grande dinˆamica destes ambientes.
Como visto na sec¸˜ao 2.3.1, organizac¸˜oes est˜ao se agrupando com o intuito de prover facilidades para seus clientes. Provedores de servic¸os compartilham informac¸˜oes sobre seus clientes, o que permite aos clientes usufruir, por exemplo, do uso de uma ´unica autenticac¸˜ao para acessar qualquer servic¸o que fac¸a parte do grupo de organizac¸˜oes. Outro ponto positivo ´e que os clientes n˜ao necessitam mais fornecer sempre as mesmas informac¸˜oes quando forem acessar algum servic¸o. Em tais ambientes a autorizac¸˜ao n˜ao pode se restringir simplesmente aos identificadores de usu´arios, diante da impossibilidade de um servic¸o conhecer todos os usu´arios existentes nos demais provedores de servic¸o. Assim, neste tipo de ambiente o ideal seria expressar a autorizac¸˜ao confrontando requisitos e condic¸˜oes com as propriedades dos usu´arios.
A federac¸˜ao de identidades tem como ponto fundamental as relac¸˜oes de confianc¸a entre provedores de servic¸os e clientes, e entre os pr´oprios provedores de servic¸o. O fornecimento de informac¸˜oes pessoais de um cliente a um provedor de servic¸o s´o ocorre depois do cliente ter certeza que suas informac¸˜oes ser˜ao manipuladas de maneira correta. Por outro lado, o provedor de servic¸o s´o ir´a conceder ao cliente o acesso ao recurso, se o mesmo confiar nas informac¸˜oes fornecidas pelo cliente. O mesmo ocorre nas relac¸˜oes de confianc¸a entre provedores de servic¸o. Tais relac¸˜oes permitem, por exemplo, que um usu´ario autenticado em um determinado provedor possa usufruir dos recursos providos por outro provedor, pois ambos possuem um acordo indicando o compartilhamento de recursos para os usu´arios de ambos provedores.
O termo confianc¸a pode assumir diversos sentidos em uma aplicac¸˜ao distribu´ıda. Em seguranc¸a o mais usual ´e como garantir que as informac¸˜oes foram enviadas por uma origem confi´avel. No caso, a preocupac¸˜ao geralmente restringe-se a garantir as propriedades de autenticidade e integridade das mensagens. Para tratar tal problema diversos modelos foram
propostos, como por exemplo, o X.509 [Housley et al., 2002], PGP [Zimmerman, 1994] e o SPKI/SDSI [Ellison et al., 1999; Rivest e Lampson, 1996].
O modelo X.509 est´a fundamentado sobre a confianc¸a nas chaves privadas das Au- toridades Certificadoras (ACs). A proposta inicial do X.509 apresentava uma topologia hier´arquica, onde os n´os inferiores da hierarquia confiam nos n´os superiores. Por´em, na vers˜ao 3 do X.509 [Housley et al., 2002] foram introduzidas algumas flexibilidades, como a criac¸˜ao de pontes entre as ACs (certificac¸˜ao cruzada), o que permite ainda a criac¸˜ao de teias de confianc¸a, que apesar de n˜ao ser amplamente adotado, consegue transpor a estrutura hier´arquica inicial. O PGP e o SPKI/SDSI s˜ao exemplos de modelos de confianc¸a baseados nas teias de confianc¸a. N˜ao existe uma hierarquia, cada n´o da rede indica em que deseja con- fiar. Trata-se de um modelo igualit´ario e independente de qualquer estrutura centralizadora.
Em uma aplicac¸˜ao distribu´ıda a confianc¸a n˜ao se restringe simplesmente em garantir as propriedades de autenticidade e integridade. As informac¸˜oes trocadas entre clientes e provedores de servic¸os possuem um certo valor e a manipulac¸˜ao indevida das mesmas pode acarretar em preju´ızos para ambos os lados. Por exemplo, um cliente n˜ao gostaria de fornecer o n´umero do cart˜ao de cr´edito para qualquer provedor de servic¸o. A confianc¸a entre clientes e provedores de servic¸o ´e algo que pode estar fundamentada, por exemplo, sobre uma base de reputac¸˜oes, a qual poderia indicar que um determinado provedor de servic¸os sempre honrou suas negociac¸˜oes.
As relac¸˜oes de confianc¸a podem ser unidirecionais. Por exemplo, no caso do modelo X.509, os usu´arios confiam nas chaves das Autoridades Certificadoras (AC) mas o inverso geralmente n˜ao ´e verdade. Ou ainda, as relac¸˜oes de confianc¸a podem ser bilaterais, exigindo assim que clientes e provedores de servic¸o fornec¸am algum tipo de informac¸˜ao para o estabe- lecimento da relac¸˜ao. Como estabelecer e gerenciar tais relac¸˜oes de confianc¸a ´e um problema que tem sido destacado em diversos trabalhos na literatura [WS-Trust, 2005; WS-Federation, 2003; Jøsang et al., 2005b; Spantzel et al., 2005; Liberty, 2003; Shibboleth, 2005; Winslett et al., 2002; Skogsrud et al., 2003].
Em alguns trabalhos assume-se que o estabelecimento de confianc¸a ´e um processo ma- nual e exigem que diversos requisitos burocr´aticos sejam cumpridos antes de criar a relac¸˜ao de confianc¸a, por exemplo, para entrar na hierarquia das ACs do X.509 ´e necess´ario cum- prir um conjunto de requisitos, sendo alguns deles relacionados `a seguranc¸a f´ısica do local onde estar´a armazenada a chave privada da AC. Outros trabalhos tratam a confianc¸a de uma maneira mais dinˆamica e vol´atil. Por exemplo, para uma determinado fluxo de neg´ocios ´e necess´ario que diversos provedores de servic¸o se agrupem e, uma vez que o fluxo tenha sido cumprido, tal relac¸˜ao ´e desfeita.