Status of WS-Security features in SwitchYard SOAP

[mike.daleiden]

Where do things stand with respect to enabling WS-Security (i.e., digital signatures) for SOAP messages? We currently have an integration with a third-party system running under SOA-P 5 (JBossESB) that requires WS-Security headers based on an X509 certificate (using Spring to wire CXF-based client code with security interceptors). We would like to be able to prototype this in SwitchYard (0.6 dev build) running under AS7.

[dward]

Hi Michael.  I am currently working on SWITCHYARD-830, which will enable PicketBox (and eventually, PicketLink) integration with SwitchYard 0.6+.  It represents the beginnings for the support you are seeking, so I suggest following ("Watching") that jira for updates.

[adamdva]

Hi David, I see that the referenced JIRA ticket is complete. Is there any quickstarts or documentation available for integrating PicketLink with SwitchYard (0.7)

thanks,

Adam

[dward]

https://docs.jboss.org/author/display/SWITCHYARD/Security

(See the STSIssueCallbackHandler and STSValidateCallbackHandler.)

https://github.com/jboss-switchyard/quickstarts/tree/0.7.0.Final/demos

(See the policy-security-saml quickstart, and it's Readme.md file.)

[adamdva]

David,

Thanks for the links, I have that quickstart now working.

Do you happen to know how I would configure a BPEL Process in SwitchYard to Call a SAML-Secured service?

[dward]

Happy to hear you got it working.

BPEL? No, not my area of expertise.  I will ping some teammates and alert them to this thread, so that they can hopefully chime in.

[dward]

FYI, after chatting with a couple other people, I can add a bit of information here.

• As far as invoking another service, that saml-secured service would have to have a service reference just like you would normally have to.  Nothing changes there.
• As far as providing the proper credentials, there are a couple options:
  1. If you already have the SAML token (retrieved possibly from PicketLink STS), you would have to copy that token into the header of the message using a BPEL assign (in the BPEL process definition).  The WSDL would have to be modified to specify the header as well.  I don't have personal experience in doing this, but was informed of it by a coworker.
  2. Instead of propagating the token itself per #1 above, you could provide a username/password (per the wsse UsernameToken element), then use SwitchYard's STSIssueCallbackHandler along with PicketLink's STSIssuingLoginModule in AS7's standalone.xml.  This option will then issue you a token per successful username/password login, which can then be passed along to the secured service.

[adamdva]

Great suggestions, thanks.

If we have a SwitchYard service configured as in the secure-saml demo, how would the user Subject/Principal/SAML Token be retrieved?

[dward]

In that demo, there are actually two request/response invocations:

1. The first request is done using the PicketLink STS client, who requests a token from PicketLink STS, who issues it.
2. The second request is the soap request to the SwitchYard service.  It is that request that inlines the SAML assertion (token) retrieved from the first request.  The SwitchYard security layer will extract the token and make it available to SwitchYard's STSTokenCallbackHandler, so that you can use the STSValidatingLoginModule provided by PicketLink to validate it.

The example code where you can see the two requests being made is here.  Make sure to checkout that quickstart's Readme.md file.

[adamdva]

Thanks,

I'm able to access the SAML via the SecurityContext in a bean component, so may persue that avenue.

Which configuration do I need to look at if I want to override the login authorization that the SAML handler uses? I've tried tweaking the security-domain properties to be optional, but it still seams to fallback to the JBoss login module.

thanks,

Adam

[dward]

I don't quite understand what you're trying to do.  Which AS7 LoginModules get used is based on the moduleName attribute of the <security> element in your switchyard.xml.  It aligns with the name attribute of the <security-domain> element in AS7's standalone.xml.

[alexey_no]

<sca:reference name="ProxyReference" multiplicity="0..1" promote="Proxy/ProxyService">

    <sca:interface.wsdl interface="META-INF/wsdl/RegisterService.wsdl#wsdl.porttypePortType)"/>

<soap:binding.soap name="soap">

<soap:contextMapper class="WSHeaderContextMapper"/>

<soap:wsdl>META-INF/wsdl/RegisterService.wsdl</soap:wsdl>

<soap:endpointAddress>${service.address}</soap:endpointAddress>

<soap:timeout>12000</soap:timeout>

</soap:binding.soap>

</sca:reference>

import org.apache.wss4j.dom.WSConstants;

import org.apache.wss4j.dom.message.WSSecUsernameToken;

import org.switchyard.Context;

import org.switchyard.component.soap.composer.SOAPBindingData;

import org.switchyard.component.soap.composer.SOAPContextMapper;

import javax.xml.soap.SOAPElement;

import javax.xml.soap.SOAPFactory;

public class WSHeaderContextMapper extends SOAPContextMapper {

    private String user = "user";

    private String password = "pass";

    @Override

    public void mapTo(Context context, SOAPBindingData target) throws Exception {

        SOAPFactory factory = SOAPFactory.newInstance();

        SOAPElement element = factory.createElement("Security", "wsse", WSConstants.WSSE_NS);

        WSSecUsernameToken utBuilder = createUsernameToken(this.user, password);

        utBuilder.prepare(element.getOwnerDocument());

        element.addChildElement(factory.createElement(utBuilder.getUsernameTokenElement()));

        context.setProperty(element.getElementQName().toString(), element);

        super.mapTo(context, target);

    }

    private WSSecUsernameToken createUsernameToken(String userName, String password) {

        WSSecUsernameToken utBuilder = new WSSecUsernameToken();

        utBuilder.setUserInfo(userName, password);

        utBuilder.setPasswordType(WSConstants.PASSWORD_TEXT);

        return utBuilder;

    }

}