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 17:10:47 -0400
- Organization: The Ohio State University
> > 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.
>
> I gave a use case in my previous e-mail. An IdP Proxy is another use
> case. These two use cases are related, in fact.
An SP's job is not to generate assertions. I can't see how that could be
considered a controversial position to take.
If you have SAML assertions in hand from someplace else, then exposing them
is a requirement for many advanced use cases, but turning everything into an
assertion just to shift code from the "SAML issuing" application where it
belongs back into this code doesn't make any sense to me.
There's a good reason for an IdP to generate assertions after resolving
data, not inside the resolver.
-- 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.