SAML sender-vouches assertions in java web services

Submitted by alister@mit.edu on Mon, 02/09/2009 - 09:52

We are attempting to get java to consume a saml-secured webservice hosted by SAP. We are using SAML Sender-vouches. My problems started when I began looking at java stacks that support this SAML scenario. I started with apache cxf with wss4j, played around a bit, but found the documentation lacking/nonexistent. I also tried the sun stacks (xwss) but had little luck with them. Basically I need something that can construct the saml assertion, populate the issuer, name identifier, and name qualifier, sign it with a certificate, and include it all in a webservice request. Anyone out there have experience with this, or ideas?

Errors parsing taglibs-standard-1.1.2-3.jar ›

Re: SAML sender-vouches assertions in java web services

Submitted by pbh@mit.edu on Tue, 02/17/2009 - 23:12.

I don’t have an ideal answer for you.

Touchstone does not currently generate signed SAML assertions that you can pass into a webservice request. This will change in the future, but probably not until the early part of 2010.

In 2006 the Burton Group published a whitepaper titled "Web Services Security: A Plethora of Products" which provided a feature comparison of several WS Platforms and WS Libraries. At that time there were no products that met a variety of MIT’s needs. (Note all MIT staff and students can access services of the Burton Group. See http://web.mit.edu/itag/services.html for details.) The web services working group has scheduled a call with the Burton Group to discuss the current state of WS Libraries and WS platforms during March of 2009.

There is a two part Dr. Dobbs article that does cover most of the steps of what your are trying to do. The URL of the first part of the article is http://www.ddj.com/java/208402532 and the URL of the second part is http://www.ddj.com/java/209100671.

Note that one piece that you need is a service that can be trusted to issue a signed SAML assertion. You don’t want to do this step on the client, since any user could then create any signed assertion. If you are thinking of creating such a service, I think it would be helpful to meet before you proceed with starting to implement.

Web Services Single Sign On with Shibboleth

Submitted by pbh@mit.edu on Tue, 03/03/2009 - 15:09.

http://www.thomas-bayer.com/shibboleth-web-services-sso-en.htm

discusses the case where you have a client that invokes a web service to interact with a remote server. The server is configured to support Shibboleth. The web service is presumed to be written using Axis2.

The article does not describe the more generalized case where you would want to use the Shibboleth assertion with the ws-security SAML profile to secure a SOAP session.

Paul

Thanks for the information.

Submitted by alister@mit.edu on Thu, 02/19/2009 - 10:37.

Thanks for the information. I'm still learning about this SAML stuff...

Could you comment more on the reasoning for having a separate issuing entity for providing assertions? Does the web service provider also communicate with this entity to check assertion validity? I do not think that this is the case for a web-service exposed sap rfc... so what is the difference between treating my web service consuming application itself as the issuing entity vs having a separate one?

source of the signed SAML assertion

Submitted by pbh@mit.edu on Fri, 02/20/2009 - 12:02.

I've been thinking abou that since I wrote my previous response.

Given the fact that your server is already a trusted server, and each of the systems in questions is operated by IS&T, I could live with your server acting as the issuing entity.

In the general case, where we cannot trust the integrity of the server, or the security of the code running on the server, then it becomes important to have a trusted third party create the SAML assertion and sign it. Otherwise the code author or server operator could impersonate any user.