shibboleth-dev - Re: attribute push
Subject: Shibboleth Developers
List archive
- From: "Tom Scavo" <>
- To:
- Subject: Re: attribute push
- Date: Mon, 11 Sep 2006 13:44:56 -0400
- Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=TnFFCk8vkwRIkapuZvhLwTt7uaVqXhXhpuHmRi8nUqVBNlEmmrfWUk875fbokIb46wYDcABwGqwLizRS3HfGMFnCV5Al8WxesiwaJX3HITBB6MA7Te3Xdc3mgo7q0dRcsq70VkDsutMVBSNEMYo3JISTPnJ29OV/qi9bPEX0eOk=
On 9/11/06, Scott Cantor
<>
wrote:
> Assuming the authentication response contains two separate assertions,
> will the Shib 2.0 SP continue to expose the complete response?
It effectively does not do this now, despite my best intentions
Isn't the entire authn response exposed in the case of attribute push?
In that case, there are two assertions, right?
so what
you're talking about is basically a new feature and no decision has been
made on an approach yet (see the other note about it). In Java, we clearly
will expose all of it.
Yeah, I guess it's a new feature. The idea, of course, is to expose
the authentication context for the purposes of access control. How
exactly that happens is less important.
> Instead of exposing the response
> at the SP, why not expose the attribute assertion only (with the
> response wrapper stripped away)? In that case, you end up with the
> same thing irrespective of push or pull.
The issue is multiple assertions. I can't expose *the* assertion because
there can be two. Or I can explicitly disallow more than one and be
non-compliant. Any votes? ;-)
Well, there are a couple of ways to do it, but I would think the same
SAML blob should be exposed whether attributes are pushed or pulled.
> Also, why not nest the authentication assertion in the <Advice>
> element of the attribute assertion?
Because that's not SAML SSO. Unless you mean doing something after the fact
just to get it in one object, but I don't really see how that's
substantially better than a wrapper element.
Well, I'd say either way is fine, as long as push agrees with pull.
Thanks,
Tom
- attribute push, Tom Scavo, 09/11/2006
- Re: attribute push, Chad la Joie, 09/11/2006
- Re: attribute push, Tom Scavo, 09/11/2006
- Re: attribute push, Chad la Joie, 09/11/2006
- RE: attribute push, Scott Cantor, 09/11/2006
- Re: attribute push, Tom Scavo, 09/11/2006
- Re: attribute push, Chad la Joie, 09/11/2006
- RE: attribute push, Scott Cantor, 09/11/2006
- Re: attribute push, Tom Scavo, 09/11/2006
- RE: attribute push, Scott Cantor, 09/11/2006
- Re: attribute push, Tom Scavo, 09/11/2006
- RE: attribute push, Scott Cantor, 09/11/2006
- Re: attribute push, Tom Scavo, 09/11/2006
- RE: attribute push, Scott Cantor, 09/11/2006
- Re: attribute push, Tom Scavo, 09/11/2006
- RE: attribute push, Scott Cantor, 09/11/2006
- Re: attribute push, Tom Scavo, 09/11/2006
- Re: attribute push, Chad la Joie, 09/11/2006
Archive powered by MHonArc 2.6.16.