Skip to Content.
Sympa Menu

shibboleth-dev - Re: exposing assertions at the SP

Subject: Shibboleth Developers

List archive

Re: exposing assertions at the SP


Chronological Thread 
  • From: "Tom Scavo" <>
  • To:
  • Subject: Re: exposing assertions at the SP
  • Date: Mon, 25 Sep 2006 11:30:28 -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=SJmfFLCZDGs9BMnc9c95UvFqlXRVOPuIBqazSm+x00nV4G8XS6wnnSJK2ZOnGSgvxagh2CKqzun04LbomhjKFywh6Q3NjWc6creKuZTDyvObE+vPJMveNC42YXtKyrRp7NnoMBqCAPwolNigee0MAZ8OeNQjNee/abq8V/8tNvY=

On 9/25/06, Scott Cantor
<>
wrote:

> I've read the SAML V2.0 bits re IdP Proxying but I don't see a
> conflict. Can you elaborate where it falls down?

2.0 proxying never forwards assertions, it builds new ones by translating
information from the original. The assumption is that the relying party
doesn't trust the original IdP, otherwise it would have used it directly.

Sorry, I don't get that at all from reading the spec. As I've said
before, the notion of IdP Proxy is underspecified in SAMLCore. I'm
trying to fill in the holes here. Evidently you want to fill in the
holes with something else, and that's fine, but I don't know it is.

We have an IdP Proxy implementation today (myVocs) so we need to
propose a standard where none exists (not even in SAML V2.0). I'm
open to suggestion, but I haven't yet heard a workable solution.

For instance, it doesn't make sense for an IdP Proxy to repackage an
eduPersonAffiliation attribute asserted by a campus IdP. The IdP
Proxy is not authoritative for that attribute or any other attribute
asserted by the campus IdP for that matter. It seems the relying
party must be able to distinguish between attributes for which the IdP
Proxy is authoritative and other attributes asserted further up in the
chain.

Tom



Archive powered by MHonArc 2.6.16.

Top of Page