Sun Identity Manager Deployment Guide

Chapter 2 Working with Authorization Types

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

What are Authorization Types?

Identity Manager 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 vastly different functions that consequently require different authorization. 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 Identity Manager administrators with a specific capability.

How Identity Manager Uses Authorization Types

Identity Manager 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’/>

This second approach is much harder to configure because administrators with rights on the parent types (red, green, blue) will also have access to type ’foo’.

Architectural Features

The primary architectural feature of authorization types is the Configuration:AuthorizationTypes object. You can add or remove authorization types by modifying this object.

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.

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 an authorization type repository type that is the supertype of this type.
`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 Subtype Permissions

Identity Manager uses the extends attribute to define the supertype of an authorization type. Supertype permissions are inherited by the subtype. For example, if a user has view rights on TaskDefinition, they would also have view rights on UsageReportTask and all other subtypes of TaskDefinition.

Although you can edit the AuthorizationTypes object only in XML, you can define permissions that reference authorization types from the Capability page. (You can access this page under the Capabilities subtab of the Security tab.)

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.

Identity Manager 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. Identity Manager 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

Identity Manager 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 Identity Manager

You can also use authorization types to grant fine-grained administrative control of a very specific part of Identity Manager 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>