Skip to Content.
Sympa Menu

mace-opensaml-users - Re: [OpenSAML] local part cannot be "null" when creating a QName during unmarshalling an Assertion object

Subject: OpenSAML user discussion

List archive

Re: [OpenSAML] local part cannot be "null" when creating a QName during unmarshalling an Assertion object


Chronological Thread 
  • From: Sidhartha Priye <>
  • To:
  • Subject: Re: [OpenSAML] local part cannot be "null" when creating a QName during unmarshalling an Assertion object
  • Date: Fri, 5 Mar 2010 10:12:38 -0800 (PST)
  • Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=DcR/QMaqF1xVhC7a/T/nad69Ax4zZB6R5lxf6uHSrbRC7tzc5pR4ngkWpq5pJfqt5booeQYjjnKorZdoV1lwaenti4AGwjeRvgHof9c/k4Xmzf8wIJwLqVRwWqeGJRd8Yfdn6spnems8vxM/7P9C4zz9L+URgXnoitbcA75TIxw=;

Thanks Chandra for the suggestion. Like I mentioned we have a third party IDP that is windows based that gives us access to the Spring NTLM token. So we cannot post a SAML request to the SAML based IDP providerand thus cannot get back a SAMLResponse which contains the Assertion.

So I opted for the other approach which was to build the Assertion ground up that includes the Principal (from Spring NTLM token) and Issuer. Once I did that I was able to serialize the SAML token, deflate it and then Base64 encode it and pass into the "Authorization" key of the HTTPHeader. Used HTTPClient's getMethod to serve the request. On the servlet end I retrieved the token from the header, decoded it, inflated it and then deserialized it.  Once I did that I was able to validate the signature and retrieve the Principal through the NameID field which is used for the second hop into IBM Filenet Content Engine.

I still need to implement a session affinity on the REST service to validate subsequent incoming requests based on certain conditions stated in the Assertion. This works for now. Once we make a shift to a formal SAML IDP (whenever the client agress), we will start to incorporate the IDP Initialized SSO Profile.

Thanks to everyone for their help and time

regards
Sid

From: Chandra Tondepu <>
To:
Sent: Fri, March 5, 2010 10:13:44 AM
Subject: Re: [OpenSAML] local part cannot be "null" when creating a QName during unmarshalling an Assertion object

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









Archive powered by MHonArc 2.6.16.

Top of Page