| | 1 | Distributed Group and Role Provisioning |
| | 2 | Statement of Work for deploying, configuring, and integrating Grouper at University of Alaska draft 2012-04-19 |
| | 3 | |
| | 4 | University of Alaska currently provisions group memberships and privileges for administrative users using an aging in-house developed tool ZUAUSR*. ZUAUSR is a legacy application providing key administrative functionality but with strong dependence on specific proprietary operating systems that are at or near end-of-life. We propose to replace this functionality with the adoption of a widely deployed standards-based supported product, Grouper <http://www.internet2.edu/pubs/grouper-infosheet.pdf>. This deployment will remove the unique proprietary OS dependencies that threaten existing operations and also enable extensions of current functionality not feasible with the current legacy product: |
| | 5 | |
| | 6 | • Remove proprietary OS dependencies |
| | 7 | • Deploy a product with a broad installed base and available external support |
| | 8 | • Incorporate current best practices and applicable de facto and formal industry standards |
| | 9 | • Provide for future enhancements by adopting a product actively enhanced and evolving to address new needs |
| | 10 | • Enable requested function of provisioning of group memberships and attributes - that is, enable provisioning to non-administrative users |
| | 11 | • Increase flexibility of adding roles or groups |
| | 12 | by adopting a modern structured architecture designed from the ground up for general and flexible use |
| | 13 | • Increase transparency of assigned permissions |
| | 14 | by providing enhanced user interfaces to view both the hierarchy of classes and the assignment of classes to individual users |
| | 15 | • Enable services to consume or utilize group memberships using defined interfaces to the classes database |
| | 16 | |
| | 17 | The work to be delivered is the following: |
| | 18 | • Deploy production and development instances of Grouper; |
| | 19 | "production" entails an instance tested and accepted for use with other UA systems, running on a redundant platform with active monitoring |
| | 20 | • Port the existing ZUAUSR superclasses to the Grouper database |
| | 21 | • Provide authentication and authorization to Grouper via UA-standard SAML IdP, verifying users with UA-Username & AD password |
| | 22 | • Port existing ZUAUSR superclass request forms (Oracle Forms) to a modern supported web-based forms connected to Grouper |
| | 23 | • Port existing ZUAUSR provisioning capabilities to connectors between Grouper and Oracle, LDAP, and AD |
| | 24 | • Documentation for all configurations, interfaces, and connectors |
| | 25 | • Knowledge transfer to OIT of maintenance and operation of Grouper, connectors, and interfaces |
| | 26 | |
| | 27 | |
| | 28 | -------- |
| | 29 | |
| | 30 | *ZUAUSR provides it group membership / permissions provisioning functionality via 6 key components that will be transferred to Grouper by this work: |
| | 31 | (1) database |
| | 32 | ZUAUSR maintains an internal database of attributes (that may be informally denoted variously as roles or classes or group memberships) necessary to do a certain (type of) job. The specific set of attributes necessary for one type of job is denoted a superclass. |
| | 33 | (2) connectors |
| | 34 | ZUAUSR can exchange specific data with Oracle, LDAP, and Unix systems; think of there being connectors between ZUAUSR and these other systems with which ZUAUSR needs to interact to execute its functions. |
| | 35 | (3) provisioning capabilities |
| | 36 | When an individual administrative user whose job requires it is assigned the appropriate superclass, ZUAUSR provisions (creates) accounts in other systems, populates group memberships in an LDAP directory, and/or assigns database permissions in Oracle to that user - in essence providing the technical ability of that individual to do that job. |
| | 37 | (4) workflow / authorization |
| | 38 | ZUAUSR maintains chains of authority or workflow: a request to assign a superclass (a set of attributes, roles, or group memberships) may require approval by another individual with the explicit authority to approve such requests. Not all requests require additional approval; those that do not may be provisioned directly, but those that do are provisioned only upon explicit approval by that authority. The designation of which superclasses require approval is maintained in the internal database (1). |
| | 39 | (5) user request interface |
| | 40 | ZUAUSR has a user request interface that enables security coordinators - those administrators who may assign superclasses to others - to request the assignment of specific superclass(es) to a user. |
| | 41 | (6) security coordinator user accounts |
| | 42 | ZUAUSR of course has it's own set of internal security coordinator user accounts - the people who can authenticate to ZUAUSR and make a request to assign a superclass to a UA identity; this is a small subset of all UA users, consisting of those users designated as security coordinators by their campus. |
