Conceitos essenciais

Artigo
03/24/2009

Capítulo 7: Aplicativos

Publicado em: maio 11, 2004 | Atualizado em: 26 de junho de 2006

Os aplicativos têm uma função importante em qualquer estratégia de gerenciamento de acesso e identidades. Eles utilizam dados de identidade digital para fins de autorização e avaliam direitos que impõem o acesso a recursos. Ao escolher ou desenvolver aplicativos, é essencial assegurar que os aplicativos se adéquem à sua estrutura de gerenciamento de acesso e identidades.

Geralmente, os aplicativos são de um destes dois tipos:

Desenvolvidos por terceiros disponíveis no varejo ou comerciais, como o Microsoft® Exchange Server 2003.
Aplicativos personalizados ou internos criados por desenvolvedores para a organização.

Independentemente de ter sido desenvolvido ou comprado, um aplicativo precisa estar integrado efetivamente à estrutura de gerenciamento de acesso e identidades da organização. No entanto, existem vários critérios envolvidos, dependendo do tipo de aplicativo que você está tentando integrar.

A facilidade ou dificuldade de integrar um aplicativo com a plataforma de gerenciamento de acesso e identidades é determinada pela arquitetura do aplicativo e pelos mecanismos que ele utiliza para identificar os usuários. A Microsoft recomenda a identificação de seus aplicativos, sua categorização e o exame de suas dependências de funcionalidade e infra-estrutura. Se um aplicativo não for compatível com a plataforma de gerenciamento de acesso e identidades da sua organização, será necessário modificar o aplicativo ou sua infra-estrutura.

Observação O ponto essencial da perspectiva de desenvolvimento de um aplicativo é que os aplicativos não devem inventar e implementar seus próprios armazenamentos de identidades, protocolos de segurança (para autenticação, autorização e auditoria) ou mecanismos de proteção de dados.

As seções a seguir deste capítulo exploram métodos recomendados para a integração de aplicativos com a Plataforma de gerenciamento de acesso e identidades da Microsoft. Elas também preparam o terreno para uma discussão detalhada das técnicas de desenvolvimento, teste e implantação de aplicativos com reconhecimento de identidades. O documento "Desenvolvendo aplicativos com reconhecimento de identidades", desta série, descreve mais detalhadamente o que os arquitetos e desenvolvedores de aplicativos precisam fazer para integrar aplicativos à infra-estrutura.

Nesta página

Escolhendo aplicativos
Desenvolvendo aplicativos

Escolhendo aplicativos

Ao escolher um aplicativo, freqüentemente os gerentes de TI se esforçam significativamente para assegurar que o aplicativo possa fornecer a funcionalidade necessária. Infelizmente, muitas vezes as considerações sobre como o aplicativo se integrará com a rede são negligenciadas, especialmente com relação ao gerenciamento de identidades.

Os aplicativos de terceiros podem identificar usuários por meio da:

Integração com o serviço de diretório principal da organização.
Vinculação ao serviço de diretório principal, usando uma conexão baseada em padrões.
Autenticação em outro serviço de diretório.
Utilização de um armazenamento de identidades dedicado.

O Exchange Server 2003 fornece um exemplo de um aplicativo que se integra totalmente com um serviço de diretório. O Exchange estende o esquema do serviço de diretório Microsoft Active Directory® e, em seguida, adiciona atributos de caixa de correio a contas de usuários no Active Directory. Ao contrário do Exchange 5.5, o Exchange 2000 Server e o Exchange Server 2003 não mantêm um banco de dados de diretório separado. A integração total com um serviço de diretório é a maneira mais fácil de implementar o gerenciamento de identidades de aplicativos.

Alguns aplicativos não se integram completamente com um serviço de diretório, mas podem autenticar usuários em um diretório usando conexões baseadas em padrões. Um exemplo disso seriam os aplicativos que podem usar o protocolo de autenticação Kerberos versão 5 para autenticar-se no Active Directory, como no exemplo do SAP R/3, que é parte do ambiente fictício da Contoso, mencionado em outros documentos desta série.

Os aplicativos podem se autenticar em outro serviço de diretório que não seja o diretório principal da organização. Isso não é o ideal, pois será necessário sincronizar o diretório principal e o diretório usado pelo aplicativo. Um produto de metadiretório, como o Microsoft Identity Integration Server 2003, Enterprise Edition (MIIS 2003 SP1), pode fornecer essa sincronização por meio de agentes de gerenciamento que se conectam aos armazenamentos de identidades mais comuns.

A disposição menos adequada é quando o aplicativo possui um armazenamento de identidades proprietário dedicado e não há ferramentas disponíveis para importar ou exportar dados de identidades em um formato para o qual o MIIS 2003 SP1 ofereça suporte. Nesse caso específico, pode não ser possível usar o MIIS 2003 SP1 para sincronizar o armazenamento de identidades de aplicativos com o serviço de diretório principal; dessa forma, a manutenção de identidades no armazenamento de identidades de aplicativos se torna um processo manual dispendioso e propenso a erros.

Desenvolvendo aplicativos

Se você estiver desenvolvendo aplicativos internamente, existem três abordagens básicas que os arquitetos e desenvolvedores de aplicativos precisam considerar:

Integração de aplicativos. A escolha de integrar ou interoperar com a infra-estrutura.
Fluxo de identidades. A escolha de uma combinação apropriada dos três modelos básicos para autenticação front-end e back-end.
Autorização. A escolha de uma combinação dos dois modelos básicos de autorização.

As opções nessas três áreas definem aquilo que os desenvolvedores de aplicativos precisam implementar para autenticação, autorização e auditoria. Em um aplicativo bem-integrado, quase nenhum código que reconhece identidades precisa de implementação, pois a infra-estrutura subjacente faz todo o trabalho.

A integração de aplicativos compreende os mesmos fatores discutidos na seção anterior, "Escolhendo aplicativos".

Habilitando o fluxo de identidades

Existem três modelos diferentes para passar identidades do usuário autenticado aos ambientes distribuídos, o que também é conhecido como fluxo de identidades. Os modelos são os seguintes:

Representação/delegação
Subsistema confiável
Mapeamento de credenciais

Usando o modelo de representação/delegação

A representação permite que um processo de servidor seja executado usando as credenciais de segurança do cliente. Quando o servidor está representando o cliente, todas as operações realizadas pelo servidor serão executadas usando as credenciais do cliente. Contudo, a representação não permite que o servidor acesse recursos remotos em nome do cliente; esse acesso exige a delegação. A delegação é mais sofisticada e permite que o processo do servidor faça chamadas para outros computadores ao atuar como cliente.

Usando o modelo de subsistema confiável

Com esse modelo, o serviço de camada intermediária usa uma identidade fixa para acessar serviços e recursos downstream. O contexto de segurança do chamador original não flui pelo serviço no nível do sistema operacional, apesar de o aplicativo poder escolher fazer a identidade do chamador original fluir no nível do aplicativo. Pode ser necessário fazer isso para oferecer suporte a requisitos de auditoria back-end ou para oferecer suporte ao acesso de dados e autorização por usuário.

O nome do modelo tem origem no fato de o serviço downstream (talvez um banco de dados) confiar no serviço upstream para autorizar chamadores.

Usando o modelo de mapeamento de credenciais

O modelo de mapeamento de credenciais alinha um conjunto de credenciais com outro em uma tabela de mapeamento. As credenciais mapeadas podem então ser usadas para criar uma nova conexão com outro sistema. O modelo de mapeamento de credenciais é fornecido em duas variedades: uma delas usa o mapeamento direto de credenciais e o outro usa “tíquetes” de mapeamento indireto, que são posteriormente trocados por credenciais. Você poderá usar o modelo de mapeamento de credenciais se o sistema de destino não oferecer suporte ao protocolo de autenticação Kerberos versão 5 ou não usar o Active Directory como armazenamento de identidades.

Implementando a autorização

Quando o aplicativo tiver identificado o usuário, ele precisará controlar o que esse usuário poderá acessar por meio da autorização. Os dois modelos de autorização de aplicativos são os seguintes:

ACL (lista de controle de acesso)
RBAC (controle de acesso baseado em função)

Usando o modelo de lista de controle de acesso

O modelo de ACL envolve proteger um recurso (como um arquivo, uma pasta, uma impressora ou um objeto de serviço de diretório) usando uma ACL, que é uma lista de usuários e grupos, em conjunto com as permissões (permissões e negações) de cada usuário ou grupo. Quando um usuário solicita o acesso ao recurso, as suas permissões de acesso são avaliadas juntamente com as permissões de acesso de todos os grupos dos quais o usuário é membro. Então, é concedido ou negado o acesso ao usuário, com base nessas permissões de acesso.

O modelo de ACL trabalha bem com objetos persistentes bem-definidos, mas não funciona em determinados ambientes, como aplicativos LOB (de linha de negócios) ou aplicativos Web. Para lidar com esses tipos de aplicativos, aplicativos de fluxo de trabalho e objetos transitórios é necessário outro modelo.

Usando o controle de acesso baseado em função

O RBAC usa o conceito de funções. Normalmente, uma função é um título organizacional, como "Gerente", "Caixa" ou "Executivo de vendas". O RBAC mapeia essas funções de acordo com as permissões do aplicativo, de forma que a administração do controle de acesso possa ser realizada de acordo com a função de um usuário.

O RBAC converte, então, a associação da função de um usuário em permissões do aplicativo. Como as permissões são concedidas no nível da função, elas podem ser consultadas e alteradas para a função sem que recursos específicos sejam examinados.

Depois que os administradores criam as funções e atribuem permissões a elas, deve haver pouca necessidade de alterar as funções ou permissões. As únicas alterações serão a atribuição de usuários (ou grupos) às funções.

O documento "Desenvolvendo aplicativos ASP.NET com reconhecimento de identidades", desta série, descreve mais detalhadamente o que os arquitetos e desenvolvedores de aplicativos precisam fazer para integrar aplicativos à infra-estrutura.