Café com Tecnologia

O WAS (WebSphere Application Server) permite que você defina usuários para acessar a console de administração com 4 possíveis regras:

• administrator
• operator
• configurator
• monitor

Esse é um recurso interessante pois permite você delegar responsabilidades para equipes distintas de seu cliente.

Porém, fazer essa configuração para administrar um Portal Server (versão 6.0) não é uma tarefa tão direta. É fácil, mas não tão direta.

Vou expor um cenário prático (e real) considerando um servidor Portal Server com segurança habilitada para um servidor LDAP.

Veja os passos para adicionar um usuário para acessar a console do WAS.

1 – Criar um usuário no LDAP

Crie um usuário no LDAP em qualquer ponto. Para exemplificar, foi criado o usuário “usuariotutorial” com senha “novasenha”. Vamos supor que o DN de seu usuário ficou “uid=usuariotutorial, ou=empregado, o=empresa.com”.

2 – Adicionar o usuário no console do WAS

Autentique com seu usuário administrador e adicione o usuário “usuariotutorial”, apenas o uid do seu usuário. Vá em “Administração do Sistema > Usuários do Console”.

Administração do Sistema

Clique no botão “Incluir”, digite “usuariotutorial”, selecione a função “Monitor” e clique em Aplicar.

Incluir Usuário no console

Você notará que o WAS aceitará seu usuário, uma vez que verifica sua existência no servidor LDAP usado para autenticação.

Usuário adicionado no Console para administração

Bom, a partir de agora você com certeza estará tentado a fazer um teste de autenticação com o usuário recém autenticado. Mas já lhe adianto: NÃO FUNCIONARÁ. Você notará no arquivo SystemOut.log do seu servidor do Portal a ocorrência a seguir.

SECJ0129E: Falha na autorização para usuariotutorial ao chamar GET em admin_host:/ibm/console/, Authorization failed, Not granted any of the required roles: administrator operator configurator monitor

E é aqui que entra uma configuração “adicional”.

3 – Alterar arquivo wmmWASAdmin.xml

Faça a edição do arquivo <portal_server_root>/wmm/wmmWASAdmin.xml e adicione o codigo XML a seguir.

  <admin logonId="usuariotutorial" logonPassword="bzv+ZzQoyHqUgewCtI1sIw==" uniqueUserId="uid=usuariotutorial, ou=empregado, o=empresa.com"/>

Note que em “logonPassword” há um código encriptado. Esse código pode ser gerado usando o script WPSconfig.[sh|bat].

./WPSconfig.sh wmm-encrypt -DPassword=novasenha

Esse comando terá uma saída como da imagem abaixo.

WPSconfig Encriptar Senha

4 – Reiniciar seu servidor

É isso ai, para terminar, reinicie seu servidor de Portal Server e teste a autenticação.

Achou simples? Que bom. Mas é um saco. Felizmente nas versões mais atuais isso é mais direto, como este blog.

Aplicações comerciais, normalmente, passam por um período de desenvolvimento, programação, “bate-tecla”, etc. E em algum momento, a aplicação será TESTADA em um ambiente de Aceite/Homologação e, somente após essa fase, será implantada em um ambiente de Produção. Simples né?

Já vi muitos casos de que implementações requererem a alteração de informações em arquivos de propriedades para que seja gerado um artefato (EAR/WAR) para ser implantado em Aceite. E pior, essa mesma propriedade tendo um valor diferente para ambiente de Produção, tendo o desenvolvedor que alterar novamente o valor de uma propriedade antes de gerar o artefato para Produção.

Além disso ser um absurdo, pode acabar acarretando de o valor ir com valor referente ao ambiente de Aceite para o ambiente de Produção, causando alguns incovenientes com o Cliente.

Para solucionar isso, vai uma dica: capturar o conteúdo de um atributo “environmento/id” definido como “Ligação de Espaços de Nomes” no servidor de aplicação (aqui, será o IBM WebSphere Application Server V6).

Configurar Ligação de Espaços de Nomes no IBM WAS V6

O primeiro passo a ser dado para realizar a adição de uma Ligação de Espaços de Nomes, é autenticar no console de administração do Application Server específico com um “ID do Usuário” que tenha permissão para realizar a atividade, ou seja, ser um “Operador”, “Configurador” ou “Administrador”.

Após autenticado, clique em “Ambiente > Nomenclatura > Ligações de Espaço de Nomes”. A ligação pode ser adicionada em um dos escopos disponíveis (célula, nó ou servidor). Clique no botão “Novo”. Selecione o tipo “Cadeia”.

Os atributos “Identificador de Ligação” e “Nome do Espaço de Nomes” devem ter o valor “environment/id”. O atributo “Valor da Cadeia” deve ter o valor DEV para um ambiente de Desenvolvimento, HOM para um ambiente de Homologação ou PRD para um ambiente de Produção.

Implementar código para capturar “environment/id”

A implementação JAVA para capturar o conteúdo de “environment/id” é relativamente simples. Crie uma classe para implementar o Design Patterns chamado Service Locator e adicione o seguinte método.

public String getString(String envName) throws ServiceLocatorException {
String envEntry = null;
try {
envEntry = (String) ic.lookup(envName);
} catch (NamingException ne) {
throw new ServiceLocatorException(ne);
} catch (Exception e) {
throw new ServiceLocatorException(e);
}
return envEntry;
}

Este método fará o lookup no atributo no application server.

Em uma segunda classe, que possa representar suas “constantes” (qual tal o nome “CommonConstants”?), adicione o código abaixo:

private static final String ENVIRONMENT_NAME_KEY = "environment/id";
public static String ENVIRONMENT;
static {
try {
ENVIRONMENT = ServiceLocator.getInstance().getString(ENVIRONMENT_NAME_KEY);
System.out.println("ENVIRONMENT=" + ENVIRONMENT);
} catch (ServiceLocatorException e) {
System.err.println("Atributo \"environment/id\" não localizado no servidor. Assumindo ambiente PRD.");
ENVIRONMENT = "PRD";
}
}

Como em algum momento do seu código você utilizará a classe de constantes, o atributo estático ENVIRONMENT será preenchido com o valor definido no atributo “environmento/id”, e com isso, você poderá utilizar uma chamada como CommonConstants.ENVIRONMENT, sem se preocupar, ENFIM, com o ambiente que sua aplicação está implantada.

Bons sonhos.