Tableau de bord/Chapter 3/1.11 — Configurer les Role-Based Applications
Chapter 3 · leçon 11 sur 12
L'architecture de sécurité des applications basées sur les rôles dans Maximo Manage est fondamentale pour garantir que les utilisateurs accèdent uniquement aux données et aux fonctionnalités pertinentes pour leurs tâches. Cette architecture est particulièrement critique pour les applications mobiles et les interfaces utilisateur spécifiques à un rôle, qui nécessitent souvent un contrôle d'accès granulaire et une performance optimisée.
Au cœur de cette architecture se trouvent les `Object structures`, qui agissent comme des passerelles de données, et les `Security groups`, qui définissent les permissions des utilisateurs. Ces deux éléments travaillent de concert pour réguler l'interaction entre les applications basées sur les rôles et les données sous-jacentes de Maximo Manage.
Certavia B
B -- "Requête données via OSLC/REST" --> C
C -- "Interagit avec" --> D
E -- "Définit les droits d'accès pour" --> B
E -- "Définit les droits d'accès pour" --> C
F -- "Personnalise UI/Logique de" --> B
classDef primary fill:#1D9E75,stroke:#178A66,stroke-width:2px,color:#FFFFFF
classDef secondary fill:#F1F5F9,stroke:#475569,stroke-width:2px,color:#0F172A
classDef tertiary fill:#FFD700,stroke:#DAA520,stroke-width:2px,color:#0F172A
classDef quaternary fill:#ADD8E6,stroke:#87CEEB,stroke-width:2px,color:#0F172A
">
La sécurité des applications mobiles et basées sur les rôles dans Maximo Manage est structurée autour de plusieurs composants interdépendants. Comprendre ces composants est essentiel pour configurer correctement l'accès et les privilèges, garantissant ainsi que les utilisateurs disposent des informations nécessaires sans compromettre l'intégrité des données.
Chaque composant joue un rôle spécifique dans la définition et l'application des règles de sécurité, depuis la granularité des données accessibles jusqu'aux actions que les utilisateurs peuvent effectuer au sein de l'application.
| Composant de sécurité | Vue d'ensemble | Exemple d'utilisation |
|---|---|---|
Object structure |
Les applications basées sur les rôles s'appuient sur `Maximo Manage` et plusieurs `Object structures` pour envoyer et recevoir des données. Elles utilisent des appels `OSLC/REST` pour échanger des données. Le niveau d'accès est défini depuis l'onglet `Object Structure` de l'application `Security groups`. | Lors de l'édition d'un `asset`, l'objet `MXAPIVENDOR` peut fournir une liste de `companies` fournisseurs dans l'application. L'accès en `READ` est généralement requis pour afficher ces listes. |
Security groups |
Les `Security groups` sont utilisés pour accorder ou refuser l'accès aux applications, aux `Object structures` et aux fonctionnalités spécifiques (`sigoptions`). Par défaut, les applications basées sur les rôles n'accordent pas d'accès à l'installation. | Un `Security group` pour les techniciens peut avoir un accès en `READ` et `WRITE` à l'`Object structure` des `WORKORDER` mais seulement en `READ` pour les `ASSET`. |
| Paramètres de l'application mobile | Chaque application mobile peut avoir un ou plusieurs paramètres qui contrôlent l'accès aux données mobiles et le comportement de l'application. Ces paramètres sont spécifiques à l'application et peuvent influencer la visibilité des champs ou des actions. | Une application `Technician` peut avoir un paramètre pour afficher uniquement les `WORKORDER` assignés à l'utilisateur connecté, ou pour permettre l'enregistrement de `meter readings` hors ligne. |
| `Application Designer` | Permet de personnaliser l'interface utilisateur des applications, d'ajouter des éléments conditionnels et de configurer des `sigoptions` pour contrôler la visibilité et l'interactivité des composants. | Un administrateur peut utiliser l'`Application Designer` pour masquer un bouton "Supprimer" pour certains `Security groups` ou rendre un champ "Coût" en lecture seule. |
| `Scripting` | Permet d'ajouter une logique métier personnalisée et d'automatiser des tâches. Les scripts peuvent être utilisés pour implémenter des validations complexes ou des actions spécifiques non couvertes par la configuration standard. | Un script peut automatiquement changer le `WOSTATUS` d'une `WORKORDER` à `COMPLETE` si toutes les `tasks` associées sont terminées et que tous les `meter readings` requis ont été enregistrés. |
La configuration des privilèges d'accès pour les applications basées sur les rôles est une étape cruciale après leur déploiement. Par défaut, ces applications n'accordent aucun accès lors de l'installation, ce qui nécessite une intervention manuelle pour attribuer les droits appropriés aux `Security groups` existants. Cette approche garantit un contrôle strict sur qui peut accéder à quoi.
Le processus implique l'utilisation de l'application `Security groups` pour définir les permissions au niveau des `Object structures` et des fonctionnalités spécifiques. Il est également possible d'affiner ces configurations via l'`Application Designer` et le `Scripting` pour des besoins plus complexes.
Le cycle de vie de la sécurité d'une application basée sur les rôles dans Maximo Manage suit une série d'étapes logiques, de l'installation initiale à la maintenance continue. Chaque étape est cruciale pour assurer que l'application fonctionne de manière sécurisée et efficace, en s'adaptant aux besoins évolutifs de l'organisation.
Ce processus met en évidence l'importance de la planification, de la configuration initiale et de la révision régulière des droits d'accès pour maintenir un environnement sécurisé et conforme.
Un piège courant est de supposer que les applications basées sur les rôles, une fois installées, accordent automatiquement un accès minimal aux utilisateurs. La réalité est qu'elles n'accordent aucun accès par défaut. Si un administrateur oublie d'attribuer explicitement les droits via l'application `Security groups`, les utilisateurs ne pourront pas accéder ou utiliser l'application, même si elle est visible. Cela peut entraîner des retards de déploiement et de la frustration. Il est impératif de toujours configurer les `Security groups` après l'installation.
Une erreur fréquente est de ne pas comprendre la granularité de la sécurité offerte par les `Object structures` et les `sigoptions`. Un administrateur pourrait accorder un accès complet à une `Object structure` sans restreindre les actions spécifiques via les `sigoptions`. Par exemple, donner un accès `WRITE` à l'`Object structure` `MXWO` permettrait à un utilisateur de modifier n'importe quel champ de `WORKORDER`. Sans configurer des `sigoptions` pour restreindre des actions comme "Changer statut" ou "Supprimer", l'utilisateur pourrait effectuer des opérations non autorisées. Il est crucial de combiner les deux niveaux de sécurité pour un contrôle fin.
Les applications mobiles `Maximo Mobile` (`Technician`, `Inspections`) dépendent fortement des `Object structures` pour l'échange de données. Modifier une `Object structure` existante ou en créer une nouvelle sans mettre à jour les configurations de sécurité correspondantes dans l'application `Security groups` peut entraîner des erreurs d'accès aux données ou des comportements inattendus dans l'application mobile. Par exemple, si un champ est ajouté à un objet de base de données et que l'`Object structure` n'est pas mise à jour avec les permissions appropriées, l'application mobile ne pourra pas afficher ou modifier ce champ, même si l'utilisateur a les droits sur l'objet sous-jacent. Toujours vérifier la cohérence entre les `Object structures` et les permissions des `Security groups`.
Outre les `Object structures` et les `Security groups`, les applications mobiles Maximo possèdent souvent des paramètres de configuration spécifiques qui influencent l'accès aux données et le comportement de l'application (par exemple, le mode hors ligne, les filtres par défaut). Un administrateur pourrait configurer correctement les `Object structures` et les `Security groups`, mais oublier de paramétrer ces options spécifiques à l'application. Cela peut entraîner une expérience utilisateur incomplète ou des limitations inattendues, comme l'impossibilité de travailler hors ligne ou de voir des données filtrées de manière incorrecte. Il est essentiel de consulter la documentation spécifique à chaque application mobile pour s'assurer que tous les paramètres pertinents sont configurés.
Les trois composants principaux sont les `Object structures`, les `Security groups` et les paramètres spécifiques à l'application mobile. Ces éléments travaillent ensemble pour définir qui peut accéder à quelles données et fonctionnalités.
Il est crucial car, par défaut, les applications basées sur les rôles n'accordent aucun accès lors de l'installation. Sans configuration explicite via l'application `Security groups`, les utilisateurs ne pourront pas utiliser l'application, même si elle est déployée.
L'`Application Designer` permet de personnaliser l'interface utilisateur (UI) des applications, d'implémenter des éléments conditionnels via des `sigoptions` et des expressions, et d'ajouter de nouvelles actions pour adapter l'application aux besoins métier spécifiques.
Les `Object structures` agissent comme des interfaces pour l'échange de données entre les applications basées sur les rôles et `Maximo Manage`. Elles utilisent des appels `OSLC/REST` et permettent de définir le niveau d'accès (lecture, écriture) aux données sous-jacentes via l'application `Security groups`.
L'`Application Configuration` est une fonctionnalité de `Maximo Application Suite` qui permet de gérer les configurations des applications, y compris les applications basées sur les rôles. Elle offre un environnement pour télécharger, modifier, prévisualiser et publier les configurations d'applications `Maximo Manage` avec une configuration minimale.
Les applications `Maximo Mobile` (comme `Technician` et `Inspections`) sont des applications hybrides qui peuvent fonctionner dans un navigateur, en mode connecté ou via une application mobile supportant également le mode hors ligne. Les autres applications basées sur les rôles peuvent être des interfaces web spécifiques à un rôle sans nécessairement offrir de capacités hors ligne natives.
Bonne réponse : D
Pourquoi cette question existe — STU §3.11 — la question distingue l'outil de configuration des Role Based Applications (MAF Configuration) des outils classiques utilisés pour les applications Manage traditionnelles (Application Designer). Les distracteurs citent un vrai outil Manage (Application Designer) inapproprié pour les RBA, et des outils de développement génériques sans rapport. En pratique, tenter d'ajouter un attribut RBA via Application Designer échoue car ces apps suivent un modèle de configuration différent.
Le contexte théorique d'abord — Les Role Based Applications (apps mobiles/légères MAS) sont configurées via l'application Maximo Application Framework Configuration, un outil distinct d'Application Designer (réservé aux apps Manage classiques basées sur MBO/présentation XML).
Ce que Maximo en fait — version opérationnelle — Dans Maximo Application Framework Configuration application, sélectionner la Role Based Application cible > ajouter un nouvel attribut > le lier à un Object Structure existant > publier la configuration pour que l'attribut apparaisse dans l'app.
Exemple chiffré — Ajouter 1 attribut personnalisé à une RBA mobile utilisée par 200 techniciens terrain ne nécessite aucune ligne de code Java, contrairement à un développement Eclipse traditionnel qui prendrait 3 à 5 jours.
Analogie quotidienne — C'est comme utiliser l'éditeur visuel d'une appli mobile no-code plutôt que d'écrire le code source à la main : MAF Configuration joue ce rôle pour les Role Based Applications.
Pourquoi A est faux — Pattern D6 mauvaise-app : Application Designer configure les applications Manage classiques, pas les Role Based Applications.
Pourquoi B est faux — Pattern D2 inventé : « Maximo Design Tool » n'est pas le nom d'un outil Maximo réel.
Pourquoi C est faux — Pattern D6 mauvaise-app : Eclipse IDE sert au développement Java bas niveau, pas à la configuration no-code des RBA.
Bonne réponse : C
Pourquoi cette question existe — STU §3.11 — la question identifie le mécanisme d'autorisation propre aux Role Based Applications, distinct de la signature électronique ou des templates de Start Center qui répondent à d'autres besoins. En pratique, les Security Templates simplifient l'octroi de droits cohérents sur un ensemble de Work Centers/RBA.
Le contexte théorique d'abord — Un Security Template est un modèle pré-construit de droits regroupant accès applicatif et autorisations sur les Object Structures associés à un Work Center ou une Role Based Application. L'appliquer à un Security Group accorde en une seule opération l'ensemble cohérent de droits nécessaires.
Ce que Maximo en fait — version opérationnelle — Dans Security Groups, sélectionner le groupe > appliquer un Security Template correspondant à la RBA cible > le template configure automatiquement l'onglet Applications ET l'onglet Object Structures (via Object Structure Authorizations) en cohérence.
Exemple chiffré — Un Security Template pour une RBA donnée configure en 1 seule application jusqu'à 5-6 object structures liés (ex. MXAPIPERUSER et consorts), contre une configuration manuelle ligne par ligne sinon.
Analogie quotidienne — C'est comme appliquer un thème prédéfini à un document plutôt que de formater chaque section manuellement : le Security Template applique d'un coup l'ensemble cohérent des droits nécessaires.
Pourquoi A est faux — Pattern D5 champ-frère : les Signature Options gèrent l'authentification e-signature d'une action, pas l'autorisation d'accès aux données RBA.
Pourquoi B est faux — Pattern D6 mauvaise-app : les Start Center Templates configurent l'apparence de la page d'accueil, pas les droits d'accès aux données.
Pourquoi D est faux — Pattern D2 inventé : « Authorize MAF Applications » n'est pas le nom d'un mécanisme d'autorisation Maximo standard.
Bonne réponse : A
Pourquoi cette question existe — STU §3.11 — cette question est le pendant pratique de Q40 : comment, concrètement, octroyer en une fois les droits sur plusieurs Object Structures liés à une même RBA. Les distracteurs proposent des actions réelles (entitlement Suite, Person Group) qui adressent d'autres couches (licence, assignation), pas l'autorisation de données. En pratique, croire que l'accès applicatif suffit (option D) est l'erreur la plus fréquente en configuration RBA.
Le contexte théorique d'abord — Lorsqu'une Role Based Application s'appuie sur plusieurs Object Structures, chacun doit être explicitement autorisé. Plutôt que de les configurer un par un, l'administrateur applique un Security Template dédié, qui couvre d'un coup l'ensemble cohérent des Object Structures requis par cette RBA.
Ce que Maximo en fait — version opérationnelle — Dans Security Groups > sélectionner le groupe > Apply Security Template > choisir le template correspondant à la RBA > Maximo configure automatiquement l'onglet Object Structures pour chacun des objets requis (ex. MXAPIPERUSER et autres).
Exemple chiffré — Une RBA s'appuyant sur 4 Object Structures distincts nécessiterait 4 configurations manuelles ; un Security Template les couvre en 1 seule action d'application.
Analogie quotidienne — C'est comme activer un pack d'options groupées sur un contrat plutôt que souscrire chaque option séparément : le Security Template regroupe l'ensemble des autorisations nécessaires.
Pourquoi B est faux — Pattern D5 champ-frère : l'entitlement Suite régule le niveau de licence (Limited/Base/Premium), pas l'autorisation fine sur les Object Structures.
Pourquoi C est faux — Pattern D5 champ-frère : le Person Group sert à l'assignation de travail ou à la résolution de Role, pas à l'octroi de droits sur des Object Structures.
Pourquoi D est faux — Pattern D3 inverse : c'est l'exact opposé du comportement réel — l'accès applicatif seul NE configure PAS automatiquement les permissions sur les Object Structures associés.