Shibboleth for Local Attribute Delivery

21 June 2007

IdP

Shibboleth with Backchannel

HS

AA

SP

WAYF

User 1

2345

6

7

8

9

10

11

Shib Attribute Delivery

AA

(SOAPserver onport 8443)

SP

(SOAPclient)

SAML Attribute Query

SAML Attribute Response

• Attribute exchange using SOAP over HTTPS encrypted channel

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>

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>

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

(SOAPserver onport 8443)

WebISO

Webserver

App

SAMLlibrary

User

2

1

3

4

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

Local Attribute Delivery

AA

(SOAPserver onport 8443)

App

SAMLlibrary

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