Projeto Shibboleth

Como parte do projeto do grupo de Internet2, o Shibboleth (Shibboleth, 2005) fornece um sistema de autenticac¸˜ao e autorizac¸˜ao baseado na Internet atrav´es do navegador Web do usu´ario. Em relac¸˜ao a interac¸˜oes entre clientes e provedores de servic¸o, o Shibboleth permite apenas que esta seja via navegador do usu´ario. Um dos seus principais requisitos ´e permitir interac¸˜oes seguras e interoperac¸˜ao entre s´ıtios Web educacionais, apesar de ser ´util para qualquer ambiente que queira trabalhar com dom´ınios de confianc¸a. Desta forma, o sistema permite que quaisquer organizac¸˜oes criem federac¸˜oes e usufruam do gerenciamento de identidades federadas.

O projeto Shibboleth faz grande uso das especificac¸˜oes XACML e SAML (ver Sec¸˜ao 3.4.1). O primeiro ´e respons´avel pelo controle de acesso atrav´es das entidades PEP Policy Enforcement Point) e PDP (Policy Decision Point). J´a o segundo, ´e utilizado para conduzir os atributos dos usu´arios entre os dom´ınios de confianc¸a.

O modelo conceitual do projeto Shibboleth ´e composto por usu´arios, s´ıtio origem e s´ıtio destino. Cada s´ıtio que deseja fazer parte da federac¸˜ao Shibboleth deve decidir se sua atuac¸˜ao ser´a como origem, destino ou ambos. O s´ıtio origem ´e respons´avel tanto por autenticar o usu´ario, quanto por fornecer atributos sobre o usu´ario para o s´ıtio destino. Os atributos fornecidos pela origem s˜ao assinados por esta, com o intuito de garantir a autenticidade dos mesmos.

A arquitetura do Shibboleth compreende um provedor de identidade (Identity Provider - IdP) e um provedor de servic¸o (Service Provider - SP) (Figura 4.4). Ambos s˜ao desen- volvidos separadamente, mas trabalham juntos para fornecer acesso seguro aos recursos. O

4. Gerenciamento de Identidades Federadas e as Relac¸ ˜oes de Confianc¸a em Servic¸os Web 73 primeiro possui as informac¸˜oes sobre o usu´ario, ´e o dom´ınio que o hospeda, respons´avel pela sua autenticac¸˜ao e o fornecimento de seus atributos. O provedor de servic¸os ´e quem hospeda o recurso a ser acessado. Para tanto, possui uma pol´ıtica relacionada ao recurso e que, se necess´ario, solicita informac¸˜oes extras sobre quem est´a requerendo acesso ao recurso. Al- guns requisitos e definic¸˜oes sobre a arquitetura do Shibboleth s˜ao apresentados em (Morgan et al., 2004):

• criac¸˜ao e gerenciamento da confianc¸a entre s´ıtios;

• gerenciamento sobre qual informac¸˜ao a origem ir´a transferir para cada s´ıtio destino; • definic¸˜ao de um esquema padr˜ao para a comunicac¸˜ao entre dom´ınios;

• prover meios para a transferˆencia segura de atributos;

• definir requisitos que os s´ıtios devem conhecer para participar do projeto Shibboleth; • garantir a privacidade dos usu´arios, permitindo o acesso de usu´arios anˆonimos, por´em

autorizados, aos recursos.

Figura 4.4: Arquitetura do Shibboleth

A Figura 4.4 exibe a arquitetura do Shibboleth e um poss´ıvel cen´ario envolvendo intera- c¸˜oes entre os m´odulos da arquitetura. O provedor de identidade possui os m´odulos Tratador do Servic¸o (Handle Service - HS) e Autoridade de Atributos (Atrribute Authority - AA). O Tratador de Servic¸o ´e respons´avel por verificar se o usu´ario est´a autenticado localmente e por criar um tratador (handler) para determinar a Autoridade de Atributos que possui as informac¸˜oes sobre o usu´ario, uma vez que ´e poss´ıvel a presenc¸a de v´arias AAs em um mesmo dom´ınio. O Shibboleth n˜ao determina como isso ´e feito, apenas diz que faz parte da implementac¸˜ao do sistema. A func¸˜ao da Autoridade de Atributos ´e fornecer atributos sobre

um usu´ario, mas esta tamb´em pode especificar um meio do usu´ario determinar quais atribu- tos este deseja dispor quando visita um s´ıtio estrangeiro. J´a o Provedor de Servic¸os possui os m´odulos SHIRE (Shibboleth Indexical Reference Establisher), WAYF (Where are you from) e SHAR (Shibboleth Attribute Requester). O SHIRE ´e o m´odulo respons´avel por descobrir qual o dom´ınio de origem do usu´ario que est´a solicitando acesso ao recurso e criar um ma- nipulador para este usu´ario. Para auxiliar o SHIRE, o WAYF questiona o usu´ario sobre o seu dom´ınio de origem. O WAYF conhece o enderec¸o dos Tratadores de Servic¸os pertencentes a federac¸˜ao e, ap´os o usu´ario apontar de qual dom´ınio pertence, entra em contato com o Trata- dor de Servic¸o do usu´ario. O SHAR tem por func¸˜ao interagir com a Autoridade de Atributos do usu´ario para obter os seus atributos.

As interac¸˜oes do cen´ario da Figura 4.4 iniciam quando um usu´ario solicita, atrav´es de seu navegador Web, acesso a um determinado recurso (passo 1). Por exemplo, um artigo hospedado em determinada universidade. Ao verificar o pedido de acesso, o SHIRE aciona o WAYF (passo 2) que questiona o usu´ario sobre o seu dom´ınio de origem, por exemplo, a universidade `a qual este pertence. O WAYF apresenta uma lista de universidades ou organizac¸˜oes ao usu´ario, que ent˜ao informa a sua origem. Ap´os isso, o WAYF entra em contato com o Tratador de Servic¸o do usu´ario (passo 3), que verifica se o usu´ario j´a est´a autenticado, caso contr´ario, realiza a autenticac¸˜ao do mesmo. A autenticac¸˜ao obedece a infra-estrutura subjacente do dom´ınio, podendo ser baseada em senha ou via uso de uma ICP. Como parte da resposta ao SHIRE, o Tratador de Servic¸o retorna o enderec¸o da Autori- dade de Atributos do usu´ario (passo 4). O SHIRE ent˜ao repassa o enderec¸o ao SHAR (passo 5) que ´e o respons´avel por obter os atributos do usu´ario necess´arios para o acesso ao recurso (passo 6). A Autoridade de Atributos, ao receber o pedido por atributos, verifica a pol´ıtica de privacidade do usu´ario e ent˜ao, conforme a pol´ıtica, retorna os atributos solicitados (passo 7). O SHAR verifica se o pedido por atributos foi atendido e ent˜ao fornece ao usu´ario acesso ao recurso (passo 8). Lembrando que tanto a solicitac¸˜ao por atributos quanto a resposta com os atributos solicitados s˜ao realizadas via asserc¸˜oes e protocolos SAML.

O Shibboleth define uma forma padronizada para a troca de atributos, atrav´es do SAML, por´em n˜ao especifica os atributos em si, deixando tal func¸˜ao livre para os desenvolvedores. Em um ambiente federado, a padronizac¸˜ao destes atributos ´e tida como crucial (Morgan et al., 2004). Para que a federac¸˜ao relacionada a servic¸os educacionais tenha uma forma

padronizada o projeto Internet2 estabelece a InCommon Federation1, (InCommon, 2006)

que ´e respons´avel pela definic¸˜ao da gram´atica que rege a troca de atributos no Shibboleth.