Shibboleth Developers

[Chad La Joie <>]

Tom Scavo wrote:
> 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.

No, just like the IdP the resolver isn't going to return assertions, 
just lists of 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.

Unknown at this time.  I don't know why it would be a requirement, I 
can't imagine that you'd ever encounter a case where you wanted to copy 
one from the other.  That said, I do think that for support reasons they 
should be compatible if possible.

> > Like the current SP, attributes will be filtered based on
> > an acceptance policy.
>
> A separate policy file, right?  Separate assertions, separate policy.

I don't care how many assertions there are, the policy just evaluates a 
pile of attribute objects.

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

There are currently no profiles that I know of for doing this unless 
liberty has an inter-provider account linking spec (which may be part of 
disco/profile service, I don't know).

> > Other thoughts and comments on this?
>
> 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.

Then write a data connector to fetch and process the information and 
expose a pile of attributes.  I don't care about the format/data 
structure the attributes are read from, that's the connectors job to 
figure out.
--
Chad La Joie             2052-C Harris Bldg
OIS-Middleware           202.687.0124