Conceptos Básicos de Spring Security

Spring Security es el framework de autenticación y control de acceso de Spring.

Autenticación en el caso más usual es determinar que el usuario que accede al sistema es quien dice ser. Spring soporta muchísimas formas de hacer la autenticación y van desde la más básica que es un simple formulario HTML hasta otras como OpenID, CAS, LDAP, Kerberos, JAAS, etc.

Control de acceso es determinar si un usuario puede realizar una determinada acción dentro del sistema. En muchos casos no tiene sentido realizar el control de acceso usuario por usuario sino agrupando a todos los usuarios que pueden realizar las mismas acciones dentro del sistema. Es decir, no se define “María y Roberto pueden imprimir facturas” sino, “todos los usuarios que sean vendedores pueden imprimir facturas”. Si hoy Juan es encargado de limpieza entonces no puede imprimir facturas, pero el día de mañana, Juan podría ser ascendido a área de ventas y ser vendedor, por lo que entonces sí podrá imprimir facturas. La forma de agrupar a “todos los usuarios que sean vendedores” es mediante roles. Entonces en un momento sólo María y Roberto tienen el rol “ROLE_VENDEDOR” y posteriormente se agregará Juan a ese grupo asignándole dicho rol.

Entender que un rol no es otra cosa que un conjunto de usuarios es muy importante.

Spring permite controlar el acceso en tres niveles

  1. URLs de una aplicación WEB,
  2. métodos de un Bean de Spring.
  3. objetos del dominio.

La única diferencia entre las tres es qué operación es la que se está controlando.

En el primer caso, se busca controlar el acceso a un grupo de recursos que son identificables mediante una URL. Por ejemplo si nuestra aplicación web tiene una página que sólo debe ser accedida por un gerente y no por todos los demás empleados, una estrategia sería que la URL de esa página fuera por ejemplo “/gerencia/index.jsp” y se configurara Spring Security para que sólo usuarios con rol “ROLE_GERENTE” pudieran acceder a URLs que empezaran con “/gerencia”.

El segundo caso busca controlar la ejecución de un método en particular. Se usa en situaciones donde no se trata de una aplicación web, cuando no es posible tener URLs distintas para diferenciar el acceso o cuando independientemente de qué URL fue solicitada desde el cliente queremos asegurarnos de que no se ejecute un método si no se trata del usuario que tiene el permiso. Los métodos que pueden ser controlados son métodos de objetos que sean Beans de Spring, no cualquier objeto.

El tercer caso busca controlar el acceso a objetos de dominio. El ejemplo más claro es para extraer dinero de una cuenta bancaria. Se debe verificar que el usuario sea el dueño de esa cuenta en particular y la relación de quién es dueño de qué cuenta puede ir variando en el tiempo por ejemplo a medida que se agregan o quitan titulares. En este caso los objetos que se desean controlar no tienen que ser Beans de Spring, puede ser cualquier objeto.

Para resolver el tercer caso se usa un módulo de Spring Security que se llama Domain Object Security o Spring ACLs.

Con Spring ACLs se define para cada objeto (instancias individuales) del dominio que se necesite controlar una lista de usuarios y roles que pueden accederlo. Como un rol no es otra cosa que un conjunto de usuarios, en verdad lo que se indica para cada objeto del dominio es directa o indirectamente una lista de usuarios.

Gráficamente lo que se tiene es un objeto del dominio, como por ejemplo una cuenta bancaria:

{Cuenta 123541500542}

y asociada al objeto una lista de usuarios que están autorizados a sacar dinero de esa cuenta

{Cuenta 123541500542} -> {“Juan”, “Pedro”, “Susana”}

Cuando la aplicación está por realizar la operación de débito sobre esa cuenta debemos indicarle a SpringSecurity que verifique que el usuario que está realizando la operación esté en la lista de usuarios de la cuenta sobre la que se está operando.

¿Cómo sería esto con la intervención de roles? Supongamos que existiera en el sistema un rol “ROLE_GERENTE_DE_CUENTAS” y que de acuerdo a las reglas del banco un usuario con ese rol está autorizado a realizar débitos sobre cualquier cuenta. La ACL quedaría así

{Cuenta 123541500542} -> {“Juan”, “Pedro”, “Susana”, “ROLE_GERENTE_DE_CUENTAS”}

Spring Security verificará en el momento que le sea indicado si el usuario que está intentando realizar la operación es Juan, Pedro, Susana, o algún usuario que tenga asignado el rol “ROLE_GERENTE_DE_CUENTAS”. Nuevamente,  como un rol no es otra cosa que un conjunto de usuarios en la lista la presencia de un rol es sólo una forma indirecta de referirnos a usuarios.

Si en cambio se define a los roles como un conjunto de “operaciones” o un conjunto de “permisos” es más difícil entender qué hace el rol en la lista de usuarios autorizados y por lo tanto entender cómo adaptar Spring ACLs a nuestra aplicación.

Spring ACLs es muy flexible y potente ya que permite manejar varios permisos como lectura, escritura, borrado y además permite otorgar y revocar permisos. Por ejemplo si le otorgamos permiso al rol “ROLE_GERENTE” y se lo revocamos al usuario “Juan” que  tiene ese rol, lo que logramos es definir que todos los gerentes menos “Juan” tienen otorgado el permiso. También podría ser a la inversa y definiríamos que ningún gerente tenga permiso a excepción de “Juan”. Si vemos los roles  como conjuntos de usuarios, es simplemente quitar elementos del conjunto.

Para aprender más en detalle cómo usar Spring ACLs, se pueden consultar estos dos artículos

La Gran Estafa

Les presento en este capítulo un cuadro compilado por el First National City Bank de New York (publicado en su carta económica mensual de julio de 1964) mostrando la reducción del poder de compra de las monedas de 42 países en la década de 1953 a 1963. La reducción se calcula inversamente a partir de los incrementos en el costo de vida o el índice de precios al consumidor calculado por cada gobierno.

Es importante mantener esta demoledora imagen mundial en nuestras mentes. Nos recuerda que la inflación no es más que una gran estafa y que esta estafa es perpetrada en diversas graduaciones, a veces por ignorancia y a veces cínicamente por casi todos los gobiernos del mundo. Esta estafa erosiona el poder de compra de los ingresos de todos y el poder de compra de los ahorros de todos. Es un impuesto encubierto y el más vicioso de todos los impuestos. Grava con el mismo porcentaje los ingresos y los ahorros de los pobres y de los ricos. Cae con fuerza tanto en los prósperos como en los jubilados o los que no se pueden proteger especulando o reclamando y obteniendo mayores ingresos para compensar la depreciación de la unidad monetaria.

¿Por qué sigue la estafa? Sigue porque los gobiernos quieren gastar, en parte en armamento y en la mayoría de los casos principalmente en subsidios y dádivas para varios grupos de presión, pero carecen de la valentía de cobrar impuestos por la misma cantidad que gastan. Sigue, en otras palabras, porque los gobiernos quieren comprar los votos de algunos de nosotros ocultándole al resto de nosotros que esos votos se están comprando con nuestro propio dinero. Sigue porque los políticos (en parte a través de la influencia de segunda o tercera mano de las teorías del difunto Lord Keynes) piensan que esta es la forma y la única forma de mantener el “pleno empleo”, el fetiche actual del auto proclamado progresismo. Sigue porque se abandonó el patrón oro, porque las monedas del mundo son esencialmente monedas de papel a la deriva y sin ancla, sopladas por cada viento político y a merced de cada capricho burocrático. Y estos mismos gobiernos que están inflando juran solemnemente estar “combatiendo” la inflación. A través de políticas de dinero barato, la maquinita de imprimir o ambas incrementan la oferta de dinero y de crédito y fingen deplorar el resultado inevitable.

 Fragmento del libro “Lo Que Debe Saber de la Inflación” de Henry Hazlitt. Escrito en 1964. Nunca más actual.