Shibboleth and uApprove at University of Michigan Luke Tracy – ltracy@umich.edu Ken Hammer – khammer@umich.edu

What is uApprove? Developed by SWITCHaai under BSD License Purposes: http://www.switch.ch/aai/support/tools/uApprove.html Purposes: For the user, mechanism to be informed about the release of attributes to a Service Provider (SP). For the admin of an Identity Provider (IdP) Provides a tool to implement data protection laws by requiring to obtain user consent before personal attributes are released to a SP Allows for collection of information about the release of attributes and accesses to SP (if configured to do so). Source: http://www.switch.ch/aai/support/tools/uApprove.html on June 15, 2010.

What is uApprove? From the user's point of view, uApprove is an application which presents a webpage, on which to accept or decline the Terms of Use of a Shibboleth Identity Provider upon first access to the system (optional) globally accept the release of attributes to any/all Service Providers accept the release of attributes upon first access to a given Service Provider (if the global release has not been approved) Note: User can reset attribute release consent on a separate webpage, such that he/she will be asked again, whenever attributes have to be released. Source: http://www.switch.ch/aai/support/tools/uApprove.html on June 15, 2010.

U of M Attribute Release InCommon IdP had been operating in Pilot Mode Opt-in required Temporarily provided means to approve the release of identity data To move beyond Pilot Remove barriers Make more self-describing

Governance Board Investigated how others were handling privacy concerns around attribute release Found common desire existed to be able to have individuals approve the release of attributes Saw mention of uApprove being used within SWITCH Demonstrated uApprove to IDM Governance Board Liked it, but had issues with changes to data and privacy settings after approval to release Looked into methods of detecting state changes and forcing re-approval

uApprove Determined best method was to prompt each time (until a more elegant solution was possible, maybe) Discussed with uApprove developers method for forcing prompt every time Decided together that in short term, using database triggers was optimal

Demo

User Visits Site and Selects Home University

User Logs In Using Our Single Sign On Tool

User is presented with the uApprove screen

If the user declines…

If the user approves…

uApprove configuration Can use a flat file or a mysql database for preferences Can be disabled on a per-SP basis Can configure which attributes are displayed and in what order Optional “Terms of Use” screen Multiple options for resetting preferences By default, uApprove will display all of the attributes that are being released to a particular SP, in the order they’re defined. You can customize the order, or suppress fields in the uApprove configuration (uApprove/attribute-list) - We hide attributes that we think the users would find confusing (eduPersonEntitlement, ePTID) uApprove can display a “Terms of Use” screen, which requires user consent. We turned that off. uApprove can use a flat file for preferences, or a mysql database – why does it need one? What does it track? - 4 tables – used to track when a user has accessed a site, when they last approved access, etc - normal configuration – show up on first visit for every site, or only once ever uApprove can be disabled totally on a per SP basis. uApprove offers two means of allowing users to reset their preferences – either by adding a checkbox to whatever is providing the shibboleth login screen, or by means of a directly accessed application (they’re really two paths into the same app).

Normally, uApprove looks like this… Presentation controlled by .jsp templates Template text strings stored separately to make translation easy This can be customized by deflating the .war file. Application presentation is handled by a number of templates in the form of .jsp files. We were able to apply our SSO’s skin to uApprove by altering the header and footer files. The text strings used to populate the templates are available in WEB-INF/classes. SWITCH wrote uApprove with language localization in mind.

U-M localizations Database trigger / cron job combination to effect our desired login behavior Applied our SSO “skin” to the application Changed text to better suit our audience The first time someone logs into an SP, an entry is inserted into uapprove.ProviderAccess and uapprove.AttrReleaseApproval. On subsequent logins, those tables are checked, and if entries exist, the “digital id card” is not displayed. Originally wanted to add a configuration switch that would allow us to display the attribute approval screen every time, presumably by preventing the database inserts. We contacted SWITCH with this feature request, and told they were re-architecting the software. Together, we came up with the idea of using database triggers to delete the inserted records, creating the desired effect. We based our solution on the application SWITCH provides for resetting user preferences. uapprove.ProviderAccess - this is the important one uapprove.AttrReleaseApproval Originally planned on using two triggers.. Trigger on INSERT into uapprove.ProviderAccess BEGIN DELETE FROM AttrReleaseApproval where idxAttrReleaseApproval = NEW.paIdxAttrReleaseApproval; END 2) Trigger on INSERT into uapprove.AttrReleaseApproval This didn’t work, because both events happen simultaneously. We resulted in using a single trigger in combination with a cron job that periodically deletes entries from the uapprove.ProviderAccess table.

attribute-resolver.xml <resolver:AttributeDefinition id="displayName" xsi:type="Simple" xmlns="urn:mace:shibboleth:2.0:resolver:ad" sourceAttributeID="displayName"> <resolver:Dependency ref="mcomm" /> <resolver:DisplayName xml:lang="en">Full Name</resolver:DisplayName> <resolver:DisplayDescription xml:lang="en"> This is your full name. </resolver:DisplayDescription> ... </resolver:AttributeDefinition> uApprove will allow you to replace shibboleth attribute names with “user friendly” strings by adding child elements to the attribute definition elements. E.g. <resolver:DisplayName xml:lang="en">Full Name</resolver:DisplayName> uApprove will also allow to provide a “hover” with further explanation, again by adding child elements to the attribute definition. E.g. <resolver:DisplayDescription xml:lang="en">This is your full name.</resolver:DisplayDescription> The same elements can be used for language localization.

resources uApprove - http://www.switch.ch/aai/support/tools/uApprove.html U-M InCommon Attribute Release Policy and Procedure - http://www.itd.umich.edu/itcsdocs/r1465/