Skip to Content.
Sympa Menu

shibboleth-dev - Re: attribute aggregation

Subject: Shibboleth Developers

List archive

Re: attribute aggregation


Chronological Thread 
  • From: "Tom Scavo" <>
  • To:
  • Subject: Re: attribute aggregation
  • Date: Tue, 28 Mar 2006 21:26:59 -0500
  • 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=XNm2wrhEGXev0XeRcMuoVhOgYMyBUqBYnviatK3s5yc8wkXTpaoFRioTB/acWYC3Z2E/g0bOQMrdcrc2+3A/kA9p6HnADP/ejamvNqfJsrPUKPQjELtqZeBAGSYGZ9REoyDUU8AOBCEL2dTMhHrp1Q+U5YwDo2SD3n7PcutwFlM=

On 3/28/06, Scott Cantor
<>
wrote:
>
> ... you definitely have to
> deliver them all at once in one response, whether it's push or pull.

Why? This is the very same question we (GridShib) faced when
designing GridShib for Globus Toolkit a year ago. We had hoped to
leverage the (standalone) attribute requester component of the Java SP
in Globus Toolkit, but of course the Java SP never materialized, so we
ended up writing our own. Tim Freeman did a superb job of this, but
it's always bothered me that we weren't able to leverage an
off-the-shelf Shibboleth component. So here we are again! ;-)

So there's no way to make the C++ SP function like a standalone
attribute requester? Remember, in this case, there is but one
IdP---the myVocs IdP---to worry about. We have total control over
what ends up at the terminal SP.

Tom



Archive powered by MHonArc 2.6.16.

Top of Page