L’organisation actuelle des entités spéciales est assez limitée. On a d’un côté les autorités globales imposées par le code et de l’autre quelques autorités locales aux rôles limités.
Le bestiaire
Premier constat fait depuis un moment, l’entité maître unique puppetmaster est par définition un risque même si pour l’instant c’est la seule façon raisonnable d’avoir une cohérence de l’ensemble. Le but serait d’avoir une entité multi-tête à seuil dont le contrôle est réparti entre plusieurs porteurs. Cette entité n’a que pour mission de désigner les autres entités spéciales globales dont la plus utilisée aujourd’hui est l’entité maître du code bachue. L’entité puppetmaster a un rôle d’autorité et sa portée est globale.
L’entité spéciale cerberus permet de gérer les bannissement d’objets. C’est un peu le rôle de police. L’enfer n’ayant pas encore officiellement ouvert, cette entité n’est pas utilisée mais elle pourrait être très rapidement sollicitée fortement pour tout et n’importe quoi.
L’entité spéciale maître du code bachue est aussi désignée autorité mais est subordonnée au puppetmaster. Son rôle est uniquement de gérer le code sous toutes ses formes.
L’entité spéciale kronos n’a qu’un rôle théorique pour l’instant et n’a que brièvement été utilisée dans des expériences. Cette entité va générer des repères temporels fiables. Mais je pressens qu’elle va devenir incontournable à l’avenir, et peut-être critique pour certains usages.
Enfin, l’entité spéciale asabiyya va être utilisée pour relier les gens avec de la confiance. Elle n’est pas encore utilisée non plus.
Les rôles
On peut distinguer plusieurs catégories d’entités. Les autorités désignes des entités sur des rôles. Les administrateurs font des choix de configuration du code et des applications. Les gestionnaires gèrent des objets, des applications, des entités. Et chaque rôle peut avoir une portée locale ou exceptionnellement globale.
Il existe déjà des méthodes d’organisation qui avaient été retranscrites dans l’article Être relié ou ne pas être. Le modèle RBAC est implémentable par les liens de nebule, le modèle OrBAC semble être moins adapté à nebule parce qu’il sous-entend une une organisation, une structure, qui n’est pas portée par nebule.
La liste de grandes catégories de rôles à compléter peut déjà prévoir l’autorité (authority), la police, l’administrateur (administrator), le gestionnaire (manager), l’entité de recouvrement (recovery)…
L’attribution de rôle est additive, les rôles s’ajoutent à une entité mais il n’y a pas de négation de rôle. Pour les rôles locaux, il est possible de supprimer un rôle d’une entité. Il n’y a pas d’inhibiteur de rôle mais juste un une suppression de lien.
La réflexion continue…
