Skip to Content.
Sympa Menu

shibboleth-dev - Re: SAML Protocol Extension for Third-Party Requests

Subject: Shibboleth Developers

List archive

Re: SAML Protocol Extension for Third-Party Requests


Chronological Thread 
  • From: "Tom Scavo" <>
  • To:
  • Subject: Re: SAML Protocol Extension for Third-Party Requests
  • Date: Sat, 13 May 2006 15:20:18 -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=sZHkVqDgIRDCKtd1g3UTpLuJkDhHqz4++PCMpScqkH0slGveYousnMtmos5PfIzydBOK3fahzsSvIWjNVIyNHq6mFQagFEVilVzQJI5xDiaKwIjQbUG/ufI+A0AakY6WLUZZYct8aEbiR7+CneB7o8T2hKZO3Gc8KOKB83n6KsA=

On 5/13/06, Scott Cantor
<>
wrote:
> Before I comment on this document, may I ask what is its intended use
> in Shib 2.0 (if any)?

If signed requests become de rigeur, then this extension is the only way
that a portal or some other intermediary can issue interoperable signed
requests on behalf of some SP to enable unsolicited SSO responses.

You can think of it as a way of doing IdP-first triggers interoperably (as
opposed to SAML 1.x where the link to the ITS was proprietary).

So let me see if I understand this. A portal is protected by an SP,
so the portal knows the user's preferred IdP. Instead of exposing
links to other 3rd-party SP-protected resources (which would require
IdP discovery), the portal handles all AuthnRequests itself, using the
extension mechanism to target the response to the 3rd-party SP.
Correct?

Tom



Archive powered by MHonArc 2.6.16.

Top of Page