Download - Shibboleth for Local Attribute Delivery
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