sistemas:cafe:estruturaprovident

Provedor de Identidade

Implementa a política interna de gestão de identidade de uma instituição

Atributos dos usuáriosNome, data do vínculo, cargo ocupado, matrícula etc.‏
Método de autenticação Login/senha, certificados etc.
Identificador único para cada pessoa vinculada à instituição

Os provedores de identidade são responsáveis por manter as informações sobre as pessoas vinculadas a uma instituição, incluindo dados pessoais (nome, data de nascimento, CPF, nomes dos pais, sexo, data de nascimento etc.) e vínculos internos (data de admissão, cargo ocupado, número de matrícula, número VoIP etc.).

O provedor de identidade estabelece seu método de autenticação interno e deve garantir que cada pessoa da instituição tenha um identificador único.

Um provedor de identidade deve construir uma infraestrutura apta para cumprir com todas as regras determinadas pela Federação CAFe e que possa ter um ótimo funcionamento.

Dentre os diversos aplicativos contidos nela, esta seção descrever sobre aqueles com maior importância: esquema brEduPerson usando no LDAP, os aplicativos EID, EDI2LDAP, Shibboleth.

brEduPersondefine atributos e classes necessários para armazenar informações específicas sobre pessoas e seus vínculos em instituições brasileiras.
EID/EID2LDAPferramentas de auxílio que facilitam o processo de extração de dados de pessoas de bases relacionais e a inclusão desses dados em um diretório LDAP.
Shibbolethplataforma para implantar um provedor de identidade institucional

Esquema proposto para membros de instituições de ensino superior no Brasil.

BrPerson tem o objetivo de capturar atributos específicos de pessoas que vivem no Brasil.

Abaixo dessa entrada principal, é recomendado existir pelo menos uma entrada de classe estrutural brEduPerson que descreve um vínculo da pessoa com a instituição.

Divide-se em:

  • Informações gerais sobre qualquer cidadão
  • Informações gerais sobre membros de uma instituição
  • Informações específicas sobre funcionários e alunos

Este esquema e também utilizado integrado com os esquemas inetOrgPerson, eduPerson e SCHAC.

Dentro de uma instituição de ensino e pesquisa, há a necessidade de modelar relacionamentos entre conjuntos de informações. Deve suportar modelagens de pessoas que possam desempenhar diferentes papeis de aluno, a cada um dos quais está associada uma data de ingresso, um codigo de curso, e outras informações, ou que uma mesma pessoa pode obter vários números VoIP, cada um com características distintas.

Esse modelo de relacionamento é realizado de forma hierárquica.

Uma pessoa com alguma ligação com a instituição e o item principal, contendo informações genéricas, como nome, CPF, gênero, data de nascimento, e as demais informações de relacionamento dela com a organização (aluno, professor, técnico, etc.) são tratados como containers interligados abaixo dele. Alem disso, abaixo da entrada com os dados gerais, podem aparecer diversas entradas descrevendo telefones VoIP, dados biometricos, etc.

Classes de objetos e atributos

O esquema brEduPerson define quatro classes de objetos:

  • brPerson (com atributos gerais sobre pessoas);
  • brEduPerson (com atributos comuns para pessoas em universidades);
  • brBiometricData (com atributos sobre dados biométricos);
  • brEduVoIP (com atributos sobre telefones VoIP).
brPersonbrPersonCPF, brPersonPassport
brEduPersonbrEduAffiliationType, brEntranceDate, brExitDate, brEduAffiliation
brBiometricDatabrCaptureDate, brBiometricSource, brBiometricData
brEduVoIPbrEduVoIPalias; brEduVoIPtype; brEduVoIPadmin; brEduVoIPcallforward; brEduVoIPaddress; brEduVoIPexpiryDate; brEduVoIPbalance; brEduVoIPcredit; brEduVoIPphone

Este modelo de estrutura tem a consequência de que as classes que em princípio não precisariam ser definidas como estruturais, passam a ser definidas dessa forma para permitir que suas informações apareçam em uma entrada independente.

A entrada principal de cada pessoa é definido pelo objeto de classe estrutural inetOrgPerson e possuindo classes auxiliares schacPersonalCharacteristics, eduPerson e brPerson.

Cada vínculo é descrito por uma entrada separada, e pode haver um número arbitrário de tais entradas, refletindo em diferentes vínculos. Classes auxiliares podem vir a ser definidas para incluir atributos relativos a cada tipo de vínculos demonstra o modelo de nomes da estrutura proposta pela Federação CAFe.

A figura a seguir apresenta um exemplo mais detalhado de um container da estrutura hierárquica.

Cada objeto de classe brEduPerson representa os vínculos (aluno, funcionário, professor, pesquisador, etc.) e ainda as posições temporárias (coordenador, diretor, etc.)

Diretórios que possuem um baixo fluxo de cadastros de pessoas podem ser facilmente gerenciados pela inclusão e exclusão manual de registros.

Já os diretórios com muitos usuários e comportamento dinâmico necessitam de um esforço maior na manutenção, o que deixa seu gerenciamento manual mais complicado, como os diretórios acadêmicos.

O objetivo do EID (Export Import Directory) é facilitar a integração de dados de diversos sistemas para construir um metadiretório (uma base relacional intermediaria entre as fontes efetivas dos dados e o diretório) e em seguida um ou mais diretórios, ou seja, ferramenta para auxiliar nas funcionalidades de importação e exportação de dados para outras fontes.

Desenvolvido pelo Grupo Sao Tomé da UFMG, teve base na ferramenta PingifesImport, ferramenta de extração, transformação e carga (ETL), utilizadas pelas instituições de ensino superior para alimentação do modelo de dados (PingIFES) definido pelo MEC.

A ferramenta EID permite importar dados de bancos relacionais, desde que exista um drive JDBC ou ODBC para fazer a conexão e/ou arquivos de texto CSV.

O EID disponibiliza um serviço web para exportação e consulta de dados, o que facilita o acesso por aplicações que utilizem tecnologias diversas.

Os dados importados são associados as pessoas e os registros completos podem ser facilmente recuperados através da interface web do EID.

O EID utiliza o conceito de Objeto (EidObject) para representar as informações que armazenam. Um objeto é uma entidade que possui um identificador único e um conjunto de atributos, sendo a unidade mínima de armazenamento de informações.

São considerados objetos: pessoas e definições de grupos.

Os atributos são mapeamentos nome-valor, onde o valor possui um tipo ou um domínio definido.

Os nomes e os tipos dos atributos são especificados em entidades denominadas classes.

As classes são definições de agrupamentos de atributos. Cada classe pode ser considerada uma definição de um tipo de dado composto.

Atribuir valores aos atributos definidos pela classe e sua associação a um objeto e o processo denominado de instanciação da classe. Um objeto pode estar associado a varias instâncias de uma mesma classe ou de classes diferentes, mas não aos atributos individualmente.

As classes podem ser definidas de acordo com as necessidades do utilizador.

Todo objeto é identificado globalmente através do GUID, que é gerado automaticamente pela ferramenta.

Esse atributo e definido pela classe especial EidObject.

O GUID é gerado ao importar a primeira classe denominada de Identificação (possui informações b ˜ asicas referente ´ as pessoas). Sua geração é realizada a partir da escolha de um atributo que seja único para cada indivíduo, tornando assim um ponto de referencia na base.

As demais classes extraídas usarão o atributo único para conciliar com o GUID determinado, interligando o registro principal sobre a pessoa com as funções e seus atributos, como funções que ela exerce na instituição (aluno, professor, técnico, etc.), e-mails que a pessoa possui, endereços, telefones para contato, VoIPs, etc.

Toda classe criada na aplicação gera uma tabela no banco de dados. A classe EidObject se relaciona com as demais classes do sistema denominadas EidClass.

Essas classes agregam a um objeto EID e seus atributos específicos. A figura a seguir demostra a estrutura do EidObject.

O EID ja fornece algumas classes que podem ser usadas para alimentar diretórios LDAP sem nenhuma configuração adicional, isso porque existe uma conversao pré-configurada para a ferramenta EID2LDAP que definem os atributos necessários para o esquema brEduPerson.

Outras classes podem ser definidas pela propria organização, para suprir suas necessidades. Estas modificações deversão também ser realizadas na conversao utilizada pelo EID2LDAP.

Metadiretorio é uma base de dados intermediária para construção do diretório e seu modelo independe do esquema final. Um metadiretório ideal permite ao administrador realizar alterações em um repositório e prover a atualização da informação em todos os diretórios ligados a ele.

O fluxo de informações acontece a partir dos dados das bases corporativas que serão importados para o metadiretóorio, e em seguida esses dados podem ser exportados para o LDAP, sendo utilizados, por exemplo, para uma autenticação.

O EID2LDAP é uma ferramenta que busca informações de diretórios armazenados no metadiretório EID e as transfere para servidores LDAP, além de possuir uma interface web.

A ferramenta EID possibilita extrair e incorporar ao seu metadiretorio, dados de diversas bases institucionais e os disponibilizam em arquivos XML atraves de um serviço web. O EID2LDAP por sua vez acessa estas informações, utilizando a marcação XSLT (Extensible Stylesheet Language Transformations) para especificar a transformação dos dados para o formato LDIF (Ldap Data Interchange Format) compatível com o formato do servidor LDAP de destino, e realiza a atualização do servidor LDAP.

O XSLT introduz flexibilidade no EID2LDAP, permitindo ao usuario definir como se dará o mapeamento entre os dados do EID e o formato do LDAP.

Assim como o EID, o EID2LDAP permite o agendamento periódico das exportações. Para cada exportação são atualizados apenas os registros modificados, ou inseridos, ou desativados desde a ultima importação.

A exportação dos dados se inicia quando o algoritmo de transformação determina o momento em que o tempo do agendamento foi alcançado:

  • EID2LDAP acessa o EID via Web Service;
  • Busca registros modificados/inseridos/desativados;
  • Todos os registros são transformados em LDIF e depois enviados;
  • Cria um novo agendamento caso o modo de repetição esteja acionado;
  • Registros são requisitados e processados de 100 em 100;
  • Caso ocorra erro, o processamento sera interrompido;
  • O próximo agendamento reiniciar a partir da série de registros em que o erro ocorreu;
  • O que foi enviado no intervalo antes do erro ao LDAP nao será desfeito, mas reescrito na próxima iteração.

O LDAP possui uma sintaxe rígida com alguns atributos, como mail, telephoneNumer, etc, e podem ocorrer erros durante a exportação de dados malformados importados das fontes.

O EID2LDAP possui um tratador onde a correção do dado da fonte pode ser realizada através de scripts de conversão executados ao inserir o valor do atributo ao seu destino.

Arquivo XML fornecido pelo EID contem informações sobre pessoas e grupos, mas apenas objetos novos (recém-inseridos no metadiretório), aqueles que sofreram algum tipo de alteração ou que foram removidos. Não há marcação no XML para indicar o atributo alterado, nem para diferenciar um objeto novo de um alterado.

Sempre é enviado todo o conteúdo do objeto.

Alguns exemplos dos formatos para informações sobre pessoas:

Pessoas e seus atributos:

<eid-object type="person">....</eid-object>

Grupos:

<eid-object type="group">...</eidobject>

Membros do grupo:

<member> <eid-object>...</eid-object>...</member>

Pessoas e grupos desativados:

<eid-object type="person" removed="true">

No XML do EID, as várias classes existentes para a pessoa são recuperadas em elementos attributes e seus atributos dispostos em elementos attribute, contendo nome e valor de cada um como exemplificado abaixo:

<!−−Pessoa ou Grupo −−>
 <eid−object type="person" guid ="EHBBCXKA-YLHXBAAA" serial="148048">
 <!−− Classe −−>
 <attributes class ="Identificacao" id ="52347">
 <attribute name="nomeCompleto" key="03812882698">
     <! [CDATA[JOAO SILVA]]>
 </attribute>
 <attribute name="nomeSolteiro">
     <! [CDATA[ ]]>
 </attribute>
 <attribute name="cpf">
     <! [CDATA[01212222222]]>
 </attribute>
 </attributes>

 <attributes class ="Email" id ="72201">
 <attribute name="email">
     <! [CDATA[silva@mail.com ]]>
 </attribute>

 </attributes>

 </eid−object>
 <!−−Membros de Grupos −−>
 <member>
     <eid−object> . . .</eid−object>
 </ member> }

No momento da exportação, caso o registro já exista no LDAP (identificado pelo DN gerado no LDIF), o LDIF e modificado para aplicar operações de alteração (modify) no registro do LDAP.

Apenas os objectClassesrepresentados no LDIF serao substituídos no LDAP, isto é, os objectClasses no LDAP passarão a ter os atributos com os mesmos valores do EID, enquanto outros objectClasses permanecerão com seus atributos inalterados.

Isto possibilita que outras aplicações alimentem diretamente o diretório sem a necessidade de passar pelo EID.

O Shibboleth é um sistema baseado em padrões para web single sign-on, ou seja, o usuário necessita se autenticar apenas uma vez, para posteriormente, ter acesso automaticamente aos outros serviços com a mesma política de autenticaçã dentro das fronteiras organizacionais.

E um projeto da Internet2 Middleware Initiative, código aberto e permite que serviços web informem decisões de autorização para acessos individuais de recursos protegidos on-line de forma que preserve a privacidade do usuário.

O software consiste na implementação de padrões amplamente utilizados para autenticação e autorização federada via web, principalmente o SAML (Security Assertion Markup Language) criado pela OASIS (Organization for the Advancement of Structured Information Standards).

Um usuário se autentica com sua credencial referente à sua organização de origem. A organização (provedor de identidade) passa a mínima quantidade de informações de identificação necessárias para que o gerente de serviço habilite a decisão de autorização.

Shibboleth é composto por dois módulos:

Provedor de Identidaderesponsável pela autenticação
Provedor de Serviçoresponsável pela autorização

Numa federação Shibboleth, normalmente apresenta mais dois componentes:

serviço WAYF (Where Are You From)
serviço de Metadataresponsável em concentrar as informações dos provedores pertencentes a federação.

O Shibboleth foi desenvolvido para tratar os seguintes desafios:

  • Acabar com as múltiplas senhas requeridas para múltiplas aplicações;
  • Suportar a escalabilidade no gerenciamento de multiplas aplicações;
  • Melhorar a segurança associada ao acesso de serviços de terceiros;
  • Aumentar a privacidade dos dados dos usuários;
  • Suportar a interoperabilidade dentro e entre organizações;
  • Permitir a liberdade de escolha das tecnologias de autenticação para as instituições;
  • Permitir o controle de acesso efetuado a partir dos provedores de serviço.

Hoje existem diversas federações espalhadas pelo mundo que fazem parte do projeto Shibboleth.

O Shibboleth IdP (Identity Provider) é a aplicação voltada para ser utilizada como provedor de identidade.

Atraves do IdP, será firmado declarações de autenticação ou de atributos para as partes confiantes, neste caso os provedores de serviços.

Os subcomponentes do IdP sao mostrados pela figura.

A autenticação e a entrega de atributos são realizadas da seguinte forma:

  1. O usuário envia as suas credenciais, que estão devidamente verificadas pelo provedor de identidade.
  2. O provedor de identidade envia um handle para o provedor de serviço, atestando que o usuário foi autenticado.
  3. O provedor de serviço envia este handle para o provedor de identidade, solicitando a entrega de atributos referentes ao usuário em questão.
  4. O provedor de identidade envia esses atributos para o provedor de serviço.

A instalação padrão de um provedor de identidade da federação CAFe é composta por três elementos principais:

Shibboleth Identity ProviderServiço de middleware, responsavel por intermediar a autenticação e o envio de atributos
Serviço de autenticação Single Sign-on – Serviço de autenticação web single sign-on, responsavel pela interface de autenticação com o usuário. Na versão Shibboleth IdP 2.x, este serviço já vem incorporado ao serviço de provedor de identidade
OpenLDAP Servidor de diretório, responsável por armazenar os atributos dos usuários e validar as suas credenciais. Shibboleth IdP pode trabalhar com outros servidores de autenticação e atributos.

O provedor de serviço e responsável por fazer a autorização do usuário e disponibilizar o acesso ao recurso, através da autenticação e dos atributos disponibilizados pelo provedor de identidade.

A autorização e o acesso ao recurso são realizados da seguinte forma:

1. O usuário solicita o acesso ao recurso. 2. O provedor de serviço solicita que ele se autentique no provedor de identidade da sua instituição. 3. O provedor de identidade envia um handle atestando a autenticação do usuário 4. O provedor de serviço envia o handle para o provedor de identidade solicitando os seus atributos. 5. O provedor de serviço processa a autorização baseado nos atributos do usuário e disponibiliza o acesso ao recurso.

A instalação padrão de um provedor de serviço da federação CAFe é baseada no Shibboleth SP (Service Provider), que, por sua vez, e composto por dois elementos: ´

Mod shib Modulo do Apache, responsável por controlar a autorização e o acesso ao recurso.
Shibd Daemon, responsavel por intermediar a solicitação de autenticação e de atributos

Shibboleth SP pode trabalhar com o servidor HTTP Microsoft IIS. Hoje, já existe uma vasta lista de aplicações que são compatíveis com o Shibboleth, por exemplo:

  1. Confluence Wiki
  2. eAcademy
  3. Horde
  4. Media Wiki
  5. Microsoft DreamSpark 2
  6. WordPress
  7. Blackboard
  8. Moodle
  9. Google Apps
  • sistemas/cafe/estruturaprovident.txt
  • Última modificação: 2021/08/25 10:33
  • (edição externa)