2010 ACAMP Identity Services Summit

The Second Advance CAMP Identity Services Summit was held on June 23-25, 2010, in Raleigh, NC, co-sponsored by Internet2, Jasig, Kuali, and ISOC. Participants posted fairly extensive meeting notes on the site. Here are some highlights from my own informal notes (not vetted, and sometimes involving areas I know little about, so take them as launching points rather than as gospel).

Social networking in higher education

• Let's distinguish external social networking from internal social network. External is what most of the university commnity uses now.
• "Yes, but recently our students were spammed with an email announcement about a new (and unauthorized) campus-specific portal/social site, and 300 students had joined by the time it got taken down. There's apparently a real need." (After all, Facebook started as Harvard-only.)
• U. Toronto has an internal social networking site.
• "One of the main reasons to go to college is to have a place to make stupid mistakes safely. Facebook isn't a safe place."
• The idea is more attractive if there's rich integration with other campus services.
• OpenID can always be used for guest accounts.
• Alternatively, you could write a Facebook app specifically for your school's data. There are a few examples. And you can embed Facebook functionality & ID into arbitrary pages on web.
• That sort of thing is done a lot at Stanford. For example, faculty post their office hours on Facebook.
• Drupal also has some modules to help with that. OpenSocial just has friends but Drupal has relationship modules, including asymmetrical relationships and sharing by relationship type.
• MySpace has received no queries from universities, though.
• Some schools use Twitter as a notification service. Which causes confusion when university staff members also tweet as individuals.
• OpenSocial gadgets are isolated from each other & the container at present. OpenSocial 1.1 (due in November) includes some inter-gadget communication with events, possibly with a full Activitystrea.ms implementation (dependent on JSON spec of Atom Pub). A context-aware piece is not there yet. Google Wave has a extended gadget API to access all the data in the Wave; we're trying to get Google to formalize the spec.
• UBC has MediaWiki + Wordpress integration with RSS/Atom pubs.
• Another school plans to use Liferay to do something similar at business school in autumn.
• "How much does Facebook live chat get used?" "Varies, but students typically use multiple IMs. Most turn it off though, to avoid being monitored."
• There's also a system that allows Stanford-authenticated anoymous course ranking.
• There's also faculty interest in social networking for serendipitous discovery: publication trackers, self-authored CVs, tagging, etc.
• It's not too early to talk with social networking companies about attributes integration in both directions. A perfect opportunity would be the Internet Identity Workshop in November.

Group and role integrations - General

• The Kuali Identity Management (KIM) team will "revisit getting a standard API for groups."
• The COmanage project has blazed a trail on federated group management. There are two concepts in play: Multiple group sources (someone new signs in from another campus and is then added) and multiple groups from the same source.
• Federated groups have become part of the Brown roadmap due to requests from researchers and faculty to open up access to wikis or the course management system. To date, the answer has been to issue guests a Brown ID.
• Library resources are another area for federated memberships.
• "Friend" is an important factor in online life in a university – relationships over time, across campuses, etc. But we need a way to start integrating relationship types / Facebook lists / OpenSocial groups.
• The key when dealing with role conflicts is to be explicit on the resolution rules. E.g., "teacher" role always trumps "student" role. Start establishng policies, even if they're experimental at first. And always try to think in terms of added privileges rather than denied privileges, except for blacklisting.
• As part of the MACE-paccman effort, Chris Hyzer has proposed a generic model for an authorization API based on recent Grouper work.

The Grouper project

• Kuali Rice can now use Grouper to handle group & ID services. Kuali still holds the workflow history.
• Grouper 1.5 was released last winter. Added:
  • A lighter one-screen UI for easier administration links from other applications. (1.6 adds skinning and replaceable text.)
  • Auditing.
  • Move and copy (along with underlying permissions, etc.).
  • Notification. (1.6 adds optional notification of flattened group.)
  • New attribute framework, with attributes supported on virtually any entity (including attribute assignments).
  • Roles and permissions built on attribute system: a "role" is a group associated with permissions. Not just RBAC, though: permissions can also be assigned to individuals. Permission is a triple: subject + qualifier + resource. The idea is that you might periodically export permissions info into your application DB, or ask the web service for permissions at run time. There's a limited "act as" capability to change roles.
  • Shibboleth integration: attribute resolver.
  • Performance improvements.
  • Membership dates.
• 1.6 on its way out now.
  • Subject support.
  • Context-based groups.
  • ESB integration through the notification engine: send XMPP message or contact this web service address on specified events; listen for events from external system.
• On the Roadmap, maybe by next winter:
  • Permissions and attribute UI.
  • Integration with uPortal, and possibly dependency of uPortal on Grouper.
  • Improved auditing and reporting.
  • Rule-based actions: for example, negotiated merges like "if member explicitly removed, don't automatically re-add member."
• Penn will try to deploy always-available Grouper web services.
• "So 'permission managment' means privilege management over resources?" "Yes. The term 'privilege' was already used for Grouper-internal actions, so a different word for external applications' use was needed." The goal is highly efficient resolution across hierarchies. E.g., a role can inherit permissions from another role; there are resource structure hierarchies (if you can read all documents in English Dept., can read document in English 101); and there is a hierarchy of permissions themselves.
• "Has anyone integrated Grouper with Google Apps Ed?" "Not yet."
• Attributes discussion
  • Type and attribute definitons used to be effectively global, but you can now define attribute permissions within a folder tree without polluting other spaces.
  • "I wonder if we could use attributes on folders to integrate with rule engines." "Overloading the attributes might become a UI issue."
  • "Use to implement tags that can cut across hierarchies?" "That was one of the goals, to give some way to call out cross-hierarchy distinctions like 'These are for this application; these are for students...' A 'Domain' attribute type is defined specifically for that sort of tagging."
  • UNC Chapel Hill is actively exploring possible uses of attributes. Watch (and contribute to) the wiki for use cases and sample Grouper shell code.
  • Currently you have to use Grouper shell to work with attributes. There's not a UI in 1.6, but hopefully in next release. The delay is in removing the code for old-school attributes.
• How do we handle federated memberships? The first step is usually to support external users in internally managed groups. Registration, invite, bulk load are all approaches that make sense. All you need to add a user to a group or give a user a permission is the user Subject, whose source can be your own IdM instead of Grouper itself. There are a couple of project integrating external users with Grouper.

Person directory

• Is it time to give up arguing the fine points and just accept that email addresses (despite all their issues) are becoming the de facto universal user ID? WebFinger / XRD may be becoming the de facto universal person directory.
  • Which loses most of the privacy battle?
  • What about the campus bureaucracies who insist on student ID rather than email? Despite them, your multi-campus or world-wide application will need some way to deal with people who don't have student ID numbers.
• There's a person picker in Grouper, including the ability to choose what attributes get passed.
• Reminder: OpenRegistry is under active development.

Identity management

• Even with "closed" grant-funded projects, OpenID integration might be needed to meet requirements for public comments.
• Shibboleth 2.0 had planned to include OpenID support, but then lost the developer to Google. Since then the community has split, reducing the attractiveness of the effort: OpenID Connect has gained ground thanks to the OAuth connection and OpenID 2 is looking like a lame duck. But if the Feds start insisting on OpenID 2, then that would be a strong argument to support the protocol. Meanwhile, OpenID "next" has got such an ambitious list of goals that it's started to look like SAML.
• Paul van Dijk described COIN (Collaboration Infrastructure) from SURFnet. They federate many sources of ID at this point (including Google Apps, although group context provision isn't there). Initial applications will include Alfredo & Liferay; possibly WebEx and others; probably 5 by the end of the year.

Non-web-based (no cookies) software

• In Europe, Asia, and Australia, eduroam is becoming a non-grid non-browser "killer app".
• Inter-domain scheduling outside the browser is increasingly important.
• The break-out meeting was reported as fairly depressing, but a couple of tasks might be Google Summer of Code candidates. It's not that there are so many application-specific approaches. Instead, there are imperfect common approaches that don't work everywhere.

Google experiences, rumors, and speculation

• A growing number of campuses are signing up for Google Apps Education for Sites, Docs, and email integration.
• Over the last 12 months, integration services (particularly for groups and roles) have evolved rapidly. Some schools now bring over course enrollments; U. Washington is planning something like this in autumn.
• Doesn't GAE force a Google identity rather than a site identity? No, not always. If your domain is integrated with Google Apps, you get prompted to log in at your institution.
• SAML can be used to get into Google, but then don't you either need to stay within that institutional domain or use the Google identity domain? No; if there's another school that uses SAML for integration, you get IDed by your original institution when crossing domains. (A real-time experiment was improvised, which confirmed that GAE could be used to share data across SAML domains.)
• Coming up: iGoogle for organizations / education?
• In general, there's a desire to shift from hundreds of one-off app integrations to deeper integrations of third-party logins with all Google services, including GMail, without the current email verification step). There's already been a demonstration of Google Doc sharing via Yahoo OpenID. An OIX-maintained list could control trusted providers. SAML isn't likely to get much more attention at this point.
• Meanwhile, various private negotations with Google on group integration continue.
• "How do you bring SAML-enabled InCommon members into Google if they don't have contracts with Google?" "Any possibility of Google joining InCommon?"
• "We're integrating campus groups into Google: we filter our info and then import it into Google groups. Instructors are able to email their class, for example. Every night a process reconciles based on SQL-stored course enrollment. Besides students, we're uploading "natural groups": departments, ad hoc groups, and query-based groups. We're planning for transaction-based updates to provisioning. We've been in production for a couple of months. Combining multiple group management domains (students vs. staff) with shared sites has been a bit buggy, but GAE just today announced better cross-domain support. Remember that there's no guarantee on a fast response at Google, though. And there's still no API to find a single shared contact, have to loop through list."
  • Any issues with policy controls? "Not yet. But there are issues around nested groups: you have to an owner of the subgroup to mail its members. Also, if you enable Google Groups for your domain, people can remove themselves from externally-managed groups; reconciliation routines have to undo that."
• There's a way to protect the membership list from access by members. Calendaring is another story, though. All users in a calendar event are visible by default, and you'd have to override by individual. Until just recently, you couldn't hide people from Directory, either.
• "I've heard complaints about the Google API being throttled down." "Such throttling is one reason we were interested in just-in-time provisioning, as a workaround for not being able to provision all class enrollments. After four or five threads, performance seemed to decline rapidly." "In some other Google APIs, performance guidelines are published. Might be worth a prod."
• Because Google Apps integrations are based on a business relationship, the security constraints differ from those of a social networking ID or Google-hosted accounts.
• The best Google contact point for a representative of an open source project like Sakai would be Google Developer Relations. The public mailing list is the place to start.

General ID service provision strategies

• "Typically there are several categories of service provider clients (on-campus and trusted or external). We release sets of attributes based on category to reduce administrative overhead." "Tiered services" are popular in this crowd.
• "We prefer to draw up specific contracts for specific clients."
• It's difficult for application developers to code around optional attributes, and usability studies aren't kind to line-item vetos: better to either provide them or not, and for applications to plan around coarse-grained service levels."