shibboleth-dev - Re: SAML Protocol Extension for Third-Party Requests
Subject: Shibboleth Developers
List archive
- 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
- SAML Protocol Extension for Third-Party Requests, Tom Scavo, 05/13/2006
- RE: SAML Protocol Extension for Third-Party Requests, Scott Cantor, 05/13/2006
- Re: SAML Protocol Extension for Third-Party Requests, Tom Scavo, 05/13/2006
- RE: SAML Protocol Extension for Third-Party Requests, Scott Cantor, 05/13/2006
- Re: SAML Protocol Extension for Third-Party Requests, Tom Scavo, 05/13/2006
- RE: SAML Protocol Extension for Third-Party Requests, Scott Cantor, 05/13/2006
Archive powered by MHonArc 2.6.16.