Uma dos principais benefícios de usar produtos construídos para serem executados em multi plataformas e suportar produtos de diferentes fornecedores é que um dia você REALMENTE utilize este BENEFÍCIO.
Em meus 10 anos trabalhando com TI sempre participei de construção de soluções que permitissem que componentes fossem pensados e construídos para permitir um (des)acoplamento. Há vários anos venho trabalhando com produtos IBM tendo o WebSphere Portal como o principal foco.
Recentemente, um cliente veio com a pergunta: qual o esforço necessário para migrar as configurações do nosso Portal que utiliza um produto LDAP do fornecedor A para um produto LDAP do fornecedor B?
Até então você pode pensar: o esforço é minimo, já que o Portal reconheceria a estrutura LDAP perfeitamente. E se eu agora der mais detalhes dizendo que o LDAP A é o MS-AD e o LDAP B é o Novell e-Directory? Bom, ai as coisas mudam um pouco de figura, já que a estrutura LDAP dos 2 produtos são diferentes. E se eu colocar uma pimentinha dizendo que a estrutura de usuários e grupos que será criada no Novell e-Directory será diferente da atual estrutura no MS-AD?
Neste cenário, seremos obrigados a executar algumas configurações para adequar a estrutura de permissionamento e segurança no WCM, nas páginas e portlets e regras de personalização.
Vejam o que acontecem com testes itens quando o LDAP com a estrutura nova é adicionada e o LDAP com a estrutura velha é removido.
Ocorrência no WCM
Todas as referências aos usuários e grupos foram apresentadas com o DN (Distinguished Name) dos componentes sendo apresentados em sua forma completa. Isso indica que a referência não foi encontrada.
O arquivo <wp_profile>\PortalServer\wcm\shared\app\config\wcmservices\MemberFixerModule.properties foi alterado para adicionar os mapeamentos de à para. Foram adicionadas as linhas:
cn=grupo01,cn=users,dc=novell,dc=corp -> cn=grupo01,ou=grupos,ou=empresa,o=poc
cn=grupo06,cn=users,dc=novell,dc=corp -> cn=grupo01,ou=grupos,ou=empresao=poc
Esta ação mapeia os grupos com DN inválidos para os grupos com DN válidos.
Após este mapeamento, foi executado o comando (URL) do MemberFixer para avaliar o que seria identificado e como seria corrigido. O comando do MemberFixer
http://portal.empresa.corp:10040/wps/wcm/connect?MOD=MemberFixer&library=Web%20Content&norealm_dn=true&mismatched=update&alt_dn=update&invalid_dn=update
Este comando varre a biblioteca indicada e informa no arquivo SystemOut o que pode ser corrigido. Algo como:
Varrendo o nome do Objeto: ldif, 0d78178042430f259fecdf5b51d42682 Tipo de objeto: com.aptrix.pluto.cmpnt.FileResourceCmpnt.
Renomeando o Membro CN=grupo01,CN=Users,DC=novell,DC=corp para cn=grupo01,ou=grupos,ou=empresa,o=poc.
Após uma validação do MemberFixer, reexecutamos o comando adicionando o parâmetro “fix=true” para que as alterações sejam efetivadas.
http://portal.empresa.corp:10040/wps/wcm/connect?MOD=MemberFixer&library=Web%20Content&norealm_dn=true&mismatched=update&alt_dn=update&invalid_dn=update&fix=true
Eventualmente, usuários não mapeados do arquivo MemberFixerModule serão renomeados para o usuário administrador do Portal e grupos não mapeados do arquivo MemberFixerModule serão renomeados para o grupo referente ao administrador do WCM.
Ocorrência com Páginas, Etiquetas e URLs
Todas as referências aos usuários e grupos foram apresentadas como “fantasmas”, ou seja, ficaram registrados no permissionamento fisicamente mas não foram exibidos corretamente.
Para solucionar esta questão, a página “raiz” (principal) foi exportada com geração do arquivo XML “pageExport.xml”. A imagem abaixo ilustra um trecho de código referente à página chamada “Página 1” onde podem ser vistos os mapeamentos para usuários e grupos com DN “…dc=novell,dc=corp”.
O conteúdo deste arquivo foi editado e as referências aos usuários e grupos não mais existentes foram alteradas.
Posteriormente, o arquivo “pageExport.xml” foi novamente importado, fazendo com que as referências incorretas fossem mantidas e as referências corretas fossem adicionadas.
Para remover as referências inválidas após correção, o script xmlaccess foi executado utilizando o modelo “CleanupUser.xml” (configurações padrão).
Após a finalização do script, todas as referências inválidas foram removidas.
Conclusão
Tanto para os problemas apresentados no WCM quanto para os demais recursos do Portal, as soluções apresentadas aqui são viáveis e simples, sendo necessário apenas tempo para os mapeamentos de -> para dos novos DNs.
