Portal-related authorizations in the Roles Database

(Last modified by Jim Repa, 12/13/2006)

The Roles Database has been configured to store Portal-related authorizations, which can be extracted by the IS&T-maintained portal. Below are some notes on how this has been set up, and how various authorizations and other types of data can be maintained by a few specially-authorized individuals.

Quick introduction to Authorizations

Authorizations in the Roles Database are 3-part entities:

Authorization = Person + Function + Qualifier

You can create or delete Authorizations in the Roles Database only if you have the authority to do so, which is itself controlled by Authorizations about Authorizations (i.e., "meta-authorizations") within the Roles Database.

To create an authorization, you pick a person from the list of people at MIT, a Function from the list of Functions for which you allowed to grant Authorizations, and a Qualifier related to the Function which you are allowed to pick. Functions are grouped into Function Categories (or application areas), and Qualifiers are grouped into Qualifier Types. Each Qualifier Type has a hierarchy of Qualifiers. An authorization granted for a Qualifier which represents the root or a node within the hierarchy applies to all child Qualifiers.

Separate "meta-authorizations" can be assigned to allow a person to maintain Authorizations, Functions, and/or Qualifiers. (Many Qualifiers are updated automatically from other sources, but some are maintained by hand.)

At the present time, Authorizations and Functions are maintained via the MIT-developed application, which was written in PowerBuilder and can be downloaded for Windows from IS&T's software web site. For Macintosh users, it is available on Citrix.

Authorizations, Functions and Qualifiers for the Portal application

The 4-character code for the Function Category for the Portal application is PRTL. Currently, there is only one Function in this category: PORTAL_ADMIN, and Authorizations for this Function must have a Qualifier from the tree of Portal Areas (Qualifier Type code PRTA). Qualifiers in this tree can be added as needed using the Roles web interface for maintaining qualifiers. Currently, the PRTA qualifier hierarchy has a root-level qualifier of ALL_PORTAL_AREA and directly under the root, it has two qualifiers with the following codes: IS&T and EHS.

To give someone the Authorization to do Portal Administration for all areas, connect to the Roles application on Windows (native) or the Mac (using Citrix), and give the person the following authorization:

PersonFunction
Category
FunctionQualifier
the person's Kerberos principal PRTLPORTAL_ADMINALL_PORTAL_AREA
To give someone the Authorization to do Portal Administration limited to one area, e.g., EHS, connect to the Roles application and give the person the following authorization:
PersonFunction
Category
FunctionQualifier
the person's Kerberos principal PRTLPORTAL_ADMINEHS

Existing Authorizations related to the Portal can be viewed either via the Roles Application or via the Roles Web interface. For a web-based report on all Authorizations for the Portal application, do the following:

You will see a display of the hierarchy of Portal Areas, and under each Portal Area, you will see related Authorizations. Function names are shown in green.

Extracting authorization information from the Roles Database

To extract authorization information from the Roles Database for the PRTL (Portal) category, you must connect to Oracle database used by the Roles system and use a SELECT statement. In the near future (first half of calendar 2007), we plan on making available a Java interface for extracting this information as another alternative. For now, the recommended method of extracting authorization information is to use a Select statement.

For systems that do automated extraction of Authorization information, we recommend setting up a special Oracle username/password for doing the database connection. We do not recommend using any individual's personal username to run a batch job.

The view EXPANDED_AUTH_FUNC_QUAL produces "expanded" authorizations, i.e., if the original authorization was granted for a Qualifier with child Qualifiers or for a Function with child Functions, it will show records for each child Qualifier and child Function. It also has a column IS_IN_EFFECT that looks at the columns EFFECTIVE_DATE, EXPIRATION_DATE, and DO_FUNCTION, and returns a single calculated field 'Y' or 'N' indicating whether or not the Authorization is in effect at this moment.

A simple SELECT statement to extract Portal-related authorization information would be the following:

  select distinct kerberos_name, function_name, qualifier_code
    from expanded_auth_func_qual
    where function_category = 'PRTL'
    and is_in_effect = 'Y';
Other columns are available, with information about who created the authorization, when it was created or is due for expiration, the level in the Qualifier hierarchy at which original Authorization was granted, etc.. However, the above SELECT statement is probably sufficient for simply extracting current Authorization information.

You can use a modified version of the SELECT statement to extract pairs of information, with (a) Kerberos principle and (b) a combined field derived from the Function and the Qualifier. The following SELECT statement combines Function and Qualifier, does special processing for the root qualifier, and changes the strings to lower-case:

  select distinct lower(kerberos_name), 
    lower(replace(function_name || '_' || qualifier_code, 
            '_all_portal_area', ''))
    from expanded_auth_func_qual
    where function_category = 'PRTL'
    and is_in_effect = 'Y';

Maintaining Portal-related Authorizations in the Roles Database

The "meta-authorization" for the authority to maintain Authorizations in the PRTL (Portal) category is the following:

PersonFunction
Category
FunctionQualifier
the person's Kerberos principal METACREATE AUTHORIZATIONSCATPRTL
As of this writing, Mike Berger, Mike Moretti, and Steve Landry have this Authorization, and they all have the authority to grant or delete it for others.

Anyone who has this "meta-authorization" has the authority to create or delete Authorizations in the category PRTL (Portal) that will give people the role of a Portal Administrator in one or more areas. They need to use the Roles application on Windows or the Macintosh. See the "Software at MIT" site to download the application.

Another prerequisite for using the Roles DB application is to have a username/password in the Roles DB Oracle database itself. (Mike, Mike, and Steve already have them.) Contact business-help@mit.edu to request a Roles DB username, which must match the MIT Kerberos principal for the person. Then, go to the Roles web site to use a secure web interface to set (or change) your Oracle Roles DB password:

(We will not include detailed instructions for using the Roles application here.)

Adding or changing PRTA (Portal Area) Qualifiers

Specifically authorized individuals can use the Roles web interface to maintain Qualifiers of type PRTA. Authorizations can only be granted on existing Qualifiers.

The "meta-authorization" for the authority to maintain Qualifiers of type PRTA is the following:

PersonFunction
Category
FunctionQualifier
the person's Kerberos principal METAMAINTAIN QUALIFIERSQUAL_PRTA
As of this writing, Mike Berger, Mike Moretti, and Steve Landry have this Authorization, and they all have the authority to grant or delete it for others.

To add, delete, or changes Qualifiers of type PTLA, do the following:

Maintaining Portal-related Functions in the Roles Database

As of this writing, there is only one Function defined under the PRTL category. If there is a need in the future to define different levels of authority for Portal administrators, then additional Functions can be created.

The "meta-authorization" for the authority to maintain Functions in the PRTL (Portal) category is the following:

PersonFunction
Category
FunctionQualifier
the person's Kerberos principal METACREATE FUNCTIONSCATPRTL
As of this writing, Mike Berger, Mike Moretti, and Steve Landry have this Authorization, and they all have the authority to grant or delete it for others.

Anyone who has this "meta-authorization" has the authority to create or delete Functions in the category PRTL (Portal) that in turn can be used in Authorizations. You cannot delete a Function if there are still Authorizations assigned for it.

As described in the section on maintaining Authorizations, you need to download the Roles application and set up a database username/password for yourself prior to maintaining Functions.

We will not describe in detail how to use the Roles application to create Functions. However, we will describe what fields need to be defined in a new Function in the PRTL category. Make sure that you specify the following fields:

Function name:A unique name, up to 30 characters, containing upper-case letters, numbers, and common special characters such as underlines, dashes, parentheses, commas, periods, or ampersands.
Function description: Up to 50 characters, mixed case
Function Category:PRTL
Qualifier Type:PRTA