Monday:



perMIT

Data Tables

"Qualifier modifies the scope within an A-spec."

Qualifier hierarchies are a tree structure.  A leaf can have more than one parent, but circular  references are not allowed.

Each distinct qulalifier hierarchy is encapusulated by the qualifier type.

E.g. qualifier type of HR Org units is one tree strucuture.

        qualifier type of Fund Centers and Funds is another tree structure.

TERM: "Primary authorizer" - a person(s) within a department that can grant authorizations  regarding the department. Who they grant that authorization to is not limited to people within  the department.

There is a function HR_PRIMARY_AUTHORIZER and a function  FINANCIAL_PRIMARY_AUTHORIZER the qualifiers are a DEPARTMENT code.

Schema exists on Troles and Roles in schema subdirectory? Should get a copy and use Visio to  create diagrams to see how these compare with Jim's diagrams.

Qualifier descent table updated by bulk feeds, as well as UI triggering stored procedures. One or  two at time via stored procedures are OK. Updating 200, the bulk feed is more efficient.

Include two views of the qualifier descendent table:

  1. Same table as today
  2. Same table as today, but also includes where the parent and child have the same ID

View B means that you can do a single select statement instead of two, for the case where the  user has a direct A-spec assignment instead of via inheritance.

Visio diagrams: try connecting Visio to roles using my roles username and password...

Vast majority of functions don't have parent / child relationship. We don't have  function  descendent table that is equivalent of the qualifier descendent table.

Suppressed QualName: business reason, make few people able to determine who is doing  particular types of researcher: animal, reactor, P4....

Visio reverse engineer:

Data Source Name:

Description:

TNS Service Name: roles.mit.edu or troles.mit.edu

User ID: pbh

Afternoon meeting: implied authorizations

(Paul 30 minutes late due to other meeting)

Some constraints maintained via a generic stored procedure. One that is not likely to modified by  any other sites because it is helping to provide the referrential integrity.

Qualifier_subtypes:

We can have subtypes within a qualifier hierarchy

e.g EHS r_set can have subtypes of principal investigator, room_set, room,...

Subtype_descendent_subtype is not derived from anything. It is manually entered. It is the table  that shows that Principal Investigator  is a higher level then the ROOM_SET, and ROOM.

Function_load_pass is missing from current document. Jim will add.

URL to show some of the rules. Jim will send or put in wiki.

Tuesday:



perMIT:

Qualifiers vs. Object

Qualifiers belong to a heirarchy

Subject

Function

qualifier

Subject

Verb

object

Who

What

where


Should permit add a second optional qualifier? (4 columns)

perMIT - Tuesday afternoon

Master Dept. Hierarchy

https://rolesweb.mit.edu/mdept/\\

If Jim were redoing qualifier hierarchy section of Roles, he would implement it more like the  master dept. hierarchy. Allows for multiple types in single heirarchy. Also means that certain  objects don't need to be duplicated.

Should perMIT do this? We could put in the tables and columns, but have them default to the way  that we have qualifiers implemented today.

Bigger meeting topic: should we change the data model of the qualifiers so that a single object can  exist in two hierarchies.

Allows for some very sophisticaded reporting, but need think through the UI issues of  creating the qualifiers.

Here's an object. What views do you want it to appear in? What are the parents and  children in each of the views?

Friday: revisiting the DB schema. How to restructure the qualifiers

Wednesday:

perMIT daily:
Waiting to hear back from Peter Maloof.
SqlSquiral installed and able to access troles.

Perl scripts to pull out stored procedures:

  • Need perl modules: dbi and oraperl

Jim out on Thursday, back in on Friday.

1 hour meeting on Friday to start writing more verbose use cases.

Friday:

PACMANN call:

  • Discussion about spoc-p
  • Lief and Roland: ontologies and semantic web

Permission

Privileges

Claim

Assertion

Attribute

Entitlement

Authorization

Roles

Rule

Provision

Delegation

Designation

Fufillment

Authority

Eligibility

Approval

Approver

Grantee

Grantor

Federation

Hierarchy

Group

ACL (access control list)

Access?


XACML diagrams

Ontology

AI:

Klara and Rob - survey results

Still in process

-talking with our auditors

Can we get a letter from MIT auditors that say they are happy with MIT Roles?

perMIT use cases:

Show changes to authorizations for a person

  • Show recent change

Show changes made by a person

Given a function and qualifier, show the history of the changes to who had access (5)

This assumes the qualifier is stable. If the qualifier has moved (e.g. from one fund center to another) then we don't track enough historical information to generate this report for those situations.

Note: mergers and acquisitions probably cause the most disruption in qualifiers. HR hierarchy, finance, ...

User's whose directory information has changed (in a given time period)

Might have moved from one department to another

Status change (employee became student, ...)

Users that departed

Note: this report is really based on system(s) external to perMIT. perMIT doesn't necessarily have all of this data about people.

Note: discussion about the contraints within roles that require that the SUBJECT be known to the system before A-spec data entry can be performed.

Hmm, should perMIT be LDAP enabled in order to lookup people?

Does sample data contain some sample HR data from an external system.

Pick a category and a qualifier type.

Display the functions related to the qualifier and the people that have those functions and qualifiers.

(qualauth.pl?category=HR&qulatype=ORG2&...)

Pick by Category & DLC:

Shows each of the hierarchies with each of the applicable Functions, and how many people have each authorization assigned.

Dlc-auth-all.pl:

Pick by category and DLC

Can display a number of options

One-step lookup of requisitioner and approval authorizations (specific use case of use case 5)

Pivot view into hierarchies:

Note: the meta data about a qualifier does not exist in roles. Current CGI code has code that nows how to pick this up from MIT DW (in some cases).

Should there be some web service interfaces so that other customers can then create the other end of the web service. Once done, you can create some rich reports very easily.

Quarterly metrics reports

Data feeds:

Parameters that limits changes made by data feeds

 

  • No labels