Chapter 3 · leçon 3 sur 12
Connectez-vous pour suivre votre progression
Questions de cette leçonPerson (identité) → User (login) → Security Group (autorisations) → Start Center (UI personnalisée). Ordre strict, FK NOT NULL à chaque maillon.READ (consulter), INSERT (créer), SAVE (modifier), DELETE (supprimer). Granularité par business object.Qualified (clause WHERE row-level), Conditional (expression runtime-évaluée), Hidden (attribut retiré de l'UI column-level).Security Groups app (flag Default cochet sur le record group). Auto-assignation aux nouveaux users.L'architecture de sécurité Maximo Manage repose sur une chaîne hiérarchique stricte de 4 entités. Chaque maillon est une étape obligatoire avant la suivante, validée par des contraintes FK au niveau base de données. Cette séparation est volontaire : elle permet de gérer indépendamment les identités (Person), les logins (User), les autorisations (Security Group) et l'UI (Start Center).
La logique métier sous-jacente : un Person représente une personne physique réelle (un humain dans l'organigramme), un User représente son compte d'accès aux systèmes, un Security Group regroupe les autorisations communes à un rôle métier (technicien, planner, controller), un Start Center personnalise l'UI selon ce rôle. Cette granularité permet de gérer 1 000 users avec ~10-20 Security Groups sans dupliquer les configurations individuellement.
People → Users → Security Groups → Start Centers. Inverser l'ordre est impossible (FK NOT NULL bloquent). Cette séparation permet d'auditer chaque couche indépendamment et de respecter les principes SOC2 / ISO 27001 de moindre privilège.Maximo applique strictement 4 permissions primitives sur chaque business object (WORKORDER, ASSET, LOCATION, PO, INVENTORY, etc.). Ces 4 verbes forment le CRUD basique et chaque permission peut être accordée ou refusée indépendamment. L'examen IBM teste systématiquement ces 4 noms — c'est un piège classique avec des distracteurs comme « UPDATE », « MODIFY », « VIEW », « CREATE » qui n'existent PAS dans Maximo.
| Permission | Verbe SQL | Action UI Maximo | Exemple révocation |
|---|---|---|---|
READ |
SELECT | Voir / lister / rechercher les records | WO confidentiels masqués pour group « stagiaires » |
INSERT |
INSERT | Créer un nouveau record (button New) | Group « consultation » ne peut pas créer de WO |
SAVE |
UPDATE | Modifier un record existant (button Save) | Read-only group peut consulter sans modifier |
DELETE |
DELETE | Supprimer un record (button Delete) | Personne ne peut supprimer hors administrateur |
APPR sur WORKORDER pour l'approbation workflow) — ce sont des permissions étendues, pas object-level standard.Les ODRs permettent de filtrer dynamiquement les données visibles ou éditables par un Security Group, sans modifier le schéma sous-jacent. Les autres groups voient toujours les données complètes. Maximo offre exactement 3 types, avec des portées de filtrage différentes : 2 row-level (Qualified, Conditional) et 1 column/attribute-level (Hidden).
| Type ODR | Portée | Mécanisme | Exemple concret |
|---|---|---|---|
Qualified |
Row-level | Clause SQL WHERE ajoutée à toutes les queries | « STATUS IN ('WAPPR','APPR') » pour cacher les WO terminés |
Conditional |
Row ou field | Expression évaluée au runtime via Conditional Expression Manager | « :user = assignedto » pour ne voir que ses propres WOs |
Hidden |
Field-level | Retire l'attribut de l'UI pour ce Security Group | Cacher SALARY pour groups non-HR |
L'accès multi-Sites se gère exclusivement via l'onglet Sites d'un Security Group. Cette approche est scalable : un admin sélectionne le group, ouvre l'onglet Sites, ajoute chaque Site autorisé (BEDFORD, NASHUA, etc.) ou coche « Authorize All Sites » pour accès global. Tous les users assignés héritent automatiquement de l'accès — aucune config per-user requise.
Avantage majeur : quand un Site s'ajoute ou se retire, on modifie le group une fois au lieu de mettre à jour 200 users individuellement. Anti-pattern à éviter : créer un user par Site et faire switcher les logins (multiplie la gestion, brise l'audit trail). Une autre erreur courante : tenter d'ajouter les Sites au record Person — le Person porte l'identité (email, phone, supervisor) mais pas les autorisations Site.
Les 5 confusions les plus fréquentes sur la sécurité à l'examen :
READ, INSERT, SAVE, DELETE. IBM utilise systématiquement les autres noms comme distracteurs.Q. Quelles sont les 4 permissions object-level par défaut dans Maximo Security Groups ?
READ, INSERT, SAVE, DELETE. Pas CREATE, pas UPDATE, pas MODIFY, pas VIEW.
Q. Quels sont les 3 types d'Optional Data Restrictions (ODR) ?
Qualified (clause WHERE row-level), Conditional (expression runtime row ou field), Hidden (attribut retiré UI column-level). 2 row-level + 1 column-level.
Q. Comment accorde-t-on l'accès multi-site à un user ?
Via l'onglet Sites d'un Security Group dans Security Groups app. Ajouter les Sites souhaités ou cocher Authorize All Sites. Tous les users assignés au group héritent automatiquement.
Q. Quelle est la chaîne de création complète pour qu'un nouveau user puisse se connecter ?
1. Person record (People app) → 2. User record (Users app, lié au Person via PERSONID) → 3. Assignation à ≥1 Security Group → 4. Start Center template associé au group. Ordre inverse impossible.