[Shib-Users] IdP Initiated SSO
Nandakumar Kalappurayil
Russell Beall
Nandakumar Kalappurayil
Nandakumar Kalappurayil
Russell Beall
Brent Putman
the lower-layer encoding that is the issue.
You seem to be using the HTTP Redirect binding. The requirements of
that binding are in the bindings docs, but in short the message has to
be DEFLATEd before being base64 encoded.
Alternatively, are you sure you want to use that binding? Perhaps you
want to use the HTTP-POST binding instead? That's a different endpoint
on the IdP. Either is ok, I'd suggest just picking the easiest one to
implement for you. There are JSP's floating around out there for this,
I don't remember off-hand whether they used Redirect or POST.
Caskey, Paul
Tell me I’m crazy, but I’ve seen this twice now with commercial SAML (SP) products trying to send an AuthnRequest to my IdP (2.1.5).
The fix was to add a ‘\r\n’ inside the inbound XML when needed. I think one of the vendors told me that they were guessing that around 76 characters was the max before the line feed was needed.
I know if doesn’t make too much sense since XML typically doesn’t care about whitespace, but sure enough, it fixed the problem in my self-written test harness.
Kevin Hall
Did you manage to get SAML2 working with salesforce.com? I'm having some
trouble myself and would love to hear the details of the resolution.
Thanks,
-Kevin
Brent Putman
SAML 2 with salesforce.com. The only real substantive issue is that the
issued Response and Assertion must have the InResponseTo attribute
removed, else they are rejected by Salesforce. That requires some mods
to the IdP, either code changes or additions. See the list archive for
some solutions people have come up with.
Kevin Hall
> Many people, including our school, have gotten the Shib IdP to work via
> SAML 2 with salesforce.com. The only real substantive issue is that the
> issued Response and Assertion must have the InResponseTo attribute
> removed, else they are rejected by Salesforce. That requires some mods
> to the IdP, either code changes or additions. See the list archive for
> some solutions people have come up with.
If there is a solution in the archives, I'm not finding it. The closest I found
was the "IdP Initiated SSO" thread from Nov. 15th but it is incomplete.
Thanks,
-Kevin
Cantor, Scott E.
> was the "IdP Initiated SSO" thread from Nov. 15th but it is incomplete.
I believe Yale's patch for one approach to this was posted very recently.
Alternatively I suppose you can just copy the existing profile handler to a second inbound endpoint with a patch to blank out InResponseTo, and trigger SSO with a request to that endpoint.
-- Scott
Brent Putman
On 1/26/2011 12:46 PM, Cantor, Scott E. wrote:
>
> Alternatively I suppose you can just copy the existing profile handler to a second inbound endpoint with a patch to blank out InResponseTo, and trigger SSO with a request to that endpoint.
That's pretty much what my solution does, and also deals with not
sending unsolicited error responses to the SP. It's not currently
publicly available, but I could probably make it so.
The problem I had with the Yale solution was that it purports to use the
third-party request extension, but doesn't actually really implement it
fully/properly. It just implements the "side-effect" part of that spec
re: eliminating the InResponseTo. Call me a purist. :-) Others may
not care about this as much. The version posted recently does seem to
have some nice support for managing SP's for IdP-initiated flows via an
externalized config file.
Nandakumar Kalappurayil
Cantor, Scott E.
> authentication
> request to the IdP(Redirect binding). I also had to comment out the code in
> the IdP that sends out a inresponseto attribute in the SAML response.
That will simply break other SPs (not Shibboleth *at the moment*) that enforce the check. In other words, this is a bad idea.
-- Scott
Nandakumar Kalappurayil
Cantor, Scott E.
> expecting an inresponseto attribute?
No, the profile certainly permits the SP to check and it may or may not.
> How can this be selectively sent from the IdP in its response?
There is no standard method to "invoke" IdP-initiated SSO. If you think about it, you'll see why, it's an impossibility. The IdP is not SkyNet, it doesn't initiate anything, a client always does.
The only standard-defined way of talking to the IdP that results in no correlation ID is with the RespondTo extension that it does not support. That's what Yale's patch partially implements, and that's a reasonable thing to do if you understand the limitations.
Or you copy the SAML2 SSO profile handler and know to use it instead of the normal endpoint, as Brent said, which keeps the regular one in the metadata clear for standard use.
Or you implement a portal inside the IdP that can direct it to issue responses to user-selected SPs.
Or you build a completely custom protocol to invoke SAML SSO and code it to leave out InResponseTo.
Etc.
-- Scott
shibnewbie
Could you please make your solution available? Also does the solution allow -
configuring SP initiated SSO too? or Does it block that out?
My scenario is as below
1. Shibboleth IDP connected 3 SPs of which 2 SPs have SP initiated SSO and
one 3rd party SP needing IDP initiated SSO.
--
View this message in context: http://shibboleth.1660669.n2.nabble.com/IdP-Initiated-SSO-tp5741045p5971522.html
Sent from the Shibboleth - Users mailing list archive at Nabble.com.
awulms
I was wondering if the
https://isa.its.yale.edu/confluence/display/Shib/Add+IdP+initiated+POST+SSO+support+to+Shibboleth+java-idp-2.2.0
Yale patch can be included in the next version (e.g. 2.4.0) of Shibboleth.
Reason to ask for it are three-fold:
- The SAML 2.0 specification explicitly states that IdP initiated flow is
part of the WEB Browser SSO Profile. When using an IdP initiated flow
(called an "
http://www.oasis-open.org/committees/download.php/35389/sstc-saml-profiles-errata-2.0-wd-06-diff.pdf
Unsolicited Response " in section 4.1.5 of the Profiles Specification), the
inResponseTo header MUST NOT be set (according to the spec). This implies
that a service provider who mandates IdP initiated flow for certain
integration models (like salesforce) and who rejects responses with an
inResponseTo header in such cases is actually fully compliant with the
specification.
- There is a proven need for it, given the existence of the Yale patch and
this discussion thread. The Yale patch correctly implements the IdP
initiated flow. It strips-out the inResponseTo header when it initiates the
flow while the inReponseTo header is nicely kept in case of a Service
Provider initiated flow. Which is great for organizations that have to
integrate with multiple service providers, some using SP initiated flow and
others forcing IdP initiated flow.
- Forcing each organization that needs to set-up IdP initiated flow to apply
the patch is cumbersome. It requires such organization to download the
source of shibboleth, set-up a build environment, apply the patch and then
building everything.
Thanks and kind regards,
Alex Wulms
--
View this message in context: http://shibboleth.1660669.n2.nabble.com/IdP-Initiated-SSO-tp5741045p6444405.html
Peter Schober
> - Forcing each organization that needs to set-up IdP initiated flow
> to apply the patch is cumbersome. It requires such organization to
> download the source of shibboleth, set-up a build environment, apply
> the patch and then building everything.
Note that no IdP version 2.4.0 is being planned. Also have a look at
this from the 2.3 IdP release announcement:
> From: Chad La Joie <laj...@itumi.biz>
> Date: Tue, 17 May 2011 17:20:35 -0400
> Subject: [Shibboleth-Announce] IdP v2.3 Released
>
> IdP, version 2.3.0, is now available on the download site[1].
>
> This release has a number of bug fixes and a bunch of new functionality
> that includes:
[...]
> - IdP-initiated SSO, for SAML 2, using the Shibboleth SSO protocol
> (the same protocol that was always used for SAML 1).
-peter
WULMS Alexander
-----Original Message-----
From: shibboleth-u...@internet2.edu [mailto:shibboleth-u...@internet2.edu] On Behalf Of Peter Schober
Sent: Monday, June 06, 2011 1:28 PM
To: shibbole...@internet2.edu
Cantor, Scott E.
>Ah great :-) I'll search the documentation on how to enable/use this new
>feature in shibboleth 2.3
/idp/profile/SAML2/Unsolicited/SSO?providerId=...
-- Scott
Tom Scavo
What is the Binding associated with this endpoint in metadata?
Tom
Cantor, Scott E.
There is none. It's not in metadata by definition, since the whole point
is that it's not initiated by somebody other than the IdP.
It should never be used in links created by anybody other than the
organization operating the IdP. We can't keep people from shooting
themselves in the head on that, but one tool is not putting it in the
metadata.
-- Scott