Date: Fri, 29 Mar 2024 09:54:29 +0000 (UTC) Message-ID: <155619683.7803.1711706069621@ip-10-10-7-29.ec2.internal> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_7802_416212292.1711706069618" ------=_Part_7802_416212292.1711706069618 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html
NCSU developed a home-grown facility for management of privileges within= its Peoplesoft-based HR and financial systems some time ago, using as its = basis the privileging mechanisms provided natively by Peoplesoft. Over time= , the cost of maintaining that privileging system coupled with the perceive= d need for the additional capabilities of a true IDM system led to the univ= ersity's deploying Sun Microsystems' Identity Management product, and negot= iating with a Sun partner to re-implement the privileging system within the= Sun IDM environment. The new solution relies heavily on automated approval= s and workflows, and relies extensively on Peoplesoft's native role managem= ent and security mechanisms. It provides a great deal of flexibility in som= e areas, but lacks some granularity the university would find useful in som= e situations.
The resulting solution has some idiosyncratic properties, perhaps best e= lucidated through a pair of contrasting scenarios - one that highlights the= solution's strengths and one that highlights its weaknesses. These scenari= os are arbitrary, but reflective of real-world situations in which (in the = first case) the NCSU system provides a particularly effective solution, and= (in the second case) has some unexpected and potentially very undesirable = consequences.
Sally is the business manager for the Department of Chemical Engineering= within the university's Engineering School. One of her routine job respons= ibilities is entering into the privilege management system requests for acc= ess to fund code information on behalf of PIs within her department. When s= he took over this responsibility long ago, she was assigned a "requestor" r= ole within the privileging system, and her department Chair approved her be= ing associated with the Chemical Engineering department for purposes of fil= ing requests on the department's behalf.
Following the recent early retirement of Bill, previously the business m= anager for the Department of Nuclear Engineering, the Nuclear Engineering d= epartment determined that with its small staff and faculty (totaling only a= dozen individuals) it would no longer need a full-time business manager. T= he Chair of the Nuclear Engineering department negotiates an agreement with= the Chair of the Chemical Engineering department to have Sally take on res= ponsibility for making the infrequent requests for privilege changes on beh= alf of the handful of PIs in the department. The Nuclear Engineering Chair = contacts the Dean's office and has a request submitted into the system to g= rant Sally access to the Nuclear Engineering data as well as Chemical Engin= eering data (Sally is not allowed to enter the request on her own behalf, b= ut the Dean's business manager has access spanning the entire Engineering S= chool, and can initiate the request on her behalf).
Because Sally's primary affiliation is with Chemical Engineering, the re= quest first must be approved by the Chair of Chemical Engineering - he must= authorize the adjustment of Sally's privileges within the system. The Chai= r, as a department head, has already been assigned a role allowing him to a= pprove privilege changes staff, and as an affiliate of the Chemical Enginee= ring department, he can exercise that role with employees of the department= . Once he provides his approval (through a web interface into the privilegi= ng system), the change request is automatically routed to the Chair of the = Nuclear Engineering department for his approval. Because the change to Sall= y's privileges involves granting her access to file requests on behalf of r= esearchers in his department, the Nuclear Engineering Chair must also provi= de his approval. Like his counterpart in Chemical Engineering, the Nuclear = Engineering chair has been granted a role allowing him to approve access re= quests within the system for "requestor" level access, and exercising that = role, he provides his approval through the privileging system's web interfa= ce, and Sally is immediately able to file access requests for PIs in his de= partment as well as in her own.
Later, when a new faculty member in the Nuclear Engineering department n= eeds authorization to access financial information pertaining to a grant fu= nd code for which he is the PI, he contacts Sally, who is able to initiate = the authorization process within the system on his behalf.
After the events in Use Case I above, Sally decides that while she enjoy= s working with the Chemical Engineering department, she would like to retur= n to working in Human Resources, as she did in a previous job. Not wanting = to lose her as a business management resource within the department, the Ch= air works out an agreement with her to have her take on the added role of p= ayroll clerk within the department (a function previously handled by the Ch= air's administrative assistant, John). The Chair has Sally work with HR to = initiate a request to remove the payroll approval role from John's profile = within the privileging system and another request to add that role to Sally= 's profile. Following his approval of both changes, the Chair is able to an= nounce that Sally has taken on the additional job of departmental payroll c= lerk for Chemical Engineering. Later, while Sally is in the HR system revie= wing pending payroll requests, she notices that she's not only seeing Chemi= cal Engineering requests, but she's also seeing Nuclear Engineering request= s. Concerned, she contacts the departmental IT manager, who explains that t= he system can't support her having one role in the Chemical Engineering dep= artment a different role in the Nuclear Engineering department without allo= wing her to exercise both roles within both departments.
The first use case above highlights two key features of the current NCSU= solution - workflow support for multiple, interlocking approval requiremen= ts, and hierarchical scoping of privileges.
In this case, a change is to be made that will affect the privileges of = an employee in one part of the organization, but that will affect access to= information associated with a different part of the organization. This sor= t of "interdepartmental" privileging scenario is not at all uncommon, parti= cularly in higher ed environments. The system recognizes that there are act= ually two separate approvals required for this change to be authorized - on= e managerial approval, permitting a change (any change) to be made to Sally= 's profile, and one resource approval, permitting a change that affects acc= ess to departmental resources within the system. Because Sally is not part = of the Nuclear Engineering department, the system requires approvals from m= anagement in both departments before the change is effected. This interlock= ing approval workflow is somewhat unique, and highlights the need for some = privileging systems to consider not only "ownership" of resources to which = subjects access is to be managed, but also the management of those subjects= as resources themselves.
For purposes of separation of duties (and, I believe, to address specifi= c concerns expressed by internal auditors) the system does not allow indivi= duals to initiate requests on their own behalf, but the system does recogni= ze the hierarchical structure of the organization, and reflects that hierar= chy in a way that allows privileges to be "scoped" to specific subsections = of the organizational hierarchy. Sally is to be granted rights at a departm= ental level, but a business manager in the Dean's office with school-level = access is able to initiate the request on her behalf. The Dean's business m= anager is not, however, authorized to approve either Sally's profile being = updated or access to the Nuclear Engineering department's fund codes being = modified - those approvals must come from individuals with separate approva= l roles.
The second use case highlights a key limitation of the current NCSU solu= tion - separation of roles and scopes.
Apparently as a direct outgrowth of the Peoplesoft paradigm for privileg= e assignment, the NCSU solution involves associating two sets of privilegin= g information with each system user - a set of roles (which control the ope= rations the user is authorized to perform within the system) and a set of r= ow-level access rules (which control the resources within the system which = the user can manipulate). Significantly, those two sets of information are = associated directly with the user, and are not linked with= one another.
In the second use case above, Sally is assigned an additional role by th=
e Chemical Engineering department which expands the operations she is autho=
rized to perform within the ERP to include approval of HR/payroll changes. =
That role gives her the ability to perform an additional set of actions