Procedimento 3.1. Remoção da Autenticação Silenciosa do Default Security Realm

• Remoção da autenticação silenciosa com o Management CLI

  Remova o elemento local a partir do Realm de Gerenciamento e Realm do Aplicativo conforme solicitado.
  1. Remova o elemento local a partir do Realm de Gerenciamento.

     • Servidores Autônomos

       /core-service=management/security-realm=ManagementRealm/authentication=local:remove

     • Managed Domains

       /host=HOST_NAME/core-service=management/security-realm=ManagementRealm/authentication=local:remove

  2. Remova o elemento local a partir do Realm do Aplicativo.

     • Servidores Autônomos

       /core-service=management/security-realm=ApplicationRealm/authentication=local:remove

     • Managed Domains

       /host=HOST_NAME/core-service=management/security-realm=ApplicationRealm/authentication=local:remove

Procedimento 4.1. Edição dos Arquivos de Configuração

1. Abra o arquivo de configuração

   Abra o arquivo de configuração para edição. Este arquivo está localizado em dois locais, dependendo de você estar usando um managed domain ou servidor autônomo. Este não é um arquivo executável usado para usar o servidor ou domain.

   • Managed Domain

     EAP_HOME/bin/domain.conf

   • Servidor Autônomo

     EAP_HOME/bin/standalone.conf

2. Adição das opções Java no final de cada arquivo.

   Adicione a seguinte linha no final do arquivo. Você pode modificar o valor -Djava.security.policy para especificar a localização exata de sua política de segurança. Isto deve ocorrer em uma linha, sem quebra de linha. Você pode modificar o -Djava.security.debug para efetuar o log de mais ou menos informações pela especificação do nível de depuração. O mais verboso é failure,access,policy.

   JAVA_OPTS="$JAVA_OPTS -Djava.security.manager -Djboss.home.dir=$PWD/.. -Djava.security.policy==$PWD/server.policy -Djava.security.debug=failure"
   
   

3. Início do domain ou servidor.

   Inicie o domain ou servidor como o normal.

Procedimento 4.2. Configuração de uma nova Política do Java Security Manager

1. Inicie o policytool.

   Inicie a ferramenta policytool em uma das seguintes manerias:

   • Red Hat Enterprise Linux

     A partir de seu GUI ou prompt de comando, execute o /usr/bin/policytool.

   • Servidor Microsoft Windows

     Execute o policytool.exe a partir do menu de Iniciação ou do bin\ de sua instalação do Java. A localização pode variar.

2. Criação de uma nova política.

   Selecione Add Policy Entry para criar uma nova política. Adicione parâmetros que você precisa, e clique em Done.

3. Edição de uma política existente

   Selecione a política a partir da lista das políticas existentes e selecione o botão Edit Policy Entry. Edite os parâmetros conforme seja necessário.

4. Exclusão de uma política existente.

   Selecione a política da lista de políticas existentes e selecione o botão Delete Policy Entry.

Procedimento 4.3. Habilitação de depuração geral

• Este procedimento irá habilitar o nível geral de sensibilidade da informação de depuração relacionada com segurança.

  Adição da seguinte linha ao arquivo de configuração do servidor.

  • Caso a instância do JBoss Enterprise Application Plataform estiver sendo executada num managed domain, a linha é adicionada ao arquivo bin/domain.conf para o Linux ou arquivo bin/domain.conf.bat para Windows.
  • Caso a instância do JBoss Enterprise Application Plataform estiver sendo executada como um servidor autônomo, a linha é adicionada ao arquivo bin/standalone.conf para o Linux ou arquivo bin\standalone.conf.bat para o Windows.

Procedimento 5.1. Subscrição à Lista de Vigilância do JBoss

1. Clique no seguinte link para ir à página de lista de correio de Vigilância do JBoss: JBoss Watch Mailing List.
2. Insira o endereço de e-mail na seção Subscribing to Jboss-watch-list
3. [Você pode optar em inserir o seu nome e selecionar uma senha. Isto é opcional, porém recomendável.]
4. Pressione o botão Subscribe para iniciar o processo de subscrição.
5. Você pode navegar nos arquivos da lista de correio através do: JBoss Watch Mailing List Archives.

Procedimento 5.2. Aplicação de um patch a um produto do JBoss através do método zip.

1. Obtenha informações sobre o patch de segurança tanto pela subscrição da lista de correio de vigilância do JBoss ou pela navegação nos arquivos da lista de correio de vigilância do JBoss.

   Nota

   Apenas patches de segurança são comunicados na lista de correio de vigilância do JBoss.
2. Leia a errata para o patch de segurança e certifique-se de que está aplicado a um produto do JBoss em seu ambiente.
3. Caso o patch de segurança for aplicado a um produto do JBoss em seu ambiente, siga as instruções do link para baixar o patch do Portal do Cliente Red Hat.
4. O arquivo zip que pode ser baixado a partir do portal do cliente terá todos os arquivos solicitados para corrigir o problema de segurança ou bug. Baixe este arquivo zip do patch na mesma localização do seu produto JBoss.
5. Desfaça o zip do arquivo patch na mesma localização onde o produto JBoss é instalado. As versões patch substituem os arquivos existentes.

Procedimento 5.3. Aplicar um patch a um produto JBoss através do método RPM.

1. Receba informação sobre o patch de segurança tanto sendo subscrito na lista de correio de vigilância do JBoss ou navegando pelos arquivos da lista de correio de vigilância do JBoss.
2. Leia a errata para o patch de segurança e certifique-se de que está aplicado a um produto do JBoss em seu ambiente.
3. Caso o patch de segurança for aplicado a um produto JBoss em seu ambiente, siga instruções do link para baixar o pacote RPM atualizado que está incluso na errata.
4. Use

   yum update

   ou um comando similar para instalar o patch.

Procedimento 6.1. Determine as Configurações da Autenticação para o Security Domain

1. Abra a visualização detalhada do security domain.

   Clique no rótulo Profiles na parte superior direita do management console. Num managed domain, selecione o perfil para modificar a caixa de seleção Profile na parte esquerda da visualização do Perfil. Clique no item do menu Security no lado esquerdo e clique no Security Domains a partir do menu expandido. Clique no link View para o security domain que você deseja editar.

2. Navegação à configuração do subsistema de Autenticação.

   Clique no rótulo Authentication no topo da visualização caso não esteja selecionado.
   A área de configuração é dividida em duas áreas: Login Modules e Details. O módulo de login é a unidade básica da configuração. O security domain pode incluir diversos módulos de login, cada qual pode incluir diversos atributos e opções.

3. Adição do módulo de autenticação.

   Clique no botão Add para adicionar um módulo de autenticação JAAS. Preencha os detalhes para o seu módulo. O Code é o nome da classe do módulo. O Flags controla como o módulo relata aos demais módulos de autenticação com o mesmo security domain.
   Explicação dos Avisos

   A especificação do Java Enterprise Edition 6 fornece a seguinte explicação dos avisos dos módulos de segurança. A seguinte lista é retirada do http://docs.oracle.com/javase/6/docs/technotes/guides/security/jaas/JAASRefGuide.html#AppendixA. Refira-se ao documento para maiores informações.

   Sinalizador	Detalhes
   Solicitado	O LoginModule é requerido para suceder. Caso isto suceda ou falhe, a autenticação continua a proceder na lista do LoginModule.
   Requisito	O LoginModule é requerido para ser sucedido. Caso ele seja bem sucedido, a autenticação continua a checagem da lista LoginModule. Caso isto falhe, o controle retorna imediatamente ao aplicativo (a autenticação não procede a checagem na lista LoginModule).
   Suficiente	O LoginModule não é solicitado para ser sucedido. Caso não seja sucedido, o controle retorna imediatamente ao aplicativo (a autenticação não procede a lista LoginModule). Caso isto falhe, a autenticação continua na listagem do LoginModule.
   Opcional	O LoginModule não é requerido para ser sucedido. Caso ele suceda ou falhe, a autenticação continua a proceder na lista do LoginModule.

   Após você adicionar o módulo, você pode modificar o seu Code ou Flags apenas clicando no botão Edit da seção Details da tela. Certifique-se de que a tab Attributes é selecionada.

4. Opcional: Adicione, edite ou remova as opções do módulo.

   Caso você precise adicionar opções ao seu módulo, clique na sua entrada na lista Login Modules e selecione a tab Module Options na seção Details da página. Clique no botão Add e forneça a chave e o valor para a opção. Para editar uma opção que já existe, clique na chave ou para alterá-la. Use no botão Remove para remover uma opção.

Procedimento 6.2. Determinação da Autorização num Security Domain

1. Abra a visualização detalhada do security domain.

   Clique no rótulo Profiles no lado direito superior do management console. Num managed domain, selecione o perfil para modificação a partir da caixa de seleção Profile na parte esquerda superior da visualização do Perfil. Clique no item do menu Security ao lado esquerdo e clique em Security Domains ao lado esquerdo e no menu expandido. Clique no link View para o security domain que você deseja editar.

2. Navegação à configuração do subsistema de Autorização.

   Clique no rótulo Authorization na parte superior da visualização caso ele não esteja selecionado.
   A área de configuração está dividida em duas áreas: Policies e Details. O módulo de login é uma unidade básica de configuração. O security domain pode incluir diversas políticas de autorização, cada qual pode incluir diversos atributos e opções.

3. Adição da política.

   Clique no botão Add para adicionar um módulo de política de autorização JAAS. O Code é o nome da classe do módulo. Preencha os detalhes para o seu módulo. O Flags controla como o módulo relata aos outros módulos de política da autorização com o mesmo security domain.
   Explicação dos Sinalizadores

   A especificação do Java Enterprise 6 fornece a seguinte explicação dos sinalizadores para os módulos de segurança. A seguinte lista foi obtida a partir do http://docs.oracle.com/javase/6/docs/technotes/guides/security/jaas/JAASRefGuide.html#AppendixA. Refira-se ao documento para maiores informações.

   Sinalizador	Detalhes
   Solicitado	O LoginModule é requerido para suceder. Caso isto suceda ou falhe, a autorização continua a proceder na lista do LoginModule.
   Requisito	O LoginModule é requerido para suceder. Caso ele suceda, a autorização continua na lista do LoginModule. Caso falhe, o controle retorna imediatamente ao aplicativo (a autorização não procede na lista do LoginModule).
   Suficiente	O LoginModule não é solicitado para ser sucedido. Caso não seja sucedido, o controle retorna imediatamente ao aplicativo (a autorização não procede a lista LoginModule). Caso isto falhe, a autenticação continua na listagem do LoginModule.
   Opção	O LoginModule não é requerido para suceder. Caso isto suceda ou falhe, a autorização continua a proceder na lista do LoginModule.

   Após você adicionar o módulo, você pode modificar o seu Code ou Flags apenas clicando no botão Edit da seção Details da tela. Certifique-se de que a tab Attributes é selecionada.

4. Opcional: Adicione, edite ou remova as opções do módulo.

   Caso você precise adicionar opções ao seu módulo, clique na sua entrada na lista Login Modules e selecione a tab Module Options na seção Details da página. Clique no botão Add e forneça a chave e o valor para a opção. Para editar uma opção que já existe, clique na chave ou para alterá-la. Use no botão Remove para remover uma opção.

Procedimento 6.3. Configuração de Auditoria de Segurança para o Security Domain

1. Abra a visualização detalhada do security domain.

   Clique no rótulo Profiles na parte direita superior do management console. Num servidor autônomo, a tab é rotulada Profile. Num managed domain, selecione o perfil para modificar a partir da caixa de seleção Profile da visualização do Perfil. Clique no item do menu Security no parte esquerda e clique no Security Domains a partir do menu expandido. Clique no link View para o security domain que você deseja editar.

2. Navegação à configuração do subsistema de Auditoria.

   Clique no rótulo Audit na parte superior da visualização caso ainda não esteja selecionado.
   A área de configuração está dividida em duas áreas: Provider Modules e Details. O módulo provedor é a unidade básica de configuração. O security domain pode incluir diversos módulos de provedor, cada qual inclui atributos e opções.

3. Adição de um módulo de provedor.

   Clique no botão Add para adicionar um módulo de provedor. Preencha a seção Code com o nome da classe do módulo do provedor.
   Após a adição do módulo, você pode modificar seu Code apenas clicando no botão Edit da seção Details da tela. Certifique-se de que a tab Attributes está selecionada.

4. Verifique se o seu módulo está funcionando

   O objetivo de um módulo de auditoria é fornecer uma maneira de monitorar os eventos no subsistema de segurança. Este monitoramento pode ser realizado por gravação de um arquivo de log, notificações de e-mail ou qualquer outro mecanismo de auditoria mensurável.
   Por exemplo, o JBoss Enterprise Application Server inclui o módulo LogAuditProvider por default. Caso habilitado seguindo as etapas acima, este módulo de auditoria grava as notificações de segurança a um arquivo audit.log na subpasta log com o diretório EAP_HOME.
   Para verificar se as etapas acima funcionaram no contexto do LogAuditProvider, execute uma ação que provavelmente efetuará o trigger na notificação e então verifique o arquivo do log de auditoria.
   Para uma lista completa dos módulos do provedor de auditoria de segurança, consulte: Seção A.4, “Módulos do Fornecedor de Auditoria de Segurança Incluídos”

5. Opcional: Adicione, edite ou remova as opções do módulo.

   Caso você deseje adicionar as opções ao seu módulo, clique sua entrada na lista Modules e selecione a tab Module Options na seção Details da página. Clique no botão Add e forneça a chave e o valor para a opção. Para editar uma opção que já exista, remova-a clicando no rótulo Remove e adicione-a novamente com as opções corretas clicando no botão Add.

Procedimento 6.4. Determinação das Configurações de Mapeamento num Security Domain

1. Abra a visualização detalhada do security domain.

   Clique no rótulo Profiles na parte superior do management console. Esta tab é rotulada Profile num servidor autônomo. Num managed domain, selecione o perfil para modificar a partir da caixa de seleção Profile na parte esquerda da visualização do Perfil. Clique no item do menu Security na parte esquerda e clique no Security Domains a partir do menu expandido. Clique no link View para o security domain que você precisa editar.

2. Navegação à configuração do subsistema de Mapeamento.

   Clique no rótulo Mapping no topo da visualização caso ele não esteja selecionado.
   A área de configuração está divida em duas áreas: Modules e Details. O módulo de mapeamento é uma unidade básica de configuração. O security domain pode incluir diversos módulos de mapeamento, cada qual pode incluir diversos atributos e opções.

3. Adição de um módulo.

   Clique no botão Add para adicionar o módulo de mapeamento de segurança. Preencha os detalhes para o seu módulo. O Code é o nome da classe do módulo. O campo Type refere-se ao tipo de mapeamento que este módulo executa. Os valores permitidos são principal, função, atributo ou credencial.
   Após você ter adicionado o seu módulo, você pode modificar o seu Code ou Type apenas clicando no botão Edit na seção Details da tela. Certifique-se que a tab Attributes é selecionada.

4. Opcional: Adicione, edite ou remova as opções do módulo.

   Caso você precise adicionar opções ao seu módulo, clique na sua entrada na lista Modules e selecione a tab Module Options na seção Details da página. Clique no botão Add e forneça a chave e o valor para a opção. Para editar uma opção que já existe, clique na chave do rótulo Remove para removê-la e adicione-a novamente com um novo valor. Use no botão Remove para remover uma opção.

Procedimento 7.1. Configuração do JBoss Web Server para uso dos HTTPS

1. Adicione um novo conector HTTPS.

   Execute o seguinte comando Management CLI, alterando o perfil conforme apropriado. Isto cria um novo conector de segurança, chamado HTTPS, que usa o esquema https, o socket binding https (do qual o default é 8443), e é configurado para possuir segurança.

   Exemplo 7.1. Comando Management CLI

   /profile=default/subsystem=web/connector=HTTPS/:add(socket-binding=https,scheme=https,protocol=HTTP/1.1,secure=true)
   

2. Configuração do certificado e chaves de criptografia SSL.

   Execute os seguintes comandos para configuração de seu certificado SSL, substituindo os seus próprios valores para aos da amostra. Esta amostra assume que o keystore é copiado ao diretório da configuração do servidor, que é o EAP_HOME/domain/configuration/ para o managed domain.

   Exemplo 7.2. Comando Management CLI

   /profile=default/subsystem=web/connector=HTTPS/ssl=configuration:add(name=https,certificate-key-file=${jboss.server.config.dir}/keystore.jks,password=SECRET, key-alias=KEY_ALIAS)
   

   Para uma listagem completa de parâmetros que você pode configurar para as propriedades SSL do conector, refira-se à Seção 7.4, “Referência do Conector SSL”.

3. Implantação de um aplicativo

   A implantação de um aplicativo a um grupo do servidor que usa o perfil que você configurou. Caso você use um servidor autônomo, implante o aplicativo ao seu servidor. As solicitações HTTP solicitam que isto use a nova conexão criptografada SSL.

Procedimento 7.2. Criação de uma Chave de Criptografia SSL e Certificado

1. Geração de um keystore com as chaves pública e privada.

   Execute o seguinte comando para gerar um keystore nomeado server.keystore com o alias jboss no seu diretório atual.

   keytool -genkey -alias jboss -keyalg RSA -keystore server.keystore -storepass mykeystorepass --dname "CN=jsmith,OU=Engineering,O=mycompany.com,L=Raleigh,S=NC,C=US"

   A seguinte tabela descreve os parâmetros usados no comando keytool:

   Parâmetro	Descrição
   -genkey	O comando keytool para gerar um par de chave contendo uma chave pública e privada.
   -alias	O alias para o keystore. Este valor é arbritário, porém o alias jboss é o default usado pelo servidor do JBoss Web.
   -keyalg	O algoritmo de geração par da chave. Neste caso ele é o RSA.
   -keystore	O nome e a localização do arquivo keystore. A localização default é o diretório atual. O nome que você escolher é arbitrário. Neste caso, o arquivo será nomeado server.keystore.
   -storepass	Essa senha é usada para autenticar ao keystore de forma que a chave pode ser lida. A senha deve ser pelo menos de 6 caracteres e deve ser fornecida quando o keystore é acessado. Neste caso, nós usamos o mykeystorepass. Caso você omitir este parâmetro, você será solicitado a inserir o mesmo quando você executar o comando.
   -keypass	Esta é a senha para a chave atual. Nota Devido à limitação da implementação, ela deve ser a mesma senha à senha do store.
   --dname	A sequência cotada descrevendo o nome distinguido para a chave, por exemplo: "CN=jsmith,OU=Engineering,O=mycompany.com,L=Raleigh,C=US". Essa sequência é a concatenação dos seguintes componentes: CN - O nome comum ou nome do host. Caso o hostname seja "jsmith.mycompany.com", o CN será "jsmith". OU - A unidade da organização, por exemplo: "Engineering" O - O nome da organização, por exemplo "mycompany.com". L - A localidade, por exemplo: "Raleigh" ou "London" S - O estado ou província, por exemplo: "NC". Este parâmetro é opcional. C - O código de suas letras do país, por exemplo: "US" ou "UK",

   Quando você executar o comando acima, você será solicitado a seguinte informação:

   • Caso não tenha usado o parâmetro -storepass na linha de comando, você será solicitado a inserir a senha keystore. Reinicie a nova senha na próxima solicitação.
   • Caso não tenha usado o parâmetro -keypass na linha de comando, você será solicitado a inserir a senha chave. Pressione Enter para configurá-la no mesmo valor ao da senha keystore.
   Quando o comando completar, o arquivo server.keystore conterá a chave única com o alias jboss.

2. Verifique a chave.

   Verifique se a chave funciona de forma apropriada usando o seguinte comando:

   keytool -list -keystore server.keystore

   A senha é solicitada com o objetivo de autenticar o keystore. Os conteúdos do keystore são exibidos (neste caso, uma chave única chamada jboss). Perceba o tipo da chave jboss, que é keyEntry. Isto indica que o keystore contém ambas entradas privada e pública para esta chave.

3. Geração de um certificado assinando uma solicitação.

   Execute o seguinte comando para gerar um certificado assinando solicitação usando a chave pública e privada a partir do keystore que você criou na etapa 1.

   keytool -certreq -keyalg RSA -alias jboss -keystore server.keystore -file certreq.csr

   A senha é solicitada com o objetivo de autenticar o keystore. O comando keytool então cria um novo certificado assinando a solicitação chamada certreq.csr no seguinte diretório de trabalho.

4. Teste o certificado recentemente gerado.

   Teste os conteúdos do certificado usando o seguinte comando.

   openssl req -in certreq.csr -noout -text

   Os detalhes do certificado são apresentados.

5. Opcional: Submeta o seu certificado a um Certificate Authority (CA - Autoridade de Certificado).

   O Certificate Authority (CA) pode autenticar o seu certificado de forma que isto é considerado de confiança por clientes de terceiros. O CA fornece um certificado assinado e opcionalmente um ou mais certificados intermediários.

6. Opcional: Exporte um certificado autoassinado a partir do keystore.

   Caso você precisar disto para testes ou propósitos internos, você pode usar um certificado autoassinado. Você pode expor um do keysotre que você criou na etapa 1, conforme abaixo:

   keytool -export -alias jboss -keystore server.keystore -file server.crt

   Você será solicitado a fornecer a senha com o objetivo de autenticar o keystore. O certificado autoassinado, nomeado server.crt, é criado no diretório de trabalho atual.

7. Importe o certificado assinado, juntamente com quaisquer certificados intermediários.

   Importe cada certificado na ordem que você está instruído pelo CA. Para cada certificado a ser importado, substitua o intermediate.ca ou server.crt pelo nome do arquivo atual. Caso os seus certificados não forem fornecidos como arquivos separados, crie um arquivo separado para cada certificado e cole os seus conteúdos no arquivo.

   Nota

   O seu certificado assinado e chaves do certificado são bens de valor. Tenha cuidado de como transportá-los entre os servidores.

   keytool -import -keystore server.keystore -alias intermediateCA -file intermediate.ca

   keytool -import -alias jboss -keystore server.keystore -file server.crt

8. Teste se seus certificados importaram com êxito.

   Execute o seguinte comando e insira a senha keystore quando solicitada. Os conteúdos de seu keystore são exibidos e os certificados fazem parte da lista.

   keytool -list -keystore server.keystore

1. Execute o Management CLI.

   Inicie o comando jboss-cli.sh ou jboss-cli.bat e conecte-se ao servidor.

2. Crie um novo security realm.

   Execute o seguinte comando para criar um novo security realm nomeado MyDomain no domain controller ou o servidor autônomo.

   /host=master/core-service=management/security-realm=MyDomainRealm:add()

3. Crie as referências ao arquivo de propriedade que irá aplicar o store na informação a respeito da nova função.

   Execute o seguinte comando para criar um direcionador ao arquivo nomeado myfile.properties, que terá as propriedades pertencentes à nova função.

   Nota

   O arquivo de propriedade recentemente criado não é gerenciado pelos scripts add-user.sh e add-user.bat incluídos. Ele deve ser gerenciado externamente.

   /host=master/core-service=management/security-realm=MyDomainRealm/authentication=properties:add(path=myfile.properties)

1. Execute o comando add-user.sh ou add-user.bat.

   Abra o command-line interface (CLI - interface da linha de comando). Altere os diretórios para o diretório EAP_HOME/bin/. Caso você esteja executando o Red Hat Enterprise Linux ou outro sistema operacional UNIX, execute o add-user.sh. Caso você execute o Microsoft Windows Server, execute o add-user.bat.

2. Escolha entre adicionar o Usuário de Gerenciamento ou o Usuário do Aplicativo.

   Para este procedimento, digite b para adicionar o Usuário do Aplicativo.

3. Escolha o realm que o usuário será adicionado.

   Por default, o único realm disponível é o ApplicationRealm. Caso você tenha adicionado um realm personalizado, você pode digitar o seu nome.

4. Digite o nome do usuário, senha e funções quando solicitado.

   Digite o nome do usuário, senha e funções quando solicitado. Verifique sua escolha digitando yes ou digite no para cancelar as alterações. As alterações são gravadas a cada um dos arquivos de propriedade para o security realm.

Procedimento 10.1. Configuração do Nó Trabalhador

1. Configuração das interfaces da rede.

   Por default, as interfaces da rede são padrões ao 127.0.0.1. Cada host físico que o realiza o host tanto no servidor autônomo, ou um ou mais servidores num grupo de servidor, precisa que suas interfaces sejam consideradas para uso do próprio endereço IP público, do qual outros servidores podem ver.
   Para a alteração do endereço IP do host do JBoss Enterprise Application Plataform, você precisa desligar e editar seus arquivos de configuração diretamente. Isto é devido ao Management API que direciona o Management Console e Management CLI baseiar-se no endereço de gerenciamento estável.
   Siga as seguintes etapas para alteração do endereço IP de cada servidor do seu cluster ao endereço IP público mestre.
   1. Desligue o servidor completamente.
   2. Edite o host.xml, que está no EAP_HOME/domain/configuration/ para o managed domain ou o arquivo standalone-ha.xml, que está no EAP_HOME/standalone/configuration/ para o servidor autônomo.
   3. Localize o elemento <interfaces>. Três interfaces são configuradas, management, public e unsecured. Para cada uma delas, altere o valor 127.0.0.1 para o endereço IP externo do host.
   4. Para os hosts que participam num managed domain mas não são o mestre, localize o elemento <host. Perceba que isto não possui o símbolo >, uma vez que isto contém os atributos. Altere o valor de seu atributo de nome a partir do master a um nome único (um nome diferente por escravo). Este nome será usado também pelo escravo para identificar o cluster, portanto faça uma anotação sobre isto.
   5. Para os hosts recém configurados que precisam unir-se ao managed domain, encontre o elemento <domain-controller>. Comente ou remova o elemento <local /> e adicione a linha de comando, alterando o endereço IP (X.X.X.X) ao endereço do domain controller. Esta etapa não é válida ao servidor autônomo.

      <remote host="X.X.X.X" port="${jboss.domain.master.port:9999}" security-realm="ManagementRealm"/>
      

   6. Salve o arquivo e saia.

2. Configuração da autenticação para o servidor escravo.

   Cada servidor escravo precisa de um nome de usuário e senha criados no ManagementRealm mestre autônomo ou domain controller. No domain controller ou mestre autônomo, execute o comando EAP_HOME/add-user.sh. Adicione um usuário com o mesmo nome do usuário ao do escravo para o ManagementRealm. Quando você for solicitado se este usuário precisará autenticar à uma instância JBoss AS, por favor responda yes. Segue abaixo uma amostra de uma entrada e saída do comando abaixo, para o escravo chamado slave1 com a senha changeme.

   user:bin user$ ./add-user.sh
   
   What type of user do you wish to add? 
    a) Management User (mgmt-users.properties) 
    b) Application User (application-users.properties)
   (a): a
   
   Enter the details of the new user to add.
   Realm (ManagementRealm) : 
   Username : slave1
   Password : changeme
   Re-enter Password : changeme
   About to add user 'slave1' for realm 'ManagementRealm'
   Is this correct yes/no? yes
   Added user 'slave1' to file '/home/user/jboss-eap-6.0/standalone/configuration/mgmt-users.properties'
   Added user 'slave1' to file '/home/user/jboss-eap-6.0/domain/configuration/mgmt-users.properties'
   Is this new user going to be used for one AS process to connect to another AS process e.g. slave domain controller?
   yes/no? yes
   To represent the user add the following to the server-identities definition <secret value="Y2hhbmdlbWU=" />
   

3. Copie o elemento Base64-encoded <secret> a partir da saída add-user.sh

   Caso você deseje especificar o valor de senha codificada Base64 para a autenticação, copie o valor do elemento <secret> a partir da última linha do resultado add-user.sh uma vez que você precisará disto na etapa abaixo.

4. Modifique o security realm do host escravo para uso da nova autenticação.

   1. Reabra o arquivo host.xml ou standalone-ha.xml do host escravo.
   2. Localize o elemento <security-realms>. Isto é onde você configura o security realm.
   3. Você pode especificar o valor secreto em uma das seguintes maneiras:

      • Especifique o valor de senha codificada Based64 no arquivo da configuração.

        1. Adicione o seguinte bloco do código XML diretamente abaixo da linha <security-realm name="ManagementRealm">,

           <server-identities>
               <secret value="Y2hhbmdlbWU="/>
           </server-identities>
                           
           
           

        2. Substitua"Y2hhbmdlbWU=" pelo valor secreto retornado a partir do resultado add-user.sh na etapa anterior.

      • Configure o host para obter a senha a partir do vault.

        1. Use o script vault.sh para gerar a senha mascarada. Ele gerará uma sequência como o seguinte: VAULT::secret::password::ODVmYmJjNGMtZDU2ZC00YmNlLWE4ODMtZjQ1NWNmNDU4ZDc1TElORV9CUkVBS3ZhdWx0.
           Você pode encontrar maiores informações sobre o vault nos vaults da Senha para a seção das Sequências Sensitivas deste guia iniciando aqui: Seção 3.8.1, “Sequências Confidenciais de Segurança nos Arquivos de texto limpo”.
        2. Adicione o seguinte bloco do código XML diretamente abaixo da linha <security-realm name="ManagementRealm">.

           <server-identities>
               <secret value="${VAULT::secret::password::ODVmYmJjNGMtZDU2ZC00YmNlLWE4ODMtZjQ1NWNmNDU4ZDc1TElORV9CUkVBS3ZhdWx0}"/>
           </server-identities>
                           
           
           

           Certifique-se de substituir o valor secreto pela senha mascarada na etapa anterior.

           Nota

           Quando criando uma senha no vault, ela deve ser especificada num texto plano, e não no Based64 codificado.

      • Especifique a senha como uma propriedade do sistema.

        1. Adicione o seguinte bloco do código XML diretamente abaixo da linha <security-realm name="ManagementRealm">

           <server-identities>
               <secret value=${server.identity.password}/>
           </server-identities>
                           
           
           

        2. Quando você especificar a senha como uma propriedade de sistema, você pode configurar o host nas seguintes maneiras:
           • Inicie o servidor inserindo a senha num texto plano como o argumento da linha de comando, por exemplo:

             -Dserver.identity.password=changeme

             Nota

             A senha deve ser inserida num texto plano e será visível a qualquer um que emite um comando ps -ef.
           • Posicione a senha num arquivo de propriedades e passe o URL do arquivo das propriedades como um argumento da linha de comando.
             1. Adicione o par chave/valor a um arquivo de propriedades. Por exemplo:

                server.identity.password=changeme
                

             2. Inicie o servidor como os argumentos da linha de comando

                --properties=URL_TO_PROPERTIES_FILE

                .
   4. Salve e saia do arquivo.

5. Reinicie o servidor.

   O escravo será agora autenticado ao mestre usando o seu nome do host como o nome de usuário e a sequência criptografada como sua senha.

1. Interrompa o JBoss Enterprise Application Plataform.

   Interrompa o JBoss Enterprise Application Plataform pelo envio de uma interrupção de forma apropriada para o seu sistema operacional. Caso você estiver executando o JBoss Enterprise Application Plataform como um aplicativo de primeiro plano, a maneira típica de realizar isto é pressionar Ctrl+C.

2. Reinicie o JBoss Enterprise Application Plataform especificando o endereço bind.

   Use a opção da linha de comando -b para iniciar o JBoss Enterprise Application Plataform numa interface específica.

   Exemplo 11.1. Especifique a interface pública.

   EAP_HOME/bin/domain.sh -b 10.1.1.1

   Exemplo 11.2. Especifique a interface de gerenciamento.

   EAP_HOME/bin/domain.sh -bmanagement=10.1.1.1

   Exemplo 11.3. Especifique os diferentes endereços para cada interface.

   EAP_HOME/bin/domain.sh -bmanagement=127.0.0.1 -b 10.1.1.1

   Exemplo 11.4. Efetue a interface pública a todas as interfaces da rede.

   EAP_HOME/bin/domain.sh -b 0.0.0.0

Procedimento 11.1. Gerencie os Firewalls da Rede e JBoss Enterprise Application Plataform 6 para funcionamento juntos.

1. Efetue o log ao Management Console.

   Efetue o log ao Consolde de Gerenciamento. Por default, ele executa no http://localhost:9990/console/.

2. Determine os socket bindings usados pelo grupo socket binging.

   Clique no rótulo Profiles no canto superior do Management Console. No canto esquerdo da tela uma série de menus é apresentada. O cabeçalho do menu inferior é General Configuration. Clique no item Socket Binding Groups abaixo deste cabeçalho. A tela Socket Binding Declarations irá aparecer. Inicialmente, o grupo standard-sockets é apresentado. Você pode escolher um grupo diferente selecionando-o a partir da caixa de combinação no lado direito.

   Nota

   Caso você use um servidor autônomo, isto possui apenas um grupo socket binding.
   A lista dos nomes do socket e portas são apresentados, seis valores por página. Você pode avançar nas páginas pelo uso da flecha de navegação na parte inferior da tela.

3. Determine as portas que você precisa abrir.

   Dependendo da funcionalidade da porta particular e das necessidades de seu ambiente, algumas das portas podem precisar serem acessadas através de seu firewall. Caso você não tenha certeza do propósito de um socket binding, refira-se à Seção 11.4, “Portas de rede usadas pelo JBoss Enterprise Application Plataform 6” para uma lista dos socket bindings default e seus propósitos.

4. Configure seu firewall para envio de tráfego ao JBoss Enterprise Application Plataform.

   Execute essas etapas para configurar o seu firewall de rede para permitir tráfego na porta desejada.
   1. Efetue o log em sua máquina de firewall e acesse a solicitação de comando como usuário root.
   2. Insira o comando system-config-firewall para lançar a utilidade de configuração do firewall. Um GUI ou a utilidade da linha de comando é lançada, dependendo da maneira em que você está registrado no sistema firewall. Essa tarefa assume que você está registrado através do SSH e usando a interface da linha de comando.
   3. Use a chave TAB em seu teclado para navegar ao botão Customize e pressione a chave ENTER. A tela Trusted Services aparecerá.
   4. Não altere qualquer valor, porém use a chave TAB para navegar ao botão Forward e pressione ENTER para avançar à próxima tela. A tela Other Ports aparecerá.
   5. Use a chave TAB para navegar ao seu botão <Add> e pressione ENTER. A tela Port and Protocol aparecerá.
   6. Insira 5445 no campo Port / Port Range e use a chave TAB para mover ao campo Protocol e insira tcp. Use a chave TAB para navegar ao botão OK e pressione ENTER.
   7. Use a chave TAB para navegar ao botão Forward até que você encontre a tela Port Forwarding.
   8. Use a chave TAB para navegar ao seu botão <Add> e pressione ENTER.
   9. Preencha os valores seguintes para determinar a porta de envio para a porta 5445.
      • Interface de fonte: eth1
      • Protocolo: tcp
      • Porta / Intervalo de Porta: 5445
      • Destinação do endereço IP: 10.1.1.2
      • Porta / Intervalo de Porta: 5445
      Use a chave TAB para navegar ao botão OK e pressione ENTER.
   10. Use a chave TAB para navegar ao botão Close e pressione ENTER.
   11. Use a chave TAB para navegar ao botão OK e pressione ENTER. Leia o aviso e clique Yes para que as alterações tenham efeito.

5. Configure um firewall em seu host do JBoss Enterprise Application Plataform 6.

   Algumas organizações escolhem em configurar no servidor do JBoss Enterprise Application Plataform 6, e encerram todas as portas que não necessárias para esta operação. Consulte a Seção 11.4, “Portas de rede usadas pelo JBoss Enterprise Application Plataform 6” e determine quais portas devem ser abertas, e encerre o resto. A configuração default do Red Hat Enterprise Linux 6 encerra todas as portas com exceção da 22 (usada para Secure Shell (SSH) e 5353 (usada para multicast DNS). Enquanto você configura as portas, certifique-se de ter acesso físico ao seu servidor de forma que você não bloqueie-se acidentalmente.

Procedimento 13.1. Configuração da Autenticação SSO para os seus Aplicativos EJB

1. Configure um security domain para representar a identidade do servidor. Determine as propriedades caso seja necessário.

   O primeiro security domain autentica o próprio contêiner ao serviço do diretório. Ele precisa usar um módulo de login que aceita algum tipo de mecanismo de login estático, uma vez que o usuário real não está envolvido. Esta amostra usa um principal estático e referencia um arquivo keytab que contém o credencial.
   O código XML é gerado aqui para clareza, porém você deve usar o Management Consolo ou Management CLI para configuração de seus security domains.

   <security-domain name="host" cache-type="default">
      <authentication>
         <login-module code="Kerberos" flag="required">
            <module-option name="storeKey" value="true"/>
            <module-option name="useKeyTab" value="true"/>
            <module-option name="principal" value="host/testserver@MY_REALM"/>
            <module-option name="keyTab" value="/home/username/service.keytab"/>
            <module-option name="doNotPrompt" value="true"/>
            <module-option name="debug" value="false"/>
         </login-module>
      </authentication>
   </security-domain>		
   		
   
   

2. Configure o segundo security domain para assegurar o aplicativo da web ou aplicativos. Determine as propriedades do sistema caso seja necessário.

   O segundo security domain é usado para autenticar o usuário individual ao Kerberos ou servidor de autenticação SPNEGO. Você precisa de pelo menos um módulo de login para autenticação do usuário e outro para buscar as funções a serem aplicadas ao usuário. O seguinte código XML apresenta um modelo de autorização para mapeamento das funções no próprio servidor de autenticação.

   <security-domain name="SPNEGO" cache-type="default">
      <authentication>
         <!-- Check the username and password -->
         <login-module code="SPNEGO"  flag="requisite">
            <module-option name="password-stacking" value="useFirstPass"/>
            <module-option name="serverSecurityDomain" value="host"/>
         </login-module>
         <!-- Search for roles -->
         <login-module code="UserRoles" flag="required">
            <module-option name="password-stacking" value="useFirstPass" />
            <module-option name="usersProperties" value="spnego-users.properties" />
            <module-option name="rolesProperties" value="spnego-roles.properties" />
         </login-module> 
      </authentication>
   </security-domain>		
   		
   
   

3. Especifique o security-constraint e login-config no web.xml

   O descritor web.xml contém informação sobre as restrições de segurança e configuração de login. Segue abaixo algumas amostras de valores para cada uma.

   <security-constraint>
      <display-name>Security Constraint on Conversation</display-name>
      <web-resource-collection>
         <web-resource-name>examplesWebApp</web-resource-name>
         <url-pattern>/*</url-pattern>
      </web-resource-collection>
      <auth-constraint>
      <role-name>RequiredRole</role-name>
      </auth-constraint>
   </security-constraint>
   
   <login-config>
      <auth-method>SPNEGO</auth-method>
      <realm-name>SPNEGO</realm-name>
   </login-config>
    
   <security-role>
      <description> role required to log in to the Application</description>
      <role-name>RequiredRole</role-name>
   </security-role>		
   		
   
   

4. Especifique o security domain e outras configurações no descritor jboss-web.xml.

   Especifique o nome do security domain ao lado do cliente (a segunda amostra) no descritor jboss-web.xml de sua implantação para direcionar o seu aplicativo para uso de seu security domain.
   Você não pode mais substituir os autenticadores diretamente. Ao invés disto, você pode adicionar o NegotiationAuthenticator como um valor ao seu descritor jboss-web.xml, caso seja necessário. O <jacc-star-role-allow> permite você usar o caractere (*) de asterisco para coincidir com os nomes de função múltiplos e é opcional.

   <jboss-web>
      <security-domain>java:/jaas/SPNEGO</security-domain>
      <valve>
         <class-name>org.jboss.security.negotiation.NegotiationAuthenticator</class-name>
      </valve>
      <jacc-star-role-allow>true</jacc-star-role-allow>
   </jboss-web>		
   		
   
   

5. Adicione uma dependência ao seu MANIFEST.MF do aplicativo para localizar as classes de Negociação.

   O aplicativo da web precisa de uma dependência no org.jboss.security.negotiation da classe a ser adicionada ao manifesto do META-INF/MANIFEST.MF da implantação, com o objetivo de localizar as classes do JBoss Negotiation. Segue abaixo uma entrada propriamente formatada.

   Manifest-Version: 1.0
   Build-Jdk: 1.6.0_24
   Dependencies: org.jboss.security.negotiation
   

Procedimento 14.1. Configure o seu Aplicativo para Uso de um Security Domain

1. Definição do Security Domain

   Você pode definir o security domain tanto no arquivo de configuração do servidor ou arquivo descritor aplicativo.

   • Configuração do security domain no arquivo de configuração do servidor.

     O security domain é configurado no subsistema security do arquivo de configuração do servidor. Caso a instância do JBoss Enterprise Application Plataform estiver sendo executada num managed domain, este é o arquivo domain/configuration/domain.xml. Caso a instância do JBoss Enterprise Application Plataform estiver sendo executada como um servidor autônomo, este é o arquivo standalone/configuration/standalone.xml.
     Os security domains other, jboss-web-policy e jboss-ejb-policy são fornecidos por default no JBoss Enterprise Application Plataform 6. A seguinte amostra XML foi copiada a partir do subsistema security no arquivo de configuração do servidor.

     <subsystem xmlns="urn:jboss:domain:security:1.2">
         <security-domains>
             <security-domain name="other" cache-type="default">
                 <authentication>
                     <login-module code="Remoting" flag="optional">
                         <module-option name="password-stacking" value="useFirstPass"/>
                     </login-module>
                     <login-module code="RealmDirect" flag="required">
                         <module-option name="password-stacking" value="useFirstPass"/>
                     </login-module>
                 </authentication>
             </security-domain>
             <security-domain name="jboss-web-policy" cache-type="default">
                 <authorization>
                     <policy-module code="Delegating" flag="required"/>
                 </authorization>
             </security-domain>
             <security-domain name="jboss-ejb-policy" cache-type="default">
                 <authorization>
                     <policy-module code="Delegating" flag="required"/>
                 </authorization>
             </security-domain>
         </security-domains>
     </subsystem>
     
     

     Você pode configurar os security domains adicionais conforme seja necessário usando o Management Console ou CLI.

   • Configuração do security domain no arquivo do descritor do aplicativo

     O security domain é especificado no elemento filho <security-domain> do elemento <jboss-web> no arquivo WEB-INF/jboss-web.xml do aplicativo. A seguinte amostra configura o security domain nomeado my-domain.

     <jboss-web>
         <security-domain>my-domain</security-domain>
     </jboss-web>        
             
     
     

     Esta é uma das muitas configurações que você pode especificar no descritor WEB-INF/jboss-web.xml.

2. Adição da Anotação Requerida para o EJB

   Você configura a segurança no EJB usando as anotações @SecurityDomain e @RolesAllowed. A seguinte amostra de código EJB limita o acesso ao security domain other por usuários na função guest.

   package example.ejb3;
   
   import java.security.Principal;
   
   import javax.annotation.Resource;
   import javax.annotation.security.RolesAllowed;
   import javax.ejb.SessionContext;
   import javax.ejb.Stateless;
   
   import org.jboss.ejb3.annotation.SecurityDomain;
   
   /**
    * Simple secured EJB using EJB security annotations
    * Allow access to "other" security domain by users in a "guest" role.
    */
   @Stateless
   @RolesAllowed({ "guest" })
   @SecurityDomain("other")
   public class SecuredEJB {
   
      // Inject the Session Context
      @Resource
      private SessionContext ctx;
   
      /**
       * Secured EJB method using security annotations
       */
      public String getSecurityInfo() {
         // Session context injected using the resource annotation
         Principal principal = ctx.getCallerPrincipal();
         return principal.toString();
      }
   }
   

   Para maiores amostras de código, consulte o ejb-security quickstart do pacote do JBoss Enterprise Application Plataform 6 Quickstarts, disponível a partir do Portal do Cliente Red Hat.

Procedimento 14.2. Adição da Segurança baseada na Função aos Servlets

1. Adição dos mapeamentos entre os padrões servlets e URL.

   Use os elementos <servlet-mapping> no web.xml para mapear os servlets individuais aos padrões URL. A seguinte amostra mapeia o servlet chamado DisplayOpResult ao /DisplayOpResult default de URL.

   <servlet-mapping>
       <servlet-name>DisplayOpResult</servlet-name>
       <url-pattern>/DisplayOpResult</url-pattern>
   </servlet-mapping>		
   			
   
   

2. Adição das restrições de segurança nos padrões URL.

   Para mapear o default URL a uma restrição de segurança, use o <security-constraint>. A seguinte amostra de acesso às restrições a partir do /DisplayOpResult default de URL a ser acessado pelos principals com o eap_admin da função. A função necessita estar presente no security domain.

   <security-constraint>
   	<display-name>Restrict access to role eap_admin</display-name>
   	<web-resource-collection>
   		<web-resource-name>Restrict access to role eap_admin</web-resource-name>
   		<url-pattern>/DisplayOpResult/*</url-pattern>
   	</web-resource-collection>
   	<auth-constraint>
   		<role-name>eap_admin</role-name>
   	</auth-constraint>	
   	<security-role>
   		<role-name>eap_admin</role-name>
   	</security-role>
   </security-constraint>		
   			
   
   

3. Especificação do security domain no jboss-web.xml do WAR.

   Adicione o security domain ao jboss-web.xml do WAR com o objetivo de conectar os servlets ao security domain configurado, que sabe como autenticar e autorizar os principals em referências de segurança. A seguinte amostra usa o security domain chamado acme_domain.

   <jboss-web>
   	...
   	<security-domain>acme_domain</security-domain>
   	...
   </jboss-web>