Oracle Waveset 8.1.1 Deployment Guide

Chapter 2 Working with Authorization Types

This chapter presents a conceptual overview of authorization types (AuthTypes) as used in Waveset deployments. Topics in this chapter include

What are Authorization Types?

Waveset provides authorization types as a mechanism for assigning authorization rights to objects without requiring code changes. This extensible mechanism is independent of the repository storage type, and is especially useful for TaskDefinition and Configuration objects. Although these objects share the same repository type, each object type can perform different functions that consequently require different authorization policies. For example, rules must have an authorization type of UserMembersRule to appear in the User Members Rules drop-down list. Both default and custom authorization types reside in the Configuration:AuthorizationTypes object.

Authorization types are repository-type independent, which means that you can define one authorization type and assign it to, for example, both Configuration and Rule objects. This allows you to use authorization types to filter lists of objects of a single type, or as a means of granting access to a related set of objects to a subset of Waveset administrators with a specific capability.

How Waveset Uses Authorization Types

Waveset uses authorization types during access checks when comparing the caller’s capabilities against an object’s authorization type. When an authorization type extends an existing repository type, access control follows the implied ’inheritance’ change. Specifically, if an administrator has rights on the parent type, he has the same rights on the child type. However, if an administrator has rights on the child type, but no rights on the parent, then the administrator can access objects of the child type only.

For example, consider the following authorization types, administrators and objects:

Authorization settings:

Configuration   (repository type)
<AuthType name=’Fruit’ extends=’Configuration’/>
<AuthType name=’Vegetable’ extends=’Configuration’/>

Rights are assigned as follows:

AdminA (has Right.VIEW on Configuration)

AdminB (has Right.VIEW on Fruit)

AdminC (has Right.VIEW on Vegetable)

ObjectA of type Configuration, no authtype

ObjectB of type Configuration, authtype == Fruit

ObjectC of type Configuration, authtype == Vegetable

The preceding authorization settings determine the following access privileges on the specified objects:

AdminA can view ObjectA, ObjectB and ObjectC
AdminB can view ObjectB only
AdminC can view ObjectC only

Why Use Authorization Types?

You use authorization types within your deployment to accomplish the following:

Restrict a list of a single type of objects to those specific for a purpose (very similar to SubType). For example, <AuthType name=’foo’ extends=’moo’/>
Group objects of different types to make them available to a specific class of administrators. For example, <AuthType name=’foo’ extends=’red,green,blue’/>

Using Authorization Types

Authorization Type (AuthType) objects are members of the Configuration:AuthorizationTypes objects. An AuthType object can be assigned directly by an authType attribute member of a persistent object or indirectly through an AdminGroup (described below).

Configuration:AuthorizationTypes Object

The Configuration:AuthorizationTypes object defines valid authorization types. Each authorization type is declared in an <AuthType> element:

<AuthType name=’SPML’ extends=’Configuration’/>

The AuthTypes element contains a list of AuthType elements. Each AuthType has, at minimum, a name attribute and typically an extends attribute. The value of the extends attribute must be the name of another authorization type or repository type.

You can add or remove authorization types by modifying this object. You can modify the Configuration:AuthorizationTypes only by editing its XML representation.

AuthType Element

This element requires the name property. The example below displays the correct syntax for an <AuthType> element. The following example shows how to add a custom task to move multiple users into a new organization.

<Configuration name=’AuthorizationTypes’>
   <Extension>
      <AuthTypes>
         <AuthType name=’Move User’ extends=’TaskDefinition,TaskInstance,TaskTemplate’/>
      </AuthTypes>
   </Extension>
</Configuration>

The AuthType element supports the following attributes.

Table 2–1 AuthType Attributes


AuthType Object Attributes	Description
`name`	Identifies the authorization type.
`extends`	Specifies the name of one or more authorization types or repository types that become the supertype of this type. Rights granted by the supertype are inherited.
`displayName`	Provides an alternate display name for this type, typically a message catalog key.
`auditKey`	Identifies the audit log key to be used for audit records associated with objects of this type. If none is specified, the audit key of the base type is used.
`allowedRights`	Provides a comma delimited list of right names. This defines the rights that can be used with this authorization type in a permission definition. If not specified, all rights are allowed.

Authorization Types and Capabilities

Authorization types are a key component of the End User authorization model. With authorization types, you can define capabilities, or AdminGroups, and then assign those capabilities to users.

AdminGroups Objects

After defining an authorization type, you can reference it in the Permission objects stored within AdminGroup objects. The following XML example defines an AdminGroup (called a capability) that you can assign to a user.

<AdminGroup name=’EndUser’>
   <Permissions>
       <Permission type=’EndUserTask’ rights=’View’/>
       <Permission type=’EndUserRule’ rights=’View’/>
   </Permissions>
 <MemberObjectGroups>
 <ObjectRef type=’ObjectGroup’ id=’#ID#All’ name=’All’/>
 </MemberObjectGroups>
</AdminGroup>

In this example, the two Permission elements both use type names that are authorization types rather than repository types. Only TaskDefinition objects that are assigned an EndUserTask authorization type will be accessible to a user that holds this capability. (A capability conveys set of rights to one or more authorization types or repository types.) Because authorization types are essentially hierarchical with other authorization types and repository types, having rights on a parent in the “type hierarchy” grants the same rights to all children.

EndUser Capability

You can use the AdminGroup EndUser capability to assign permissions to non-administrative users that typically do not have assigned capabilities and do not control any organizations. The default definition of this capability was given in the example in the Permission Extensions section.

Waveset implicitly assigns all users the EndUser capability. This capability permits users to view several types of objects, including tasks, rules, roles, and resources. Although you can assign capabilities to end users, you may prefer not to. Waveset defines a user with explicitly assigned capabilities as an administrator, and the system caches information about administrators that results in an effective upper limit on the number of administrators an installation can have.

You can use the EndUserLibrary authorization type. The EndUser capability (or AdminGroup) has List and View access to Libraries with the EndUserLibrary authType.

To give users access to the contents of a Library, set authType=’EndUserLibrary’ and ensure that the Library’s MemberObjectGroup is set to All.

Creating an Authorization Type

You can create a new authorization type by extending the existing TaskDefinition, TaskInstance, and TaskTemplate authorization types. You can use one of the following methods to add an authorization type:

Create a new authorization type using the <AuthType> element.
Edit the Authorization Types Configuration object in the repository by adding the new authorization type element (AuthType) for your task.

Assigning an Authorization Type to a Repository

By setting an authorization type on a respiratory, you can restrict which users can see, modify, or delete particular object types. To define an authorization type for a repository type, set the authorization type name to the name of a repository type and omit the extends attribute.

Example: Setting End-User Authorization Types

Waveset implements the User Admin role and assigns it to all users by default. This role encapsulates the EndUser AdminGroup that provides two end-user authorization types (AuthTypes) and several list permissions for various object types.

These end-user authorization types include:

EndUserRule. Allows access to rule objects that have the EndUserRule AuthType specified in the object, as follows:
```
<Rule authType=’EndUserRule’ ...>
```
EndUserTask. Allows access to TaskDefinition objects that have the EndUserTask AuthType specified in the object, as follows:
```
<TaskDefinition authType=’EndUserTask’ ...>
```
EndUserLibrary. Allows access to the contents of a Library object.

To implement this AuthType, set the AuthType to EndUserLibrary and ensure the Library’s MemberObjectGroup is All. (The EndUser capability (AdminGroup) has List and View access to Libraries whose authorization type is EndUserLibrary.)

Example: Using Authorization Types to Restrict Visibility on Resources

You can use authorization types to restrict visibility on resources on the resource level. Rather than move resources into special organizations, you can

Define an authorization type for each resource (for example, Resource-Corporate-LDAP)
Build capabilities with rights for those resource types

When assigning capabilities to users, do not assign a capability that includes rights to a generic resource type. Instead, assign users a capability with rights for a specific resource type.

Note –

For an example of stock authorization types defined in the system, see the admingroups.xml file.

To Define a Resource-Specific Authorization Type

Add an entry to Configuration:AuthorizationTypes object.

<AuthType name=’Resource-Corporate-LDAP’ extends=’Resource’/>

Derive a variant of one of the standard capabilities, such as Resource Administrator. Note that the only difference between this capability and the standard AdminGroup is the type name in the Permission, which is Resource-Corporate-LDAP instead of Resource.

<AdminGroup name=’Corporate LDAP Resource Administrator’
           protected=’true’
           displayName=’UI_ADMINGROUP_RESOURCE_ADMIN’
           description=’UI_ADMINGROUP_RESOURCE_ADMIN_DESCRIPTION’>
   <AdminGroups>
       <ObjectRef type=’AdminGroup’ id=’#ID#Resource Group Administrator’/>
       <ObjectRef type=’AdminGroup’ id=’#ID#Resource Report Administrator’/>
       <ObjectRef type=’AdminGroup’ id=’#ID#Connect Organizations’/>
       <ObjectRef type=’AdminGroup’ id=’#ID#Connect Policies’/>
   </AdminGroups>
   <Permissions>
       <Permission type=’AttributeDefinition’ rights=’View’/>
       <Permission type=’Resource-Corporate-LDAP’ rights=’View,List,Create,Modify,Delete,Execute’/>
       <Permission type=’ResourceUIConfig’ rights=’Create,Modify’/>
       <Permission type=’Rule’ rights=’View’/>
       <Permission type=’User’ rights=’View,List’/>
   </Permissions>
   <MemberObjectGroups>
       <ObjectRef type=’ObjectGroup’ id=’#ID#All’ name=’All’/>
   </MemberObjectGroups>
</AdminGroup>
<ObjectRef type=’AdminGroup’ id=’#ID#Connect Resource Groups’/>

Example: Granting Access to a Specific Part of Waveset

You can also use authorization types to grant fine-grained administrative control of a very specific part of Waveset to a set of users.

You create an AuthType, assign objects to that AuthType, and then create a capability that grants that AuthType. When you assign this capability to a set of users, they can only see the area of the system that the authorization type and capability allow them to see.

The following example assigns the LimitedReportType authorization type to a TaskDefinition, and the Run Limited Report capability to a user. Consequently, that user can only execute reports where TaskDefinition is the LimitedReportType authorization type.

<AuthType name=’LimitedReportType’ extends=’TaskDefinition’/>
<AuthType name=’LimitedReportType’ extends=’TaskInstance’/>
<AdminGroup name=’Run Limited Report’ ...>
...
<Permissions type=’LimitedReportType’ rights=’View,Execute’/>
 ...
</AdminGroup>