Using Roles for Access Control

As described in the previous section, you can use principals such as roles to secure access to the ACC, to the Business Control Center, and to repository objects. You can also use global roles in combination with access rights to secure access to various parts of your Web application UI. For example, you might have several pages on your sites that can be used to edit a customer’s profile, and you want to make these available only to customer service representatives. You can set up a global role called Customer Service Rep and add an access right to that role that allows entry to the specified site pages. Any user who is assigned that role, either directly or though membership of an organization, can access the appropriate pages.

As well as assigning access rights to global roles to secure the pages of a Web UI, you can also use access rights with roles to perform access control of repository objects (for example, workflows). For example, you could assign access rights to an organizational role, and configure a security check that compared the organization associated with an object against the organization associated with the organizational role. As described earlier, you can control access to objects by assigning an access control list (ACL) that can include a role as a principal. However, doing so requires you to set the ACL individually for each object. Assigning access rights to roles as described in this section allows you to design a security system in which access for multiple objects can be set at once. ATG Service uses an implementation similar to this to secure access to solutions.

The rest of this section contains the following information:

Using Global Roles to Control Access to UI Pages

UI access rights that you assign through global roles work as follows:

  1. In the internal user profile repository, you create an accessRight repository item that corresponds to some functional aspect of your sites that you want to secure. For example, you could set up an access right item called Edit Customer Profiles to be applied to any page that allows users to change a customer’s profile information.

  2. You configure an AccessRightAccessController component (class atg.userprofiling.AccessRightAccessController) that specifies the Edit Customer Profiles repository item you created in step 1.

  3. You configure an AccessControlServlet component (class atg.userprofiling.AccessControlServlet) whose accessControllers property specifies the pages to which the Edit Customer Profiles access controller should apply.

  4. In the ATG Control Center, you add the Edit Customer Profiles access right to one or more global roles, and you assign those roles to individual users. When a user attempts to display any of the pages specified in the AccessControlServlet as requiring the Edit Customer Profile access right, a security check is performed to verify that the user’s profile contains the appropriate role.

The following examples show typical contents of the property files for the two components you set up:

EditCustomerProfilesAccessRightController.properties:

$class=atg.userprofiling.AccessRightAccessController
$scope=global

accessRightsPropertyName=accessRights
accessRightNamePropertyName=name
allowedAccessRightNames=edit_customer_profiles

deniedAccessURL=/MY-APP/en/accessdenied.jsp

Note: The deniedAccessURL specifies the page to display if the user fails the security check. This property can also be specified in the AccessControlServlet (see below), but defining it in the AccessController helps to eliminate conflicts in cases where more than one application is running.

AccessControlServlet.properties:

$class=atg.userprofiling.AccessControlServlet

profilePath^=ProfileRequestServlet.profilePath

enabled=true

# List of mappings between paths and AccessController objects.  If a
# path refers to a directory, all the documents in that directory and
# its subdirectories will be protected by the given AccessController.

accessControllers+=\
  /MY-WEB-APP/en/edit_address.jsp=/atg/mymodule/
   EditCustomerProfileAccessRightController,\
  /MY-WEB-APP/en/edit_username.jsp=/atg/mymodule/
   EditCustomerProfileAccessRightController

# Default deniedAccessURL to use if an AccessController
# doesn't supply one
deniedAccessURL=

#loggingDebug=true

The item descriptor for the accessRights repository item is shown below:

<item-descriptor name="accessRight" sub-type-property="type"
id-space-name="internalAccessRight"
display-name-resource="itemDescriptorAccessRight"
  display-property="name" item-cache-size="1000" query-cache-size="1000"
version-property="version">
  <attribute name="resourceBundle"
   value="atg.userprofiling.InternalUserProfileTemplateResources"/>

    <table name="dpi_access_right" type="primary"
      id-column-name="access_right_id">
      <property name="name" column-name="name" data-type="string"
          required="true"
          display-name-resource="rightName">
          <attribute name="propertySortPriority" value="10"/>
      </property>
      <property name="version" column-name="version" data-type="int"
          writable="false" expert="true" display-name-resource="version">
          <attribute name="propertySortPriority" value="60"/>
      </property>
      <property name="description" column-name="description" data-type="string"
          display-name-resource="rightDescription">
          <attribute name="propertySortPriority" value="30"/>
      </property>
      <property name="scope" column-name="right_scope" required="true"
          data-type="enumerated"
          display-name-resource="scope">
          <attribute name="propertySortPriority" value="40"/>
          <option value="global" code="1"/>
          <option value="organization" code="2"/>
      </property>
      <property name="type" column-name="right_type" required="true"
          data-type="enumerated" default="generic"
          display-name-resource="rightType">
          <attribute name="uiwritable" value="false"/>
          <attribute name="propertySortPriority" value="80"/>
          <option value="generic" code="1"/>
      </property>

    </table>
  </item-descriptor>
Adding Access Rights to a Role

As indicated elsewhere in this chapter, inheritance plays an important part in the way roles and organizations work. Access rights that you grant to a role that is assigned to a parent organization are automatically inherited by any dependent organizations. Before you assign access rights to roles, make sure you have a clear understanding of the parent/child relationships among the entities in your user directory.

To use the ACC to add access rights to a role, complete the following steps:

  1. Display the Roles window (select People and Organizations > Roles).

  2. In the list in the left pane, select the role (either global or organizational) to which you want to add access rights. For information on the difference between the two types of role, see User Directory Architecture.

  3. Display the Profile tab for the role.

  4. Click the button in the Direct Access Rights field. The Direct Access Rights dialog box appears. Note: If the field does not appear, check that you have started your application with a module that supports adding access rights through the ATG Control Center.

  5. Click Add. The New Item dialog box appears.

  6. Specify Items of Type Access Right as the query, and click List. All existing access rights appear.

  7. Select the access rights you want to add for this role.

  8. Click OK to return to the Direct Access Rights dialog box.

  9. Click OK again.

Note: To see a brief description of an access right, complete the steps in the procedure as far as step 8. If you double-click the name of an access right in the Direct Access Rights dialog box, its properties, including the Description field, are displayed.

Using Roles as Templates for Adding Access Rights

In cases where you need to define access rights for a large number of roles, you can save time by adding the rights to one role and then using that role as a template. Example: You have 20 organizations called Product 1, Product 2, Product 3, and so on. You have forty corresponding organizational roles for Author and Reviewer (for example, Product 1 Author, Product 1 Reviewer, Product 2 Author, Product 2 Reviewer). You want to assign the same access rights to all the Product n Reviewer roles. To do so quickly, you can set up a role called Reviewer, define the access rights for it, and then use it as a template for the appropriate organizational roles.

Rights that you add through template roles are cumulative with rights added through the Direct Access Rights field described in the previous section. This behavior allows you to use a combination technique where you can assign shared rights through role templates and define rights that are unique to a role through the Direct Access Rights field.

You can use both global and organizational roles as templates for any type of role. Note that only the role’s access rights are inherited by the non-template role; no other properties of the template role are acquired.

To use a global role as a template for adding access rights:

  1. Add the required access rights to the role you want to use as a template. Follow the procedure in the previous section, Adding Access Rights to a Role.

  2. Select or create the first role to which you want to apply the template, and display the Profile tab for that role.

  3. In the templateRoles field, click the button. The Template Roles dialog box appears.

  4. Click Add. The New Item dialog box appears.

  5. Specify Items of Type Role as the query, and click List. All roles in your system appear.

  6. Select the role you want to use as the template. (Note that you can select multiple roles if you want to add access rights from more than one template role.)

  7. Click OK to return to the Template Roles dialog box.

  8. Click OK.

  9. Repeat steps 2 to 8 for other non-template roles.

  10. Select File > Save when you have finished.

Copyright © 1997, 2012 Oracle and/or its affiliates. All rights reserved.

Legal Notices