Integração – Content Server & Active Directory

O Content Server é desenhado para 2 tipos de usuário e 2 tipos de administradores:

Consumers: Usuários que necessitam somente: procurar, achar, visualizar e imprimir arquivos.

Contributors: Usuários que precisam criar e revisar arquivos.

Administrators: Administradores que supervisionam uma instância inteira.

Sub-administrators: Administradores que supervisionam um subconjunto ou parte de uma instância.

Em um cenário típico, a maioria dos usuários são Consumers. Esses usuários não necessitam de um user name e um password para acessar o Content Server a menos que alguma política de segurança seja aplicada aos arquivos. Para garantir a integridade dos arquivos, os Contributors necessitam de um user name e um password para fazer check-in de arquivos no sistema.

Normalmente a maioria dos administradores são sub-administradores. Eles administram “porções” do software que correspondem às permissões que o System Administrator atribui a eles.

O Oracle Content Server oferece 2 tipos de segurança no que diz respeito ao conteúdo: security groups (que são obrigatórios) e accounts (que são opcionais). Cada item de conteúdo é relacionado com um security group, e se você utilizar accounts, os items de conteúdo podem ser relacionados também com uma account. Aos usuários são atribuídos certos níveis de permissão (Read, Write, Delete, ou Admin) para cada security group e account, que lhes permitam trabalhar com apenas um item de conteúdo, na medida em que tenha permissões para o item de segurança do security group e/ou da account.

ad_structure

Nesse caso um usuário pode ser atribuido a um grupo que tem um DN (distinguished name):

cn=Project1 OU=TopSecret, OU=Accounts, OU=Stellent, dc=company, dc=com

USUÁRIOS EXTERNOS

Usuários que são autenticados através de mecanismos de segurança externa (Active Directory ou LDAP) são considerados usuários externos no Content Server. A primeira vez que o usuário logar no Content Server, ele será adicionado na tabela USERS do banco de dados, e os administradores do sistema podem ver informações sobre esse usuário através do Repository Manager. Entretanto, usuários externos não são incluidos nas user lists, como o campo Author por exemplo numa página de Check-In. Por padrão, a integração com os mecanismos de segurança externa mapeia somente alguns dados sobre o usuário (user name, password, roles, e accounts). Se você está usando integração com o  Active Directory ou LDAP, informações adicionais sobre o usuário, como endereço de e-mail ou local do usuário, podem ser mapeados para a página de administração do Content Server.

Algumas restrições de segurança do Content Server:

Web Server: IIS 5.0 ou mais recente.

Usuários: Usuários devem estar em um grupo global ou local no domínio do Windows

PROCESSO DE AUTENTICAÇÃO NO ACTIVE DIRECTORY

Quando a segurança do Active Directory é integrada com o Content Server, o IIS e o filtro do webserver trabalham da seguinte maneira para autenticar um usuário:

1. O cliente faz uma requisição para o IIS.

2. Se alguma credencial é exigida para fazer essa requisição, o filtro do web server verifica se o usuário está definido como um usuário interno no Content Server.

• Se o usuário é definido como um usuário local ou global do Content Server, as roles, accounts, e os atributos do usuário definidos no Content Server são usados.

•Se o usuário não está definido, ou é definido somente como um usuário externo no Content Server, o filtro do web server aplica a seguinte sequência:

a. O web server faz uma requisição para o Active Directory requerendo o password do usuário.

b. O filtro do web server valida o password do usuário.

c. Quando essa etapa é concluida com sucesso, o filtro do web server recupera o grupo ao qual pertence o usuário do servidor do Active Directory.

d. O grupo do Active Directory ao qual o usuário pertence é mapeado para as roles e accounts do Content Server.

e. O filtro do web server recupera informações sobre o usuário, como o e-mail e o tipo de usuário do servidor do Active Directory.

3. Se essa requisição for uma CGI URL, a requisição é repassada ao Content Server junto com as roles e accounts do usuário.

4. Se essa requisição for uma URL estática, o filtro do web server vai checar as roles e accounts do usuário para verificar se o usuário tem permissões suficientes para acessar aquela requisição.

MAPEANDO ROLES E ACCOUNTS

Quando o Active Directory está integrado com o Content Server, o grupo no Active Directory ao qual o usuário pretence, é mapeado junto com as roles e accounts:

Se um nome do grupo é analisado como uma role e corresponde ao nome de um role no Content Server, é concedido ao usuário permissões baseadas nesse papel.

Se o nome do grupo é analisado como uma account, o usuário é atribuído à essa account; você pode criar novas accounts de grupos do Active Directory dessa maneira.

Se os nomes dos grupos no AD não baterem com as roles ou accounts no Content Server, eles serão ignorados.

Permissões nas accounts são determinadas pelo nome do grupo em si ou pela permissão default.

GROUP FILTERING (ROLES E ACCOUNT PREFIXES)

Group Filtering são usados para especificar quais partes dos grupos do Active Directory vão ser mapeados para as roles e accounts do Content Server.

Quando o Group Filtering está habilitado no Active Directory Configuration Page os campos Role Prefix e Account Prefix são usados para filtrar cada nome de grupo de usuário. Você pode especificar um número ilimitado de roles prefixes e account prefixes, que na verdade são substrings que são comparadas com cada group name do Active Directory. Se um prefixo de uma substring é achado em um group name, o resto do group name depois desse prefixo (a um nivel mais baixo na árvore de diretórios) será entendido como uma role ou account.

O resultado do mapeamento da role e account depende se a setting: Full Group Names estiver habilitada. Se estiver desabilitada, todos os group names serão entendidas como Content Server roles, de acordo com as configurações do Full Group Names. Cada role prefix e account prefix tem que ter um parâmetro Depth, que especifica número máximo dos níveis que podem existir entre o prefixo e a última unidade do group name, para que o grupo seja considerado uma role ou account válida.

Coloque um asterisco (*) no parâmetro depth para que um determinado prefixo garanta um nome curto para qualquer grupo mapeado. Por exemplo, para um grupo com um DN CN=TestApp,OU=Apps,OU=Roles,[LdapSuffix]:

Role Prefix > Role Name
OU=Roles[4] > Apps/TestApp
OU=Roles[*4] > TestApp

O exemplo abaixo são prefixos de roles e accounts, onde a árvore de diretórios inclui uma OU chamada Stellent, com OU’s “filhas” chamadas de Roles e Accounts:

Role Prefix: OU=Roles,OU=Stellent
Account Prefix: OU=Accounts,OU=Stellent

Nota: Não inclua espaços antes ou depois das vírgulas que separam os prefixos.

O Content Server transforma qualquer % numa barra (/) para fazer estruturas hierárquicas. Por examplo, um Group Name FOO%BOO%BASH é mapeado para a account como FOO/BOO/BASH.

EXEMPLO DE MAPEAMENTO DE ROLES

Group: CN=admin,OU=Mgr,OU=Dept,OU=Roles,OU=Stellent,dc=company,dc=com
Role Prefix: OU=Roles,OU=Stellent[2]
Group Filtering Full Group Names Result
Enabled Enabled Role = Dept/Mgr/admin
Enabled Disabled Role = admin
Disabled Enabled Role = Stellent/Roles/Dept/Mgr/admin
Disabled Disabled Role = admin

EXEMPLO DE MAPEAMENTO DE ACCOUNT

Group: CN=admin,OU=Mgr,OU=Dept,OU=Accounts,OU=Stellent,dc=company,dc=com
Role Prefix: OU=Accounts,OU=Stellent[2]
Group Filtering Full Group Names Result
Enabled Enabled Account = Dept/Mgr/admin
Enabled Disabled Account = admin
Disabled Enabled Role = Stellent/Accounts/Dept/Mgr/admin
Disabled Disabled Role = admin

PERMISSÕES EM ACCOUNTS

Permissões em accounts podem ser especificadas da seguinte maneira:

Nas account settings especifique o Default Network Accounts na página Active Directory Configuration. O default é #none(RWDA), o que significa que os usuários do Active Directory tem permissões de Administrador para todos os items de conteúdo que não são ligados à uma account.

Segue abaixo uma série de passos para integrar o UCM (UNIVERSAL CONTENT MANAGEMENT) com o  Microsoft Active Directory

1. Criar uma OU no Active Directory chamada Stellent

2. Criar uma sub-OU debaixo de Stellent chamada Roles

3. Debaixo de Roles, crie os Security Groups do AD com o mesmo nome das Roles do UCM (ex. contributor, admin)

4. Na Home Page do Content Server, abra a página Admin Server

5. Abra o Content Server instance que sera integrada ao AD

6. Abra a página Internet Configuration

7. Na opção Microsoft Security escolha a opção Active Directory Security

8. Restarte o Content Server

9. No Content Server Home Page, debaixo de Administration abra a página Filter Administration

10. No Active Directory Security, clique no link Configure

11. Abaixo de Role Prefix, adicione o seguinte “OU=Roles,OU=Stellent”

12. Clique em Update

13. Restarte o Content Server e o IIS


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s