Enterprise Authorization Working Group - 2008/05/12 Meeting

 Attendees

• John R - Engineering
• Dana W - NACS
• Josh D - AdCom
• Neil M - AdCom
• Beth H - Communications
• Jim K - Communications
• Erik O - Student Affairs
• Steve C - Health Affairs

Discussion

• Everyone gave introductions and background to Steve. We are looking at either vendor or open source options for enterprise level authorization on campus. Health Affairs uses Microsoft solutions.
• Josh gave debrief of conference call with Signet leaders.
  • Spoke about the features we feel are currently missing and their future roadmap
• Josh gave debrief of conversations with Albert from UCLA
  • UCLA is planning to deploy Grouper first this fall for their course management systems mainly just incorporating automatically generated groups from institutional data. Will look into manually created and managed groups next year. They will expose Grouper data via Shibboleth. They will do minimal Grouper UI customizations for initial rollout (skinning mostly), with planned new custom written UI next year. Will begin looking at Signet after Grouper in the fall to replace their DACSS system.
  • AdCom plans to keep in touch and look for partnerships in new development with UCLA and Grouper community, or at the very least share how they define their groups as there will be much similarity of institutional data groups between campuses.
• Discussed whether following a similar rollout plan would work for UCI. Would Grouper by itself meet any of the needs of the campus?
  • Josh mentioned AdCom could use Grouper by itself in a couple of its applications that just need group management, but it could not replace SAMS or be used for access control.
  • John mentioned that it wouldn't be useful, needs something like Signet to assign permissions specifically, not to automatic groups.
  • Dana will check with EEE group
• Steve mentioned that they use Active Directory and a password synchronization production called P-Synch to manage access controls. It allows them to have a single password for everything and they use a Microsoft based web administration tool to change access control permissions in the AD. For 40K+ users, it costs between $2-3 per user with 20% annual support/renewal.
• Dana gave an update on the vendors. He called Novell three times and no one has gotten back to him. No useful response back from Sun either. Sun would require the whole identity management suite, $100k+ to start with overhead of maintenance.
  • It is unlikely anyone has any funding for a vendor solution this year.
  • It was mentioned that someone with a Java background could help NACS or Health Affairs, both of which have tried to evaluate the Sun solution but found it too difficult to initially install and setup. If the issue is with Java related knowledge this may be true. Neil has gone to a conference where they set it up before, although difficult, it may be worth one more try before giving up completely.
• Erik went to JA-SIG and talked about a presentation Duke gave about Grouper. They took a phased approach as well. For the first phase they had auto-generated groups based on institutional data only. The central IT controls it, with feeds from Registrar, Payroll, etc. They found the UI lacking, using it to tweak the auto-generated groups for exceptional cases. They currently have over 104,000 groups and it takes hours each day to update from batch feeds. They create groups for each course, and each teacher/student/TA group for each course, for all classes in the past four years. Not sure if they will look into implementing Signet as well in the future.
• So assuming vendor solutions are too expensive and/or complicated, and we go with Grouper Signet...
  • We need to create a high-level project plan and get official commitments from workgroup departments with phases, timelines, and real use-cases.
  • Could we follow a similar model as other universities and deploy Grouper based on institutional data first, and then custom groups and finally Signet? It seems like the most practical approach although would not meet the complete needs of people right off the bat.
  • We need to decide which groups should be defined at first. Obvious choices are to start with institutional affiliations, other grouping attributes that were defined in the campus LDAP meetings, and go from there.
  • It would probably make sense to include Scott or someone from Registrar in these discussions as access to some groups (i.e. FERPA covered) must be controlled properly. Since they are the source of institutional data feeds that generate Grouper groups it may not be appropriate for NACS to speak for them.
  • Student affairs could integrate this new Grouper service with their uPortal groups in the student portal. Communications could also use for an Events Calendar system.
  • Dana could ask Max and the EEE group what kinds of data they would find useful.
• It would need to be decided eventually who would host Grouper/Signet, administer it, and maintain it with both core updates from the open-source project as well as all the custom development that would need to be added.
  • Dana thinks NACS should host Grouper/Signet in the long run with some help of custom coding and software maintenance.
  • Josh mentioned that both Grouper/Signet administration and maintenance would require Java knowledge.
• Breakout group to discuss UCCSC presentation.

Action Items

• Everyone will go back to their department heads to get an official commitment to the project going forward also clarifying their needs, expectations, and amount of resources they could contribute.
• Josh/Neil continue to keep in the loop with the Grouper/Signet workgroups as well as UCLA.
• Dana touch base with NACS EEE team to gauge their requirements and interest.
• Neil work with Dana and/or Steve to try to get Sun Access Manager up and running?