Embed Size (px)
Citation preview
UNIVERSIDADE DO VALE DO ITAJAÍ
CENTRO DE CIÊNCIAS TECNOLÓGICAS DA TERRA E DO MAR
CURSO DE CIÊNCIA DA COMPUTAÇÃO
SISTEMA DE GERENCIAMENTO DE IDENTIDADES PARA A
REDE CATARINENSE DE INFORMAÇÕES MUNICIPAIS
Emerson Souto
Michelle S. Wangham, Dra.
São José, Novembro / 2013.
UNIVERSIDADE DO VALE DO ITAJAÍ
CENTRO DE CIÊNCIAS TECNOLÓGICAS DA TERRA E DO MAR
CURSO DE CIÊNCIA DA COMPUTAÇÃO
SISTEMA DE GERENCIAMENTO DE IDENTIDADES PARA A
REDE CATARINENSE DE INFORMAÇÕES MUNICIPAIS
Emerson Souto
São José, Novembro / 2013
Orientadora: Michelle S. Wangham, Dra.
Área de Concentração: Computação Aplicada
Linha de Pesquisa: Sistemas Distribuídos
Palavras-chave: Segurança da Informação, Gestão de Identidades, Governo Eletrônico.
Número de páginas: 156
DEDICATÓRIA
Este trabalho é dedicado aos meus pais,
Osvaldo e Carmem.
A minha querida esposa e minha filha,
Vânia e Vitória.
AGRADECIMENTOS
Aos meus pais, Osvaldo de Souza Souto e Carmem Mary de Souza Souto, meus irmãos e toda a minha
família pela educação e valores que me ensinaram, e todo o apoio que viabilizou alcançar meus
objetivos.
A minha esposa e amiga Vânia, pelo apoio, ajuda, dedicação, compreensão e carinho no decorrer desta
jornada.
E a todos amigos e colegas que de forma direta ou indireta contribuíram para que este sonho se
realizasse.
Gostaria de agradecer a Federação Catarinense de Municípios e todo seu corpo técnico pelo apoio no
desenvolvimento deste trabalho e especialmente ao colega Luiz Paulo Schlischting pela ajuda nas
dificuldades de instalação do ambiente e na programação.
Um agradecimento especial a minha orientadora Michelle Wangham e a todos os professores que
participaram da minha formação acadêmica.
RESUMO
As aplicações de Governo Eletrônico já são uma realidade nos municípios de Santa Catarina.
Os agentes públicos municipais entendem que os serviços prestados via Internet podem trazer
inúmeras vantagens, tanto para os cidadãos quanto para a própria administração pública. Para apoiar os
municípios diante desta crescente demanda por soluções web, a Federação Catarinense de Municípios
(FECAM) disponibiliza por meio da Rede Catarinense de Informações Municipais (RedeCIM) uma
gama de sistemas, provendo serviços a um expressivo número de usuários das mais diversas áreas da
administração pública municipal. Atualmente, a gestão destes usuários é realizada de forma isolada, ou
seja, cada serviço possui um provedor de identidades e um processo diferente, o que dificulta e onera a
instituição na manutenção das diversas bases de usuários. Por outro lado, estão os próprios usuários,
que precisam guardar com segurança um número excessivo de senhas, pois cada sistema utiliza um
mecanismo diferente de autenticação e autorização. Existem diversas soluções de gerenciamento de
identidades que possibilitam prover a autenticação única (Single Sing-On - SSO) e que possuem
implementações de código aberto que podem tornar a gestão de identidades da RedeCIM mais simples
e segura. O objetivo deste trabalho é aprimorar o processo de gestão de identidades da Rede
Catarinense de Informações Municipais, por meio do desenvolvimento de um sistema de
gerenciamento de identidades. O sistema proposto segue o modelo centralizado de gestão de
identidades, a autenticação única (SSO) e está alinhado as recomendações da arquitetura E-PING,
Padrões de Interoperabilidade de Governo Eletrônico, do Brasil. O trabalho realizado envolveu (1)
uma pesquisa bibliográfica sobre os modelos de gerenciamento de identidades e tecnologias existentes,
(2) a definição de um provedor de identidades centralizado (IdP) baseado no padrão SAML, (3) o
desenvolvimento de um protótipo de sistema de gerenciamento de identidades que faz uso do IdP
proposto, e (4) avaliação do sistema de gerencimento de identidades por meio da aplicação de casos de
testes para avaliar as funcionalidades do sistema e de uma pesquisa de satisfação aplicada em todos os
perfis de usuários. Os resultados obtidos comprovam que é viável o desenvolvimento e a utilização de
um sistema de gerenciamento de identidades centralizado que atenda as necessidades da RedeCIM.
Comprovou-se também que a utilização da autenticação única (SSO) traz satisfação, tanto para os
usuários dos serviços, quanto para os gestores de identidades das instituições relacionadas.
ABSTRACT
The applications of the Electronic Government are already a reality in the municipalities of Santa
Catarina. The municipal agents understand that the services by Internet can bring a lot of advantages to
both, citizens and public administration. To support the municipalities against the growing demand for
web solutions, the Federação Catarinense de Municípios (FECAM) makes available by Rede
Catarinense de Informações Municipais (RedeCIM) a gamma of systems, providing services to an
expressive number of users from several areas of municipal government. Currently, the management
of this users is taken in isolation, or, each service have an identity provider and a different process,
which make more difficult and burdens the institution on the maintenance of the several users’ bases.
On the other hand, are the own users, who need keep in secure an excessive number of passwords,
because each system uses a different sign-on and authorization mechanism. There are a lot of solutions
of identity management that make possible provide a single sign-on (SSO) and that have open source’s
implementations that can make de Identity management of RedeCIM simpler and safer. The goal of
this work is improve the identity management process of Rede Catarinense de Informações
Municipais, through the development of identity management system. The system proposed follows
the centralized model of identity management, the single sign-on and is aligned to the E-PING
architecture recommendations, Interoperability Standards of the Electronic Government, from Brazil.
This works involved a literature about the identity management models and existing technologies, the
definition of a centralized identity provider (IdP), based on SAML standard, the development of a
prototype of the system for identity management with the test cases to evaluate the functionalities of
the system and a satisfaction survey applied to all users profiles. The results show that is viable the
development and utilization of a centralized system of identity management that answer the necessities
of RedeCIM. It is also demonstrated that the utilization of SSO bring satisfaction to both, users and
managers identities from related institutions.
LISTA DE TABELAS E QUADROS
Tabela 1. Proporção de Usuários na Internet (2005-2011) .................................................................. ...15
Tabela 2. Resumo de comparação das ferramentas estudadas ............................................................. ..58
Tabela 3. Características dos principais sistemas da RedeCIM..............................................................65
Tabela 4. Tabela da descrição de atributos do IdP..................................................................................70
Quadro 1. Caso de uso Gerenciar Serviços expandido...........................................................................75
Quadro 2. Caso de uso Gerenciar Administrador da Instituição expandido.......................................... 76
Quadro 3. Caso de uso Configurar Mecanismo de Autenticação expandido..........................................77
Quadro 4. Caso de uso Gerenciar Colaboradores expandido..................................................................77
Quadro 5. Caso de uso Autenticar Usuários expandido..........................................................................78
Quadro 6. Caso de uso Atualizar Cadastro expandido............................................................................79
Quadro 7. Detalhamentos do caso de teste CT 01...................................................................................87
Quadro 8. Detalhamentos do caso de teste CT 02...................................................................................88
Quadro 9. Detalhamentos do caso de teste CT 03...................................................................................89
Quadro 10. Detalhamentos do caso de teste CT 04.................................................................................89
Quadro 11. Detalhamentos do caso de teste CT 05................................................................................90
Quadro 12. Detalhamentos do caso de teste CT 06...............................................................................91
Quadro 13. Detalhamentos do caso de teste CT 07...............................................................................91
Quadro 14. Detalhamentos do caso de teste CT 08...............................................................................92
Quadro 15. Detalhamentos do caso de teste CT 09...............................................................................93
Quadro 16. Detalhamentos do caso de teste CT 10...............................................................................94
Quadro 17. Detalhamentos do caso de teste CT 11...............................................................................94
Quadro 18. Detalhamentos do caso de teste CT 12...............................................................................95
Quadro 19. Detalhamentos do caso de teste CT 13...............................................................................96
Quadro 20. Detalhamentos do caso de teste CT 14...............................................................................97
LISTA DE ABREVIATURAS E SIGLAS
ACL Access Control List
API Application Programming Interface
AS Authentication Service
CAFe Comunidade Acadêmica Federada
CAS Central Authentication Service
CGI.BR Comitê Gestor da Internet no Brasil
CoT Circles of trust
DIT Directory Information Tree
DNS Domain Name System
e-Gov Governo Eletrônico
e-PING Padrões de Interoperabilidade em Governo Eletrônico
EGEM Escola de Gestão Pública Municipal
FECAM Federação Catarinense de Municípios
FTP File Transfer Protocol
GCIO Government ICT Directions and Priorities
HTTP Hypertext Transfer Protocol
IDEA International Data encryption Algorithm
IdM Identity Management
IdP Identity Provider
IIA Institute of Internal Auditors
ISO International Organization for Standardization
JDBC Java Database Connectivity
KDC Key Distribution Centers
LDAP lightweight Directory Access Protocol
MIT Massachusetts Institute of Technology
OASIS Organization for the Advancement of Structured Information Standards
OSI Open Systems Interconnection
RADIUS Remote Authentication Dial In User Service
RAID Redundant Array of Independendet Disks
RedeCIM Rede Catarinense de Informações Municipais
REST Representational State Transfer
RNP Rede Nacional de Ensino e Pesquisa
SAML Security Assertion Markup Language
SASL Simples Authentication and Security Layer
SLO Single Log-Out
SOAP Simple Object Access Protocol
SP Service Provider
SSL Secure Socket Layer
SSO Single Sign-On
TCP Transmission Control Protocol
TIC Tecnologia da Informação e Comunicação
TGS Ticket-Granting Service
TLS Transport Layer Security
UML Unified Modeling Language
URI Uniform Resource Identifier
URL Uniform Resource Locator
XML eXtensible Markup Language
W3C World Wide Web Consortium
LISTA DE FIGURAS
Figura 1. Exemplo de uma identidade digital.........................................................................................26
Figura 2. Classificação dos modelos de gerenciamento de identidade...................................................27
Figura 3. Exemplo de autenticação única................................................................................................30
Figura 4. Processo de SSO que utiliza abordagem Baseada em Broker.................................................31
Figura 5. Processo de SSO que utiliza abordagem Baseada em Agente.................................................32
Figura 6. Processo de SSO que utiliza abordagem Baseada em Proxy Reverso.....................................33
Figura 7. Processo de SSO que utiliza abordagem Baseada em API......................................................34
Figura 8. Processo de SSO que utiliza abordagem Baseada em Serviços...............................................34
Figura 9. Relação entre os componentes SAML.....................................................................................37
Figura 10. Estrutura de alto nível da asserção SAML.............................................................................38
Figura 11. Protocolo OpenID Authentication 2.0……………..……………......…………….……......43
Figura 12. Visão simplificada do protocolo OAuth................................................................................46
Figura 13. Troca de mensagens no Kerberos..........................................................................................49
Figura 14. Fluxo do protocolo CAS........................................................................................................52
Figura 15. Estrutura no estilo DNS.........................................................................................................55
Figura 16. Visão geral do sistema de gestão de identidade.....................................................................68
Figura 17. Casos de Uso do Administrador, Administrador de Instituição e Colaborador.....................74
Figura 18. Estrutura de diretório LDAP do sistema................................................................................80
Figura 19. Tela de autenticação do IdP...................................................................................................82
Figura 20: Configuração da fonte de autenticação..................................................................................83
Figura 21: Metadado do IdP salm20-idp-hosted.php..............................................................................83
Figura 22: Metadados fornecidos pelo IdP.............................................................................................84
Figura 23: Log de requisições na porta 443 (ssl)..................................................................................97
Figura 24: Número de avaliadores conforme perfil do usuário no IdP.................................................99
Figura 25: Número de avaliadores conforme a instituição pertencente................................................99
Figura 26: Distribuição dos avaliadores por área técnica.....................................................................100
Figura 27: Número de sistemas que o avaliador é usuário....................................................................100
Figura 28: Tempo de atuação do avaliador no papel de usuário...........................................................100
Figura 29: Percentual de conhecimento sobre provedor de identidades...............................................100
Figura 30: Percentual de conhecimento sobre autenticação SSO.........................................................102
Figura 31: Percentual de conhecimento sobre autenticação centralizada.............................................102
Figura 32: Percentual de conhecimento sobre autenticação Federada..................................................103
Figura 33: Sistemas operacionais utilizados pelos avaliadores.............................................................104
Figura 34: Navegadores web utilizados pelos avaliadores....................................................................104
Figura 35: Execução do experimento....................................................................................................105
Figura 36: Necessidade de reinicio do experimento.............................................................................105
Figura 37: Suficiência das mensagens de erro......................................................................................106
Figura 38: Apresentação legível das informações.................................................................................106
Figura 39: Rapidez dos serviços do IdP ............................................................................................107
Figura 40: Não saber executar o experimento.......................................................................................107
Figura 41: Compreensão da funções do IdP .......................................................................................108
Figura 42: Rapidez na gestão de usuários............................................................................................108
Figura 43: Opinião sobre a flexibilidade no acesso aos serviços com a autenticação SSO..................109
Figura 44: Opinião sobre a segurança do IdP.......................................................................................110
Figura 45: Opinião sobre a utilização do IdP nas instituições..............................................................111
Figura 46: Opinião sobre a utilização do IdP pelos colaboradores.......................................................111
Figura 47: Opinião sobre a facilidade na gestão e na satisfação dos usuários......................................112
SUMÁRIO
INTRODUÇÃO ........................................................................................ 14
1.1 PROBLEMA DE PESQUISA........................................................................... 16
1.1.1 Solução Proposta ............................................................................................. 17
1.1.2 Delimitação de Escopo .................................................................................... 18
1.1.3 Justificativa ...................................................................................................... 18
1.2 OBJETIVOS ...................................................................................................... 19
1.2.1 Objetivo Geral ................................................................................................. 19
1.2.2 Objetivos Específicos ...................................................................................... 19
1.3 METODOLOGIA .............................................................................................. 20
1.3.1 Metodologia da Pesquisa ................................................................................ 20
1.3.2 Procedimentos Metodológicos ........................................................................ 20
1.4 ESTRUTURA DO TRABALHO ...................................................................... 21
2 FUNDAMENTAÇÃO TEÓRICA ...................................................... 22
2.1 SEGURANÇA DA INFORMAÇÃO ................................................................ 22
2.2 GESTÃO DE IDENTIDADES ......................................................................... 24
2.2.1 Modelos de Gerenciamento de Identidades .................................................. 26
2.2.2 Opções para Implantação da autenticação Single Sing-On (SSO) ............. 29
2.3 SOLUÇÕES PARA IMPLANTAÇÃO DE AUTENTICAÇÃO SSO .......... 35
2.3.1 SAML ............................................................................................................... 35
2.3.2 OpenID ............................................................................................................. 41
2.3.3 OAuth ............................................................................................................... 44
2.3.4 Protocolo de Autenticação Kerberos ............................................................. 47
2.3.5 CAS ................................................................................................................... 51
2.3.6 OpenLDAP ....................................................................................................... 53
2.3.7 Outras Soluções ............................................................................................... 56
2.4 COMPARAÇÃO DAS SOLUÇÕES ................................................................ 58
2.5 E-PING ............................................................................................................... 59
2.6 CONSIDERAÇÕES .......................................................................................... 61
3 TRABALHOS RELACIONADOS .................................................... 62
3.1 COMUNIDADE ACADÊMICA FEDERADA (CAFE) ................................ 62
4 DESENVOLVIMENTO ...................................................................... 64
4.1 ANÁLISE DOS PRINCIPAIS SISTEMAS DA REDECIM ......................... 64
4.2 VISÃO GERAL E ESPECIFICAÇÕES TÉCNICAS .................................... 66
4.3 ANÁLISE DE REQUISITOS ........................................................................... 71
4.3.1 Requisitos Funcionais ..................................................................................... 71
4.3.2 Requisitos Não Funcionais ............................................................................. 72
4.3.3 Regras do Negócio ........................................................................................... 73
4.4 MODELAGEM DO SISTEMA ........................................................................ 74
4.4.1 Casos de Uso .................................................................................................... 74
4.4.2 Estrutura de Diretório LDAP ........................................................................ 80
4.5 DETALHAMENTO DO DESENVOLVIMENTO......................................... 81
4.6 DESCRIÇÃO DO PROJETO DE EXPERIMENTOS .................................. 85
5 RESULTADOS E ANÁLISES ........................................................... 87
5.1 RESULTADOS OBTIDOS ............................................................................... 87
5.1.1 Resultados do Primeiro Experimento: Casos de Teste ............................... 87
5.1.2 Resultados e Análise do Segundo Experimento: Pesquisa de Satisfação .. 98
6 CONCLUSÕES .................................................................................. 115
6.1 TRABALHOS FUTUROS .............................................................................. 116
REFERÊNCIA BIBLIOGRÁFICA ..................................................... 117
APÊNDICE 1 - METADADOS PROVEDOR DE SERVIÇOS ........ 122
APÊNDICE 2 - TELAS DA APLICAÇÃO DOS TESTES ................ 123
APÊNDICE 3 - ROTEIROS DA PESQUISA DE SATISFAÇÃO .... 143
APÊNDICE 4 - CORPO DO E-MAIL DA PESQUISA ..................... 149
APÊNDICE 5 - COMPILAÇÃO DAS RESPOSTAS......................... 150
14
INTRODUÇÃO
A Internet se torna cada vez mais indispensável para o acesso a informações e serviços
públicos. A sociedade a cada dia exige um governo mais transparente e eficiente na prestação de
serviços. Constata-se que a utilização da Internet e de web sites governamentais para a prestação de
serviços on-line e para a disponibilização de informações acerca das atividades públicas representa um
caminho para melhorar a eficácia e a qualidade dos serviços prestados ao cidadão (FERREIRA &
ARAUJO, 2000).
Segundo Barbosa (2008), as relações entre governos e cidadão têm sido impactadas pelo uso
cada vez maior das TICs (Tecnologias da Informação e Comunicação) pelos cidadãos e empresas,
sobre tudo pela preferência por serviços transacionais online em ambientes virtuais, associadas à
conveniência desses ambientes, e pela universalização da Internet.
A pesquisa coordenada pelo Comitê Gestor da Internet no Brasil (CGI.br) sobre o uso das
tecnologias de informação e comunicação no Brasil - TIC Domicílios e Empresas, aponta o aumento
expressivo do número de brasileiros que usam a Internet. O crescimento dos acessos nos domicílios e
nas empresas contribui para evidenciar que as informações e a prestação de serviços por meio
eletrônico estão mudando o cenário econômico e social no Brasil (CGI.BR, 2012). Cada vez mais, os
governos, empresas e cidadãos interagem por meio da Internet. A Tabela 1 revela o crescimento de
usuários da Internet nas diversas regiões do Brasil entre os anos de 2005 e 2011. Na Região Sul, por
exemplo, observou-se uma taxa de crescimento de 19% no número de usuários em 2011, em relação ao
número de usuários de 2010. Este aumento foi superior ao número total de usuários do Brasil, que
cresceu 9,75% (CGI.BR, 2012).
Outro dado relevante na pesquisa TIC Domicílios e Empresas é que quase um terço dos
brasileiros (31%), população acima de 16 anos, utilizou serviços de governo eletrônico (e-Gov) nos 12
meses anteriores a pesquisa. Enquanto 92% das empresas utilizaram a Internet para fazer consultas ou
transações com instituições governamentais no mesmo período (CGI.BR, 2012).
15
Tabela 1: Proporção de Usuários na Internet (2005-2011) - Percentual sobre o total da população
Região
Área urbana Total Brasil (urbano + rural)
2005 2006 2007 2008 2009 2010 2011 2008 2009 2010 2011
Brasil 24 28 34 38 43 45 50 34 39 41 45
Norte 19 22 28 30 36 41 42 25 30 34 36
Nordeste 17 18 28 30 36 37 40 25 30 28 32
Sudeste 27 31 37 41 47 49 55 40 45 47 53
Sul 26 29 37 37 46 44 54 34 43 42 50
Centro-Oeste 28 34 38 44 48 53 53 41 45 50 51
Fonte: CGI.BR (2012).
Atualmente, o município é a esfera de governo com o relacionamento mais estreito com o
cidadão, sendo que uma multiplicidade de serviços pode ser oferecida, ainda que em muitos casos em
cooperação com os governos federal e estadual.
“(...) os municípios após as mudanças na estrutura governamental do Brasil com a Constituição
Federal de 1988, não conquistaram apenas autonomia, mas também herdaram diversas
atribuições e competências na execução das políticas públicas nas áreas de educação, saúde,
agricultura, assistência social, segurança de trânsito, entre outras competências administrativas
e tributárias.” (VEDANA, 2002).
Segundo Vedana (2002), os municípios herdaram diversas atribuições e responsabilidades, mas
os recursos financeiros continuaram centralizados na União e nos Estados. Esta afirmação revela a
dificuldade que os municípios, principalmente os de pequeno porte, possuem para implantar um
governo eletrônico eficiente e adequado à demanda crescente da sociedade.
Neste cenário, a Federação Catarinense de Municípios (FECAM), a partir de 2005, criou a
Rede Catarinense de Informações Municipais (RedeCIM), que integra diversas soluções tecnológicas
de apoio à gestão pública municipal, promovendo o governo eletrônico nos municípios catarinenses.
Estas soluções são compostas por sistemas que proveem serviços às entidades municipalistas
catarinenses por meio de uma rede colaborativa interinstitucional. Esta rede integra instituições
públicas como os municípios, os consórcios intermunicipais e as organizações privadas sem fins
econômicos, como é o caso da FECAM, da Escola de Gestão Pública Municipal (EGEM) e das vinte e
uma associações de municípios de Santa Catarina.
16
Os sistemas da RedeCIM foram desenvolvidos em diferentes plataformas computacionais, com
diferentes políticas de segurança e mecanismos de segurança, ou seja, cada sistema possui a sua
política de segurança e utiliza um método diferente de prover o acesso ao sistema. Em 2013, o número
de usuários com acesso aos sistemas da RedeCIM é de aproximadamente dois mil, distribuídos entre
os servidores públicos dos 295 municípios e dos colaboradores das instituições municipalistas
(FECAM, 2013), o que demonstra a necessidade e importância do aprimoramento do método atual
utilizado para garantir a segurança das informações.
Segundo Dias (2000), a gestão da segurança da informação é necessária para redução do
impacto e diminuir a probabilidade de incidentes de segurança, protegendo as informações, sistemas e
os recursos das manipulações não autorizadas.
Chadwick (2009 apud WANGHAM et at, 2010), afirma que o gerenciamento de identidades
consiste em um conjunto de funções e habilidades como administração, descoberta e troca de
informações usadas para garantir a identidade de uma entidade e as informações contidas nessa
identidade (atributos, credenciais e certificados), permitindo assim que relações comerciais possam
ocorrer de forma segura.
Dentro deste contexto, este trabalho procurou fazer uma contribuição para a RedeCIM, na área
de gestão de identidades, visando subsidiar a FECAM na definição do modelo e das ferramentas
tecnológicas e no desenvolvimento de um sistema de gestão de identidades para instituição.
1.1 PROBLEMA DE PESQUISA
O desenvolvimento de novas soluções tecnológicas de apoio aos municípios catarinenses foi
avançando conforme a demanda de solicitações dos municípios e de acordo com os recursos
disponíveis. No período de 2005 a 2013, a FECAM passou de uma simples provedora de informações,
por meio do site institucional, para uma prestadora de serviços de Tecnologia da Informação aos
municípios e instituições coligadas.
O crescimento na quantidade de sistemas resultou no expressivo aumento no número de
usuários. Além disso, os sistemas foram desenvolvidos por vários fornecedores, resultando na adoção
de diferentes mecanismos de autenticação e de autorização, além da implantação de políticas de
gerenciamento de identidades distintas.
17
Atualmente, os usuários realizam diversos cadastros e possuem um número excessivo de
senhas, ou seja, para cada sistema que o usuário possui acesso é necessário obter uma senha diferente.
Esta forma dificulta o usuário na guarda segura das senhas e dificulta o processo de gestão de usuários
por parte da organização, pois a mesma possui diversos provedores de identidades integrados nas
diferentes aplicações. Outra dificuldade encontrada é a alta rotatividade dos servidores públicos
municipais, que implica na necessidade constante de novos cadastros de usuários e da desativação dos
usuários que não fazem mais parte da organização.
Os usuários no seu dia-a-dia precisam acessar diversos sistemas e a cada acesso realizar uma
nova autenticação. Desta forma, aumentando a probabilidade de captura das credenciais dos usuários
por invasores, durante a troca de informações do processo de autenticação. Visando minimizar este
problema, Jøsang e Pope (2005) apresenta a autenticação single sing-on (SSO) como a possibilidade
de um usuário autenticado em um prestador de serviços ser considerado autenticado por outros
prestadores de serviços, normalmente utilizando uma entidade responsável pela atribuição de
identificadores, por emitir credenciais e por autenticar o usuário.
Neste contexto, têm-se as seguintes questões de pesquisa :
1. Qual modelo de gestão de identidades é o mais adequado para o cenário da FECAM?
2. Como prover a autenticação única (Single Sing-On - SSO) nos serviços da RedeCIM?
3. Dentre as ferramentas e tecnologias disponíveis, quais atendem aos requisitos do
modelo selecionado e das aplicações/serviços existentes na RedeCIM?
4. Quais especificações técnicas precisam ser definidas para operação e uso do sistema de
gerenciamento de identidades na FECAM?
5. Para os administradores de serviços da RedeCIM, quais as vantagens e desvantagens do
uso de um novo sistema de gerenciamento de identidades?
1.1.1 Solução Proposta
O desenvolvimento de um sistema de gerenciamento de identidades visa auxiliar o processo de
gestão de identidades dos provedores de serviço integrados à RedeCIM, buscando o aprimoramento de
práticas e o aumento do conhecimento em torno do problema da pesquisa.
18
Este trabalho compreende a implementação de sistema de gerenciamento de identidades que
utiliza a especificação SAML 2.0 (OASIS, 2008), como solução para troca de mensagens seguras com
os provedores de serviços da RedeCIM e o provedor de identidades (IdP). Como a FECAM necessita
de um modelo de gerenciamento de identidades que possibilite o controle efetivo dos usuários, optou-
se pelo modelo centralizado, entretanto foi necessário considerar a interoperabilidade do sistema de
gerenciamento de identidades com sistemas de outras entidades, conforme recomendado pela
arquitetura e-PING, (Padrões de Interoperabilidade de Governo Eletrônico), arquitetura que define um
conjunto mínimo de premissas, políticas e especificações técnicas que regulamentam a utilização da
Tecnologia de Informação e Comunicação (TIC) no governo federal (GOV.BR, 2013).
Através do uso de tecnologias que possibilitem a autenticação única (Single Sign-On) os
usuários terão a possibilidade de, por meio de uma única autenticação, acessar diversos serviços que
compõem o círculo de confiança estabelecido pelo sistema de gerenciamento de identidades proposto.
1.1.2 Delimitação de Escopo
Considerando o cenário apresentado, este projeto está focado principalmente no
desenvolvimento de um provedor de identidade para os sistemas disponibilizados pela FECAM, e
operacionalizados pelos servidores públicos municipais e colaboradores das instituições coligadas.
Neste sentido, não é considerado a gestão dos usuários finais, como exemplo o cidadão que acessa aos
portais municipais.
Para garantir a troca de informações seguras na autenticação e autorização dos usuários foi
escolhido o padrão SAML 2.0, também por esta ser uma tecnologia recomendada pela arquitetura e-
PING e que possui boa documentação e suporte disponível. Observa-se ainda que este padrão também
é utilizado na Comunidade Acadêmica Federada (CAFe) que possui uma infraestrutura de autenticação
e autorização federada já implantada e consolidada (RNP, 2013).
1.1.3 Justificativa
Segundo Thibeau (2009), até pouco tempo atrás as tecnologias de identidades digitais eram
confinadas a sistema fechados, ou seja, sistemas que só atendem a uma população definida de usuários
conhecidos. Tais como redes corporativas ou sites individuais. A ascensão da Internet, interligando
19
milhões de sites e sistemas diferentes, demandou o desenvolvimento de novas soluções de identidades
digitais, abrindo os sistemas fechados para usuários qualificados de qualquer lugar na Internet.
Nos municípios, a crescente demanda da sociedade por informações e por serviços eletrônicos
promoveu o desenvolvimento dos mais variados provedores de serviços web, ocasionando a
necessidade de aprimoramento no processo de gerenciamento de identidades digitais. Neste contexto,
acredita-se que este trabalho possa contribuir com uma importante ferramenta para a gestão efetiva dos
usuários que possuem acesso aos serviços disponibilizados na RedeCIM.
O impacto deste trabalho para a FECAM não está apenas nos benefícios tecnológicos, mas
também no conhecimento adquirido sobre gestão de identidades, conhecimento que atualmente está
centrado nas empresas que fornecem sistemas. Outro benefício importante está no aspecto cultural,
pois o trabalho busca promover uma mudança tanto para os usuários das instituições que interagem
com o sistema de IdM, quanto para as empresas que terão que se adaptar ao novo modelo de gestão de
identidades e ao padrão SAML (Security Assertion Markup Language).
1.2 OBJETIVOS
Esta seção formaliza os objetivos do trabalho, conforme descrito a seguir.
1.2.1 Objetivo Geral
Aprimorar o processo de gestão de identidades na Rede Catarinense de Informações
Municipais, por meio do desenvolvimento de um sistema de gerenciamento de identidades.
1.2.2 Objetivos Específicos
1. Analisar os modelos e as tecnologias empregadas para gerenciamento de identidades
visando identificar quais podem ser empregados na solução proposta;
2. Conceber um sistema de gerenciamento de identidades com suporte a autenticação única
(Single Sing-On – SSO) para RedeCIM;
3. Definir as especificações técnicas para operação e uso do sistema de gerenciamento de
identidades da RedeCIM;
20
4. Avaliar a satisfação dos usuários ao fazer uso do protótipo desenvolvido (sistema
proposto); e
5. Verificar o atendimento aos requisitos definidos no projeto por meio de testes de
integração, usabilidade e de segurança.
1.3 METODOLOGIA
Segundo Gil (2008), a metodologia é um conjunto de procedimentos intelectuais e técnicos
para que seus objetivos sejam atingidos, os métodos fornecem as bases lógicas para a investigação do
objeto da pesquisa. A partir deste contexto, a metodologia se relaciona como ferramenta de auxilio
para o alcance do objetivo da pesquisa.
1.3.1 Metodologia da Pesquisa
No desenvolvimento da pesquisa, foi aplicado o método hipotético-dedutivo. Conforme Gil
(2008), quando o conhecimento é insuficiente para explicar um fenômeno, surge o problema, para
expressar as dificuldades do problema são formuladas as hipóteses, das hipóteses deduzem-se
conseqüências a serem testadas; enquanto o método dedutivo procura confirmar a hipótese.
A pesquisa buscou gerar conhecimentos para o desenvolvimento de uma solução de um
problema específico, desta forma o presente trabalho pode ser caracterizado como uma pesquisa de
natureza aplicada. Já na forma de abordagem do problema a pesquisa em parte é qualitativa, pois o
objetivo é melhorar o processo de gerenciamento de identidades existente, ou seja, avaliar o
cumprimento dos requisitos de segurança. A atividade de avaliação de satisfação dos usuários utilizou
técnica estatística, logo pode ser classificada como quantitativa (GIL, 2008).
1.3.2 Procedimentos Metodológicos
Pesquisa bibliográfica: a pesquisa bibliográfica consistiu em pesquisar conceitos para
a definição exata do problema. A pesquisa foi realizada sobre os modelos de
gerenciamento de identidades, e sobre as ferramentas e tecnologias existentes para o
desenvolvimento de sistemas de gestão de identidades;
Definição do Provedor de Identidade (IdP): a definição do provedor de identidade,
compreendeu a apresentação de uma visão geral do sistema, a análise de requisitos
21
funcionais e não funcionais, as especificações técnicas e a modelagem dos casos de uso
utilizando a linguagem UML (Unified Modeling Language);
Implementação do sistema: nesta etapa foram implementados os protótipos do
provedor de identidades e do provedor de serviço; e
Avaliação do sistema proposto: esta etapa consistiu em verificar se o sistema IdP
atendeu todos os requisitos funcionais e não funcionais por meio da execução de casos
testes, e em avaliar a satisfação dos usuários no uso do protótipo desenvolvido por meio
da pesquisa de satisfação aplicada nos três perfis de usuários da RedeCIM.
1.4 ESTRUTURA DO TRABALHO
A estrutura deste documento se divide em seis capítulos, sendo o Capítulo 1, denominado
Introdução, que aborda a visão geral do trabalho, apresentando a problemática, a solução proposta e os
objetivos a serem alcançados com o desenvolvimento do trabalho.
O Capítulo 2, Fundamentação Teórica, é apresentado o estudo bibliográfico sobre conceitos de
segurança da informação e de modelos de gestão de identidades, além da análise de tecnologias para a
autenticação Single Sing-On, como SAML, OpenID, Oauth, Kerberos, CAS, OpenLDAP e Arquitetura
e-PING.
No Capitulo 3 é apresentado os trabalhos relacionados ao tema da pesquisa.
O Capítulo 4 apresenta o desenvolvimento do IdP, incluindo a análise dos serviços da
RedeCIM, uma visão geral do sistema IdP, a descrição dos requisitos funcionais e não funcionais, as
especificações técnicas, modelagem em UML e o detalhamento da implementação do protótipo
desenvolvido.
No Capítulo 5, são apresentados os experimentos de avaliação realizados, bem como os
resultados obtidos na aplicação de tais experimentos.
Concluindo, no Capítulo 6, apresenta-se as conclusões, no qual são abordados os resultados
obtidos e as opções para o desenvolvimento de trabalhos futuros.
22
2 FUNDAMENTAÇÃO TEÓRICA
O embasamento teórico necessário para o desenvolvimento do sistema de gerenciamento de
identidades da RedeCIM é apresentado neste capítulo. Os tópicos abordados são: Segurança da
Informação, Gestão de Identidades, Autenticação Single Sing-On, SAML, OpenID, Oauth, Kerberos,
CAS, OpenLDAP e Arquitetura e-PING.
2.1 SEGURANÇA DA INFORMAÇÃO
Segundo Dias (2000), segurança é proteger informações, sistemas, recursos e serviços contra
erros, manipulações não autorizadas e desastres, para redução do impacto e diminuir a probabilidade
de incidentes de segurança. Portanto é necessária a gestão da segurança da informação para resolver os
problemas encontrados.
Stallings (2008) enfatiza que com a introdução do computador tornou-se evidente a necessidade
de ferramentas automatizadas para proteger arquivos e outras informações armazenadas em um
computador, especialmente no caso de um sistema compartilhado, e a necessidade é ainda mais
presente para sistemas que podem ser acessados por meio de uma rede de dados ou a internet.
Segundo Stallings (2008) a arquitetura de segurança OSI (Open Systems Interconnection)
oferece uma estrutura sistemática para definir ataques à segurança, mecanismos e serviços de
segurança. Os ataques à segurança são classificados em ataques passivos e ataques ativos. Os ataques
passivos monitoram as transmissões com o objetivo de obter informações durante a transmissão.
Enquanto os ataques ativos envolvem alguma modificação do fluxo de dados ou a criação de um fluxo
falso. Os ataques ativos são muito difíceis de impedir devido a variedade de vulnerabilidades, porém é
possível detectar e recuperar qualquer interrupção causada. Por outro lado os ataques passivos são
difíceis de detectar, entretanto existem medidas para impedir seu sucesso.
Stallings (2008) define os serviços de segurança X.800 como um serviço fornecido por uma
camada de protocolo de comunicação de sistemas abertos, que garante a segurança adequada dos
sistemas ou das transferências de dados. Os serviços de segurança definem as políticas, enquanto os
mecanismos de segurança implementam as diretrizes definidas nas políticas. A X.800 divide os
serviços de segurança em cinco categorias, apresentadas a seguir:
23
Autenticação: refere-se à garantia de que uma comunicação é autêntica. A função do
serviço de autenticação é garantir ao destinatário que a mensagem é proveniente de
onde ela afirma ter vindo;
Controle de acesso: é a capacidade de limitar e controlar o acesso aos sistemas e
aplicações hospedeiras por meio de enlaces de comunicação. Para obter este controle
cada entidade precisa ser identificada para ter o acesso, ou autenticada, de modo que os
direitos de acesso possam ser ajustados ao indivíduo;
Confidencialidade dos dados: é o serviço de proteção dos dados transmitidos contra
ataques passivos. Vários níveis de proteção podem ser identificados, o serviço mais
amplo protege todos os dados transmitidos entre dois usuários por um período de
tempo;
Integridade dos dados: a integridade pode se aplicar a um fluxo de mensagens, uma
única mensagem ou campos selecionados dentro de uma mensagem. Este serviço
garante que as mensagens são recebidas conforme enviadas, sem duplicação, inserção,
modificação, reordenação ou repetição; e
Irretratabilidade: impede que o emissor ou receptor negue uma mensagem
transmitida, assim pode-se provar quando uma mensagem foi enviada e também quando
uma mensagem foi recebida.
Além dos cinco serviços de segurança apresentados anteriormente, as recomendações X.800 e
RFC 28281, têm a disponibilidade como sendo a prioridade de um sistema, ou seja, o sistema deve
estar acessível e utilizável quando uma entidade autorizada desejar (STALLINGS, 2008).
Os mecanismos de segurança são implementados e divididos em camadas específicas do
protocolo ou do serviço de segurança. Stallings (2008) apresenta os seguintes mecanismos que podem
ser incorporados à camada de protocolo apropriado a fim de oferecer alguns serviços de segurança
OSI:
1 Disponível em: http://www.rfc-editor.org/rfc/rfc2828.txt
24
Cifragem: é o uso de algoritmos matemáticos para transformar os dados em um
formato que não seja prontamente decifrável. A transformação e subsequente
recuperação dos dados dependem de um algoritmo e chaves de criptografia;
Assinatura digital: são dados anexados a uma unidade de dados que permite que um
destinatário da unidade de dados comprove a origem e a integridade de dados e proteja-
se contra falsificação;
Controle de acesso: são mecanismos que impõem direitos de acesso aos recursos;
Integridade de dados: é uma série de mecanismos utilizados para garantir a
integridade de uma unidade de dados ou fluxo de unidades de dados;
Troca de informações de autenticação: é o mecanismo que garante a identificação de
uma entidade por meio da troca de informações;
Preenchimento de tráfego: é a inserção de bits nas lacunas de um fluxo de dados para
frustrar as tentativas de análise de tráfego;
Controle de roteamento: permite a seleção de determinadas rotas fisicamente seguras
para certos dados e permite mudanças de roteamento, especialmente quando existem
brechas de segurança; e
Certificação: é o uso de uma terceira entidade confiável para garantir certas
propriedades de uma troca de dados (STALLINGS, 2008).
2.2 GESTÃO DE IDENTIDADES
Os investimentos em Tecnologia da Informação da FECAM chegam a aproximadamente 45% do
faturamento fixo mensal da entidade para aprimorar a gestão corporativa e principalmente para
oferecer serviços no ambiente on-line aos municípios catarinenses. O uso destes ambientes requer
segurança, portanto, é preciso possuir um sistema que possa autenticar e autorizar os usuários antes de
fornecer esses serviços (REDDICK, 2009 apud BALDONI, 2010). Os sistemas que autenticam e
autorizam os usuários a utilizar determinado serviço são conhecidos como sistema de Gerenciamento
de Identidades (IdM – Identity Management).
25
Segundo Chadwick (2009 apud WANGHAM et al, 2010), o gerenciamento de identidades
consiste em um conjunto de funções e habilidades como administração, descoberta e troca de
informações usadas para garantir a identidade de uma entidade e as informações contidas nessa
identidade, permitindo assim que relações comerciais possam ocorrer de forma segura.
O gerenciamento de identidades é definido por Santos (2007), como um conjunto de processos
e tecnologias voltadas para o tratamento e manipulação de identidades de usuários desde o nascimento
dos dados em sistemas de recursos humanos e cadastros de terceiros até as aplicações gerenciadas
(sistemas operacionais, correios eletrônicos, acesso físico etc.).
“A aquisição de sistemas corporativos como ERP, CRM, sistemas operacionais, junto com
diversos sistemas desenvolvidos internamente em uma corporação geram diversos repositórios
de usuários para autenticação e autorização, exigindo uma administração descentralizada e
suscetível a erros.” (SANTOS, 2007)
O controle dos usuários dos sistemas deve ser realizado durante o período em que o
colaborador estiver ativo na entidade, e principalmente desativá-lo no momento do desligamento do
mesmo. Os usuários que deveriam estar inativados em N sistemas, recursos ou aplicativos após serem
demitidos podem continuar com o acesso ativo em uma aplicação, o que abriria oportunidades de
fraude (SANTOS, 2007).
Conforme Bhargav-Spantzel et al. (2007), o sistema de gerenciamento de identidades possui os
seguintes elementos:
Usuário: cliente do serviço;
Identidade: atributos que definem um usuário. Ex: nome, cpf, e-mail, etc.
Provedor de Identidades (Identity Provider - IdP): sistema reponsável por gerar as
identidades dos usuários; e
Provedor de Serviços (Service Provider - SP): responsável por oferecer recursos a
usuários que possuem uma identidade verdadeira e com os atributos corretos.
No sistema gerenciador de identidades, o provedor de identidades (Identity Provider - IdP) é um
provedor de serviços de identidades. Sua responsabilidade é de manter a base de dados de usuários do
domínio e validar as credenciais de usuários. O provedor de serviços (Service Provider - SP) é a
26
entidade mais próxima ao recurso do domínio em questão, sendo responsável por verificar a validade
dos cookies de sessão e das permissões de acesso aos recursos por usuários autenticados (FELICIANO
et al., 2011).
Santos (2007) define uma identidade como a representação digital de uma pessoa. Esta
representação digital normalmente é composta por um identificador único e outros dados (atributos)
como documentos, nome, e-mail, etc. A identidade de uma pessoa é composta por uma grande
quantidade de informações pessoais que caracterizam essa pessoa em diferentes contextos das quais
ela faz parte.
Na Figura 1, tem-se um exemplo de identidade.
Figura 1: Exemplo de uma identidade digital
Fonte: Santos (2007)
O usuário é a entidade que terá acesso aos serviços disponibilizados pelo provedor de serviços
em um determinado domínio por meio de sua identidade cadastrada no sistema gerenciador de
identidades. Por exemplo, um servidor público municipal é usuário dos serviços da Prefeitura que seus
dados estão cadastrados.
2.2.1 Modelos de Gerenciamento de Identidades
Segundo Jøsang e Pope et al. (2005), existem quatro modelos de interação entre os elementos
dos sistemas de gerenciamento de identidades, estes modelos são conhecidos como tradicional,
centralizado, federado e centrado no usuário. A Figura 2 ilustra cada modelo de IdM, a saber:
27
Figura 2: Classificação dos modelos de gerenciamento de identidade
Fonte: Wangham et al. (2010)
a) Modelo Tradicional: nesse modelo o provedor de identidade esta na própia aplicação do
provedor de serviços;
b) Modelo Federado: esse modelo possibilita o usuário utilizar o provedor de identidades de sua
escolha dentro de uma federação estabelece uma relação de confiança entre diversos
provedores de identidades;
c) Modelo Centralizado: nesse modelo usuários de vários provedores de serviços se autenticam
em um único provedor; e
d) Modelo Centrado no Usuário: nesse modelo o usuário possui total controle sobre as
informações de sua identidade, sendo uma evolução dos modelos federado e centralizado.
28
Segundo Wangham et al., (2010), o modelo tradicional é amplamente utilizado nos sistemas
atuais. Neste modelo, a autenticação é tratada de forma isolada e cabe ao usuário criar uma identidade
em cada provedor de serviços, não havendo assim o compartilhamento de identidades desses usuários
entre diferentes provedores de serviço. Para o provedor de serviços, isto representa um custo maior
para gerenciar sua infraestrutura de IdM (WANGHAM et al., 2010). Uma desvantagem deste modelo
é que o usuário precisa lembrar da identidade que possui em cada serviço que o usuário acessa
(FELICIANO et al., 2011).
Conforme Feliciano et al. (2011) o modelo centralizado surgiu para amenizar os problemas
existentes no modelo tradiconal. Neste modelo, há o conceito de provedor de identidades (IdP –
Identity Provider) e de provedores de serviços (SPs – Service Providers), no qual diversos provedores
de serviços delegam a autenticação de seus usuários a um único IdP.
Segundo Bhargav-Spantzel et al. (2007), o modelo centralizado, no qual o usuário se autentica
uma única vez no provedor de identidades e utiliza diversos serviços de provedores parceiros, sem a
necessidade de nova autenticação, é conhecido como SSO (Single Sing-On). Neste modelo, o usuário
apresenta seu identificador e credenciais apenas uma vez no IdP parceiro do SP, outros serviços que
utilizam o mesmo IdP podem confiar na autenticação prévia do usuário e disponibilizar recursos sem a
necessidade de novo processo de autenticação (FELICIANO et al., 2011).
Segundo Maliki e Seigneur (2007), o ponto fraco do modelo centralizado é que o provedor de
identidades possui controle absoluto sobre as informações de seus usuários, podendo assim usá-las da
forma que bem entender. Este modelo além da questão da privacidade ainda oferece outras
desvantagens, tais como, escalabilidade, segurança (o IdP é um ponto de falha) e o fato de que os SPs e
IdP necessitam estar no mesmo domínio administrativo (FELICIANO et al., 2011).
O modelo de gerenciamento de identidades federadas busca otimizar a troca de informações
relacionadas a uma identidade por meio de relações de confiança construídas na federação
(CAMENISCH & PFITZMANN, 2007). Este modelo utiliza o conceito de autenticação única por
meio de acordos estabelecidos entre provedores de identidades que asseguram que identidades
emitidas em um domínio sejam reconhecidas por outros provedores de serviços. Um dominio
administrativo pode representar uma empresa, uma universidade, uma prefeitura, etc. e é formado por
usuários, diversos provedores de serviços e um único provedor de identidades. Neste modelo, os SPs e
29
o IdP podem estar em domínios administrativos diferentes sendo considerado uma evolução do modelo
centralizado (FELICIANO et al., 2011).
Segundo Wangham et al. (2010), a vantagem no modelo federado para os usuários é não precisar
lidar com diversas identidades e passar diversas vezes pelo processo de autenticação. Já para os
provedores de serviços, o benefício é a manutenção de um número menor de usuários temporários.
Segundo Feliciano et al. (2011), o modelo centrado no usuário é uma evolução do modelo
federado e tem como objetivo resolver uma das principais críticas relacionadas aos modelos anteriores,
que é o controle sobre as informações da identidade do usuário. Este modelo objetiva dar ao usuário o
total controle sobre suas identidades digitais, sendo possível a utilização dos modelos centralizado ou
federado nas principais propostas de implementação. Na proposta de Josang e Pope (2005), a solução
é deixar os identificadores de usuários e as credenciais de diferentes prestadores de serviços
armazenados em um único dispositivo físico, que pode ser um cartão inteligente ou algum outro
dispositivo portátil pessoal. O usuário autentica neste dispositivo físico e cabe a este liberar as
informações do usuário para cada provedor de serviços que o usuário acessar.
As diferenças dos modelos apresentados estão basicamente na forma como as identidades dos
usuários são armazenadas e disponibilizadas, sendo que em alguns modelos o compartilhamento da
identidade entre provedores de serviços, aliado ao conceito de autenticação única trazem facilidades
aos usuários (BHARGAV-SPANTZEL et al., 2007).
2.2.2 Opções para Implantação da autenticação Single Sing-On (SSO)
Jøsang e Pope (2005) abordam a autenticação single sing-on (SSO) como a possibilidade de um
usuário autenticado em um prestador de serviços ser considerado autenticado por outros prestadores de
serviços. Normalmente há uma entidade responsável pela atribuição de identificadores, por emitir
credenciais e por autenticar o usuário.
Segundo Nogueira, Santos e Custódio (2012) o SSO em sua forma mais simples, significa um
mecanismo onde o usuário pode acessar vários serviços por meio da realização de sua autenticação
apenas uma vez. Geralmente utilizando um gerenciador central de informações cadastrais de usuários.
Um ambiente tipico de SSO envolve provedores de serviços (SP) e provedores de identidade (IdP).
30
Peixoto (2012) apresenta na Figura 3, uma representação simplificada do ambiente SSO, no qual
o usuário (user) com apenas um processo de autenticação consegue o acesso aos recursos dos serviços
A, B e C.
Figura 3: Exemplo de autenticação única
Fonte: Peixoto (2012)
Segundo Feliciano et al. (2011), uma questão importante no processo de implantação de sistemas
de gerenciamento de identidades é a instalação de um middleware2 que ficará reponsável pelos
serviços de identidade (autenticação, autorização, entre outros), principalmente se o SSO envolver
diferentes domínios.
2 Middleware é o neologismo criado para designar camadas de software que não constituem diretamente aplicações, mas
que facilitam o uso de ambientes ricos em tecnologia da informação. A camada de middleware concentra serviços como
identificação, autenticação, autorização, diretórios, certificados digitais e outras ferramentas para segurança. Disponível
em: http://www.rnp.br/noticias/2006/not-060926.html
31
A seguir, algumas opções para implantação de SSO estão descritas (BERTINO & TAKAHASHI,
2011).
Baseada em Broker
Nesta abordagem, um servidor central é responsavel por autenticar os usuários e emitir uma
credencial em forma de ticket. Através destes tickets, é possivel ao usuário obter acesso aos recursos
protegidos. O Kerberos é um exemplo de implantação de SSO que utiliza a abordagem baseada em
broker. Esta abordagem está relacionada com o modelo centralizado de IdM.
A Figura 4 apresenta o processo de autenticação baseada em broker, aonde cliente acessa o
Servidor Kerberos, comprova sua identidade por meio das suas credenciais e solicita um ticket de
concessão (passo 1). Com ticket de concessão o cliente adquire um ticket de acesso no Servidor de
Tickets (passo 2), e com o ticket de acesso o cliente requisita o acesso ao Servidor de Aplicações
(passo 3).
Figura 4: Processo de SSO que utiliza abordagem Baseada em Broker
Fonte: Feliciano et al. (2011).
Baseada em Agentes
Esta abordagem utiliza um filtro instalado em um servidor de aplicação Web. Este filtro
intercepta todas as requisições que passam neste servidor (passo 1, da Figura 5) e, com base em regras
32
pré-estabelecidas, redireciona a requisição para um servidor de autenticação (provedor de identidades,
passo 2). Após a autenticação bem sucedida (passo 3), o agente verifica se há alguma credencial válida
e, se houver, libera o acesso ao recurso solicitado (passo 4).
Figura 5: Processo de SSO que utiliza abordagem Baseada em Agente.
Fonte: Feliciano et al. (2011)
Baseada em Proxy Reverso
Esta abordagem utiliza um proxy localizado na borda da rede ou em uma zona desmilitarizada
(DMZ). Através deste proxy, requisições de acesso a recursos (por exemplo, aplicações) são filtradas
(com o uso de um agente, passo 1, da Figura 6) e o usuário é redirecionado para um servidor de
autenticação (provedor de identidades, passo 2). Após a autenticação bem sucedida, o usuário é
redirecionado de volta para o proxy (passo 3), que por sua vez estará apto a liberar o acesso
redirecionando o usuário para o recurso protegido (passo 4). Nesta abordagem, é possível através do
proxy, o redirecionamento para qualquer domínio ao qual este tenha alcance. Um problema com esta
abordagem é que há uma perda de eficiência uma vez que todas as requisições passam pelo mesmo
proxy. Uma vantagem é que não é necessário instalar componentes adicionais nos servidores de
aplicação para protegê-los.
33
Figura 6: Processo de SSO que utiliza abordagem Baseada em Proxy Reverso.
Fonte: Feliciano et al. (2011)
Baseada em API
Nesta abordagem há a inclusão de uma API relacionada com o middleware para IdM nas
aplicações a serem protegidas. Este mecanismo é o mais intrusivo de todos, uma vez que cada
aplicação necessita chamar as primitivas oferecidas pela API. Um fator positivo é que nesta
abordagem é possível obter um nível de controle de acesso mais sofisticado se comparado com as
demais abordagens. No passo 1, da Figura 7, a requisição para acessar a aplicação Web é interceptada
pela API que está na própria aplicação. No passo 2, a API redireciona o browser para o provedor de
identidades. No passo 3, após a autenticação bem sucedida, este provedor redireciona o browser do
usuário para a API. No passo 4, a API informa à aplicação que o usuário está autenticado e a aplicação
segue o seu fluxo de execução.
34
Figura 7: Processo de SSO que utiliza abordagem Baseada em API.
Fonte: Feliciano et al. (2011)
Baseada em Serviços
Esta abordagem é parecida com a abordagem baseada em API. A diferença é que neste caso as
chamadas são realizadas remotamente (passos 2 e 3, da Figura 8), pois são oferecidas diretamente pelo
provedor de serviço de identidades.
Figura 8: Processo de SSO que utiliza abordagem Baseada em Serviços.
Fonte: Feliciano et al. (2011)
35
2.3 SOLUÇÕES PARA IMPLANTAÇÃO DE AUTENTICAÇÃO SSO
Durante anos diversos sistemas de gerenciamento de identidades que possibilitam o SSO foram
implementados, inclusive permitindo o compartilhamento de credenciais pelos provedores de
identidades. Nesta seção, estão descritos alguns destes protocolos, padrões e ferramentas
desenvolvidas para prover a autenticação SSO, tais como: OpenLDAP, especificação SAML, OpenID,
Oauth, Kerberos e CAS.
2.3.1 SAML
O SAML (Security Assertion Markup Language) é um padrão que define uma estrutura
baseada em XML para descrever e trocar informações de segurança entre os parceiros de negócios on-
line. Estas informações são expressas sob a forma de afirmações portáteis SAML. O padrão SAML
define a sintaxe e regras claras para a solicitação, a criação, a comunicação e a utilização das asserções
SAML (OASIS, 2008).
A OASIS (Organization for the Advandement of Structured Informations Standards)
desenvolve e mantém um framework SAML aberto, usado para comunicar a autenticação dos usuários,
seus direitos e seus atributos, permitindo a geração de afirmações solicitadas pelos usuários ou
organizações parceiras na troca de informações entre aplicativos coorporativos (OASIS, 2005).
Segundo OASIS (2005), a primeira versão do SAML V1.0 se tornou um padrão OASIS em
2002, seguido pela versão SAML V1.1 em 2003, que ganhou importância em serviços financeiros, de
ensino superior, de governos e outros serviços do segmento industrial, alcançando significativo
sucesso. Atualmente, a SAML está na versão 2.0 (lançada em 2005) e se transformou em um passo
fundamental para a plena convergência dos padrões de identidade federada.
As aplicações da especificação SAML estão sendo utilizadas de diferentes maneiras, as mais
relevantes estão descritas em (OASIS, 2005):
Web SSO: o SAML possibilita o SSO através da comunicação de uma asserção de
autenticação em um primeiro local para um segundo local que confia na origem da
autenticação.
36
Autorização baseada em atributos: semelhante ao cenário de SSO, o SAML permite a
autorização baseada em atributos para comunicar informações de uma identidade entre
diferentes Webs sites, possibilitando desta forma apoio em algumas transações.
Segurança em Serviços da Web: as asserções SAML podem ser usadas dentro das
mensagens SOAP, afim de realizar operações com segurança de informações e
identidade entre agentes em um serviço web.
2.3.1.1 Componentes da especificação SAML
Segundo o Governo de Orientações e Prioridades de TIC (Government ICT Directions and
Priorities - GCIO) do Governo da Nova Zelândia, o SAML v2.0 em termos gerais é uma norma que
define as asserções SAML, protocolos, associações (ligação de mensagens para os protocolos de
comunicação), e perfis SAML refletindo um caso de uso definido, juntamente com a assinatura XML
aplicável e padrões de criptografia do W3C3 (GCIO, 2005). A Figura 9 apresenta a relação entre os
componentes do SAML.
3 Consórcio World Wide Web (W3C) é um consórcio internacional que desenvolve os padrões para Web, disponível em:
http://www.w3c.br/Sobre
37
Figura 9: Relação entre os componentes SAML
Fonte: OASIS (2005)
OASIS (2005) fornece uma descrição alto nível dos componentes do SAML representados pela
Figura 9:
Asserções (assertions)
Uma asserção é um pacote de informações que suprimem uma ou mais declarações feitas por
uma autoridade SAML. O SAML define três tipos de asserções que podem ser criadas por uma
autoridade SAML, que são:
Autenticação: esse tipo de asserção é normalmente gerada por uma autoridade SAML
chamada de provedor de identidade, que é responsável por autenticar os usuários e
manter o controle de suas informações;
Atributo: esta asserção associa os usuários aos seus atributos especificados;
Decisão de autorização: asserção permitindo ou negando a autorização de serviços de
uma solicitação específica de acesso.
38
Segundo OASIS (2005), a estrutura externa de uma asserção é genérica e fornece a informação
que é comum a todas as declarações dentro dela. Os elementos existentes em uma asserção descrevem
a autenticação, os atributos ou as especificações definidas pelo usuário. A Figura 10 ilustra a estrutura
de alto nível de uma asserção de autenticação SAML.
Figura 10: Estrutura de alto nível da asserção SAML
Fonte: OASIS (2005)
Protocolos (protocols)
Os protocolos do SAML definem como as asserções SAML são transportadas entre os
participantes. As asserções podem ser geradas e trocadas entre os provedores de identidade e serviço,
usando uma variedade de protocolos de solicitação-resposta. Estes protocolos são baseados em XML e
são na forma de pares de solicitação-resposta, que detalham as informações ou a ação solicitada e
como isso será respondido (GCIO, 2005).
Os protocolos definidos dentro da especificação SAML realizam as seguintes ações:
Retornar uma ou mais asserções solicitadas. Isto é, em resposta a uma solicitação direta da
asserção desejada, ou uma consulta por asserções que atendam a critérios específicos;
39
Executar a autenticação mediante uma solicitação e retornar a asserção correspondente;
Registrar um identificador de nome ou rescindir um registro de nome, mediante solicitação;
Recuperar uma mensagem do protocolo que tenha sido solicitada por meio de um artefato;
Solicitar simultaneamente a saída de uma coleção de asserções relacionadas, ou seja desconecta
de tudo ao mesmo tempo, conhecido como “single logout”; e
Fornecer um mecanismo de ligação ou mapeamento de nomes identificadores em sites
federados.
Ligações (bindings)
O mapeamento do SAML para troca de mensagens de solicitação-resposta entre as partes
participantes utilizando protocolos de comunicação é chamado de Ligações SAML. Segundo o GCIO
(2005), há uma variedade de ligações definidas para o transporte de mensagens entre as partes
participantes. As ligações SAML v2.0 são:
Ligação SOAP (SOAP Binding). As mensagens SAML podem ser transmitidas utilizando o
protocolo SOAP bem definido;
Ligação SOAP Reverso (Reverter Binding SOAP). As mensagens SAML também podem ser
trocadas via SOAP reverso;
Ligação Redirecionamento HTTP (HTTP Redirect Binding). Esta ligação fornece o padrão
SAML com um mecanismo para transmitir uma mensagem SAML dentro da URL de uma
solicitação HTTP. Isso normalmente é necessário quando não há um caminho direto entre um
provedor de identidade e um provedor de serviços, caso em que a mensagem SAML tem que
ser transportado indiretamente, normalmente, via o navegador web do usuário final;
Ligação Mensagem HTTP (HTTP Post Binding). As mensagens SAML podem ser
transmitidas dentro do conteúdo de um formulário HTML postado em um provedor de
serviços;
40
Ligação Artefato HTTP (HTTP Artifact Binding). O Artefato HTTP SAML é um
mecanismo que permite a comunicação através de um agente do usuário HTTP intermediário,
esta ligação tem o objetivo de reduzir o fluxo de mensagens através do SAML; e
Ligação URI (URI Binding). Uma asserção SAML específica pode ser repassada em uma
HTTP URI.
Perfis (profiles)
Um perfil SAML é uma maneira de definir como as asserções, os protocolos e as ligações
SAML são combinados para especificar um caso de uso particular. O objetivo de um perfil é remover
algumas das ambiguidades na aplicação SAML que surge inevitavelmente em um padrão de uso
geral. Um perfil pode ser usado para definir restrições e / ou extensões de SAML para melhorar a sua
adequação para um uso ou aplicação particular. Por exemplo, o Web SSO especifica o perfil como
federação de identidades habilitado para a sessão do navegador web do usuário, especificando a
maneira pela qual as afirmações de autenticação SAML são comunicadas entre um Provedor de
Identidade e um Provedor de Serviços.
Outro tipo de perfil SAML é o perfil baseado em atributos, que prevê regras específicas para
interpretação de atributos em uma asserção SAML. Um exemplo é o Perfil X.500/LDAP, que descreve
como utilizar atributos X.500/LDAP dentro de asserções SAML atributos (OASIS, 2005).
2.3.1.2 Benefícios da utilização da especificação SAML
Segundo OASIS (2005) os benefícios de utilização da especificação SAML para troca de
informações de identidades digitais dos usuários e das organizações incluem os seguintes itens:
Neutralidade da plataforma: A segurança da especificação SAML é garantida independente
da lógica da aplicação, que é um princípio importante da arquitetura orientada a serviços. Este
benefício é garantido por abstrair da estrutura de segurança a arquitetura determinada;
Liberdade no acoplamento de diretórios: O SAML não requer que as informações do
usuário sejam mantidas e sincronizadas entre os diretórios;
41
Melhora da experiência on-line dos usuários finais: SAML permite o SSO (single sign-on),
permitindo aos usuários se autenticar em um provedor de identidade e, em seguida, acessar
provedores de serviços sem a necessidade de nova autenticação. Além disso, possibilita a
ligação de múltiplas identidades em uma federação de identidade. Desta forma o SAML
promove a privacidade e melhora a experiência dos usuários na personalização em cada
serviço;
Redução dos custos administrativos para os provedores de serviço: a reutilização de um
único ato de autenticação possibilitado pelo uso do SAML pode reduzir os custos de
manutenção da conta, desta forma transferindo os custos para o fornecedor das identidades; e
Transferência de risco: O SAML pode impulsionar a responsabilidade pela gestão das
identidades para o provedor de identidade, que geralmente possui o modelo de negócio mais
compatível do que um provedor de serviços.
2.3.2 OpenID
Segundo Thibeau (2009) o OpenID é um protocolo de autenticação SSO que permite que os
usuários se registrem e se autentiquem em sites de terceiros que utilizam o OpenID, para exemplo, a
maioria dos grandes portais da Web, como a AOL, Facebook, Google e Yahoo fornecem suporte para
o OpenID.
“O OpenID é descentralizado, ou seja, nenhuma autoridade central deve aprovar ou registrar
uma aplicação ou um provedor OpenID. O usuário poderá escolher qual provedor OpenID
utilizar, e pode preservar seu identificador se mudar de provedor (NOGUEIRA, SANTOS e
CUSTÓDIO, 2012).
O protocolo OpenID utiliza redirecionamentos HTTP (Hypertext Transfer Protocol) entre o
usuário/aplicação e um provedor de identidades. Primeiramente o usuário deve se registrar em um
provedor de identidades com suporte OpenID. O provedor de identidades utiliza o nome da conta do
usuário para gerar a URL (Uniform Resource Locator) específica do usuário que será utilizada pelo
42
aplicativo cliente como argumento de localização do serviço remoto de autenticação do usuário no
círculo de confiança4 (FELICIANO et al., 2011).
A Figura 11 apresenta uma visão geral da troca de mensagens do protocolo OpenID é
apresentada a seguir (OPENID, 2013).
1. O usuário final inicia a autenticação apresentando um identificador para a terceira parte
confiante através de um sitio web com suporte OpenID;
2. O usuário fornece para a parte confiante a sua identificação ou URL do provedor OpenID
para realização da autenticação;
3. A parte confiante estabelece uma associação com o provedor OpenID. Uma chave secreta é
estabelecida utilizando o protocolo Diffie-Hellman Key Exchange. Esta associação é
estabelecida para facilitar o processo de assinatura e a verificação de mensagens trocadas
entre o provedor OpenID e a parte confiante;
4. A parte confiante redireciona o navegador do usuário para o provedor OpenID com um
pedido de autenticação OpenID (solicitação de uma asserção ou credencial);
5. O provedor OpenID verifica se o usuário final está autorizado a realizar a autenticação
OpenID que deseja fazê-lo. A maneira pela qual o provedor OpenID autentica o usuário
final e as políticas que cercam esta autenticação não estão especificadas no escopo;
6. O provedor OpenID redireciona o navegador Web do usuário final de volta para a parte
confiante com a afirmação que a autenticação seja aprovada (asserções positivas) ou uma
mensagem que a autenticação falhou (asserções negativas); e
7. A parte confiante verifica as informações recebidas a partir do provedor OpenID, incluindo
a verificação da URL retornada, das informações descobertas, do nonce e da assinatura. Na
4 Círculo de Confiança (CoT – Circles of Trust): representa um conjunto de organizações que cooperam entre si de acordo
com regras de confiança pré-estabelecidas para a autenticação de usuários e compartilhamento de recursos (SWITCH, 2011
apud FELICIANO et al., 2011)
43
verificação da assinatura a parte confiante utiliza a chave compartilhada estabelecida
durante a associação ou a solicita diretamente ao provedor OpenID.
Figura 11: Protocolo OpenID Authentication 2.0
Fonte: Wangham et al., (2009)
O OpenID é a maneira rápida, fácil e segura para entrar em sites. A seguir é apresentado alguns
benefícios da utilização do OpenID (OPENID, 2013).
Facilita o processo de acesso aos sites: o framework OpenID elimina o preenchimento
de cadastros repetitivos permitindo acesso a sites de maneira relativamente fácil
(OPENID, 2010);
Reduz a obrigação do usuário em manter diversos usuários/senha: retira do usuário
a obrigação de lembrar todos os nomes de usuário e múltiplas combinações de senha
44
necessárias para entrar nos sites, utilizando uma conta única a partir de provedores
como Google, Yahoo, Facebook e AOL (OPENID, 2010);
Controle da Identidade Digital: por ser um padrão descentralizado, o controle da
identidade do usuário é realizada pelo usuário (OPENID, 2010); e
Portabilidade de identidade: permite que os usuários utilizem os mesmos
identificadores e credenciais para diversos sites e serviços diferentes.
Segundo a especificação OpenID (2013), o framework OpenID utiliza apenas pedidos e
respostas HTTP, não exigindo nenhuma capacidade especial do software cliente, no caso um
navegador web. O framework não está vinculado à utilização de cookies, ou depende de qualquer outro
mecanismo específico da parte confiante (WANGHAM et al., 2009).
Segundo Nogueira, Santos e Custódio (2012), o OpenID possui diversas brechas de segurança,
entre estas estão: ataque de espionagem, ataque do homem do meio, cross-site-scripting, phishung e o
ataque de negação de serviço. O maior problema de segurança do OpenID é a vulnerabilidade de
phishung, que é quando um fraudador se passa por uma parte confiável e o usuário insere seu
identificador OpenID. Outra limitação do OpenID é não possuir suporte para o Single Log-Out (SLO)
e isso torna uma vulnerabilidade de segurança, por não ser possível controlar o tempo de vida de uma
sessão.
2.3.3 OAuth
Segundo Youn (2011), o OAuth é um protocolo que permite a um usuário final autorizar o
compartilhamento de informações entre serviços web ou aplicações. O objetivo do OAuth é permitir o
compartilhamento de recursos sem exigir que o usuário compartilhe sua real credencial com vários
serviços. De acordo com Hammer-Lahav (2007), o OAuth é um framework de código aberto que
permite ao usuário conceber acesso aos recursos privados de um site, denominado Provedor de
Serviços, para outro site, denominado Consumidor.
Segundo Nogueira, Santos e Custódio (2012) o protocolo OAuth introduz um terceiro fator
para o modelo tradicional de autenticação cliente-servidor: o “dono do serviço” (proprietário do
recurso). Em um modelo OAuth o cliente requisita o acesso para os recursos controlados pelo “dono
do recurso".
45
Segundo Hardt (2012), o OAuth em vez de usar as credenciais do proprietário do recurso de
acesso protegido, o cliente obtém um token de acesso – uma string denotando um âmbito específico,
tempo de vida, e outros atributos de acesso. Os tokens de acesso são emitidos para os clientes de
terceiros por um servidor de autorização com a autorização do proprietário do recurso. Desta forma o
cliente utiliza o token de acesso para acessar os recursos protegidos hospedados pelo servidor de
recursos.
A versão atual do OAuth 2.0 possui estruturas de framework e característica que permite
estendê-lo de acordo com as necessidades dos desenvolvedores. O OAuth 2.0 permite que um terceiro
aplicativo possa obter acesso limitado a um serviço HTTP. Esta especificação substitui e torna
obsoleto o protocolo OAuth 1.05 (HARDT, 2012).
São quatro os papéis definidos pelo protocolo OAuth 2.0 (HARDT, 2012):
Proprietário do recurso: é uma entidade capaz de possibilitar o acesso a um recurso
protegido. Quando um proprietário de recursos é uma pessoa, é referido como um usuário final;
Servidor de recurso: é o servidor que hospeda os recursos protegidos, capaz de aceitar e
responder às solicitações de recursos protegidos usando tokens de acesso;
Cliente: é um aplicativo que realiza solicitações de recursos protegidos em nome do
proprietário dos recursos e com sua autorização; e
Servidor de autorização: é o servidor responsável por emitir tokens de acesso para o cliente
após autenticar com sucesso o proprietário de recursos e obter a autorização.
Youn (2011), apresenta uma visão simplificada do protocolo OAuth, na Figura 12.
5 O protocolo OAuth 1.0 esta descrito em: http://tools.ietf.org/html/rfc5849
46
Figura 12: Visão simplificada do protocolo OAuth
Fonte: Youn (2011)
A Figura 12 apresenta no passo zero (0) o registro do consumidor (cliente) com o servidor.
Tipicamente, o servidor vai emitir um ID de consumidor e uma chave secreta que o consumidor utiliza
para se autenticar (YOUN, 2011). Os outros passos são apresentados a seguir:
1. O usuário acessa um serviço de aplicação cliente;
2. O cliente faz uma requisição de compartilhamento com o usuário ao servidor, este responde
a operação com a URL para redirecionamento do usuário e URL para autenticação da
aplicação cliente e obtenção do token de acesso (Access Token);
3. O usuário é redirecionado ao servidor onde este solicita sua autorização para conceder o
acesso ao cliente. Note que para obter a permissão de acesso pelo cliente é necessário o
proprietário do recurso se autenticar em seu próprio domínio;
4. Com a permissão concedida o servidor envia o token de acesso para a aplicação cliente; e
5. O cliente utiliza o token de acesso para acessar os recursos em nome do usuário no servidor.
47
Segundo OpenID (2013) o OpenID Connect 1.06 é uma camada simples de identidade que
utiliza as capacidades do protocolo OAuth 2.0 para permitir que os clientes verifiquem a identidade do
usuário final baseado na autenticação realizada por um servidor de autorização, bem como obter
informações básicas sobre o perfil do usuário de forma interoperável. O OAuth 2.0 integrado ao
próprio protocolo do OpenID Connect 1.0 possibilita a definição de mecanismos opcionais para
assinatura e criptografia robusta dos dados de identidade dos usuários, a descoberta de Provedores de
OpenID e um gerenciamento mais avançado de sessão, realizando muitas tarefas do OpenID 2.0 porém
de uma forma mais amigável, e utilizável por aplicativos nativos e móveis (OPENID, 2013).
2.3.4 Protocolo de Autenticação Kerberos
Kerberos é um protocolo de autenticação de rede criado pelo Massachusetts Institute of
Technology (MIT) e utiliza criptografia de chave secreta para autenticar usuários no acesso a serviços
de rede. O protocolo nasceu de um projeto desenvolvido a partir de 1983 pelo MIT chamado Athena
com o foco de implementar estratégias e softwares para integração de computadores em rede.
O objetivo principal do protocolo é eliminar a transmissão de senhas pela rede e prover a
transmissão de dados criptografados entre o cliente e o servidor. A implementação livre deste
protocolo está disponível no MIT na versão Kerberos 5.0, porém outras implementações livres do
Kerberos como Heimdal7 e Shishi
8 estão disponíveis.
Segundo Neuman e Theodore (1994) o Kerberos é um serviço de autenticação distribuída que
permite que um processo (um cliente) rodando em nome de um principal (um usuário) para provar sua
identidade a um verificador (um servidor de aplicativos, ou simplesmente servidor), sem o envio de
dados através da rede.
Segundo Riccardi (2007) 9 o servidor de autenticação em um ambiente Kerberos, com base na
sua função de distribuição de tickets para acesso aos serviços, é chamado de KDC (Key Distribution
6 Disponível em: http://openid.net/connect/
7 Disponível em: http://www.h5l.org/
8 Disponível em: http://www.gnu.org/software/shishi/
9 Disponível em http://www.kerberos.org/software/tutorial.html
48
Centers – Centro de Distribuição de Chaves) e está dividido em três partes: Banco de Dados, Servidor
de Autenticação (AS) e Serviço de Concessão de Tíquetes (TGS).
AS (Authentication Service – Serviço de Autenticação), é responsável pela autenticação
do cliente, isto é, confirmar a identidade do cliente. Fornece um TGT (Ticket Granting
Ticket - Tíquete de Concessão) para o cliente acessar o TGS.
TGS (Ticket-Granting Service – Serviço de Concessão de Tíquetes), é responsável por
fornecer tíquetes aos clientes já autenticados no AS. Fornece Tickets para que o cliente
possa se comunicar nos servidores específicos.
Database (Base de dados), é responsável pelo armazenamento dos dados associados aos
clientes e serviços, chaves secretas e informações sobre os Tickets.
No funcionamento do Kerberos um servidor de aplicativos nunca se comunica diretamente com
o Centro de Distribuição de Chaves: os tickets de serviço, embora empacotados pela TGS, alcançam o
serviços somente através do cliente que deseja acessá-lo. Os pacotes trocados que vão entre o cliente e
o KDC e entre o cliente e o servidor de aplicativos durante a autenticação são descritos à seguir e
representados na Figura 13 (RICCARDI, 2007):
AS_REQ é a solicitação de autenticação inicial do usuário. Esta mensagem é dirigida
ao componente KDC conhecido como Servidor de Autenticação (AS)
AS_REP é a resposta do servidor de autenticação para o pedido anterior. Basicamente
ele contém o TGT para se comunicar com o TGS e a chave de sessão;
TGS_REQ é o pedido do cliente de um ticket de serviço para o servidor TGS. Este
pacote inclui o TGT obtido a partir da mensagem anterior e um autenticador gerado
pelo cliente e encriptado com a chave de sessão;
TGS_REP é a resposta do TGS para o pedido anterior. Esta é a permissão do serviço
solicitado pelo cliente;
AP_REQ é o pedido que o cliente envia para um servidor de aplicação para acessar um
serviço. Os componentes são os tickets de serviço obtidos TGS com a resposta anterior
49
e um autenticador novamente gerado pelo cliente, mas desta vez criptografada usando a
chave de sessão de serviço (gerada pelo TGS); e
AP_REP é a resposta que o servidor de aplicação dá ao cliente para provar que ele
realmente é o servidor que o cliente está esperando. Este pacote, nem sempre é
requerido. O cliente solicita ao servidor por ele somente quando a autenticação mútua é
necessária.
Figura 13: Troca de mensagens no Kerberos.
Fonte: Ricciardi (2007)10
10
Disponível em: http://www.kerberos.org/software/tutorial.html
50
Ricciardi (2007), apresenta as seguintes definições dos componentes realm, principal e ticket
como essenciais para a implementação do protocolo Kerberos:
Realm (reino): o termo reino indica um domínio administrativo de autenticação, sua intenção é
estabelecer os limites dentro dos quais um servidor de autenticação tem a autoridade para autenticar
um usuário, host ou serviço. Isso não significa que a autenticação entre um usuário e um serviço que
eles devem pertencer ao mesmo reino: se os dois objetos fazem parte de diferentes reinos e há uma
relação de confiança entre eles, a autenticação pode ocorrer. Esta característica, conhecida como Cross
Autenticazione (autenticação cruzada).
Principals: o termo principal é o nome usado para se referir as entradas no banco de dados do
servidor de autenticação, sendo associado a cada entidade, seja ela um usuário, host ou serviço de um
determinado domínio. Um exemplo simples de definir um usuário é o nome seguido de @ e o nome do
reino (nome @ REALM). No caso de um Principals associado a um serviço é utilizado o nome do
serviço seguido do nome completo do domínio da máquina no qual ele está instalado (serviço /
hostname @ REALM).
Ticket: é um conjunto de informações que um cliente apresenta para um servidor de aplicativos
para demonstrar a autenticidade da sua identidade. Os tickets são emitidos pelo servidor de
autenticação e são criptografados usando a chave secreta do serviço que se destinam. Uma vez que esta
chave é um segredo compartilhado apenas entre o servidor de autenticação e o servidor que presta o
serviço, nem mesmo o cliente que solicitou o ticket pode conhecê-lo ou alterar seu conteúdo. As
principais informações contidas em um ticket incluem:
Principal do usuário solicitante (geralmente o nome de usuário);
O diretor do serviço a que se destina;
O endereço IP do computador do cliente a partir do qual o ticket pode ser utilizado. No
Kerberos 5 este campo é opcional e pode também ser múltiplo, a fim de ser capaz de
executar os clientes sob NAT ou com hospedagem múltipla;
A data e a hora (em formato timestamp) quando a validade do ticket começa;
Duração máxima do ticket; e
51
A chave de sessão (cada ticket tem uma validade, isto é essencial, uma vez que o
servidor de autenticação não tem qualquer controle sobre o ticket já emitido).
Outra característica importante do Kerberos mencionada por Ricciardi (2007) é a Autenticação
Cruzada (Cross Autenticazione) que possibilita um usuário pertencer a um determinado domínio para
autenticar e acessar os serviços de outro reino. Esta característica conhecida como autenticação
transversal baseia-se na suposição de que há uma relação de confiança entre os domínios
envolvidos. Isso pode ser mono-direcional, o que significa que os usuários do domínio A pode acessar
os serviços do reino B, mas não vice-versa, ou bi-direcional, onde, o contrário também é possível
(RICCIARDI, 2007).
Neuman e Theodore (1994) apresentam algumas limitações, em particular o Kerberos não é
eficaz contra ataques de adivinhação de senha, se um usuário escolher uma senha fraca, então um
atacante pode adivinhar a senha e representar o usuário. Da mesma forma, Kerberos requer um
caminho confiável através do qual as senhas são digitadas. Se um usuário digitar uma senha em um
programa já modificado por um atacante como um cavalo de Tróia, o atacante poderá obter as
informações necessárias para representar o usuário. Cheswick, Bellovin e Rubin (2005) apresentam a
sincronização do tempo entre os relógios do cliente e do servidor, e a definição do tempo de validade
de um ticket, geralmente limitado a poucas horas, como limitações do Kerberos.
2.3.5 CAS
CAS (Central Authentication Service) é um sistema de autenticação originalmente criado pela
Universidade de Yale para fornecer de maneira confiável uma aplicação de código aberto para
autenticação de usuário, se tornando a partir de 2004 um projeto Jasig (JASIG, 2013).
Segundo Nogueira, Santos e Custódio (2012) o CAS permite a integração com um provedor de
autenticação, gerenciamento de políticas de segurança, autorização, considerações de disponibilidade e
liberação de atributos. O CAS possibilita ser configurado com outros modelos e mecanismos de
autenticação e autorização como o Active Directory, JDBC, RADIUS, LDAP, PAM, ACLs,
certificados digitais X.509, entre outros, desta forma o processo se torna mais seguro e amplo
(AUBRY, MATHIEU & MARCHAL, 2004).
52
No protocolo CAS, as credenciais e respostas são trocadas entre os envolvidos no processo por
meio de tickets via canal seguro (TLS/SSL). A Figura 14 representa o fluxo de troca de mensagens
realizada em uma aplicação web implementada utilizando o protocolo CAS (NOGUEIRA, SANTOS
& CUSTÓDIO, 2012).
Figura 14: Fluxo do protocolo CAS
Fonte: Adaptado de Nogueira, Santos e Custódio (2012)
1. O usuário acessa pela primeira vez um serviço web com suporte à autenticação CAS (ainda
não há nenhum serviço de ticket). Ele requisita sua autenticação e a aplicação web
redireciona o usuário para o servidor CAS;
2. O usuário insere suas credenciais de autenticação. As credenciais são verificadas em um
banco de dados externo e se estiverem corretas, o servidor CAS emite um Ticket Granting
Cookie para o navegador do usuário;
3. O servidor CAS entrega para a aplicação web um Service Ticket usável somente pelo serviço
que o requereu;
4. A aplicação web verifica Service Ticket e o envia ao servidor CAS; e
53
5. O Service Ticket é então validado e o recurso requerido pode ser entregue ao navegador do
usuário.
Os redirecionamentos são transparentes ao usuário, tendo o serviço de ticket como o passaporte
do navegador por meio do cliente CAS, com validade apenas para o cliente CAS que foi entregue, e
somente por um curto período de tempo.
2.3.6 OpenLDAP
O OpenLDAP possibilita o desenvolvimento de um provedor de identidades centralizado.
Dentre das funcionalidades do OpenLDAP, a considerada como principal destaque é a capacidade de
oferecer a autenticação de usuários usando sua base de dados (RIBEIRO JR., 2008).
“O OpenLDAP é um pacote do LDAP (Lightweight Directoty Access Protocol - Protocolo
Leve de Acesso a Diretório), adicionado de recursos e softwares necessários para torná-lo
funcional, que oferece um serviço de diretório prático e seguro. Este serviço é usado para
armazenar todos os dados da rede, como senhas, IDs de usuários, nomes, endereços, além de
outros, centralizando as pesquisas e consultas em si, esta centralização é a chave para abrir um
caminho que leva a praticidade na administração de uma rede de qualquer tamanho.”
(RIBEIRO JR., 2008).
Segundo Carrara e Trigo (2010), o OpenLDAP é uma implementação do protocolo LDAP,
desenvolvida pela Universidade de Michigam, sendo um software de código aberto e pode ser
executado em vários sistemas operacionais, dentre eles BSB, Solaris, Windows e distribuição Linux. O
LDAP trata-se, como o nome já diz, de um protocolo que rege a forma de acesso a serviços de
diretórios e respectivos clientes, oferecendo a integração com protocolos de comunicação como o
IPV4 e IPV6, e de transferência de arquivos como FTP e outros, além da integração do banco de
dados, chaves criptografadas, possuindo dentre outras capacidades o armazenamento de dados dos
usuários de forma prática e segura, inclusive logins e senhas (RIBEIRO JR., 2008).
Segundo Trigo (2007), as principais características do OpenLDAP são:
a. Suporte a IPv4 e IPv6;
b. Autenticação (Cryrus Sasl-Kerberos V, GSSAPI, Digst-MD5);
c. Controle de acessos;
d. Escolha entre banco de dados (LDBM e o BerkeleyDB);
54
e. Capacidade de atender a múltiplos bancos ao mesmo tempo (suporte para os
seguintes bancos de dados: IBMDb2, Mssql, MySQL, Oracle, PostgreSQL e
Timesten);
f. Alta performance em múltiplas chamadas; e
g. Replicação de base.
Ribeiro Jr. (2008) enfatiza que o OpenLDAP provê um conjunto de softwares que são
implementados junto ao LDAP para que o SLDAP (servidor LDAP, máquina onde o LDAP está
instalado) se torne funcional. O Cryrus Sasl-Kerberos V, GSSAPI, Digst-MD5, são softwares
responsáveis pela autenticação de usuários e permitem que todos os serviços de rede como FTP,
SAMBA, SQUID, APACHE, QMAIL, domínios Windows e domínios Linux autentiquem na base do
SLDAP. A suíte é composta pelos softwares:
Slapd – stand-alone LDAP daemon (servidor);
Slurpd – stand-alone LDAP update replication daemon;
Syncrepl – Replicação de base mais flexivel e tem mais recursos que o slurpd;
Bibliotecas de implementação do protocolo LDAP; e
Utilitários, ferramentas, e amostras clientes.
Segundo Maia (2005), o LDAP utiliza o conceito de diretórios hierárquicos para armazenar
suas informações e não é relacional, ou seja, no lugar de tabelas os dados são organizados em uma DIT
(Directory Information Tree – Árvore de Informação do Diretório), que é uma árvore onde cada
vértice é um registro. O objetivo principal da utilização de DIT é de facilitar a pesquisa e a
recuperação das informações e consiste em um repositório, uma espécie de banco de dados
especializado para armazenar informações ordenadas e de vários tipos, sobre objetos (TRIGO, 2007).
Trigo (2007) apresenta uma abordagem de árvore de diretório como um componente de
domínio na internet (dc – Domain Component), refletindo a estrutura do DNS. Desta forma os
primeiros níveis do diretório representam o nome de domínio da empresa, na mesma ordem de leitura
de um servidor DNS, conforme apresentado na Figura 15.
55
Figura 15: Estrutura no estilo DNS
Fonte: Trigo (2007).
Segundo Tuttle (2004 apud TRIGO, 2007), a vantagem do uso de diretórios é que eles são
acessados muito mais rapidamente, pois são armazenamentos de forma estática, ou seja, que
dificilmente são modificadas, seu algoritimo é otimizado e as informações são lidas de forma muito
mais rápida. Já o ponto fraco é a escrita, pois tem como base que as informações cadastradas
dificilmente serão alteradas. Como as informações de autenticação são raramente modificadas, esta
característica não se torna uma desvantagem tão espressiva para a implementação do sistema proposto.
Na autenticação centralizada um ponto crítico é a segurança, pois se um intruso descobrir um
login e senha terá acesso a tudo que for permitido ao usuário X, ressaltando que ele poderá fazer isto
de qualquer ponto da rede. Um dos recursos do OpenLDAP é seu vinculo com softwares de
criptografia, possibilitando um nível a mais de segurança. O OpenSSL quando integrado faz com que o
OpenLDAP transmita dados criptografados, onde chaves criptográficas e certificações digitais podem
ser configuradas pelo administrador do sistema. (RIBEIRO JR., 2008)
O SSL (Secure Sockets Layer) é um protocolo de nível de aplicativo que foi desenvolvido pela
Netscape Communications Corporation, com a finalidade de transmitir informações sensíveis, tais
como detalhes de cartão de crédito, através da internet. O SSL funciona utilizando uma chave privada
para criptografar dos dados transferidos por meio da conexão SSL-habilitada, tendo seu uso mais
popular na navegação via web utilizando o protocolo HTTP (Hipertext Transfer Protocol) (UBUNTU
COMMUNITY, 2012). A utilização do OpenSSL, como o OpenLDAP, por ser viável em
56
multiplataformas e já vir instalado em algumas distribuições Linux além de poder ser facilmente
encontrado em repositórios é uma solução interessante para o desenvolvimento do sistema proposto.
Além de uma política de segurança na transmissão de dados outros itens são expressamente
importantes para o funcionamento adequado de um provedor de identidades, como o controle de
acesso que o OpenLDAP prove através das ACLs (Access Control List – Listas de Controle de
Acesso), que deverão ser definidas pelo administrador do sistema. (RIBEIRO, 2008) e o RAID11
(Redundant Array of Independent Disks – Matriz Redundante de Discos Independentes) que é um
conjunto da HDs como uma única unidade de armazenamento de dados, independente da quantidade
de dispositivos que estiver em uso. Desta forma garante o funcionamento do sistema, pois se um disco
tiver falhas os outros continuam funcionando (ALECRIM, 2012).
Segundo Ribeiro Jr. (2008), o uso do OpenLDAP facilita o trabalho dos administradores de
redes na gestão dos serviços da mesma, facilitando a gerência de cadastros de usuários centralizados e
garantindo um acesso seguro aos provedores de serviços.
2.3.7 Outras Soluções
Existe uma diversidade de soluções abertas que suportam a autenticação SSO. Nesta seção é
apresentada uma breve descrição de outras soluções para implementação do SSO não apresentadas
anteriormente.
2.3.7.1 OpenAM
Segundo Nogueira, Santos e Custódio (2012) o OpenAM é uma ferramenta de código aberto
para gerenciamento de autenticação centralizada, autorização e serviços federados. Essa ferramenta
possui suporte para o uso de smartcards e certificados digitais, acesso a serviços, Fedlets e OAuth.
Além de suportar a autenticação federada com SAML, WS-Federation e Liberty ID-FF 1.x.
11 Disponível em: http://www.infowester.com/raid.php acessado em maio de 2012
57
O OpenAM fornece a segurança na integridade e confidencialidade de serviços web, através
das aplicações que suportam Liberty ID-WSF 1.x, WS-I Basic Security Profile. WS-Trust (STS) e
WS-Policy. Suportando também diversos módulos de autenticação, com Active Directory, certificados
digitais, HTTP, JDBC, LDAP, registro do próprio usuário, One Time Password, RADIUS, entre outros
(NOGUEIRA, SANTOS & CUSTÓDIUO, 2012).
O OpenAM é uma ferramenta completa e robusta, porém as dificuldades devido as inúmeras e
diferentes configurações possibilitam a brechas de segurança, desta forma a necessidade de um
administrador com experiência é imprescindível.
2.3.7.2 JOSSO
De acordo com o site do projeto12
, o JOSSO (Java Open Single Sign-On) é uma solução aberta
para implementação SSO baseada em padrões SAML, permitindo acesso seguro à internet para as
aplicações ou serviços de clientes, fornecedores e parceiros baseados na web (JOSSO, 2013)
Segundo Nogueira, Santos e Custódio (2012) por ser um framework, o JOSSO permite
implementar e combinar múltiplos esquemas de autenticação, fornecendo uma plataforma centralizada.
O JOSSO foi desenvolvido pela Atricore13
, não é uma ferramenta totalmente gratuita, possuindo
limitação de suporte, porém possui uma boa documentação.
O fornecimento do SSO na infraestrutura JOSSO é realizado por meio de um gateway, sendo o
mesmo responsável por agir como autoridade de gestão web para acesso SSO aos aplicativos
habilitados e seus usuários. Outro elemento é o Agente SSO, que manipula os casos de uso do SSO e
os detalhes de execução do ambiente de integração para aplicativos habilitados (NOGUEIRA,
SANTOS & CUSTÓDIUO, 2012).
12
Disponível em: www.josso.org 13
Disponível em: www.atricore.com
58
2.4 COMPARAÇÃO DAS SOLUÇÕES
A Tabela 2 compara as ferramentas estudadas em relação a algumas características essenciais
para a escolha da tecnologia ideal para o desenvolvimento da solução propostas. Essas características
são:
Característica 1 (Possibilita SSO): Informa se a ferramenta possibilita a autenticação Single
Sign-On (SSO);
Características 2 (Modelo IdP): Informa quais modelos de gerenciamento de identidade a
ferramenta suporta (tradicional, centralizado, federado ou centrado no usuário);
Característica 3 (Mecanismo de autenticação): Informa quais mecanismos de autenticação a
ferramenta suporta, ou de forma direta (estabelecido pela ferramenta) ou de forma indireta (utilizando
o mecanismo de outra aplicação em conjunto);
Característica 4 (Integração): Se a ferramenta permite a integração com outras tecnologias e
aplicações;
Característica 5 (Instalação): Dificuldade de instalação da ferramenta; e
Característica 6 (Segurança): Apresenta se a ferramenta possui algum problema de segurança
em seu desenvolvimento.
Tabela 2: Resumo de comparação das ferramentas estudadas
Ferramentas
Possibilita
SSO
Suporte para
Modelo de IdP
Mecanismos
Autenticação Integração Instalação Segurança
OpenID Sim Federado
Escolha do
provedor
Apache; C++,
Java, PHP, etc. Fácil Fraco
Oauth Sim Federado
Escolha do
provedor
Java, DotNet,
C#, PHP, etc. Fácil
Previsto e
com solução
CAS Sim Federado
JDBC, LDAP,
RADIUS, X.509,
RET API
Apache, Java,
PERL, PHP,
ASP, Shiboleth,
etc Fácil
Previsto e
com solução
OpenLDAP Sim Centralizado
Cryrus Sasl-
Kerberus V,
GSSAPI, Digst-
MD5
FTP, Apache,
SQUID,
SAMBA, outros. Moderado
Previsto e
com solução
Kerberos Sim
Centralizado,
Federado
O próprio
Kerberus é o
mecanismo OpenLDAP Moderado
Previsto e
com solução
SAML Sim
Centralizado,
Federado
O próprio SAML
é o mecanismo
OpenID, Oauth,
CAS, JOSSO,
OpenAM,
outros. Fácil
Previsto e
com solução
59
A comparação entre soluções pesquisadas direcionou a escolha da Especificação SAML 2.0,
por ser uma ferramenta que possibilita implementar o modelo de gerenciamento de identidades
centralizado, possui suporte para autenticação SSO e é de fácil instalação. Outra vantagem desta
ferramenta é a disponibilidade do Framework simpleSAMLPHP para a construção da autenticação
SSO, além de, possibilitar uma migração futura para o modelo de gestão de identidades federada.
2.5 E-PING
A arquitetura e-PING (Padrões de Interoperabilidade de Governo Eletrônico) define um conjunto
mínimo de premissas, políticas e especificações técnicas que regulamentam a utilização da Tecnologia
de Informação e Comunicação (TIC) no governo federal, estabelecendo as condições de interação com
os demais Poderes e esferas de governo e com a sociedade em geral (GOV.BR, 2013).
No Poder Executivo brasileiro a utilização dos padrões e políticas contidos no e-PING são
obrigatórias, no entanto, não podem ser impostas aos cidadãos e demais entes federativos, dentro e fora
do país. As entidades que desejam utilizar a arquitetura e-PING podem aderir de forma voluntária e
sem qualquer ingerência da Coordenação da e-PING (GOV.BR, 2013).
Entender claramente o que significa interoperabilidade é fundamental para conhecer os
objetivos da arquitetura e-PING. Os conceitos que fundamentaram o entendimento do governo
brasileiro a respeito do assunto são apresentados a seguir:
“Intercâmbio coerente de informações e serviços entre sistemas. Deve possibilitar a
substituição de qualquer componente ou produto usado nos pontos de interligação por outro de
especificação similar, sem comprometimento das funcionalidades do sistema”;
“Habilidade de transferir e utilizar informações de maneira uniforme e eficiente entre várias
organizações e sistemas de informação”;
“Habilidade de dois ou mais sistemas (computadores, meios de comunicação, redes, software e
outros componentes de tecnologia da informação) de interagir e de intercambiar dados de
acordo com um método definido, de forma a obter os resultados esperados”; e
60
“Interoperabilidade define se dois componentes de um sistema, desenvolvidos com ferramentas
diferentes, de fornecedores diferentes, podem ou não atuar em conjunto”.
Segundo GOV.BR (2013) a Interoperabilidade não é somente Integração de Sistemas, não é
somente Integração de Redes. Não referencia unicamente troca de dados entre sistemas. Não
contempla simplesmente definição de tecnologia. Na verdade, a interoperabilidade tem por meta a
consideração de todos os fatores para que os sistemas possam atuar cooperativamente, fixando as
normas, as políticas e os padrões necessários para consecução desses objetivos.
São cinco os segmentos cobertos pela e-PING: Interconexão, Segurança, Meios de Acesso,
Organização e Intercâmbio de Informações e Áreas de Integração para Governo Eletrônico. Os padrões
destes segmentos são organizados e definidos por grupos de trabalhos (GT) formados de especialistas
em cada assunto, a seguir segue a definição de cada um dos segmentos:
Interconexão: este segmento estabelece as condições para que os órgãos de governo se
interconectem, além de fixar as condições de interoperação entre o governo e a sociedade;
Segurança: este segmento trata dos aspectos de segurança de TIC (tecnologia da informação e
comunicação) que o governo federal deve considerar;
Meios de Acesso: são especificadas as questões relativas aos padrões dos dispositivos de
acesso aos serviços de governo eletrônico;
Organização e Intercâmbio de Informações: aborda os aspectos relativos ao tratamento e as
transferências de informações nos serviços de governo eletrônico; e
Áreas de Integração para Governo Eletrônico: estabelece a utilização ou construção de
especificações técnicas para sustentar o intercâmbio de informações em áreas transversais de
atuação governamental, cuja padronização seja relevante para a interoperabilidade de serviços
de governo eletrônico.
As principais especificações da arquitetura e-PING alinhadas a este trabalho é relacionado aos
componentes do Segmento de Segurança - Comunicação de Dados, que recomenda: a utilização do
TLS (Transport Layer Security) para a transferência de dados em redes inseguras, a utilização do RSA,
Diffie-Hellman RSA, Diffie-Hellman DSS, DHE_DSS, DHE_RSA como algoritmos de troca de
61
chaves de sessão durante o handshake e a utilização de algoritmos SHA para assintatura/hashing.
Ainda no segmento Segurança, porém na especificação para o Desenvolvimento de Sistemas, a e-
PING recomenda o componente SAML como ferramenta de autenticação e autorização de acesso
XML (GOV.BR, 2013).
2.6 CONSIDERAÇÕES
A fundamentação teórica apresentou inicialmente as diretrizes sobre a segurança da informação
visando definir os principais temas a serem abordados para o desenvolvimento do trabalho. Neste
ponto ficou definido pelo estudo dos modelos de gerenciamento de identidades existentes, além do
estudo das tecnologias existentes que fornecem serviços e mecanismos de segurança necessários para
prover a autenticação SSO.
Os conhecimentos adquiridos neste capítulo possibilitaram o desenvolvimento da visão geral
de um sistema de gestão de identidades, possibilitando selecionar o modelo adequado de gestão de
identidade, bem como escolher as tecnologias disponíveis para o desenvolvimento da solução.
62
3 TRABALHOS RELACIONADOS
3.1 COMUNIDADE ACADÊMICA FEDERADA (CAFE)
A Comunidade Acadêmica Federada (CAFe) é uma federação de identidade que reúne
instituições de ensino e pesquisa brasileiras. As instituições pertencentes à CAFe podem atuar como
provedoras de identidade (IdP) e como provedoras de serviço (SP). A relação de confiança entre
instituições participantes da Federação permite que o usuário se autentique unicamente em sua
instituição de origem, que fornece as garantias de autenticidade e credibilidade necessárias às demais
(RNP, 2013).
A CAFe funciona como uma infraestrutura de autenticação e autorização federada e é
constituída por dois elementos principais:
Provedores de identidades: são responsáveis pela manutenção das informações sobre usuários
e por sua autenticação; e
Provedores de serviços: são os provedores que oferecem acesso a um recurso ou serviço
específico.
Segundo a RNP (2013), o conceito básico de uma federação é a relação de confiança entre os
provedores de serviço e provedores de identidade. Outro aspecto da arquitetura da federação é o
gerenciamento de informações sobre os provedores de identidade e serviço através da manutenção dos
metadados. Segue as especificações técnicas da CAFe (RNP, 2013):
Protocolo: O protocolo utilizado pela Federação CAFe para a troca de informação entre os
membros é o SAML na versão 2.0.
Software: A Federação CAFe oferece suporte para o sistema Shibboleth, nas versões 2.x.
Outros softwares compatíveis com o protocolo indicado pela Federação podem ser utilizados.
Porém, não haverá suporte por parte da RNP.
Sistema Operacional: A Federação CAFe oferece suporte para o sistema operacional Linux na
distribuição Ubuntu 10.04 LTS. Outros sistemas operacionais podem ser utilizados. Porém, não
haverá suporte por parte da Rede Nacional de Ensino e Pesquisa (RNP).
63
Metadados: Os metadados da Federação CAFe são disponibilizados no formato SAML 2.0
Metadata.
Certificados: os certificados devem respeitar diversas restrições, entre elas o nome distinto no
common name, validade do certificado, algoritmo de assinatura digital e configurações da
chave definidos pela CAFe.
Atributos: Recomenda-se que os Provedores de Identidade sejam capazes de liberar os
seguintes atributos: cn: nome do usuário, Ssn: sobrenome do usuário, mail: endereço de e-mail
do usuário, eduPersonPrincipalName: identificador único do usuário na federação e
brEduAffiliationType: tipo de vínculo do usuário com a instituição.
De acordo com a RNP (2013), o principal benefício da CAFe é o conforto, já que o usuário não
precisa se cadastrar em diferentes sistemas, nem gerenciar senhas distintas. Além disso, o Single Sign-
On permite que a navegação em uma sessão de uso do browser não necessita de autenticação a cada
passo.
64
4 DESENVOLVIMENTO
Este capítulo apresenta uma análise dos principais sistemas da RedeCIM, uma visão geral do
sistema de gerenciamento de identidades proposto e a análise e o projeto do provedor de identidades
(IdP), identificando os requisitos funcionais e não funcionais, os diagramas e descrições detalhadas dos
casos de uso. Em seguida, os principais aspectos do desenvolvimento da solução proposta são
analisados. Por fim, os experimentos realizados para avaliação das funcionalidades do IdP são
descritos.
4.1 ANÁLISE DOS PRINCIPAIS SISTEMAS DA REDECIM
As informações sobre os principais sistemas integrados à RedeCIM foram coletadas junto à
equipe do centro de tecnologia da informação da FECAM.
A seguir, tem-se uma breve descrição dos principais sistemas:
1. Gerenciador de Portais Municipais (GPM): sistema gerenciador de conteúdos dos portais
municipais;
2. Gerenciador de Portais das Associações de Municípios (GAM): sistema gerenciador de
conteúdos dos portais institucionais das associações de municípios microrregionais;
3. Gerenciador do Portal da FECAM (GPFECAM): sistema gerenciador de conteúdos do portal
institucional da FECAM;
4. Gerenciador de Portais das Câmaras de Vereadores (PGCAMARA): sistema de gestão do
processo legislativo e gerenciamento do portal institucional das câmaras de vereadores;
5. Diário Oficial dos Municípios de Santa Catarina (DOM/SC): sistema de publicação de atos
oficiais;
6. Programa de Excelência na Gestão da Assistência Social (PEGASO): sistema de gestão dos
serviços prestados pela assistência social dos municípios;
7. Programa de Gestão do Simples Nacional (PGSimples): sistema de acompanhamento dos
dados das empresas integrantes do simples nacional, visando subsidiar a fiscalização tributária
dos municípios.
65
A Tabela 3 compara as principais características dos sistemas da RedeCIM. Estas
características, visam esclarecer alguns itens importantes que foram considerados no desenvolvimento
da solução proposta.
Tabela 3: Características dos principais sistemas da RedeCIM.
Item / Sistema GPM GAM GPFECAM PGCAMARA DOM/SC PEGASO PGSIMPLES
Perfis de
usuários
Administrador
e Usuário Colaborador
Administrador Administrador
Administrador e
Usuário Colaborador
Usuário
Colaborador
Administrador
e Usuário Colaborador
Administrador
e Usuário Colaborador
Atributos que
compõem
cadastro dos
usuários
Código do
município,
nome do
usuário, senha
e perfil
(ativo/inativo)
Código da associação de
município, nome
do usuário e senha
Nome do
usuário e senha
Código da câmara, nome da
pessoa, e-mail,
senha e perfil (ativo/inativo)
Código da
Instituição, Nome, E-mail,
Nome do
usuário, Senha e situação
(ativo/inativo)
Código do
município, nome do
usuário, CPF,
e-mail, senha e perfil.
(ativo/inativo)
Código do
município, nome do
usuário, CPF,
e-mail, senha e perfil.
(ativo/inativo)
Possibilita
cadastro de
múltiplos
usuários
Sim Não Não Sim Sim Sim Sim
A instituição
possui
autonomia na
gestão de
usuários
Não, os
usuários são
Cadastrados na FECAM
Não, os usuários
são cadastrados
no prestador (fornecedor)
Não, os
usuários são cadastrados no
prestador
(fornecedor)
Sim, o administrador é
cadastrado na
FECAM, com autonomia para
criação de
usuários colaboradores na
instituição.
Não, os usuários são Cadastrados
na FECAM
Sim, o administrador
é cadastrado na
FECAM, com autonomia para
criação de
usuários colaboradores
na instituição.
Sim, o administrador
é cadastrado na
FECAM, com autonomia para
criação de
usuários colaboradores
na instituição.
Permite a
alteração de
senha pelo
usuário
Não Não Não Sim Não Sim Sim
Número de
usuários ativos 795 20 1 36 611 23 67
Número de
Instituições
Utilizando
234 20
associações
1
(FECAM)
18
municípios
213
instituições
5
municípios
27
municípios
Forma de
indicação dos
usuários
Termo de
indicação do
Prefeito
Informal Informal
Termo de indicação do
prefeito para o
usuário administrador
Termo de indicação da
autoridade
responsável pela instituição
Termo de indicação do
prefeito para o
usuário administrador
Termo de
indicação do
Prefeito
Plataforma de
desenvolvimento
utilizada
PHP,
Framework de propriedade do
desenvolvedor
(A9XP)
PHP, Framework
de propriedade
do desenvolvedor (A9XP)
PHP,
Framework de propriedade do
desenvolvedor
(A9XP)
PHP, Framework zend +
DOCTRINE.
PHP, Framework
de propriedade do
desenvolvedor.
(A9XP)
PHP, Framework
zend
PHP, Framework
YII
Tipo de banco
de dados MySQL MySQL MySQL MySQL MySQL PostGree SQL MONGO DB
Protocolo de
Criptografia SSL SSL SSL SSL SSL SSL SSL
66
A análise dos sistemas integrados à RedeCIM demonstrou que os mesmos utilizam a
autenticação realizada no próprio provedor de serviços, ou seja, seguem o modelo tradicional de
gerenciamento de identidades. Em todos os sistemas, o mecanismo de autenticação segue o padrão de
login e senha, ou seja, nenhum dos sistemas utiliza um modelo mais robusto e seguro como um
modelo de autenticação de dois fatores que combina autenticação baseada em senha com autenticação
biométrica ou o modelo baseados em certificados digitais.
Ao analisar as principais características dos sistemas da RedeCIM, observou-se que existem os
atores administrador e usuário colaborador para praticamente todos os serviços, com exceção do
GAM e o GPFECAM, que possuem apenas o ator administrador e todos os usuários utilizam o
mesmo identificador e credencial para acessar o serviço. Observou-se também que apenas três dos sete
serviços analisados possibilitam a gerenciamento de novos usuários pelos administradores das
instituições, ou seja, quando é necessário criar uma nova senha a um colaborador, é preciso solicitar o
cadastro na FECAM encaminhando um termo assinado pelo representante legal da instituição,
atividade que burocratiza o processo de liberação de acesso aos serviços. Além disso, apenas três dos
serviços possibilitam a troca da credencial (senha) pelo usuário.
Outro ponto relevante é o grande número de usuários, totalizando 1.553 usuários, considerando
apenas os principais serviços analisados. Estes usuários estão distribuídos em mais de 500 instituições
do Estado, considerando prefeituras, câmaras de vereadores, empresas públicas municipais,
associações de municípios e a FECAM, característica que justifica a criação de um novo processo e
sistema de gestão de identidades.
Quanto às tecnologias utilizadas para o desenvolvimento dos sistemas integrados à RedeCIM,
todas são desenvolvidos para plataforma web e utilizam a linguagem de programação PHP, os bancos
de dados MySQL, PostGree SQL e Mongo SQL e o protocolo de criptografia SSL.
4.2 VISÃO GERAL E ESPECIFICAÇÕES TÉCNICAS
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
67
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.
68
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;
C) O Administrador IdP disponibiliza os seus metadados para o Administrador SP; e
69
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
10. Se autorizado, o SP disponibiliza os recursos ao usuário colaborador.
70
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
Disponível em: https://www.oasis-open.org/standards#samlv2.0
71
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.
4.3 ANÁLISE DE REQUISITOS
Esta seção apresenta os requisitos funcionais e não funcionais do IdP.
4.3.1 Requisitos Funcionais
Perfil de Administrador IdP
RF 01: O sistema deve permitir o gerenciamento de usuários com o perfil administrador IdP;
RF 02: O sistema deve permitir o cadastro de serviços para o estabelecimento da relação de
confiança;
RF 03: O sistema deve permitir o gerenciamento de usuários com o perfil administrador da
instituição;
72
RF 04: O sistema deve permitir a configuração do mecanismo de autenticação; e
RF 05: O sistema deve permitir a autenticação de usuários do perfil de administrador IdP.
Perfil de Administrador da Instituição
RF 06: O sistema deve permitir o gerenciamento de usuários com o perfil colaborador;
RF 07: O sistema deve permitir a alteração das informações cadastrais do seu usuário,
conforme permissões pré-definidas pelo Administrador IdP;
RF 08: O sistema deve possibilitar a alteração da senha pelo Administrador da Instituição; e
RF 09: O sistema deve permitir a autenticação de usuários do perfil administrador da
instituição.
Perfil de Colaborador
RF 10: O sistema deve permitir a alteração das informações cadastrais do seu usuário,
conforme permissões pré-definidas pelo Administrador IdP;
RF 11: O sistema deve possibilitar a alteração da senha pelo colaborador; e
RF 12: O sistema deve permitir a autenticação de usuários do perfil colaborador. Caso o
usuário já esteja autenticado no IdP, ou seja, está com uma sessão aberta devido a autenticação
solicitada por outro provedor de serviços do círculo de confiança, o mesmo não precisará se
autenticar novamente.
4.3.2 Requisitos Não Funcionais
RNF 01: O sistema deve ser desenvolvido em plataforma web;
RNF 02: O sistema deve ser desenvolvido utilizando o Zend Framework 2;
RNF 03: O sistema deve ser desenvolvido sobre uma estrutura de diretório LDAP;
Requisitos elencados tendo como base a arquitetura E-Ping:
73
RNF 04: O sistema deve ser desenvolvido utilizando a especificação SAML 2.0 como
ferramenta de autenticação e autorização de acesso XML;
RFN 05: O sistema deve utilizar o TLS (Transport Layer Security) para a transferência de
dados;
RFN 06: O sistema deve utilizar os algoritmos RSA, Diffie-Hellman RSA, Diffie-Hellman
DSS, DHE_DSS, DHE_RSA para a troca de chaves de sessão durante o handshake;
RNF 07: O sistema deve utilizar SHA1 como algoritmo para assinatura/hashing;
RNF 08: O sistema deve registrar os logs das autenticações de todos os usuários;
RNF 09: O sistema deve possibilitar a autenticação SSO; e
RNF 10: O sistema deve implementar a redundância do IdP, visando manter o serviço de
autenticação sempre disponível.
4.3.3 Regras do Negócio
RN 01: O sistema não deve permitir o acesso a usuários não autenticados;
RN 02: O sistema deve permitir somente acesso aos provedores de serviços do círculo de
confiança, devidamente cadastrados;
RN 03: A adesão dos provedores de serviços ao círculo de confiança do sistema deverá seguir
as regras pré-definidas pelo administrador do IdP;
RN 04: Os usuários administradores da instituição deverão ser indicados diretamente aos
Administradores IdP por meio de formulário assinado pelo responsável pela instituição.
74
4.4 MODELAGEM DO SISTEMA
4.4.1 Casos de Uso
O Diagrama de Casos de Uso contempla os casos de uso dos três tipos de atores que interagem
com o sistema, descritos na visão geral, são eles: o Administrador IdP, o Administrador da Instituição
e o Colaborador. A Figura 17 ilustra os Casos de Uso.
Figura 17: Casos de Uso do Administrador, Administrador de Instituição e Colaborador.
75
Nos quadros, a seguir são apresentados os casos de uso expandidos para cada perfil de usuário.
Quadro 1: Caso de uso Gerenciar Serviços expandido
Nome do caso de uso USC 01 Gerenciar Serviços
Breve descrição O Administrador IdP gerencia os serviços que fazem
parte do círculo de confiança do IdP, ou seja, é o
gerenciamento do cadastro dos provedores de serviços
que utilizarão o IdP como provedor de identidade dos
seus usuários.
Ator(es) Primário(s) Administrador IdP
Pré-condições O Administrador IdP deve estar autenticado no
sistema
Fluxo principal 1. O Administrador IdP acessa a tela com a listagem
dos serviços cadastrados;
2. O Administrador IdP seleciona a ação que será
executada (inserir novo serviço ou editar serviço);
Se a ação selecionada é inserir novo serviço:
a. O Administrador IdP clica em “Novo
Serviço”;
b. O sistema disponibiliza a tela com o
formulário para cadastro do serviço;
c. O Administrador IdP preenche o cadastro
com as informações e parâmetros do
serviço e salva.
3. Se a ação selecionada é editar serviço:
a. O Administrador IdP clica no botão
“Editar” do serviço relacionado;
b. O sistema disponibiliza a tela com o
cadastro do serviço;
c. O Administrador altera os dados
necessários e salva.
Fluxos alternativos e exceções Fluxo alternativo: Caso o Administrador IdP não
esteja autenticado o sistema deverá iniciar o caso de
uso Autenticar Usuários.
Pós-condições 1. Após o cadastro do serviço, deverão ser
encaminhados os parâmetros para configuração
do provedor de serviço e desta forma permitir a
troca de informações de autenticação entre as
partes.
2. Após a edição as alterações deverão estar salvas
na base de dados e o usuário deverá receber a
mensagem de alterações salvas com sucesso.
76
Quadro 2: Caso de uso Gerenciar Administrador da Instituição expandido
Nome do caso de uso USC 02 Gerenciar Administrador da Instituição
Breve descrição O Administrador IdP pode inserir, editar, e excluir
administradores das instituições.
Ator(es) Primário(s) Administrador IdP
Pré-condições O Administrador IdP deve estar autenticado no
sistema e ter recebido o termo de indicação do
administrador da instituição devidamente assinado
pela autoridade responsável.
Fluxo principal 1. O Administrador IdP acessa a tela com a
listagem de administradores das instituições
cadastrados;
2. O Administrador IdP seleciona a ação que será
executada
3. Se a ação selecionada é inserir Administrador
da Instituição:
a) O Administrador IdP clica em “Novo
Administrador da Instituição”;
b) O sistema disponibiliza a tela com o
formulário de cadastro de Administrador
da Instituição;
c) O Administrador IdP preenche o cadastro
com as informações do Administrador da
Instituição e salva.
4. Se a ação selecionada é editar Administrador
da Instituição:
a) O Administrador IdP clica no botão
“Editar” do Administrador da Instituição
relacionado,
b) O sistema disponibilizará a tela com o
cadastro do Administrador da Instituição.
c) O Administrador IdP altera os dados
necessários e salva.
5. Se a ação selecionada é excluir Administrador
da Instituição:
a) O Administrador IdP clica no botão
“Excluir” do Administrador da Instituição
relacionado;
b) O sistema disponibiliza a tela com o
cadastro do Administrador da Instituição;
c) O Administrador IdP desativa o
Administrador da Instituição desmarcando
o campo “Ativo” e salva a alteração.
Fluxos alternativos e exceções Fluxo alternativo: Caso o Administrador IdP não
esteja autenticado o sistema deverá iniciar o caso de
uso Autenticar Usuários.
77
Pós-condições 1. Após o cadastro do administrador da instituição
as informações (credenciais) de acesso ao
sistema, devem ser encaminhadas ao mesmo.
2. Após a edição as alterações deverão estar salvas
na base de dados e o usuário deverá receber a
mensagem de alterações salvas com sucesso.
Quadro 3: Caso de uso Configurar Mecanismo de Autenticação expandido
Nome do caso de uso USC 03 Configurar Mecanismo de Autenticação
Breve descrição O Administrador IdP pode definir o mecanismo de
autenticação dos usuários.
Ator(es) Primário(s) Administrador IdP
Pré-condições O Administrador IdP estar autenticado no sistema
Fluxo principal 1. O Administrador IdP acessa a tela de definição
de mecanismos e atributos;
2. O Administrador IdP configura o mecanismo e
atributos que desejar e salva.
Fluxos alternativos e exceções Fluxo alternativo: Caso o Administrador IdP não
esteja autenticado o sistema deverá iniciar o caso de
uso Autenticar Usuários.
Pós-condições Os mecanismos de autenticação configurados
Quadro 4: Caso de uso Gerenciar Colaboradores expandido
Nome do caso de uso USC 04 Gerenciar Colaboradores
Breve descrição O Administrador da Instituição pode inserir, editar, e
excluir colaborador.
Ator(es) Primário(s) Administrador da Instituição
Pré-condições O Administrador da Instituição deve estar autenticado
no sistema.
Fluxo principal 1. O Administrador da Instituição acessa a tela
com a listagem de colaboradores cadastrados;
2. O Administrador da Instituição seleciona a
ação que será executada;
3. Se a ação selecionada é inserir Colaborador:
a) O Administrador da Instituição clica em
“Novo Colaborador”;
b) O sistema disponibiliza a tela com o
formulário de cadastro de Colaborador;
c) O Administrador da Instituição preenche o
cadastro com as informações do
Colaborador e salva.
78
4. Se a ação selecionada é editar Colaborador:
a) O Administrador da Instituição clica no
botão “Editar” do Colaborador
relacionado,
b) O sistema disponibilizará a tela com o
cadastro do Colaborador.
c) O Administrador da Instituição altera os
dados necessários e salva.
5. Se a ação selecionada é excluir Colaborador:
a) O Administrador da Instituição clica no
botão “Excluir” do Colaborador
relacionado;
b) O sistema disponibiliza a tela com o
cadastro do Colaborador;
c) O Administrador da Instituição desativa o
Colaborador desmarcando o campo
“Ativo” e salva a alteração.
Fluxos alternativos e exceções Fluxo alternativo: Caso o Administrador da
Instituição não esteja autenticado o sistema deverá
iniciar o caso de uso Autenticar Usuários.
Pós-condições 1. Após o cadastro do colaborador as informações
(credenciais) de acesso ao sistema, devem ser
encaminhadas ao mesmo.
2. Após a edição as alterações deverão estar salvas
na base de dados e o usuário deverá receber a
mensagem de alterações salvas com sucesso.
Quadro 5: Caso de uso Autenticar Usuários expandido
Nome do caso de uso USC 05 Autenticar Usuários
Breve descrição Os usuários de qualquer perfil utiliza o provedor de
identidade para se autenticar. Esta autenticação poderá
ser realizada diretamente no Provedor IdP para a
solicitação de algum recurso do próprio sistema, ou
por meio do redirecionamento de algum provedor de
serviço integrado ao círculo de confiança.
Ator(es) Primário(s) Administrador IdP, Administrador da Instituição e o
Colaborador.
Pré-condições O usuário estar com seu cadastrado ativo no IdP e
possuir suas credenciais para a autenticação
Fluxo principal 1. O usuário acessa a tela de login no sistema,
preenche com suas credenciais, e clica no
botão “Entrar”.
2. O sistema valida o usuário comparando com a
base de usuários ativos.
79
3. O sistema verifica se o usuário possui
permissão à aplicação relacionada.
4. Se o usuário está valido e possui o acesso à
aplicação relacionada o sistema autentica o
usuário.
5. Se o usuário não está valido ou não possui
permissão de acesso à aplicação o sistema não
autentica o usuário.
Fluxos alternativos e exceções 1. Caso o usuário não possua acesso à aplicação,
o sistema deve retornar a mensagem de
usuário não valido;
2. Caso o usuário não esta ativo na base do
provedor IdP, o sistema deve retornar a
mensagem de usuário inexistente;
3. Se o usuário não se lembrar das suas
credenciais, o mesmo pode solicitar as
credenciais clicando em “esqueci minha
senha”. O sistema encaminha as novas
credenciais para o e-mail cadastrado nos
atributos do usuário relacionado.
Pós-condições O usuário deverá estar autenticado no sistema ou ter
recebido por e-mail a nova senha.
Quadro 6: Caso de uso Atualizar Cadastro expandido
Nome do caso de uso USC 06 Atualizar cadastro
Breve descrição Os usuários de qualquer perfil utiliza o provedor de
identidade para atualizar os atributos permitidos em
seu cadastro.
Ator(es) Primário(s) Administrador IdP, Administrador da Instituição e o
Colaborador.
Pré-condições O usuário estar autenticado no sistema.
Fluxo principal 1. O usuário acessa o formulário com suas
informações cadastrais.
2. O usuário altera as informações permitidas que
desejar e salva. Fluxos alternativos e exceções 1. Se o usuário desejar alterar uma informação
não permitida, o mesmo deverá entrar em
contato com o Administrador IdP.
2. Caso o usuário não esteja autenticado o
sistema redireciona o mesmo para realizar a
autenticação.
Pós-condições O cadastro do usuário estará atualizado e apresentada
a mensagem de cadastro realizado com sucesso.
80
4.4.2 Estrutura de Diretório LDAP
O sistema foi construído utilizando a estrutura de diretório LDAP (lightweight Directory
Access Protocol) para armazenamento dos dados dos usuários e serviços. A Figura 18 apresenta a
estrutura de diretórios do sistema.
Figura 18: Estrutura de diretório LDAP
A raiz da estrutura LDAP está definida como dc=fecam, dc=org, dc=br, que representa
componente de domínio de internet (dc - Domain Component) refletindo a estrutura DNS. A
organização está definida como o=fecam.org.br. As unidades organizacionais foram definas como
ou=pessoa, ou=serviços e ou=município.
A unidade organizacional ou=pessoa contêm usuários em sua estrutura com uid=CPF. Desta
forma, o DN (dominiam name) do usuário, identificado nesta estrutura pelo atributo uid, está
representado por uid=CPF, ou=pessoa, o=fecam.org.br, dc=fecam, dc=org, dc=br. Já a unidade
organizacional ou=serviço contêm serviços em sua estrutura com cn=nomeServiço. O DN do serviço,
nesta estrutura, identificado pelo atributo cn, está representado por cn=nomeServiço, ou=serviços,
o=fecam.org.br, dc=fecam, dc=org, dc=br. Por fim, a unidade organizacional ou=município contêm
81
municípios em sua estrutura com cn=nomeMunicipio. Seu DN nesta estrutura é identificado pelo
atributo cn e está representado por cn=nomeMunicipio, ou=municipio, dc=fecam, dc=org, dc=br.
O usuário está vinculado ao seu município e aos serviços pela identificação do seu DN
(uid=CPF, ou=pessoa, o=fecam.org.br, dc=fecam,dc=org,dc=br) no campo member, tanto do
cn=nomeMunicipio, quanto do cn=nomeServiço.
4.5 DETALHAMENTO DO DESENVOLVIMENTO
Na escolha das ferramentas e tecnologias utilizadas para o desenvolvimento do provedor de
identidades, foram priorizadas soluções de software livre, conforme recomendado pelo Comitê de
Executivo do Governo Eletrônico Brasileiro. No desenvolvimento do sistema, foi escolhida a
linguagem PHP utilizando o Zend Framework 2, por esta ferramenta possuir uma ampla biblioteca de
comunicação com o LDAP. Por se tratar de uma aplicação de internet rica (RIA - Rich Internet
Application) foi utilizado o Framework Javascript jQuery, ferramenta escolhida por ser amplamente
utilizada para o desenvolvimento desta função na FECAM. Para prover a troca de informações de
autenticação e autorização com a especificação SAML 2.0 e a construção do ambiente autenticação
Single Sing-On foi utilizada a ferramenta simpleSAMLPHP.
Como protocolo de segurança na transferência de dados foi utilizado o TLS 1.2 (Transport
Layer Security). A conexão é criptografada utilizado AES_256_CBC, com SHA1 para mensagem de
autenticação e DHE_RSA como mecanismo de troca de chaves. O certificado é emitido por StarCom16
por ser um certificado de classe 1 gratuita e compatível com os principais sistemas operacionais e
navegadores disponíveis no mercado. Entretanto para utilizar o IdP como provedor de identidade na
FECAM será necessário adquirir um certificado mais confiável.
A hospedagem dos sistemas estão em dois servidores com sistema operacional linux, com
servidor web Apache 2 e PHP 5. Para preparar este ambiente foram executados os seguintes passos:
16
Certificado disponível em: http://www.startssl.com/?app=1
82
1. Instalação do apache com as bibliotecas PHP;
2. Geração dos certificados e posterior assinatura pela CA (StarCom);
3. Instalação do LDAP (pacote slapd); e
4. Configuração dos virtual hosts do Apache para aceitar múltiplos domínios e certificados
no mesmo IP.
A base de dados utiliza estrutura de diretórios LDAP com a gerencia realizada através do
Apache Directory Studio 2.0, conforme apresentado na Figura 19.
Figura 19: Tela da estrutura de diretórios LDAP configurada no Apache Directory Estudio.
O primeiro passo para a implementação do Provedor de Identidade (IdP) no simpleSAMLPHP
foi a configuração da fonte de autenticação no /config/authsources.php para utilização o LDAP,
conforme apresenta a Figura 20.
83
Figura 20: Configuração da fonte de autenticação.
Após configuração da fonte de autenticação, ela foi habilitada como autenticação padrão do IdP
no arquivo de metadados conforme as especificações técnicas. A Figura 21 apresenta o metadado do
IdP salm20-idp-hosted.php.
Figura 21: Metadado do IdP salm20-idp-hosted.php
84
Por fim, gerou-se os metadados do IdP para serem distribuídos aos SPs afim de estabelecer o
círculo de confiança. A Figura 22 apresenta os metadados fornecidos do IdP.
Figura 22: Metadados fornecidos pelo IdP
O Sistema de Gerenciamento de Identidades está implementado conforme definido nos casos
de uso, com exceção do caso de uso USC 03 Configurar Mecanismo de Autenticação, que após a
reavaliá-lo, verificou-se que os serviços cadastrados no IdP que farão parte do círculo de confiança
devem seguir o mecanismo pré-definidos para autenticação. Além disto, foi fixado os atributos nome
do usuário (CPF) e senha para realização do login.
Para avaliar a aplicabilidade do IdP, foi desenvolvido um protótipo de SP e configurado com os
metadados do IdP. Após a configuração do SP com os metadados, gerou-se os metadados do SP, afim
de disponibilizá-los para o cadastro do serviço no círculo de confiança do IdP. O código gerado com os
metadados do protótipo SP (http://sistema1.levelplus.com.br) está disponível no Apêndice 1.
Maiores detalhes sobre a sintaxe dos metadados, atributos e afirmações trocadas através de
mensagens SAML 2.0 estão mais detalhadas na especificação OASIS17
do SAML 2.0 Metadata
Exchange. As funcionalidades do IdP estão mais detalhadas na Seção 5.1.1, na descrição dos casos de
teste.
17
Disponível em: http://docs.oasis-open.org/security/saml/v2.0/saml-metadata-2.0-os.pdf
85
O requisito não funcional RNF 10 que indica que o sistema deve implementar a redundância do
IdP, não foi desenvolvido, devido a sua complexidade utilizando o simpleSAMLPHP. Entretanto com
a utilização do SAML para o desenvolvimento o IdP é possível disponibilizar a redundância do
sistema utilizando a Ferramenta OpenAM, apresentada na Seção 2.3.7.
4.6 DESCRIÇÃO DO PROJETO DE EXPERIMENTOS
Nesta seção, são descritos os dois experimentos realizados para avaliar o sistema desenvolvido,
de forma a responder as questões de pesquisa apresentadas no Capítulo 1. O primeiro relacionado à
aplicação dos casos de testes e o segundo uma pesquisa de satisfação aplicada aos usuários da
RedeCIM dos diferentes perfis.
No primeiro experimento, o protótipo implementado passou por testes funcionais e testes não
funcionais nos níveis de sistema e de integração. Para primeira etapa, foram definidos quinze casos de
testes e executados pelo próprio aluno. Dentre os aspectos que foram avaliados, as funcionalidades no
atendimento dos casos de uso e o atendimento aos requisitos não funcionais e regras de negócio
definidas.
Para o segundo experimento, uma pesquisa de satisfação foi elaborada. Experimentos foram
realizados por técnicos da FECAM, do CIGA e das associações de municípios que atuam nas funções
de gerenciamento de usuários dos sistemas da RedeCIM. Foram elaborados três roteiros (ver Apêndice
3) para que os profissionais soubessem os objetivos do IdP e as funcionalidades que estes deveriam
testar e avaliar no sistema, porém, nenhuma informação detalhada de como o sistema foi desenvolvido
foi passada. Vale ressaltar que a diferença entre cada um dos roteiros elaborados são questões
direcionadas conforme o perfil de acesso dos avaliadores do sistema desenvolvido. Em seguida, os
avaliadores responderam a uma pesquisa de satisfação.
A pesquisa de satisfação teve como objetivos:
1. Identificar o perfil dos avaliadores em relação a sua experiência e área de atuação como
usuário dos sistemas da RedeCIM;
2. Identificar o conhecimento dos avaliadores em relação aos conceitos de gestão de
identidades (autenticação SSO, provedores de identidades, autenticação centralizada e
autenticação federada);
86
3. Identificar qual sistema operacional e navegador os avaliadores usaram no teste;
4. Identificar se os avaliadores conseguiram executar todo o experimento conforme descrito no
roteiro e quais problemas ocorreram;
5. Verificar se foi necessário cancelar a execução de algum serviço durante o experimento e se
as mensagens de erros (caso tenham ocorrido) foram suficientes para resolver o problema;
6. Verificar se as informações apresentadas no protótipo estavam legíveis e de fácil
compreensão;
7. Verificar a satisfação dos avaliadores em relação ao tempo de resposta das operações
realizadas no IdP;
8. Verificar se os avaliadores, em algum momento, não souberam o que fazer e se os mesmos
tiveram dificuldades para entender as funções do IdP;
9. Verificar se os avaliadores acham que o uso do IdP trará mais rapidez, flexibilidade e
segurança para os serviços da RedeCIM;
10. Identificar se os avaliadores gostariam de utilizar o IdP para o gerenciamento de
identidades e a autenticação de usuários dos serviços disponibilizados pela FECAM e
CIGA;
11. Identificar o que os avaliadores avaliaram de melhor na execução do experimento; e
12. Identificar o que pode ser melhorado no IdP para satisfazer os usuários.
87
5 RESULTADOS E ANÁLISES
Neste capítulo, são apresentados os resultados obtidos na fase de avaliação do Provedor de
Identidade (IdP).
5.1 RESULTADOS OBTIDOS
Esta seção apresenta os resultados obtidos na execução dos experimentos, contemplando a
aplicação dos casos de teste e os resultados das pesquisas de satisfação aplicadas aos diferentes perfis
de usuários.
5.1.1 Resultados do Primeiro Experimento: Casos de Teste
Esta seção, apresenta os resultados da aplicação de quatorze (14) casos de testes que avaliam as
funcionalidades conforme descritos nos casos de uso, nos requisitos funcionais e não funcionais, além
de avaliar se o IdP está de acordo com as regras de negócio definidas. As telas apresentadas durante a
aplicação dos casos de teste estão disponíveis no Apêndice 2.
O detalhamento dos casos de teste definidos para testar o Caso de Uso USC 01, Gerenciar
serviços, são apresentados nos Quadros 7 e 8.
Quadro 7: Caso de Teste CT 01 - Cadastro de serviços
Número do teste: CT01 Nível de teste: Integração
Descrição (passos) Após realizar a autenticação com o perfil
administrador IdP, acessar a área administrativa e
inserir um novo serviço.
Pré-condições Usuário autenticado, perfil administrador IdP.
Entrada de dados Dados do serviço: nome do serviço, URL do serviço e
os metadados do serviço.
Resultados esperados O cadastro deve ser realizado e a listagem dos
serviços deve ser apresentada.
Execução do teste: Em um computador pessoal, com acesso à Internet e um navegador Web
instalado, foi acessado o endereço https://idp.levelplus.com.br. Ao acessar o endereço do IdP, o
navegador Web do usuário foi redirecionado para a tela de autenticação do IdP.
88
Após o usuário entrar com os dados de acesso (CPF e senha) e a autenticação ser realizada com
sucesso, o IdP redirecionou o navegador Web para a tela inicial da área administrativa do IdP. Para
cadastrar um novo serviço, o usuário selecionou a opção "Cadastro" da aba "Serviços", o sistema
apresentou a tela do formulário de cadastro de serviços. Os campos Nome, URL e Metadata foram
preenchidos e o serviço foi salvo clicando no botão "Salvar". (O metadado para o teste está disponível
no endereço: http://sistema2.levelplus.com.br/metadados). Para finalizar o processo de cadastro do
serviço, clicou-se no botão "Recarregar metadados IdP" para atualização do IdP. Ao finalizar o
cadastro do serviço, a tela informando que os Metadados do serviço foram recarregados com sucesso
foi apresentada.
Resultado do teste: O serviço está cadastrado e disponível para autenticação dos usuários
vinculados no IdP.
Quadro 8: Detalhamentos do caso de teste CT 02 - Alteração de dados do serviço
Número do teste: CT02 Nível de teste: Sistema
Descrição (passos) Após realizar a autenticação com o perfil
administrador IdP, acessar a área administrativa e
alterar o nome do serviço, a URL e o metadado do
serviço.
Pré-condições Usuário autenticado, perfil administrador IdP .
Entrada de dados Dados do serviço: novo nome, nova URL e o novo
metadado do serviço.
Resultados esperados Deve ser apresentada uma mensagem de confirmação
e a listagem deve ser atualizada e apresentada.
Execução do teste: Após executar os passos de autenticação descritos no CT 01, o usuário
perfil Administrador IdP iniciou o processo de alteração de serviço ao clicar no submenu "Lista" da
aba "Serviços", o sistema apresentou a listagem dos serviços cadastrados. Após acessar a lista de
serviços o usuário acessou os dados do serviço "Gerenciador Portal de Turismo" clicando no ícone
"Editar" e alterou os campos nome, URL e o Metadados e salvou as alterações clicando no botão
"Salvar". Ao finalizar a alteração dos dados do serviço foi apresentada tela de confirmação de
alteração do serviço.
Resultado do teste: O teste foi realizado com sucesso, as alterações no serviços foram
realizadas e a mensagem de confirmação foi apresentada.
89
O detalhamento dos casos de teste definidos para testar o Caso de Uso USC 02, Gerenciar
Administrador da Instituição, são apresentados nos Quadros 9 e 10.
Quadro 9: Detalhamentos do caso de teste CT 03 - Cadastro de Administrador da Instituição
Número do teste: CT03 Nível de teste: Sistema
Descrição (passos) Após realizar a autenticação com o perfil
administrador IdP, acessar a área administrativa e
inserir um novo administrador da instituição.
Pré-condições Usuário autenticado, perfil administrador IdP.
Entrada de dados Dados do administrador da instituição: nome,
sobrenome, e-mail, CPF, telefone, órgão, município e
os serviços vinculados ao usuário.
Resultados esperados O cadastro deve ser realizado e a listagem dos
usuários cadastrados deve ser apresentada.
Execução do teste: Após executar os passos de autenticação descritos no CT 01, o testador
(perfil Administrador IdP) iniciou o processo de cadastro de usuários do perfil Administrador da
Instituição ao clicar no submenu "Novo Adm de Instituição" da aba "Pessoas". A tela com o
formulário de cadastro de administrador da instituição foi apresentada, o testador cadastrou os dados
no formulário e finalizou o cadastro clicando no botão "Salvar". Após o cadastro, foi apresentada a tela
de confirmação do cadastro e a listagem dos usuários cadastrados.
Resultado do teste: O cadastro do usuário administrador da instituição foi realizado com
sucesso, a mensagem de confirmação e a listagem com os usuários cadastrados foram apresentadas.
Quadro 10: Detalhamentos do caso de teste CT 04 - Alteração dos dados do Administrador da
Instituição
Número do teste: CT04 Nível de teste: Sistema
Descrição (passos) Após realizar a autenticação com o perfil
administrador IdP, acessar a área administrativa e
alterar os dados do administrador da instituição
desejado.
Pré-condições Usuário autenticado, perfil administrador IdP .
Entrada de dados Dados do administrador da instituição: telefone, órgão
e ou serviço vinculado.
Resultados esperados Deve ser apresentada uma mensagem de confirmação
e a listagem deve ser atualizada e apresentada.
90
Execução do teste: Após se autenticar no IdP conforme descrito no CT 01, o testador (perfil
Administrador IdP) executou o processo de alteração do cadastro de um usuário do perfil
Administrador da Instituição clicando no ícone "Editar" do usuário desejado. O sistema exibiu o
formulário com os dados do usuário. O testador alterou os dados desejados e clicou no botão "Salvar".
Após salvar as alterações, foi apresentada a tela de confirmação.
Resultado do teste: Os dados do administrador da instituição foram alterados com sucesso, a
mensagem de confirmação e a listagem atualizada de usuários cadastrados foram apresentadas.
O detalhamento dos casos de teste definidos para testar o Caso de Uso USC 04, Gerenciar
Colaboradores, são apresentados nos Quadros 11, 12 e 13.
Quadro 11: Detalhamentos do caso de teste CT 05 - Cadastro de Colaborador
Número do teste: CT05 Nível de teste: Sistema
Descrição (passos) Após realizar a autenticação com o perfil
administrador da instituição, acessar a área
administrativa e inserir um novo colaborador.
Pré-condições Usuário autenticado, perfil administrador da
instituição.
Entrada de dados Dados do colaborador: nome, sobrenome, e-mail,
CPF, telefone, órgão e os serviços vinculados ao
usuário.
Resultados esperados O cadastro deve ser realizado e a listagem dos
serviços deve ser apresentada.
Execução do teste: Após a autenticação, a tela inicial do IdP no perfil Administrador da
Instituição foi apresentada. O testador iniciou o processo de cadastro de usuários do perfil Colaborador
ao clicar no submenu "Novo Colaborador" da aba "Pessoas". A tela com o formulário de cadastro de
colaborador foi apresentada, o testador cadastrou os dados no formulário e finalizou o cadastro
clicando no botão "Salvar". Após o cadastro realizado, foram apresentadas na tela a confirmação do
cadastro e a listagem dos usuários cadastrados nesta instituição.
Resultado do teste: O cadastro do usuário colaborador foi realizado com sucesso, a mensagem
de confirmação e a listagem com os usuários cadastrados foram apresentadas.
91
Quadro 12: Detalhamentos do caso de teste CT 06 - Alteração dos dados do Colaborador pelo
Administrador da Instituição
Número do teste: CT06 Nível de teste: Sistema
Descrição (passos) Após realizar a autenticação com o perfil
administrador da instituição, acessar a área
administrativa e alterar os dados do colaborador
desejado.
Pré-condições Usuário autenticado, perfil administrador da
instituição.
Entrada de dados Dados do colaborador: telefone, órgão e ou serviço
vinculado.
Resultados esperados Deve ser apresentada uma mensagem de confirmação
e a listagem deve ser atualizada e apresentada.
Execução do teste: Após a autenticação, o testador (perfil Administrador da Instituição)
acessou a listagem de colaboradores cadastrados clicando no submenu "Lista" da aba "Pessoas". A
listagem com os colaboradores cadastrados da instituição foi apresentada. O testador executou o
processo de alteração do cadastro de um usuário do perfil Colaborador, clicando no ícone "Editar" do
usuário desejado. O sistema exibiu o formulário com os dados do usuário e o testador alterou os dados
desejados e os salvou. Após salvar as alterações, foi apresentada a tela de confirmação.
Resultado do teste: Os dados do colaborador foram alterados com sucesso, a mensagem de
confirmação e a listagem atualizada de usuários cadastrados foram apresentadas.
Quadro 13: Detalhamentos do caso de teste CT 07 - Desativar usuário colaborador
Número do teste: CT07 Nível de teste: Sistema
Descrição (passos) Após executar corretamente os CT 08. O usuário
Administrador da Instituição deve desativar o usuário
colaborador, desvinculando-o dos serviços e
posteriormente acessar o serviço: Gerenciador do
Portal do Municípios (http:sitema1.levelplus.com.br)
com as credenciais do Colaborador desativado.
Pré-condições Administrador da Instituição autenticado no IdP
Entrada de dados Credenciais do usuário: CPF e senha.
Resultados esperados O usuário deve conseguir se autenticar no IdP, porém
não terá mais acesso ao serviço que foi desvinculado.
e uma mensagem que usuário não tem acesso ao
serviço. .
92
Execução do teste: Após se autenticar no IdP , o testador (perfil Administrador da Instituição)
acessou a listagem de serviços vinculados a sua instituição clicando no submenu "Serviços do
Municípios" da aba "Serviços". A tela da listagem com os serviços vinculados ao município foi
apresentada. O usuário acessou a tela de gerenciamento dos usuários do serviço Gerenciador do Portal
Municipal, clicando no botão "Gerenciar" do referido serviço e desvinculou o usuário colaborador
(José - CPF: 64151871551) clicando na opção remover do referido usuário. O usuário foi desvinculado
do serviço. Para verificar se o usuário foi realmente desvinculado do serviço, o testador se autenticou
no IdP com as credenciais do usuário (José - CPF: 64151871551) e acessou o serviço Gerenciador do
Portal do Municípios (http:sitema1.levelplus.com.br). O IdP retornou a mensagem que o colaborador
não é usuário deste serviço.
Resultado do teste: O testador (perfil administrador da instituição) desvinculou o colaborador
do serviço com sucesso e o testador conseguiu se autenticar no IdP, porém, não foi liberado o acesso
ao serviço, pois o colaborador não está mais vinculado ao mesmo.
O Quadro 14 apresenta o detalhamento do caso de teste CT 07, que testa a obrigatoriedade de
alteração da senha do usuário no primeiro acesso no IdP.
Quadro 14: Detalhamentos do caso de teste CT 08 - Alteração de senha obrigatória no primeiro acesso
Número do teste: CT08 Nível de teste: Sistema
Descrição (passos) Após a execução do CT 06, realizar a autenticação do
usuário do perfil colaborador cadastrado. O IdP deve
solicitar a alteração da senha no primeiro acesso e
disponibilizar a tela de login novamente para o
colaborador se autenticar no IdP.
Após a autenticação o colaborador deve acessar um
serviço vinculado disponível em
http://sistema1.levelplus.com.br
Pré-condições Usuário colaborador cadastrado e ativo no IdP.
Entrada de dados Credenciais dos usuários: CPF e senha inicial.
Resultados esperados O usuário deve ser forçado a alterar sua senha, se
autenticar no IdP e acessar o serviço vinculado
Execução do teste: O usuário do perfil colaborador cadastrado no CT 06 acessou o IdP no
endereço https://idp.levelplus.com.br para se autenticar, ao entrar com as credenciais e clicar no botão
"Acessar", o IdP forçou a alteração da senha por ser o primeiro acesso deste usuário. Após a troca de
senha, o IdP exigiu que o testador realizasse a autenticação novamente.Após autenticação bem
93
sucedida, o IdP redirecionou o navegador web para a tela inicial do usuário com o perfil colaborador.
Em seguida, o testador acessou o protótipo do serviço Gerenciador Portal Municipal digitando a URL
http://sistema1.levelplus.com.br no navegador. O IdP verificou que o usuário já estava autenticado e
direcionou o navegador web para a página inicial do serviço, disponibilizando o acesso ao usuário.
Resultado do teste: O colaborador alterou sua senha no primeiro acesso, se autenticou no IdP e
o acesso ao serviço foi liberado ao usuário.
O Quadro 15 apresenta o detalhamento do caso de teste CT 09, que testa se o requisito
funcional RF 10, que define que o colaborador deve conseguir alterar suas informações cadastrais no
IdP, está funcionando.
Quadro 15: Detalhamentos do caso de teste CT 09 - Alteração dos dados pelo colaborador
Número do teste: CT09 Nível de teste: Sistema
Descrição Após realizar a autenticação, o usuário do perfil
colaborador deve alterar seus dados no sistema.
Pré-condições O usuário do perfil colaborador estar autenticado no
IdP
Entrada de dados Dados do usuário: telefone, órgão e nova senha.
Resultados esperados Dever ser apresentada a tela de confirmação e os
dados estarem alterados no sistema
Execução do teste: Após se autenticar no IdP , o usuário do perfil colaborador alterou seus
dados e salvou as alterações. O IdP exibiu a mensagem que os dados foram atualizados com sucesso.
Após as alterações o colaborador acessou a tela de alteração de senha, clicando no submenu "Alteração
de Senha" da aba "Pessoas". O IdP direcionou o navegador web para a tela de alteração de senha.
Resultado do teste: O usuário colaborador alterou seus dados no IdP com sucesso, a
mensagem de confirmação foi apresentada.
O Quadro 16 apresenta o detalhamento do Caso de Teste CT 10, que testa se o IdP possibilita a
autenticação Single Sing-On (SSO), conforme definido pelo requisito não funcional RNF 09.
94
Quadro 16: Detalhamentos do caso de teste CT 10 - Teste de autenticação SSO
Número do teste: CT10 Nível de teste: Sistema
Descrição Após realizar a autenticação no IdP, o usuário deve
acessar os protótipos de serviços que fazem parte do
círculo de confiança do IdP, sem necessitar nova
autenticação. Este teste avalia se o IdP esta
possibilitando a autenticação Single Sing-On (SSO),
conforme definido no requisito não funcional RNF 09. Pré-condições Usuário autenticado e possuir permissão de acesso a
aos protótipos serviço
Entrada de dados Dados do usuário. (CPF e senha)
Resultados esperados O usuário deve conseguir o acesso aos serviços que
possui permissão sem realizar nova autenticação.
Execução do teste: Após se autenticar no IdP , o usuário acessou o serviço Gerenciador do
Portal Municipal no endereço http://sistema1.levelplus.com.br e obteve o acesso sem necessidade de se
autenticar novamente no IdP. Após o usuário acessou o serviço Gerenciador do Portal de Turismo no
endereço http://sistema2.levelplus.com.br e obteve o acesso sem necessidade de se autenticar
novamente no IdP.
Resultado do teste: O usuário colaborador autenticado no IdP conseguiu o acesso aos serviços
sem a necessidade de nova autenticação. O teste confirmou que o IdP está possibilitando a
autenticação única (SSO).
O Quadro 17 apresenta o detalhamento do Caso de Uso CT 11, que testa se o IdP não permite o
acesso à usuários não válidos no sistema, além testar a possibilidade de recuperação da senha por um
usuário válido no IdP.
Quadro 17: Detalhamentos do caso de teste CT 11 - Teste de usuário inválido e recuperação de senha
Número do teste: CT11 Nível de teste: Sistema
Descrição Este caso de teste avalia se usuários não validos no
IdP conseguem acesso, além de testar o procedimento
de recuperação de senha em caso de esquecimento.
Este teste também avalia se o IdP cumpriu a regra de
negócio RN 01.
1 - Um usuário não castrado deve tentar se autenticar
no IdP;
2 - Um usuário cadastrado deve tentar se autenticar
95
no IdP com uma senha inválida (errada);
3 - Um usuário cadastrado deve solicitar a
recuperação de senha.
Pré-condições O usuário não estar cadastrado no sistema
Entrada de dados Dados de credenciais não validas no IdP e o CPF de
um usuário cadastrado.
Resultados esperados O usuário não cadastrado não deve ter acesso a
autenticação no IdP, ser apresentada a mensagem de
usuário não cadastrado e a senha deve ser recuperada
por um usuário cadastrado.
Execução do teste: Foi utilizado dados de pessoas não cadastradas no IdP para se autenticar. O
IdP exibiu a tela com a mensagem de erro. Após o teste com os dados não válidos, foi testado o
processo de recuperação de senha de um usuário válido, o usuário digitou seu CPF e clicou no botão
"Recuperar". O IdP apresentou a tela com a mensagem que o link para recuperação de senha foi
encaminhada para o e-mail do usuário. O usuário acessou a conta de seu e-mail cadastrado no IdP,
acessou o link para alteração de senha. O usuário cadastrou a nova senha e IdP apresentou a mensagem
"Senha alterada com sucesso, faça o login novamente".
Resultado do teste: Os usuários não validos no IdP não conseguiram se autenticar e o usuário
cadastrado conseguiu recuperar sua senha com sucesso. Este teste validou a regra de negócio RN 01.
O Quadro 18 apresenta o detalhamento do Caso de Uso CT 12, que testa o funcionamento do IdP
em diversos navegadores.
Quadro 18: Detalhamentos do caso de teste CT 12 - Funcionamento do IdP em diversos navegadores
Número do teste: CT12 Nível de teste: Portabilidade
Descrição O objetivo deste teste é verificar o correto
funcionamento do IdP nos navegadores Internet
Explorer 10, Mozilla Firefox, Google Chrome, Safari
e Opera.
Pré-condições O usuário estar ativo no IdP, computadores
conectados à internet e com diferentes navegadores
instalados.
Entrada de dados Dados de credenciais do usuário (CPF e senha)
Resultados esperados O IdP deve funcionar nos navegadores testados.
Execução do teste: Os testes das funcionalidades do IdP foram realizados em vários
computadores e utilizando os navegadores Internet Explorer, Mozilla Firefox, Google Chrome, Safari
e Opera.
96
Resultado do teste: Em todos os navegadores, as funcionalidades do IdP foram executadas com
sucesso. Apenas foi detectada a diferença de cor no layout da tela de login, quando utilizado o Internet
Explorer.
O Quadro 19 apresenta o detalhamento do Caso de Uso CT 13, que testa a segurança na
transferência de dados do IdP.
Quadro 19: Detalhamentos do caso de teste CT 13 - Monitoramento transferência de dados
Número do teste: CT13 Nível de teste: Segurança
Descrição O objetivo deste teste é verificar se o sistema utiliza
os protocolos de segurança para transferência de
dados conforme definido nos requisitos não
funcionais RNF 05, RNF 06 e RNF 07.
Ao acessar o IdP verificar se o sistema esta certificado
e utilizando os algoritmos definidos.
Pré-condições O IdP estar disponível na internet e wireshark
instalado para monitoramento
Entrada de dados Url: idp.levelplus.com.br
Resultados esperados Deve ser apresentado as informações do certificado de
segurança com a utilização dos algoritmos definidos
nos requisitos não funcionais.
Execução do teste: Foi acessado a URL: idp.levelplus.com.br no navegador web e visualizado
as informações contidas no certificado de segurança. A Figura 23 apresenta os a captura de pacotes no
wireshark tcp da porta 443 (ssl). Percebeu-se no pacotes capturados que as mensagens trocadas entre o
IdP e o SP foram criptografadas corretamente.
Resultado do teste: O IdP está utilizando certificado de segurança para a transferência de dados
conforme definido no requisitos não funcionais RNF 05, RNF 06 e RNF 07.
97
Figura 23: Log de requisições na porta 443 (ssl).
O Quadro 20 apresenta o detalhamento do Caso de Teste CT 14, que testa se o IdP não permite
o acesso a um Provedor de Serviço (SP) que não pertence ao círculo de confiança do IdP, conforme
definido pelas regras de negócio RN 02 e RN 03.
Quadro 20: Detalhamentos do caso de teste CT 14 - Acesso negado ao serviço que não pertence ao
círculo de confiança do IdP.
Número do teste: CT14 Nível de teste: Sistema e Integração
Descrição O objetivo deste teste é avaliar que apenas provedores
de serviços do círculo de confiança devidamente
cadastrados podem utilizar o IdP para autenticar seus
usuários, definido nas regras de negócio RN 02 e RN
03.
Pré-condições O Provedor de Serviço estar cadastrado no IdP, porém
sem os metadados corretos, conforme definido pelo
Administrador IdP
Entrada de dados A URL do provedor de serviços:
sistema2.levelplus.com.br
Resultados esperados Deve ser apresentada a tela de mensagem de
metadado não válido para o serviço.
98
Execução do teste: Primeiramente o serviço Gerenciador do Portal de Turismo
(http://sistema2.levelplus.com.br) foi alterado, sendo excluído os metadados válidos, conforme já
demonstrado nos casos de teste CT 01 e CT 02. Após a alteração realizada foi utilizada a URL
http://sistema2.levelplus.com.br para tentar realizar a autenticação por meio do IdP. A mensagem de
Metadata não válida foi apresentada.
Resultado do teste: O provedor de serviço não conseguiu utilizar a autenticação por meio do
IdP, pois não seguiu as regras definidas para integrar o círculo de confiança. As regras de negócio RN
02 e RN 03 definidas foram cumpridas pelo IdP.
A execução dos casos de teste apresentou que o protótipo de gerenciador de identidades
desenvolvido disponibilizou as funcionalidades definidas nos casos de uso, com exceção do caso de
uso USC 03, conforme já mencionado na seção 4.5.
5.1.2 Resultados e Análise do Segundo Experimento: Pesquisa de Satisfação
Esta seção apresenta os resultados e análise da pesquisa que foi aplicada para avaliação da
satisfação do usuário ao utilizar as funcionalidades do IdP. A pesquisa foi realizada no período de 14 a
24 de outubro de 2013.
Com o objetivo de alcançar um número considerável de avaliadores, uma mensagem de
correio eletrônico (ver Apêndice 4) foi encaminhada para cinqüenta e sete (57) pessoas que trabalham
na FECAM, CIGA e nas associações de municípios regionais. Sendo seis (6) técnicos que atuam
como administrador de serviços da RedeCIM, vinte e quatro (24) técnicos que atuam na gerencia de
usuários e vinte e sete (27) técnicos que utilizam os serviços disponibilizados na RedeCIM.
O experimento foi executado por cinco (5) profissionais de TI que trabalham na FECAM e no
CIGA que atuam no gerenciamento de serviços e usuários dos sistemas disponibilizados, por dezoito
(18) profissionais que atuam como gerente de contas de usuários dos serviços e mais dezoito (18)
profissionais que atuam como usuários consumidores dos serviços disponibilizados nas instituições,
totalizando quarenta e um (41) avaliadores. A Figura 24, apresenta a distribuição dos avaliadores
relacionado ao perfil dos usuários no IdP.
99
Figura 24: Número de avaliadores conforme perfil do usuário no IdP
O gráfico da Figura 25, refere-se a distribuição dos avaliadores conforme a instituição que ele
faz parte. Vale ressaltar que 34% da amostra são avaliadores distribuídos nas associações de
municípios regionais catarinenses, avaliadores que são considerados clientes dos serviços da
RedeCIM, sendo os outros 66% dos avaliadores, usuários das instituições vinculadas à FECAM.
Figura 25: Número de avaliadores conforme a instituição pertencente
Conforme o gráfico da Figura 26, a maioria dos avaliadores são profissionais que atuam na área
de TI, totalizando 21 avaliadores (51% da amostra), seguido pela área administrativa com 27% dos
avaliadores, totalizando 11 avaliadores. Porém, apesar da concentração dos avaliadores nas áreas de TI
e administrativa, o gráfico da apresenta a multidisciplinaridade dos avaliadores distribuídos em oito
áreas técnicas relacionadas à atuação das instituições envolvidas na amostra.
5; 12%
18; 44%
18; 44%
Distribuição dos avaliadores conforme o perfil do usuário no IdP
Administrador IdP
Administrador Instituição
Colaborador
21; 51%
6; 15%
14; 34%
Distribuição da amostra conforme a instituição do avaliador
FECAM
CIGA
Associações de Municípios
100
Figura 26: Distribuição dos avaliadores por área técnica
Dentre os avaliadores, 34% são usuários de mais de cinco sistemas e outros 49% utilizam entre
um (1) e cinco (5) sistemas, números que demonstram a necessidade de ferramentas como o IdP para
auxiliar e contribuir com a gestão de identidades mais efetiva nas instituições, pois apenas 17% dos
avaliadores são usuários de apenas um serviço (Figura 27).
Figura 27: Número de sistemas que o avaliador é usuário
O gráfico da Figura 28 refere-se ao tempo de atuação dos profissionais na função de usuários dos
serviços da RedeCIM e demonstra que a pesquisa foi aplicada em um grupo experiente. Sendo que
39% atuam a mais de 5 anos nesta função, 34% atuam entre um (1) e cinco (5) anos e 27% atuam a
menos de um 1 ano. Se considerado apenas os avaliadores que atuam como administrador de usuários,
21
11
2
2
2
1
1
1
0 5 10 15 20 25
Tecnologia da Informação
Administração
Jurídico
Economia
Comunicação
Meio Ambiente
Cultura e Turismo
Assistência social
Número de avaliadores por área de atuação na sua instituição
7; 17%
20; 49%
14; 34%
Quantos sistemas disponibilizados pela FECAM e CIGA você é usuário?
1 sistema
Entre 1 e 5 sistemas
Acima de 5 sistemas
101
que totalizam 23 avaliadores, o grau de experiência aumenta, pois 47,82% atuam neste papel a mais de
cinco (5) anos e apenas 17,39% atuam neste papel a menos de um (1) ano.
Figura 28: Tempo de atuação do avaliador no papel de usuário
As repostas das questões relacionadas ao nível de conhecimento dos avaliadores quanto aos
conceitos de gerenciamento de identidades são apresentados nos gráficos das Figuras 29, 30, 31 e 32.
Sendo que, 66% dos avaliadores conhecem os conceitos de provedor de identidades. Considerando que
na amostra, 21 (vinte um) dos avaliadores são da área de TI (Figura 26), observa-se que o percentual
de conhecimento sobre este conceito é significativa. Por outro lado, se for considerado apenas os 18
(dezoito) avaliadores do perfil colaborador no IdP, o percentual de conhecimento baixa para 39%,
apenas 7 (sete) avaliadores. (ver Tabela 5 do Apêndice 5). A Figura 29, apresenta os resultados do
conhecimento dos avaliadores sobre o conceito de provedor de identidades.
Figura 29: Percentual de conhecimento sobre provedor de identidades
11; 27%
14; 34%
16; 39%
Quantos anos você atua neste papel?
Menos de 1 ano
Entre 1 e 5 anos
Acima de 5 anos
27; 66%
14; 34%
Você sabe o que são provedores de identidades (IdP - Indentity Provider)?
Sim
Não
102
O gráfico da Figura 30, mostra que conhecimento dos usuários quanto ao conceito de
autenticação SSO apresentou menor taxa, pois somente 41% dos avaliadores conhecem este conceito.
Já o percentual de conhecimento sobre autenticação centralizada foi 61% (Figura 31) e o conhecimento
sobre autenticação federada apresentou 52% (Figura 32).
Figura 30: Percentual de conhecimento sobre autenticação SSO
Figura 31: Percentual de conhecimento sobre autenticação centralizada
A questão sobre o conceito de autenticação Federada foi aplicada apenas aos 23 avaliadores do
perfil de administrador IdP e administrador da instituição, portanto representam o conhecimento
apenas dos avaliadores que gerenciam usuários dos serviços da RedeCIM, não representando o
conhecimento dos avaliadores que participaram do experimento como usuários do perfil de
colaborador.
17; 41%
24; 59%
Você conhece o conceito de autenticação SSO?
Sim
Não
25; 61%
16; 39%
Você conhece o conceito de autenticação Centralizada?
Sim
Não
103
Figura 32: Percentual de conhecimento sobre autenticação Federada
Dentre os avaliadores foi possível verificar o pouco conhecimento deles quanto aos conceitos na
área de gestão de identidades, pois apresentaram a média de conhecimento da quatro questões de
apenas 55%, principalmente se considerarmos o tempo experiência da atuação dos avaliadores neste
papel. Vale ressaltar que a pesquisa foi respondida na sua maioria por técnicos das instituições que
vivenciam a administração de sistema no seu dia-a-dia, portanto, se a mesma pesquisa fosse aplicada
aos servidores públicos municipais, a tendência é que o grau de conhecimento sobre estes conceitos
específicos fosse menor.
Os gráficos das Figuras 33 e 34 apresentam as tecnologias utilizadas pelos avaliadores na
execução do experimento. O Windows em suas diferentes versões foi o sistema operacional mais
utilizado com 76%, sendo que por ser uma pergunta aberta, os avaliadores não descreveram as versões
utilizadas. Porém, 12% dos avaliadores não souberam responder qual sistema operacional estavam
utilizando. Quanto ao uso de navegadores Web os resultados apresentaram que 90% utiliza o Google
Chrome.
12; 52%
11; 48%
Você conhece o conceito de autenticação Federada?*
Sim
Não
104
Figura 33: Sistemas operacionais utilizados pelos avaliadores
Figura 34: Navegadores web utilizados pelos avaliadores
31; 76%
5; 12%
5; 12%
Qual sistema operacional você está utilizando para executar este experimento?
Windows
Linux
Não soube responder
37; 90%
3; 7% 1; 3%
Qual navegador web você está utilizando para executar este experimento?
Google Chrome
Mozila Firefox
Internet Explorer
Safari
Opera
Outros
105
O gráfico apresentado na Figura 35, representa a taxa de avaliadores que executaram com
sucesso o experimento.
Figura 35: Execução do experimento
As respostas obtidas dos usuários que tiveram problemas ao executar o experimento, foram:
1. "Não tive problemas, apenas quando fui no item "recuperar senha" e digitei o CPF, o
sistema acabou puxando dados que estavam gravados e possuía pontos entre os
números. Porém, há uma mensagem clara dizendo que são apenas números."
2. "Ao selecionar um usuário para vincular com o serviço, fui direcionado para uma
pagina de erro do navegador. Na segunda tentativa o procedimento foi realizado com
sucesso."
O gráfico da Figura 36 apresenta que 15% dos avaliadores precisaram reiniciar o experimento
por algum tipo de problema, alguns desses já relatados na resposta anterior.
Figura 36: Necessidade de reinício do experimento.
38; 93%
3; 7%
Você conseguiu executar com sucesso todos os passos descritos no roteiro do experimento?
Sim
Não
35; 85%
6; 15%
Foi necessário cancelar a execução de algum serviço e iniciar novamente?
Não
Sim
106
A Figura 37, apresenta o gráfico que avalia a satisfação dos usuários quanto as mensagens de
erros, caso elas tenham ocorrido. 34% dos usuários não tiveram problemas, portanto não avaliaram
esta questão. 49% dos usuários que avaliaram as mensagens consideraram que as mensagens foram
suficientes para apontar o problema ocorrido, outros 15% consideraram que as mensagens foram
parcialmente suficientes e os 2% restantes (um usuário), não considerou as mensagens suficientes para
entender o problema.
Figura 37: Suficiência das mensagens de erro
O gráfico da Figura 38 representa o ponto de vista dos avaliadores quanto a apresentação das
informações do protótipo. A maioria (76%) considerou as informações claras e compreensíveis, 22%
consideram as informações parcialmente claras e apenas 2% consideram que as informações do IdP
não compreensíveis.
Figura 38: Apresentação legível das informações
20; 49%
6; 15%
1; 2%
14; 34%
As mensagens de erros, caso tenham ocorrido, foram suficientes para apontar o problema?
Sim
Parcialmente
Não
Não se aplica
31; 76%
9; 22%
1; 2%
No seu ponto de vista, a apresentação das informações está legível (claras e compreensíveis)?
Sim
Parcialmente
Não
107
Quanto a rapidez na execução dos serviços, (ver Figura 39), a grande maioria (90%) dos
avaliadores consideram que o IdP respondeu rapidamente as suas ações.
Figura 39: Rapidez dos serviços do IdP
A Figura 40 apresenta os resultados sobre a questão em que o usuário respondeu se em algum
momento durante a utilização do experimento ele não soube o que fazer. Como resposta obteve-se que
71% dos avaliadores souberam o que fazer, entretanto, se comprova que em algum ponto do roteiro do
experimento está faltando informações mais claras das funcionalidades do IdP, pois 29% da amostra
em algum momento não soube o que fazer.
Figura 40: Não saber executar o experimento
37; 90%
4; 10% 0; 0%
Os serviços reagiram rapidamente as suas ações?
Sim
Parcialmente
Não
29; 71%
12; 29%
Você em algum momento não soube o que fazer?
Não
Sim
108
A Figura 41 apresenta que na média dos três perfis de usuários 85% dos avaliadores
compreenderam as funções do IdP acessadas durante o experimento. Entretanto, a análise das respostas
divididas conforme o perfil do usuário apresenta no perfil Administrador do IdP que 100%
compreenderam as funções do IdP, enquanto os Administradores da Instituição o percentual baixou
para 89% e os avaliadores do perfil colaborador baixou ainda mais para 78%. Ao analisar os perfis,
observa-se que os avaliadores que trabalham no seu dia-a-dia com a gestão de usuários
compreenderam melhor as funções do IdP, já os colaboradores que são os usuários que apenas utilizam
o IdP para autenticação tiveram mais dificuldades para entender seu objetivo.
Você compreendeu as funções do IdP acessadas no experimento?
Figura 41: Compreensão da funções do IdP
O gráfico da Figura 42, apresenta as respostas dos perfis Administrador do IdP e
Administradores das Instituições. Na média 83% dos avaliadores opinaram que o gerenciamento de
usuários realizado utilizando o modelo centralizado como o IdP traz maior rapidez.
Na sua opinião, o gerenciamento de usuários pode ser realizado com maior rapidez utilizando um sistema centralizado como o IdP?
Figura 42: Rapidez na gestão de usuários
5; 100%
Perfil Administrador do IdP
Sim
Não
16; 89%
2; 11%
Perfil Administrador da Instituição
Sim
Não
14; 78%
4; 22%
Perfil Colaborador
Sim
Não
4; 80%
0; 0%
1; 20%
Perfil Administrador do IdP
Sim
Não
Sem opinião formada 15; 83%
0; 0%
3; 17%
Perfil Administrador da Instituição
Sim
Não
Sem opinião formada
109
O gráfico da Figura 43 apresenta que, na média dos três perfis, a opinião de 88% dos avaliadores
referente a utilização do IdP, traz maior flexibilidade no acesso aos serviços. Entretanto, se for
considerada as opiniões apenas dos avaliadores do perfil colaborador observa-se que o percentual de
satisfação neste quesito baixa para 83%, sendo que 11% não possuem opinião formada.
Na sua opinião, um sistema de gerenciamento de identidades, como o que você testou, que provê a autenticação
única de usuários e possibilita o acesso a diversos serviços sem a necessidade de nova autenticação, trará mais
flexibilidade para os serviços utilizados pela sua instituição?
Figura 43: Opinião sobre a flexibilidade no acesso aos serviços com a autenticação SSO
Segue alguns comentários obtidos sobre a flexibilidade do IdP:
1. "Flexibilidade trará com certeza, mas deve-se ter muito cuidado no processamento das
informações, segurança e confiabilidade do sistema."
2. "Esse sistema de gerenciamento de identidades torna mais rápido e ágil a realização das
atividades da instituição, o que é de suma importância dentro de um órgão que trabalha
com tais aspectos."
3. "Ficaria uma forma mais centralizada de autenticação, portanto gerando mais
organização e controle dos usuários."
4. "Hoje temos na instituição oferece muitos serviços e cada um com uma autenticação.
Gerenciar todas essas identidades com em um sistema só seria um avanço."
5. "A ferramenta é muito útil pois facilitará o processo num todo, sem necessidade de
novos acessos com pedidos de login e senhas, gostei muito, não conhecia essa ferramenta
e ela aplicada nos sistemas públicos principalmente nos portais da FECAM será de
5; 100%
Perfil Administrado do IdP
Sim
Não
Sem opinião formada 16;
89%
2; 11%
Perfil Administrado da Instituição
Sim
Não
Sem opinião formada 15;
83%
1; 6%
2; 11%
Perfil Colaborador
Sim
Não
Sem opinião formada
110
grande valia. Pois o usuário não necessita lembrar de diversas senhas, basta lembrar de
uma."
Sobre a opinião dos avaliadores referente à segurança da utilização do IdP para autenticação
centralizada dos usuários, os resultados apontam que 71% dos avaliadores indicam que traz maior
segurança, 24% dos avaliadores não tinham uma opinião formada e apenas 5% opinaram que o IdP
não traz segurança. A Figura 44, apresenta a opinião distribuída conforme o perfil do avaliador no IdP.
Na sua opinião, o modelo de autenticação centralizada no IdP traz maior segurança?
Figura 44: Opinião sobre a segurança do IdP
Quanto questão sobre a segurança do IdP foram obtidos os seguinte comentários durante a
aplicação do questionário:
1. "Quanto maior o número de senhas mais complicado fica a guarda destas senhas."
2. "Existe maior segurança no processo de login pois os sistemas passam a ter apenas um
ponto convergente para essa ação, entretanto um ataque de negação de serviço ao
provedor IDP deixaria todos os SP's indisponíveis."
3. "Acredito que não pois se algum intruso descobrir essa única senha, terá acesso a todos
os sistemas participantes."
4. "Sim porque é mais fácil o usuário criar e lembrar de uma única senha mais elaborada
(com caracteres especiais, etc) do que varias senhas mais simples (Ex data de
nascimento)."
5. "Facilita muito o trabalho, mas não necessariamente trará maior segurança. Tudo
dependerá da segurança e confiabilidade do sistema."
4; 80%
1; 20%
Perfil Administrador do IdP
Sim
Não
Sem opinião formada 13;
72%
1; 6%
4; 22%
Perfil Administrador da Instituição
Sim
Não
Sem opinião formada 12;
67%
1; 5%
5; 28%
Perfil Colaborador
Sim
Não
Sem opinião formada
111
O gráfico da Figura 45 apresenta a opinião dos avaliadores dos perfis Administrador do IdP e
dos Administrador da Instituição quanto ao uso do IdP para a gestão dos usuários dos serviços da
FECAM e do CIGA. Observou-se que 60% dos administradores do IdP não possuem opinião formada
e 40% gostariam de utilizar o IdP. Já os avaliadores do perfil administrador da Instituição, 89%
opinaram que gostariam de utilizar o IdP e 11% não possuem opinião formada.
Você gostaria de utilizar o IdP para a gestão dos usuários dos serviços disponibilizados pela FECAM as instituições?
Figura 45: Opinião sobre a utilização do IdP nas instituições
78% dos avaliadores do perfil colaborador opinaram que gostariam de utilizar o IdP para realizar
a autenticação para acesso aos serviços, 17% não possuem opinião formada enquanto apenas 5% (um
avaliador), opinou que não gostaria de utilizar o IdP (ver Figura 46).
Você gostaria de utilizar o IdP para a autenticação e acesso aos serviços disponibilizados pela FECAM/CIGA?
Figura 46: Opinião sobre a utilização do IdP pelos colaboradores
O gráfico da Figura 47 apresenta os resultados da opinião dos avaliadores dos perfil
administrador IdP e administrador da Instituição que somam 23 avaliadores. Na média dos dois perfis,
2; 40%
3; 60%
Perfil Administrador do IdP
Sim
Não
Sem opinião formada
16; 89%
2; 11%
Perfil Administrador da Instituição
Sim
Não
Sem opinião formada
14; 78%
1; 5%
3; 17%
Perfil Colaborador
Sim
Não
Sem opinião formada
112
96% dos avaliadores opinaram que a utilização do IdP facilitaria o processo de gestão de usuários,
além de trazer maior satisfação dos usuários que utilizam os serviços disponibilizados pela FECAM e
CIGA. Entretanto se considerar apenas os avaliadores do perfil administrador da instituição, os 100%
dos usuários opinaram que o IdP facilitaria o processo de gestão de usuários.
Na sua opinião, para os administradores das instituições integradas (municípios e associações de municípios), o uso do IdP
facilitaria o processo de gestão de usuários e traria maior satisfação aos clientes?
Figura 47: Opinião sobre a facilidade na gestão e na satisfação dos usuários
Ao final do formulário de pesquisa foram feitas duas perguntas opcionais para os avaliadores. As
perguntas e as respectivas respostas são apresentadas a seguir:
O que você achou melhor no experimento que você executou? Por quê?
1. "Acesso mais rápido aos sistemas.";
2. "Apenas um login acessa várias ferramentas.";
3. "Facilidade em deliberar acesso a determinado sistema e melhor controle de usuários.";
4. "O melhor é ter acesso a todos os sistemas sem precisar ficar lembrando usuário e senha
de cada um deles.";
5. "Facilidade e simplicidade de cadastro.";
6. "Muito bom , gera maior segurança para o usuário.";
7. "As informações solicitadas eram breves e claras e o processo muito rápido.";
8. "O ponto principal é a questão da unificação das senhas e a facilidade de
gerenciamento.";
4; 80%
1; 20%
Perfil Administrador do IdP
Sim
Não
Sem opinião formada
18; 100%
Perfil Administrador da Instituição
Sim
Não
Sem opinião formada
113
9. "O sistema, permite um entendimento claro dos conceitos de funcionamento do modelo
IdP, porque contempla os eixos principais da solução.";
10. "Porque gera um maior controle em cima no que tange administração de usuários.";
11. "Gostei pela segurança e praticidade que a ferramenta oferece.";
12. "Imaginar todos os usuários num único login.";
13. "Facilidade de uso, porque pelo breve período que utilizei o sistema ele me pareceu bem
"claro, simples de usar e fácil de cadastrar novos usuários.";
14. "Achei o experimento bastante dinâmico, visto que é possível efetuar o cadastro do
usuário uma única vez e gerenciar o acesso do mesmo a vários sistemas.";
15. "Possibilidade de utilizar uma única senha para diversos sistemas evita o hábito de
repetir a senha para sistemas diferentes afim de evitar esquecimento, tornando o acesso
a estes sistemas mais vulnerável.";
16. "A centralização de acessos para vários sistemas com apenas um login e senha. Facilita
a vida do usuário na questão de criação de senhas (uma só apenas) assim como também
traz mais agilidade no uso dos sistemas.";
17. "Visão ampla dos serviços disponíveis a partir do login/senha único.";
18. "Acho muito prático ter uma única senha para acessar todos os programas.";
19. "A facilidade em executar o login. O rápido envio da senha, visto que em outras
situações já identifiquei a demora no envio da nova senha, trazendo problemas.";
20. "O fácil acesso das informações a respeito do profissional.";
21. "Sua página, por apresentar características simples, promove a rápida pesquisa, sem
demora no processo de carregamento de informações."; e
22. "A facilidade no acesso, a possibilidade de recuperar senha.".
Você tem algum comentário adicional sobre o IdP (sugestões e críticas)
1. "A priori não teria um sugestão, mas posso analisar melhor caso eu tenha alguma lhe
encaminho.";
114
2. "A literatura e estudos do tema , deixa algumas questões em aberto, citando vantagens e
desvantagem em relação ao modelo " tradicional".Na minha opinião uma das questões
mais relevantes, trata do entendimento do usuário final da aplicação, que parece ser o
elo mais frágil e vulnerável.";
3. "No acesso centralizado a diversos sistemas e dados poderia forçar o usuário a pensar
que toda informação tratada pelos serviços/sistemas estejam interligadas, gerando um
uso moderado dos recursos, causando talvez até insegurança.";
4. "Tenho como sugestão acrescentar e aprimorar a ferramenta para os deficientes
audiovisuais, ou seja, oferecer o recurso incluindo essas pessoas que estão em nosso
meio e que possam estar utilizando essa ferramenta de grande valia e com segurança e
praticidade.";
5. "Na parte de gerenciamento de usuários, a mensagem que está abaixo poderia aparecer
quando passasse o mouse sobre os botões de opção (+) e (-).";
6. "Seria legal implementar redundância no idp.";
7. "Para fins de controle seria interessante que o sistema permitisse a visualização do
administrador que efetuou a liberação do acesso ao serviço para determinado
colaborador. Isto porque, acredito eu, haverá mais de um administrador com permissão
para liberar acessos de colaboradores no mesmo sistema.";
8. "Acho que o sistema deveria exigir a gravação de senhas com números e letras diferentes
da senha.";
9. "Ao mesmo tempo que é interessante e prático ter uma única senha de acesso, acho que o
risco de clonar ou de dar algum problema é muito maior.";
10. "Apenas o cuidado com as informações e senhas dos usuários. Como mencionei acima,
tudo dependerá do grau de segurança do sistema. No mais acho uma excelente idéia e
facilita o trabalho tornando mais ágil."; e
11. "Como não conheço as terminologias da tecnologia tive dificuldades de compreender
algumas questões.".
115
6 CONCLUSÕES
Conforme descrito neste trabalho, um dos desafios da Federação Catarinense de Municípios é
realizar uma gestão eficiente do crescente número de usuários dos sistemas integrados à RedeCIM,
neste contexto, se faz necessário uma solução para aprimorar o atual processo de gerenciamento de
identidades, de modo que facilite a administração dos cadastros de serviços e pessoas, além de garantir
a identidade e autenticidade dos usuários. De forma a analisar como o modelo de gestão de identidades
centralizado pode ser empregado na RedeCIM, foi desenvolvido neste trabalho um protótipo de um
provedor de identidades baseado no padrão SAML.
Para o desenvolvimento deste trabalho foi realizada uma revisão bibliográfica sobre conceitos
relacionados à gestão de identidades. Foram abordados tópicos sobre gerenciamento de identidades,
Autenticação Single Sing-On, SAML, OpenID, Oauth, Kerberos, CAS, OpenLDAP, e Arquitetura e-
PING.
A revisão bibliográfica possibilitou identificar a importância e as vantagens que o
gerenciamento de identidades utilizando tecnologias abertas podem trazer para o usuários e os gestores
da RedeCIM. Através desta revisão bibliográfica, da análise dos serviços da RedeCIM e das reuniões
com a equipe técnica da Federação Catarinense de Municípios o modelo centralizado de
gerenciamento de identidades foi definido como o mais adequado. Além disso, foi possível definir os
requisitos e os casos de uso do Provedor IdP desenvolvido.
O IdP foi desenvolvido baseado em tecnologias de código aberto, utilizando o Zend Framework
com a ferramenta simpleSAMLPHP para prover a troca de informações de autenticação e autorização
com a especificação SAML 2.0, e uma estrutura de diretórios LDAP para armazenagem dos dados,
seguindo as recomendações da arquitetura e-PING. Com as funcionalidades do IdP, os usuários podem
realizar sua autenticação e acessar os serviços permitidos, bem como os administradores do IdP podem
gerenciar pessoas e serviços. Outra funcionalidade que o IdP proporcionou aos usuários foi a
autenticação única (Single Sing-On - SSO), desta forma, possibilitando ao usuário autenticado acesso
aos serviços pertencentes ao círculo de confiança do IdP, sem a necessidade de nova autenticação.
Por fim, o portal foi avaliado através de uma pesquisa de satisfação aplicada em três grupos de
usuários que representam os perfis no IdP. Os resultados da pesquisa de satisfação demonstram que os
116
avaliadores em sua grande maioria ficaram satisfeitos com o uso do IdP, principalmente os
administradores de serviços, que com o uso do gerenciador de identidades centralizado podem realizar
a gestão dos serviços e usuários de uma forma mais simples e segura. Além da avaliação realizada
pelos usuários, foram executados casos de teste para verificação do atendimento aos requisitos
funcionais e não funcionais, obtendo resultado positivo para maioria destes.
A principal contribuição deste trabalho foi oferecer uma solução tecnológica viável para o
aprimoramento do processo de gestão de identidades da Federação Catarinense de Municípios, além de
apresentar os diversos modelos e tecnologias existentes como alternativas para o gerenciamento de
identidades na instituição.
6.1 TRABALHOS FUTUROS
Como recomendação de trabalhos futuros, sugere-se o desenvolvimento de um sistema que
possibilite que os cidadãos que interagem com os portais integrados da RedeCIM, consigam se
autenticar nos serviços disponibilizados utilizando as credenciais de suas contas pessoais, como contas
no Google, Yahoo e Facebook, desta forma facilitando o acesso sem a necessidade de novo cadastro de
informações.
O uso da especificação SAML no IdP possibilita 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.
Outro trabalho que deve ser implementado é a redundância do IdP, afim de possibilitar que o
sistema fique sempre em funcionamento.
117
REFERÊNCIA BIBLIOGRÁFICA
ALECRIM, Emerson; Tecnologia RAID, Infowester, 2004, Atualizado em 2013. Disponível em: <
http://www.infowester.com/raid.php>. Acesso em fevereiro de 2013.
AUBRY, P., MATHIEU, V., MARCHAL, J. Esup-Portail: open source Single Sign-On with CAS.
2004. Disponível em: <http://www.esup-portail.org/consortium/espace/SSO_1B/cas/eunis2004/cas-
eunis2004-article.pdf>. Acessado em Junho de 2013.
BALDONI, R. Federated Identity Management Systems in e-Government: the Case of Italy.
Electronic Government: An International Journal, 8, 2010
BARBOSA, A. Governo Eletrônico: Dimensões da Avaliação de Desempenho na Perspectiva do
Cidadão. Tese de doutorado, FGV-EAESP, 2008.
BERTINO, E., TAKAHASHI, K. Identity Management: Concepts, Technologies and Systems.
Artech House, 2011.
BHARGAV-SPANTZEL, A., CAMENISCH, J., GROSS, T., E SOMMER, D. User centricity: a
taxonomy and open issues. Journal of Computer Security. 2007.
CAMENISCH, J.; PFITZMANN, B. Security, privacy, and trust in modern data management,
chapter Federated Identity Management, pages 213–238. Springer Verlag, 2007.
CAMPOS, André L. N. Sistema de Segurança da Informação: Controlando Riscos. Florianópolis:
Visual Books, 2006.
CGI.br. Pesquisa sobre o uso das Tecnologias da Informação e da Comunicação – TIC Governo
Eletrônico 2011. Comitê Gestor da Internet no Brasil – CGI.br, São Paulo: 2012. Disponivel em: <
http://cgi.br/publicacoes/pesquisas/index.htm#tic-domicilios-2011>. Acesso em 14 de março de 2013.
CHESWICK, R. William.; BELLOVIN, M. Steven; RUBIN,; D. Aviel. Firewalls e Segurança na
Internet: Repelling a Wily Hacker. 2ª. ed. São Paulo, 2005.
CHADWICK, D. Federated identity management. Foundations of Security Analysis and Design V,
pages 96–120. 2009.
118
CAMENISCH, J. E PFITZMANN, B. Security, Privacy, and Trust in Modern Data Management,
chapter Federated Identity Management, pages 213–238. Springer Verlag, 2007.
CARRARA, Luis Henrique; TRIGO, Clodonil Honório. Autenticação Centralizada com
OpenLDAP. UNICEP, São Carlos – SP, 2010.
DIAS, Cláudia. Segurança e auditoria da tecnologia da informação. Rio de Janeiro: Axcel Books,
2000.
DIVITO, T. OpenID: A Potential Authentication Technology. 2008. Disponível em: <
http://www.decisionsciences.org/DecisionLine/Vol39/39_2/dsi-dl39_2ecom.pdf>. Acesso em maio de
2013.
FELICIANO, G.; AGOSTINHO, L.; GUIMARÃES, E.; CARDOZO, E. Gerência de Identidades
Federadas em Nuvens: Enfoque na Utilização de Soluções Abertas, Campinas, 2011. Disponível
em: < http://dainf.ct.utfpr.edu.br/~maziero/lib/exe/fetch.php/ceseg:2011-sbseg-mc5.pdf>. Acesso em
20 de abril de 2013.
FECAM, Guia dos Municípios Catarinenses 2011/2012. Florianópolis, 2011. Disponível em: <
HTTP://guia.fecam.org.br>
FERREIRA, Sérgio G. e ARAUJO, Erika A. Modernização da gestão: E-governo: o que ensina a
experiência internacional. 2000. Informe SF (Secretaria para Assuntos Fiscais do BNDES), n. 17,
agosto. Disponível em:
<http://www.bndes.gov.br/SiteBNDES/export/sites/default/bndes_pt/Galerias/Arquivos/conhecimento/
informesf/inf_17.pdf> Acesso em junho de 2013.
GCIO. An Overview of SAML v2.0. Government ICT Directions ad Priorities, Nova Zelândia, 2005.
Disponível em: <http://ict.govt.nz/guidance-and-resources/standards-compliance/authentication-
standards/security-assertion-messaging-framework/7-overview-saml-v20>. Acesso em maio de 2013
GIL, A. C. Métodos e Técnicas de Pesquisa Social, 6ª Ed. São Paulo, 2008. Disponível em:
<http://mba.eci.ufmg.br/downloads/metodologia.pdf>
GOV.BR. Padrões de Interoperabilidade de Governo Eletrônico – e-PING, Ministério do
Planejamento, Orçamento e Gestão, Brasília, 2013. Disponível em:
119
<http://www.governoeletronico.gov.br/acoes-e-projetos/e-ping-padroes-de-interoperabilidade> Acesso
em junho de 2013.
HAMMER-LAHAV, E.; The OAuth 1.0 Protocol. 2010. Disponível em:<
http://tools.ietf.org/html/rfc5849>. Acesso em maio de 2013.
HARDT, D.; The OAuth 2.0 Authorization Framework draft-ietf-oauth-v2-31. 2012. Disponível
em:< http://tools.ietf.org/html/draft-ietf-oauth-v2-31>. Acesso em maio de 2013.
JASIG. CAS – Central Authentication Service. Disponível em: < http://www.jasig.org/cas>
JOSANG, A.; POPE, S. User Centric Identity Management. CRC for Enterprise Distributed
Systems Technology. The University Queensland, Australia, 2005.
JØSANG, A. E POPE, S. User centric identity management, In AusCERT Asia Pacific Information
Technology Security Conference, 2005.
JOSSO. Java Open Single Sign-On. Disponível em: <http://www.josso.org>. Acesso em maio de
2013.
MAIA. J. R. Francisco. Entendendo o LDAP. (2005). Disponível em: <
http://www.vivaolinux.com.br/artigo/Entendendo-o-LDAP>. Acesso em fevereiro de 2013.
MALIKI, T. E.; SEIGNEUR, J. M. A survey of user-centric identity management technologies. In
The International Conference on Emerging Security Information, Systems, and Technologies, 2007.
SecureWare 2007, pages 12–17. 2007.
MIT. Kerberos: The Network Authentication Protocol. MIT Kerberos Consortium. Disponível em:
<http://web.mit.edu/kerberos/ >. Acesso em 01 de maio de 2013.
NEUMAN, B. Clifford.; TS’O, Theodore. Kerberos: An Authentication Service for Computer
Networks. IEEE Communications Magazine, Volume 32, Nº 9, paginas 33-38, Setembro de 1994.
Disponível em: <http://gost.isi.edu/publications/kerberos-neuman-tso.html>Acesso em 01 de maio de
2013.
NOGUEIRA, H. SANTOS, D. B., CUSTÓDIO, R. F. Um Survey sobre Ferramentas para Single
Sign-On, XII Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais. 2012.
120
Curitiba: Sociedade Brasileira de Computação, 2012. P. 522-542 Disponível em: <
http://sbseg2012.ppgia.pucpr.br/@docs/SBSeg2012Anais.pdf> Acesso em abril de 2013.
OPENID FOUNDATION. OpenID. Disponível em: < http://openid.net/get-an-openid/what-is-
openid/> Acesso em maio de 2013.
OPENLDAP FOUNDATION. OpenLDAP. Disponível em: < http://www.openldap.org/> Acesso em
fevereiro de 2013.
OASIS. SAML V2.0 Executive Overview. (2005) Disponível em: <https://www.oasis-
open.org/committees/download.php/13525/sstc-saml-exec-overview-2.0-cd-01-2col.pdf>. Acesso em
maio de 2013
OASIS. SAML V2.0 Technical Overview. (2008) Disponível em: < http://docs.oasis-
open.org/security/saml/Post2.0/sstc-saml-tech-overview-2.0.pdf>. Acesso em maio de 2013.
PEIXOTO, Mário, Uma análise geral sobre Single Sing On, Rio de Janeiro, 2012. Disponível em:
<http://webinsider.uol.com.br/2012/01/09/uma-analise-geral-sobre-single-sign-on/>. Acesso em 20 de
abril de 2013.
RIBEIRO JR. Jaime.; Open LDAP: a chave é a centralização. (2008). Disponível em:
<http://www.vivaolinux.com.br/artigo/OpenLDAP-a-chave-e-a-centralizacao?pagina=5>. Acesso em
fevereiro de 2013.
RICCIARDI, Fulvio.; Kerberos Protocol Tutorial. Lecce, Italy, Novembro de 2007. Disponível em:
< http://www.kerberos.org/software/tutorial.html> Acesso 01 de maio de 2013.
RNP. Comunidade Acadêmica Federada – CAFe, Rede Nacional de Ensino e Pesquisa. Disponível
em: <http://portal.rnp.br/web/servicos/cafe> Acesso em junho de 2013.
ROVER, Aires. O governo eletrônico e a inclusão digital: duas faces da mesma moeda chamada
democracia. In: ROVER, Aires José (ed). Inclusão digital e governo eletrônico. Zaragoza: Prensas
Universitárias de Zaragoza, Lefis series 3, 2008, p. 9 - 34.
SANTOS, Alfredo. Gerenciamento de Identidades. Rio de Janeiro: Brasport, 2007.
STALLINGS, William. Criptografia e Segurança de Redes – Princípios e Práticas. 4ª Ed. São
Paulo: Pearson Prentice Hall, 2008.
121
THIBEAU, D. A Letter from the Executive Director: OpenID and Open Government, 2009.
Disponível em: < http://openid.net/government/>. Acesso em maio de 2013.
THIBEAU, D. Open Trust Frameworks for Open Government: Enabling Citizen Involvement
through Open Identity Technologies, 2009. Disponível em: <
http://openid.net/docs/Open_Trust_Frameworks_for_Govts.pdf>. Acesso em maio de 2013.
TRIGO, Clodonil Honório.; OpenLDAP: uma abordagem integrada, São Paulo: Novatec, 2007.
VEDANA, Celso. Federalismo: Autonomia Tributária Formal dos Municípios. Florianópolis:
Habitus, 2002. 208 p.
WANGHAM, M. S.; MELLO, E. R.; BOGER, D. S.; SILVA, R. S.; HOLLER, D. R.; FRAGA, J. S.
Segurança em Redes Colaborativas: desafios e propostas de soluções. IX Simpósio Brasileiro em
Segurança da Informação e de Sistemas Computacionais. 2009. Campinas: Sociedade Brasileira de
Computação, 2009. P. 99-148. Disponível em:
http://www.lbd.dcc.ufmg.br/colecoes/sbseg/2009/041.pdf>
WANGHAM, M. S.; MELLOM E.R.; BOGER, D. S.; GUERIOS, M.; FRAGA, J. S. Gerenciamento
de Identidades Federadas, X Simpósio Brasileiro em Segurança da Informação e de Sistemas
Computacionais. 2010. Fortaleza: Sociedade Brasileira de Computação. 2010.
YOUN. P. Creating a Safer OAuth User-Experience, San Francisco, CA, 2011. Disponível em: <
https://www.isecpartners.com/media/11683/isec-creating_safer_oauth_experience.pdf>. Acesso em:
maio de 2013.
122
APÊNDICE 1 - METADADOS FORNECIDOS PELO PROTÓTIPO DE
PROVEDOR DE SERVIÇOS - SP
$metadata['http://sistema1.levelplus.com.br/simplesaml/module.php/saml/sp/metadata.php/wso2-sp'] = array (
'entityid' => 'http://sistema1.levelplus.com.br/simplesaml/module.php/saml/sp/metadata.php/wso2-sp',
'contacts' =>
array (
0 =>
array (
'contactType' => 'technical',
'givenName' => 'Administrator',
'emailAddress' =>
array (
0 => '[email protected]',
),
),
),
'metadata-set' => 'saml20-sp-remote',
'AssertionConsumerService' =>
array (
0 =>
array (
'Binding' => 'urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST',
'Location' => 'http://sistema1.levelplus.com.br/simplesaml/module.php/saml/sp/saml2-acs.php/wso2-sp',
'index' => 0,
),
1 =>
array (
'Binding' => 'urn:oasis:names:tc:SAML:1.0:profiles:browser-post',
'Location' => 'http://sistema1.levelplus.com.br/simplesaml/module.php/saml/sp/saml1-acs.php/wso2-sp',
'index' => 1,
),
2 =>
array (
'Binding' => 'urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Artifact',
'Location' => 'http://sistema1.levelplus.com.br/simplesaml/module.php/saml/sp/saml2-acs.php/wso2-sp',
'index' => 2,
),
3 =>
array (
'Binding' => 'urn:oasis:names:tc:SAML:1.0:profiles:artifact-01',
'Location' => 'http://sistema1.levelplus.com.br/simplesaml/module.php/saml/sp/saml1-acs.php/wso2-
sp/artifact',
'index' => 3,
),
4 =>
array (
'Binding' => 'urn:oasis:names:tc:SAML:2.0:profiles:holder-of-key:SSO:browser',
'Location' => 'http://sistema1.levelplus.com.br/simplesaml/module.php/saml/sp/saml2-acs.php/wso2-sp',
'index' => 4,
),
),
'SingleLogoutService' =>
array (
0 =>
array (
'Binding' => 'urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect',
'Location' => 'http://sistema1.levelplus.com.br/simplesaml/module.php/saml/sp/saml2-logout.php/wso2-
sp',
),
),
);
123
APÊNDICE 2 - TELAS DO IDP APRESENTADAS NA APLICAÇÃO DOS
CASOS DE TESTE
1 - Telas apresentadas na aplicação do caso de teste CT 01 - Cadastro de serviços
Figura 1: Tela de autenticação do IdP
Figura 2: Tela inicial do módulo administrativo do IdP
124
Figura 3: Tela do formulário de cadastro de serviço
Figura 4: Tela de retorno do serviço cadastrado no IdP
125
Figura 5: Tela de retorno dos Metadados recarregados no IdP
2 - Telas apresentadas na aplicação do caso de teste CT 02 - Alteração de dados do serviço
Figura 6: Tela inicial do módulo administrativo do IdP
126
Figura 7: Tela da lista dos serviços cadastrados
Figura 8: Tela do formulário do serviço alterado
127
Figura 9: Tela de confirmação de alteração do serviço
3 - Telas apresentadas na aplicação do caso de teste CT 03 - Cadastro de Administrador da
Instituição
Figura 10: Tela inicial do IdP, com acesso ao submenu Novo Adm de Instituição
128
Figura 11: Tela do formulário de cadastro de Administrador da Instituição
Figura 12: Tela de confirmação do cadastro de Administrador da Instituição
129
4 - Telas apresentadas na aplicação do caso de teste CT 04 - Alteração dos dados do
Administrador da Instituição
Figura 13: Tela inicial do módulo administrativo do IdP - Lista de usuários
Figura 14: Tela de cadastro do administrativo da instituição
130
Figura 15: Tela de confirmação da alteração dos dados do administrador da instituição.
5 - Telas apresentadas na aplicação do caso de teste CT 05 - Cadastro de Colaborador
Figura 16: Tela inicial do IdP, no perfil Administrador da Instituição
131
Figura 17: Tela do formulário de cadastro de Colaborador
Figura 18: Tela de confirmação do cadastro de Colaborador
132
6 - Telas apresentadas na aplicação do caso de teste CT 06 - Alteração dos dados do Colaborador
pelo Administrador da Instituição
Figura 19: Tela de inicial do perfil Administrador da Instituição.
Figura 20: Tela da listagem dos colaboradores cadastrados na instituição.
133
Figura 21: Tela do formulário dos dados do colaborador cadastrado para alteração.
Figura 22: Tela de confirmação da alteração dos dados do colaborador.
134
7 - Telas apresentadas na aplicação do caso de teste CT 07 - Alteração de senha obrigatória no
primeiro acesso
Figura 23: Tela de autenticação no IdP.
Figura 24: Tela de alteração de senha.
135
Figura 25: Tela inicial do perfil colaborador no IdP.
Figura 26: Tela do protótipo do serviço Gerenciador do Portal Municipal.
136
8 - Telas apresentadas na aplicação do caso de teste CT 08 - Desativar usuário colaborador
Figura 27: Tela inicial do perfil colaborador no IdP (submenu Serviços do Município).
Figura 28: Tela da listagem de serviços vinculadas ao município.
Figura 29: Tela de gerenciamento de membros dos serviços do município.
137
Figura 30: Tela com a mensagem que o colaborador não é usuário do serviço.
9 - Telas apresentadas na aplicação do caso de teste CT 09 - Alteração dos dados pelo
colaborador
Figura 31: Tela de alteração de dados do colaborador.
138
Figura 32: Tela do submenu para alteração de senha.
10 - Telas apresentadas na aplicação do caso de teste CT 10 - Teste de autenticação SSO
Figura 33: Tela inicial do protótipo de serviço Gerenciador do Portal Municipal.
139
Figura 34: Tela inicial do protótipo de serviço Gerenciador do Portal de Turismo.
11 - Telas apresentadas na aplicação do caso de teste CT 11 - Teste de usuário inválido e
recuperação de senha
Figura 35: Tela com a mensagem de usuário ou senha incorretos.
140
Figura 36: Tela de solicitação de recuperação de senha.
Figura 37: Tela com a mensagem de solicitação de recuperação de senha encaminhada.
Figura 38: Tela de alteração de senha via link encaminhado para o e-mail do usuário.
141
12 - Telas apresentadas na aplicação do caso de teste CT 13 - Monitoramento transferência de
dados
Figura 39: Informações do certificado de segurança utilizado no IdP.
Figura 40: Log de requisições na porta 443 (ssl).
142
13 - Telas apresentadas na aplicação do caso de teste CT 14 - Acesso negado ao serviço que não
pertence ao círculo de confiança do IdP.
Figura 41: Mensagem de erro de metadado (serviço não configurado no IdP)
143
APÊNDICE 3 - ROTEIROS DA PESQUISA DE SATISFAÇÃO
Texto de apresentação dos formulários da pesquisa de satisfação:
Caros (a) Avaliador (a),
Primeiramente, agradeço por ter aceito participar deste processo de avaliação do protótipo do Sistema
de Gerenciamento de Identidades para a Rede Catarinense de Informações Municipais (RedeCIM).
Este trabalho está sendo desenvolvido pelo aluno de graduação Emerson Souto sob a orientação da
Prof. Michelle Wangham (UNIVALI - Ciências da Computação), com o apoio da Federação
Catarinense de Municípios (FECAM) e do Consórcio de Informática na Gestão Pública Municipal
(CIGA)
* Utilize um computador Desktop ou um Notebook para realizar o experimento, e que tenha instalado
Sistema Operacional e Navegador Web nas suas versões mais recentes.
Os objetivos do IdP são:
1 - Aperfeiçoar o processo de gestão dos usuários da RedeCIM;
2 - Permitir o gerenciamento dos usuários dos sistemas integrados à RedeCIM em um único sistema
chamado de Provedor de identidades (IdP);
3 - Facilitar o processo de autenticação dos usuários da RedeCIM;
4 - Possibilitar o acesso aos sistemas autorizados por meio de autenticação única (Single Sign On-
SSO);
5 - Disponibilizar um canal seguro para autenticação dos usuários da RedeCIM;
O foco desta avaliação é o uso do IdP no perfil do administrador IdP, que são os usuários responsáveis
por liberar o acesso aos administradores dos usuários dos municípios.
O tempo total para a realização do experimento e da avaliação é de aproximadamente 15 minutos.
Segue o roteiro com os passos para execução do experimento.
144
Roteiro da pesquisa aplicada aos avaliadores do perfil Administrador IdP:
Para iniciar a avaliação você precisa seguir os passos.
1 - Acesse o Provedor de Identidades (IdP) e siga as instruções:
* Endereço do sistema: https://idp.levelplus.com.br
2 - Se autentique no sistema com os dados de login indicados a seguir:
* Usuário: admin
* Senha: fecam
3 - Após efetuar a autenticação no IdP, o sistema estará disponível para gerenciar usuários
administradores das instituições e os serviços (SPs) disponibilizados na RedeCIM. Neste momento,
você poderá escolher qual ação deseja executar no sistema indicado no menu.
4 - Para avaliar as funcionalidades do cadastro de administradores das instituições você deve acessar a
aba Pessoas e executar as funções de cadastro e alteração dos dados do administrador da instituição*
* O Administrador da Instituição é o usuário do município ou da associação de município que gerencia
os usuários da sua instituição.
5 - Após cadastrar um administrador, favor verificar se o mesmo esta cadastrado na lista de usuários.
- Para verificar os usuários cadastrados em cada município, basta clicar na aba Municípios/Lista
6 - Para avaliar as funcionalidades do cadastro de serviços, basta clicar nas funções da aba
Serviços/Cadastro.
7- Para concluir o cadastro de serviços é necessário disponibilizar para o IdP e para um serviço os
metadados* que possibilitam a troca de informações entre estes.
* Metadados é o código que define as regras de negócio em XML para possibilitar as transações entre
o IdP e o Serviço.
O metadado do IdP está disponível no menu Serviços/Metadados do IdP. Para avaliar o sistema, os
metadados de um serviço foi definido para que o administrador do IdP possa cadastrá-lo no provedor e
145
assim estabelecer a relação de confiança com este serviço. A avaliação desta etapa deve seguir os
seguintes passos:
a) Primeiro você deve sair do IdP clicando no menu "sair" a direita do cabeçalho do sistema.
b) Acesse o serviço http://sistema2.levelplus.com.br/ com os seguintes dados para login.
Usuário: Número do seu CPF
Senha: fecam
Observe que não foi possível acessar o serviço pois o serviço em questão ainda não está no círculo de
confiança do IdP, ou seja, o metadado do serviço ainda não foi configurado no IdP. Para fazer isto,
siga os passos a seguir.
c) Acesse novamente o IdP: https://idp.levelplus.com.br
* Usuário: admin
* Senha: fecam
d) Acesse o cadastro de serviços no menu Serviços/lista e editar o serviço: Gerenciador Portal de
Turismo - http://sistema2.levelplus.com.br
No campo Metadata, remova o # e insira o metadata do serviço disponível em:
http://sistema2.levelplus.com.br/metadados.php
Obs: Copie e cole sem modificar o conteúdo (observe se o navegador esta traduzindo o texto), pois o
mesmo dever ser o original, sem tradução. SALVE a edição do serviço.
e) Recarregue os metadados do IdP clicando no botão indicado na tela Lista Serviços.
f) Saia novamente do IdP clicando no menu "sair" a direita do cabeçalho do sistema.
g) Acesse novamente o serviço com os dados do passo "b" e verifique se o mesmo esta acessível por
meio do IdP. Ou seja, se o usuário é redirecionado para página de autenticação do IdP.
h) Saia novamente do IdP clicando no menu "sair" a direita do cabeçalho do sistema.
146
8 - Para finalizar o experimento, Acesse novamente o IdP: https://idp.levelplus.com.br
* Usuário: admin
* Senha: fecam
9 - Acesse o cadastro de serviços no menu Serviços/lista e editar o serviço: Gerenciador Portal de
Turismo - http://sistema2.levelplus.com.br
* No campo Metadata, remova o metadata e insira o carácter #, SALVE a edição do serviço.
10 - Recarregue os metadados do IdP clicando no botão indicado na tela Lista Serviços para retornar
ao formato inicial do experimento.
Após os passos descritos acima, por favor, preencha o formulário de avaliação. (O questionário
aplicado aos avaliadores está disponível no Apêndice 3)
Roteiro da pesquisa aplicada aos avaliadores do perfil Administrador da Instituição:
Para iniciar a avaliação você precisa seguir os passos.
1 - Acesse o sistema de Gerenciamento de identidades (IdP) e siga as instruções:
* Endereço do sistema: https://idp.levelplus.com.br
2 - Realize o login utilizando as informações abaixo para se autenticar no sistema.
* Usuário: Número do seu CPF
* Senha: fecam
3 - Ao tentar se autenticar o sistema deverá solicitar a alteração da senha pelo usuário.
4 - Após alterar a senha o sistema solicitará que o usuário se autentique novamente pelo endereço:
https://idp.levelplus.com.br
* Usuário: Número do seu CPF
147
* Senha: "senha que você alterou"
5 - Após efetuar a autenticação no IdP, o sistema estará disponível para cadastrar colaboradores, alterar
seu cadastro, alterar sua senha e relacionar usuários a serviços. Neste momento, você poderá escolher
qual ação deseja executar no sistema clicando nas abas do menu superior.
6 - Para avaliar a funcionalidade do cadastro de colaboradores, você deve acessar o submenu Novo
Colaborador da aba Pessoas;
7 - Após cadastrar o colaborar verificar na listagem de pessoas se o colaborador foi cadastrado;
Clicando na aba Pessoas/Lista
8 - Para vincular e desvincular colaboradores dos serviços que foram selecionados, deve-se clicar na
aba Serviços/Serviços do Município e acessar a opção gerenciar do serviço que deseja editar.
9 - Para avaliar a funcionalidade alteração de senha basta clicar no submenu Alteração de Senha da aba
Pessoas;
10 - Saia do IdP clicando no menu "sair" a direita do cabeçalho do sistema.
11 - Recupere a senha clicando no link "Esqueci minha senha" disponível no formulário de login no
Endereço do sistema: https://idp.levelplus.com.br
* O IdP encaminhará a senha para o seu e-mail cadastrado.
12 - Saia do IdP clicando no menu "sair" a direita do cabeçalho do sistema.
Após os passos descritos acima, por favor, preencha o formulário de avaliação. (O questionário
aplicado aos avaliadores está disponível no Apêndice 3)
Roteiro da pesquisa aplicada aos avaliadores do perfil Colaborador:
Para iniciar a avaliação você precisa seguir os passos.
1 - Acesse o IdP e siga as instruções:
* Endereço do sistema: https://idp.levelplus.com.br
148
2 - Realize o login utilizando as informações abaixo para se autenticar no sistema.
* Usuário: Número do seu CPF
* Senha: fecam
3 - Ao tentar se autenticar o sistema deverá solicitar a alteração da senha pelo usuário.
4 - Após alterar a senha o sistema solicitará que o usuário se autentique novamente pelo endereço:
https://idp.levelplus.com.br
* Usuário: Número do seu CPF
* Senha: "senha que você alterou"
5 - Após efetuar a autenticação no IdP, o sistema estará disponível para alterar os atributos órgão e
telefone, alterar senha e acessar a listagem dos serviços que o colaborador possuí acesso.
6 - Para avaliar a funcionalidade de alteração de atributos, basta acessá-lo pelos submenus da aba
Pessoas/Meu Cadastro;
7 - Para avaliar a funcionalidade de alteração de senha, basta clicar no submenu da Pessoas/Alteração
de senha;
8 - Para avaliar se esta disponível o acesso a outro serviço sem a necessidade de nova autenticação,
basta acessar o serviço que você está vinculado pelo endereço: Gerenciador Portal Municipal:
http://sistema1.levelplus.com.br/
9 - Saia do IdP clicando no menu "sair" a direita do cabeçalho do sistema.
10 - Recupere a senha clicando no link "Esqueci minha senha" disponível no formulário de login no
Endereço do sistema: https://idp.levelplus.com.br
* O IdP encaminhará a senha para o seu e-mail cadastrado.
11 - Saia do IdP clicando no menu "sair" a direita do cabeçalho do sistema.
Após os passos descritos acima, por favor, preencha o formulário de avaliação. (O questionário
aplicado aos avaliadores está disponível no Apêndice 3)
149
APÊNDICE 4 - CORPO DO E-MAIL DA PESQUISA
Caro Profissional,
Gostaríamos de contar com sua colaboração para avaliar um Sistema Gerenciador de Identidades (IdP)
voltado para os sistemas disponibilizados pela Federação Catarinense de Municípios (FECAM) e o
Consórcio de Informática na Gestão Pública Municipal (CIGA). Este trabalho foi desenvolvido no
contexto de um projeto de graduação e no momento está em fase de avaliação.
O experimento deve tomar cerca de 15 minutos do seu tempo.
Você deverá acessar o IdP e executar as funcionalidades do sistema e em seguida, responder a uma
pesquisa de satisfação. O questionário abrange a avaliação do IdP, bem como um breve levantamento
técnico sobre seu conhecimento nos assuntos que norteiam essa pesquisa.
Para ler as instruções de acesso e iniciar o processo de avaliação acesse o link a seguir:
(Observação: para cada perfil o endereço do formulário da pesquisa foi alterado)
Endereço do formulário para o perfil Administrador IdP:
https://docs.google.com/forms/d/1Qu9Uc3-FyU0ImJ-bOGLm4uKL49hzFVfiaWlrV-n0iZg/viewform
Endereço do formulário para o perfil Administrador da Instituição:
https://docs.google.com/forms/d/1EdTQ6zMKPBQC4Me5EELNB_9ReNeOmFQRKS7rJQVMM2g/v
iewform
Endereço do formulário para o perfil Colaborador:
https://docs.google.com/forms/d/17uGPZrGNxdIaURQnvOIS549JrUxZzUnPAGwpBTCNvzs/viewfor
m
Sua colaboração é muito importante.
Atenciosamente
Emerson Souto
Michelle S. Wangham (orientadora)
UNIVALI - Universidade do Vale do Itajaí
Contato: (48) 3221 8800 - 9968 9574
150
APÊNDICE 5 - COMPILAÇÃO DAS RESPOSTAS
Resultado das perguntas sobre o perfil do avaliador:
Tabela 1: Respostas da Pergunta 1.
1. Para qual instituição/município você é vinculado?
Respostas por Perfil do Usuário Total de
Respostas Administrador
IdP
Administrador
Instituição Colaborador
FECAM 3 4 14 21
CIGA 2 3 1 6
Associações de Municípios 11 3 14
Total de Respostas Por perfil de Usuário 5 18 18 41
Tabela 2: Respostas da Pergunta 2.
2. Qual é a sua área de atuação na
instituição/município?
Respostas por Perfil do Usuário Total de
Respostas Administrador
IdP
Administrador
Instituição Colaborador
Tecnologia da Informação 5 12 4 21
Administração 3 8 11
Outras 3 6 9
Total de Respostas Por perfil de Usuário 5 18 18 41
Tabela 3: Respostas da Pergunta 3.
3. Quantos sistemas da RedeCIM você é o responsável
por gerenciar usuários ou é usuário de algum serviço?
Respostas por Perfil do Usuário Total de
Respostas Administrador
IdP
Administrador
Instituição Colaborador
1 sistema 3 4 7
Entre 1 e 5 sistemas 3 7 10 20
Acima de 5 sistemas 2 8 4 14
Total de Respostas Por perfil de Usuário 5 18 18 41
Tabela 4: Respostas da Pergunta 4.
4. A quantos anos você atua neste papel?
Respostas por Perfil do Usuário Total de
Respostas Administrador
IdP
Administrador
Instituição Colaborador
Menos de 1 ano 2 2 7 11
Entre 1 e 5 anos 1 7 6 14
Acima de 5 anos 2 9 5 16
Total de Respostas Por perfil de Usuário 5 18 18 41
151
Tabela 5: Respostas da Pergunta 5.
5. Você sabe o que são provedores de identidade (IdP -
Indentity Provider)?
Respostas por Perfil do Usuário Total de
Respostas Administrador
IdP
Administrador
Instituição Colaborador
Sim 5 15 7 27
Não 0 3 11 14
Total de Respostas Por perfil de Usuário 5 18 18 41
Tabela 6: Respostas da Pergunta 6.
6. Você conhece o conceito de autenticação SSO?
Respostas por Perfil do Usuário Total de
Respostas Administrador
IdP
Administrador
Instituição Colaborador
Sim 4 9 4 17
Não 1 9 14 24
Total de Respostas Por perfil de Usuário 5 18 18 41
Tabela 7: Respostas da Pergunta 7.
7. Você conhece o conceito de autenticação
Centralizada?
Respostas por Perfil do Usuário Total de
Respostas Administrador
IdP
Administrador
Instituição Colaborador
Sim 5 11 9 25
Não 0 7 9 16
Total de Respostas Por perfil de Usuário 5 18 18 41
Tabela 8: Respostas da Pergunta 8.
8. Você conhece o conceito de autenticação Federada?
Respostas por Perfil do Usuário Total de
Respostas Administrador
IdP
Administrador
Instituição Colaborador
Sim 3 9 12
Não 2 9 11
Total de Respostas Por perfil de Usuário 5 18 0 23
* Pergunta não realizadas aos avaliadores do perfil colaborador
152
Tabela 9: Respostas da Pergunta 9.
9. Qual sistema operacional você esta utilizando para
executar este experimento?
Respostas por Perfil do Usuário Total de
Respostas Administrador
IdP
Administrador
Instituição Colaborador
Windows 4 15 12 31
Ubunto 1 2 3
Linux 2 2
Não soube responder 1 4 5
Total de Respostas Por perfil de Usuário 5 18 18 41
Tabela 10: Respostas da Pergunta 10.
10. Qual navegador web você esta utilizando para
executar esse experimento?
Respostas por Perfil do Usuário Total de
Respostas Administrador
IdP
Administrador
Instituição Colaborador
Google Chrome 5 16 16 37
Mozila Firefox 0 1 2 3
Internet Explorer 0 1 0 1
Safari 0 0 0 0
Opera 0 0 0 0
Outros 0 0 0 0
Total de Respostas Por perfil de Usuário 5 18 18 41
Resultado das perguntas sobre a satisfação do usuário no uso do IdP:
Tabela 11: Respostas da Pergunta 11.
11. Você conseguiu executar com sucesso todos os
passos descritos no roteiro do experimento?
Respostas por Perfil do Usuário Total de
respostas Administrador
IdP
Administrador
Instituição Colaborador
Sim 4 17 17 38
Não 1 1 1 3
Total de Respostas Por perfil de Usuário 5 18 18 41
Caso você não tenha executado com sucesso todos os passos, identifique o(s) passo (s) e descreva o problema.
Não tive problemas, apenas quando fui no item "recuperar senha" e digitei o CPF, o sistema acabou puxando dados
que estavam gravados e possuía pontos entre os números.
Mais há uma mensagem clara dizendo que são apenas números. Usuário/CPF (Apenas números)
1) Ao selecionar um usuário para vincular com o serviço, fui direcionado para uma pagina de erro do navegador. Na
segunda tentativa o procedimento foi realizado com sucesso.
153
Tabela 12: Respostas da Pergunta 12.
12. Foi necessário cancelar a execução de algum
serviço e iniciar novamente?
Respostas por Perfil do Usuário Total de
respostas Administrador
IdP
Administrador
Instituição Colaborador
Não 4 14 17 35
Sim 1 4 1 6
Total de Respostas Por perfil de Usuário 5 18 18 41
Tabela 13: Respostas da Pergunta 13.
13. As mensagens de erros, caso tenham ocorrido,
foram suficientes para apontar o problema?
Respostas por Perfil do Usuário Total de
respostas Administrador
IdP
Administrador
Instituição Colaborador
Sim 4 11 5 20
Parcialmente 0 3 3 6
Não 0 0 1 1
Não se aplica 1 4 9 14
Total de Respostas Por perfil de Usuário 5 18 18 41
Tabela 14: Respostas da Pergunta 14.
14. No seu ponto de vista, a apresentação das
informações está legível (claras e compreensíveis) ?
Respostas por Perfil do Usuário Total de
respostas Administrador
IdP
Administrador
Instituição Colaborador
Sim 4 15 12 31
Parcialmente 1 3 5 9
Não 0 0 1 1
Total de Respostas Por perfil de Usuário 5 18 18 41
Tabela 15: Respostas da Pergunta 15.
15. Os serviços reagiram rapidamente as suas
ações?
Respostas por Perfil do Usuário Total de
respostas Administrador
IdP
Administrador
Instituição Colaborador
Sim 5 18 14 37
Parcialmente 0 0 4 4
Não 0 0 0 0
Total de Respostas Por perfil de Usuário 5 18 18 41
Tabela 16: Respostas da Pergunta 16.
16. Você em algum momento não soube o que
fazer?
Respostas por Perfil do Usuário Total de
respostas Administrador
IdP
Administrador
Instituição Colaborador
Não 2 15 12 29
Sim 3 3 6 12
Total de Respostas Por perfil de Usuário 5 18 18 41
154
Tabela 17: Respostas da Pergunta 17.
17. Você compreendeu as funções do IdP acessadas
no experimento?
Respostas por Perfil do Usuário Total de
respostas Administrador
IdP
Administrador
Instituição Colaborador
Sim 5 16 14 35
Não 0 2 4 6
Total de Respostas Por perfil de Usuário 5 18 18 41
Caso você não tenha compreendido alguma função, favor listar quais não foram compreendidas.
Quando sair da fase experimental poderia ter um pouco mais de mensagens para os erro dos usuários, tipo tentei
cadastrar um outro usuário com o meu CPF, não deu erro, mas, também não cadastrou. Um dos serviços acessados,
no link voltar da erro ao retornar deve ser um pequeno ajuste.
Não compreendi o objetivo final do IdP, precisa maiores informações para quem não é da área e é leigo no assunto.
Tabela 18: Respostas da Pergunta 18.
18. Na sua opinião, o gerenciamento de usuários
pode ser realizado com maior rapidez utilizando
um sistema centralizado como o IdP? *
Respostas por Perfil do Usuário Total de
respostas Administrador
IdP
Administrador
Instituição Colaborador
Sim 4 15 19
Não 0 0 0
Sem opinião formada 1 3 4
Total de Respostas Por perfil de Usuário 5 18 0 23
* Pergunta não realizadas aos avaliadores do perfil colaborador
Tabela 19: Respostas da Pergunta 19.
19. Na sua opinião, um sistema de gerenciamento
de identidades, como o que você testou. que provê a
autenticação única de usuários e possibilita o
acesso a diversos serviços sem a necessidade de
nova autenticação, trará mais flexibilidade para os
serviços utilizados pela sua instituição?
Respostas por Perfil do Usuário
Total de
respostas Administrador
IdP
Administrador
Instituição Colaborador
Sim 5 16 15 36
Não 0 0 1 1
Sem opinião formada 0 2 2 4
Total de Respostas Por perfil de Usuário 5 18 18 41
Comentários:
155
Flexibilidade trará com certeza, mas deve-se ter muito cuidado no processamento das informações, segurança e
confiabilidade do sistema.
Esse sistema de gerenciamento de identidades torna mais rápido e agil a realização das atividades necessárias
realizadas pela instituição, o que é de suma importância dentro de um orgão que lide com tais aspectos.
Ficaria uma forma mais centralizada de autenticação, portanto gerando mais organização e controle dos usuários.
Hoje temos na instituição oferece muitos serviços e cada um com uma autenticação. Gerenciar todas essas
identidades com em um sistema só seria um avanço.
A ferramenta é muito útil pois facilitará o processo num todo, sem necessidade de novos acessos com pedidos de
login e senhas, gostei muito, não conhecia essa ferramenta e ela aplicada nos sistemas públicos principalmente nos
portais da FECAM será de grande valia.
Pois o usuário não necessita lembrar de diversas senhas, basta lembrar de uma.
Tabela 20: Respostas da Pergunta 20.
20. Na sua opinião, o modelo de autenticação
centralizada no IdP traz maior segurança?
Respostas por Perfil do Usuário Total de
respostas Administrador
IdP
Administrador
Instituição Colaborador
Sim 4 13 12 29
Não 0 1 1 2
Sem opinião formada 1 4 5 10
Total de Respostas Por perfil de Usuário 5 18 18 41
Comentários:
Quanto maior o número de senhas mais complicado fica de guardar a senha.
Existe maior segurança no processo de login pois os sistemas passam a ter apenas um ponto convergente para essa
ação, entretanto um ataque de negação de serviço ao provedor IDP deixaria todos os SP's indisponíveis.
Acredito que não pois se algum intruso descobrir essa única senha, terá acesso a todos os sistemas participantes.
Sim porque é mais fácil o usuário criar e lembrar de uma única senha mais elaborada (com caracteres especiais, etc)
do que varias senhas mais simples (Ex data de nascimento).
Facilita muito o trabalho, mas não necessariamente trará maior segurança. Tudo dependerá da segurança e
confiabilidade do sistema.
Tabela 21: Respostas da Pergunta 21.
156
21. Você gostaria de utilizar o IdP para a gestão
dos usuários dos serviços disponibilizados pela
FECAM as instituições? - 20. Você gostaria de
utilizar o IdP para a autenticação e acesso aos
serviços disponibilizados pela FECAM/CIGA?
Respostas por Perfil do Usuário
Total de
respostas Administrador
IdP
Administrador
Instituição Colaborador
Sim 2 16 14 32
Não 0 0 1 1
Sem opinião formada 3 2 3 8
Total de Respostas Por perfil de Usuário 5 18 18 41
Tabela 22: Respostas da Pergunta 22.
22. Na sua opinião, para os administradores das
instituições integradas (municípios e associações de
municípios), o uso do IdP facilitaria o processo de
gestão de usuários e traria maior satisfação aos
clientes? *
Respostas por Perfil do Usuário
Total de
respostas Administrador
IdP
Administrador
Instituição Colaborador
Sim 4 18 22
Não 0 0 0
Sem opinião formada 1 0 1
Total de Respostas Por perfil de Usuário 5 18 0 23
* Pergunta não realizadas aos avaliadores do perfil colaborador
Tabela 23: Respostas da Pergunta 23.
23. O que você achou melhor do experimento que você executou? Por quê?
Acesso mais rapidamente aos sistemas.
Apenas um login acessa várias ferramentas
Facilidade em deliberar acesso a determinado sistema. Melhor controle.
O melhor é ter acesso a todos os sistemas sem precisar ficar lembrando usuário e senha de cada um deles.
Facilidade e simplicidade de cadastro.
Muito bom , gera maior segurança para o usuario
As informações solicitadas eram breves e claras e o processo muito rápido.
O ponto principal é a questão da unificação das senhas e a facilidade de gerenciamento.
O sistema, permite um entendimento claro dos conceitos de funcionamento do modelo IdP, porque contempla os
eixos principais da solução.
Porque gera um maior controle em cima no que tange administração de usuários.
Gostei pela segurança e praticidade que a ferramenta oferece.
Imaginar todos os usuários num único login
157
Facilidade de uso, porque pelo breve período que utilizei o sistema ele me pareceu bem claro, simples de usar e fácil
de cadastrar novos usuários.
Fazer login apenas uma vez
Ache o experimento bastante dinâmico, visto que é possível efetuar o cadastro do usuário uma única vez e gerenciar
o acesso do mesmo a vários sistemas.
Possibilidade de utilizar uma única senha para diversos sistemas evita o hábito de repetir a senha para sistemas
diferentes afim de evitar esquecimento, tornando o acesso a estes sistemas mais vulnerável.
A centralização de acessos para vários sistemas com apenas um login e senha. Facilita a vida do usuário na questão
de criação de senhas (uma só apenas) assim como também traz mais agilidade no uso dos sistemas.
Visão ampla dos serviços disponíveis a partir do login/senha único
A idéia
Acho muito prático ter uma única senha para acessar todos os programas.
Achei o procedimento bem simples.
A facilidade em executar o login. O rápido envio da senha, visto que em outras situações já identifiquei a demora no
envio da nova senha, trazendo problemas.
O facil acesso das informações a respeito do profissional.
Sua página, por apresentar características simples, promove a rapída pesquisa, sem demora no processo de
carregamento de informações.
O melhor foi salvar e não ter dado nenhum erro!
A conexão segura
A facilidade no acesso, a possibilidade de recuperar senha.
Tabela 24: Respostas da Pergunta 24.
24. Você tem algum comentário adicional sobre o IdP? (sugestões e críticas)
A priore não teria um sugestão, mas posso analisar melhor caso eu tenha alguma lhe encaminho.
Muito bom
A literatura e estudos do tema , deixa algumas questões em aberto, citando vantagens e desvantagem em relação ao
modelo " tradicional".
Na minha opinião uma das questões mais relevantes, trata do entendimento do usuário final da aplicação, que parece
ser o elo mais frágil e vulnerável.
No acesso centralizado a diversos sistemas e dados poderia forçar o usuário a pensar que toda informação tratada
pelos serviços/sistemas estejam interligadas, gerando um uso moderado dos recursos, causando talvez até
insegurança.
Bom vai aqui meus parabéns pelo trabalho, e espero que seja o primeiro grande passo para uso dessa aplicação.
Tenho como sugestão acrescentar e aprimorar a ferramenta para os deficientes audiovisuais, ou seja, oferecer o
recurso incluindo essas pessoas que estão em nosso meio e que possam estar utilizando essa ferramenta de grande
valia e com segurança e praticidade.
- Na parte de gerenciamento de usuários, a mensagem que está abaixo poderia aparecer quando passasse o mouse
sobre os botões de opção (+) e (-)
158
Seria legal implementar redundância no idp
Para fins de controle seria interessante que o sistema permitisse a visualização do administrador que efetuou a
liberação do acesso ao serviço para determinado colaborador. Isto porque, acredito eu, haverá mais um de um
administrador com permissão para liberar acessos de colaboradores no mesmo sistema.
Acho que o sistema deveria exigir a gravação de senhas com números e letras diferentes da senha
quero ver a instituição aplicar a medida sem embaraços
Ao mesmo tempo que é interessante e prático ter uma única senha de acesso, acho que o risco de clonar ou de dar
algum problema é muito maior.
Apenas o cuidado com as informações e senhas dos usuários. Como mencionei acima, tudo dependerá do grau de
segurança do sistema. No mais acho uma excelente idéia e facilita o trabalho tornando mais ágil.
Como não conheço as terminologias da tecnologia tive dificuldades de compreender algumas questões.
