Capítulo 7. Migrando para o Elytron no JBoss EAP 7.1 [Esta é uma tradução automática]

7.1. Visão geral de Elytron [Esta é uma tradução automática]

O JBoss EAP 7.1 apresenta o Elytron, que fornece uma única estrutura unificada que pode gerenciar e configurar o acesso para servidores independentes e domínios gerenciados. Também pode ser usado para configurar o acesso de segurança para aplicativos implantados nos servidores do JBoss EAP.

Importante

As arquiteturas do Elytron e do subsistema de segurança legado que é baseado no PicketBox são muito diferentes. Com o Elytron, foi feita uma tentativa de criar uma solução que permite operar nos mesmos ambientes de segurança em que você opera atualmente; no entanto, isso faz não significa que cada opção de configuração do PicketBox tem uma opção de configuração equivalente no Elytron.

Se você não conseguir encontrar informações na documentação para ajudá-lo a obter uma funcionalidade semelhante usando o Elytron ao usar a implementação de segurança herdada, poderá encontrar ajuda de uma das maneiras a seguir.

Se você tem um Subscrição do Red Hat Development, você tem acesso a Casos de suporte, Soluções, e Artigos de conhecimento no Portal do Cliente Red Hat. Você também pode abrir um caso com Suporte técnico e obter ajuda da comunidade WildFly, conforme descrito abaixo.
Se você não tem uma assinatura do Red Hat Development, você ainda pode acessar Artigos de conhecimento no Portal do Cliente Red Hat. Você também pode participar do fóruns de usuários e chat ao vivo para fazer perguntas da comunidade WildFly. As ofertas da comunidade WildFly são ativamente monitoradas pela equipe de engenharia da Elytron.

A configuração do seu servidor JBoss EAP 7.0 e as implementações que usam o legado security O subsistema, que é baseado no PicketBox, deve rodar sem alterações no JBoss EAP 7.1. O PicketBox continua a oferecer suporte a domínios de segurança, o que permite que os aplicativos continuem usando os módulos de login existentes. Os realms de segurança, que são usados pela camada de gerenciamento para segurança, também são transportados e emulados pelo Elytron. Isso permite que você defina a autenticação tanto no elytron e legado security subsistemas e usá-los em paralelo. Para obter mais informações sobre como configurar seu aplicativo para usar o Elytron e a segurança legada, consulte Configurar aplicativos da Web para usar o Elytron ou a segurança legada para autenticação dentro Como configurar o gerenciamento de identidades para o JBoss EAP.

Embora a autenticação do PicketBox continue sendo suportada, recomendamos que você alterne para o Elytron quando estiver pronto para migrar seus aplicativos. Uma das vantagens de usar a segurança Elytron é que ela fornece uma solução de segurança consistente em todo o servidor e seus aplicativos. Para obter informações sobre como migrar a autenticação e autorização do PicketBox para usar o Elytron, consulte Migrar Configuração de Autenticação neste guia.

Para obter uma visão geral dos novos recursos disponíveis no elytron subsistema, consulte Recursos no subsistema Elytron no JBoss EAP Arquitetura de Segurança guia.

Importante

Esteja ciente de que, se você optar por usar tanto o legado security subsistema e Elytron em suas implementações, invocações entre implementações usando diferentes arquiteturas de segurança não são suportadas.

Para obter mais informações sobre o uso desses subsistemas em paralelo, consulte Usando os subsistemas Elytron e Legacy Security em paralelo dentro Como configurar o gerenciamento de identidades para o JBoss EAP.

7.2. Migração de cofres e propriedades seguras [Esta é uma tradução automática]

7.2.1. Migrar Vaults para Proteger o Armazenamento de Credenciais [Esta é uma tradução automática]

O cofre que foi usado para armazenar criptografia de cadeia de texto simples no legado security O subsistema no JBoss EAP 7.0 não é compatível com o Elytron no JBoss EAP 7.1, que usa um novo armazenamento de credenciais para armazenar cadeias de caracteres. As lojas de credenciais criptografam com segurança credenciais em um arquivo de armazenamento fora dos arquivos de configuração do JBoss EAP. Você pode usar a implementação fornecida pelo Elytron ou pode personalizar a configuração usando as APIs e SPIs do repositório de credenciais. Cada servidor do JBoss EAP pode conter vários armazenamentos de credenciais.

Nota

Se você usou anteriormente expressões de cofre para parametrizar dados não sensíveis, é recomendável substituir os dados por Propriedades de segurança Elytron.

Se você continuar a usar o legado security subsistema, você não precisa modificar ou atualizar os dados do seu cofre. No entanto, se você planeja migrar seu aplicativo para usar o Elytron, é necessário converter seus cofres existentes em armazenamentos de credenciais para que possam ser processados pelo elytron subsistema. Para obter mais informações sobre armazenamentos de credenciais, consulte Lojas de credenciais dentro Como configurar a segurança do servidor para o JBoss EAP.

Migrar clientes para usar o arquivo de configuração do WildFly [Esta é uma tradução automática]

A ferramenta WildFly Elytron Tool, fornecida com o JBoss EAP, fornece vault comando para ajudá-lo a migrar o conteúdo do vault para armazenamentos de credenciais. Você executa a ferramenta executando o elytron-tool script, que está localizado no EAP_HOME/bin diretório.

$ EAP_HOME/bin/elytron-tool.sh vault VAULT_ARGUMENTS

Se preferir, você pode executar a ferramenta executando o java -jar comando.

$ java -jar EAP_HOME/bin/wildfly-elytron-tool.jar vault VAULT_ARGUMENTS

Você pode usar o seguinte comando para obter uma descrição de todos os argumentos disponíveis.

$ EAP_HOME/bin/elytron-tool.sh vault --help

Nota

A ferramenta WildFly Elytron não pode lidar com a primeira versão dos arquivos de dados do cofre de segurança.
Você pode digitar o --keystore-password argumento em formato mascarado, como mostrado no exemplo abaixo para migrar um cofre único ou em texto não criptografado.
o --salt e --iteration argumentos são fornecidos para fornecer informações para decriptografar a senha mascarada ou para gerar uma senha mascarada na saída. Se o --salt e --iteration argumentos são omitidos, valores padrão são usados.
o --summary O argumento produz comandos CLI de gerenciamento formatados que podem ser usados para adicionar os armazenamentos de credenciais convertidos à configuração do JBoss EAP. Senhas de texto simples são mascaradas na saída de resumo.

Importante

Esteja ciente de que os armazenamentos de credenciais só podem ser usados para proteger senhas. Eles não suportam o recurso de expressão do vault que pode ser usado em qualquer parte do modelo de gerenciamento.

Escolha uma das seguintes opções de migração:

Migrar Vaults para Proteger o Armazenamento de Credenciais [Esta é uma tradução automática]

A seguir, um exemplo do comando usado para converter um único cofre de segurança em um armazenamento de credenciais.

$ EAP_HOME/bin/elytron-tool.sh vault --enc-dir vault_data/ --keystore vault-jceks.keystore --keystore-password MASK-2hKo56F1a3jYGnJwhPmiF5 --iteration 34 --salt 12345678 --alias test --location cs-v1.store --summary

Esse comando converte o cofre de segurança em um armazenamento de credenciais e imprime o resumo dos comandos da CLI de gerenciamento que foram usados para convertê-lo na saída.

Vault (enc-dir="vault_data/";keystore="vault-jceks.keystore") converted to credential store "cs-v1.store"
Vault Conversion summary:
--------------------------------------
Vault Conversion Successful
CLI command to add new credential store:
/subsystem=elytron/credential-store=test:add(relative-to=jboss.server.data.dir,create=true,modifiable=true,location="cs-v1.store",implementation-properties={"keyStoreType"=>"JCEKS"},credential-reference={clear-text="MASK-2hKo56F1a3jYGnJwhPmiF5;12345678;34"})

Migrar Vaults para Proteger o Armazenamento de Credenciais [Esta é uma tradução automática]

Você pode converter vários cofres em um armazenamento de credenciais usando o --bulk-convert argumento e apontando para um arquivo descritor de conversão em massa.

Os exemplos nesta seção usam o seguinte arquivo descritor de conversão em massa.

Exemplo: bulk-vault-conversion-descriptor.txt Arquivo [Esta é uma tradução automática]

keystore:vault-v1/vault-jceks.keystore
keystore-password:MASK-2hKo56F1a3jYGnJwhPmiF5
enc-dir:vault-v1/vault_data/
salt:12345678
iteration:34
location:v1-cs-1.store
alias:test

keystore:vault-v1/vault-jceks.keystore
keystore-password:secretsecret
enc-dir:vault-v1/vault_data/
location:v1-cs-2.store
alias:test

# different vault vault-v1-more
keystore:vault-v1-more/vault-jceks.keystore
keystore-password:MASK-2hKo56F1a3jYGnJwhPmiF5
enc-dir:vault-v1-more/vault_data/
salt:12345678
iteration:34
location:v1-cs-more.store
alias:test

Uma nova conversão começa quando cada novo keystore: linha é encontrada. Todas as opções são obrigatórias, exceto para salt, iteration, e properties.

Para executar a conversão em massa e gerar saída que formata os comandos da CLI de gerenciamento, execute o seguinte comando.

$ EAP_HOME/bin/elytron-tool.sh vault --bulk-convert path/to/bulk-vault-conversion-descriptor.txt --summary

Esse comando converte todas as áreas seguras especificadas no arquivo em um armazenamento de credenciais e imprime o resumo dos comandos da CLI de gerenciamento que foram usados para convertê-los na saída.

Vault (enc-dir="vault-v1/vault_data/";keystore="vault-v1/vault-jceks.keystore") converted to credential store "v1-cs-1.store"
Vault Conversion summary:
--------------------------------------
Vault Conversion Successful
CLI command to add new credential store:
/subsystem=elytron/credential-store=test:add(relative-to=jboss.server.data.dir,create=true,modifiable=true,location="v1-cs-1.store",implementation-properties={"keyStoreType"=>"JCEKS"},credential-reference={clear-text="MASK-2hKo56F1a3jYGnJwhPmiF5;12345678;34"})
--------------------------------------

Vault (enc-dir="vault-v1/vault_data/";keystore="vault-v1/vault-jceks.keystore") converted to credential store "v1-cs-2.store"
Vault Conversion summary:
--------------------------------------
Vault Conversion Successful
CLI command to add new credential store:
/subsystem=elytron/credential-store=test:add(relative-to=jboss.server.data.dir,create=true,modifiable=true,location="v1-cs-2.store",implementation-properties={"keyStoreType"=>"JCEKS"},credential-reference={clear-text="secretsecret"})
--------------------------------------

Vault (enc-dir="vault-v1-more/vault_data/";keystore="vault-v1-more/vault-jceks.keystore") converted to credential store "v1-cs-more.store"
Vault Conversion summary:
--------------------------------------
Vault Conversion Successful
CLI command to add new credential store:
/subsystem=elytron/credential-store=test:add(relative-to=jboss.server.data.dir,create=true,modifiable=true,location="v1-cs-more.store",implementation-properties={"keyStoreType"=>"JCEKS"},credential-reference={clear-text="MASK-2hKo56F1a3jYGnJwhPmiF5;12345678;34"})
--------------------------------------

7.2.2. Migrar propriedades de segurança para o Elytron [Esta é uma tradução automática]

Os exemplos nesta seção assumem que o group.name e encoding.algorithm propriedades de segurança são definidas como security-properties no legado security subsistema da seguinte forma.

Exemplo: propriedades de segurança definidas no security Subsistema [Esta é uma tradução automática]

<subsystem xmlns="urn:jboss:domain:security:2.0">
    ...
    <security-properties>
        <property name="group.name" value="engineering-group" />
        <property name="encoding.algorithm" value="BASE64" />
    </security-properties>
</subsystem>

Para definir as mesmas propriedades de segurança no elytron subsistema, defina o security-properties atributo do elytron subsistema usando o seguinte comando CLI de gerenciamento.

/subsystem=elytron:write-attribute(name=security-properties, value={ group.name = "engineering-group", encoding.algorithm = "BASE64" })

Isso configura o seguinte security-properties no elytron subsistema no arquivo de configuração do servidor.

<subsystem xmlns="urn:wildfly:elytron:1.2" final-providers="combined-providers" disallowed-providers="OracleUcrypto">
    <security-properties>
        <security-property name="group.name" value="engineering-group"/>
        <security-property name="encoding.algorithm" value="BASE64"/>
    </security-properties>
    ...
</subsystem>

o write-attribute operação usada no comando anterior sobrescreve as propriedades existentes. Para adicionar ou alterar uma propriedade de segurança sem afetar outras propriedades de segurança, use o map operação no comando CLI de gerenciamento.

/subsystem=elytron:map-put(name=security-properties, key=group.name, value=technical-support)

De maneira semelhante, você pode remover uma propriedade de segurança específica usando o map-remove Operação.

/subsystem=elytron:map-remove(name=security-properties, key=group.name)

7.3. Migrar Configuração de Autenticação [Esta é uma tradução automática]

7.3.1. Migrar Autenticação e Autorização Baseadas em Propriedades para o Elytron [Esta é uma tradução automática]

7.3.1.1. Migrar a configuração baseada em propriedades do PicketBox para Elytron [Esta é uma tradução automática]

Esta seção descreve como migrar a autenticação baseada em propriedades do PicketBox para o Elytron. Você pode escolher migrar parcialmente autenticação baseada em propriedades expondo apenas o domínio de segurança PicketBox ao Elytron ou você pode migrar totalmente as configurações de autenticação baseadas em propriedades para usar o Elytron.

Os procedimentos a seguir presumem que o aplicativo da Web implementado que você planeja migrar está configurado para exigir autenticação baseada em formulário. O aplicativo está fazendo referência a um domínio de segurança PicketBox e está usando UsersRolesLoginModule para carregar informações do usuário do example-users.properties e example-roles.properties arquivos. Esses exemplos também assumem que o domínio de segurança é definido no legado security subsistema usando os seguintes comandos CLI de gerenciamento.

Exemplo: Comandos de Configuração Baseados em Propriedades do PicketBox [Esta é uma tradução automática]

/subsystem=security/security-domain=application-security:add
/subsystem=security/security-domain=application-security/authentication=classic:add(login-modules=[{code=UsersRoles, flag=Required, module-options={usersProperties=file://${jboss.server.config.dir}/example-users.properties, rolesProperties=file://${jboss.server.config.dir}/example-roles.properties}}])

Isso resulta na seguinte configuração do servidor.

Exemplo: Configuração de Domínio de Segurança Baseada em Propriedades do PicketBox [Esta é uma tradução automática]

<security-domain name="application-security">
  <authentication>
    <login-module code="UsersRoles" flag="required">
      <module-option name="usersProperties" value="file://${jboss.server.config.dir}/example-users.properties"/>
      <module-option name="rolesProperties" value="file://${jboss.server.config.dir}/example-roles.properties"/>
    </login-module>
  </authentication>
</security-domain>

Escolha uma das seguintes opções de migração:

Migrar parcialmente expondo o domínio de segurança do PicketBox para Elytron

Você pode expor um domínio de segurança do PicketBox como um domínio de segurança Elytron para que ele possa ser conectado a uma configuração do Elytron; no entanto, isso cria uma dependência do legado security subsistema. Se você estiver migrando apenas a autenticação baseada em propriedades, é recomendável migrar totalmente o aplicativo para Elytron para evitar a dependência desnecessária do legado security subsistema. No entanto, uma migração parcial pode ser uma solução intermediária quando não for possível migrar completamente o aplicativo para usar o Elytron.

Siga este procedimento para adicionar uma configuração de região de segurança PicketBox existente como uma região de segurança Elytron.

Exemplo: propriedades de segurança definidas no security Subsistema [Esta é uma tradução automática]

/subsystem=security/elytron-realm=application-security:add(legacy-jaas-config=application-security)

Isso configura o seguinte domínio de segurança Elytron no security subsistema do arquivo de configuração do servidor.

<subsystem xmlns="urn:jboss:domain:security:2.0">
  ...
  <elytron-integration>
    <security-realms>
      <elytron-realm name="application-security" legacy-jaas-config="application-security"/>
    </security-realms>
  </elytron-integration>
  ...
</subsystem>

Definir um domínio de segurança no elytron subsistema que referencia a região de segurança exportada e uma fábrica de autenticação HTTP que suporta autenticação baseada em formulário.

/subsystem=elytron/security-domain=application-security:add(realms=[{realm=application-security}], default-realm=application-security, permission-mapper=default-permission-mapper)
/subsystem=elytron/http-authentication-factory=application-security-http:add(http-server-mechanism-factory=global, security-domain=application-security, mechanism-configurations=[{mechanism-name=DIGEST,mechanism-realm-configurations=[{realm-name=RealmName}]}]

Isso resulta nas seguintes elytron configuração do subsistema no arquivo de configuração do servidor.

<subsystem xmlns="urn:wildfly:elytron:1.2" final-providers="combined-providers" disallowed-providers="OracleUcrypto">
  ...
  <security-domains>
    ...
    <security-domain name="application-security" default-realm="application-security" permission-mapper="default-permission-mapper">
      <realm name="application-security"/>
    </security-domain>
  </security-domains>
  ...
  <http>
    ...
    <http-authentication-factory name="application-security-http" http-server-mechanism-factory="global" security-domain="application-security">
      <mechanism-configuration>
        <mechanism mechanism-name="DIGEST">
          <mechanism-realm realm-name="RealmName"/>
        </mechanism>
      </mechanism-configuration>
    </http-authentication-factory>
    ...
  </http>
  ...
</subsystem>

Mapeie o domínio de segurança referenciado pela implementação para o factory de autenticação HTTP recém-definido no undertow subsistema.

/subsystem=undertow/application-security-domain=application-security:add(http-authentication-factory=application-security-http)

Isso resulta na seguinte configuração no undertow subsistema do arquivo de configuração do servidor.

<subsystem xmlns="urn:jboss:domain:undertow:4.0">
  ...
  <application-security-domains>
    <application-security-domain name="application-security" http-authentication-factory="application-security-http"/>
  </application-security-domains>
  ...
</subsystem>

Se o aplicativo já tiver sido implementado antes dessa configuração, você deverá recarregar o servidor ou reimplementar o aplicativo para que o mapeamento do novo domínio de segurança do aplicativo tenha efeito.

Verifique se o mapeamento foi aplicado à implantação usando o seguinte comando da CLI de gerenciamento. A implantação usada neste exemplo é HelloWorld.war. A saída do comando this mostra essa implementação referenciando o mapeamento Elytron.

/subsystem=undertow/application-security-domain=application-security:read-resource(include-runtime=true)
{
    "outcome" => "success",
    "result" => {
        "enable-jacc" => false,
        "http-authentication-factory" => "application-security-http",
        "override-deployment-config" => false,
        "referencing-deployments" => ["HelloWorld.war"],
        "setting" => undefined
    }
}

Nesta fase, o domínio de segurança previamente definido é usado para LoginModule configuração, mas é envolvido pelos componentes Elytron, que assumem a autenticação.

Migrar Autenticação e Autorização Baseadas em Propriedades para o Elytron [Esta é uma tradução automática]

Siga estas etapas para migrar completamente a autenticação baseada em propriedades do PicketBox para o Elytron. Este procedimento assume que você está começando com a configuração legada descrita na introdução desta seção e não migrou para o parcialmente migrado solução. Quando você concluir este processo, qualquer definição de domínio de segurança que exista no legado security subsistema permanece completamente independente da configuração do Elytron.

Defina um novo domínio de segurança no elytron subsistema que referencia os arquivos de propriedades do PicketBox.

/subsystem=elytron/properties-realm=application-properties:add(users-properties={path=example-users.properties, relative-to=jboss.server.config.dir, plain-text=true, digest-realm-name="Application Security"}, groups-properties={path=example-roles.properties, relative-to=jboss.server.config.dir}, groups-attribute=Roles)

Definir um subsistema de domínio de segurança e um factory de autenticação HTTP no elytron subsistema.

/subsystem=elytron/security-domain=application-security:add(realms=[{realm=application-properties}], default-realm=application-properties, permission-mapper=default-permission-mapper)
/subsystem=elytron/http-authentication-factory=application-security-http:add(http-server-mechanism-factory=global, security-domain=application-security, mechanism-configurations=[{mechanism-name=FORM}])

Isso resulta nas seguintes elytron configuração do subsistema no arquivo de configuração do servidor.

<subsystem xmlns="urn:wildfly:elytron:1.2" final-providers="combined-providers" disallowed-providers="OracleUcrypto">
  ...
  <security-domains>
    ...
    <security-domain name="application-security" default-realm="application-properties" permission-mapper="default-permission-mapper">
      <realm name="application-properties"/>
    </security-domain>
  </security-domains>
  <security-realms>
    ...
    <properties-realm name="application-properties" groups-attribute="Roles">
      <users-properties path="example-users.properties" relative-to="jboss.server.config.dir" digest-realm-name="Application Security" plain-text="true"/>
      <groups-properties path="example-roles.properties" relative-to="jboss.server.config.dir"/>
    </properties-realm>
  </security-realms>
  ...
  <http>
    ...
    <http-authentication-factory name="application-security-http" http-server-mechanism-factory="global" security-domain="application-security">
      <mechanism-configuration>
        <mechanism mechanism-name="FORM"/>
      </mechanism-configuration>
    </http-authentication-factory>
    ...
  </http>
  ...
</subsystem>

Mapeie o domínio de segurança do aplicativo mencionado pela implementação para o factory de autenticação HTTP recém-definido no undertow subsistema.

/subsystem=undertow/application-security-domain=application-security:add(http-authentication-factory=application-security-http)

Isso resulta nas seguintes undertow configuração do subsistema no arquivo de configuração do servidor.

<subsystem xmlns="urn:jboss:domain:undertow:4.0">
  ...
  <application-security-domains>
    <application-security-domain name="application-security" http-authentication-factory="application-security-http"/>
  </application-security-domains>
  ...
</subsystem>

Você deve recarregar o servidor ou reimplementar o aplicativo para que o mapeamento do novo domínio de segurança do aplicativo tenha efeito.

A autenticação está agora configurada para ser equivalente à configuração do PicketBox; no entanto, os componentes Elytron são agora usados exclusivamente para autenticação.

7.3.1.2. Migrar a configuração baseada em propriedades herdadas para o Elytron [Esta é uma tradução automática]

Esta seção descreve como migrar uma região de segurança legada que carrega informações de usuário, senha e grupo dos arquivos de propriedades para o Elytron. Esse tipo de domínio de segurança herdado é normalmente usado para proteger as interfaces de gerenciamento ou os conectores remotos.

Estes exemplos assumem que o domínio de segurança legado é definido usando os seguintes comandos da CLI de gerenciamento.

Exemplo: Comandos do Reino de Segurança Legado [Esta é uma tradução automática]

/core-service=management/security-realm=ApplicationSecurity:add
/core-service=management/security-realm=ApplicationSecurity/authentication=properties:add(relative-to=jboss.server.config.dir, path=example-users.properties, plain-text=true)
/core-service=management/security-realm=ApplicationSecurity/authorization=properties:add(relative-to=jboss.server.config.dir, path=example-roles.properties)

Isso resulta na seguinte configuração do servidor.

Exemplo: Comandos de Configuração do Reino de Segurança Legado [Esta é uma tradução automática]

<security-realm name="ApplicationSecurity">
  <authentication>
    <properties path="example-users.properties" relative-to="jboss.server.config.dir" plain-text="true"/>
  </authentication>
  <authorization>
    <properties path="example-roles.properties" relative-to="jboss.server.config.dir"/>
  </authorization>
</security-realm>

Uma das motivações para adicionar a segurança Elytron ao servidor de aplicativos é permitir que uma solução de segurança consistente seja usada em todo o servidor. As etapas iniciais para migrar um domínio de segurança legado baseado em propriedades para o Elytron são semelhantes àquelas usadas para migrar uma autenticação baseada em propriedades do PicketBox para o Elytron. Siga estas etapas para migrar um domínio de segurança legado baseado em propriedades para o Elytron.

Defina um novo domínio de segurança no elytron subsistema que referencia os arquivos de propriedades.

/subsystem=elytron/properties-realm=application-properties:add(users-properties={path=example-users.properties, relative-to=jboss.server.config.dir, plain-text=true, digest-realm-name="Application Security"}, groups-properties={path=example-roles.properties, relative-to=jboss.server.config.dir}, groups-attribute=Roles)

Definir um subsistema de domínio de segurança e um factory de autenticação HTTP no elytron subsistema.

/subsystem=elytron/security-domain=application-security:add(realms=[{realm=application-properties}], default-realm=application-properties, permission-mapper=default-permission-mapper)
/subsystem=elytron/http-authentication-factory=application-security-http:add(http-server-mechanism-factory=global, security-domain=application-security, mechanism-configurations=[{mechanism-name=FORM}])

Isso resulta na seguinte configuração Elytron.

<subsystem xmlns="urn:wildfly:elytron:1.2" final-providers="combined-providers" disallowed-providers="OracleUcrypto">
  ...
  <security-domains>
    ...
    <security-domain name="application-security" default-realm="application-properties" permission-mapper="default-permission-mapper">
      <realm name="application-properties"/>
    </security-domain>
  </security-domains>
  <security-realms>
    ...
    <properties-realm name="application-properties" groups-attribute="Roles">
      <users-properties path="example-users.properties" relative-to="jboss.server.config.dir" digest-realm-name="Application Security" plain-text="true"/>
      <groups-properties path="example-roles.properties" relative-to="jboss.server.config.dir"/>
    </properties-realm>
  </security-realms>
  ...
  <http>
    ...
    <http-authentication-factory name="application-security-http" http-server-mechanism-factory="global" security-domain="application-security">
      <mechanism-configuration>
        <mechanism mechanism-name="FORM"/>
      </mechanism-configuration>
    </http-authentication-factory>
    ...
  </http>
  ...
</subsystem>

Definir um sasl-authentication-factory para que o domínio de segurança legado também possa ser usado para autenticação SASL (Simple Authentication Security Layer).

/subsystem=elytron/sasl-authentication-factory=application-security-sasl:add(sasl-server-factory=elytron, security-domain=application-security, mechanism-configurations=[{mechanism-name=PLAIN}])

Isso resulta na seguinte configuração Elytron.

<subsystem xmlns="urn:wildfly:elytron:1.2" final-providers="combined-providers" disallowed-providers="OracleUcrypto">
  ...
  <sasl>
    ...
    <sasl-authentication-factory name="application-security-sasl" sasl-server-factory="elytron" security-domain="application-security">
      <mechanism-configuration>
        <mechanism mechanism-name="PLAIN"/>
      </mechanism-configuration>
    </sasl-authentication-factory>
    ...
  </sasl>
</subsystem>

Configure um conector remoto para a autenticação SASL e remova a associação com a região de segurança legada.

/subsystem=remoting/http-connector=http-remoting-connector:write-attribute(name=sasl-authentication-factory, value=application-security-sasl)
/subsystem=remoting/http-connector=http-remoting-connector:undefine-attribute(name=security-realm)

Isso resulta na seguinte configuração no remoting subsistema do arquivo de configuração do servidor.

<subsystem xmlns="urn:jboss:domain:remoting:4.0">
  ...
  <http-connector name="http-remoting-connector" connector-ref="default" sasl-authentication-factory="application-security-sasl"/>
</subsystem>

Adicione as duas fábricas de autenticação e remova as referências de domínio de segurança legadas para proteger http-interface com Elytron.

/core-service=management/management-interface=http-interface:write-attribute(name=http-authentication-factory, value=application-security-http)
/core-service=management/management-interface=http-interface:write-attribute(name=http-upgrade.sasl-authentication-factory, value=application-security-sasl)
/core-service=management/management-interface=http-interface:undefine-attribute(name=security-realm)

Isso resulta na seguinte configuração.

<management-interfaces>
  <http-interface http-authentication-factory="application-security-http">
    <http-upgrade enabled="true" sasl-authentication-factory="application-security-sasl"/>
    <socket-binding http="management-http"/>
  </http-interface>
</management-interfaces>

Nota

Você deve escolher nomes mais adequados do que aqueles usados nesses exemplos ao proteger as interfaces de gerenciamento.

Migrar a configuração baseada em propriedades herdadas para o Elytron [Esta é uma tradução automática]

7.3.2. Migrar a configuração de autenticação LDAP para o Elytron [Esta é uma tradução automática]

Esta seção descreve como migrar a autenticação LDAP herdada para o Elytron para que ela possa gerenciar as informações como atributos de identidade. Muitas das informações fornecidas na seção intitulada Migrar Autenticação e Autorização Baseadas em Propriedades para o Elytron aplica-se aqui, particularmente sobre como definir domínios de segurança e fábricas de autenticação, e como mapeá-los para serem usados para autenticação. Esta seção não repete essas instruções, portanto, leia essa seção antes de continuar.

Os exemplos a seguir supõem que as informações de grupo ou função são carregadas diretamente do LDAP e que a autenticação LDAP herdada é configurada da seguinte maneira.

O servidor LDAP contém as seguintes entradas de usuário e grupo.

Exemplo: Entradas do Usuário do Servidor LDAP [Esta é uma tradução automática]

dn: uid=TestUserOne,ou=users,dc=group-to-principal,dc=wildfly,dc=org
objectClass: top
objectClass: inetOrgPerson
objectClass: uidObject
objectClass: person
objectClass: organizationalPerson
cn: Test User One
sn: Test User One
uid: TestUserOne
userPassword: {SSHA}UG8ov2rnrnBKakcARVvraZHqTa7mFWJZlWt2HA==

Exemplo: Entradas do Grupo de Servidores LDAP [Esta é uma tradução automática]

dn: uid=GroupOne,ou=groups,dc=group-to-principal,dc=wildfly,dc=org
objectClass: top
objectClass: groupOfUniqueNames
objectClass: uidObject
cn: Group One
uid: GroupOne
uniqueMember: uid=TestUserOne,ou=users,dc=group-to-principal,dc=wildfly,dc=org

Para fins de autenticação, o nome do usuário é comparado com o uid atributo e o nome do grupo resultante é retirado do uid atributo da entrada do grupo.

A conexão com o servidor LDAP e a região de segurança relacionada é definida usando os seguintes comandos da CLI de gerenciamento.

Exemplo: Comandos de configuração do domínio de segurança do LDAP [Esta é uma tradução automática]

batch
/core-service=management/ldap-connection=MyLdapConnection:add(url="ldap://localhost:10389", search-dn="uid=admin,ou=system", search-credential="secret")

/core-service=management/security-realm=LDAPRealm:add
/core-service=management/security-realm=LDAPRealm/authentication=ldap:add(connection="MyLdapConnection", username-attribute=uid, base-dn="ou=users,dc=group-to-principal,dc=wildfly,dc=org")

/core-service=management/security-realm=LDAPRealm/authorization=ldap:add(connection=MyLdapConnection)
/core-service=management/security-realm=LDAPRealm/authorization=ldap/username-to-dn=username-filter:add(attribute=uid, base-dn="ou=users,dc=group-to-principal,dc=wildfly,dc=org")
/core-service=management/security-realm=LDAPRealm/authorization=ldap/group-search=group-to-principal:add(base-dn="ou=groups,dc=group-to-principal,dc=wildfly,dc=org", iterative=true, prefer-original-connection=true, principal-attribute=uniqueMember, search-by=DISTINGUISHED_NAME, group-name=SIMPLE, group-name-attribute=uid)
run-batch

Isso resulta na seguinte configuração do servidor.

Exemplo: Configuração do Realm de Segurança LDAP [Esta é uma tradução automática]

<management>
  <security-realms>
    ...
    <security-realm name="LDAPRealm">
      <authentication>
        <ldap connection="MyLdapConnection" base-dn="ou=users,dc=group-to-principal,dc=wildfly,dc=org">
          <username-filter attribute="uid"/>
        </ldap>
      </authentication>
      <authorization>
        <ldap connection="MyLdapConnection">
          <username-to-dn>
            <username-filter base-dn="ou=users,dc=group-to-principal,dc=wildfly,dc=org" attribute="uid"/>
          </username-to-dn>
          <group-search group-name="SIMPLE" iterative="true" group-name-attribute="uid">
            <group-to-principal search-by="DISTINGUISHED_NAME" base-dn="ou=groups,dc=group-to-principal,dc=wildfly,dc=org" prefer-original-connection="true">
              <membership-filter principal-attribute="uniqueMember"/>
            </group-to-principal>
          </group-search>
        </ldap>
      </authorization>
    </security-realm>
  </security-realms>
  <outbound-connections>
    <ldap name="MyLdapConnection" url="ldap://localhost:10389" search-dn="uid=admin,ou=system" search-credential="secret"/>
  </outbound-connections>
  ...
</management>

Os seguintes comandos CLI de gerenciamento são usados para configurar um domínio de segurança PicketBox, que usa o LdapExtLoginModule para verificar um nome de usuário e senha.

Exemplo: Comandos de Configuração do Domínio de Segurança [Esta é uma tradução automática]

/subsystem=security/security-domain=application-security:add
/subsystem=security/security-domain=application-security/authentication=classic:add(login-modules=[{code=LdapExtended, flag=Required, module-options={ java.naming.factory.initial=com.sun.jndi.ldap.LdapCtxFactory, java.naming.provider.url=ldap://localhost:10389, java.naming.security.authentication=simple, bindDN="uid=admin,ou=system", bindCredential=secret, baseCtxDN="ou=users,dc=group-to-principal,dc=wildfly,dc=org", baseFilter="(uid={0})", rolesCtxDN="ou=groups,dc=group-to-principal,dc=wildfly,dc=org", roleFilter="(uniqueMember={1})", roleAttributeID="uid" }}])

Isso resulta na seguinte configuração do servidor.

Exemplo: Configuração do Domínio de Segurança [Esta é uma tradução automática]

<subsystem xmlns="urn:jboss:domain:security:2.0">
  ...
  <security-domains>
    ...
    <security-domain name="application-security">
      <authentication>
        <login-module code="LdapExtended" flag="required">
          <module-option name="java.naming.factory.initial" value="com.sun.jndi.ldap.LdapCtxFactory"/>
          <module-option name="java.naming.provider.url" value="ldap://localhost:10389"/>
          <module-option name="java.naming.security.authentication" value="simple"/>
          <module-option name="bindDN" value="uid=admin,ou=system"/>
          <module-option name="bindCredential" value="secret"/>
          <module-option name="baseCtxDN" value="ou=users,dc=group-to-principal,dc=wildfly,dc=org"/>
          <module-option name="baseFilter" value="(uid={0})"/>
          <module-option name="rolesCtxDN" value="ou=groups,dc=group-to-principal,dc=wildfly,dc=org"/>
          <module-option name="roleFilter" value="(uniqueMember={1})"/>
          <module-option name="roleAttributeID" value="uid"/>
        </login-module>
      </authentication>
    </security-domain>
  </security-domains>
</subsystem>

7.3.2.1. Migre a Autenticação LDAP Legada para Elytron [Esta é uma tradução automática]

Siga estas etapas para migrar a configuração anterior do exemplo de autenticação LDAP para o Elytron. Esta seção aplica-se à migração de um domínio LDAP de segurança legada bem como um Domínio de segurança do PicketBox LDAP.

Exemplo: propriedades de segurança definidas no security Subsistema [Esta é uma tradução automática]

/subsystem=elytron/dir-context=ldap-connection:add(url=ldap://localhost:10389, principal="uid=admin, ou=system", credential-reference={clear-text=secret})

Crie um domínio de segurança para pesquisar o LDAP e verifique a senha fornecida.

/subsystem=elytron/ldap-realm=ldap-realm:add(dir-context=ldap-connection, direct-verification=true, identity-mapping={search-base-dn="ou=users, dc=group-to-principal, dc=wildfly, dc=org", rdn-identifier="uid", attribute-mapping=[{filter-base-dn="ou=groups, dc=group-to-principal, dc=wildfly, dc=org", filter="(uniqueMember={1})", from="uid", to="Roles"}]})

Essas etapas resultam nas seguintes elytron configuração do subsistema no arquivo de configuração do servidor.

<subsystem xmlns="urn:wildfly:elytron:1.2" final-providers="combined-providers" disallowed-providers="OracleUcrypto">
  ...
  <security-realms>
    ...
    <ldap-realm name="ldap-realm" dir-context="ldap-connection" direct-verification="true">
      <identity-mapping rdn-identifier="uid" search-base-dn="ou=users,dc=group-to-principal,dc=wildfly,dc=org">
        <attribute-mapping>
          <attribute from="uid" to="Roles" filter="(uniqueMember={1})" filter-base-dn="ou=groups,dc=group-to-principal,dc=wildfly,dc=org"/>
        </attribute-mapping>
      </identity-mapping>
    </ldap-realm>
  </security-realms>
  ...
  <dir-contexts>
    <dir-context name="ldap-connection" url="ldap://localhost:10389" principal="uid=admin,ou=system">
      <credential-reference clear-text="secret"/>
    </dir-context>
  </dir-contexts>
</subsystem>

Nota

Por padrão, se não role-decoder é definido para um dado security-domain, o atributo de identidade "Funções" é mapeado para as funções de identidade.

Informações carregadas do LDAP agora podem ser associadas a identidades como atributos. Esses atributos podem ser mapeados para funções, mas também podem ser carregados e usados para outras finalidades. O domínio de segurança recém-criado pode ser usado em um domínio de segurança da mesma forma que é descrito no Migrar Autenticação e Autorização Baseadas em Propriedades para o Elytron seção deste guia.

7.3.3. Migrar a configuração de autenticação de banco de dados para o Elytron [Esta é uma tradução automática]

Esta seção descreve como migrar a autenticação PicketBox baseada em origem de dados JDBC para o Elytron. Muitas das informações fornecidas na seção intitulada Migrar Autenticação e Autorização Baseadas em Propriedades para o Elytron aplica-se aqui, particularmente sobre como definir domínios de segurança e fábricas de autenticação, e como mapeá-los para serem usados para autenticação. Esta seção não repete essas instruções, portanto, leia essa seção antes de continuar.

Os exemplos a seguir presumem que os dados de autenticação do usuário estão armazenados em uma tabela de banco de dados criada usando uma sintaxe semelhante ao exemplo a seguir.

Exemplo: sintaxe para criar a tabela de usuário do banco de dados [Esta é uma tradução automática]

CREATE TABLE User (
    id BIGINT NOT NULL,
    username VARCHAR(255),
    password VARCHAR(255),
    role ENUM('admin', 'manager', 'user'),
    PRIMARY KEY (id),
    UNIQUE (username)
)

Para fins de autenticação, o nome de usuário é comparado com os dados armazenados no username coluna, espera-se que a senha seja armazenada como um hash MD5 codificado hexadecimal no password coluna, ea função de usuário para fins de autorização é armazenada no role coluna.

O domínio de segurança PicketBox é configurado para usar uma origem de dados JBDC para recuperar dados da tabela de banco de dados e, em seguida, usá-lo para verificar o nome de usuário e a senha e para atribuir funções. Suponha que o domínio de segurança PicketBox esteja configurado usando os seguintes comandos da CLI de gerenciamento.

Exemplo: Comandos de Configuração do LoginModule do Banco de Dados do PicketBox [Esta é uma tradução automática]

/subsystem=security/security-domain=application-security:add
/subsystem=security/security-domain=application-security/authentication=classic:add( login-modules=[ { code=Database, flag=Required, module-options={ dsJndiName="java:jboss/datasources/ExampleDS", principalsQuery="SELECT password FROM User WHERE username = ?", rolesQuery="SELECT role, 'Roles' FROM User WHERE username = ?", hashAlgorithm=MD5, hashEncoding=base64 } } ] )

Isso resulta nas seguintes login-module configuração no legado security subsistema.

Exemplo: Configuração do PicketBox LoginModule [Esta é uma tradução automática]

<subsystem xmlns="urn:jboss:domain:security:2.0">
  <security-domains>
    ...
    <security-domain name="application-security">
      <authentication>
        <login-module code="Database" flag="required">
          <module-option name="dsJndiName" value="java:jboss/datasources/ExampleDS"/>
          <module-option name="principalsQuery" value="SELECT password FROM User WHERE username = ?"/>
          <module-option name="rolesQuery" value="SELECT role, 'Roles' FROM User WHERE username = ?"/>
          <module-option name="hashAlgorithm" value="MD5"/>
          <module-option name="hashEncoding" value="base64"/>
        </login-module>
      </authentication>
    </security-domain>
  </security-domains>
</subsystem>

7.3.3.1. Migre a Autenticação de Banco de Dados Legada para Elytron [Esta é uma tradução automática]

Para migrar a configuração anterior do exemplo de autenticação do banco de dados para o Elytron, você deve definir uma região JDBC para ativar o acesso à origem de dados JDBC pelo Elytron.

Utilize o seguinte comando de gerenciamento para definir jdbc-realm.

/subsystem=elytron/jdbc-realm=jdbc-realm:add(principal-query=[ { data-source=ExampleDS, sql="SELECT role, password FROM User WHERE username = ?", attribute-mapping=[{index=1, to=Roles } ] simple-digest-mapper={algorithm=simple-digest-md5, password-index=2} } ] )

Isso resulta nas seguintes jdbc-realm configuração no elytron subsistema do arquivo de configuração do servidor.

<subsystem xmlns="urn:wildfly:elytron:1.2" final-providers="combined-providers" disallowed-providers="OracleUcrypto">
  ...
  <security-realms>
    ...
    <jdbc-realm name="jdbc-realm">
      <principal-query sql="SELECT role, password FROM User WHERE username = ?" data-source="ExampleDS">
        <attribute-mapping>
          <attribute to="Roles" index="1"/>
        </attribute-mapping>
        <simple-digest-mapper password-index="2"/>
      </principal-query>
    </jdbc-realm>
    ...
  </security-realms>
  ...
</subsystem>

O Elytron agora gerencia a autenticação do banco de dados usando a configuração do território JDBC. O Elytron é mais eficiente que o PicketBox porque usa uma consulta SQL para obter todos os atributos e credenciais do usuário e, em seguida, extrai dados dos resultados do SQL e cria um mapeamento dos atributos a serem usados para autenticação.

7.3.4. Migração da autenticação Kerberos para o Elytron [Esta é uma tradução automática]

Ao trabalhar com uma configuração do Kerberos, o servidor do JBoss EAP pode confiar nas informações de configuração do ambiente, ou a configuração da chave pode ser especificada usando as propriedades do sistema. Esta seção discute como migrar HTTP Kerberos e Kerberos SASL autenticação.

Os exemplos a seguir pressupõem que o Kerberos esteja configurado usando as seguintes propriedades do sistema. Essas propriedades do sistema são aplicáveis à configuração herdada e à configuração migrada do Elytron.

Exemplo: Comandos CLI de gerenciamento de propriedades do sistema Kerberos [Esta é uma tradução automática]

# Enable debugging
/system-property=sun.security.krb5.debug:add(value=true)
# Identify the Kerberos realm to use
/system-property=java.security.krb5.realm:add(value=ELYTRON.ORG)
# Identify the address of the KDC
/system-property=java.security.krb5.kdc:add(value=kdc.elytron.org)

Exemplo: configuração do servidor de propriedades do sistema Kerberos [Esta é uma tradução automática]

<system-properties>
  <property name="sun.security.krb5.debug" value="true"/>
  <property name="java.security.krb5.realm" value="ELYTRON.ORG"/>
  <property name="java.security.krb5.kdc" value="kdc.elytron.org"/>
</system-properties>

Escolha uma das seguintes opções de migração:

Migração da autenticação Kerberos para o Elytron [Esta é uma tradução automática]

Nas configurações de segurança herdadas, você pode definir um domínio de segurança para habilitar a autenticação SPNEGO para a interface de gerenciamento HTTP da seguinte maneira.

Exemplo: Ativar a autenticação SPNEGO para a interface de gerenciamento de HTTP [Esta é uma tradução automática]

/core-service=management/security-realm=Kerberos:add
/core-service=management/security-realm=Kerberos/server-identity=kerberos:add
/core-service=management/security-realm=Kerberos/server-identity=kerberos/keytab=HTTP\/test-server.elytron.org@ELYTRON.ORG:add(path=/path/to/test-server.keytab, debug=true)
/core-service=management/security-realm=Kerberos/authentication=kerberos:add(remove-realm=true)

Exemplo: configuração do território de segurança Kerberos [Esta é uma tradução automática]

<security-realms>
  ...
  <security-realm name="Kerberos">
    <server-identities>
      <kerberos>
        <keytab principal="HTTP/test-server.elytron.org@ELYTRON.ORG" path="/path/to/test-server.keytab" debug="true"/>
      </kerberos>
    </server-identities>
    <authentication>
      <kerberos remove-realm="true"/>
    </authentication>
  </security-realm>
</security-realms>

Você também pode definir um par de domínios de segurança legados para permitir que os aplicativos usem a autenticação HTTP do Kerberos.

Exemplo: definir vários domínios de segurança [Esta é uma tradução automática]

# Define the first security domain
/subsystem=security/security-domain=host:add
/subsystem=security/security-domain=host/authentication=classic:add
/subsystem=security/security-domain=host/authentication=classic/login-module=1:add(code=Kerberos, flag=Required, module-options={storeKey=true, useKeyTab=true, principal=HTTP/test-server.elytron.org@ELYTRON.ORG, keyTab=path/to/test-server.keytab, debug=true}

# Define the second SPNEGO security domain
/subsystem=security/security-domain=SPNEGO:add
/subsystem=security/security-domain=SPNEGO/authentication=classic:add
/subsystem=security/security-domain=SPNEGO/authentication=classic/login-module=1:add(code=SPNEGO, flag=requisite,  module-options={password-stacking=useFirstPass, serverSecurityDomain=host})
/subsystem=security/security-domain=SPNEGO/authentication=classic/login-module=1:write-attribute(name=module, value=org.jboss.security.negotiation)
/subsystem=security/security-domain=SPNEGO/authentication=classic/login-module=2:add(code=UsersRoles, flag=required, module-options={password-stacking=useFirstPass, usersProperties=  /path/to/kerberos/spnego-users.properties, rolesProperties=  /path/to/kerberos/spnego-roles.properties, defaultUsersProperties=  /path/to/kerberos/spnego-users.properties, defaultRolesProperties=  /path/to/kerberos/spnego-roles.properties})

Exemplo: Configuração usando um par de domínios de segurança [Esta é uma tradução automática]

<subsystem xmlns="urn:jboss:domain:security:2.0">
  <security-domains>
    ...
    <security-domain name="host">
      <authentication>
        <login-module name="1" code="Kerberos" flag="required">
          <module-option name="storeKey" value="true"/>
          <module-option name="useKeyTab" value="true"/>
          <module-option name="principal" value="HTTP/test-server.elytron.org@ELYTRON.ORG"/>
          <module-option name="keyTab" value="/path/to/test-server.keytab"/>
          <module-option name="debug" value="true"/>
        </login-module>
      </authentication>
    </security-domain>
    <security-domain name="SPNEGO">
      <authentication>
        <login-module name="1" code="SPNEGO" flag="requisite" module="org.jboss.security.negotiation">
          <module-option name="password-stacking" value="useFirstPass"/>
          <module-option name="serverSecurityDomain" value="host"/>
        </login-module>
        <login-module name="2" code="UsersRoles" flag="required">
          <module-option name="password-stacking" value="useFirstPass"/>
          <module-option name="usersProperties" value="path/to/kerberos/spnego-users.properties"/>
          <module-option name="rolesProperties" value="  /path/to/kerberos/spnego-roles.properties"/>
          <module-option name="defaultUsersProperties" value="  /path/to/kerberos/spnego-users.properties"/>
          <module-option name="defaultRolesProperties" value="  /path/to/kerberos/spnego-roles.properties"/>
        </login-module>
      </authentication>
    </security-domain>
  </security-domains>
</subsystem>

Os aplicativos legados são então implantados referenciando o domínio de segurança SPNEGO e protegidos com o mecanismo SPNEGO.

Migração da autenticação Kerberos para o Elytron [Esta é uma tradução automática]

Tanto a interface de gerenciamento quanto os aplicativos podem ser protegidos no Elytron usando uma região de segurança e uma fábrica de segurança Kerberos.

Defina uma região de segurança a ser usada para carregar informações de identidade.

/subsystem=elytron/properties-realm=spnego-properties:add(users-properties={path=path/to/spnego-users.properties, plain-text=true, digest-realm-name=ELYTRON.ORG}, groups-properties={path=path/to/spnego-roles.properties})

Defina uma fábrica de segurança Kerberos que permita ao servidor carregar sua própria identidade Kerberos.

/subsystem=elytron/kerberos-security-factory=test-server:add(path=path/to/test-server.keytab, principal=HTTP/test-server.elytron.org@ELYTRON.ORG, debug=true)

Defina um domínio de segurança para reunir a política, bem como uma fábrica de autenticação HTTP para a política de autenticação.

/subsystem=elytron/security-domain=SPNEGODomain:add(default-realm=spnego-properties, realms=[{realm=spnego-properties, role-decoder=groups-to-roles}], permission-mapper=default-permission-mapper)
/subsystem=elytron/http-authentication-factory=spnego-http-authentication:add(security-domain=SPNEGODomain, http-server-mechanism-factory=global,mechanism-configurations=[{mechanism-name=SPNEGO, credential-security-factory=test-server}])

Isso resulta na seguinte configuração no elytron subsistema do arquivo de configuração do servidor.

Exemplo: Configuração do Elytron Migrado [Esta é uma tradução automática]

<subsystem xmlns="urn:wildfly:elytron:1.2" final-providers="combined-providers" disallowed-providers="OracleUcrypto">
  ...
  <security-domains>
  ...
    <security-domain name="SPNEGODomain" default-realm="spnego-properties" permission-mapper="default-permission-mapper">
      <realm name="spnego-properties" role-decoder="groups-to-roles"/>
    </security-domain>
  </security-domains>
  <security-realms>
    ...
    <properties-realm name="spnego-properties">
      <users-properties path="path/to/spnego-users.properties" digest-realm-name="ELYTRON.ORG" plain-text="true"/>
      <groups-properties path="path/to/spnego-roles.properties"/>
    </properties-realm>
  </security-realms>
  <credential-security-factories>
    <kerberos-security-factory name="test-server" principal="HTTP/test-server.elytron.org@ELYTRON.ORG" path="path/to/test-server.keytab" debug="true"/>
  </credential-security-factories>
  ...
  <http>
    ...
    <http-authentication-factory name="spnego-http-authentication" http-server-mechanism-factory="global" security-domain="SPNEGODomain">
      <mechanism-configuration>
        <mechanism mechanism-name="SPNEGO" credential-security-factory="test-server"/>
      </mechanism-configuration>
    </http-authentication-factory>
    ...
  </http>
  ...
</subsystem>

Para proteger o aplicativo, defina um domínio de segurança do aplicativo no undertow subsistema para mapear domínios de segurança para este http-authentication-factory. A interface de gerenciamento HTTP pode ser atualizada para referenciar http-authentication-factory definido nesta configuração. Este processo está documentado no Migrar Autenticação e Autorização Baseadas em Propriedades para o Elytron seção deste guia.

Migração da autenticação Kerberos para o Elytron [Esta é uma tradução automática]

É possível definir uma região de segurança legada para que a autenticação Kerberos / GSSAPI SASL seja usada para autenticação remota, como a interface de gerenciamento nativa.

Exemplo: Autenticação Kerberos para Comandos CLI de Gerenciamento Remoto [Esta é uma tradução automática]

/core-service=management/security-realm=Kerberos:add
/core-service=management/security-realm=Kerberos/server-identity=kerberos:add
/core-service=management/security-realm=Kerberos/server-identity=kerberos/keytab=remote\/test-server.elytron.org@ELYTRON.ORG:add(path=path/to/remote-test-server.keytab, debug=true)
/core-service=management/security-realm=Kerberos/authentication=kerberos:add(remove-realm=true)

Exemplo: configuração de domínio de segurança remota do Kerberos [Esta é uma tradução automática]

<management>
  <security-realms>
    ...
    <security-realm name="Kerberos">
      <server-identities>
        <kerberos>
          <keytab principal="remote/test-server.elytron.org@ELYTRON.ORG" path="path/to/remote-test-server.keytab" debug="true"/>
        </kerberos>
      </server-identities>
      <authentication>
        <kerberos remove-realm="true"/>
      </authentication>
    </security-realm>
  </security-realms>
  ...
</management>

Migração da autenticação Kerberos para o Elytron [Esta é uma tradução automática]

As etapas para definir a configuração equivalente do Elytron são muito semelhantes às descritas Migração da Autenticação HTTP Kerberos.

Defina uma região de segurança a ser usada para carregar informações de identidade.

/path=kerberos:add(relative-to=user.home, path=src/kerberos)
/subsystem=elytron/properties-realm=kerberos-properties:add(users-properties={path=kerberos-users.properties, relative-to=kerberos, digest-realm-name=ELYTRON.ORG}, groups-properties={path=kerberos-groups.properties, relative-to=kerberos})

Defina a fábrica de segurança Kerberos para a identidade do servidor.

/subsystem=elytron/kerberos-security-factory=test-server:add(relative-to=kerberos, path=remote-test-server.keytab, principal=remote/test-server.elytron.org@ELYTRON.ORG)

Exemplo: Domínio de Segurança Elytron e Comandos de Configuração de Fábrica de Autenticação [Esta é uma tradução automática]

/subsystem=elytron/security-domain=KerberosDomain:add(default-realm=kerberos-properties, realms=[{realm=kerberos-properties, role-decoder=groups-to-roles}], permission-mapper=default-permission-mapper)
/subsystem=elytron/sasl-authentication-factory=gssapi-authentication-factory:add(security-domain=KerberosDomain, sasl-server-factory=elytron, mechanism-configurations=[{mechanism-name=GSSAPI, credential-security-factory=test-server}])

Isso resulta na seguinte configuração no elytron subsistema do arquivo de configuração do servidor.

<subsystem xmlns="urn:wildfly:elytron:1.2" final-providers="combined-providers" disallowed-providers="OracleUcrypto">
  ...
  <security-domains>
    ...
    <security-domain name="KerberosDomain" default-realm="kerberos-properties" permission-mapper="default-permission-mapper">
      <realm name="kerberos-properties" role-decoder="groups-to-roles"/>
    </security-domain>
  </security-domains>
  <security-realms>
   ...
     <properties-realm name="kerberos-properties">
       <users-properties path="kerberos-users.properties" relative-to="kerberos" digest-realm-name="ELYTRON.ORG"/>
       <groups-properties path="kerberos-groups.properties" relative-to="kerberos"/>
     </properties-realm>
   </security-realms>
   <credential-security-factories>
     <kerberos-security-factory name="test-server" principal="remote/test-server.elytron.org@ELYTRON.ORG" path="remote-test-server.keytab" relative-to="kerberos"/>
   </credential-security-factories>
   ...
   <sasl>
     ...
     <sasl-authentication-factory name="gssapi-authentication-factory" sasl-server-factory="elytron" security-domain="KerberosDomain">
       <mechanism-configuration>
         <mechanism mechanism-name="GSSAPI" credential-security-factory="test-server"/>
       </mechanism-configuration>
     </sasl-authentication-factory>
     ...
   </sasl>
 </subsystem>

A interface de gerenciamento ou os conectores remotos podem agora ser atualizados para fazer referência ao factory de autenticação SASL.

Os dois exemplos de Elytron definidos aqui também podem ser combinados para usar um domínio de segurança e um domínio de segurança compartilhados e apenas usar fábricas de autenticação específicas de protocolo, cada uma referenciando sua própria fábrica de segurança Kerberos.

7.3.5. Migrar lojas compostas para Elytron [Esta é uma tradução automática]

Esta seção descreve como migrar uma PicketBox ou domínio de segurança legado configuração que usa vários armazenamentos de identidades para Élitro. Ao usar o PicketBox ou os domínios de segurança legados, é possível definir uma configuração em que a autenticação é executada em um armazenamento de identidades enquanto as informações usadas para autorização são carregadas de um armazenamento diferente. Ao migrar para o Elytron, isso pode ser feito usando um domínio de segurança agregado.

Os exemplos a seguir executam a autenticação do usuário usando o example-users.properties arquivo de propriedades e, em seguida, consulte o LDAP para carregar as informações de grupo e função.

Nota

As configurações mostradas são baseadas nos exemplos das seções a seguir, que fornecem informações adicionais sobre o histórico:

Migrar Autenticação e Autorização Baseadas em Propriedades para o Elytron [Esta é uma tradução automática]
Migrar a configuração de autenticação LDAP para o Elytron

Exemplo: Configuração do PicketBox LoginModule [Esta é uma tradução automática]

O domínio de segurança PicketBox para este cenário é configurado usando os seguintes comandos da CLI de gerenciamento.

Exemplo: comandos de configuração do PicketBox [Esta é uma tradução automática]

/subsystem=security/security-domain=application-security:add

/subsystem=security/security-domain=application-security/authentication=classic:add(login-modules=[ {code=UsersRoles, flag=Required, module-options={ password-stacking=useFirstPass, usersProperties=file://${jboss.server.config.dir}/example-users.properties}} {code=LdapExtended, flag=Required, module-options={ password-stacking=useFirstPass, java.naming.factory.initial=com.sun.jndi.ldap.LdapCtxFactory, java.naming.provider.url=ldap://localhost:10389, java.naming.security.authentication=simple, bindDN="uid=admin,ou=system", bindCredential=secret, baseCtxDN="ou=users,dc=group-to-principal,dc=wildfly,dc=org", baseFilter="(uid={0})", rolesCtxDN="ou=groups,dc=group-to-principal,dc=wildfly,dc=org",roleFilter="(uniqueMember={1})", roleAttributeID="uid" }}])

Isso resulta na seguinte configuração do servidor.

Exemplo: Configuração do Domínio de Segurança do PicketBox [Esta é uma tradução automática]

<security-domain name="application-security">
  <authentication>
    <login-module code="UsersRoles" flag="required">
      <module-option name="password-stacking" value="useFirstPass"/>
      <module-option name="usersProperties" value="file://${jboss.server.config.dir}/example-users.properties"/>
    </login-module>
    <login-module code="LdapExtended" flag="required">
      <module-option name="password-stacking" value="useFirstPass"/>
      <module-option name="java.naming.factory.initial" value="com.sun.jndi.ldap.LdapCtxFactory"/>
      <module-option name="java.naming.provider.url" value="ldap://localhost:10389"/>
      <module-option name="java.naming.security.authentication" value="simple"/>
      <module-option name="bindDN" value="uid=admin,ou=system"/>
      <module-option name="bindCredential" value="secret"/>
      <module-option name="baseCtxDN" value="ou=users,dc=group-to-principal,dc=wildfly,dc=org"/>
      <module-option name="baseFilter" value="(uid={0})"/>
      <module-option name="rolesCtxDN" value="ou=groups,dc=group-to-principal,dc=wildfly,dc=org"/>
      <module-option name="roleFilter" value="(uniqueMember={1})"/>
      <module-option name="roleAttributeID" value="uid"/>
    </login-module>
  </authentication>
</security-domain>

Vejo Configuração do domínio de segurança agregada Elytron para saber como configurar um domínio de segurança agregado no elytron subsistema para realizar isso.

Exemplo: Comandos de Configuração do Reino de Segurança Legado [Esta é uma tradução automática]

A configuração de região de segurança legada para este cenário é configurada usando os seguintes comandos da CLI de gerenciamento.

Exemplo: Comandos de Configuração do Reino de Segurança Legado [Esta é uma tradução automática]

/core-service=management/ldap-connection=MyLdapConnection:add(url="ldap://localhost:10389", search-dn="uid=admin,ou=system", search-credential="secret")

/core-service=management/security-realm=ApplicationSecurity:add
/core-service=management/security-realm=ApplicationSecurity/authentication=properties:add(path=example-users.properties, relative-to=jboss.server.config.dir, plain-text=true)

batch
/core-service=management/security-realm=ApplicationSecurity/authorization=ldap:add(connection=MyLdapConnection)
/core-service=management/security-realm=ApplicationSecurity/authorization=ldap/username-to-dn=username-filter:add(attribute=uid, base-dn="ou=users,dc=group-to-principal,dc=wildfly,dc=org")
/core-service=management/security-realm=ApplicationSecurity/authorization=ldap/group-search=group-to-principal:add(base-dn="ou=groups,dc=group-to-principal,dc=wildfly,dc=org", iterative=true, prefer-original-connection=true, principal-attribute=uniqueMember, search-by=DISTINGUISHED_NAME, group-name=SIMPLE, group-name-attribute=uid)
run-batch

Isso resulta na seguinte configuração do servidor.

Exemplo: Comandos de Configuração do Reino de Segurança Legado [Esta é uma tradução automática]

<security-realms>
  ...
  <security-realm name="ApplicationSecurity">
    <authentication>
      <properties path="example-users.properties" relative-to="jboss.server.config.dir" plain-text="true"/>
    </authentication>
    <authorization>
      <ldap connection="MyLdapConnection">
        <username-to-dn>
          <username-filter base-dn="ou=users,dc=group-to-principal,dc=wildfly,dc=org" attribute="uid"/>
        </username-to-dn>
        <group-search group-name="SIMPLE" iterative="true" group-name-attribute="uid">
          <group-to-principal search-by="DISTINGUISHED_NAME" base-dn="ou=groups,dc=group-to-principal,dc=wildfly,dc=org" prefer-original-connection="true">
            <membership-filter principal-attribute="uniqueMember"/>
          </group-to-principal>
        </group-search>
      </ldap>
    </authorization>
  </security-realm>
</security-realms>
<outbound-connections>
  <ldap name="MyLdapConnection" url="ldap://localhost:10389" search-dn="uid=admin,ou=system" search-credential="secret"/>
</outbound-connections>

Vejo Configuração do domínio de segurança agregada Elytron para saber como configurar um domínio de segurança agregado no elytron subsistema para realizar isso.

Exemplo: Configuração do Realm de Segurança LDAP [Esta é uma tradução automática]

A configuração equivalente do Elytron para este cenário é configurada usando os seguintes comandos da CLI de gerenciamento.

Exemplo: Comandos de Configuração do Elytron [Esta é uma tradução automática]

/subsystem=elytron/dir-context=ldap-connection:add(url=ldap://localhost:10389, principal="uid=admin,ou=system", credential-reference={clear-text=secret})

/subsystem=elytron/ldap-realm=ldap-realm:add(dir-context=ldap-connection, direct-verification=true, identity-mapping={search-base-dn="ou=users,dc=group-to-principal,dc=wildfly,dc=org", rdn-identifier="uid", attribute-mapping=[{filter-base-dn="ou=groups,dc=group-to-principal,dc=wildfly,dc=org",filter="(uniqueMember={1})",from="uid",to="Roles"}]})

/subsystem=elytron/properties-realm=application-properties:add(users-properties={path=example-users.properties, relative-to=jboss.server.config.dir, plain-text=true, digest-realm-name="Application Security"})

/subsystem=elytron/aggregate-realm=combined-realm:add(authentication-realm=application-properties, authorization-realm=ldap-realm)

/subsystem=elytron/security-domain=application-security:add(realms=[{realm=combined-realm}], default-realm=combined-realm, permission-mapper=default-permission-mapper)
/subsystem=elytron/http-authentication-factory=application-security-http:add(http-server-mechanism-factory=global, security-domain=application-security, mechanism-configurations=[{mechanism-name=BASIC}])

Isso resulta na seguinte configuração do servidor.

Exemplo: Configuração Elytron [Esta é uma tradução automática]

<subsystem xmlns="urn:wildfly:elytron:1.2" final-providers="combined-providers" disallowed-providers="OracleUcrypto">
  ...
  <security-domains>
    ...
    <security-domain name="application-security" default-realm="combined-realm" permission-mapper="default-permission-mapper">
      <realm name="combined-realm"/>
    </security-domain>
  </security-domains>
  <security-realms>
    <aggregate-realm name="combined-realm" authentication-realm="application-properties" authorization-realm="ldap-realm"/>
      ...
      <properties-realm name="application-properties">
        <users-properties path="example-users.properties" relative-to="jboss.server.config.dir" digest-realm-name="Application Security" plain-text="true"/>
      </properties-realm>
      <ldap-realm name="ldap-realm" dir-context="ldap-connection" direct-verification="true">
        <identity-mapping rdn-identifier="uid" search-base-dn="ou=users,dc=group-to-principal,dc=wildfly,dc=org">
          <attribute-mapping>
            <attribute from="uid" to="Roles" filter="(uniqueMember={1})" filter-base-dn="ou=groups,dc=group-to-principal,dc=wildfly,dc=org"/>
          </attribute-mapping>
        </identity-mapping>
      </ldap-realm>
  </security-realms>
  ...
  <http>
    ...
    <http-authentication-factory name="application-security-http" http-server-mechanism-factory="global" security-domain="application-security">
      <mechanism-configuration>
        <mechanism mechanism-name="BASIC"/>
      </mechanism-configuration>
    </http-authentication-factory>
    ...
  </http>
  ...
  <dir-contexts>
    <dir-context name="ldap-connection" url="ldap://localhost:10389" principal="uid=admin,ou=system">
      <credential-reference clear-text="secret"/>
    </dir-context>
  </dir-contexts>
</subsystem>

No elytron subsistema, um aggregate-realm foi definido que especifica quais domínios de segurança devem ser usados para autenticação e quais usar para decisões de autorização.

7.3.6. Migrar os domínios de segurança que usam o cache para Elytron [Esta é uma tradução automática]

Ao usar o PicketBox, é possível definir um domínio de segurança e ativar o armazenamento em cache da memória para seu acesso. Isso permite que você acesse os dados de identidade na memória e evita o acesso direto adicional ao armazenamento de identidades. É possível obter uma configuração semelhante com o Elytron. Esta seção descreve como configurar o armazenamento em cache do domínio de segurança ao usar o Elytron.

Exemplo: Configuração do Domínio de Segurança em Cache do PicketBox [Esta é uma tradução automática]

Os comandos a seguir mostram como configurar um domínio de segurança PicketBox que permite o armazenamento em cache.

Exemplo: Comandos do Domínio de Segurança em Cache do PicketBox [Esta é uma tradução automática]

/subsystem=security/security-domain=application-security:add(cache-type=default)
/subsystem=security/security-domain=application-security/authentication=classic:add(login-modules=[{code=LdapExtended, flag=Required, module-options={ java.naming.factory.initial=com.sun.jndi.ldap.LdapCtxFactory, java.naming.provider.url=ldap://localhost:10389, java.naming.security.authentication=simple, bindDN="uid=admin,ou=system", bindCredential=secret, baseCtxDN="ou=users,dc=group-to-principal,dc=wildfly,dc=org", baseFilter="(uid={0})", rolesCtxDN="ou=groups,dc=group-to-principal,dc=wildfly,dc=org", roleFilter="(uniqueMember={1})", roleAttributeID="uid" }}])

Isso resulta na seguinte configuração do servidor.

Exemplo: Configuração do Domínio de Segurança em Cache do PicketBox [Esta é uma tradução automática]

<subsystem xmlns="urn:jboss:domain:security:2.0">
  <security-domains>
    ...
    <security-domain name="application-security" cache-type="default">
      <authentication>
        <login-module code="LdapExtended" flag="required">
          <module-option name="java.naming.factory.initial" value="com.sun.jndi.ldap.LdapCtxFactory"/>
          <module-option name="java.naming.provider.url" value="ldap://localhost:10389"/>
          <module-option name="java.naming.security.authentication" value="simple"/>
          <module-option name="bindDN" value="uid=admin,ou=system"/>
          <module-option name="bindCredential" value="secret"/>
          <module-option name="baseCtxDN" value="ou=users,dc=group-to-principal,dc=wildfly,dc=org"/>
          <module-option name="baseFilter" value="(uid={0})"/>
          <module-option name="rolesCtxDN" value="ou=groups,dc=group-to-principal,dc=wildfly,dc=org"/>
          <module-option name="roleFilter" value="(uniqueMember={1})"/>
          <module-option name="roleAttributeID" value="uid"/>
        </login-module>
      </authentication>
    </security-domain>
  </security-domains>
</subsystem>

Nota

Este comando e configuração resultante é semelhante ao exemplo mostrado em Migrar a configuração de autenticação LDAP para o Elytron; no entanto, aqui o atributo cache-type é definido com um valor de default. o default O tipo de cache é um cache na memória. Ao usar o PicketBox, você também pode especificar um cache-type do infinispan, no entanto, este tipo não é suportado pelo Elytron.

Exemplo: Configuração do Domínio de Segurança em Cache do Elytron [Esta é uma tradução automática]

Siga as etapas abaixo para criar uma configuração semelhante que armazena em cache um domínio de segurança ao usar o Elytron.

Defina um domínio de segurança e envolva o domínio de segurança em um domínio de armazenamento em cache. O domínio de armazenamento em cache pode ser usado em um domínio de segurança e, posteriormente, em uma fábrica de autenticação.

Exemplo: Comandos de Configuração do Elytron Security Realm [Esta é uma tradução automática]

/subsystem=elytron/dir-context=ldap-connection:add(url=ldap://localhost:10389, principal="uid=admin,ou=system", credential-reference={clear-text=secret})
/subsystem=elytron/ldap-realm=ldap-realm:add(dir-context=ldap-connection, direct-verification=true, identity-mapping={search-base-dn="ou=users,dc=group-to-principal,dc=wildfly,dc=org", rdn-identifier="uid", attribute-mapping=[{filter-base-dn="ou=groups,dc=group-to-principal,dc=wildfly,dc=org",filter="(uniqueMember={1})",from="uid",to="Roles"}]})
/subsystem=elytron/caching-realm=cached-ldap:add(realm=ldap-realm)

Defina um domínio de segurança e uma fábrica de autenticação HTTP que use o cached-ldap reino definido na etapa anterior.
Exemplo: Domínio de Segurança Elytron e Comandos de Configuração de Fábrica de Autenticação [Esta é uma tradução automática]
```
/subsystem=elytron/security-domain=application-security:add(realms=[{realm=cached-ldap}], default-realm=cached-ldap, permission-mapper=default-permission-mapper)
/subsystem=elytron/http-authentication-factory=application-security-http:add(http-server-mechanism-factory=global, security-domain=application-security, mechanism-configurations=[{mechanism-name=BASIC}])
```
Nota
Nesta etapa, é importante referenciar o caching-realm em vez do reino original. Caso contrário, o cache será ignorado.

Esses comandos resultam nas seguintes adições à configuração do servidor.

Exemplo: Configuração do Domínio de Segurança em Cache do Elytron [Esta é uma tradução automática]

<subsystem xmlns="urn:wildfly:elytron:1.2" final-providers="combined-providers" disallowed-providers="OracleUcrypto">
  ...
  <security-domains>
    ...
    <security-domain name="application-security" default-realm="cached-ldap" permission-mapper="default-permission-mapper">
      <realm name="cached-ldap"/>
    </security-domain>
  </security-domains>
  ...
  <security-realms>
    ....
  <ldap-realm name="ldap-realm" dir-context="ldap-connection" direct-verification="true">
      <identity-mapping rdn-identifier="uid" search-base-dn="ou=users,dc=group-to-principal,dc=wildfly,dc=org">
        <attribute-mapping>
          <attribute from="uid" to="Roles" filter="(uniqueMember={1})" filter-base-dn="ou=groups,dc=group-to-principal,dc=wildfly,dc=org"/>
        </attribute-mapping>
      </identity-mapping>
    </ldap-realm>
    <caching-realm name="cached-ldap" realm="ldap-realm"/>
  </security-realms>
  ...
  <http>
    ...
    <http-authentication-factory name="application-security-http" http-server-mechanism-factory="global" security-domain="application-security">
      <mechanism-configuration>
        <mechanism mechanism-name="BASIC"/>
      </mechanism-configuration>
    </http-authentication-factory>
    ...
  </http>
   ...
  <dir-contexts>
    <dir-context name="ldap-connection" url="ldap://localhost:10389" principal="uid=admin,ou=system">
      <credential-reference clear-text="secret"/>
    </dir-context>
  </dir-contexts>
  ...

7.3.7. Migre a Segurança do JACC para o Elytron [Esta é uma tradução automática]

Por padrão, o JBoss EAP usa o legado security subsistema para configurar o fornecedor e a fábrica de políticas do Java Authorization Contract for Containers (JACC). A configuração padrão é mapeada para implementações da PicketBox.

o elytron O subsistema fornece um provedor de políticas integrado com base na especificação JACC. Antes de configurar seu servidor para permitir que o Elytron gerencie configurações do JACC e outras políticas, você deve primeiro desabilitar o JACC no security subsistema usando o seguinte comando CLI de gerenciamento.

/subsystem=security:write-attribute(name=initialize-jacc, value=false)

Não fazer isso pode resultar no seguinte erro no log do servidor: MSC000004: Failure during stop of service org.wildfly.security.policy: java.lang.StackOverflowError.

Para obter informações sobre como ativar o JACC e definir um provedor de política JACC no elytron subsistema, consulte Ativando o JACC usando o elytron Subsistema no Guia de desenvolvimento para o JBoss EAP.

7.4. Migrar clientes de aplicativos [Esta é uma tradução automática]

7.4.1. Migrar uma configuração de cliente de nomeação para Elytron [Esta é uma tradução automática]

Esta seção descreve como migrar um aplicativo cliente que executa uma consulta JNDI remota usando um org.jboss.naming.remote.client.InitialContext classe, que é apoiado por um org.jboss.naming.remote.client.InitialContextFactory classe, para Elytron.

Os exemplos a seguir assumem que o InitialContextFactory classe é criada especificando propriedades para as credenciais do usuário e para o URL do provedor de nomeação ao qual ele se conecta.

Exemplo: InitialContext Código usado na liberação anterior [Esta é uma tradução automática]

Properties properties = new Properties();
properties.put(Context.INITIAL_CONTEXT_FACTORY, "org.jboss.naming.remote.client.InitialContextFactory");
properties.put(Context.PROVIDER_URL,"http-remoting://127.0.0.1:8080");
properties.put(Context.SECURITY_PRINCIPAL, "bob");
properties.put(Context.SECURITY_CREDENTIALS, "secret");
InitialContext context = new InitialContext(properties);
Bar bar = (Bar) context.lookup("foo/bar");
...

Você pode escolher uma das seguintes abordagens de migração:

Migrar o cliente de nomeação usando a abordagem do arquivo de configuração [Esta é uma tradução automática]
Migrar o cliente de nomeação usando a abordagem programática [Esta é uma tradução automática]

7.4.1.1. Migrar o cliente de nomeação usando a abordagem do arquivo de configuração [Esta é uma tradução automática]

Migrar o cliente de nomeação usando a abordagem do arquivo de configuração [Esta é uma tradução automática]

Crie um wildfly-config.xml arquivo no aplicativo cliente META-INF/ diretório. O arquivo deve conter as credenciais do usuário a serem usadas ao estabelecer uma conexão com o provedor de nomenclatura.

Exemplo: Configuração Equivalente Usando o wildfly-config.xml Arquivo [Esta é uma tradução automática]

<configuration>
  <authentication-client xmlns="urn:elytron:1.0.1">
    <authentication-rules>
      <rule use-configuration="namingConfig">
        <match-host name="127.0.0.1"/>
      </rule>
    </authentication-rules>
    <authentication-configurations>
      <configuration name="namingConfig">
        <set-user-name name="bob"/>
        <credentials>
          <clear-password password="secret"/>
        </credentials>
      </configuration>
    </authentication-configurations>
  </authentication-client>
</configuration>

Criar um InitialContext como no exemplo a seguir. Note que o InitialContext é apoiado pelo org.wildfly.naming.client.WildFlyInitialContextFactory classe.

Exemplo: InitialContext Código usado na liberação anterior [Esta é uma tradução automática]

Properties properties = new Properties();
properties.put(Context.INITIAL_CONTEXT_FACTORY,"org.wildfly.naming.client.WildFlyInitialContextFactory");
properties.put(Context.PROVIDER_URL,"remote+http://127.0.0.1:8080");
InitialContext context = new InitialContext(properties);
Bar bar = (Bar) context.lookup("foo/bar");
...

7.4.1.2. Migrar o cliente de nomeação usando a abordagem programática [Esta é uma tradução automática]

Usando essa abordagem, você fornece as credenciais do usuário que são usadas para estabelecer uma conexão com o provedor de nomenclatura diretamente no código do aplicativo.

Migrar o cliente EJB usando a abordagem programática [Esta é uma tradução automática]

// Create the authentication configuration
AuthenticationConfiguration namingConfig = AuthenticationConfiguration.empty().useName("bob").usePassword("secret");

// Create the authentication context
AuthenticationContext context = AuthenticationContext.empty().with(MatchRule.ALL.matchHost("127.0.0.1"), namingConfig);

// Create a callable that creates and uses an InitialContext
Callable<Void> callable = () -> {
    Properties properties = new Properties();
    properties.put(Context.INITIAL_CONTEXT_FACTORY,"org.wildfly.naming.client.WildFlyInitialContextFactory");
    properties.put(Context.PROVIDER_URL,"remote+http://127.0.0.1:8080");
    InitialContext context = new InitialContext(properties);
    Bar bar = (Bar) context.lookup("foo/bar");
    ...
    return null;
};

// Use the authentication context to run the callable
context.runCallable(callable);

7.4.2. Migrar um cliente EJB para Elytron [Esta é uma tradução automática]

Este exemplo de migração assume que o aplicativo cliente está configurado para chamar um EJB implementado em um servidor remoto usando um jboss-ejb-client.properties Arquivo. Este arquivo, localizado no aplicativo cliente META-INF/ diretório, contém as seguintes informações necessárias para conectar-se ao servidor remoto.

Exemplo: jboss-ejb-client.properties Arquivo [Esta é uma tradução automática]

remote.connectionprovider.create.options.org.xnio.Options.SSL_ENABLED=false
remote.connections=default
remote.connection.default.host=127.0.0.1
remote.connection.default.port = 8080
remote.connection.default.username=bob
remote.connection.default.password=secret

O cliente consulta o EJB e chama um de seus métodos usando código semelhante ao exemplo a seguir.

Exemplo: código do cliente que chama um EJB remoto [Esta é uma tradução automática]

// Create an InitialContext
Properties properties = new Properties();
properties.put(Context.URL_PKG_PREFIXES, "org.jboss.ejb.client.naming");
InitialContext context = new InitialContext(properties);

// Look up the EJB and invoke one of its methods
RemoteCalculator statelessRemoteCalculator = (RemoteCalculator) context.lookup(
    "ejb:/ejb-remote-server-side//CalculatorBean!" + RemoteCalculator.class.getName());
int sum = statelessRemoteCalculator.add(101, 202);

Você pode escolher uma das seguintes abordagens de migração:

Migrar o cliente EJB usando a abordagem do arquivo de configuração [Esta é uma tradução automática]
Migrar o cliente EJB usando a abordagem programática [Esta é uma tradução automática]

7.4.2.1. Migrar o cliente EJB usando a abordagem do arquivo de configuração [Esta é uma tradução automática]

Migrar o cliente de nomeação usando a abordagem do arquivo de configuração [Esta é uma tradução automática]

Configurar um wildfly-config.xml arquivo no aplicativo cliente META-INF/ diretório. O arquivo deve conter as credenciais do usuário a serem usadas ao estabelecer uma conexão com o provedor de nomenclatura.

Exemplo: Configuração Equivalente Usando o wildfly-config.xml Arquivo [Esta é uma tradução automática]

<configuration>
  <authentication-client xmlns="urn:elytron:1.0.1">
    <authentication-rules>
      <rule use-configuration="ejbConfig">
        <match-host name="127.0.0.1"/>
      </rule>
    </authentication-rules>
    <authentication-configurations>
      <configuration name="ejbConfig">
        <set-user-name name="bob"/>
        <credentials>
          <clear-password password="secret"/>
        </credentials>
      </configuration>
    </authentication-configurations>
  </authentication-client>
  <jboss-ejb-client xmlns="urn:jboss:wildfly-client-ejb:3.0">
    <connections>
      <connection uri="remote+http://127.0.0.1:8080" />
    </connections>
  </jboss-ejb-client>
</configuration>

Criar um InitialContext como no exemplo a seguir. Note que o InitialContext é apoiado pelo org.wildfly.naming.client.WildFlyInitialContextFactory classe.

Exemplo: InitialContext Código usado na liberação anterior [Esta é uma tradução automática]

// Create an InitialContext
Properties properties = new Properties();
properties.put(Context.INITIAL_CONTEXT_FACTORY,"org.wildfly.naming.client.WildFlyInitialContextFactory");
InitialContext context = new InitialContext(properties);

// Look up an EJB and invoke one of its methods
// Note that this code is the same as before
RemoteCalculator statelessRemoteCalculator = (RemoteCalculator) context.lookup(
    "ejb:/ejb-remote-server-side//CalculatorBean!" + RemoteCalculator.class.getName());
int sum = statelessRemoteCalculator.add(101, 202);----

Exemplo: jboss-ejb-client.properties Arquivo de propriedades [Esta é uma tradução automática]

7.4.2.2. Migrar o cliente EJB usando a abordagem programática [Esta é uma tradução automática]

Usando essa abordagem, você fornece as informações necessárias para se conectar ao servidor remoto diretamente no código do aplicativo.

Migrar o cliente EJB usando a abordagem programática [Esta é uma tradução automática]

// Create the authentication configuration
AuthenticationConfiguration ejbConfig = AuthenticationConfiguration.empty().useName("bob").usePassword("secret");

// Create the authentication context
AuthenticationContext context = AuthenticationContext.empty().with(MatchRule.ALL.matchHost("127.0.0.1"), ejbConfig);

// Create a callable that invokes the EJB
Callable<Void> callable = () -> {

    // Create an InitialContext
    Properties properties = new Properties();
    properties.put(Context.INITIAL_CONTEXT_FACTORY, "org.wildfly.naming.client.WildFlyInitialContextFactory");
    properties.put(Context.PROVIDER_URL, "remote+http://127.0.0.1:8080");
    InitialContext context = new InitialContext(properties);

    // Look up the EJB and invoke one of its methods
    // Note that this code is the same as before
    RemoteCalculator statelessRemoteCalculator = (RemoteCalculator) context.lookup(
        "ejb:/ejb-remote-server-side//CalculatorBean!" + RemoteCalculator.class.getName());
    int sum = statelessRemoteCalculator.add(101, 202);
    ...
    return null;
};

// Use the authentication context to run the callable
context.runCallable(callable);

Exemplo: jboss-ejb-client.properties Arquivo de propriedades [Esta é uma tradução automática]

7.5. Migrar configurações SSL [Esta é uma tradução automática]

7.5.1. Migrar uma configuração SSL simples para o Elytron [Esta é uma tradução automática]

Se você protegeu conexões HTTP com o servidor do JBoss EAP usando uma região de segurança, pode migrar essa configuração para o Elytron usando as informações fornecidas nesta seção.

Os exemplos a seguir presumem que você tenha os seguintes keystore configurado no security-realm.

Exemplo: Configuração SSL Usando um Keystore de Realm de Segurança [Esta é uma tradução automática]

<security-realm name="ApplicationRealm">
  <server-identities>
    <ssl>
      <keystore path="server.keystore" relative-to="jboss.server.config.dir" keystore-password="keystore_password" alias="server" key-password="key_password" />
    </ssl>
  </server-identities>
</security-realm>

Siga os passos abaixo para obter a mesma configuração usando o Elytron.

Crie um key-store no elytron subsistema que especifica o local do keystore e a senha pela qual ele é criptografado. Este comando assume que o keystore foi gerado usando o comando keytool e seu tipo é JKS.
```
/subsystem=elytron/key-store=LocalhostKeyStore:add(path=server.keystore,relative-to=jboss.server.config.dir,credential-reference={clear-text="keystore_password"},type=JKS)
```

Crie um key-manager no elytron subsistema que especifica o key-store definido na etapa anterior, o alias e a senha da chave.

/subsystem=elytron/key-manager=LocalhostKeyManager:add(key-store=LocalhostKeyStore,alias-filter=server,credential-reference={clear-text="key_password"})

Crie um server-ssl-context no elytron subsistema que referencia o key-manager que foi definido na etapa anterior.
```
/subsystem=elytron/server-ssl-context=LocalhostSslContext:add(key-manager=LocalhostKeyManager)
```

Mude o https-listener do legado security-realm para o recém-criado Elytron ssl-context.

batch
/subsystem=undertow/server=default-server/https-listener=https:undefine-attribute(name=security-realm)
/subsystem=undertow/server=default-server/https-listener=https:write-attribute(name=ssl-context,value=LocalhostSslContext)
run-batch

Recarregue o servidor.
```
recarregar
```

Isso resulta nas seguintes elytron configuração do subsistema no arquivo de configuração do servidor.

<subsystem xmlns="urn:wildfly:elytron:1.2" ...>
  ...
  <tls>
    <key-stores>
      <key-store name="LocalhostKeyStore">
        <credential-reference clear-text="keystore_password"/>
        <implementation type="JKS"/>
        <file path="server.keystore" relative-to="jboss.server.config.dir"/>
      </key-store>
    </key-stores>
    <key-managers>
      <key-manager name="LocalhostKeyManager" key-store="LocalhostKeyStore"  alias-filter="server">
        <credential-reference clear-text="key_password"/>
      </key-manager>
    </key-managers>
    <server-ssl-contexts>
      <server-ssl-context name="LocalhostSslContext" key-manager="LocalhostKeyManager"/>
    </server-ssl-contexts>
  </tls>
</subsystem>

Isso resulta nas seguintes undertow configuração do subsistema no arquivo de configuração do servidor.

<https-listener name="https" socket-binding="https" ssl-context="LocalhostSslContext" enable-http2="true"/>

Para mais informações, veja Subsistema Elytron e Como proteger as interfaces de gerenciamento dentro Como configurar a segurança do servidor para o JBoss EAP.

7.5.2. Migrar Autenticação SSL de Cliente-Certificado para Elytron [Esta é uma tradução automática]

Se você configurou a autenticação SSL do Client-Cert usando um truststore de security realm, poderá migrar essa configuração para o Elytron usando as informações fornecidas nesta seção.

Os passos abaixo assumem que você tem o seguinte truststore configurado no security-realm.

Exemplo: Configuração SSL Usando o Truststore de Realm de Segurança [Esta é uma tradução automática]

<security-realm name="ApplicationRealm">
  <server-identities>
    <ssl>
      <keystore path="server.keystore" relative-to="jboss.server.config.dir" keystore-password="keystore_password" alias="server" key-password="key_password" />
    </ssl>
  </server-identities>
  <authentication>
    <truststore path="server.truststore" relative-to="jboss.server.config.dir" keystore-password="truststore_password" />
    <local default-user="$local"/>
    <properties path="application-users.properties" relative-to="jboss.server.config.dir"/>
  </authentication>
  <authorization>
    <properties path="application-roles.properties" relative-to="jboss.server.config.dir"/>
  </authorization>
</security-realm>

Importante

As etapas abaixo apenas fornecem configuração para impedir que usuários sem um certificado válido e uma chave privada acessem o servidor. Eles não configuram a identidade do usuário para autenticação no servidor. Supõe-se que você já tenha configurado a autenticação HTTP CLIENT-CERT e a autenticação SASL externa para autenticação de identidade do usuário.

Siga estas etapas para configurar o servidor para impedir que usuários sem um certificado válido e uma chave privada acessem o servidor usando o Elytron.

Crie um key-store no elytron subsistema que especifica o local do keystore e a senha pela qual ele é criptografado. Este comando assume que o keystore foi gerado usando o comando keytool e seu tipo é JKS.
```
/subsystem=elytron/key-store=LocalhostKeyStore:add(path=server.keystore,relative-to=jboss.server.config.dir,credential-reference={clear-text="keystore_password"},type=JKS)
```
Crie um key-store no elytron subsistema que especifica o local do armazenamento confiável e a senha pela qual ele é criptografado. Este comando assume que o keystore foi gerado usando o comando keytool e seu tipo é JKS.
```
/subsystem=elytron/key-store=TrustStore:add(path=server.truststore,relative-to=jboss.server.config.dir,credential-reference={clear-text="truststore_password"},type=JKS)
```

Crie um key-manager no elytron subsistema que especifica o definido anteriormente LocalhostKeyStore keystore, o alias e a senha da chave.

/subsystem=elytron/key-manager=LocalhostKeyManager:add(key-store=LocalhostKeyStore,alias-filter=server,credential-reference={clear-text="key_password"})

Crie um trust-manager no elytron subsistema que especifica o key-store do armazenamento confiável criado anteriormente.
```
/subsystem=elytron/trust-manager=TrustManager:add(key-store=TrustStore)
```
Crie um server-ssl-context no elytron subsistema que faz referência ao anteriormente definido key-manager, define o trust-manager atributo e permite a autenticação do cliente.
```
/subsystem=elytron/server-ssl-context=LocalhostSslContext:add(key-manager=LocalhostKeyManager,trust-manager=TrustManager,need-client-auth=true)
```

Mude o https-listener do legado security-realm para o recém-criado Elytron ssl-context.

batch
/subsystem=undertow/server=default-server/https-listener=https:undefine-attribute(name=security-realm)
/subsystem=undertow/server=default-server/https-listener=https:write-attribute(name=ssl-context,value=LocalhostSslContext)
run-batch

Recarregue o servidor.
```
recarregar
```

Isso resulta nas seguintes elytron configuração do subsistema no arquivo de configuração do servidor.

<subsystem xmlns="urn:wildfly:elytron:1.2" ...>
  ...
  <tls>
    <key-stores>
      <key-store name="LocalhostKeyStore">
        <credential-reference clear-text="keystore_password"/>
        <implementation type="JKS"/>
        <file path="server.keystore" relative-to="jboss.server.config.dir"/>
      </key-store>
      <key-store name="TrustStore">
        <credential-reference clear-text="truststore_password"/>
        <implementation type="JKS"/>
        <file path="server.truststore" relative-to="jboss.server.config.dir"/>
      </key-store>
    </key-stores>
    <key-managers>
      <key-manager name="LocalhostKeyManager" key-store="LocalhostKeyStore" alias-filter="server">
        <credential-reference clear-text="key_password"/>
      </key-manager>
    </key-managers>
    <trust-managers>
      <trust-manager name="TrustManager" key-store="TrustStore"/>
    </trust-managers>
    <server-ssl-contexts>
      <server-ssl-context name="LocalhostSslContext" need-client-auth="true" key-manager="LocalhostKeyManager" trust-manager="TrustManager"/>
    </server-ssl-contexts>
  </tls>
</subsystem>

Isso resulta nas seguintes undertow configuração do subsistema no arquivo de configuração do servidor.

<https-listener name="https" socket-binding="https" ssl-context="LocalhostSslContext" enable-http2="true"/>

Para mais informações, veja Subsistema Elytron e Usando um contexto SSL-cliente dentro Como configurar a segurança do servidor para o JBoss EAP.

Where did the comment section go?

Red Hat's documentation publication system recently went through an upgrade to enable speedier, more mobile-friendly content. We decided to re-evaluate our commenting platform to ensure that it meets your expectations and serves as an optimal feedback mechanism. During this redesign, we invite your input on providing feedback on Red Hat documentation via the discussion platform.