Modelo de seguridad en OBIEE 11g

Una de las cosas que más me interesan cuando le echo un vistazo a cualquier sistema de BI es su modelo de seguridad, es decir, la forma en la que se autentica a los usuarios y el modo en el que controlamos lo que pueden o no pueden ver o hacer.

Desde el punto de vista comercial, quizás el modelo de seguridad queda en un segundo plano frente a otros aspectos más funcionales que “fardan” más, como las funciones analíticas o de visualización de datos. Todas esas cosas son muy bonitas para el personal que va a explotar el sistema (y que generalmente son los que pagan), pero para el personal de TI lo importante es como vamos a controlar y administrar las a veces ridículas peticiones de privacidad de los usuarios.

Cuando salió la nueva suite de Oracle OBIEE 11g, uno de los cambios importantes implicaba precisamente al modelo de seguridad de la 10g que tan bien hemos llegado a dominar. En esta nueva versión, al introducir en la ecuación al servidor de aplicaciones WebLogic, los fundamentos de seguridad de OBIEE pasan a estar (en parte) supeditados por los de Oracle Fusion MiddleWare 11g (OFMW), así que han cambiado bastantes cosas. Este cambio es en realidad bastante lógico si observamos que la política reciente de Oracle es hacer pasar a todas sus aplicaciones por OFMW, así que de esta forma la seguridad queda centralizada. Vale, aceptamos barco…

He creado este diagrama que muestra los pasos que suceden en el acceso al sistema con la configuración por defecto

Bien, entonces, ¿Cómo queda la cosa? La verdad es que leyendo la documentación parece más complicado de lo que es en realidad. Echemos un vistazo :)

La seguridad en OBIEE11g desde un punto de acceso a la información por parte de los usuarios sucede en dos fases:

1. Autentificación –> ¿Quién eres? ¿Te dejo entrar?
2. Autorización –> Ok, ya te he dejado entrar. ¿Qué te dejo hacer? ¿Qué datos estás autorizado a ver?

El paso 1 es obvio, y el paso 2 también. En el paso 2 refinamos los permisos de acceso a los diferentes componentes y datos del sistema. Es casi seguro que al director de RRHH no le haga mucha gracia que sus datos sobre las nóminas del personal estén disponibles para consulta de todo el mundo. Ya me entendéis…

Componentes principales del modelo de seguridad OBIEE 11g

Cuando instalamos una nueva instancia de OBIEE 11g muy amablemente se nos aplicará una configuración de seguridad por defecto (si o si), de manera que en cuanto terminemos de instalar ya tendremos la infraestructura necesaria para echar a andar.
Por supuesto, esta configuración se puede cambiar para adaptarla a nuestras necesidades, pero de momento vamos a analizar la configuración de seguridad por defecto para entender como funciona y luego ya veremos.

OBIEE 11g maneja la seguridad usando los componentes de la plataforma Oracle Platform Security Services(OPSS) que utiliza una serie de “proveedores de seguridad” que vienen a representar el protocolo de seguridad que vamos a utilizar para autorizar y autenticar a los usuarios. Cambiando estos proveedores de seguridad conseguiremos adaptar la configuración de seguridad a nuestras necesidades.

Existen tres proveedores de seguridad (security providers), a saber:

AuthenticationProvider	Se encarga de llevar a cabo la primera fase de autorización, es decir, comprueba que las credenciales proporcionadas por el usuario son correctas y existen en la identity store. Por defecto, el authentication provider en OBIEE11g es el servidor LDAP embebido en WebLogic Server. La identity store en este caso está formada por los usuarios y grupos del directorio. Podríamos cambiar el authentication Provider para usar otro directorio, como OID o Active Directory.
Policy Store Provider	Una vez nos hemos autenticado, OBIEE utiliza el proveedor de políticas de seguridad para establecer cuales son nuestros permisos. Para ello, OPSS introduce un nuevo nivel de indirección entre los grupos del directorio LDAP que son mapeados a un concepto llamado Application Role. De esta manera es mucho más natural utilizar nuestro servicio de directorio habitual (el que tengamos en la empresa) y realizar los re-mapeos necesarios a nivel de roles de aplicación. Buena idea :) Por defecto, este proveedor utiliza la tecnología JAAS (Java Authentication and authorization Services) en un fichero system-jazn-data.xml
Credencial Store Provider	Este proveedor no nos interesa tanto para este artículo. Se encarga de mantener los credenciales internos que permiten comunicarse a los diferentes componentes de la suite OBIEE. Bueno es saberlo, oye.

¿Cómo se autorizan y autentican los usuarios en OBIEE 11g?

Todo esto está muy bien, pero ¿Cómo funciona? Vamos a repasar los pasos del diagrama

	Lo primero el usuario introduce sus credenciales en la pantalla de login. Suponiendo que acceda por el punto central de la aplicación estará en: http://server:7001/analytics
	Lo primero, el authentication provider comprobará si esos credenciales (usuario y password) existen en la identity store (los usuarios del WLS LDAP) y si son correctos. Si la autenticación es satisfactoria, ese usuario pertenecerá a uno de los tres grupos que se crean por defecto, que son: BIAdministrators (para el admin del sistema) BIAuthors (para los desarrolladores) BIConsumers (para los usuarios finales) Se crea una clase principal java que incluye el nombre de usuario y el grupo y se manda al Security Policy Provider.
	Ahora que sabemos a que grupo del directorio pertenece el usuario, vamos a buscar que rol de aplicación hemos definido para ese grupo. En la 10g había una relación directa entre el grupo del usuario y sus permisos, pero en la 11g se introduce un nuevo nivel de separación mediante estos roles de aplicación. Por defecto, se crean tres roles de aplicación, cada uno asociado a un grupo del directorio LDAP. BI Administrator Role (mapeado al grupo BIAdministrators) BI Author Role (mapeado al grupo BIAuthors) BI Consumer Role (mapeado al grupo BIConsumers) Por supuesto, existe una herencia entre roles, de manera que el Administrador hereda todos los permisos del autor, y por su parte el autor hereda todos los del consumidor. En cuanto hayamos determinado cual es el Application Role del usuario, sólo quedara determinar sus permisos en la siguiente fase.
	Un rol de aplicación tiene asociada una Security Policy que se compone de una serie de permisos que definen lo que un usuario va a poder ver y hacer en el sistema. Esta serie de permisos se reparten en tres áreas: Application Policy: Controla los permisos fundamentales de la suite OBIEE, como por ejemplo acceder al repositorio o a otros componentes como BI Publisher o finantials. Data Access Rights: Estos son permisos que se asignan en la herramienta de administración de BI y que nos permiten otorgar permisos de acceso sobre los metadatos del repositorio. Mediante esta configuración podemos, por ejemplo, hacer que un usuario no tenga acceso a determinadas tablas, o controlar que sus consultas sólo recuperen un número de filas determinado para evitar problemas de rendimiento. Estos permisos son los de más fina granularidad dentro del sistema OBIEE y normalmente sólo se utilizan para afinar mucho la configuración de privacidad. Presentation Services Object Level Access: Estos permisos se otorgan a nivel de Application Role o de usuario ( o de grupo de catálogo para mantener compatibilidad hacia atrás con 10g) y nos permiten controlar permisos a más alto nivel, como acceso a cuadros de mandos o informes completos. También controlamos desde aquí el acceso a determinadas funciones del sistema, como acceso ascorecards, etc.. Estos permisos los otorga el administrador usando la pantalla de configuración de Presentation Services. Todos estos permisos conforman de forma lógica lo que se llama la Security Policy asignada a un Application Role.
	Una vez que sabemos que un usuario está autenticado y hemos obtenido su política de seguridad a través de su rol de aplicación, se le concede el acceso al sistema.

En resumen:

• A partir de los credenciales obtenemos el grupo del LDAP al que pertenece el usuario
• A partir del grupo, obtenemos su rol de aplicación
• A partir del rol de aplicación, obtenemos su política de seguridad
• A partir de la política de seguridad, obtenemos sus permisos

Pues no era tan complicado como parecía ¿verdad? :P

Claro, todo esto parte de la base de que nuestro Authentication Provider es un servicio de directorio LDAP, bien sea el del propio WebLogic (por defecto y no recomendado para más de 1000 usuarios) o uno comercial como Oracle Internet Directory (OID) o Microsoft Active Directory (AD). ¿Pero que pasa si en nuestra organización no tenemos un LDAP, o no lo tenemos sincronizado con nuestro stack de aplicaciones de Oracle?

Fuente: http://www.bi.dev42.es/2011/05/15/modelo-de-seguridad-en-obiee-11g/