UNIVERSIDADE LICUNGO

FACULDADE DE CIÊNCIAS E TECNOLOGIA

LICENCIATURA EM INFORMÁTICA

4º Ano

Dário Gildo de Carvalho

Mercito Francisco Armando Ordem
Mildo Álvaro António Sortane
Sualé Mussa Francisco

Sistemas de Autenticação

3º Grupo

Quelimane
2022
 Dário Gildo de Carvalho
Mercito Francisco Armando Ordem
Mildo Álvaro António Sortane
Sualé Mussa Francisco

Sistemas de Autenticação

3º Grupo

Trabalho de Caracter avaliativo a ser

entregue no Departamento de Ciências e
Tecnologias na Cadeira de Segurança
Informática, lecionada pelo:

Msc. Beldo Mario

Quelimane
2022
Índice
1. INTRODUÇÃO ....................................................................................................................... 4
1.1. Objectivos ................................................................................................................................. 4
1.1.1. Geral ...................................................................................................................................... 4
1.1.2. Objectivos Específicos .......................................................................................................... 4
1.2. Metodologia do Projecto .......................................................................................................... 4
2. SISTEMAS DE AUTENTICAÇÃO ........................................................................................ 5
2.1. OBJECTIVO ..................................................................................................................... 5
2.2. COMPONENTES LÓGICOS DE UM SISTEMA DE AUTENTICAÇÃO (AAA) ........ 5
2.3. AUTENTICAÇÃO ........................................................................................................... 6
2.4. AUTORIZAÇÃO .............................................................................................................. 8
2.5. CONTABILIZAÇÃO ....................................................................................................... 9
2.6. PROTOCOLOS DE AAA ................................................................................................ 9
2.6.1. CLIENTE PEP........................................................................................................... 9
2.6.1.1. PPP E PPPoE ......................................................................................................... 9
2.6.1.2. VPN IPsec E SSL/TLS ........................................................................................ 10
2.6.2. PEP-PDP.................................................................................................................. 10
2.6.2.1. RADIUS............................................................................................................... 10
2.6.2.2. TACACS+ ........................................................................................................... 10
2.6.2.3. DIAMETER ......................................................................................................... 10
2.6.3. CLIENTE-PDP ........................................................................................................ 10
2.6.4. PDP-PIP ................................................................................................................... 11
2.7. REPOSITÓRIO DE CREDENCIAIS DE AUTENTICAÇÃO ...................................... 11
2.7.1. LIGHTWEIGHT DIRECTORY ACCESS PROTOCOL (LDAP) ......................... 11
2.7.2. MODELO CLIENTE-SERVIDOR LDAP .............................................................. 12
2.7.3. ELEMENTOS DO DIRECTÓRIO ......................................................................... 13
2.8. PROTOCOLOS DE ACESSO AO REPOSITÓRIO ...................................................... 13
2.8.1. LDAP ....................................................................................................................... 13
2.8.1.1. CLIENTE LINUX ............................................................................................... 14
2.8.1.2. CLIENTE APPLE MACOS ................................................................................ 15
2.8.1.3. CLIENTE MICROSOFT WINDOWS ................................................................ 15
2.8.2. RADIUS .................................................................................................................. 16
2.9. EXEMPLO DE UTILIZAÇÃO DE SERVIÇO DE AUTENTICAÇÃO ....................... 17
2.10. REDUNDÂNCIA E ESCALABILIDADE ................................................................. 17
2.10.1. REPLICAR O DIRECTÓRIO ................................................................................. 18
2.10.2. REPARTIR O DIRECTÓRIO ................................................................................. 18
2.10.3. REDUNDÂNCIA RADIUS .................................................................................... 18
2.10.4. Expansão da Solução ............................................................................................... 18
2.11. OUTRAS ALTERNATIVAS ..................................................................................... 19
2.11.1. KERBEROS ............................................................................................................ 19
2.11.2. MICROSOFT ACTIVE DIRECTORY ................................................................... 20
2.11.3. SHIBBOLETH SYSTEM ....................................................................................... 20
3. CONCLUSÃO ....................................................................................................................... 21
4. REFERÊNCIA BIBLIOGRÁFICA ....................................................................................... 22
 4

1. INTRODUÇÃO

O presente trabalho tem como tema, Sistemas de Autenticação. Onde estes são encontrados em
diversos computadores e sistemas para melhor controlo no acesso das informações de clientes ao
tentar ter acesso a seus dados e informações. Na mesma sequência iremos descrever todos
elementos que compõem os sistemas de autenticação. Definindo cada um, descrevendo alguns
componentes e suas funcionalidades dentro de diversos sistemas e plataformas. Seja no Apple,
Linux e no Microsoft Windows.

1.1. Objectivos
1.1.1. Geral
 Compreender a camada de aplicação.
1.1.2. Objectivos Específicos
 Debruçar sobre os principais conceitos da camada de aplicação;
 Distinguir os protocolos da camada de aplicação;
 Apontar a forma de funcionamento de cada protocolo de comunicação.

1.2. Metodologia do Projecto

Metodologia é o caminho do pensamento e a prática exercida na abordagem da realidade
(MINAYO, 1996:16), ou seja, disciplina que se ocupa de estudar e ordenar (no possível) e em
conformidade com COHN, (1992), realça que a metodologia é o caminho pelo qual fazemos algo,
de maneira a atingir um objectivo; é a base mental para o exercício de uma actividade que se
deseja eficaz; exige a organização do conhecimento e experiências prévias
Para esta elaboração deste trabalho foi usado o método de revisão bibliográfica que
consistiu na leitura, análise e interpretação de informações contidas em várias literaturas que
abordam o tema em epígrafe. Neste processo de revisões bibliográficas, foi feita uma procura de
diferentes ferramentas para protocolos da camada de aplicac tendo-se procedido à comparação
entre elas.
Em seguida foram realizadas revisões de site com a finalidade de adquirir conhecimentos
básicos e específicos sobre a metodologia de desenvolvimento de projectos de web site.
 5

2. SISTEMAS DE AUTENTICAÇÃO
2.1. OBJECTIVO

O objectivo de qualquer sistema de Autenticação é permitir ao seu usuário ou usuários tomar as

providências necessárias para diminuir ou eliminar um perigo iminente.

2.2. COMPONENTES LÓGICOS DE UM SISTEMA DE AUTENTICAÇÃO (AAA)

Durante vários anos, um sistema de AAA era sinónimo de um sistema RADIUS. O papel que os
sistemas de AAA desempenham, neste contexto, e os novos requisitos de segurança para fazer
face a ameaças externas e internas necessitam de um modelo de AAA mais elaborado, que
permita enquadrar as múltiplas tecnologias de autenticação, autorização e contabilização,
independentemente da tecnologia da rede de acesso. Dentre os componentes lógicos referidos no
RFC 2904 que o modelo de referência adoptou são:

Onde:

 Cliente: Dispositivo que solicita acesso a um recurso, por exemplo, um computador

pessoal de um utilizador, numa rede cablada ou sem fios;
 Policy Enforcement Point (PEP): muitas vezes, identificado como autenticador ou NAS
(Network Acess Server), é o dispositivo onde é imposta uma política de acesso à rede (ou
 6

ao recurso). Um ponto de acesso de uma rede sem fios é um exemplo de um PEP, na

medida em que impõe ao cliente, o cumprimento de um conjunto de condições (utilização
de um protocolo seguro, credenciais de autenticação válidas) para lhe ser concebido
acesso à rede;
 Policy Information Point (PIP): reúne a informação necessária para possibilitar a decisão
de permitir ou rejeitar o acesso à rede. No mínimo, trata-se um repositório de credenciais
de autenticação de utilizadores, como um ficheiro /etc/passwd de um sistema Unix, ou
uma alternativa mais complexa, como um directório LDAP ou uma base de dados
racional;
 Policy Decision Point (PDP): é a entidade responsável pela tomada de decisão de
permitir ou rejeitar o acesso à rede, com base na informação fornecida pelo cliente
através do PEP e após consultar um ou mais PIP. Num cenário mais comum, trata-se de
um servidor de AAA que consulta um repositório de credencias de autenticação;
 Sistema de Contabilização (Accounting): trata-se de u componente autónomo ou
integrado no PDP que é utilizado para registar a utilização da rede, isto é, a identificação
do utilizador a quem foi concebido (ou rejeitado) acesso à rede, em que ponto da rede foi
feito o acesso, hora de inicio e fim da sessão.

2.3. AUTENTICAÇÃO

O processo de autenticação envolve um cliente que solicita acesso à rede ou aplicação, as

credencias de autenticação submetidas e, eventualmente, informação de contexto, isto é,
informação complementar que permite uma decisão mais selectiva, relativamente à decisão de
acesso. Cliente, Principal, Suplicante, ou mesmo utilizador, são designações para entidades
(utilizador, aplicação, serviço) que solicitam acesso a um recurso, cujos atributos são
armazenados no PIP. Para o caso de um utilizador, o PIP contém atributos como o username, a
password, o endereço de correio electrónico ou os grupos de utilizadores a que pertence e as
horas a que lhe é permitido acesso à rede ou aplicação. Todos estes atributos são acessíveis pelo
PDP.

As credencias de autenticação submetidas pelo cliente ao PDP como prova de identidade são,
normalmente =, enquadradas num dos seguintes tipos:
 7

 Chave partilhada (shared-key) é a situação mais comum em que a um identificador do

utilizador (username) está associada uma palavra-chave (password). A verificação da
password pode ser feita utilizando o Password Authentication Protocol (PAP), descrito no
RFC 1334, ou o Challenge Handshake Authentication Protocol (CHAP), descrito no RFC
1996. O PAP é um protocolo muito simples que transmite as passwords em ASCII, sem
qualquer cifra, devendo apenas ser utilizado, quando protegido por um túnel seguro. O
CHAP nunca transmite a password em claro; o cliente recebe um desafio (challenge) que
submete a uma funcao de hashing, baseada na sua password e devolve para autenticação.
O autenticador compara o hash recebido com o seu próprio hash, calculado com base no
desafio enviado e na password do cliente, que conhece. Se coincidirem, o utilizador é
considerado autenticado. Este processo é repetido periodicamente durante a comunicação.
O CHAP necessita que as passwords sejam armazenadas em claro. A Microsoft produziu
duas extensões de CHAP, designadas por MS-CHAPv1 e MS-CHAPv2, mais adaptadas
aos seus ambientes. Apesar de não transmitiras passwords em claro, o CHAP é vulnerável
a ataques baseados em dicionários que contêm um conjunto de possíveis passwords, a
partir das quais são gerados hashes;
 OTP (one-time password), em que um identificador (token), contido num cartão, é
utilizado para gerar aleatoriamente um código válido apenas para um único acesso. Este
processo é sincronizado com um servidor de tokens que desempenha as funções de PIP. O
código pode ser transmitido em claro (sem ser cifrado), uma vez que é válido apenas para
um acesso. Uma OTP pode ser associada a um PIN (Personal Identification Number),
conseguindo-se um tipo de autenticação baseada num elemento que o cliente deve possuir
(o token) e noutro que deve conhecer (o PIN);
 Certificado digital, que é emitido e assinado por uma entidade de certificacao (CA,
Certification authority) e inclui, para além de uma chave pública, diversos atributos que
identificam a pessoa ou dispositivo que lhe está associado. Um certificado digital é
armazenado no servidor que identifica (ou, no caso de um utilizador, num cartão ou
computador pessoal) no formato ITU-T X.509. A entidade certificadora, quando emite o
certificado e a chave pública, gera uma chave privada associada à chave pública com a
qual forma um par único. Esta tecnologia, brevemente resumida, designa-se por
 8

criptografia de chaves assimétricas (asymmetric-key crytography), dado que uma chave é

utilizada para cifrar a mensagem e a outra para decifrar a mesma mensagem;
 Credencial biométrico, que ignora tudo o que o cliente tem ou conhece e se baseia naquilo
que o cliente é. Inclui tecnologias de reconhecimento facial, identificação da íris ou de
impressões digitais.

Informação de contexto inclui um conjunto de factores que os PDP mais complexos podem ter
em consideração para determinar a decisão de acesso a um recurso, designadamente, a hora a que
é solicitado o acesso ou a rede a partir da qual é feito o pedido. Inclui-se, ainda, na informação de
contexto, a informação de postura do dispositivo, como o sistema de operações do cliente, a data
da última actualização do antivírus ou outras situações que poderão representar um factor risco. A
informação de postura é, normalmente, discutida no âmbito do controlo de acesso à rede (NAC,
Network Access Control).

2.4. AUTORIZAÇÃO

Uma vez identificado o utilizador, a autorização determina o que ele “pode fazer”, isto é, quais os
recursos do sistema que pode utilizar. A granularidade desta decisão depende, necessariamente,
da implementação do componente responsável pela tomada de decisão (PDP) e do ponto onde é
aplicada a politica de acesso (PEP), não bastando que a informação esteja simplesmente
armazenada no PIP.

O processo de autorização é suportado por um processo de “provisioning”, em que, a informação

sobre os direitos do utilizador, armazenada num repositório (PIP), é transmitida ao PEP após uma
decisão do PDP.

Por exemplo, na atribuição dinâmica de VLAN, um switch (PEP), que tenha capacidade, bloqueia
o acesso à rede ao utilizador até estar concluída a autenticação. De seguida, o switch configura
automaticamente a porta, de acordo com a informação sobre a VLAN em que o utilizador deve
ser colocado.

O RADIUS, para facilitar a troca de informações entre o PDP e o PEP, permite definir Vendor
Specific Attributes (VSA) que, como o nome indica, constituem atributos específicos que não
 9

constam dos dicionários padrão e que possibilitam a implementação de mecanismos adicionais de

autorização.

Uma alternativa, recentemente normalizada no RFC 4849 “RADIUS Filter Rule Attribute”,
define uma extensão que vai permitir, por exemplo, armazenar listas de controlo de acesso (ACL)
em atributos RADIUS, o que significa que podem ser implementadas politicas de controlo de
acesso, por utilizador.

2.5. CONTABILIZAÇÃO

A contabilização consiste num registo da actividade do utilizador – identificação, hora de acesso,

PEP usado para acesso, hora a que terminou o acesso à rede. Durante muito tempo,
contabilização era sinónimo da funcionalidade de accounting do RADIUS e apenas utilizada
pelos fornecedores de acesso à internet, com o objectivo de efectuar os seus clientes. Hoje em
dia, por questões de segurança e de protecção de direitos de autor, a contabilização assume
particular importância, na medida em que a legislação é cada vez mais exigente na manutenção
de registos de utilização das redes.

2.6. PROTOCOLOS DE AAA

2.6.1. CLIENTE PEP

Os protocolos utilizados entre o cliente e o PEP operam no perímetro externo da rede,

considerando o PEP como ponto de fronteira. O protocolo utilizado depende do modo como o
utilizador solicita o acesso à rede e um sistema de autenticação deverá autenticar utilizadores que
usam diferentes tecnologias de acesso.

2.6.1.1. PPP E PPPoE

Num acesso telefónico (dial-up), é estabelecida uma ligação ponto – a - ponto entre o cliente e o
PEP que, neste caso, é um Network Acess Server (NAS) do operador. Esta ligação utiliza o Point-
to-Point Protocol (PPP) que, Após estabelecimento da ligação, inclui uma fase de autenticação
(opcional). A validação das credenciais de autenticação entre o cliente e o PEP é então feita com
base em PAP ou CHAP.
 10

2.6.1.2. VPN IPsec E SSL/TLS

Um utilizador pode solicitar acesso seguro à rede da sua organização, a partir de uma rede
remota. O PEP corresponderá, assim, ao concentrador de VPN, localizado na rede de destino, que
termina a ligação segura e autentica o utilizador.

2.6.2. PEP-PDP

Os protocolos usados na comunicação entre o PEP e o PDP operam no interior da rede e

permitem suportar a decisão sobre o pedido de acesso do utilizador. Devem ser referidos três
protocolos: RADIUS, TACACS+ e Diameter.

2.6.2.1. RADIUS

O Remote Authentication Dial In User Service (RADIUS), o PDP corresponde ao servidor

RADIUS que comunica com o PEP (switch, Acess point, concentrador de VPN), utilizando o
protocolo RADIUS. É um protocolo com uma forte base de utilização e suporte, flexível, e que
tem sido adaptado para responder a requisitos mais recentes.

2.6.2.2. TACACS+

O TACACS+ é um protocolo proprietário, desenvolvido pela Cisco, para comunicação entre PEP
e PDP. Apesar de funcionalidades importantes e de suporte que recebe nos equipamentos de
outros construtores, não tem a aceitação do RADIUS.

2.6.2.3. DIAMETER

O Diameter é um protocolo do IETF designado como sucessor do RADIUS, orientado para

serviços avançados de AAA em redes de operadores e suporte de redes móveis.

2.6.3. CLIENTE-PDP

No contexto de comunicação Cliente - PDP, o PEP funciona apenas como dispositivo de

passagem, não necessitando de conhecer o mecanismo de autenticação em uso, o que simplifica a
sua concepção.
 11

2.6.4. PDP-PIP

Os protocolos PDP-PIP permitem ao PDP consultar um repositório de informação sobre o cliente

(atributos), com o objectivo de permitir ou rejeitar o acesso. Onde o LDAP permite ao PDP,
interrogar um repositório de dados sobre o cliente, armazenado num directório X:500 (muitas
vezes referido como directório LDAP). E o LDAP permite construir soluções de elevado
desempenho, robustas e fiáveis

2.7. REPOSITÓRIO DE CREDENCIAIS DE AUTENTICAÇÃO

O repositório corresponde ao Policy Information Point (PIP), que reúne um conjunto de

informação que permitirá ao Policy Decision Point (PDP), tomar decisões de permitir ou rejeitar
o acesso solicitado pelo cliente. O repositório de credenciais de autenticação é implementado
num directório acessível por LDAP. Para além de redundância e escalabilidade, o sistema
proposto permite a interligação de múltiplos servidores de autenticação, com o objectivo de
construir um sistema que possa autenticar os utilizadores de uma organização, geograficamente
dispersa.

2.7.1. LIGHTWEIGHT DIRECTORY ACCESS PROTOCOL (LDAP)

O LDAP é um protocolo resultante de outro, mais complexo, especificado na norma X.500/ISO-

9594, para acesso a directórios X.500, onde é possível armazenar informações relativo a diversos
tipos de objectos (pessoas, organizações, serviços) que pode ser partilhada por múltiplas
aplicações. O LDAP é um protocolo para acesso a uma entidade fornecedora de serviços de
directório que se designa por Directtory Server Agent (DSA). Entre os DAS com maior
divulgação, podem ser referidos o OpenLDAP, o Microsoft Active Directory, o Samba One Dir
ou Novell E-Directory.
 12

2.7.2. MODELO CLIENTE-SERVIDOR LDAP

O cliente pode ser um módulo de autenticação do sistema de operação ou outro componente de

software, como uma aplicação ou um sistema de gestão de base de dados. O servidor LDAP
recebe a comunicação dos clientes no porto 389/tcp e, inclui o directório no mesmo equipamento.
O directório é implementado sobre um backend que pode ser de diversos tipos, desde um simples
ficheiro de texto até uma base de dados racional. O Berkeley Database da Oracle (BDB) é o
backend usado com maior frequência. Usa-se mecanismos de indexação e caching para melhorar
o tempo de acesso à informação.

De acordo com a especificação do LDAPv3, o cliente pode ter acesso anónimo ao directório
(sem credenciais de autenticação), que é um processo de autenticação bastante útil quando,
por exemplo, se pretende dar acesso a um serviço de pesquisa de contactos. Em alternativa,
pode-se utilizar um dos mecanismos de autenticação simples:

 Autenticação simples: as credencias de autenticação são trocadas em claro ou coma

password, num formato de hash suportado (crypt, MD5, SHA ou SSHA);
 Autenticação simples protegida por SSL/TLS: em que o cliente e o servidor começam
por estabelecer um túnel seguro SSL ou TLS, dentro do qual é efectuada a troca de
credenciais de autenticação.
 Autenticação simples em SASL: em que o processo de autenticação é mais flexíveis,
podendo der utilizado um dos mecanismos de autenticação SASL, a troca de
credenciais pode, ainda, ser protegida por um túnel SSL/TLS.
 13

Para controlo mais selectivo de acesso dos clientes à informação, o LDAPv3 prevê a utilização de
listas de controlo de acesso (ACL).

2.7.3. ELEMENTOS DO DIRECTÓRIO

O modelo de informação LDAP estrutura a informação de forma hierárquica, numa árvore

invertida, designada por Directory Information Tree (DIT).

Uma entrada (entry) corresponde a uma folha da árvore e contém informações relativas a um
objecto, na forma de atributos.

Uma objectClass é um atributo espacial que estrutura a informações em cada entrada, isto é,
define os atributos, obrigatórios ou opcionais, que podem existir na entrada.

As objectClass válidas e os atributos que incluem, quais os atributos obrigatórios e quais são
opcionais, a sintaxe de cada atributo, os mesmos são definidos nos ficheiros de schema
armazenados em /etc/openldap.schema ou em /user/local/etc/openldap/schema,

objectClass person que permite incluir, na entrada, os atributos necessários para conter a
informação sobre pessoas.

PROTOCOLOS DE ACESSO AO REPOSITÓRIO

Um cliente pode ter acesso à informação no directório, através de dois protocolos – LDAP, o
protocolo nativo do directório, e RADIUS. Em primeiro lugar, é apresentada a configuração de
um cliente Linux para acesso LDAP a repositório de credenciais e, de seguida, após uma
introdução ao protocolo RADIUS, inclui-se configuração de um servidor freeRADIUS que utiliza
o mesmo repositório de credenciais.

2.7.4. LDAP

A solução de acesso ao directório de credenciais de autenticação de utilizadores é baseada em

LDAP. Abaixo é descrita a configuração de clientes Linux, Apple MacOS e MS-Windows para
permitir que a autenticação dos utilizadores destes sistemas seja feita sobre um directório
acessível por LDAP, em alternativa à informação de utilizadores armazenada em cada
equipamento.
 14

2.7.4.1. CLIENTE LINUX

A configuração de um cliente LDAP em plataforma Linux, permite que os utilizadores deste

sistema sejam autenticados, com base em credenciais de autenticação armazenadas num
directório LDAP, em vez de utilizar o tradicional ficheiro /etc.passwd. este processo envolve a
utilização de duas funcionalidades a seguir descritas – PAM e NSS.

PAM (Pluggable Authentication Modules): Permite que os processos de autenticação, autorização

e contabilização sejam efectuados e personalizados em diversos ambientes.

NSS (Name Service Switch): Permite ao administrador de sistemas escolher quais os serviços de
resolução de nomes que serão usados em diversos contextos.
 15

2.7.4.2. CLIENTE APPLE MACOS

A autenticação de utilizadores em directórios LDAP é um mecanismo implementado de base no

MacOS, o sistema de operação da Apple. A configuração usa o Directory Utility onde, quando se
cria nova ligação, se especifica que o directório será utilizado para autenticar.

2.7.4.3. CLIENTE MICROSOFT WINDOWS

Ao contrário dos Apple Macintosh, os computadores MS-Windows, na sua versão cliente,

dispõem apenas de um único mecanismo de autenticação que implica a utilização de servidor NT
4 ou Active Directory. Para poderem ser integrados no ambiente de autenticação. Normalmente
existem duas alternativas como: utilização e um Primary Domain Controller (PDC) SAMBA ou
através da instalação individual da DLL pGINA.
 16

Primary Domain Controller (PDC) SAMBA, os sistemas Windows autenticam-se num PDC
implementado com SAMBA que, acede por LDP ao repositório de credenciais. Para permitir a
autenticação de clientes Windows, o directório tem que suportar o samba.achema incluído na
distribuição SAMBA. Esta solução oferece, funcionalidades adicionais, como a possibilidade de
dispor de um Backup Domain Controller (BDC), serviços de partilha de ficheiros e de impressão,
igualmente implementados com SAMBA.

Outra alternativa, pode-se optar por uma abordagem completamente independente do ambiente
Microsoft e fazer com que cada computador Windows possa aceder directamente, via LDAP, ao
directório. Para permitir a utilização de outros mecanismos de autenticação, a Microsoft
disponibiliza a especificação da interface da DLL Gina (Graphical Indentification aNd
Authentication). O pGINA é um substituto da DLL GINA que permite a utilização de diversos
métodos de autenticação, designadamente LDAP e RADIUS.

2.7.5. RADIUS

O Remote Authentication Dial In User Service (RADIUS) foi desenvolvido pela Livingstone com
o objectivo de autenticar utilizadores dial-up que acediam aos seus Network Access Servers
(NAS), especificar os serviços autorizados a cada utilizador e contabilizar a utilização desses
serviços. O RADIUS é um protocolo para comunicação entre PEP e o PDP, em que o PEP
corresponde ao NAS e o PDP ao servidor de RADIUS que integra também o componente de
contabilização.

Os servidores RADIUS, de código aberto ou proprietários, suportam diversos repositórios de

informação, desde simples ficheiros de texto, a bases de dados relacionais ou directórios
acessíveis por LDAP. Enquanto, que o ficheiro de texto reside num sistema de ficheiros acessível
pelo servidor RADIUS, as bases de dados ou directórios LDAP podem ser disponibilizados em
servidores externos. O RADIOS surge como um mecanismo integrador que permite a
dispositivos sem suporte LDAP (como switches ou routers) terem acesso ao repositório de
credenciais de autenticação.
 17

2.8. EXEMPLO DE UTILIZAÇÃO DE SERVIÇO DE AUTENTICAÇÃO

A figura apresenta uma pequena rede que poderá ser montada para testar o servidor de
autenticação descrito e as configurações dos clientes. Os servidores LDAP e RADIUS são
incluídos no mesmo hardware, constituindo o que tem sido designado por “servidor de
autenticação”. A rede inclui três clientes – um sistema Linux, um MacOS e um Windows XP.

Também está incluído um Switch Cisco Catalyst com suporte de RADIUS.

2.9. REDUNDÂNCIA E ESCALABILIDADE

Um serviço de autenticação que se pretende que dê resposta, não apenas aos requisitos de uma
pequena organização, mas também aos de organizações de grande dimensão, geograficamente
dispersas e com elevado número de utilizadores, tem requisitos importantes de redundância e
escalabilidade. O serviço de autenticação deverá ser implementado de modo a permitir, não só
integrar as diversas plataformas de software, como oferecer sólidos mecanismos resistentes a
 18

situações de avaria e permitir dar resposta a situações de crescimento do número de utilizadores.

Neste contexto o sistema deve ser redundante, de modo a que uma paragem (por avaria ou
manutenção) de um servidor não determine a paragem do serviço; a capacidade de crescimento
do sistema não deve ser limitada à expansão do equipamento, o sistema deve poder crescer com
recurso a equipamentos adicionais.

2.9.1. REPLICAR O DIRECTÓRIO

O directório LDAP é o repositório da informação fundamental ao funcionamento do serviço, pelo

que deve ser possível replicar automaticamente o seu conteúdo. A réplica é uma funcionalidade
que os vários DAS oferecem.

2.9.2. REPARTIR O DIRECTÓRIO

Repartir directórios consiste em armazenar uma parte do directório num ou mais servidores. A
repartição do directório é suportada pela ObjectClass referral, este atributo é apenas um URI que
contém uma ligação, ou referencia subordinada, para o servidor que contém de facto a
informação, neste caso, as entradas da ou=pessoas.

2.9.3. REDUNDÂNCIA RADIUS

O protocolo RADIUS não define qualquer mecanismo de redundância, o mecanismo mais

simples para garantir a autenticação em caso de falha do servidor, consiste em configurar o
cliente para aceder a um servidor alternativo em situações de falha do principal. Compete ao
gestor do serviço de autenticação, assegurar que os dois servidores têm acesso ao mesmo
repositório de informação.

2.9.4. Expansão da Solução

Anteriormente referiu-se acerca da redundância e a escalabilidade que estas estão entre os

principais requisitos de um sistema de autenticação de utilizadores. A solução apresentada pode
ser implementada sobre um único sistema, mais pode, também, evoluir gradualmente para
cenários redundantes, com capacidade para suportar um elevado número de utilizadores,
eventualmente dispersos por várias localizações geográficas.+
 19

2.10. OUTRAS ALTERNATIVAS

2.10.1. KERBEROS

O Kerberos é um protocolo de autenticação que se destina a verificar a identidade de um

utilizador, servidor ou instancia de servidor que comunicam sobre uma rede insegura. O Kerberos
foi desenvolvido pelo MIT, no âmbito do Athena Project, que teve inicio em 1983. O Kerberos
utiliza uma terminologia muito que é necessário conhecer para compreender o funcionamento do
protocolo. O mesmo protocolo usa dois conceitos fundamentais para compreender o mecanismo
de autenticação nomeadamente:

 A SESSION-KEY: é uma chave temporária gerada pelo KDC, válida apenas numa única
sessão, utilizada para cifrar a comunicação entre dois principals, que tem um papel muito
importante na prova de identidade do utilizador.
 O TICKET: inclui informação que um sistema cliente transmite para um servidor
aplicacional como prova da sua identidade. São emitidos por um servidor de autenticação
e cifrados com a chave secreta associada ao serviço de autenticação e pelo sistema que
fornece o serviço (o cliente nunca tem conhecimento da chave). As principais
componentes da informação de um ticket são a identidade do cliente (username), o
principal do serviço a que o ticket se destina, o endereço IP do cliente, o dia e hora
(timestamp) a partir da qual o ticket é válido, a duração máxima do ticket e a session key.

Um sistema de autenticação Kerberos envolve os seguintes componentes:

 O cliente: um utilizador de um computador pessoal que deseja ter acesso a um serviço. A

chave secreta do cliente é normalmente gerada a partir de uma password do utilizador;
 O servidor aplicacional: disponibiliza o serviço ao qual o cliente pretende aceder. É
configurado com uma chave secreta para acesso ao serviço;
 O key distriburion center (KDC): é o servidor de autenticação de um ambiente Kerberos e
implementa um serviço de rede que disponibiliza tickets e chaves temporárias de sessão
(session keys), para autenticar o acesso a serviços de rede. E o mesmo compreende três
componentes lógicos: uma base de dados com o registo dos principais (utilizadores e
servidores) e respectivas chaves secretas; O authentication-server (AS) que responde aos
pedidos iniciais dos clientes, ainda não autenticados e o ticket-granting server (TGS) que
 20

distribui os tikets para acesso aos serviços, após garantir a autenticidade da identidade do
principal.
2.10.2. MICROSOFT ACTIVE DIRECTORY

Active Directory é uma implementação proprietária da Microsoft de um serviço de directório

baseado em LDAP, com uma terminologia própria. Uma forest (floresta) designa uma área de
segurança que pode ser estruturada em domains (domínios) e unidades orgânicos, constituindo
uma estrutura hierárquica com múltiplos objectos (utilizadores, computadores, aplicações).

2.10.3. SHIBBOLETH SYSTEM

Shibboleth System é a designação de um projecto desenvolvido no âmbito da Internet2

Middleware Iniactive e apresentado como campus and Federated Single Sign-On Software. Esta
designação representa uma extensão do conceito de single sign-on, normalmente realizado no
âmbito de um campus universitário ou de uma organização, alargando o domínio de autenticação
a uma federação de organizações.

Shibboleth envolve dois componentes fundamentais:

 Identity Provider (IDP): Software na organização de origem do utilizador que pretende ter
acesso a um serviço restrito. Para ter acesso às credenciais dos utilizadores deve ser
integrado com o serviço de directório da organização;
 Server Provider (SP): Software de controlo de acesso ao serviço, gerido pelo respectivo
fornecedor, que dialoga com o IdP para validar o acesso do utilizador e avaliar se este está
autorizado a utilizar o recurso.
 21

3. CONCLUSÃO

O trabalho contextualiza o básico sobre uma proposta de enquadramento de diversos protocolos

envolvidos no processo de autenticação de utilizadores, mais abrangente do que o modelo
tradicional de AAA, invariavelmente associado ao RADIUS. Este modelo responde; não só aos
habituais ambientes de acesso dial-up, mas também a ambientes de autenticação em redes
cabladas ou sem fios. Os protocolos LDAP e RADIUS são utilizados para construir uma solução
de autenticação robusta e utilizável numa variedade de cenários de múltiplas dimensões,
permitindo controlar o acesso a recursos de rede (hardware ou software), exigindo aos
utilizadores um único par de credenciais de autenticação.
 22

4. REFERÊNCIA BIBLIOGRÁFICA

CONVERY, S. , “Network Authentication, Authorization and Accounting Part I”. The Internet
Protocol Journal, Volume 10, Number 1, http://www.cisco.com/ipj/, (2007)

CONVERY, S. , “Network Authentication, Authorization and Accounting Part II”. The Internet
Protocol Journal, Volume 10, Number 2, http://www.cisco.com/ipj/, (2007)

IANA – Internet Assigned Numbers Authority, http://www.iana.org/

IEEE Std. 802.1X-2001, Port-Based Network Access Control, (2001)

ITU-X Recommendation X.506: “Information technology – Open Systems Interconnection – The

Directory Public-Key and attribute certificate frameworks”

Kerberos: “The Network Authentication Protocol”, http://web.mit.edu/Kerberos/

LDAP Browser/Editor, http://www-unix.mcs.anl.gov/~gawor/Idap/

LDAP Schema Viewer, http://Idap.akbkhome.com/

LDAP Synchronization Connector (LSC), http://Isc-project.org/

Microsoft Windows Server 2003 Active Directory, http://www.microsoft.com/ad/