Conforme citado nos capítulos anteriores, a gestão eficiente de identidades é um importante instrumento para minimizar as vulnerabilidades de segurança em sistemas provedores de serviços, principalmente os serviços disponibilizados via web. O modelo atual de gestão de identidades utilizado nos provedores de serviços da RedeCIM é o tradicional, o que resulta em um processo trabalhoso e mais oneroso de manutenção das informações dos usuários. Estas informações estão distribuídas em
vários cadastros isolados, o que exige que os usuários memorizem e façam uso de diversas senhas. Outra dificuldade está no processo de controle das permissões de acesso dos usuários. Devido a grande rotatividade de servidores públicos existe uma grande demanda para ativar e desativar usuários dos serviços e por muitas vezes um servidor exonerado continua com acesso a serviços do município.
Diante deste cenário, este trabalho visa contribuir com a gestão de identidades dos sistemas da RedeCIM a partir do desenvolvimento de um sistema de gerenciamento gestão de identidades que utiliza o modelo centralizado na organização. O modelo centralizado foi escolhido devido à forma de atuação da FECAM, que necessita manter o controle central das identidades digitais ligadas à instituição e do processo de autenticação. Como a instituição provê aplicações de governo eletrônico, visando prover a interoperabilidade com outros sistemas, adotou-se como infraestrutura de autenticação o padrão SAML 2.0, já que este padrão, possibilita a troca de informações de autenticação e autorização entre domínios, conforme recomendado pela arquitetura e-PING. Outra vantagem com o uso do SAML é a possibilidade de implementar no futuro o modelo de gerenciamento de identidades federado, construindo um círculo de confiança com outros provedores de identidade relacionados as instituições municipalistas, ou até mesmo instituições públicas da esfera estadual e federal.
Conforme ilustrado na Figura 16, o sistema de gerenciamento de identidades interage com três atores que representam usuários dos perfis administrador do IdP, administrador da instituição e do colaborador (servidor público municipal ou colaborador das instituições municipalistas). O grande número de colaboradores que possuem acesso a mais de um provedor de serviços indica que o sistema deve possibilitar a autenticação Single Sing-On (SSO), desta forma um usuário já autenticado no IdP não necessitará nova autenticação para acessar recursos de outros SPs que integram o círculo de confiança.
A Figura 16 ilustra uma visão geral de funcionamento do sistema de gerenciamento de identidades. Os passos estão descritos a seguir.
Figura 16: Visão geral do sistema de gestão de identidade
A configuração da relação de confiança entre o Provedor de Identidade (IdP) e dos Provedores de Serviços (SP) é realizada num processo de troca de informações separado do fluxo principal do sistema desenvolvido. Segue os passos desta configuração:
A) O administrador do SP, ator que não se relaciona diretamente com o sistema, repassa as informações necessárias do SP para que o IdP reconheça e confie no SP;
B) O Administrador do IdP registra as informações do SP no provedor IdP, visando aceitar seus pedidos de autenticação;
D) O Administrador do SP configura o serviço para troca de informações com o IdP.
O passo (E) é referente à indicação do ator Administrador da Instituição. Este processo é o encaminhamento de um formulário assinado pelo representante legal da instituição (prefeito, presidente de câmara de vereadores ou diretor executivo) indicando quem será o Administrador da Instituição. O formulário deve conter as informações cadastrais do Administrador da Instituição para registro no sistema.
A seguir, tem-se a descrição do fluxo de mensagens entre os atores e o sistema de gerenciamento de identidades proposto:
1. O Administrador do IdP cadastra o Administrador da Instituição no provedor de identidade - IdP;
2. O provedor de identidade encaminha para o e-mail do administrador da instituição cadastrado as credenciais de autenticação, que precisarão ser modificadas no primeiro acesso;
3. O Administrador da Instituição cadastra usuários do perfil colaborador, que são os servidores das instituições que utilizarão os serviços do provedor;
4. O IdP encaminha para o e-mail do colaborador cadastrado as credenciais de autenticação, que precisarão ser modificados no primeiro acesso;
5. Após estar cadastrado, o colaborador direciona seu navegador para a página do serviço (SP) desejado;
6. O SP redireciona o navegador para o IdP, para que este colaborador se autentique; 7. O IdP envia ao navegador do usuário colaborador a página de autenticação;
8. O colaborador fornece seu identificador e sua credencial e o navegador os envia ao IdP; 9. O IdP gera uma asserção SAML com os atributos do usuário autenticado e o envia ao
SP; e
Outras interações dos atores com o provedor de identidades são detalhadas na Seção 4.3. Para concepção de um sistema de gerenciamento de identidades, algumas especificações técnicas precisam ser definidas e adotadas por todas as entidades participantes e usuárias do sistema, entre estas destacam-se os atributos dos usuários e os metadados do sistema.
O IdP disponibiliza os atributos no formato urn:oid: conforme o SAML 2.0, apresentado na Tabela 4.
Tabela 4: Tabela da descrição de atributos do IdP.
Atributo Descrição Fonte
Cn Nome do usuário inetOrgPerson14
Sn Sobrenome do usuário inetOrgPerson
Mail Endereço de e-mail do usuário inetOrgPerson
Uid Identificador único do usuário dentro da federação. Formato: Número do CPF
inetOrgPerson
o Nome do órgão (instituição) do usuário inetOrgPerson
Os metadados que foram definidos para troca de informações entre os membros do círculo de confiança do IdP estão no formato SAML 2.0 Metadata15, padrão estabelecido pela OASIS e também recomendado pela arquitetura e-PING.
Os documentos de metadados fornecidos pelo provedor de identidades (IdP) inclui um elemento <md:IDPSSODescriptor>, que contem informações dos elementos:
<md:KeyDescriptor>: adequado para utilização de criptografia XML, este elemento é utilizado quando um provedor de serviço renuncia o uso de TLS/SSL; e
<md:SingleSingOnService>: responsável pela autenticação SSO;
14 Disponível em: http://tools.ietf.org/html/rfc2798 15
Os metadados devem incluir um ou mais <md:NameIDFormat>, elementos que indicam os formatos de valores são suportados no <saml2:NameID> (elemento identificador do usuário).
Os documentos de metadados fornecidos por um provedor de serviços (SP) inclui um elemento <md:SPSSODescriptor>, que contem informações dos elementos:
<md:KeyDescriptor>: adequado para utilização de criptografia XML, este elemento é utilizado quando o provedor de serviço não utiliza TLS/SSL; e
<md:AssertionConsumerService>: elemento que possibilita o provedor de serviços receber asserções do provedor de identidade;
Os metadados incluem também um ou mais <md:NameIDFormat> elementos que indicam os formatos de valores suportados no <saml2:NameID> (elemento identificador do usuário) e um ou mais <md:AttributeConsumingService> elementos que descrevem o serviço(s) oferecido e as suas necessidades de atributos. Os metadados fornecidos pelo fornecedor de serviços deve conter um nome descritivo do serviço que o provedor de serviços representa. O nome deve ser colocado na <md:ServiceName> e no <md:AttributeConsumingService> recipiente. Além disto, os provedores de serviço devem utilizar o TLS/SSL para afirmação de terminais de serviço do consumidor, caso contrário seus metadados deve incluir um <md:KeyDescriptor> adequado para a criptografia XML.