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


Convertendo Documentos com o Ghostscript 8.64 ou posterior (IBR) (DAM)

Então você tentou converter os documentos do ContentServer usando às versões mais novas do Ghostscript não é?

Ah….e adivinha….DEU ERRO!!!!

BEM aqui segue um “WORKAROUND”….mais conhecido como GAMBIARRA…para fazer o “bichinho” funcionar.

Quando o Ghostscript v8.64 ou posterior é usado, são requeridas algumas variáveis adicionais no Intradoc.cfg para que o Content Server possa se comunicar corretamente com o Ghostscript.

Neste exemplo o GhostScript 8.64 está instalado no seguinte diretório: C:\Ghostscript\gs\gpl\gs8.64

EXPORT_CUSTOM_GS_LIB=GS_LIB
CUSTOM_GS_LIB=C:/Ghostscript/gs/gpl/gs8.64/lib
EXPORT_CUSTOM_GS_DLL=GS_DLL
CUSTOM_GS_DLL=C:/Ghostscript/gs/gpl/gs8.64/bin/gsdll32.dll

A variável GS_LIB tem que ser setada no diretório /lib e a variável GS_DLL
tem que ser setada para onde está o arquivo gsdll32.dll.

A Oracle promete que futuras versões do IBR irão suportar essas versões mais novas do Ghostscript sem precisarmos fazer esse “workaround”.

Solução de Portal…Usar ou não usar?…Eis a questão!!!

Como decidir se uma solução de portal é boa ou não para meu projeto?

Muitos profissionais se perguntam qual solução adotar no seus projetos. Adoto uma solução de portal? Uma solução de WCM (Web Content Management)? Existem muitas opções de integração de aplicações como, mashups, ferramentas de ECM, widgets, desenvolvimento customizado de sites web e RIA (Rich Internet Application). Como comparar uma solução de portal com uma solução de WCM, colaboração, etc?

9 fatores que devem guiá-lo a decidir se deve ou não usar uma ferramenta de Portal

1. Você tem o “skill” e a mão-de-obra necessária para manter uma solução de portal? Mão-de-obra essa que deve ser especializada de acordo co ma complexidade da integração. Porque o TCO de projetos que envolvem soluções de Portal, variam diretamente com o número de aplicações back-end e repositórios que iremos integrar com o Front-End da nossa solução de Portal. Se você quiser adotar uma solução mais simples, pode-se pensar em uma equipe entre 3-5 colaboradores para manter sua solução de Portal no ar sempre atualizada. A chave aqui é: Quanto mais complexa a integração com múltiplas aplicações back-end, mais mão de obra especializada iremos precisar.

2. Maturidade ciclo de vida do desenvolvimento de aplicações. A equipe de TI deve ter experiência no ciclo de vida do desenvolvimento de uma aplicação. Por exemplo, deve se considerar ambientes separados para desenvolvimento, integração, teste, qualidade e produção. Portais de missão critica requerem mais atenção com Infra-Estrutura, gerenciamento de código fonte, scripts de teste, configuração de arquivos e múltiplas instâncias do Portal. Maturidade do processo e disciplina são fatores chave para o sucesso desses projetos.

3. Os profissionais de Gestão do Conhecimento devem trabalhar com os Arquitetos de Solução e a Equipe de TI para mensurar quais sistemas operacionais, bancos de dados, servidores de aplicações, ERP’s, etc para decidir qual plataforma de Portal irão adquirir. No “frigir dos ovos” quando falamos de portais, falamos de INTEGRAÇÃO, então se pudermos alinhar componentes como WCM e Portal de um único fabricante, isso pode reduzir significativamente nossa “dor-de-cabeça” no que diz respeito à integração dessas aplicações.

4. Necessidade de acesso seguro através de grupos e usuários nomeados. As soluções de portais permitem que os administradores selecionem expor diferentes páginas e portlets para diferentes grupos de usuários dependendo de suas permissões. Empresas que não possuem uma boa política de segurança da informação talvez possam optar por uma solução de WCM com segurança feita pelo servidor Web nativo.

5. Os portais oferecem vários métodos para integração com aplicações de terceiros, mas o mais recomendado é usar portles baseado no JSR-168 e no seu sucessor, o JSR-286 para portais baseados em JAVA. Empresas que necessitem de integrar muitos aplicativos de terceiros em uma única interface irão achar em uma solução de portal a melhor maneira de se fazer isso. Mas aqueles que tem limitações quanto às integrações talvez possam considerar usar uma solução básica de WCM ou uma aplicação Web customizada.

6. Portais oferecem um mecanismo para controlar o “branding” por meio de um Web Site multipart ou por meio de uma aplicação. Branding está relacionado aos elementos visuais, como classificar seu site em um mecanismo de busca, enfim tudo o que você irá fazer para tornar o seu site mais acessado. As tecnologias oferecem isso através de “skins” no quais você pode aplicar elementos XML e CSS para fins específicos de “branding”. Mas quem detém um simples site, sem complexidade de navegação ache melhor usar uma versão standard de algum portal.

7. Necessidade de customização pelos usuários finais. De acordo com uma pesquisa do instituto Forrest, menos de 20% dos funcionários de uma empresa se preocupam em customizar uma página deles em um portal da companhia que trabalham. E a customização eleva a complexidade em futuros upgrades do portal. Se você tem essa necessidade escolha um portal, se não tem, poderá usar alternativas como um WCM ou uma aplicação Web customizada.

8. Customização da interface. Para empresas que investem em design da interface, as tecnologias de portais oferecem frameworks consistentes para executar e renderizar esses designs. Versões mais novas de portais como os da IBM e Oracle começaram a adicionar novas e avançadas tecnologias como AJAX.

9. Reúso dos componentes dos portais. Os profissionais de Gestão do Conhecimento devem considerar o nivel de reuso de componentes específicos – elementos da UI (User Interface), portlests e serviços de back-end – como elementos chave. Construir uma aplicação para no futuro podermos fazer um reuso desses componentes requer um nível de especialização alto o que infelizmente muitas companhias não possuem. Se o reuso de componentes está no topo de suas prioridades considere o uso de alguma tecnologia de portal.

Baseado no paper da Forrest : Deciding Wheter Or Not To Use A Portal Platform

Oracle UCM (Universal Content Management) – Tutorial de Migração

1)Crie instâncias de desenvolvimento, teste (homologação) e produção com nomes de instância diferentes (por exemplo: ucmdev, ucmteste e ucmprod). Se todas se chamarem UCM, o servidor vai se complicar na hora que voce fizer uma importação (ele vai achar que você está restaurando um backup, e não importando de outra instância).

2)Para o componente Folders, existe uma configuração em que você define o ID inicial das pastas.

Abra o Assistente de Componentes


Uma vez aberto o Assistente de Componentes, selecione o componente no qual iremos trabalhar em cima dele, no caso, o Folders_g.


Clique na aba Install/Uninstall Settings e selecione a última linha que se chama InitialFolderID.
É nessa propriedade que iremos definir o prefixo do Content ID de forma diferente para cada instância, para evitar conflito de Content ID durante uma importação/replicação.

Cada pasta tem um ID numérico, que normalmente começa em 2. Este ID é um metadado do documento (xCollectionID), e ele é guardado apenas na forma numérica.

Imagine que você tem um servidor aonde a pasta com ID = 6 é CONTRATOS e a pasta com ID = 7 é PROPOSTAS.

Se você exportar todos os CONTRATOS e PROPOSTAS para uma nova instância, aonde a pasta com ID = 6 é NOTAS FISCAIS e não existe pasta com ID = 7, todos os CONTRATOS vão aparecer na pasta de NOTAS FISCAIS e as PROPOSTAS não vão aparecer em nenhuma pasta (embora todos os documentos estarão no repositório, uma vez que o ID da pasta é apenas um metadado). Por isso o ideal é que no ambiente de desenvolvimento as pastas comecem com ID = 1, ID = 1000 em teste (homologação), e ID = 3000 em producao, (ou alguma coisa assim, para você ter uma janela que vai evitar o overlap).

LEMBRE-SE
Defina o prefixo do Content ID de forma diferente para cada instância, para evitar conflito de Content ID durante uma importação/replicação.

3)Se você for usar o Site Studio, evite ter o banco de dados como repositório de documentos. Você pode criar regras para armazenar todos os documentos “normais” no banco e apenas o conteúdo do Site Studio na File System.

4) Agora iremos exportar a Estrutura de Pastas.

Vá ao menu Administração, depois clique em Configuração de Arquivos de Pastas

Feito isso irá aparecer uma tela como acima mostrado. Dê um nome para o Archiver da Estrutura de Pastas que será feito e selecione quais as pastas você quer importar. Feito isso é só clicar em ADD (Adicionar).


Depois vá ao Menu Administração novamente e clique agora em Admin Applets (Miniaplicativos de Administração)


Clique na opção Archiver (Arquivador) e espere uma tela se abrir.


Uma tela como a mostrada acima se abrirá e você deverá selecionar a Estrutura de Pastas recém criada que você irá exportar. Note que na Description (Descrição) do Archiver está escrito: Archiver with folder structures.
Ou seja temos a certeza que a exportação que será feita é da Estrutura de Pastas.


O que iremos fazer agora é entrar dentro da pasta “archives” no diretório aonde está instalado o UCM e copiar essa pasta, para a pasta “archives” do outro servidor aonde iremos fazer a migração.
Mas antes de fazer essa cópia iremos no servidor aonde iremos fazer a migração e criaremos um “archiver” com o mesmo nome: No exemplo aqui: “folderarchiver1”.
Você a esta altura já sabe fazer isso. É só seguir os passos ditos anteriormente nesse mesmo tutorial.

Após exportar a estrutura de pastas vamos agora fazer a Exportação\Importação dos arquivos e tabelas do sistema.

migra1

Crie um Archiver com um nome qualquer.

migra2

Depois clique em Editar da Aba GERAL e selecione a opção EXPORTAR SOMENTE TABELAS.

Isso irá fazer com que o Archiver exporte as tabelas do sistema.

Feito isso vá para o servidor aonde iremos importar essa estrutura de tabelas que acabamos de criar e crie um Archiver com o mesmo nome.

Feito isso copie a pasta gerada pelo Archiver do servidor aonde você EXPORTOU os dados, para o servidor aonde você irá IMPORTAR os dados.

Lembre-se que esta pasta encontra-se em D:\oracle\ucm\server\archives no servidor HML.

Após isso clique em Ações/IMPORTAR para que o sistema possa ler o Archiver que você acabou de copiar e começar a importação das tabelas.

Obrigado ao Denis da Oracle pela ajuda nesse post!

writing down things that go through my head…