1 / 38

Cornell University

Cornell University. Central Authorization. Replacing a System that (sorta) Works. Tom Parker Project Manager Identity Management Team Cornell University jtp5@cornell.edu. Cornell’s Permit System. Also a Permit. Central Authorization at Cornell is generically handled by a Permit Server

lita
Télécharger la présentation

Cornell University

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Cornell University Central Authorization Replacing a System that (sorta) Works Tom Parker Project Manager Identity Management Team Cornell University jtp5@cornell.edu

  2. Cornell’s Permit System Also a Permit • Central Authorization at Cornell is generically handled by a Permit Server • Developed at Cornell and has been in use for over a decade • The Permit Server maps groups of NetIDs to “permits” • A permit is just a string token, such as “cit.staff” or “cu.student”

  3. It’s a List-based System Also a Permit On the Permit Server, we might see something like this table:

  4. How are Permits Obtained? • Whenever a new NetID is created during the hiring process (staff) • Whenever a new NetID is created during the the admissions process (students) • Service owners wishing to restrict a specialized service may request a permit for their application • They are given tools to manage their permit • They decide when to assign or revoke a permit for a particular user • That is, if they remember to do so…

  5. How are Permits Used? • Permits allow users to be put into “groups” • Students • Staff • Chess Club Members • These groups can be big or small • Application administrators can choose to use centrally maintained permits, or they may opt to administer their own. • Some are maintained by central IT staff • Who are the students? • Who are the staff? • Others are maintained at a departmental level • Who are the Human Ecology students? • Who can download certain licensed software? • Various applications (including CUWebAuth, our Apache module for doing web-based authentication) know how to query the Permit Server and thus use the central authorization system

  6. Permit Server Stats • Cornell has approximately 60,000 NetIDs. • There are over 800 permits but only about 325 are active. • Those active permits have about 300,000 memberships. • On our busiest day, there are about 375,000 queries to the permit server. • On that day the busiest minute has about 1,650 queries.

  7. Permits: High on Maintenance • Regardless of whether a permit is centrally or locally owned, the permit is maintained manually • There are a few provisioning scripts developed in-house which cause a basic set of permits to be issued when NetIDs are created • Regularly scheduled “clean up” processes are in place to remove permit entries when a user’s association with the university changes • student graduates • student changes to employee • employee changes to student • Employee is terminated • Currently there is no way to automatically manage permits

  8. MODERN Permits: Low on Features • AdminUI designed for the 1990s • No automatic memberships • No limitations, expirations • Limited delegation features • Users can’t see what permits they have • Permits can’t do negative authorizations • For example, an institution may want to offer a service to all active students but only within the United States due to export regulations.. • No self-enrollment options • Anyone (or anything) can be included in a Permit List • No checks for misspellings or formatting errors

  9. So, we love Permits, but.. • We recently had to restructure the on-line course registration application because it was crashing the Permit Server. • We are starting to need more features, and a more modern system.

  10. I2 Authorization Initiatives • Grouper (group-based membership) • Signet (privileges and limitations) • Shibboleth (open source implementation to support inter-institutional sharing of web resources subject to access controls)

  11. I2 Overview Maps Nicely to CU

  12. Grouper • Cornell was following Grouper development efforts. • Grouper seemed like it might be a possible replacement for the Permit Server. • We looked into Grouper a little bit more and liked what we saw!

  13. It’s a Group Management Service • A common user interface and standard API for managing groups. • Users can easily see what groups they are members of. • Users can create and manage their own groups.

  14. A Few of the Grouper Features that the Permit Server Doesn’t Have • basic group management by distributed authorities • subgroups • composite groups - groups whose membership is determined by the union, intersection, or relative complement of two other groups • traceback of indirect membership • a future version of Grouper will include aging of groups and memberships • Self enrollment and unenrollment • LDAP provisioning of group membership information • Uses existing repositories for subject sources

  15. Why Grouper for CU? • Grouper’s LDAP provisioning connector plays nicely with our campus-wide electronic directory. • For other in-house applications we can use a web-service to obtain group membership information directly from Grouper. • A big one for us: Grouper supports a delegated model of control

  16. Cornell’s Project Mgt. Methodology • Bringing some corporate rigor to campus but in a way that remains appropriate to a university environment • Requirements • Use Cases • Communication Plans • Project Planning • Migration strategies • Thorough testing • Rollout Planning

  17. Lots of Up-Front Document Work Project Charters Initiation Plans Project Planning

  18. Steering Committee, a Key Component

  19. Fit-Gap analysis between Permit Server System and Grouper Early versions of Grouper running in test Emphasis on discovery and use cases Built and tested scripts to migrate permits into Grouper Modified UI for Cornell look and feel Requirements gathering - over 30 meetings Initial Investigations

  20. Understanding the Requirements

  21. Relatively Easy Subject sources UI requirements Logging needs Cleanup utilities Updater utilities Communications Infrastructure updates Test plans Security User documentation Business processes Availability Not So Easy Query mechanisms Namespace Migration planning Requirements,some easy, some not…

  22. Two Problems Loomed Large • Defining a namespace • Of 30 Requirements-gathering meetings, eight were devoted to defining the namespace • Migration strategy • How would we roll out a new campus-wide system without causing undue interruption to current services (or for that matter, any interruption whatsoever..)

  23. Defining a Namespace • Grouper will likely handle many different types of groups. • Some groups will be used to make authorization decisions • Some may be used for non-authorization activities such as generating email lists and calendaring. • When someone requests that a new group or stem be created, we will need a process for defining • where in the Grouper name-space the new stem or group should be placed • what it should be named.

  24. Our Namespace Strategy • Define a basic name-space of stems in which new groups can be created so that as soon as we switch from using the Permit Server to using Grouper, we will be ready to create new groups. • Designate one or more people from each Cornell unit as the “owner” or “stem administrator” of their unit’s name-space. • In this way, we would be pushing authority to the departmental units and each unit could decide how they want to administer their Grouper stem.

  25. Orthogonal Views of Delegated Authority • HR View of Delegated Authority • Division Department, Unit, Job, Position, • Also Role, Project, or other notions of responsibility • Matrixed & non-matrixed • Fiscal Responsibility View(s) • Role-based: Fiscal Officer, Account Manager, Account Supervisor • Org Hierarchies: Responsibility Centers, Divisions, Departments, Units • Account-based: Chart of Accounts, Account, Sub-Account, Object Codes, Project Codes, etc. • Academic View(s) • College, Department, Program, etc. • Statutory vs. endowed • Project-based (crosses all of the above) • Research View(s) • Closely related to, sometimes the same as, Academic view(s) • Based on Funding Source or… • Based on Signature Authority • Or Project-based • Issues For All • Delegation, Matrixing, Effective-dating (time boxing), etc. • Resolution of orthogonal views (cross-walking multiple Orgs) • Base the multiple views on administered data in enterprise sources

  26. Research Unit Reference Chart • Office of Institutional Planning • Structure designed to provide a view of delegated authority at the organizational entity level from the Board of Trustees view • Currently updated every Spring • Willing to maintain this if users signed up to the idea • Partly because the structure below Unit Name is political not logical, and therefore unfathomable….. • Affiliates (have their own tree) • RURC has 48 Units • Decent representation (ITMC)

  27. Our Migration Strategy • Phased approach • Phase One: Permit Server replacement (I2 Grouper) • Phase Two: Privilege Management (I2 Signet) • Making the Permit Server replacement as transparent to users as possible • Application administrators can switch to native Grouper at their convenience (if they don’t take *too* long - maybe a little over a year) • Staged rollout of new features • New features come later • Incl. addition of automatically provisioned groups

  28. Transparent Cutover (Current view) • Transparent cutover of Permit Server to Grouper • System owners and application developers migrate at their convenience

  29. Transparent Cutover (Developer’s view) • Transparent cutover of Permit Server to Grouper • System owners and application developers migrate at their convenience

  30. Transparent Cutover (Proj. Mgr’s view) • From a Project Manager’s point-of-view, a simple shim that fixes everything has a lot to offer..

  31. Transparent Cutover (Proj. Mgr’s view) • The only feature I could think of to add…

  32. The Shim is just an Emulator • Runs on same server and port as permitd • Understands Cornell’s Stateless Server protocol (cussp) • Translates cussp queries and updates into Grouper API calls • Translates Grouper messages into cussp • Applications talking to the Permit Server won’t know the difference

  33. Our Current Timeline For Example: General requirements New use cases Business processes Cornell project Interdependencies Application-specific requirements Name space conventions Roll-out requirements Back-out strategy Security For Example: Fit-gap analysis Permit server log analysis Testing with I2 Applications Working Group participation Known use cases Requirements Signet available For testing Discovery (you are here) ‘06 ‘07 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec Jan Feb Mar Apr May Jun Requirements Sign-off Phase One Requirements Project Planning Target Cutover Phase One Grouper

  34. We’re re-skinning the Grouper native interface

  35. Continued Campus Communications…

  36. Questions? 300 Pound Giant Grouper Project Manager looking for Grouper

  37. Questions? …is actually daydreaming about Permit Shim

More Related