1. Shibboleth for Local Attribute Delivery 21 June 2007

2. Shibboleth with Backchannel WAYF 5 2 4 3 User 6 1 IdP 7 HS SP 8 9 10 AA 11

3. Shib Attribute Delivery • Attribute exchange using SOAP over HTTPS encrypted channel SP(SOAPclient) AA(SOAPserver onport 8443) SAML Attribute Query SAML Attribute Response

4. SAML Attribute Query <Request … IssueInstant=“2007-06-19T12:12:12Z” … RequestId=“_50e5776dca6345c77987a4c22”> <AttributeQuery Resource=https://sp.wisc.edu/shibboleth> <Subject xmlns=…> <NameIdentifier Format=“…shibboleth:1.0:nameIdentifier” NameQualifier=https://idp.login.wisc.edu/shibboleth> mrosz </NameIdentifier> </Subject> </AttributeQuery> </Request>

5. SAML Attribute Response <Response … ResponseID=“_e4a2475bc5437b89ac866c66d59efdc6”> <Status> <StatusCode Value=“samlp:Success”></StatusCode> </Status> <Assertion …> <Conditions>…</Conditions> <AttributeStatement> <Subject xmlns=…> </Subject> <Attribute AttributeName=“givenName”> <AttributeValue>Roszkowski</AttributeValue> </Attribute> </AttributeStatement> </Assertion> </Response>

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

7. Local Attribute Delivery WebISO 3 User 4 1 2 8 Webserver AA(SOAPserver onport 8443) App SAMLlibrary 5 6

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

9. Local Attribute Delivery AA(SOAPserver onport 8443) App SAMLlibrary 1 2

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

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

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

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