OpenSAML user discussion

[Chandra Tondepu <>]

To post a SAML Request

 

 <form method="post" action=""https://idp.example.org/SAML2/SSO/POST" ...>
   <input type="hidden" name="SAMLRequest" value="request" />
   ...
   <input type="submit" value="Submit" />
</form>

 

In your case, it must be a bearer token that you are trying to propogate from one service to another service.  So you can send that as SAMLResponse to the other system.

 

snip2>>

 

<form method="post" action=""https://sp.example.com/SAML2/SSO/POST" ...>
   <input type="hidden" name="SAMLResponse" value="response" />
   ...
   <input type="submit" value="Submit" />
</form>

<<snip2

 

You can use the above snip.

 

Regards, Chandra.

 

On Thu, Mar 4, 2010 at 11:51 PM, Sidhartha Priye <> wrote:

Scott,

I completely agree with you. Building an Assertion on the client end does not serve any purpose, not without an IDP.

However we are operating within the limitations laid out by the client. They prefer to not change their preferred approach of using Spring NTLM to render a UsernamePasswordToken. However they insist on using SAML (since it is a standard) to propagate a signed SAML token in the HTTP call made out to the RESTful service. They want to embed the Principal (through NameID) in the SAML assertion, sign it and pass it into the http request. On the service end they want to validate the signature and retrieve the Principal to be used further downstream for logging into Filenet Content Engine using a Websphere Custom Login Module that operates on Identity assertion with trust validation.

Given all that I mentioned, I am struggling to (for lack of documentation unless I missed it)  to come up with an approach to issue HTTP calls (using a HTTP Post) and pass along the SAML token. We have historically been using Apache HTTPClient to issue the Get and Post requests to the REST services.
For .e.g.

   String samlAction = "http://localhost:9088/SAML2/SSO/POST";

   List<NameValuePair> params = new ArrayList<NameValuePair>();
       params.add(new NameValuePair(PARAM_ACTION, samlAction));
       params.add(new NameValuePair (PARAM_SAMLP_RESPONSE, samlpResponseStart)); //hidden form field.

       method = new PostMethod(url.toString());
           method.setQueryString((NameValuePair[])params.toArray(new NameValuePair[0]));
           method.getParams().setParameter(HttpMethodParams.RETRY_HANDLER,
                   new DefaultHttpMethodRetryHandler(ConfigManager.getInstance().getServiceRetry(), false));

           HttpClient client = new HttpClient();
           client.getHttpConnectionManager().getParams().setConnectionTimeout(TIME_OUT);

           url += "?" + method.getQueryString();
           if (logger.isInfoEnabled()) logger.info("BPM10038", url);

           statusCode = client.executeMethod(method);

Now the challenge is to integrate our existing setup using HTTPClient with one of the SSO Profiles you mentioned. Can I leverage the BasicSAMLMessageContext and pass that into the samlpResponse parameter. Also how can this accomplished through an HttpClient interface.

 HTTPPostEncoder encoder = new HTTPPostEncoder(velocityEngine,  "/templates/saml2-post-binding.vm");
 encoder.encode(messageContext);



thanks for all the help so far. Really appreciate your time.

Sid










----- Original Message ----
> From: Scott Cantor <>
> To:

> Sent: Thu, March 4, 2010 4:12:16 PM
> Subject: RE: [OpenSAML] local part cannot be "null" when creating a QName during unmarshalling an Assertion object
>

> > In our case I am not sure if I can completely integrate the Shibboleth's
> > WebSSO solution you are proposing because there is already IDP initialized
> > through a third party IDP that provides us the NTLM token obtained through
> a
> > windows logon. Our custom Spring SSO solution gives us the User Token and
> > more specifically the principal.
>
> If you're using Windows security, seems like you're done. No SAML needed.
>
> > So all we have to do now is issue an HTTP POST (preferred to HTTPRedirect
> > which uses a GET) binding to the Service Provider (SP) in the form of a

> > and pass the serialized encoded signed assertion using
> the
> > protocol message exchange.
>
> I don't know how you think you'd get an assertion or what would be in it, or
> how you think you're going to secure it all, but you're describing the
> standard browser SSO profile response, and I suggested using a variant of
> that designed for non-browsers, so I don't know why you think it doesn't
> apply.
>
> > So here is what I am thinking I need to do
> >
> > 1. Build the Assertion myself (rather than through asamlp:AuthnRequest
> > to an IDP)
>
> Who is "myself"? An IdP? A client can't just make up an assertion, it serves
> no purpose to do so.
>
> -- Scott