Planned or proposed enhancements to the Roles DB and interface
-----------------------------------------------------------------------------
(Jim Repa 2/13/2007)
Below is a list of proposed enhancements and interface additions for the Roles DB. We'd like to prioritize the items below, determining which are needed sooner rather than later.
This document is an overview of enhancents. There is another WIKI document that goes into more details on possible requirements for "implied authorizations".
* Build a new web-based authorization maintainers' interface to replace the
current PowerBuilder application
* Extend the Roles DB to allow authorizations for generic "agents" (not
just people). In addition to continuing to support MIT people who
have a Kerberos principal, also support some or all of the
following:
(a) servers,
(b) explicit lists of people (Moira),
(c) implicit lists of people (e.g., those with a particular attribute),
and
(d) people authenticated outside of the ATHENA.MIT.EDU realm.
* Provide 24/7 service (eliminate the current downtime for backups)
* Implied authorizations:
-- Build "meta-data" structures for defining implied authorizations, as
well as derived three-part data items about people that are not
authorizations but can reside in similar structures. Allow for one
class of implied authorizations to be derived from other sources and
cached in tables in the Roles DB so that they can be implmented in the
short term using existing database tables.
-- Define an interface to allow for implied authorizations to be
looked up "on the fly" without the need for them to be fed into the
Roles DB tables via periodic feeds.
* Real-time interface
Provide a real-time interface to support the following
Part 1a. Look up authorizations
-- Look up existence of an Auth: Can agent A do function F with
qualifier Q?
-- Get a list of Auths for an agent within a Function category
(see more detail in other requirements document)
-- Find out who can do a given Function optionally limited by
a given Qualifier
-- Get information about implied authorizations, i.e., what is the
rule by which an authorization is implied (see more detail in
other requirements document)
Part 1b. Update authorizations
-- Create or delete an authorization
Part 2. Look up or update functions
-- Look up all Functions in a Function Category
-- Look up parent/child relationships between Functions in a given
Function Category
-- Create or delete a Function within a Function Category
-- Modify Function parent/child pairs within a Function Category
Part 3. Look up or update qualifiers
-- Look up Qualifiers under a given parent Qualifier
-- Look up Qualifiers by qualifier code or qualifier name
-- Add, delete, or modify a Qualifier within a given qualifier_type
Part 4. Look up agents (modify agents?)
-- Look up an "agent" by name, username, etc.
-- Are there types of "agents" which, unlike MIT people, will not be
automatically fed from other source, and for which we should provide
an interface to the Roles DB for adding, deleting or updating them?
(Most "agents", such as MIT people, are automatically fed from other
sources and should only be updated in the system of record.) The
types of agents might include servers, test users, non-MIT users,
or implied lists (i.e., where membership in a list is implied by
an attribute that someone has).
Part 5. Miscellaneous functionality
-- Look up qualifier types
-- Maintain qualifier types
-- Look up Function Categories
-- Maintain Function Categories
-- Look up the rules for implied Functions within a category
-- Modify the rules for implied Functions within a category