Shibboleth for Local Attribute Delivery 21 June 2007

IdP Shibboleth with Backchannel HS AA SP WAYF User

Shib Attribute Delivery AA (SOAP server on port 8443) SP (SOAP client) SAML Attribute Query SAML Attribute Response Attribute exchange using SOAP over HTTPS encrypted channel

SAML Attribute Query <Request … IssueInstant=“ T12:12:12Z” … RequestId=“_50e5776dca6345c77987a4c22”> <NameIdentifier Format=“…shibboleth:1.0:nameIdentifier” NameQualifier= mrosz

SAML Attribute Response <Response … ResponseID=“_e4a2475bc5437b89ac866c66d59efdc6”> … Roszkowski

For “local” Attribute Delivery Set up a Shib IdP/AA that uses PrincipalNameIdentifier as the NameIdentifierMapping Develop scripts/programs that can take as input a NetID and package it into a SAML attribute query and deliver the query to the AA using SOAP over SSL Certs provide the “authentication” for this service.

Local Attribute Delivery AA (SOAP server on port 8443) WebISO Web server App SAML library User

Local Attribute Delivery User requests a protected resource from campus web server User authenticates via WebISO Application takes NetID from the HTTP response and submits attribute query Response from AA contains attributes for that NetID; attributes returned to application Application uses attributes to make authorization decision and either delivers content or denies access

Local Attribute Delivery AA (SOAP server on port 8443) App SAML library 1 2

What does it get us? Works for both web-based and non-web-based applications MST spends considerable time working on web services to provide attributes Clients are set up with the proper certs (we could probably use webservices certs and CA) to look like an SP and must handle the SAML conversation No configuration of attributes on the client (except in the app which will consume them)

What does it get us? (cont.) MST controls which attributes are released to which SPs via standard Shib ARPs To release a new attribute to a client, we just edit the ARP on the IdP We already have the infrastructure to issue certificates Shibboleth supports multiple data sources for attributes: some could come from LDAP, some from UDS

On the other hand… Requires sample code for each target platform/language (likely need Perl w/ SOAPLite for Unix/Linux, Java, and.NET for Windows) Requires that we manage another namespace (shib ProviderIDs)

Why not just use Shib? Allows non-web apps to get attribute information from UDS Incremental approach: allows existing Pubcookie app servers to use attributes for authZ decisions Platform support is about the same for Pubcookie and Shib SPs Preserves investment in Pubcookie