none
Gestion de la sécurité selon "Manager / Subordonnées" RRS feed

  • Question

  • Bonjour,

    Est-ce qu'il existe un outil additionnel sur le marché qui permettent de gérer la sécurité dans Sharepoint selon sa position hiérarchique ?

    L'idée existe dans "My Site" avec la portée de la visibilité de certains champs.

    Mais hors "My Site", peut-on faire quelque chose de similaire ?

    Je pense creuser la piste des "Custom Security Role", mais je ne sais pas si c'est une bonne piste.

    Merci pour vos contributions.
    Charles
    mardi 10 mars 2009 12:27

Toutes les réponses

  • Bonjour,

    Je rencontre cette demande dans un contexte sur deux aujourd'hui, c'est dire comme elle est fréquente. A ma connaissance, il n'existe pas de mécanisme tiers permettant de gérer ça dans SharePoint.

    Côté implémentation, c'est techniqument possible... mais à déconseiller fortement.

    Voici quelques pistes et raisons de ne pas les suivre :

    - Custom RoleProvider : ce provider ne gère pas les sous ensembles (un role contenu dans un autre role). La hiérarchie ne peut donc pas être respéctée. Outre cet aspect, vous serez contraint d'utiliser un MemberShipProvder, donc vous serez face à des difficultés supplémentaires, notamment conernant les limites d'intégration des outils Office (Word gère très mal la redirection par formulaire lié à l'utilisation des MemberShipProviders par exemple)

    - Gestionnaire d'événement + Job modifiant les droits pour ajouter la hiérarchie : Des difficultés de déploiements, car le gestionnaire doit être associé à toutes les listes existantes et à venir. Ce gestionnaire devra désactiver l'héritage de la sécurité au niveau liste/bibliothèque. Ce n'est déjà pas annodin. Une fois l'héritage désactivé, il devra interroger un annuaire (AD , WebService ou autre, peu importe) pour identifier la hiérarchie et ajouter les droits à la hiérarchie. Bien sûr, la hiérarchie évoluant, il faut prévoir de mettre à jour les droits sans gestionnaire d'événement, donc avec un job s'éxécutant régulièrement pour réaffecter lesd roits en cas de changement dans l'annuaire. De plus, il n'y a pas de vue temps réel des données assuré. Les droits attribués spécifiquement sont donc très nombreux : celà devient très difficle de savoir qui a accès à quoi. Outre ce point, le grand nombre d'ACL définis devient difficile à gérer et les performances de la plateforme SharePoint risquent de s'effondrer. En résumé, cette solution constitue une véritable usine à gaz, une bonne recette pour échouer sur un projet... à éviter absolument.

    - Gestion via la structure des sites : Difficile à mettre en place et à faire coller au besoin initial, mais cette solution est standard. L'idée est de se baser sur la hiérarchie pour faire vivre la structure du site. Les droits sont donc à gérer sur les sites plutôt que sur les documents. Le nombre de sites est cependant plus important, et les utilisateurs ont du mal à s'y retrouver. Celà implique un gros effort sur l'agrégation de données, sur la bonne utilisation des ContentTypes, etc. De plus, tout changement dans la hiérarchie doit entrainer la modification de la structure des sites. C'est un traitement à automatiser, et difficilement compatible avec une bonne gestion d'URL (les utilisateurs ayant ajouté des sites comme favoris dans leur navigateur ne retrouvent plus leurs sites).

    Bref, je sais que c'est difficile à faire passer, mais il faut faire passer au demandeur que cette gestion est à exlure. Il faut lui préférer la vision d'équipe avec un gestionnaire de site chargé d'affecter les droits aux personnes concernées. La solution la moins contraignante se trouve au niveau de la délégation de la gestion de la sécurité des sites.

    http://blogs.developpeur.org/gribouillon/
    jeudi 12 mars 2009 11:54
    Modérateur
  • Merci pour cette réponse.

    C'est bien dommage que rien ne soit prévu dans Sharepoint, alors que dans l'AD, il est possible de faire référence au supérieur hierarchique d'un utilisateur.

    Est-ce que IRM (Information Right Manager) couplé à MOSS pourrait répondre à ce besoin ?
    Je ne sais pas ce qu'est ILM (Identity Lifecycle Management) et si c'est mieux adapté...

    Un workflow pourrait modifier la sécurité à son déclenchement également...

    Dernière option, faire un dev .net pour faire une gestion de la sécurité comme souhaité, et l'intégrer via le BDC aux interfaces MOSS ?

    Enfin, une question importante est, comment fonctionne le MySite pour gérer les droits d'accès ? (Puisqu'à cet endroit, la notion de Manager existe...)
    vendredi 13 mars 2009 10:10
  • Les MySites fonctionnent de la même façon que les autres collections de sites. La notion de Manager est lié aux profils MOSS (détail utilisateur) et non aux comptes SharePoint (compte utilisateur). De la même façon que dans l'AD, la notion de manager est informative et ne permet pas de gérer des droits.

    IRM peut éventuellement vous aider, mais pas pour la navigation au sein des sites... plutôt du côté des documents en eux même. Je ne peux pas vous en dire plus sur IRL, c'est peut être à creuser.

    Le workflow et les gestionnaires d'événements fonctionnent... mais posent le problème que j'ai détaillé précédemment dans le deuxième point.

    En ce qui concerne le dev custom, vous ne pouvez pas le concevoir avec le BDC (ce n'est pas fait pour ça, et il n'y a rien qui vour permettrait de l'implémenter). VOus pouvez aussi imaginer changer la sécurité partout sur les sites, mais c'est un travail tytannesque, qui ne sera pas automatisé... et qui vous demande de tout réécrire. Bref, c'est ce qu'on ferait dans le cas d'un site ASP.Net.

    Vous aurez peut être des nouveaux éléments qui vous interesseront dans la prochaine version de SharePoint (sans avoir de détail à vous donner ni aucune certitude, je vous invite à consulter ce document : http://www.networkworld.com/news/2007/101607-microsoft-switching-sharepoint.html)
    http://blogs.developpeur.org/gribouillon/
    dimanche 15 mars 2009 23:17
    Modérateur
  • Pour clarifier mes propos sur le MySite, je pensais aux options que l'on peut configurer dans le SSP (/ssp/admin/_layouts/ManagePrivacyPolicy.aspx). C'est bien de la sécurité selon la hierarchie qui s'applique ici, non ?

    Pour le Dev Custom, je pensais à gérer cette problèmatique de sécurité à l'aide du dev, mais utiliser MOSS comme interface web pour voir les données et interagir avec elles.
    Le BDC étant un moyen comme un autre pour accéder à ces données (passe les credentials de la personne connecté, et c'est tout...). L'idée que je me fais du BDC c'est de pouvoir utiliser les fonctionnalités Sharepoint (tri, connection entre WP, recherche...) sur des données externes.

    Pour le reste, merci pour vos réponses.
    mardi 17 mars 2009 17:37