Michel Perfetti [Miiitch]

J’ai installé TFS 2010 et après? Contrôle d’accès: c’est pas la fête au village!

Structurellement, TFS est un application 3-tiers : le client (le Team Explorer) la souche de service (qui est à l’adresse de notre serveur) et les bases de données. Nous les développeurs, notre vision s’arrète à la couche de service, c’est à ce niveau que la sécurité est gérée. Je ne compte pas ici faire un tour exhaustif des droits et comptes de sécurité de TFS, mais un tour d’horizon de ce qui est possible de faire avec.

Sécurité au niveau du serveur et des collections de projets

la collection de projet est une segmentation du serveur en entités indépendantes (voir mon billet sur les  Collections de projets). Vous pouvez donc avoir plusieurs équipes distinctes sur le même serveur. Un bon exemple de mutualisation de ressource est la migration de Codeplex sur TFS 2010 .

Concernant les droits du coté du serveur, cela se passe sur la console d’administrateur de TFS :

“Group membership” permet entre autre de donner les droits administrateurs au serveur. Mais être administrateur de TFS est différent de pouvoir administrer TFS via sa console d’admin et  TFS est un ensemble de service:

• des sites sharepoints
• un serveur de rapport SQL Server
• un cube
• ….

Pour pouvoir administrer tout cela, il faut pour chaque compte avoir les bons droits. C’est le role de la liste de utilisateurs de la console d’admin de gérer cela. Lorsque j’ajoute un utilisateur (Bob) à cette liste, la liste des opérations suivantes est réalisée:

Les opérations sont bien sur annulées lorsque l’on retire l’utilisateur de la liste.

SI l’on veut maintenant gérer la sécurité au niveau de la collection de projet, c’est aussi possible dans la console d’administration:

Généralement, à ce niveau, la tâche la plus courante est de définir les administrateurs de la collection de projets. Et si l’on veut définir maintenant plus finement les droits, il va falloir sortir de la console d’administration et d’aller dans le Team Explorer, et là ce n’est plus le rôle de d’administrateur de TFS, mais de celui de la collection.

Contrôle d’accès à la collection de projets et au projet

Nous revoilà dans le Team Explorer. Pas besoin d’avoir accès à la console du serveur pour les prochaines manipulations. Au niveau de la collection, généralement, on ajoute d’autres administrateurs:

Théoriquement on devrait aussi définir les utilisateurs de la collection, mais ce n’est pas la peine.TFS ajoute automatiquement les groupes d’utilisateurs de chaque projet de la collection:

Il suffit donc d’ajouter un utilisateur dans un projet pour qu’il soit autorisé dans la collection.Dans un projet, on ajoute généralement  les utilisateurs dans 3 groupes importants: les administateurs, les contributeurs et les lecteurs. Les administrateurs du projet permettent de modifier les artefacts du projet, les 2 autres groupes sont accès clairs. Coté confidentialité, les workitems d’un projet ne sont visibles par les utilisateurs que si possède les droits de les voir au niveau du projet. Cela est aussi valable pour les autres artefacts comme le contrôleur de source et les builds. Si un utilisateur essaye de voir une information dont il n’a pas accès, il reçoit une erreur comme si cette artefact n’existait pas (Voir http://en.wikipedia.org/wiki/Information_leakage).

Contrôle d’accès au niveau du source

Il  y a parfois des cas ou il faut descendre encore plus bas dans la sécurité: comme les droits par élément du code source. Par exemple: la branche de Fix est uniquement modifiable par l’équipe de support et la branche de release n’est qu’en lecture seule (voir le billet  Organisation des sources). Dans ce cas il suffit d’aller dans le Source Control Explorer et d’aller dans les propriétés du dossier que l’on veut gérer:

Le droit que l’on modifie le plus souvent est le droit de “Check-in”.On touche au droit de “Read” lorsqu’on veut garantir la confidentialité d’une partie du code. Remarque importante: lorsque l’on branche du source, on récupère aussi les droits de la branche parente. C’est une chose tout à fait logique mais on peut se faire surprendre.

Quelques astuces

La chose la plus importante lorsque l’on commence à modifier la sécurité est d’éviter les cas particuliers: il faut toujours essayer de passer par des groupes d’utilisateurs. Si possible définir les droits pour des groupes AD, comme cela tout est fait en dehors de TFS, sinon des groupes TFS et là il faut ajouter manuellement (et supprimer aussi manuellement) les utilisateurs.

Dans TFS, pour chaque droit, il y a une case “Allow” et une case "Deny”. Il faut éviter le plus souvent de cocher la case “Deny”: si un utilisateur fait parti de 2 groupes, dont un qui est en “Allow” et l’autre en "Deny”. Il sera en “Deny” sur ce droit. Surtout que si aucune des 2 cases n’est cochée, il n’y pas accès à la ressource.

Et pour terminer, Team Foundation Sidekicks est un très bon outil pour éditer les droits et régler les problèmes d’accès.

@+