shibboleth-dev - RE: Java SP Architecture: Attribute Resolver
Subject: Shibboleth Developers
List archive
- From: "Scott Cantor" <>
- To: <>
- Subject: RE: Java SP Architecture: Attribute Resolver
- Date: Thu, 21 Sep 2006 15:52:23 -0400
- Organization: The Ohio State University
> 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.
I would think not, as this is not about creating assertions at all, but
about unifying a pool of data between what you get from a SAML source and
from other sources into just "data".
It's a way to abstract the SAML part itself behind a different interface,
the resolver layer. Something I think probably makes sense in Java, although
I haven't ever really seen anybody ask for it.
> > Like the current SP, attributes will be filtered based on
> > an acceptance policy.
>
> A separate policy file, right? Separate assertions, separate policy.
That's not how the AAP design works now, multiple policies simply stack.
Policies are not discrete based on issuers, they're based soley on
attributes and are combined into one set of rules that all run together.
> 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.
It works well with global identifiers and no privacy, and is impossible
without them, without much more work.
> > 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.
That's an entirely different issue, though. Developers don't want to go
parsing SAML assertions in most cases. We're talking about cooked data,
which is why XML values are so bad.
Exposing assertions is for cases where you have SAML inputs to things like
an XACML engine, or need the security tokens to invoke ID-WSF services.
That's a fairly different set of use cases from what I see Chad talking
about here. I can't think why in most cases anybody would want local data
sucked in and turned into SAML. It's more usable in the original form,
probably.
-- Scott
- Java SP Architecture: Attribute Resolver, Chad La Joie, 09/21/2006
- Re: Java SP Architecture: Attribute Resolver, Tom Scavo, 09/21/2006
- RE: Java SP Architecture: Attribute Resolver, Scott Cantor, 09/21/2006
- Re: Java SP Architecture: Attribute Resolver, Tom Scavo, 09/21/2006
- RE: Java SP Architecture: Attribute Resolver, Scott Cantor, 09/21/2006
- Re: Java SP Architecture: Attribute Resolver, Tom Scavo, 09/21/2006
- Re: Java SP Architecture: Attribute Resolver, Chad La Joie, 09/21/2006
- RE: Java SP Architecture: Attribute Resolver, Scott Cantor, 09/21/2006
- RE: Java SP Architecture: Attribute Resolver, Scott Cantor, 09/21/2006
- Re: Java SP Architecture: Attribute Resolver, Tom Scavo, 09/21/2006
Archive powered by MHonArc 2.6.16.