Scenario 3: Customer access with Public Queries to internal user databases

The purpose of this scenario is to allow customer access to an internal ClearQuest database, to view records for their issues, submit new issues, and view other relevant public information.

It is often useful to allow customer access to an internal ClearQuest database, with the intent of allowing them to view records associated with their issues, submit new issues, and possibly see other public information that is not specific to any particular customer.

Scenario 3 context

A key aspect of this ability is that one customer cannot be allowed to see, or discover, the existence of any other customer information. They also cannot be allowed to see, or discover, the existence of any internal users or internal information.

It is important to note that workspace folder permissions are only part of the solution to achieving the above goal. Many ClearQuest schemas include records containing data that it might not be advisable for a customer to see.

The Security Context feature of Rational ClearQuest must be used to restrict visibility of which records are returned by a query. Workspace folder permissions do not restrict in any way what data is returned by a query. And workspace folder permissions do not in any way restrict the users ability to make private queries. Only the Security Context feature of Rational ClearQuest has the ability to restrict which records are returned from a query.

The schema developer would have to modify the record types provided by the schema, by adding references to Security Context records and possibly separating logical record types into multiple records where the logical content of each record can be controlled separately, in order to truly enable customer access to an internal user database. (For example, if a product record has the product description, price, and cost to produce in the logical record, the security context feature can only restrict access to the entire record, not pieces of the record. So if a customer is not to know the cost to produce the product, then that information must be on a separate record. Such separation of records can be quite complex and lead to other problems and is not recommended

Scenario 3 workflow

The Security Administrator performs the following steps.

  1. Creates a group for the customer users, CustUsers.
  2. Any users created for the customer are made members of only the customer group, CustUsers.
  3. Grants Read-Limited permission to CustUsers on the Public Queries folder.
  4. Creates a folder in Public Queries for the customer, CustFolder.
  5. Grants Read-Only or Read-Write permission to CustUsers on the CustFolder

The customer users would only be able to see their own Personal Queries folder and the CustFolder along with anything inside either folder. If Read-Only permission is granted to the CustFolder, then the customer users cannot create or modify any content and the folder would have to be managed by some other group that did have Read-Write permission on the folder.

If they also had Read-Write permission on CustFolder, they could create or modify things in that folder, including creation of subfolders, thereby doing their own management withing the folder.

Alternate scenario 3a: Customer management of their own folder

A variation of the previous scenario is to separate the customer users into two groups: one for normal users and another that would be able to administer the content of the customer folder. This would allow using CustFolder in a way that is similar to the default for Public Queries, i.e. where most users have read-only access and selected users have read-write access.

To achieve this, the Security Administrator performs the following steps in addition to what is outlined above.

  1. Creates a group for customer administrators, CustAdmin. Users created for the customer would be members of either CustUsers or CustAdmin, depending on their role. It may be further appropriate to have some users members of both groups.
  2. Grants Read-Limited permission to both CustAdmin and CustUsers on the Public Queries folder.
  3. Grants Read-Only permission to CustUsers on the CustFolder folder (no option for Read-Write as indicated in the previous scenario).
  4. Grants Read-Write permission to CustAdmin on the CustFolder folder.

In this case, members of CustAdmin could modify the content of CustFolder, but users that are members only of CustUsers could not.

Alternate scenario 3b: Multiple Customer Groups

A large customer may have different internal groups that need access to an internal ClearQuest database. In this situation, there are two cases: the customer groups are either independent or cooperating.

In the first case, the two customer groups are independent and should not necessarily know about each other. This would be handled the same as two completely independent customers. The only real issue is what names to use for the ClearQuest groups and customer folders such that there is no suspicion that there are multiple groups. This may or may not be critical to the required security policy. For example, using “Acme1” and “Acme2” would suggest to a user of only one or the other that there are any number of other “AcmeN” groups. Appropriate naming for this situation is left as an exercise for the reader.

In the second case, the groups are cooperating and are aware that each is using the same database. In this situation the group and folder names are less important. There are several variations that could be used for this case, depending on how much sharing between the groups is desired. The typical case would be where each group, or each group’s administrator, controls its own customer folder, but allows the other group to have Read-Only access. This would require either 2 or 4 groups, depending on whether each group had a separate group for administration (as outlined in the previous section: Alternate scenario 3a: Customer management of their own folder. Another variation would be for the groups to share the administration role. This only makes sense if the previous alternate flow is used; it would allow using only 3 ClearQuest groups instead of 4: 2 for the customer groups and one for a common administrator.

Alternate scenario 3c: Cooperating Customers

This is a situation where more than one customer is involved with a single project and they both need to see the same data in the internal ClearQuest database. This can be addressed it two ways.



Feedback