La sécurité sous Cognos BI peut devenir un vrai casse-tête dès que le nombre d’utilisateurs à administrer devient important. Via cette série d’articles nous allons voir quelques bonnes pratiques facilitant la mise en œuvre et permettant d’éviter les principaux écueils.
Partie 1 : Présentation des différents objets de sécurité
Cette première partie a pour objet de présenter les différents objets utilisés dans Cognos pour gérer la sécurité, et de préciser certaines notions importantes pour bien comprendre les articles suivants.
Les espaces-noms
Les espaces-noms (namespaces en anglais) contiennent les objets utilisés dans Cognos pour la gestion de la sécurité, tels que les groupes et les rôles, mais aussi les connexions aux sources de données, les listes de distributions ainsi que les profils utilisateurs.
Il existe deux types d’espaces noms dans Cognos :
- L’espace-nom local (nommé « Cognos » par défaut)
- Les espaces-noms externes, connectés à un annuaire d’entreprise (LDAP)
L’espace-nom local permettant uniquement de gérer des groupes et des rôles spécifiques à l’application, il faut noter que Cognos BI ne fourni donc pas de composant permettant en interne la gestion d’utilisateurs nommés.
C’est pourquoi il est nécessaire de paramétrer au moins un annuaire externe (LDAP) afin de gérer des comptes utilisateurs ainsi que le processus d’authentification.
Cognos BI est compatible avec l’ensemble des technologies d’annuaire du marché. (OpenLDAP, ApacheDirectory, Active Directory, solution spécifique, etc…)
Le paramétrage des annuaires externes est effectué dans Cognos Configuration.
Le Cognos Access Manager ID (CAMID)
Chaque utilisateur est identifié dans Cognos BI grâce à une chaîne unique, basé sur les propriétés suivantes :
- L’ID d’espace nom :
L’ID d’espace nom est défini dans Cognos Configuration. Il peut être différent du nom de l’espace-nom, qui est présenté dans l’écran d’authentification aux utilisateurs. Il est important de noter que si l’ID d’espace-nom devait être modifié, Cognos considèrerait cela comme un nouvel espace-nom, et l’ensemble des profils et objets utilisateurs deviendraient inaccessibles (Car restant attachés à l’ancien ID).
- La propriété nsuniqueid :
La propriété nsuniqueid doit être renseignée dans la configuration de l’espace-nom avec un attribut de l’annuaire externe utilisé, et qui doit être un identifiant unique pour chaque objet de l’annuaire. Cet attribut est totalement géré par l’annuaire et Cognos n’y accède qu’en lecture seule.
- Le type d’objet :
Utilisé dans le CAMID via un caractère. Par exemple, ce caractère vaut « u » pour un utilisateur et « g » pour un groupe.
Ainsi, pour un annuaire dont l’ID serait « LDAP_ID » et un utilisateur nommé « David Smith » avec une propriété nsuniqueid extraite de l’annuaire valant « smithd », le CAMID résultant serait :
CAMID("LDAP_ID:u:smithd")
Authentification automatique des utilisateurs (Single-signon)
Cognos BI fourni deux manière d’activer l’authentification automatique (Single-signon) des utilisateurs :
- Utilisation de Kerberos SSO :
Aucune configuration n’est nécessaire côté Cognos BI. Néanmoins, le compte utilisé pour accéder à l’annuaire externe dans Cognos Configuration (propriété “bind user DN and password”) doit posséder les droits de délégation Kerberos au niveau de l’annuaire.
- Utilisation de variables d’environnement :
Les informations d’identification sont transmises par une application tierce et stockés dans une variable d’environnement sur les machines clientes. Dans Cognos Configuration, la propriété “use external identity mapping” doit être renseigné en fonction de la variable à récupérer.
Groupes, Rôles et comptes utilisateurs
Cognos BI utilise 3 types d’objets pour de gérer la sécurité :
- Les rôles
Les rôles sont utilisés pour gérer l’accès aux différentes fonctionnalités du portail, et pour organiser les utilisateurs selon un axe technique.
- Les groupes
Les groupes sont utilisés pour gérer l’accès au contenu Cognos BI, et pour organiser les utilisateurs selon un axe métier.
- Les comptes
Les comptes représentent les utilisateurs, uniques par leurs identifiants d’authentification. Chaque compte possède un profil configurable et un espace personnel dans lequel l’utilisateur peut stocker ses objets Cognos. Le profil est créé lors de la première connexion de l’utilisateur.
Les appartenances aux groupes et rôles dans Cognos BI sont cumulatives. Ainsi, un utilisateur membre du groupe “RH Manager” et du groupe “France” cumulera les droits définis pour ces deux groupes.
Rôles et groupes par défaut
Cognos BI fourni 4 groupes et rôles par défaut qui ne peuvent être supprimés :
- Administrateurs système :
Tous les utilisateurs membres de ce rôle ont accès à l’ensemble des objets et fonctionnalités du portail, et ce quel que soit la sécurité définie par ailleurs.
- Tous les utilisateurs authentifiés :
Ce groupe représente l’ensemble des utilisateurs qui se sont connectés au portail au moins une fois. En pratique, cela correspond à tous les utilisateurs qui possèdent un profil.
- Tous :
Ce groupe représente l’ensemble des utilisateurs pouvant potentiellement accéder d’une manière ou d’une autre au portail Cognos Connection. En pratique, cela correspond à l’ensemble des comptes accessibles par Cognos dans les espaces-noms paramétrés dans Cognos Configuration.
- Anonyme :
Il s’agit du seul compte utilisateur pouvant exister dans l’espace-nom local de Cognos BI. Si l’accès anonyme est autorisé dans Cognos Configuration, ce compte représente l’ensemble des utilisateurs accédant au portail Cognos Connection et ne s’étant pas encore authentifié. Ce compte n’a pas d’utilité si l’accès anonyme est désactivé dans Cognos Configuration.
Les autres groupes et rôles par défaut peuvent être supprimés (bien que ce ne soit pas recommandé), et fournissent un axe technique basique donnant accès aux différentes fonctionnalités du portail.
Les permissions
La sécurité Cognos BI étant extrêmement fine, absolument tous objets Cognos peuvent posséder des permissions spécifiques. Pour chaque objet, les permissions définies s’appliquent à l’objet en question ainsi qu’à ses descendants (sauf en cas de permission spécifique définie sur les descendants).
Les permissions peuvent être autorisées, interdites ou indéfinies et sont les suivantes :
Lecture : Permet de voir l’objet.
Ecriture : Permet d’éditer les propriétés de l’objet.
Exécution : Permet d’exécuter l’objet (S’il est exécutable).
Définition des règles : Permet de changer les permissions de l’objet.
Passage : Ne permet pas de voir l’objet, mais autorise l’accès direct aux descendants de l’objet.
Les fonctions
Les fonctions Cognos BI sont utilisées pour définir l’accès aux différentes fonctionnalités du portail. Certaines fonctions possèdent des sous fonctions, afin de gérer les droits plus finement.
Une fonction est autorisée lorsqu’une permission de type “Exécution” est définie sur celle-ci. Pour autoriser seulement une sous fonction sans autoriser la fonction parente, une permission de type “Passage” doit être définie sur la fonction parente.
Les permissions possibles sur les fonctions reprennent le modèle Cognos détaillé précédemment. Néanmoins les permissions de type “Lecture” et “Ecriture” n’ont aucune utilité pour ce type d’objet.
Les fonctions peuvent de plus être redéfinies pour chaque dossier dans Cognos Connection. Ces surcharges spécifiques sont définies en éditant les propriétés des dossiers en question.
L’analyse de l’accès aux différentes fonctions de Cognos BI permet de déduire pour chaque utilisateur le type de licence commerciale effectivement consommé.
L’accès aux données
Les groupes & rôles Cognos BI peuvent être utilisés pour définir une sécurité sur l’accès aux données, durant l’accès aux bases de données relationnelles métiers. Cette sécurisation est effectuée durant la phase de modélisation, dans Framework Manager. La sécurité peut être utilisée de deux manières :
- D’une part pour définir l’accès aux différentes données élémentaires d’un package publié sur le portail
- D’autre part pour spécifier des filtres de sécurité qui seront appliqués automatiquement aux requêtes effectuées en base de données.
Dans le cas de bases de données OLAP (cubes) telles que les Powercubes, la sécurité doit être gérée par le moteur OLAP. Étant donné que toutes les technologies OLAP ne sont pas capables de travailler avec des groupes et rôles Cognos, la mise en place de la sécurité peut s’avérer assez complexe.