4.8 Metamodel Access Control

Access rights can be set on all metamodel elements, including classes, behavior models, and property pages. For more information on creating Metamodel elements, see the Operations Center 5.6 Service Modeling Guide.

Access rights to Service Model elements is discussed in Section 4.9, Service Models Access Control.

Figure 4-7 Metamodel Elements in the Explorer Pane

Some general rules regarding these components:

  • Access rights are inherited by elements within the Metamodel hierarchy. However, access rights explicitly set on an element override any inherited permissions.

  • To access a property page, a user must have access rights to both the element and the property page. If a user has access rights to only one property page for a behavior model that has multiple property pages, the user can access only that property page for elements to which he or she has access rights.

  • A user who has access rights to a subclass, but does not have access rights to the parent class, can access the subclass and its child elements, but cannot access the parent class.

To set access rights, review the following sections:

4.8.1 Setting Access Rights for Classes and Behavior Models

Every class and behavior model inherits the security of its parent unless additional security is specified. Modify access privileges for these elements by using the Access Control panel in the Portal view or the Access Control property page.

You use the Class Model Access Control property page to specify the access privileges for groups and users who attempt to access the class:

Figure 4-8 Class Element Access Control Property Page

4.8.2 Setting Access Rights for Property Pages

The access rights set on custom property pages in the Metamodel hierarchy determine which property pages a user can access and the level of access, such as View or Manage.

Rules for Property Page Access

To determine which property pages a user can access, the following rules apply in the order specified:

1. Check Behavior Model Permissions

To access a property page, a user must have access rights to the associated behavior model and class. When a user tries to access a custom property page, the system first checks behavior model permissions:

  • It finds all explicitly matched behavior models. If a user does not have View or Manage rights for the behavior model, the user cannot access any of the property pages.

  • It finds all behavior models related to the Service Model element’s class, including behavior models related to any parent class or root element (such as Enterprise or Administration).

    • If the user does not have View or Manage rights for the class, the user cannot access any of the matched behavior models/property pages.

    • If permissions are not set explicitly on a matched behavior model, the behavior model permissions are determined by traversing the hierarchy up to the root element (such as Enterprise or Administration) until a permission is found.

    • If multiple permissions are inherited for a given behavior model, the most restrictive permission is used.

2. Check Property Page Permissions

When a user requests to view a property page, the system locates all the related property pages for all matched behavior models for which the user has a minimum of View access rights. The following rules apply:

  • If access rights are not set explicitly on a property page, the access rights of the related behavior model are used.

  • If access rights are not set explicitly on a property page or behavior model, the class permissions are used.

Example of Applying Metamodel Access Rights

It might be helpful to step through an example showing how inherited access rights apply to different types of metamodel components. Custom property pages can be assigned to elements in the Service Models hierarchy. Inherited access rights from the relevant class and behavior model apply to the custom property pages that are attached to a service model element.

Assume the Service Models hierarchy is as follows:

  • Service Models
  •      Router2 (Not matched using the Routers behavior model)
  •      Routers
  •           Router1 (Matched using the Routers behavior model)

Table 4-2 lists the access rights for two groups of users for a class, behavior model, and custom property page:

Table 4-2 Access Rights for IT Managers and Users

Access Rights Set On

For IT Managers

For IT Users

Class - Router

Define

View

Behavior Model – Routers

Define

View

Property Page – Leasing

None

None

These settings have different results when different users try to access a router class element’s property pages:

  • When an IT Manager accesses the Router1 or Router2 element, the Router Leasing property page displays and the user can enter new property values. This is because access rights are not set explicitly on a property page, so the Define behavior model permissions are used.

  • When an IT user accesses Router1 or Router2, the Router Leasing property page displays, but users are not allowed to update the property values. This is because access rights are not set explicitly on a property page, so the View behavior model permissions are used.

  • When users who are not IT managers or IT users access Router1 or Router2, they do not see any of the Router Leasing property pages. This is because View or Manage rights for the Router class are not defined for any other user groups. These other users cannot access any of the matched Routers behavior models/property pages.

Setting Permissions for Property Pages

Another security parameter specifies access rights to different users or groups who access a custom property page. For example, you can allow any user to view a property page, but allow only specific groups to edit/update the properties.

The following steps describe two scenarios for the process you can use to establish different property page permissions:

Scenario 1: Creating a Custom Property Page with Properties

To create a property page:

  1. In the Explorer page, click Administration > MetaModel > Property Pages.

  2. Right-click Property Pages and select Create Property Page. The Create Property Page dialog box opens.

    All users can view and update this page and its properties.

    For detailed steps on creating property pages, see the Operations Center 5.6 Service Modeling Guide.

  3. Specify a Display Name for the property page.

    The display name can be different from the page Name. It is visible to all users who view the property page.

  4. Add properties, as necessary.

  5. Click Create.

    The new property page displays in the Explorer pane under Administration > Metamodel > Property Pages.

Scenario 1: Modifying the Access Privileges for the Property Page

To modify access privileges for the property page:

  1. Right-click the property page that you just created and select Properties.

  2. In the left pane, click Access Control.

    The inherited permissions for the property page display in the right pane:

  3. Modify the access rights for the new property page. For example, select a group and specify View or Manage only to establish read-only or read-write access to the associated properties.

    Editing the Access Control property page is the same as editing an element’s access control page, described in Section 4.5.1, Assigning Privileges to Elements.

  4. Click Apply.

Scenario 2: General Steps

A variation of Scenario 1 is to establish different access rights for multiple properties on the same property page. For example, Group A can update two properties but only view the remaining properties. Group B can update one property but not view any other properties.

To manage this scenario, you need to create variations of a property page for each group of intended users. The general steps are:

  1. Create the property page with all properties.

  2. Use the Copy, Paste, and Rename commands to create additional pages.

  3. To modify these pages for each intended user group, modify or remove properties, then set the access control rights to the property page.

  4. Create a behavior model and add each property page. The intended users for each property page have access as defined for the properties on the property pages.

    Create a behavior model and add each property page. The intended users for each property page have access as defined for the properties on the property pages.

Scenario 2: Creating the Master Property Page

To create the master property page:

  1. Create a property page or use the property page created in the previous scenario.

  2. Specify a display name for the property page that you want to display to all users. This name does not change among the copied property pages that you will create.

  3. Add all properties relevant to the property page.

  4. Click Create.

    The new property page displays in the Explorer pane under Administration > Metamodel > Property Pages.

By default, the new property page inherits the access control rights set for its parent, the Property Pages element. To change the access rights for the new property page, see Section 4.5.1, Assigning Privileges to Elements.

Scenario 2: Making a Copy of a Property Page and Renaming It

Now use the Copy and Paste commands to create a variation of this property page. You can then change the properties and access rights to the page.

To make a copy of the property page and rename it:

  1. In the Explorer pane, right-click the new property page and select Copy.

  2. Right-click the Property Pages element and select Paste. The copied property page has the same name as the original, with (1) appended.

  3. Right-click the copied page and select Rename.

    Specify the new name and click OK. The new name displays.

    Use a name that identifies the intended users, to help you identify the appropriate properties to use on the property page.

Scenario 2: Modifying the Properties and Access Rights for the Copied Property Page

  1. Right-click the copied property page and select Properties. The property pages display.

  2. Remove or modify the properties that you want to display to intended users.

    For example, if the Auditors group should not view some properties, remove them from this property page. Leave the properties that they can edit.

    Do not modify the Display Name. This maintains a link to the original property page.

  3. In the left pane, click Access Control.

    The property page updates to show the existing access rights.

    By default, the new property page inherits the access control rights set for its parent, the Property Pages element.

  4. Modify the access rights for users and groups. Editing the Access Control property page is similar to editing access rights for elements, as described in Section 4.5.1, Assigning Privileges to Elements. See this section for detailed steps.

  5. Click Apply.

  6. If necessary, copy and modify additional property pages.

  7. Create a behavior model.

  8. Add each property page to the behavior model.

    The intended users for each property page have access, as defined, to the properties on the property pages.