====== Autorización de servicios REST ======

La **autorización en servicios REST** consiste en permitir la ejecución de determinados métodos de nuestro servicio a un conjunto de usuarios con un determinado **ROL** dentro de nuestra aplicación. Por lo tanto con este mecanismo, para un usuario autenticado, podemos** controlar la funcionalidad a la que tiene acceso**, de esta manera permitimos que usuarios con perfiles diferentes puedan utilizar nuestra API asegurando que sólo accederán a los métodos de la API que les hayamos permitido.

Si lo que quieres es controlar si un usuario accede o no a la parte privada de tu aplicación revisa primero la **[[fdw2.0:fundeweb2.0:gt:rest:autenticacion_de_servicios_web_rest_token|wiki de autenticación]]**

**Es importante distinguir entre autenticación y autorización**. Mediante la autenticación validamos que un usuario es quien dice ser permitiéndole acceder a nuestra aplicación, si procede. Mediante autorización decidimos a qué partes de nuestra aplicación puede acceder un usuario autenticado. Ambos mecanismos están diseñados para trabajar conjuntamente gestionando tanto el acceso a nuestra API como a los diferentes niveles recursos en base a nuestro rol asignado. 

===== Estructuras de clases =====
Para poder dar soporte de autorización es imprescindible dar soporte de autenticación, por lo que la estructura de clases resultantes es un añadido a la indicada en la **[[fdw2.0:fundeweb2.0:gt:rest:autenticacion_de_servicios_web_rest_token|wiki de autenticación]]**, con alguna variación para que ambos mecanismos convivan.

{{ :fdw2.0:fundeweb2.0:gt:rest:diagramaautorizacion.png?800 |}}

Las clases recuadradas en azul son las mismas que intervenían en la autenticación por lo que no tendrán funcionalidad adicional relacionada con la autorización.

Las clases recuadradas en rojo son las que implementarán la nueva funcionalidad de autorización, las cuales comentamos a continuación.

En este esquema podemos ver que la clase RestRequestFilter inculida en la **[[fdw2.0:fundeweb2.0:gt:rest:autenticacion_de_servicios_web_rest_token|wiki de autenticación]]** desaparece ya que su funcionalidad es asumida por RestAuthorizationFilter, por lo que si teníamos creada la clase la podremos borrar ya que su código se encuentra encapsulado en RestRequestUtil.


===== Configuración de la autorización en nuestra aplicación =====

Para configurar la autorización en nuestra API REST, deberemos quitar el mecanismo que tuviéramos antes y sustituirlo por el siguiente {{ :fdw2.0:fundeweb2.0:gt:rest:autorizacion.zip |código}}

Deberemos descomprimir las clases en nuestro proyecto y ajustar los nombres de los paquetes y ubicación de las clases a la ruta que tengamos.

También deberemos configurar el fichero web.xml para dar de alta los listeners que ejecutarán nuestro proceso de autenticación y autorización

Fichero **web.xml**
<code xml>
	<context-param> 
		<param-name>com.sun.jersey.spi.container.ContainerResponseFilters</param-name> 
		<param-value>es.um.atica.[MIPROYECTO].security.authorization.filter.RestResponseFilter</param-value> 
	</context-param>

	<context-param>
		<param-name>com.sun.jersey.spi.container.ResourceFilters</param-name>
		<param-value>es.um.atica.[MIPROYECTO].security.authorization.filter.RestAuthorizationFilter</param-value>
	</context-param>
</code>

Por último deberemos modificar la clase **RestRequestUtil** para incorporar la carga de roles según como los obtengamos en nuestra aplicación.
<code java>
    ...
    ...
 //FIXME: Carga roles usuario del usuario ya logueado
       List<String>rolesUsuario = new ArrayList<String>();                
       if ( rolesPermitidos != null && !rolesPermitidos.isEmpty() ) {
          boolean rolEncontrado = false;
          for(String rolUsuairo: rolesUsuario){
             if(rolesPermitidos.contains( rolUsuairo )){
                rolEncontrado=true;
                break;
              }
           }
           if(!rolEncontrado){
               denegarConexion();
               return null;
              }
        }
        ...
        ...
</code>

Donde se indica con **FIXME** deberemos realizar la carga de los roles para el usuario que le llega al método. En este punto del filtro el usuario ya está autenticado por lo que se considera seguro cargar los roles. En caso de no cargar un rol que soporte el método se devolverá un no autorizado.

Una vez configurado el mecanismo de autorización deberemos anotar los métodos de mi API REST que requieran autorización con la anotación **@RolesAllowed** y la lista de roles permitodos:
<code java>
    @RolesAllowed("ADMIN","GESTOR")
    @GET    
    @Path("/prueba")
    public String prueba(){
      ...
      ...
    }
</code>



Ojo, si al ejecutar las peticiones rest que deberían validar autenticación el servidor devuelve 401 y en el mensaje encuentras 
<code>
WWW-Authenticate: Basic realm="weblogic"
</code>
Es necesario añadir la siguiente linea en el archivo config.xml del dominio (fundeweb\2.x\servidores\wl121y_dev\dominios\fundeweb\config\)
<code>
	<enforce-valid-basic-auth-credentials>false</enforce-valid-basic-auth-credentials>
</code>
fuente:
<code>
https://stackoverflow.com/questions/40397917/what-are-the-consequences-when-setting-enforce-valid-basic-auth-credentials-to-f
</code>