How Multi-Tenancy Works

This article contains the following topics:
casm173
This article contains the following topics:
After enabling CA SDM multi-tenancy, you can grant contacts access to all tenants (public), a single tenant, or a tenant group (user-defined or product-maintained). A contacts role controls access and specifies the read-write access independently. As the tenant access is role-dependent and a contact can modify roles during a session, contact tenant access is also subject to change.
Most of the CA SDM objects when multi-tenancy is installed include a tenant attribute to specify owner of the object. Objects fall into three groups, depending on their tenant attribute and how it is used:
Untenanted
Defines objects without a tenant attribute. All data in these objects is public.
Examples:
Priority and urgency.
Tenant Required
Defines objects with a tenant attribute that cannot be null (enforced by CA SDM, not the DBMS). All data in these objects is associated with individual tenants; there is no public data.
Examples:
Ticket tables (Request, Issue, and Change Order).
Tenant Optional
Defines objects with a tenant attribute that can be null. Some of the data in these objects is public, and some is associated with specific tenants. Each tenant's view of the object is a merged view of the public data and their tenant-specific data.
Examples:
Category and location.
When a user queries the database, CA SDM restricts the results to objects belonging to tenants. The user is authorized to access these tenants. This restriction applies in addition to any data partition restrictions that are in effect.
If a user creates an object with update access to multiple tenants, the user must specify the tenant explicitly.
Few SREL references (such as the assignee of an incident) are permitted to reference objects that belong to tenants in their containing object's tenant hierarchy. Such references are designated as SERVICE_PROVIDER_ELIGIBLE in the CA SDM object schema (the Majic). The SERVICE_PROVIDER_ELIGIBLE flag makes a difference only if the service provider tenant is not in the tenant hierarchy; if the service provider tenant is in the hierarchy, tenant validation rules permit service provider references.
If CA SDM limits a user from updating tenant data, an error message can announce a data partition limitation. If you receive this error message, either data partition or multi-tenancy restrictions are in effect.
The Multi-Tenancy Option
You activate multi-tenancy by installing one of the following multi-tenancy options:
When tenancy is in setup mode, do not perform any transactions on the server as this may lead to data loss. Before performing any operations or transactions, it's recommended that you complete the task of creating tenants and set it to ON state.
  • Off
    -- Multi-tenancy is not in use. Multi-tenancy features are not available, and objects do not have a tenant attribute. This option is the default setting at a new CA SDM installation.
  • Setup
    -- Multi-tenancy features are in effect for administrators, so that tenant-related objects and attributes are visible and editable. However, CA SDM does not enforce tenancy restrictions, and non-administrator users see no changes. This setting allows an administrator to prepare for multi-tenancy by performing such tasks as defining tenants or assigning objects to tenants without impacting normal use of CA SDM.
  • On
    -- Multi-tenancy is fully operational. All users see the UI changes appropriate to them, and CA SDM enforces tenancy restrictions.
    Recommendation is to create tenants in setup mode and make multi tenancy to ON state before performing operations.
Tenant Information
You create and update tenants when you install multi-tenancy (in either setup or full enforcement mode). Information that is maintained for a tenant is similar to the data maintained for Organization, except for the following two attributes:
  • Logo
    Provides a URL to an image file with the logo of the tenant. The logo is shown both on the Tenant Detail page itself, and as a substitute for the CA logo on web forms that are displayed by a tenant user or showing an object that is associated with the tenant.
  • Service Provider
    Indicates whether the tenant is the service provider. The service provider tenant is always the first tenant added. When the administrator adds the first tenant:
    • The first tenant becomes the service provider. This designation cannot be changed.
    • The privileged user (usually ServiceDesk) and all system contacts (such as System_AHD_Generated) are set to belong to the new service provider tenant.
      The system user "Administrator" is added in Windows only and is not assigned a tenant. The privileged user must assign a tenant to Administrator manually.
Tenant Access
The role of a CA SDM user governs both access authorization and the user interface. The set of roles available to users depends on their access type. Multi-tenancy lets you control the tenant or tenant group that a user can access within the role.
The Role Detail page provides Tenant Access and Tenant Write Access drop-down lists on its Authorization tab. Tenant Access is view-only, and Tenant Write Access also allows create and update.
You can assign the following associations to roles:
  • Same As Tenant Access (Tenant Write Access Only)
    Sets Tenant Write Access to be the same as the Tenant Access setting. Default for Tenant Write Access and only valid for Tenant Write Access.
  • All Tenants
    Removes tenant restrictions. CA SDM allows a user in a role with this access to view any object in the database (read access) or create and update (write access) any tenanted object in the database. When users with All Tenant access create an object, CA SDM requires that they select the tenant of the new object.
  • Single Tenant
    Sets a role's tenant access to a named tenant. When this option is selected, a second field appears on the web UI that allows selection of a specific tenant. CA SDM restricts a user in a role with this access to view (read access) or create and update (write access) only those objects that are associated with the named tenant. This selection is valid for either Tenant Access or Tenant Write Access.
  • Tenant Group
    Sets a role's tenant access to a user-defined or system-maintained tenant group. When the Tenant Group option is selected, a second field appears on the web UI that allows selection of a specific tenant group. CA SDM restricts a user with the role to view (read access) or create and update (write access) only those objects that are associated with one of the tenants in the group. When a user with tenant group access creates an object, CA SDM requires that they select the tenant for the new object. This selection is valid for either Tenant Access or Tenant Write Access.
  • Contact's Tenant
    Sets a role's tenant access to the tenant of the contact using it. CA SDM restricts a user in a role with this access to view (read access) or create and update (write access) only those objects that are associated with their own tenant. This selection is valid for either Tenant Access or Tenant Write Access.
  • Contact's Tenant Group (Analyst Only)
    Sets an analyst's role access to the tenant group that the analyst works with, as specified on the analyst's contact record. If the user with the role is not an analyst, this selection has the same effect as Contact's Tenant. It is valid for either Tenant Access or Tenant Write Access.
  • Contact's Subtenant Group
    Sets a role's tenant access to the Subtenant group of the contact using it. CA SDM restricts a user in a role with this access to view (read access) or create and update (write access) only those objects that are associated with their own Subtenant group. This selection is valid for either Tenant Access or Tenant Write Access.
  • Contact's Supertenant Group
    Sets a role's tenant access to the Supertenant group of the contact using it. CA SDM restricts a user in a role with this access to view (read access) or create and update (write access) only those objects that are associated with their own Supertenant group. This selection is valid for either Tenant Access or Tenant Write Access.
  • Contact's Related Tenant Group
    Sets a role's tenant access to the Related Tenants Group of the contact using it. CA SDM restricts a user in a role with this access to view (read access) or create and update (write access) only those objects that are associated with their own Related Tenants Group. This selection is valid for either Tenant Access or Tenant Write Access.
All users can view public data, regardless of their current role's access rights. The Update Public check box controls whether a service provider user in the role has the authorization to create or update public data. The Tenant users (users belonging to a tenant other than the service provider) cannot update public data, regardless of their role.
Edit Tenant Access for a Role
The role of a CA SDM user governs both access authorization and the user interface. The set of roles available to users depends on their access type. Multi-tenancy lets you control the tenant or tenant group that a user can access within the role.
The Role Detail page provides Tenant Access and Tenant Write Access drop-down lists on its Authorization tab. Tenant Access is view-only, and Tenant Write Access also allows create and update.
You can assign or edit tenant access for a role.
Follow these steps
  1. Navigate to Security and Role Management, Role Management, Role List.
  2. Click a role and click Edit.
  3. Select options for Tenant Access and Tenant Write Access.
    Note:
    Exercise caution if you select different options for these settings.
  4. Click Save.
    The updated tenant access options are saved for the role.
Tenant Terms of Usage
An end user is presented with a terms of usage statement while logging in the CA SDM application. The terms of usage statement is regarding proper usage, terms and conditions of using the product by the end user. The user must agree to the terms before logging to CA SDM. Entries are written to the standard log and in the user event log after the attempted session login.
You can perform the following terms of usage actions:
  • Create, update, and delete a terms of usage statement.
  • Associate a terms of usage statement with a tenant.
    You must enable multi-tenancy and configure one or more tenants before associating a terms of usage statement with a tenant.
  • Force the end user to accept the statement every time they log in.
  • Let the end user ignore the initial statement by presenting a blank terms of usage statement.
For more information about creating terms of usage statement, see Setting Up Terms of Usage.
How to Configure Terms of Usage
The terms of usage statement presents the end user with an initial page statement when they log in to CA SDM. The statement reminds the user about the proper use of the product. The user must agree to the terms before they can continue to log in to CA SDM. If the end user selects Accept, CA SDM proceeds with the login and displays the main form. If the user selects Reject, CA SDM returns to the login. Entries are written to the standard log and in the user event log after the attempted session login.
Typically, you configure the contact tenant terms of usage statement. If the contact tenant is configured with an inactive terms of usage statement, the terms of usage is not configured, or if <empty> is selected in the Terms of Usage drop-down list, CA SDM displays the terms of usage statement for the tenants parent, grandparent, and so on. If no terms of usage statement is found at any level, CA SDM proceeds with the login. If you configure a tenant with a blank terms of usage statement, CA SDM proceeds with the login and displays the main form.
You can configure terms of usage as follows: