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: Thu, 4 Mar 2010 20:51: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=v1GoK2V1WPpqE/MR/G30fDg3ggPoSOKzQZQl39G39xkhI9nkuw15aTrmN/0TdzZZMzHrH8HIneIiV0GDSp9iTRtcebmg5U3MJH51KJOweZyKprGjhi3lxis5S2AAVrSiGLcKrIc7yoOzrbDUIu932X/oyBBrS00axZwPhaNiPks=;

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