...
| Gliffy Diagram | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
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
...
- Only include records where the username matches \*@mit.edu (mailto:*@mit.edu)
- Include a field Kerberos_name that is the username field with "*@mit.edu" stripped off
...
and would contain records such as the following
agent_type_code |
|---|
...
description | |
|---|---|
EMPLOYEE | current faculty or staff |
STUDENT | current undergrad or graduate student |
SERVER | a server, not a person |
GUEST | a person who is neither employee nor student |
f.
Build a view on the new Agent table to mimic the Person table at MIT.
...
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.
...
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
...