Shibboleth Developers

["Tom Scavo" <>]

On 9/21/06, Chad La Joie 
<>
 wrote:
> We've often heard two feature requests on the SP side of things:
>    - The ability to pull attributes from multiple sources (e.g. local
> databases, other attribute authorities, etc)

Will these local attributes be bundled as a separate assertion?  I
would think so since local attributes might be governed by policy
distinct from campus attributes.

>    - The ability to transform an attribute (e.g. base64 decode)
>
> For those familiar with the IdP you might say "isn't that what the
> attribute resolver does?" and of course you'd be right.  So I'm
> currently looking at including an attribute resolver in the SP.

Will resolver.xml be 100% compatible across the IdP and SP?  I see
this as a requirement.

> Like the current SP, attributes will be filtered based on
> an acceptance policy.

A separate policy file, right?  Separate assertions, separate policy.

> While I believe this model will allow the two uses cases above (and many
> more) to be met, I currently have no intention of shipping code that
> would allow people to contact another SAML IdP for attributes.  This is
> certainly doable, and the design is meant to allow that, but there are
> currently to many deployment specific variables to provide a useful data
> connector.

Not sure why this is causing you to lose sleep. ;-)  Once you add
local attributes to the mix, it's not that big of a leap to add
standalone attribute query.  In fact, a profile already exists for
that, so there are no unknowns.

> 2. How would developers expect to get at these attributes?

A requirement for us, today and in the future, is that all assertions
should be exposed at the SP.  This includes assertions received from
the campus as well as assertions issued locally.  Regardless of
whether or not the SP obtains assertions by push or pull, the payload
(whatever that is) should be the same, that is, complete
<saml:Assertion> elements, sometimes signed depending on how they get
used down the road.

> Other thoughts and comments on this?

Well, it might be useful (or not) if I outline the gateway push use
case that we're working on right now:

- Assume the gateway is *not* shib-enabled
- Bolt an IdP directly onto the gateway (no apache, no tomcat)
- Extend resolvertest so that it returns a complete attribute
assertion based on the configuration in resolver.xml
- Implement a similar tool called ssotest (or whatever) that returns
an authentication assertion based on the configuration in idp.xml
- Refactor the Shib IdP Tester (a GridShib tool) so that it returns an
attribute assertion (right now it returns a list of attributes like
resolvertest)
- Implement an X.509 binding tool that binds these assertions to an
X.509 proxy certificate
- Use the proxy certificate to authenticate to a Grid SP

There are three sources of attributes here: the local Authn Authority,
the local Attribute Authority, and zero or more remote AAs.  So there
are two or more assertions in this scenario.  Only the assertions
obtained from the remote AAs are signed.  All are bound (sequentially)
to the proxy cert.

Now shib-enable the gateway (our users find that step to be nontrivial
btw).  This provides yet another source of attributes.  To the Grid
SP, these proxied attributes (different use of the word "proxy") are
"less useful" than the attributes asserted by the gateway, so we nest
the former inside the latter using <saml:Advice>.

The point of all that was to say that we can use today's IdP
implementation to do attribute resolution at the SP.  Not sure what
the conclusion is, just FYI.

Tom