UNI Security Request System
This document is intended to introduce you to the Security Request System (SRS) and explain why it was built, how it works, how to get help in using it and the initial steps for going live. If you have questions on the system, please contact the IT Service Desk (x3-5555 or servicedesk@uni.edu) and they will either answer your question or get you in touch with someone that can.
Why do we need a system to manage security requests?
The Security Request System (SRS) was identified as a need here at UNI after the implementation of the e-Business system. Paper forms take time to mail around and get to ITS often creating frustration for users. Then ITS needs to maintain all these forms so they are available to auditors for review. There are currently thousands of security forms in ITS files supporting the security in place today for all our systems.
As time has progressed, the paper security form issue has only escalated with the implementation of Facilities Management system (FAMIS), Student Information System (SIS), Imaging and custom web transactions. It can take weeks to get all the approvals needed for new employees and the variety of required forms.
Another identified need is to grant security to a person to based on their HR assignment. As employment changes occur, ITS has to keep track of when employees jobs change so their security can be updated. This is fairly easy to do when employees leave the university as it is obvious they are no longer here. However when employment assignment changes occur, it can be difficult to determine when the person's job is really the same and needs to stay in place versus when it needs to be removed.
Prior to the SRS system it required about 35+% of an ITS FTE to manage and process all the security forms. Since the forms will be online, they will no longer need to be keyed into the system, thus saving time. We also plan to develop an interface from the SRS to each system, such that once approvals are complete, the security to the proper system are granted either instantaneously or within hours. While we will have a new system to maintain, we will eliminate the need for 35% of a person to manage the paper, all while providing more timely service to you, our customer.
The final major need identified for the SRS system is reporting. Who has access to what? In what systems? Who approved it? etc.. This information currently exists in a number of systems and is difficult to bring together into a single place for accurate reporting to management and auditors.
Key features of the SRS
Note: All the help links referenced below can be found on the Security Request System help page at any time at: SRS Key Features
Requesting Access
Help link: SRS Help
Allows any employee to request access for themselves, another employee, new hires, student employees, patrons (auditors, consultants etc…). Note for all requests except the patron, they must identify an assignment or PAF for the request to be tied to. PAF’s evolve into assignments, and once that happens the requests are tied to the assignment. If that assignment is ever terminated due to leaving the university or changing departments, the employees access will be terminated. if it needs to remain, it will need to be re-requested.
For new hires, they must at least have a PAF in the PAF system for access to be requested. Please note that some systems won't be able to actually physically give access until the employee is actually processed into the e-Business system.
For patrons, they must be in the patron system already, if you have a need to create and maintain patrons, please contact Kevan Forest in ITS-IS to discuss your needs. NOTE: Patrons are individuals who are not students, or employees, yet have a relationship with UNI requiring access to UNI services or resources.
Approving Access
All approvals are done via the e-Business workflow approval system used for financials, timecards, PAFs etc.. Security requests do not time out and move up the management chain, they will await approval forever.
There are really two types of approvals in the SRS system, they are:
Management Approval
The system automatically identifies the manager of the assignment tied to the request and they are the first approver. If the manager is lower than a director, the director is identified as the second approver. If the initial manager is either a director or higher, that is all the management approval needed. In the case of requests for patrons, the Management Approval is sent to the Manager and Director of the person that originated the request for the patron. So if I as director of ITS Information systems requested access for a consultant, the request would go to Marty Mark the university CIO as my manager for approval.
Resource owner Approval This is one or more groups of people identified in the university as responsible for the role being requested. For example the role “Bender_Hall Timecard Reviewer” is for Residence, so the group “SRS Residence_System_Operations” is identified as being responsible for approving requests for that role. Glen Gray, as director of Residence, is in that group, and he is free to give access to that group to others as well. If he has himself and two others in the group, all receive the notification for the request, but only ONE of them must approve it. Once one of them approves the request, it is removed from the notification list of all approvers for that group and it moves on.
There are some roles which require approval by multiple offices, such as HR and Business Operations. In those cases there are two approval groups tied to the role in question and one person for EACH group must approve the request.
The entire workflow is identified and viewable by the requestor in SRS before the request is submitted. The user and requestor can check back any time to see the status and where the request is in the process.
Copying Access
One common request we have heard from users when discussing the SRS was “we want to copy roles from one person to another”. For example if an individual leaves the university, and their replacement is hired, they want to be able to copy the roles from the first employee to the second. To support this request, we allow you to bring up the original employee, and manually select each role they had one by one and copy them to a new request. Each role will still need to be approved by the proper parties, but creating the request is much simpler. We do caution you from blindly copying all roles, please be certain you copy only those roles which you know are needed. If you have questions, please use the SRS system to query each role to see what functionality it provides.
Templates
View this article on creating and using security templates.
Reporting Features
There are reporting features identified below that cover reporting for yourself, your employees and for the roles you manage. You will notice that our initial load of all roles does not include who originally approved the roles and when they were granted. All new approvals done in the system will have this data, and the reports will show it when it is available.
Note that all roles granted are listed. You will see that some roles are shaded while others are not. The shaded roles are what we call auto granted roles, and can not be requested. They are given automatically by the system based on data. For example employees get certain roles automatically, students get different roles, as do DDDH and higher.
View My Roles
Help link: How to view my roles
This feature allows any employee the ability to view what roles they have in all participating systems. They can view when it was granted, or revoked, and the approval process it went through.
Role Lists and descriptions:
There are a number of types of information that will be available via the SRS. First and foremost is a list of roles by system and a description of the purpose of each. Too often roles are requested because someone else had it and they claim “I am doing the same job, so I must need it”. This may or may not be true, it is important to know what each role does before requesting access to it.
ITS is working to clearly define what each role is, however there are over 1,900 roles currently in the SRS system, we are working to clearly define each of them, however if you see a role you are responsible for and have a better definition, please send it to Kevan.Forest@uni.edu and we will see that it gets updated.
You may notice that the search roles option allows you to see all university roles. However the request roles pages only show you a subset. This has been done for several reasons:
1. We wanted transparency on the search roles page, so that every role can be seen.
2. On the request roles page, we wanted to make it easier for users to find what they are looking for, so by default
the system filters the roles to those that an average end user will request. Should you need to request other roles
not available via the request role page, you can also request a role from the search list that has all roles on it.
Role Owners/Approvers
Each role in the system has a single role owner identified. That owner can at any time view a list of users who have that role and revoke the role as well.
Supervisors
Supervisors have the ability to view their direct reports and what roles they have as well.
Approvals
Approvals for the SRS system are handled via our e-Business workflow, and operate just like all other e-Business approvals.
Delegating approvals
We recommend careful thought before delegating your approval responsibilities to others. However should you decide delegation is appropriate there are also a number of ways to accomplish the delegation. These are summarized below
Management Approval
These approvals can be delegated in one of a few ways:
1. Vacation Rules, you can create a rule, that for a predetermined date range approvals will go to the party you identify as
your proxy. For details on how to do this, please see: Setting a proxy
2. Worklist Access, allows you to identify someone to delegate certain workflows to on an ongoing basis. For details on
how to do this, please see: Granting worklist access
Resource owner Approval
While the above routes will work for Resource owner Approval as well, it is best to grant someone the SRS role you manage. That way either of you can approve these types of requests at any time. This can be done via the SRS system itself, for details on requesting a new role for someone, please see: Requesting a role
System Usability
We have tried to be very careful to ensure that the SRS system will work in all browsers. In testing we have found that to be the case. However testing did identify that the pdf’s in the ebiz workflow (used for approvals) don't always work when using various browser’s built in pdf viewer. If you find that your workflows come up with a blank space where the pdf document should be below is a help document that explains how to set adobe as the default pdf reader for your various browsers and resolve that issue:
If you need help configuring your browser to display these PDFs appropriately, please contact the IT Service Desk.
Once approvals are done, when does the security get granted?
The security request system project actually has 2 phases. Phase I is making the requests and approvals electronic, which is now complete. Phase I calls for grants to still be done manually in each target system, however instead of reading off paper forms, we will use the SRS as input.
Phase 2 will start in the coming weeks, and will focus on automating the feeds from SRS to the target systems: EBIZ, SIS, FAMIS, Web Transactions, imaging and OBIEE. The goal is to have these interfaces complete before January 1, 2016.
Can the SRS work with other systems?
Absolutely! If there is interest in the SRS working with other systems, please contact Kevan Forest or write a par, and we can discuss what it would take.
Conversion and Re-approval of roles
For the initial go live (September 3), we have automatically loaded all the roles currently granted in the systems using the SRS, however you will also notice no historic approval data has been loaded as it is not available. After discussion between ITS and university operations directors and managers, it has been decided that we should generate requests for all existing roles granted. We did not want to do this with the initial go live of the SRS, as it is too near the beginning of the school year, and your lives are hectic enough. However we feel this is a good clean up procedure to ensure all access granted is properly documented, and still needed.
The current plan for these requests to be generated is September 20. Most areas this means you will have a noticeable spike in workflow approvals, however it should be less than 100 in most cases. There will be some of our back office areas (registrar, business operations and a few others) that will have to deal with thousands of approvals. Those areas have been contacted and are preparing for the task. We appreciate everyone's effort to see that these are done in a timely fashion, and hope that those with a small number can be done in less than a week. For those with larger volumes we understand that it may take 4 - 5 weeks to process through the backlog.
If you find that these conversion notifications are getting in the way of other important notifications, please note that you can sort the notifications by hitting the subject column and you can then easily see other notifications at the top or bottom of your list.
Again should you have questions or concerns regarding the SRS, please contact the IT Service Desk and they will log your concern, and make sure it makes its way to the proper people.
