For example, user joe is given Product A, user jill is given Product B, and user jane has no read security value.
Consider this example:
The product_name attribute is designated as a read security attribute. User joe is given the read security value Product A, user jill is given Product B, and user jane has no read security value. When joe submits CR 123, the CR is automatically tagged product_name="Product A". Then, joe can access CR 123 through shows, searches, and reports because the CR read security attribute matches his value. Jill, however, cannot access CR 123. To her, this CR does not exist. However, Jane can access CR 123 because this user does not have a read security value restricting what she can see.
Read security provides a limited form of access control that predates access control lists (ACLs). ACLs govern read/write security and are typically administered at the group level. Read security is administered at the individual user level and governs only whether CRs are visible, not writable.
Read/write security features are administered from IBM Rational Directory Server. For more information about creating and managing groups and access permissions, see the IBM Rational Directory Server information center.
Groups are implemented and administered using the Rational Directory Server.
Before you implement read/write security, you might design and define your CR process, including lifecycles. The read/write security feature uses a combination of rules to implement security. See Planning read/write security rules.
After reading the design information, you can perform the following types of security customizations:
Information about using the group security features is also found in the Rational Directory Server Help.