1. Shibboleth and uApprove at University of Michigan
Luke Tracy –
Ken Hammer –

2. What is uApprove? Developed by SWITCHaai under BSD License Purposes:
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: on June 15, 2010.

3. 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: on June 15, 2010.

4. 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

5. 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

6. 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

7. Demo

8. User Visits Site and Selects Home University

9. User Logs In Using Our Single Sign On Tool

10. User is presented with the uApprove screen

11. If the user declines…

12. If the user approves…

13. 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).

14. 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.

15. 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.

16. 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.

17. resources
uApprove -
U-M InCommon Attribute Release Policy and Procedure -