Embedded Files
Voici les instructions que j'ai reçu pour le nouveau design:
I would also designed differently your use case, based on Syncope features:
* no need for PERSON, just stick to USER
* define a Group for each application, where:
* the Type Extension for the Group contains all user attributes required by the application
* the External Resource is assigned to the Group, not the single User, where the mapping of such External Resource is based on both USER and Membership attributes (as defined by the Type Extension)
Now, when a user needs to be assigned to an application, a membership will be created and the given user will be propagated to the Resource assigned to the Group for the membership.
No need for any code customization.
Une élaboration laborieuse
Une élaboration laborieuse
En premier lieu je n'ai rien compris à ce que voulait dire Extension car dans l'interface Française ce menu ne fonctionnait pas. Un extension est un jeu d'attribut que l'on ajoute dans le cadre de l'association d'un compte et d'un groupe.
Ensuite il me fallait une ressource REST pour supporter les données de groupe et de compte que j'allait produire avec ce nouveau design. Pour cela j'ai modifié mon projet pour les personnes et ajouter une API d'administration d'une application qui permet la gestion de ces nouveau objets.
J'ai mis un certain temps à mettre au point la ressource côté Syncope / ConnId pour provisionner les groupes et aussi de bien distinguer les deux flux de données entre GROUP et __GROUP__ et USER et __ACCOUNT__.
Dans ma logique le calcul du login du compte doit se faire via le groupe en utilisant un attribut dérivé et la formule login = 'adm-'+personId. Mais je me suis aperçu que la formule ne marchait pas et que c'était une erreur.
J'ai aussi mis du temps à comprendre qu'il fallait utiliser des formule particulière pour alimenter les attributs de l'extension et que cela générait une rigidité particulière du modèle:
Dans tous les cas un groupe est associé à une ressource, mais ça peut être le même connecteur. Donc si votre application à une centaine de configuration vous aurez une centaine de ressource pour un connecteur
En conséquence la propagation des données contenue dans le groupe et qui représente les données d'autorisation supportées par les attributs de l'extension utilise des formules de mapping du type "intAttrName": "groups[appAdmin].projects" qui permettent dans le contexte d'un USER lié au GROUP appAdmin de trouver les données contenues dans l'attribut projects, par exemple les projets autorisés
Mais il possible de laisser les champs d'extension ouvert à la saisie et alors la formule de mapping devient "intAttrName": "memberships[appAdmin2].projects" et l'interface enduser permet la saisie
Ce modèle de classe est une simplification de tous les éléments sur lesquels on doit agir pour configurer Syncope dans le cadre du modèle proposé par Francesco Chicchiriccò. On reconnait:
l'Extension qui se définit sur le GROUP par des attributs (AnyTypeClasse) sur USER
L'association GROUP et Resource et le Connector supportant la Resource
Dans la Resource le Provisioning des objets USER et GROUP qui s'appuie sur un Mapping
En conclusion il devrait être possible avec la version 4.0.4 de réaliser le modèle proposer et sans doute qu'avec un annuaire LDAP on peut supporter cette logique au prix d'une réécriture de tous les cas d'autorisations dans des groupes / ressources et mapping statiques côté Syncope. Je ne pense pas que ce soit le sens de l'histoire ...
Page updated
Report abuse