Authorization Application Overview
This system allows UWM employees and student help a means to request authorization to various systems/groups and track the progress of the request online. Those who authorize access will receive email notification that they have requests pending and will be able to approve or deny the requests online.
At this time, there is no automatic processing of the actual request. The access will be entered into the separate system (e.g. PAWS Student Admin Data Warehouse) for which the request for access has been made and that action is recorded in the Auth App.
The authorization process should be faster and at any point in time the requestor will be able to see where their request is in the process.
Other benefits to the Authorization Application include being able to see all groups to which an individual belongs and request removal from a group. A dean or custodian will also be able to request removal of an individual. A custodian will be able to see all members of groups; deans or division heads will be able to see to which groups people in their Division belong.
Components of the Authorization Application System
The system is the highest level of organization. Every system must have at least one system administrator. Some examples: Data Warehouse UWM PAWS Data, Hyperion Foundation
An 'Agreement of Use' can be required at this level. If required, the agreement text must be entered when the system is created. The agreement text will be displayed for the requestor the first time a request is made for a group in that system. Once 'agreed', the act of agreeing for that system is logged for the requestor and will not appear again for any other group in that system.
Groups allow for distinction within the systems. Every system must have at least one group. The group is the level at which access will be granted. Some examples:
System=Data Warehouse UWM PAWS Data
Groups=Admissions, Campus Community, Student Records; Financial Aid.
Ferpa can be required at the group level. If required, a check is made against the DES database of those who have taken the FERPA test with the appropriate score to have passed FERPA.
Confidentiality Acknowledgement can be required at the group level. If required, a check is made against the Database of those who have passed the Acknowledgement Assessment.
An agreement of use can be required at this level. If required, the text must be entered when the group is created and it will be displayed for the requestor. Once 'agreed', the act of agreeing is logged for the requestor and they won't be asked again.
The levels of authorizations that are required are entered at this level. It's possible to require no levels of authorization (an example is access to the Hyperion Foundation - we need to record access but a person only has to work at UWM for approval for access).
Levels of Authorization/Processing
There are several levels of authorization possible for each system/group. All levels are optional except the Security level.
Twice a day, outstanding requests will be checked and emails will be sent to anyone who has pending requests that require action. As each level processes their portion of the request, entries are made to record the action. The authorizers don't have to wait for the email notice, they can log on to the application at any time to see their outstanding requests and take action.
A supervisor authorization can be required.
If supervisor authorization is required, the requestor will indicate the appropriate supervisor. This is done a) because we have no electronic indication of a person's supervisor at this time. And b) because a requestor could be doing work in another area which would require a different supervisor's approval.
A drop down menu of employee's in the Requestor's primary appointment Division will be offered for selection or a different supervisor's epantherId can be entered. Any valid epantherId could be entered, upper levels of authorization are expected to validate supervisor entries (e.g. if someone entered a co-worker as their supervisor, a Dean/Director/Division head, Custodian or Security Administrator would be expected to see this).
If a group allows Student Help access, a Supervisor's approval must be required for everyone. This is because we have no appointing UDDS (UWM's Unit, Division, Department and Sub-Department coding) for Student Help at this time and need to obtain a Division for the request (which will then come from the Supervisor's UDDS).
The Supervisor's Division will be used for the 'Division of record' for the request; this can be different than the Requestor's Division. If a Dean/Div approval is required, the Division of record will be used to select Dean/Director/Division head's who are able to authorize the request. The requestor and the specific system/group requested will then be displayed in lists for the Division of record (as opposed to the Requestor's Division).
Supervisors can only request removal of access for people that they themselves have authorized. They can ask for removal from one group or ALL groups (where they were the authorizer).
Dean/Director/Division HeadThe second level of authorization possible is the dean/director/division head level.
If a supervisor was required, the supervisor's division is recorded for the request. If the supervisor level is not required, the division for the requestor's primary appointment is used.
There may be multiple people who can authorize for a division. This is done to allow for multiple people and/or designates. All who are eligible to authorize for a Division are entered into the Authapp_Div_Auth table.
All possible authorizers for the division will receive a pending work email (if the division authorization is still pending when the email selection is done); the person who actually processes the request will become the dean/director/division head authorizer of record.
The third level of authorization possible is the custodian level.
Custodians are entered for the system/group combination. There may be multiples. All who are eligible to authorize for a group are entered into the Authapp_Cust_Auth table.
Email notification and authorizer of record work in the same manner as the dean/director/division head level.
The custodian can request removal for anyone in the groups that they authorize. They don't have to have been the custodian who actually authorized.
This level is required; this is not an authorization level per se. Security administrators are at the system level. These are the people who actually process the access in the separate system for which access has been requested. There may be multiples at this level. All who are eligible to process the access for a system are entered into the Authapp_Security_Administrators table.
Email notification and recorded processor of access works in the same manner as the dean/director/division head and custodian levels.
At this time, there is no automatic processing of the actual request. The security administrator does their entry work into the separate system for which the request for access has been made.
Security administrators don't authorize per se. They could call attention to a request if they question it; primarily they are acting on other's authorization. They also do not remove access on their own decision.