Skip to Content.
Sympa Menu

shibboleth-dev - Re: query profile support in Shib 2

Subject: Shibboleth Developers

List archive

Re: query profile support in Shib 2


Chronological Thread 
  • From: "Tom Scavo" <>
  • To:
  • Subject: Re: query profile support in Shib 2
  • Date: Sun, 30 Jul 2006 17:23:23 -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=e8hfoGHYjV5+OZsZJGNr3yJht5LG2NPh13Z1v81EQdB9JSujMmBqRq1fxpzmvuJ/opOfu4Ba4S12owjxXi1StRofOVfEiPzK6+JKzwUHLUYd6Yw7foK/x3Nx0nwuGf7nePDkBqPPgfsHSUBe/PjkWNRoXpddyXMVmkqbc+cX1oQ=

On 7/30/06, Scott Cantor
<>
wrote:
> What X.509 part? Are you referring to the use of
> X509SubjectName identifiers?

No, that part is meaningless but transparent to SAML. I mean the X.509
authentication part.

That's not part of the Attribute Sharing Profile, so I still don't
understand your concern.

> Well, I could be missing something, but there seems to be a real
> problem here. So the Shib 2.0 IdP will have AA endpoints that support
> Shib 1.x attribute exchange, SAML V1.1 Attribute Query Profile
> (currently being written), SAML V2.0 Assertion Query/Request Profile,
> and SAML V2.0 Attribute Sharing Profile (standards track). How does
> an SP find an endpoint that supports a specific profile?

We support Shibboleth attribute queries now and we'll support vanilla 2.0
queries, both of which are distinct SOAP bindings (and protocol URIs). I'm
not sure why the other two things are suddenly in the picture.

They've always been in the picture (the one I'm seeing, anyway) but it
wasn't until recently that I realized how difficult it was going to be
to juggle all these protocols.

But if they
have to overload the SOAP binding, then they need their own endpoint
extension attributes, same as the other extensions that have been proposed.

Agreed, but one concludes from this that multiple
<md:AttributeService> elements within a single
<md:AttributeAuthorityDescriptor> element won't work in general, which
might be a problem (see below).

I think it's a mistake to imagine that metadata is the answer to
interoperability. It will never capture everything. Separate endpoints and
per-partner metadata will always be an option to get around limitations.

What I think you're suggesting is that these various AA endpoints can
not coexist in a single metadata file. So if, for example, a group of
TeraGrid service providers joined InCommon, a new process for
producing and distributing TG-specific IdP metadata would have to be
devised. Does that sound right?

Tom



Archive powered by MHonArc 2.6.16.

Top of Page