Adding support for federation

The orginal MIT Roles system assumed that all ASPECs pertained to people that had accounts which existed in the central MIT namespace. In other words, the Subject of any ASPEC was a Kerberos principal name associated with someone that had an MIT account. One of perMIT's primary goals is to broaden the scope of Subjects to support applications that deal with federated authentication. Subjects will also be able to be systems, services, or processes that can authenticate.

Option 1

a.

Build a new base table (ASPEC) to replace the Authorization table. In the new table, instead of Kerberos_name field, make it agent_identifier field. Expand the length of the field to 60 characters (longer?) to accommodate usernames that include a domain, e.g., username@xxxxxxx.xxxxxxxx

Within this field, you could have a username of the form username@xxxxxx.xxxxxxx or it could be another kind of unique
string to represent the person, e.g., nnnnnnnnn@mitid.mit.edu (holds an MIT ID number)

A new field, part of the primary key, would be agent_id_type_code, which would determine the format of the agent_identifier field. This field is joined with the agent_id_type table.

b.

To mimic the old Authorization table for old applications at MIT, build a view on the Aspec table. The view would

1. Only include records where the username matches \*@mit.edu (mailto:*@mit.edu)
2. Include a field Kerberos_name that is the username field with "*@mit.edu" stripped off

c.

Build a new base table (Agent) to replace the Person table. This table would have the additional column agent_id_type_code The column agent_type_code joins to the agent_id_type table.

Instead of the primary_person_type column in the existing person table, we would have an agent_type_code column, allowing a finer splitting of agent types (e.g., faculty, staff, student, guest, server, etc.). This would join to the agent_type table.

Add some more columns to allow for local data about people or agents,for example

• local_attribute1 (could be used for MIT ID number at MIT)
• local_attribute2
• ...
• local_attribute10
  
  

d.

Build a new base table Agent_id_type

• agent_id_type_code varchar(20)
• description varchar(80)
  
  

Records in this table would include

e.

Buld a table Agent_type. This would have columns

and would contain records such as the following

f.

Build a view on the new Agent table to mimic the Person table at MIT.

g.

Build a new table Function_agent_id_type to indicate which agent_id_types
(not to be confused with agent_types) are allowed for an agent when you create an Aspec for the given Function. For example, some
SAP financials authorizations might require an agent_id_type_code that
represents an MIT Kerberos username in the ATHENA.MIT.EDU space (the
current de facto scenario). Other Functions might allow other agent_id types.

When we convert data in a later version of perMIT, we could make the default for existing Functions be to only allow the
agent_id_type for MIT Kerberos principles. However, the default for newly
created Functions would be '*' (all agent_id_types allowed).

Columns:

• function_id
• agent_id_type_code

h.

Build a new table Function_agent_type to indicate which agent_types (not to be confused with agent_id_types) are allowed when you create an Aspec for a given Function. The default would be '*' - all agent_types allowed. This could be used if an application
insists that only current MIT employees be assigned an Aspec for a given Function.

There would need to be a nightly feed program (or process that is triggered by changes in an agent's status) that would deactivate an Aspec if the agent_type becomes incompatible with allowed agent_types for the Function.

Columns:

• function_id
• agent_type_code

i.

Build a new table Function_authn to indicate which types of authentication are allowed for an end user when checking a person's authorization for something.

Columns

• function_id
• agent_id_type_code
• authn_level

With this table, you could set up a configuration where different application levels could have different authentication
requirements. At MIT we would set records in this table to initially preserve the existing implementation (e.g., SAP access requires a Kerberos principal or MIT certificate), but allow new applications to accept other types of authentication.

j.

New table Agent_mapping. Each record in this table maps one record in the Agent table to another record in the Agent table, indicating that these are two representations of the same person or agent.

• original_agent_id_type_code
• original_username
• mapped_agent_id_type_code
• mapped_username

k.

New table Cat_Default_AuthN. Each record in this table maps one record in the Agent_ID_Type table to another record in the Category table, indicating one of the default allowable Agent_ID_Types allowable for Functions within the given Category.    The allowable Agent_ID_Types can be set either at the Category level (i.e., applies to all Functions within the Category) or the Function level.  If at least one record exists in the Function_AuthN table for a given Function, then the allowable Agent_ID_Types for that Function are gotten from the Function_AuthN table, and the Cat_Default_AuthN table is ignored for that Function.

• Function_Category
• Agent_ID_Type
• mapped_agent_id_type_code
• mapped_username

Option 2

Similar to Option 1 except

• In Aspec table we have a numeric agent_id (internally defined, meaningless outside of the system) instead of a string for the user_identifier field and agent_id_type_code. The agent_id field would be meaningless unless you join it to the agent table.
• In this scenario, the Authorization view (mimicking the old Authorization table) would need to join the Aspec table with the Agent table to get Kerberos_name value.