[Shib-Users] Idp Initiated POST SSO
Joseph Valerio
I have been reading the mailing lists, and some recent activity about removing the inResponseTo attribute from the Response element. I too am plagued with this problem. My issue is that I need to create a IdP initiated SAML2 POST SSO response to our commercial partner that is unwilling/unable to ignore the inResponseTo attribute. How do you recommend creating such a response, short of using openSaml to generate one. I was hoping to get all that for free from Shib. I like how it manages the profiles, metadata, keys, and attribute resolution. I feel like I would loose all that. I guess I could extend the current SAML2SSOProfile and remove the attribute myself, but again, with little experience with OpenSaml and even less with Shib, that sounds like a much larger project than I want to take on right now. I was thinking that you could add a profile attribute to turn-off inResponseTo and that way we could control it based our needs, even with a big fat warning about what the Spec says.
Attached is a jsp that I added to the web app that creates the authnRequest, much like the ShibbolethSSOProfile, but SAML 2.0 compliant...
In a world of specifications, sometimes we need get the job done.
Thanks in advance,
- Joe
Joseph Valerio
Senior Systems Programmer
Yale University
Technology & Planning
Information Technology Services
phone: 203-432-1196
email: joseph....@yale.edu
smail: 25 Science Park, New Haven, CT 06511
Scott Cantor
> I have been reading the mailing lists, and some recent activity about
> removing the inResponseTo attribute from the Response element. I too am
> plagued with this problem. My issue is that I need to create a IdP
> initiated SAML2 POST SSO response to our commercial partner that is
> unwilling/unable to ignore the inResponseTo attribute. How do you
> recommend creating such a response, short of using openSaml to generate
one.
If the problem here is that the vendor can't generate a request, but also
can't ignore the InResponseTo value (since it wouldn't match a request that
they generated), there's a SAML extension defined for that called a "third
party request" that indicates to the IdP that the system sending the request
isn't actually the SP to respond to. It's an extension element called
"RespondTo", IIRC, that just tells it to send an unsolicited response to the
SP named in the element.
I just looked, it's actually a committee spec, so it's basically one step
short of standard (the step being that 3 implementations are needed).
http://wiki.oasis-open.org/security/ProtocolExtThirdParty
So if you were going to file a request to support something, that would be
the feature to reference.
This was one of the use cases, allowing an outside request (which gives the
IdP more information about how to respond), but avoiding InResponseTo.
-- Scott
Joseph Valerio
Do you have any suggestions for the short term?
- Joe
Scott Cantor
> Do you have any suggestions for the short term?
My SP never looks at InResponseTo because it has nothing to compare it to,
so I will say if you patched it to simply remove that code in your IdP it
won't break anything I wrote. I can't speak for other SPs of course.
The effort it would take to add the option you described is not
significantly different than the effort to support the extension. With
either one, you would either have to do it, or file a request, but I
wouldn't be the one doing it, nor is there an IdP release likely very soon.
So the only short term fix is adding something on your own (or finding
somebody to help), or removing that line of code.
-- Scott
Joseph Valerio
I hate to run a production system off release, but you have to do what you have to do.
I attached the patch file for:
edu.internet2.middleware.shibboleth.idp.profile.saml2.AbstractSAML2ProfileHandler.java
I also attached my updated idp-initiated-post-sso.jsp if any one wants to use it.
Thanks for your help.
- Joe
Scott Cantor wrote:
Chad La Joie
system this will never make it in to a release.
--
SWITCH
Serving Swiss Universities
--------------------------
Chad La Joie, Software Engineer, Net Services
Werdstrasse 2, P.O. Box, 8021 Zürich, Switzerland
phone +41 44 268 15 75, fax +41 44 268 15 68
chad....@switch.ch, http://www.switch.ch
Joseph Valerio
Redmond Militante
Hi -
We've been following your thread on the shib-users list and was interested in trying out your patch. I thought I'd be able to run something like
patch -p1 -i RespondTo.patch
inside the unarchived shibboleth-identityprovider-2.1.2-bin.tar.gz (shibboleth-identityprovider-2.1.2) directory, then rerun the install.sh script to deploy the patched 2.1 IdP. I was not able to find AbstractSAML2ProfileHandler.java on my system to patch against, am I going about this the right way?
I also wanted to clarify that this patch would modify the IdP in such a way that it would not include the InResponseTo attribute in any unsolicited responses, but would include this attribute in any solicited responses? Correct?
Thanks,
R.
+++ Joseph Valerio <joseph....@yale.edu> [09/06/22 08:00]:
> <%@page import="org.opensaml.xml.*"%>
> <%@page import="org.opensaml.saml2.common.*" %>
> <%@page import="org.opensaml.saml2.common.impl.*" %>
> <%@page import="java.util.UUID"%>
> <%@page import="org.opensaml.saml2.core.*"%>
> <%@page import="org.opensaml.saml2.core.impl.*"%>
> <%@page import="org.opensaml.xml.Configuration"%>
> <%@page import="org.opensaml.xml.XMLObjectBuilderFactory"%>
> <%@page import="org.joda.time.DateTime"%>
> <%@page import="org.opensaml.xml.io.MarshallingException"%>
> <%@page import="org.opensaml.xml.util.XMLHelper"%>
> <%@page import="org.opensaml.saml2.core.impl.AuthnRequestMarshaller"%>
> <%@page import="org.w3c.dom.Element"%>
> <%@page import="org.opensaml.xml.util.Base64" %>
> <%@page import="org.opensaml.samlext.samlpthrpty.*" %>
> <%@page import="org.opensaml.samlext.samlpthrpty.impl.*" %>
> <html>
> <%
> String SAML_POST_SSO_CONTEXT = "/idp/profile/SAML2/POST/SSO";
> String PROTOCOL_BINDING = "urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST";
>
> String entityIdParam = request.getParameter("entityId");
> String acsUrlParam = request.getParameter("acsUrl");
> String relayStateParam = request.getParameter("relayState");
>
> String base64EncodedSamlRequest = null;
> String samlRequest = null;
>
> try {
> if(entityIdParam == null)
> throw new RuntimeException("entityId is a required parameter.");
> if(acsUrlParam == null)
> throw new RuntimeException("acsUrl is a required parameter.");
>
> XMLObjectBuilderFactory builderFactory = Configuration.getBuilderFactory();
>
> AuthnRequestBuilder authnRequestBuilder = (AuthnRequestBuilder) builderFactory.getBuilder(AuthnRequest.DEFAULT_ELEMENT_NAME);
> IssuerBuilder issuerBuilder = (IssuerBuilder) builderFactory.getBuilder(Issuer.DEFAULT_ELEMENT_NAME);
> NameIDPolicyBuilder nipBuilder = (NameIDPolicyBuilder) builderFactory.getBuilder(NameIDPolicy.DEFAULT_ELEMENT_NAME);
> RespondToBuilder rtBuilder = (RespondToBuilder) builderFactory.getBuilder(RespondTo.DEFAULT_ELEMENT_NAME);
> ExtensionsBuilder exBuilder = new ExtensionsBuilder();
>
> AuthnRequest authnReq = authnRequestBuilder.buildObject();
> authnReq.setAssertionConsumerServiceURL(acsUrlParam);
> authnReq.setID(UUID.randomUUID().toString());
> authnReq.setDestination(request.getScheme() + "://" + request.getServerName() + SAML_POST_SSO_CONTEXT);
> authnReq.setIssueInstant(new DateTime());
> authnReq.setProtocolBinding(PROTOCOL_BINDING);
>
> Issuer issuer = issuerBuilder.buildObject();
> issuer.setValue(entityIdParam);
> authnReq.setIssuer(issuer);
>
> Extensions exs = exBuilder.buildObject();
> RespondTo rt = rtBuilder.buildObject();
>
> exs.getUnknownXMLObjects().add(rt);
>
> authnReq.setExtensions(exs);
>
> NameIDPolicy nip = nipBuilder.buildObject();
> nip.setAllowCreate(true);
> authnReq.setNameIDPolicy(nip);
>
> AuthnRequestMarshaller m = new AuthnRequestMarshaller();
> Element elem = m.marshall(authnReq);
> samlRequest = XMLHelper.nodeToString(elem);
> base64EncodedSamlRequest = Base64.encodeBytes(samlRequest.getBytes());
>
> %>
> <body onload="document.forms[0].submit()">
> <noscript>
> <p>
> <strong>Note:</strong> Since your browser does not support JavaScript,
> you must press the Continue button once to proceed.
> </p>
> </noscript>
> <form method="post" action="<%=SAML_POST_SSO_CONTEXT%>">
> <input type="hidden" name="SAMLRequest" value="<%=base64EncodedSamlRequest %>" />
> <% if (relayStateParam != null) { %>
> <input type="hidden" name="RelayState" value="<%=relayStateParam %>" />
> <% } %>
> <noscript>
> <div>
> <input type="submit" value="Continue"/>
> </div>
> </noscript>
> <!--
> <%=samlRequest %>
> -->
> </form>
> </body>
> <%
> } catch (Exception e) {
> %>
> <head>
> <style type="text/css">
> .txt {
> font-family: Verdana, Arial, Helvetica, sans-serif;
> font-size: 12px;
> white-space: nowrap;
> }
> .hdr {
> font-family: Verdana, Arial, Helvetica, sans-serif;
> font-size: 16px;
> font-weight: bold;
> white-space: nowrap;
> }
> .code{
> border-width: 1px 1px 1px 1px;
> border-style: dashed;
> border-color:blue;
> background-color: lightgrey;
> width: 700px;
> height: 300px;
> overflow: auto;
> padding: 5px;
> display: none;
> }
> </style>
> <script language="JavaScript">
> function toggle(obj) {
> var el = document.getElementById(obj);
> el.style.display = (el.style.display != 'none' ? 'none' : '' );
> }
> </script>
> </head>
> <body class="txt">
> <span class="hdr">Error during IdP Initiated Post SSO attempt</span><br /><br />
> <strong>Error Message:</strong> <%=e.getMessage()%><br />
> <br />
> <table>
> <tr>
> <td colspan="4"><span class="hdr">Usage:</span></td>
> </tr>
> <tr>
> <td width="15" />
> <td>Request parameter <strong>entityId</strong> is required.</td>
> <td width="15" />
> <td><small>Current Value: <strong><%=entityIdParam == null ? "<null>" : entityIdParam %></strong></small></td>
> </tr>
> <tr>
> <td width="15" />
> <td>Request parameter <strong>acsUrl</strong> is required.</td>
> <td width="15" />
> <td><small>Current Value: <strong><%=acsUrlParam == null ? "<null>" : acsUrlParam%></strong></small></td>
> </tr>
> <tr>
> <td width="15" />
> <td>Request parameter <strong>relayState</strong> is optional.</td>
> <td width="15" />
> <td><small>Current Value: <strong><%=relayStateParam == null ? "<null>" : relayStateParam%></strong></small></td>
> </tr>
> </table>
> <br />
> <br />
> <strong><a href="javascript:toggle('exception')">Error Detail</a></strong>
> <div id="exception" style="border-width: 1px 1px 1px 1px;
> border-style: dashed;
> border-color:blue;
> background-color: lightgrey;
> width: 700px;
> height: 300px;
> overflow: auto;
> padding: 5px;
> display: none;">
> <pre>
> <%
> e.printStackTrace(new java.io.PrintWriter(out));
> %>
> </pre>
> </div>
> </body>
> <%
> }
> %>
> </html>
>
--
Redmond Militante NSIT/NBS The University of Chicago
PGP Public Key: <http://home.uchicago.edu/~rjm/pubkey.asc>
Chad La Joie
Redmond Militante wrote:
> inside the unarchived shibboleth-identityprovider-2.1.2-bin.tar.gz (shibboleth-identityprovider-2.1.2) directory, then rerun the install.sh script to deploy the patched 2.1 IdP. I was not able to find AbstractSAML2ProfileHandler.java on my system to patch against, am I going about this the right way?
That's the binary release of the IdP it wouldn't contain the source
files. To see how to build the IdP from source refer to the wiki.
Joseph Valerio
Sorry for the delayed response, but I have been busy trying to get our systems and security dept on board for deployment.
I after more complete testing I found that the original patch I listed was not complete and the one in jira is also not complete. I am creating a wiki page with the details of what I did. So please be patient and I should be done by the end of the day. I will post a link to it later.
Thanks,
- Joe
Joseph Valerio
Ramm
Not sure why this is not talking about target URL. Where do we specify the
target URL in this case anyway !
--
View this message in context: http://n2.nabble.com/Idp-Initiated-POST-SSO-tp3122153p3960908.html
Sent from the Shibboleth - Users mailing list archive at Nabble.com.
Scott Cantor
> Not sure why this is not talking about target URL. Where do we specify
> the target URL in this case anyway !
Formally, SAML 2 assumes that IdP-initiated SSO implies a defaulted resource
URL at the SP. Informally, people still throw it into RelayState and ignore
the 80-byte limit, and most SPs, mine included, handle that.
-- Scott
Ramm
tried AbstractSAML2ProfileHandler.java.patch, I built the IDP from source
(mvn package). Rebuild idp.war and deployed. Still see 'inResponseTo'
attribute in XML
--
View this message in context: http://n2.nabble.com/Idp-Initiated-POST-SSO-tp3122153p3977078.html
Ramm
But I tried this patch against idp 2.1.5, is it matters ?
Ramm wrote:
>
> tried AbstractSAML2ProfileHandler.java.patch, I built the IDP from source
> (mvn package). Rebuild idp.war and deployed. Still see 'inResponseTo'
> attribute in XML
>
--
View this message in context: http://n2.nabble.com/Idp-Initiated-POST-SSO-tp3122153p3977104.html
Joseph Valerio
http://tp.its.yale.edu/confluence/display/Shib/Add+IdP+Initiated+Post+SSO+Support+to+Shibboleth
No in reality I did a little more work than this, creating a new configuration file holding the properties that are set in the example.jsp page redirected to the idp-initiated-sso.jsp, so that the later page can call a pre-defined service for idp initiated sso. If you are interested I would be more that happy to forward that code to you.
- Joe
Ramm wrote:
But I tried this patch against idp 2.1.5, is it matters ? Ramm wrote:tried AbstractSAML2ProfileHandler.java.patch, I built the IDP from source (mvn package). Rebuild idp.war and deployed. Still see 'inResponseTo' attribute in XML
Senior Systems Programmer
Yale University