Hdiv
UDA ofrece una librería de seguridad que integra x38 y Hdiv. En esta wikise detallan los pasos necesarios para su instalación y uso. Se podrá encontrar más información en la documentación oficial de Hdiv disponible en (apartado library).
La librería de Hdiv realiza tres tipos de validaciones:- Control de acceso
- Validaciones de editables
- Validaciones de integridad
La configuración de seguridad se podrá modificar desde la consola modificada teniendo esta prioridad sobre la definida en la propia aplicación.
Se trata de determinar qué URLs quedan accesibles para el usuario. Por defecto ninguna URL será permitida a no ser que se habilite desde la parte servidora de la aplicación. Más adelante se muestra cómo habilitar los accesos. Se trata de validar los datos enviados en campos de texto. Existe una validación por defecto que podrá ser completada por el desarrollador. Se trata de validar los datos enviados en campos de texto. Existe una validación por defecto que podrá ser completada por el desarrollador.-La librería de Hdiv forma parte de la x38 >=5.x. Se cargarán las dependencias necesarias al hacer uso de la x38.
El los proyectos web (WAR):
-Añadir el listener y el filtro de Hdiv en el web.xml El filtro debe ser el primero en registrarse. Para ello se situará por delante del filtro de UDA.
<!-- Hdiv Init Listener -->
<listener>
<listener-class>org.hdiv.listener.InitListener</listener-class>
</listener>
<!-- Hdiv Validator Filter -->
<filter>
<filter-name>ValidatorFilter</filter-name>
<filter-class>org.hdiv.filter.ValidatorFilter</filter-class>
</filter>
<filter-mapping>
<filter-name>ValidatorFilter</filter-name>
<url-pattern>/*</url-pattern>
</filter-mapping>-Añadir una clase de configuración que extienda de la clase UDA4HdivConfigurerAdapter. Un ejemplo básico sería el siguiente:
@Configuration
public class UDA4HdivConfig extends UDA4HdivConfigurerAdapter {
@Override
protected String getHomePage() {
return "/";
}
@Override
protected String getLoginPage() {
return "/loginPage";
}
protected String getDashboardUser() {
return "dashboard-admin";
}
protected String getDashboardPass() {
return "password";
}
@Override
public void addCustomExclusions(final ExclusionRegistry registry) {
}
@Override
public void addCustomRules(final RuleRegistry registry) {
}
@Override
public void customConfigureEditableValidation(final ValidationConfigurer validationConfigurer) {
}
}Más adelante en el punto 6 se explicará con más detalle la configuración de la librería.
En el método "getHomePage" se establecerá la URL por la que se accede a la aplicación.
En "getLoginPage" se especifica la URL de la página de login.
En "getDashboardUser" y "getDashboardPass" se especifica el usuario y contraseña de acceso al dashboard de Hdiv. En este dashboard se muestra la información de seguridad relativa a la aplicación.
Para acceder a esta vista de información: {appContextPath}/hdiv-services/dashboard
Para añadir exclusiones de validación se hará uso del método "addCustomExclusions".
Si se necesitan crear nuevas reglas de validación, se hará uso del método "addCustomRules". Aquí se especificará un nombre de validación y los patrones aceptados y/o rechazados.
Un ejemplo de validación en la que se aceptan únicamente valores numéricos sería:
registry.addRule("numerico").acceptedPattern("^[0-9]+$");Para asignar las reglas existentes a URLs o parámetros se hará uso de customConfigureEditableValidation.
Un ejemplo de asignación de la regla de valores booleanos sería el siguiente:
validationConfigurer
.addValidation("/.*")
.forParameters("parameter.name")
.rules("boolean")
.target(ValidationTargetType.CLIENT_PARAMETERS);El atributo CLIENT_PARAMETERS se refiere a parámetros creados directamente en el cliente sin ser enviados desde el servidor (javascript).
-Cambiar el archivo mvc-config.xml para que el base scan encuentre el archivo de configuración.
Para permitir el acceso a URLs será necesario que estas estén creadas mediante el tag de spring spring:url o permitidas desde el controlador. El método aconsejado es mediante el tag de spring, siendo la habilitación desde el controlador el método utilizado para URLs creadas en cliente (javascript).Las peticiones realizadas a URLs no generadas de las siguientes maneras serán bloqueadas.
Esta forma de generar las URLs hace que el servidor sea el encargado de crearlas y de registrarlas. En las URLs se añadirá un parámetro de seguridad encargado de identificar el enlace.Incorrecta:
<a class="nav-link" href="/appContext/url">Adecuada:
<spring:url value="/url" var="url"/>
<a class="nav-link" href=${url}>Las URLs que coinciden con el siguiente listado están excluidas de validación en la configuración de la librería, y por lo tanto no requieren del tag de spring.
/scripts/.*, /styles/.*, /fonts/.*, /error, /*.gif
Se ha implementado una herramienta que permite habilitar URLs desde el controlador: @UDALink.
Esta herramienta se utiliza en forma de anotación. Consta de dos partes, identificación del link y accesos permitidos.
Al acceder al método del controlador con esta anotación, se habilitará el acceso a los links definidos en linkTo.
Por ejemplo, un método anotado de la siguiente manera permite el acceso a las peticiones de los métodos marcados como UDALink “edit” y “remove”.
@UDALink(name = "get", linkTo = {@UDALinkAllower(name = "edit" ), @UDALinkAllower(name = "remove" )})Una condición para el uso de esta anotación, es que en el caso de existir path variables en el mapping de los métodos a habilitar, el nombre de las path variables debe coincidir con el nombre de atributo del objeto enviado en la response. Solo se permitirá el acceso a los métodos que coincida esta regla, es decir, siguiendo con el ejemplo anterior no se podrá editar o eliminar ningún objeto que no haya sido devuelto en el método con nombre “get”.
@UDALink(name = "remove")
@RequestMapping(value = "/{id}", method = RequestMethod.DELETE)El atributo id debe existir en el objeto devuelto por el método “get”.
Si el método al que se quiere dar acceso se encuentra en otro controlador, se hara uso de el atributo “linkClass” de la anotación UDALinkAllower dentro de UDALink.
@UDALink(name = "get",
linkTo = {@UDALinkAllower(name = "edit",
linkClass = CustomOtherController.class) })Hay casos en los que no todas las entidades devueltas por el método del controlador deben tener acceso a los links anotados. Para discriminar parte de estos recursos se hará uso del atributo “allower”.
@UDALink(name = "get",
linkTo = {@UDALinkAllower(name = "edit",
allower = CustomController.class) })Este atributo define la clase en la que se encuentra el predicado con la lógica de clasificación. El predicado debe ser un método público y estático que devuelva un pbjeto de tipo LinkPredicate<Tipo_De_Entidad> con la implementación del método “test”. El método test recibe el objeto ”LinkInfo“ como parámetro.
public class LinkInfo<T> {
private final String linkId;
private final T entity;
private final HttpServletRequest request;
}A continuación se muestra un ejemplo de implementación:
public static LinkPredicate<Entidad> getEntidadLinkPredicate() {
return new LinkPredicate<Entidad>() {
@Override
public boolean test(LinkInfo<Entidad> linkInfo) {
return !linkInfo.getEntity().isClosed();
}
};
}- Formularios con tags de Spring
- Peticiones tipo REST
<spring:url value="/url" var="url"/>
<form:form id="form_id" action="${url}">Es importante incluir el taglib de spring-form.
<%@ taglib prefix="form" uri="/WEB-INF/tld/spring-form.tld"%>Los datos estáticos de los formularios como combos, radios, checkbox, etc., se deberán cargar en tiempo de renderizado. Lo más común es emplear el modelo para añadir estos datos como atributos:
Controller
Map<String,String> att = new LinkedHashMap<String,String>();
att.put("value1", "value1Name");
att.put("value2", "value2Name");
model.addAttribute("attname", att);JSP
<form:select path="name" id="estado_filter_table" class="rup-combo" items="${attname}"/>Controller
model.addAttribute("attname2", att2ValueList);JSP
<form:select path="name2" class="rup-combo">
<form:option value=""> </form:option>
<form:options items="${attname2}" itemLabel="desc" itemValue="key"/>
</form:select>Es importante comprender que los datos permitidos en un formulario están asociados al “action” del mismo. Si se modifica la URL del formulario, esta no corresponderá con los parámetros permitidos y la petición será bloqueada.
La librería considera que los campos definidos como hidden no son editables, con lo que si estos sufren modificaciones (su valor no corresponde al del momento de renderizado del formulario) la petición será bloqueada.
Si hay campos ocultos en los que las modificaciones están permitidas, estos deberán ser inputs ocultos.
<form:input path="parameter" style="display: none"/>Las entidades deberán ser de tipo SecureIdContainer o SecureIdentifiable. Siempre serán representadas por un identificador único. Este identificador viajará encriptado. Se proporcionará el valor original en el campo con nombre “nid”.
SecureIdentifiable: En caso de que la entidad posea un atributo llamado “id” o requiera de clave compuesta. Se crearán los métodos getId y setId.
SecureIdContainer: Si la entidad tiene un atributo identificativo (código cuyo nombre de atributo es distinto de “id”) o si el objeto no es una entidad en sí misma, pero contiene una, esta implementará SecureIdentifiable. Para identificar el atributo identificador, se anotará este con @TrustAssertion(idFor = EntidadActual.class).
Un ejemplo de SecureIdContainer.
Clase entidad:
public class Entidad implements java.io.Serializable, SecureIdContainer {
@TrustAssertion(idFor = Entidad.class)
private Integer codEntidad;
}Clase que no es una entidad en sí, pero hace uso de una:
public class EntidadDAO implements java.io.Serializable, SecureIdContainer {
@TrustAssertion(idFor = Entidad.class)
private Integer codEntidad;
}Al enviar las entidades a cliente, se harán en forma de Resource.
new Resource<Entidad>(entidad);
public @ResponseBody Resource<Entidad> get(@PathVariable String id)
public @ResponseBody TableResourceResponseDto<Entidad> filter()La librería x38 hace uso de la clase TableResourceResponseDto para enviar las entidades como Resources. Esta clase es compatible con el componente tabla.
Las URLs de peticiones que hagan uso de path variables deberán cumplir con el siguiente patrón:
La última variable corresponderá al identificador de la entidad. Las variables en la URL que correspondan a la entidad y no estén modificados deberán tener el mismo nombre que el atributo de la propiedad. Se recomienda que las variables estáticas de la URL sean una enumeración para controlar el valor de los mismos. Por ejemplo una variable con nombre “estado” cuyos valores se esperan entre “activo” e “inactivo”, se recomienda que sea un enumerado al menos en el path.
En caso de que el valor de una variable no quiera ser validado por integridad, se marcará en el controlador de la siguiente manera:
@PathVariable @TrustAssertion(idFor = NoEntity.class) Integer valueLa librería ofrece la posibilidad de añadir configuración a la aportada por defecto. Las validaciones se configurarán desde la clase de configuración que extiende de UDA4HdivConfigurerAdapter.
A continuación se exponen las opciones de configuración.
Las URLs añadidas como urlexclusions no serán validadas. Se establecerá la URL (puede contener expresiones regulares) y se podrá especificar el verbo del método http al que aplica.@Override
public void addCustomExclusions(final ExclusionRegistry registry) {
registry.addUrlExclusions("/url.html").method("GET");
}Como parte especial de URLs excluídas de validación se encuentran las URLs de entrada a la aplicación y login.
Estas se configuran de la siguiente manera:
@Override
protected String getHomePage() {
return "/";
}
@Override
protected String getLoginPage() {
return "/loginPage";
}Se permite especificar la validación de valor de parámetro por nombre de parámetro y URL.
Esta regla se compone de la URL en la que se aplica la validación, el patrón aceptado, el rechazado y el nombre que se da a la regla. En la regla se podrá especificar el patrón aceptado y/o el rechazado.
Patrón de valores aceptados en el parámetro. Se compone de expresiones regulares.
Patrón de valores rechazados en el parámetro. Se compone de expresiones regulares.
A continuación se muestra un ejemplo de regla de validación de editables.
@Override
public void addCustomRules(final RuleRegistry registry)
registry.addRule("customValidation")
.acceptedPattern("^[a-zA-Z0-9@.\\-_]*$");
}
@Override
public void customConfigureEditableValidation(final ValidationConfigurer validationConfigurer){
validationConfigurer.addValidation(".*").rules("customValidation");
}Al igual que se ofrece una opción para evitar la validación por URLs, se permite excluir las validaciones de parámetros en concreto. Estas exclusiones pueden especificarse por URL siguiendo una expresión regular.
A continuación se muestra un ejemplo de configuración para la exclusión del parámetro “paramName” para todas las URLs que empiezan por “section/”.
@Override
public void addExclusions(ExclusionRegistry registry) {
registry.addParamExclusions("paramName").forUrls("/section/.*");;
}En ocasiones hay parámetros que son generados en el cliente y por lo tanto desconocidos para la parte servidora.
Una petición con este tipo de parámetros sería bloqueada por la librería por tratarse de datos no autorizados por el servidor.
Si es necesario que estos parámetros sigan siendo creados en la parte cliente (js, html) se deberá añadir una validación indicando que son parámetros creados en cliente esperados por el servidor.
Esta configuración se hará de la siguiente manera:
Parámetro generado en cliente con validación por defecto:
@Override
public void customConfigureEditableValidation(final ValidationConfigurer validationConfigurer){
validationConfigurer.addValidation("/.*")
.forParameters("paramName")
.target(ValidationTargetType.CLIENT_PARAMETERS;
}Parámetro generado en cliente con validación personalizada:
@Override
public void customConfigureEditableValidation(final ValidationConfigurer validationConfigurer){
validationConfigurer.addValidation("/.*")
.forParameters("paramName")
.rules("customValidation")
.target(ValidationTargetType.CLIENT_PARAMETERS).disableDefaults();
}Cuando se despliega una aplicación que hace uso de la librería Hdiv, también se despliega un dashboard dónde poder ver cómo de securizada está la aplicación, sus entidades etc.
Para poder acceder hay que añadir /hdiv-services/dashboard a la URL tras el nombre de la aplicación. Antes de poder acceder, nos aparecerá un formulario para ingresar el nombre de usuario y su contraseña, ambos están definidos en la clase UDA4HdivConfig. El formulario es el siguiente:
A continuación, volverá a aparecer el mismo formulario, pero esta vez habrá que ingresar el nombre de usuario y contraseña usados para acceder al panel de gestión de WebLogic. A continuación, una captura que muestra el formulario:
Una vez ingresados ambos usuarios, se mostrará el dashboard:
Por el momento al menos, no se pueden usar los combos mixtos en las aplicaciones que tengan Hdiv activado. El motivo es simple, Hdiv funciona con identificadores cifrados y al utilizar combos mixtos, van a existir identificadores sin cifrar, dando lugar a un bloqueo por parte de Hdiv por ser un problema de seguridad.
La documentación y la información contenida en estas páginas se ofrecen bajo licencia
El plugin 