When you enable multi-tenancy, you can grant each contact access to all tenants (public), a single tenant, or a tenant group (user-defined or product-maintained). The role for a contact controls access, which specifies read and write access independently.
Note: For more information about creating a user role and assigning a role to a user, see the Administration Guide.
If multi-tenancy is enabled, most CA APM objects include a tenant attribute that specifies the tenant that owns the object. Objects are categorized into three groups, depending on their tenant attribute and how the object is used:
Defines objects without a tenant attribute. All data in these objects is public, and any user can create and update untenanted public data.
Defines objects with a tenant attribute that cannot be null (enforced by CA APM, not the DBMS). All data in these objects is associated with individual tenants; there is no public data.
Defines objects with a tenant attribute that can be null. You can either create these objects as tenanted or public. When you select a tenant in a tenant drop-down to create an object, the object becomes a tenanted object. However, when you select the Public Data option in a tenant drop-down, the object becomes a tenanted public object. Users assigned to a role that only exposes a single tenant do not see a tenant drop-down when entering data.
When a user queries the database, the product restricts the results to objects belonging to tenants that the user is authorized to access. As a result, you never see data in tenant required tables except for the data that belongs to tenants that you are permitted to access. If the data is tenanted public data, you can see the data in tenant optional tables because the data is also public data.
When a tenant user asks to create or update a database object, the product verifies that the object belongs to a tenant that the current role for the user can update. The product also verifies that all references from the object to other objects are to public (untenanted) objects, to objects from the same tenant, or to objects from tenants in the tenant hierarchy above the tenant for the object. That is, a tenanted object is allowed to reference objects belonging to its parent tenant, to the parent of the parent, and so on.
If a user who creates an object has update access to multiple tenants, the user must specify the tenant explicitly, either directly or indirectly.
Note: The referenced objects restriction has one exception. Certain references are permitted to reference objects that belong to tenants in the tenant hierarchy of their containing object. These references are designated as SERVICE_PROVIDER_ELIGIBLE in the CA APM object schema. The SERVICE_PROVIDER_ELIGIBLE setting makes a difference only if the service provider tenant is not in the tenant hierarchy above the tenant for the object; if the service provider tenant is in the hierarchy, tenant validation rules permit service provider references.
A service provider user asking to create or update an object is subject to the same restrictions as tenant users, except that service provider users can be authorized to create or update tenanted public objects. The defined role of the service provider user controls this authorization. A service provider user with authorization to multiple tenants who is creating a tenanted object must specify the tenant directly or indirectly.
|
Copyright © 2013 CA.
All rights reserved.
|
|