L'objectif de ce scénario est de permettre aux clients d'accéder à une base de données ClearQuest interne, afin qu'ils puissent afficher les enregistrements associés à leurs incidents, soumettre de nouveaux incidents et éventuellement afficher d'autres informations publiques pertinentes.
Il est souvent utile de permettre aux clients d'accéder à une base de données ClearQuest interne, afin qu'ils puissent afficher les enregistrements associés à leurs incidents, soumettre de nouveaux incidents et éventuellement afficher d'autres informations publiques non spécifiques à un client particulier.
Un aspect clé de cette fonction est que le client ne peut pas être autorisé à afficher ou rechercher l'existence d'informations relatives à d'autres clients. Il n'est pas non plus autorisé à afficher ou rechercher l'existence d'utilisateurs ou d'informations internes.
Il est important de noter que les droits d'accès aux dossiers de l'espace de travail ne constituent qu'une partie de la solution permettant d'atteindre le but mentionné ci-dessus. De nombreux schémas ClearQuest incluent des enregistrements contenant des données qu'il est conseillé de garder hors de portée des clients.
La fonction de contexte de sécurité de Rational ClearQuest doit être utilisée pour restreindre la visibilité des enregistrements renvoyés par une requête. Les droits d'accès aux dossiers de l'espace de travail ne limitent pas les données renvoyées par une requête. Et les droits d'accès aux dossiers de l'espace de travail ne limitent absolument pas la capacité des utilisateurs à effectuer des requêtes personnelles. Seule la fonction de contexte de sécurité de Rational ClearQuest peut restreindre la visibilité des enregistrements renvoyés par une requête.
Pour réellement permettre au client d'accéder à une base de données utilisateur interne, le développeur de schémas aurait à modifier les types d'enregistrement fournis par le schéma, en ajoutant des références aux enregistrements de contexte de sécurité et séparant éventuellement les types d'enregistrement logiques en plusieurs enregistrements donc le contenu peut être contrôlé séparément. (Par exemple, si un enregistrement de produit comporte la description du produit, le prix et le coût de production dans l'enregistrement logique, la fonction de contexte de sécurité ne peut restreindre que l'accès à l'intégralité de l'enregistrement et non pas à des parties de celui-ci. De ce fait, si un client ne doit pas connaître le prix de production du produit, cette information doit se trouver dans un enregistrement distinct. Une telle séparation des schémas peut être très complexe et engendrer d'autres problèmes. Elle n'est donc pas conseillée.
L'administrateur de la sécurité effectue les étapes suivantes.
Les utilisateurs du client ne pourront voir que leur dossier de requêtes personnelles et le dossier CustFolder ainsi que les contenus de ces deux dossiers. Si le droit d'accès en lecture seule est affecté au dossier CustFolder, les utilisateurs du client ne pourront pas créer ou modifier le contenu et le dossier devra être géré par un autre groupe ayant le droit d'accès en lecture-écriture sur le dossier.
Si les utilisateurs du client disposent également du droit d'accès en lecture-écriture sur le dossier CustFolder, ils peuvent également créer ou modifier des éléments dans ce dossier, y compris créer des sous-dossiers et ainsi effectuer leur propre gestion dans le dossier.
Une variation du scénario précédent est de séparer les utilisateurs du client en deux groupes : un pour les utilisateurs normaux et un autre pouvant gérer le contenu du dossier du client. Cela permet d'utiliser le dossier CustFolder d'une manière similaire à l'utilisation par défaut des requêtes publiques : la plupart des utilisateurs ont un accès en lecture seule et certains utilisateurs sélectionnés disposent d'un accès en lecture/écriture.
Pour cela, l'administrateur de la sécurité effectue les étapes suivantes en plus de celles décrites ci-dessus.
Dans ce cas, les membres du groupe CustAdmin peuvent modifier le contenu du dossier CustFolder mais les utilisateurs qui ne sont membres que du groupe CustUsers ne le peuvent pas.
Un client (grande entreprise) peut avoir différents groupes internes devant avoir accès à une base de données ClearQuest interne. Dans cette situation, il existe deux possibilités : les groupes clients sont indépendants ou coopèrent.
Dans le premier cas, les deux groupes clients sont indépendants et n'ont pas nécessairement à être informés l'un de l'autre. Ils sont alors gérés comme deux clients totalement indépendants. Le seul véritable problème est le choix des noms à utiliser pour les groupes et les dossiers clients ClearQuest afin de ne pas laisser paraître qu'il existe plusieurs groupes. Cela peut être critique pour la règle de sécurité requise ou non. Par exemple, utiliser “Acme1” et “Acme2” suggère à l'utilisateur de l'un des deux groupes qu'il existe d'autres groupes “AcmeN”. Le choix de nom appropriés pour cette situation est laissé au lecteur en tant qu'exercice.
Dans le second cas, les groupes coopèrent et savent qu'ils utilisent la même base de données. Dans cette situation, les noms de groupes et de dossiers sont moins importants. Il existe plusieurs variations pouvant être utilisées pour ce cas, en fonction de la quantité d'informations à partager entre les groupes. Dans ce cas, chaque groupe, ou chaque administrateur de groupe, contrôle généralement son propre dossier client mais autorise un accès en en lecture seule pour l'autre groupe. Ce scénario nécessite 2 ou 4 groupes, selon si chaque groupe dispose d'un groupe spécifique pour l'administration (comme décrit dans la section précédente : Scénario de remplacement 3a : Gestion par le client de son propre dossier. Une autre variation peut être le partage du rôle d'administrateur entre les groupes. Cela n'est envisageable que si le flux de remplacement précédent est utilisé. Il permettrait ainsi de n'utiliser que 3 groupes ClearQuest au lieu de 4 : 2 pour les groupes clients et un pour l'administrateur commun.
Il s'agit d'une situation dans laquelle plusieurs clients sont impliqués dans un même projet et ont besoin de voir les mêmes données dans la base de données ClearQuest interne. Deux solutions sont possibles pour cette situation.