Capítulo 7. Migración a Elytron en JBoss EAP 7.1 [Esto es una traducción automática]
7.1. Descripción general de Elytron [Esto es una traducción automática]
JBoss EAP 7.1 presenta Elytron, que proporciona un único marco unificado que puede administrar y configurar el acceso tanto para servidores independientes como para dominios administrados. También se puede usar para configurar el acceso de seguridad para aplicaciones implementadas en servidores JBoss EAP.
Las arquitecturas de Elytron y el subsistema de seguridad heredado que se basa en PicketBox son muy diferentes. Con Elytron, se intentó crear una solución que le permita operar en los mismos entornos de seguridad en los que opera actualmente; sin embargo, esto no no significa que cada opción de configuración de PicketBox tiene una opción de configuración equivalente en Elytron.
Si no puede encontrar información en la documentación que lo ayude a lograr una funcionalidad similar utilizando Elytron que tenía al usar la implementación de seguridad heredada, puede encontrar ayuda de una de las siguientes maneras.
- Si tienes un Suscripción a Red Hat Development, tienes acceso a Casos de soporte, Soluciones, y Artículos de conocimiento en el portal de clientes de Red Hat. También puedes abrir un caso con Soporte técnico y consigue ayuda de la comunidad WildFly como se describe a continuación.
- Si no tienes una suscripción a Red Hat Development, aún puedes acceder Artículos de conocimiento en el portal de clientes de Red Hat. También puedes unirte al foros de usuarios y chat en vivo para hacer preguntas a la comunidad de WildFly. La oferta de la comunidad WildFly es monitoreada activamente por el equipo de ingeniería de Elytron.
Su configuración de servidor JBoss EAP 7.0 y las implementaciones que utilizan el legado security el subsistema, que está basado en PicketBox, debería ejecutarse sin cambios en JBoss EAP 7.1. PicketBox continúa admitiendo dominios de seguridad, lo que permite que las aplicaciones continúen utilizando los módulos de inicio de sesión existentes. Los dominios de seguridad, que son utilizados por la capa de administración para la seguridad, también son transferidos e imitados por Elytron. Esto le permite definir la autenticación tanto en el elytron y legado security subsistemas y usarlos en paralelo. Para obtener más información acerca de cómo configurar su aplicación para usar Elytron y la seguridad heredada, consulte Configurar aplicaciones web para usar Elytron o Legacy Security para la autenticación en Cómo configurar la gestión de identidad para JBoss EAP.
Aunque la autenticación PicketBox sigue siendo compatible, se recomienda que cambie a Elytron cuando esté listo para migrar sus aplicaciones. Una de las ventajas de usar la seguridad de Elytron es que proporciona una solución de seguridad consistente en todo el servidor y sus aplicaciones. Para obtener información sobre cómo migrar la autenticación y autorización de PicketBox para usar Elytron, consulte Migrar la configuración de autenticación en esta guía.
Para obtener una descripción general de los nuevos recursos que están disponibles en elytron subsistema, ver Recursos en el subsistema Elytron en el JBoss EAP Arquitectura de seguridad guía.
Tenga en cuenta que si elige usar tanto el legado security subsistema y Elytron en sus implementaciones, las invocaciones entre implementaciones que usan arquitecturas de seguridad diferentes no son compatibles.
Para obtener más información sobre el uso de estos subsistemas en paralelo, consulte Usando Elytron y los subsistemas de seguridad heredados en paralelo en Cómo configurar la gestión de identidad para JBoss EAP.
7.2. Migrar bóvedas y propiedades seguras [Esto es una traducción automática]
7.2.1. Migre las bóvedas para proteger el almacenamiento de credenciales [Esto es una traducción automática]
La bóveda que se usó para almacenar el cifrado de cadenas de texto sin formato en el legado security El subsistema en JBoss EAP 7.0 no es compatible con Elytron en JBoss EAP 7.1, que utiliza un almacén de credenciales recientemente diseñado para almacenar cadenas. Las tiendas de credenciales cifran las credenciales de forma segura en un archivo de almacenamiento externo a los archivos de configuración de JBoss EAP. Puede usar la implementación provista por Elytron o puede personalizar la configuración usando las API y SPI del store de credenciales. Cada servidor JBoss EAP puede contener múltiples tiendas de credenciales.
Si utilizó previamente expresiones de bóveda para parametrizar datos no sensibles, se recomienda que reemplace los datos con Propiedades de seguridad Elytron.
Si continúas usando el legado security subsistema, no debería necesitar modificar o actualizar sus datos de bóveda. Sin embargo, si planea migrar su aplicación para usar Elytron, debe convertir sus bóvedas existentes en tiendas de credenciales para que puedan ser procesadas por el elytron subsistema. Para obtener más información acerca de las tiendas de credenciales, consulte Tiendas de credenciales en Cómo configurar la seguridad del servidor para JBoss EAP.
Migre los clientes para usar el archivo de configuración de WildFly [Esto es una traducción automática]
La herramienta Wildly Elytron que se envía con JBoss EAP proporciona una vault comando para ayudarlo a migrar el contenido de la bóveda a las tiendas de credenciales. Ejecuta la herramienta ejecutando el elytron-tool script, que se encuentra en EAP_HOME/bin directorio.
$ EAP_HOME/bin/elytron-tool.sh vault VAULT_ARGUMENTS
Si lo prefiere, puede ejecutar la herramienta ejecutando el java -jar mando.
$ java -jar EAP_HOME/bin/wildfly-elytron-tool.jar vault VAULT_ARGUMENTS
Puede usar el siguiente comando para obtener una descripción de todos los argumentos disponibles.
$ EAP_HOME/bin/elytron-tool.sh vault --help- La herramienta Wildly Elytron no puede manejar la primera versión de los archivos de datos de la bóveda de seguridad.
-
Puede ingresar el
--keystore-passwordargumento en formato enmascarado, como se muestra en el siguiente ejemplo para migrar una sola bóveda, o en texto claro. -
los
--salty--iterationse proporcionan argumentos para proporcionar información para descifrar la contraseña enmascarada o para generar una contraseña enmascarada en la salida. Si el--salty--iterationlos argumentos se omiten, se usan valores predeterminados. -
los
--summaryEl argumento produce comandos CLI de administración formateados que se pueden usar para agregar las tiendas de credenciales convertidas a la configuración de JBoss EAP. Las contraseñas de texto plano están enmascaradas en el resultado del resumen.
Tenga en cuenta que las tiendas de credenciales solo se pueden usar para proteger contraseñas. No son compatibles con la característica de expresión de la bóveda que podría utilizarse en cualquier lugar del modelo de gestión.
Elija una de las siguientes opciones de migración:
Migre las bóvedas para proteger el almacenamiento de credenciales [Esto es una traducción automática]
El siguiente es un ejemplo del comando utilizado para convertir una única bóveda de seguridad a un almacén de credenciales.
$ 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 --summaryEste comando convierte la bóveda de seguridad en un almacén de credenciales e imprime el resumen de los comandos CLI de administración que se usaron para convertirlo en la salida.
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"})Migre las bóvedas para proteger el almacenamiento de credenciales [Esto es una traducción automática]
Puede convertir varias bóvedas en una tienda de credenciales utilizando --bulk-convert argumento y apuntando a un archivo descriptor de conversión masiva.
Los ejemplos en esta sección usan el siguiente archivo descriptor de conversión masiva.
Ejemplo: bulk-vault-conversion-descriptor.txt Archivo [Esto es una traducción 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
Una nueva conversión comienza cuando cada nuevo keystore: línea se encuentra. Todas las opciones son obligatorias excepto por salt, iteration, y properties.
Para realizar la conversión masiva y generar resultados que formatean los comandos CLI de administración, ejecute el siguiente comando.
$ EAP_HOME/bin/elytron-tool.sh vault --bulk-convert path/to/bulk-vault-conversion-descriptor.txt --summary
Este comando convierte todas las bóvedas de seguridad especificadas en el archivo en un almacén de credenciales e imprime el resumen de los comandos CLI de administración que se usaron para convertirlos en el resultado.
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. Migre las propiedades de seguridad a Elytron [Esto es una traducción automática]
Los ejemplos en esta sección suponen que group.name y encoding.algorithm las propiedades de seguridad se definen como security-properties en el legado security subsistema de la siguiente manera.
Ejemplo: Propiedades de seguridad definidas en security Subsistema [Esto es una traducción 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 las mismas propiedades de seguridad en elytron subsistema, configure el security-properties atributo de la elytron subsistema utilizando el siguiente comando CLI de gestión.
/subsystem=elytron:write-attribute(name=security-properties, value={ group.name = "engineering-group", encoding.algorithm = "BASE64" })
Esto configura lo siguiente security-properties en el elytron subsistema en el archivo de configuración del 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>
los write-attribute la operación utilizada en el comando anterior sobrescribe las propiedades existentes. Para agregar o cambiar una propiedad de seguridad sin afectar otras propiedades de seguridad, use la map operación en el comando CLI de administración.
/subsystem=elytron:map-put(name=security-properties, key=group.name, value=technical-support)
De manera similar, puede eliminar una propiedad de seguridad específica utilizando el map-remove operación.
/subsystem=elytron:map-remove(name=security-properties, key=group.name)
7.3. Migrar la configuración de autenticación [Esto es una traducción automática]
7.3.1. Migre la autenticación y autorización basada en las propiedades a Elytron [Esto es una traducción automática]
7.3.1.1. Migre la configuración basada en propiedades de PicketBox a Elytron [Esto es una traducción automática]
Esta sección describe cómo migrar la autenticación basada en propiedades de PicketBox a Elytron. Puedes elegir migrar parcialmente autenticación basada en propiedades exponiendo únicamente el dominio de seguridad PicketBox a Elytron o puede migrar completamente las configuraciones de autenticación basadas en propiedades para usar Elytron.
Los siguientes procedimientos suponen que la aplicación web implementada que planea migrar está configurada para requerir autenticación basada en formularios. La aplicación hace referencia a un dominio de seguridad PicketBox y está utilizando el UsersRolesLoginModule para cargar información del usuario desde example-users.properties y example-roles.properties archivos. Estos ejemplos también suponen que el dominio de seguridad se define en el legado security subsistema utilizando los siguientes comandos CLI de gestión.
Ejemplo: Comandos de configuración basados en las propiedades de PicketBox [Esto es una traducción 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}}])
Esto da como resultado la siguiente configuración de servidor.
Ejemplo: configuración de dominio de seguridad basada en propiedades de PicketBox [Esto es una traducción 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>
Elija una de las siguientes opciones de migración:
Parcialmente migrar al exponer el dominio de seguridad de PicketBox a Elytron
Puede exponer un dominio de seguridad PicketBox como un dominio de seguridad Elytron para que pueda conectarse a una configuración Elytron; sin embargo, hacerlo crea una dependencia en el legado security subsistema. Si solo está migrando la autenticación basada en propiedades, se recomienda que migrar completamente la aplicación a Elytron para evitar la dependencia innecesaria del legado security subsistema. Sin embargo, una migración parcial puede ser una solución intermedia cuando no es posible migrar completamente la aplicación para usar Elytron.
Siga este procedimiento para agregar una configuración de dominio de seguridad PicketBox existente como un dominio de seguridad Elytron.
Ejemplo: Propiedades de seguridad definidas en
securitySubsistema [Esto es una traducción automática]/subsystem=security/elytron-realm=application-security:add(legacy-jaas-config=application-security)
Esto configura el siguiente reino de seguridad Elytron en el
securitysubsistema del archivo de configuración del 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 un dominio de seguridad en el
elytronsubsistema que hace referencia al reino de seguridad exportado y una fábrica de autenticación HTTP que admite la autenticación basada en formularios./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}]}]Esto resulta en lo siguiente
elytronconfiguración del subsistema en el archivo de configuración del 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>Asigne el dominio de seguridad al que hace referencia la implementación a la fábrica de autenticación HTTP recientemente definida en
undertowsubsistema./subsystem=undertow/application-security-domain=application-security:add(http-authentication-factory=application-security-http)
Esto da como resultado la siguiente configuración en
undertowsubsistema del archivo de configuración del 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>
- Si la aplicación ya se implementó antes de esta configuración, debe volver a cargar el servidor o volver a implementar la aplicación para que la nueva asignación de dominio de seguridad de la aplicación surta efecto.
Verifique que la asignación se aplicó a la implementación utilizando el siguiente comando CLI de administración. La implementación utilizada en este ejemplo es
HelloWorld.war. El resultado de este comando muestra que esta implementación hace referencia a la asignación de 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 } }
En esta etapa, el dominio de seguridad previamente definido se utiliza para su LoginModule configuración, pero está envuelto por los componentes de Elytron, que se hacen cargo de la autenticación.
Migre la autenticación y autorización basada en las propiedades a Elytron [Esto es una traducción automática]
Siga estos pasos para migrar completamente la autenticación basada en propiedades de PicketBox a Elytron. Este procedimiento supone que está comenzando con la configuración heredada descrita en la introducción a esta sección y tiene no migrado a la parcialmente migrado solución. Cuando haya completado este proceso, cualquier definición de dominio de seguridad que exista en el legado security subsistema permanece completamente independiente de la configuración de Elytron.
Definir un nuevo reino de seguridad en
elytronsubsistema que hace referencia a los archivos de propiedades de 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 un subsistema de dominio de seguridad y una fábrica de autenticación HTTP en
elytronsubsistema./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}])Esto resulta en lo siguiente
elytronconfiguración del subsistema en el archivo de configuración del 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>
Asigne el dominio de seguridad de la aplicación al que hace referencia la implementación a la fábrica de autenticación HTTP recientemente definida en
undertowsubsistema./subsystem=undertow/application-security-domain=application-security:add(http-authentication-factory=application-security-http)
Esto resulta en lo siguiente
undertowconfiguración del subsistema en el archivo de configuración del 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>
- Debe volver a cargar el servidor o volver a implementar la aplicación para que la nueva asignación de dominio de seguridad de la aplicación surta efecto.
La autenticación ahora está configurada para ser equivalente a la configuración de PicketBox; sin embargo, los componentes de Elytron ahora se usan exclusivamente para la autenticación.
7.3.1.2. Migre la configuración heredada basada en propiedades a Elytron [Esto es una traducción automática]
Esta sección describe cómo migrar un reino de seguridad heredado que carga información de usuarios, contraseñas y grupos desde los archivos de propiedades a Elytron. Este tipo de reino de seguridad heredado se usa generalmente para proteger las interfaces de administración o los conectores remotos.
Estos ejemplos suponen que el dominio de seguridad heredado se define mediante los siguientes comandos CLI de gestión.
Ejemplo: Comandos Legacy Security Realm [Esto es una traducción 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)
Esto da como resultado la siguiente configuración de servidor.
Ejemplo: Comandos de configuración de dominios de seguridad heredados [Esto es una traducción 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>
Una de las motivaciones para agregar la seguridad de Elytron al servidor de aplicaciones es permitir que se use una solución de seguridad consistente en todo el servidor. Los pasos iniciales para migrar un dominio de seguridad heredado basado en propiedades a Elytron son similares a los utilizados para migrar una autenticación basada en propiedades de PicketBox a Elytron. Siga estos pasos para migrar un dominio de seguridad heredado basado en propiedades a Elytron.
Definir un nuevo reino de seguridad en
elytronsubsistema que hace referencia a los archivos de propiedades./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 un subsistema de dominio de seguridad y una fábrica de autenticación HTTP en
elytronsubsistema./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}])Esto da como resultado la siguiente configuración de 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 un
sasl-authentication-factorypara que el reino de seguridad heredado también se pueda usar para la autenticación de capa de seguridad de autenticación simple (SASL)./subsystem=elytron/sasl-authentication-factory=application-security-sasl:add(sasl-server-factory=elytron, security-domain=application-security, mechanism-configurations=[{mechanism-name=PLAIN}])Esto da como resultado la siguiente configuración de 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 un conector remoto para la autenticación SASL y elimine la asociación con el reino de seguridad heredado.
/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)
Esto da como resultado la siguiente configuración en
remotingsubsistema del archivo de configuración del 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>
Agregue las dos fábricas de autenticación y elimine las referencias heredadas del reino de seguridad para asegurar el
http-interfacecon 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)
Esto da como resultado la siguiente configuración.
<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>
NotaDebería elegir nombres más adecuados que los utilizados en estos ejemplos para proteger las interfaces de gestión.
Migre la configuración heredada basada en propiedades a Elytron [Esto es una traducción automática]
7.3.2. Migre la configuración de autenticación LDAP a Elytron [Esto es una traducción automática]
Esta sección describe cómo migrar la autenticación LDAP heredada a Elytron para que pueda administrar la información como atributos de identidad. Gran parte de la información proporcionada en la sección titulada Migre la autenticación y autorización basada en las propiedades a Elytron se aplica aquí, particularmente con respecto a cómo definir dominios de seguridad y fábricas de autenticación, y cómo mapearlas para ser utilizadas para la autenticación. Esta sección no repite esas instrucciones, así que asegúrese de leer esa sección antes de continuar.
Los siguientes ejemplos suponen que la información de grupo o rol se carga directamente desde LDAP y que la autenticación LDAP heredada se configura de la siguiente manera.
El servidor LDAP contiene las siguientes entradas de usuario y grupo.
Ejemplo: entradas de usuario del servidor LDAP [Esto es una traducción 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==Ejemplo: entradas de grupos de servidores LDAP [Esto es una traducción 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 fines de autenticación, el nombre de usuario se compara con el
uidatributo y el nombre del grupo resultante se toma de lauidatributo de la entrada del grupo.La conexión con el servidor LDAP y el reino de seguridad relacionado se define mediante los siguientes comandos CLI de gestión.
Ejemplo: Comandos de configuración de LDAP Security Realm [Esto es una traducción 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
Esto da como resultado la siguiente configuración de servidor.
Ejemplo: Configuración de LDAP Security Realm [Esto es una traducción 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>
Los siguientes comandos CLI de gestión se utilizan para configurar un dominio de seguridad PicketBox, que utiliza el
LdapExtLoginModulepara verificar un nombre de usuario y contraseña.Ejemplo: Comandos de configuración de dominio de seguridad [Esto es una traducción 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" }}])Esto da como resultado la siguiente configuración de servidor.
Ejemplo: configuración de dominio de seguridad [Esto es una traducción 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 la autenticación LDAP heredada a Elytron [Esto es una traducción automática]
Siga estos pasos para migrar la configuración de ejemplo de autenticación LDAP anterior a Elytron. Esta sección se aplica a la migración de un legado de seguridad LDAP reino así como también Dominio de seguridad LDAP de PicketBox.
Ejemplo: Propiedades de seguridad definidas en
securitySubsistema [Esto es una traducción automática]/subsystem=elytron/dir-context=ldap-connection:add(url=ldap://localhost:10389, principal="uid=admin, ou=system", credential-reference={clear-text=secret})Cree un dominio de seguridad para buscar LDAP y verifique la contraseña proporcionada.
/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"}]})
Estos pasos resultan en lo siguiente elytron configuración del subsistema en el archivo de configuración del 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>
Por defecto, si no role-decoder se define para un dado security-domain, el atributo de identidad "Roles" se asigna a los roles de identidad.
La información cargada desde LDAP ahora puede asociarse con identidades como atributos. Estos atributos se pueden asignar a roles, pero también se pueden cargar y usar para otros fines. El reino de seguridad recién creado se puede usar en un dominio de seguridad de la misma manera que se describe en el Migre la autenticación y autorización basada en las propiedades a Elytron sección de esta guía.
7.3.3. Migre la configuración de autenticación de la base de datos a Elytron [Esto es una traducción automática]
Esta sección describe cómo migrar la autenticación de PicketBox basada en la fuente de datos JDBC a Elytron. Gran parte de la información proporcionada en la sección titulada Migre la autenticación y autorización basada en las propiedades a Elytron se aplica aquí, particularmente con respecto a cómo definir dominios de seguridad y fábricas de autenticación, y cómo mapearlas para ser utilizadas para la autenticación. Esta sección no repite esas instrucciones, así que asegúrese de leer esa sección antes de continuar.
Los siguientes ejemplos suponen que los datos de autenticación de usuario se almacenan en una tabla de base de datos creada usando sintaxis similar al ejemplo siguiente.
Ejemplo: sintaxis para crear la tabla de usuario de la base de datos [Esto es una traducción 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 fines de autenticación, el nombre de usuario se compara con los datos almacenados en el username columna, se espera que la contraseña se almacene como un hash MD5 con codificación hexadecimal en el password columna, y la función de usuario para fines de autorización se almacena en role columna.
El dominio de seguridad PicketBox está configurado para usar un origen de datos JBDC para recuperar datos de la tabla de la base de datos, y luego usarlos para verificar el nombre de usuario y la contraseña, y para asignar roles. Supongamos que el dominio de seguridad PicketBox se configura con los siguientes comandos CLI de administración.
Ejemplo: Comandos de configuración de LoginModule de la base de datos de PicketBox [Esto es una traducción 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 } } ] )
Esto resulta en lo siguiente login-module configuración en el legado security subsistema.
Ejemplo: Configuración de PicketBox LoginModule [Esto es una traducción 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 la autenticación de base de datos heredada a Elytron [Esto es una traducción automática]
Para migrar la configuración de ejemplo de autenticación de base de datos anterior a Elytron, debe definir un dominio JDBC para habilitar el acceso a la fuente de datos JDBC por Elytron.
Use el siguiente comando de administración para definir el 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} } ] )
Esto resulta en lo siguiente jdbc-realm configuración en el elytron subsistema del archivo de configuración del 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>
Elytron ahora administra la autenticación de la base de datos utilizando la configuración de reino JDBC. Elytron es más eficiente que PicketBox porque usa una consulta SQL para obtener todos los atributos de usuario y credenciales, y luego extrae datos de los resultados de SQL y crea una asignación de los atributos para usar para la autenticación.
7.3.4. Migre la autenticación de Kerberos a Elytron [Esto es una traducción automática]
Cuando se trabaja con una configuración de Kerberos, el servidor JBoss EAP puede confiar en la información de configuración del entorno, o la configuración de la clave se puede especificar utilizando las propiedades del sistema. Esta sección explica cómo migrar Kerberos HTTP y Kerberos SASL autenticación.
Los ejemplos que siguen suponen que Kerberos se configura utilizando las siguientes propiedades del sistema. Estas propiedades del sistema son aplicables tanto a la configuración heredada como a la configuración migrada de Elytron.
Ejemplo: Comandos de la CLI de administración de propiedades del sistema Kerberos [Esto es una traducción 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)
Ejemplo: Kerberos System Properties Server Configuration [Esto es una traducción 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>
Elija una de las siguientes opciones de migración:
Migre la autenticación de Kerberos a Elytron [Esto es una traducción automática]
En las configuraciones de seguridad heredadas, puede definir un reino de seguridad para habilitar la autenticación SPNEGO para la interfaz de administración HTTP de la siguiente manera.
Ejemplo: habilitar la autenticación SPNEGO para la interfaz de gestión HTTP [Esto es una traducción 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)
Ejemplo: Kerberos Security Realm Configuration [Esto es una traducción 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>
También puede definir un par de dominios de seguridad heredados para permitir que las aplicaciones utilicen la autenticación HTTP de Kerberos.
Ejemplo: definir múltiples dominios de seguridad [Esto es una traducción 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})
Ejemplo: Configuración usando un par de dominios de seguridad [Esto es una traducción 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>
Las aplicaciones heredadas luego se implementan haciendo referencia al dominio de seguridad SPNEGO y aseguradas con el mecanismo SPNEGO.
Migre la autenticación de Kerberos a Elytron [Esto es una traducción automática]
Tanto la interfaz de administración como las aplicaciones se pueden proteger en Elytron utilizando un reino de seguridad y una fábrica de seguridad Kerberos.
Defina un reino de seguridad que se utilizará para cargar información de identidad.
/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 una fábrica de seguridad Kerberos que permita al servidor cargar su propia identidad 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 un dominio de seguridad para reunir la política, así como una fábrica de autenticación HTTP para la política de autenticación.
/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}])Esto da como resultado la siguiente configuración en
elytronsubsistema del archivo de configuración del servidor.Ejemplo: configuración migrada de Elytron [Esto es una traducción 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 la aplicación, defina un dominio de seguridad de la aplicación en
undertowsubsistema para mapear dominios de seguridad a estehttp-authentication-factory. La interfaz de gestión de HTTP se puede actualizar para hacer referencia a lahttp-authentication-factorydefinido en esta configuración. Este proceso está documentado en Migre la autenticación y autorización basada en las propiedades a Elytron sección de esta guía.
Migre la autenticación de Kerberos a Elytron [Esto es una traducción automática]
Es posible definir un reino de seguridad heredado para la autenticación Kerberos / GSSAPI SASL que se utilizará para la autenticación remota, como la interfaz de administración nativa.
Ejemplo: Autenticación de Kerberos para los comandos de la CLI de administración remota [Esto es una traducción 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)
Ejemplo: Kerberos Remoting Security Realm Configuration [Esto es una traducción 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>
Migre la autenticación de Kerberos a Elytron [Esto es una traducción automática]
Los pasos para definir la configuración de Elytron equivalente son muy similares a los descritos en Migrar autenticación Kerberos HTTP.
Defina un reino de seguridad que se utilizará para cargar información de identidad.
/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 la fábrica de seguridad Kerberos para la identidad del 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)
Ejemplo: Dominio de Seguridad Elytron y Comandos de Configuración de Fábrica de Autenticación [Esto es una traducción 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}])
Esto da como resultado la siguiente configuración en elytron subsistema del archivo de configuración del 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>La interfaz de gestión o los conectores remotos ahora se pueden actualizar para hacer referencia a la fábrica de autenticación SASL.
Los dos ejemplos de Elytron definidos aquí también podrían combinarse para usar un dominio de seguridad y un dominio de seguridad compartidos y simplemente usar fábricas de autenticación específicas del protocolo cada una haciendo referencia a su propia fábrica de seguridad de Kerberos.
7.3.5. Migre tiendas compuestas a Elytron [Esto es una traducción automática]
Esta sección describe cómo migrar un PicketBox o reino de seguridad heredado configuración que usa múltiples almacenes de identidad para Elitrono. Al utilizar PicketBox o los reinos de seguridad heredados, es posible definir una configuración donde la autenticación se realiza en un único almacén de identidades mientras que la información utilizada para la autorización se carga desde un almacén diferente. Al migrar a Elytron, esto se puede lograr mediante el uso de un reino de seguridad agregado.
Los siguientes ejemplos realizan autenticación de usuario utilizando el example-users.properties archivo de propiedades, y luego consulta LDAP para cargar la información del grupo y la función.
Las configuraciones que se muestran se basan en los ejemplos de las siguientes secciones, que brindan información de fondo adicional:
- Migre la autenticación y autorización basada en las propiedades a Elytron [Esto es una traducción automática]
- Migre la configuración de autenticación LDAP a Elytron
Ejemplo: Configuración de PicketBox LoginModule [Esto es una traducción automática]
El dominio de seguridad PicketBox para este escenario se configura mediante los siguientes comandos CLI de administración.
Ejemplo: Comandos de configuración de PicketBox [Esto es una traducción 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" }}])
Esto da como resultado la siguiente configuración de servidor.
Ejemplo: configuración del dominio de seguridad PicketBox [Esto es una traducción 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>
Ver Configuración del reino de seguridad agregada de Elytron para saber cómo configurar un reino de seguridad agregado en el elytron subsistema para lograr esto.
Ejemplo: Comandos de configuración de dominios de seguridad heredados [Esto es una traducción automática]
La configuración del reino de seguridad heredada para este escenario se configura mediante los siguientes comandos CLI de administración.
Ejemplo: Comandos de configuración de dominios de seguridad heredados [Esto es una traducción 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
Esto da como resultado la siguiente configuración de servidor.
Ejemplo: Comandos de configuración de dominios de seguridad heredados [Esto es una traducción 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>
Ver Configuración del reino de seguridad agregada de Elytron para saber cómo configurar un reino de seguridad agregado en el elytron subsistema para lograr esto.
Ejemplo: Configuración de LDAP Security Realm [Esto es una traducción automática]
La configuración equivalente de Elytron para este escenario se configura con los siguientes comandos CLI de administración.
Ejemplo: Comandos de configuración de Elytron [Esto es una traducción 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}])
Esto da como resultado la siguiente configuración de servidor.
Ejemplo: configuración Elytron [Esto es una traducción 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>
En el elytron subsistema, un aggregate-realm ha sido definido que especifica qué dominios de seguridad usar para la autenticación y cuáles usar para las decisiones de autorización.
7.3.6. Migre los dominios de seguridad que usan almacenamiento en caché para Elytron [Esto es una traducción automática]
Al usar PicketBox, es posible definir un dominio de seguridad y habilitar el almacenamiento en memoria caché en memoria para su acceso. Esto le permite acceder a los datos de identidad en la memoria y evita el acceso directo adicional al almacén de identidades. Es posible lograr una configuración similar con Elytron. Esta sección describe cómo configurar el almacenamiento en caché del dominio de seguridad cuando se usa Elytron.
Ejemplo: configuración de dominio de seguridad en caché PicketBox [Esto es una traducción automática]
Los siguientes comandos muestran cómo configurar un dominio de seguridad PicketBox que permite el almacenamiento en caché.
Ejemplo: Comandos del dominio de seguridad en caché de PicketBox [Esto es una traducción 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" }}])
Esto da como resultado la siguiente configuración de servidor.
Ejemplo: configuración de dominio de seguridad en caché PicketBox [Esto es una traducción 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>
Este comando y la configuración resultante es similar al ejemplo que se muestra en Migre la configuración de autenticación LDAP a Elytron; Sin embargo, aquí el atributo cache-type se define con un valor de default. los default el tipo de caché es un caché en memoria. Al usar PicketBox, también puede especificar un cache-type de infinispan, Sin embargo, este tipo no es compatible con Elytron.
Ejemplo: configuración de dominio de seguridad en caché Elytron [Esto es una traducción automática]
Siga los pasos a continuación para crear una configuración similar que almacena en caché un dominio de seguridad cuando usa Elytron.
Defina un reino de seguridad y ajuste el dominio de seguridad en un reino de almacenamiento en caché. El dominio de almacenamiento en caché se puede usar en un dominio de seguridad y, posteriormente, en una fábrica de autenticación.
Ejemplo: Comandos de configuración de Elytron Security Realm [Esto es una traducción 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 un dominio de seguridad y una fábrica de autenticación HTTP que utilicen
cached-ldapreino definido en el paso anterior.Ejemplo: Dominio de Seguridad Elytron y Comandos de Configuración de Fábrica de Autenticación [Esto es una traducción 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}])NotaEn este paso, es importante que haga referencia al
caching-realmen lugar del reino original. De lo contrario, el almacenamiento en caché se pasa por alto.
Estos comandos dan como resultado las siguientes adiciones a la configuración del servidor.
Ejemplo: configuración de dominio de seguridad en caché Elytron [Esto es una traducción 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 la seguridad de JACC a Elytron [Esto es una traducción automática]
Por defecto, JBoss EAP usa el legado security subsistema para configurar el proveedor de políticas de Contrato de Autorización de Java para Contenedores (JACC) y la fábrica. La configuración predeterminada se asigna a las implementaciones de PicketBox.
los elytron subsistema proporciona un proveedor de políticas incorporado basado en la especificación JACC. Antes de configurar su servidor para permitir que Elytron administre las configuraciones de JACC y otras políticas, primero debe deshabilitar JACC en el legado security subsistema utilizando el siguiente comando de gestión CLI.
/subsystem=security:write-attribute(name=initialize-jacc, value=false)
De lo contrario, puede producirse el siguiente error en el registro del servidor: MSC000004: Failure during stop of service org.wildfly.security.policy: java.lang.StackOverflowError.
Para obtener información sobre cómo habilitar JACC y definir un proveedor de políticas JACC en el elytron subsistema, ver Habilitando JACC Usando el elytron Subsistema en el Guía de desarrollo para JBoss EAP.
7.4. Migrar clientes de aplicaciones [Esto es una traducción automática]
7.4.1. Migre una configuración de Naming Client a Elytron [Esto es una traducción automática]
Esta sección describe cómo migrar una aplicación cliente que realiza una búsqueda JNDI remota utilizando un org.jboss.naming.remote.client.InitialContext clase, que está respaldado por org.jboss.naming.remote.client.InitialContextFactory clase, a Elytron.
Los siguientes ejemplos suponen que InitialContextFactory la clase se crea especificando las propiedades de las credenciales del usuario y la URL del proveedor de nombres al que se conecta.
Ejemplo: InitialContext Código utilizado en la versión anterior [Esto es una traducción 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");
...
Puede elegir uno de los siguientes enfoques de migración:
- Migre el cliente de nombres usando el enfoque de archivo de configuración [Esto es una traducción automática]
- Migre el cliente de nombres usando el enfoque programático [Esto es una traducción automática]
7.4.1.1. Migre el cliente de nombres usando el enfoque de archivo de configuración [Esto es una traducción automática]
Migre el cliente de nombres usando el enfoque de archivo de configuración [Esto es una traducción automática]
Crear un
wildfly-config.xmlarchivo en la aplicación clienteMETA-INF/directorio. El archivo debe contener las credenciales de usuario que se utilizarán al establecer una conexión con el proveedor de nombres.Ejemplo: configuración equivalente usando el
wildfly-config.xmlArchivo [Esto es una traducción 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>Crear un
InitialContextcomo en el siguiente ejemplo. Tenga en cuenta queInitialContextestá respaldado por elorg.wildfly.naming.client.WildFlyInitialContextFactoryclase.Ejemplo:
InitialContextCódigo utilizado en la versión anterior [Esto es una traducción 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. Migre el cliente de nombres usando el enfoque programático [Esto es una traducción automática]
Con este enfoque, proporciona las credenciales de usuario que se utilizan para establecer una conexión con el proveedor de nombres directamente en el código de la aplicación.
Migre el cliente EJB utilizando el enfoque programático [Esto es una traducción 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. Migre un cliente EJB a Elytron [Esto es una traducción automática]
Este ejemplo de migración supone que la aplicación cliente está configurada para invocar un EJB desplegado en un servidor remoto utilizando un jboss-ejb-client.properties archivo. Este archivo, que se encuentra en la aplicación cliente META-INF/ directorio, contiene la siguiente información necesaria para conectarse al servidor remoto.
Ejemplo: jboss-ejb-client.properties Archivo [Esto es una traducción 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
El cliente busca el EJB y llama a uno de sus métodos usando un código similar al del siguiente ejemplo.
Ejemplo: Código de cliente que llama a un EJB remoto [Esto es una traducción 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);
Puede elegir uno de los siguientes enfoques de migración:
- Migre el cliente EJB utilizando el enfoque del archivo de configuración [Esto es una traducción automática]
- Migre el cliente EJB utilizando el enfoque programático [Esto es una traducción automática]
7.4.2.1. Migre el cliente EJB utilizando el enfoque del archivo de configuración [Esto es una traducción automática]
Migre el cliente de nombres usando el enfoque de archivo de configuración [Esto es una traducción automática]
Configura un
wildfly-config.xmlarchivo en la aplicación clienteMETA-INF/directorio. El archivo debe contener las credenciales de usuario que se utilizarán al establecer una conexión con el proveedor de nombres.Ejemplo: configuración equivalente usando el
wildfly-config.xmlArchivo [Esto es una traducción 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>Crear un
InitialContextcomo en el siguiente ejemplo. Tenga en cuenta queInitialContextestá respaldado por elorg.wildfly.naming.client.WildFlyInitialContextFactoryclase.Ejemplo:
InitialContextCódigo utilizado en la versión anterior [Esto es una traducción 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);-----
Ejemplo:
jboss-ejb-client.propertiesArchivo de propiedades [Esto es una traducción automática]
7.4.2.2. Migre el cliente EJB utilizando el enfoque programático [Esto es una traducción automática]
Con este enfoque, proporciona la información necesaria para conectarse al servidor remoto directamente en el código de la aplicación.
Migre el cliente EJB utilizando el enfoque programático [Esto es una traducción 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);
Ejemplo: jboss-ejb-client.properties Archivo de propiedades [Esto es una traducción automática]
7.5. Migrar configuraciones de SSL [Esto es una traducción automática]
7.5.1. Migre una configuración simple de SSL a Elytron [Esto es una traducción automática]
Si aseguró conexiones HTTP al servidor JBoss EAP usando un reino de seguridad, puede migrar esa configuración a Elytron utilizando la información proporcionada en esta sección.
Los siguientes ejemplos asumen que tiene lo siguiente keystore configurado en el security-realm.
Ejemplo: Configuración de SSL con un almacén de claves de Realismo de seguridad [Esto es una traducción 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 los pasos a continuación para lograr la misma configuración usando Elytron.
Crear un
key-storeen elelytronsubsistema que especifica la ubicación del almacén de claves y la contraseña mediante la cual se encripta. Este comando supone que el almacén de claves se generó utilizando el comando keytool y su tipo esJKS./subsystem=elytron/key-store=LocalhostKeyStore:add(path=server.keystore,relative-to=jboss.server.config.dir,credential-reference={clear-text="keystore_password"},type=JKS)Crear un
key-manageren elelytronsubsistema que especifica elkey-storedefinido en el paso anterior, el alias y la contraseña de la clave./subsystem=elytron/key-manager=LocalhostKeyManager:add(key-store=LocalhostKeyStore,alias-filter=server,credential-reference={clear-text="key_password"})Crear un
server-ssl-contexten elelytronsubsistema que hace referencia a lakey-managereso fue definido en el paso anterior./subsystem=elytron/server-ssl-context=LocalhostSslContext:add(key-manager=LocalhostKeyManager)
Cambiar el
https-listenerdel legadosecurity-realmal recién creado Elytronssl-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
Recargar el servidor.
recargar
Esto resulta en lo siguiente elytron configuración del subsistema en el archivo de configuración del 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>
Esto resulta en lo siguiente undertow configuración del subsistema en el archivo de configuración del servidor.
<https-listener name="https" socket-binding="https" ssl-context="LocalhostSslContext" enable-http2="true"/>
Para más información, ver Subsistema Elytron y Cómo proteger las interfaces de administración en Cómo configurar la seguridad del servidor para JBoss EAP.
7.5.2. Migre la autenticación SSL de Client-Cert a Elytron [Esto es una traducción automática]
Si configuró la autenticación SSL de Client-Cert utilizando un almacén de confianza del reino de seguridad, puede migrar esa configuración a Elytron utilizando la información proporcionada en esta sección.
Los pasos siguientes suponen que tiene lo siguiente truststore configurado en el security-realm.
Ejemplo: Configuración de SSL utilizando Security Realm Truststore [Esto es una traducción 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>
Los pasos a continuación solo brindan configuración para evitar que los usuarios sin un certificado válido y una clave privada accedan al servidor. No configuran la identidad del usuario para autenticarse en el servidor. Se supone que ya ha configurado la autenticación HTTP CLIENT-CERT y la autenticación SASL externa para la autenticación de identidad del usuario.
Siga estos pasos para configurar el servidor para evitar que los usuarios sin un certificado válido y una clave privada accedan al servidor utilizando Elytron.
Crear un
key-storeen elelytronsubsistema que especifica la ubicación del almacén de claves y la contraseña mediante la cual se encripta. Este comando supone que el almacén de claves se generó utilizando el comando keytool y su tipo esJKS./subsystem=elytron/key-store=LocalhostKeyStore:add(path=server.keystore,relative-to=jboss.server.config.dir,credential-reference={clear-text="keystore_password"},type=JKS)Crear un
key-storeen elelytronsubsistema que especifica la ubicación del almacén de confianza y la contraseña mediante la cual se encripta. Este comando supone que el almacén de claves se generó utilizando el comando keytool y su tipo esJKS./subsystem=elytron/key-store=TrustStore:add(path=server.truststore,relative-to=jboss.server.config.dir,credential-reference={clear-text="truststore_password"},type=JKS)Crear un
key-manageren elelytronsubsistema que especifica lo previamente definidoLocalhostKeyStorekeystore, el alias y la contraseña de la clave./subsystem=elytron/key-manager=LocalhostKeyManager:add(key-store=LocalhostKeyStore,alias-filter=server,credential-reference={clear-text="key_password"})Crear un
trust-manageren elelytronsubsistema que especifica elkey-storedel almacén de confianza creado previamente./subsystem=elytron/trust-manager=TrustManager:add(key-store=TrustStore)
Crear un
server-ssl-contexten elelytronsubsistema que hace referencia a los definidos previamentekey-manager, establece eltrust-manageratributo, y habilita la autenticación del cliente./subsystem=elytron/server-ssl-context=LocalhostSslContext:add(key-manager=LocalhostKeyManager,trust-manager=TrustManager,need-client-auth=true)
Cambiar el
https-listenerdel legadosecurity-realmal recién creado Elytronssl-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
Recargar el servidor.
recargar
Esto resulta en lo siguiente elytron configuración del subsistema en el archivo de configuración del 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>
Esto resulta en lo siguiente undertow configuración del subsistema en el archivo de configuración del servidor.
<https-listener name="https" socket-binding="https" ssl-context="LocalhostSslContext" enable-http2="true"/>
Para más información, ver Subsistema Elytron y Usando un cliente-ssl-context en Cómo configurar la seguridad del servidor para 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.