Shibboleth Developers

[Steven Carmody <>]

Is there any documentation describing how to use this ? There are a 
couple of options mentioned at the bottom of the jira post ....

Thanks!

-------- Original Message --------
Subject: [JIRA] Resolved: (SIDP-461) Add legacy Shib SSO protocol as 
binding for IdP-initiated SSO for SAML 2.0
Date: Wed, 9 Feb 2011 18:06:21 -0500 (EST)
From: Scott Cantor (JIRA) 
<>
To: 



     [ 
https://bugs.internet2.edu/jira/browse/SIDP-461?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel 
]

Scott Cantor resolved SIDP-461.
-------------------------------

    Resolution: Fixed

Checked in rev 2989.

This is enabled by default in the config, since we don't require signed 
requests in general anyway, but we can revisit before release.

Brent, if you have time to try using your custom decoder with the 
changed core classes, that might be a good test.

> Add legacy Shib SSO protocol as binding for IdP-initiated SSO for SAML 2.0
> --------------------------------------------------------------------------
>
>                 Key: SIDP-461
>                 URL: https://bugs.internet2.edu/jira/browse/SIDP-461
>             Project: Shibboleth IdP 2 - Java
>          Issue Type: New Feature
>          Components: SAML 2
>            Reporter: Scott Cantor
>            Assignee: Scott Cantor
>            Priority: Major
>             Fix For: 2.3.0
>
>         Attachments: unsolicited.patch
>
>
> After much gnashing of teeth, we've agreed to support IdP-initiated SSO by 
> using the legacy Shibboleth protocol (a simple query string) to signal this 
> on the SAML 2.0 SSO endpoint.
> We need to reuse or adapt the MessageDecoder from the original protocol 
> support for SAML 1 and bind it to the SAML 2.0 endpoint. We may even be able 
> to reuse the binding URN, because there's no reason to add this to metadata 
> (it's intended to be internal to the IdP deployment, not public).
> We will not try and support both SAML versions on one endpoint, so if the 
> shire parameter matches a SAML 1 ACS, it will be treated as an error when the 
> SAML 2 endpoint is used.
> Finally, the whole point of this exercise is to signal that the IdP should 
> omit InResponseTo. We can't do this by the absence of a messageID, because 
> the replay support we added to 2.2.1 mocks up a messageID for legacy protocol 
> requests. Chad suggested using a profile handler option, but I would rather 
> that deployers didn't have to turn this off for all responses from the 
> profile handler, mainly because the SP at some point might start enforcing 
> the InResponseTo check.
> So I think we have a couple of options:
> - create a second version of the profile handler to represent IdP-initiated 
> SSO, and add that to the relying-party set, and to handler.xml bound to only 
> the legacy MessageDecoder (they would obviously share 99.9% code)
> - implement a brute force check of the inbound binding to suppress 
> InResponseTo automatically when the legacy binding is used (reusing the 
> existing profile handler)

--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira