SAML Token Support

[beve]

Jeff Yu and I are working on adding SAML v2.0 support for JBossESB : http://jira.jboss.org/jira/browse/JBESB-2263

We have the following situations regarding authentication:

The calling party has a pre-existing SAML Assertion that is to be validated.
This option is taken care of by JBossSTSLoginModule which is a JAAS Login Module which will call JBossSTS (Security Token Service) to validate an existing SAML Assertion. The SAML Assertion will be extracted prior to calling the service by the client. The client could be an external client using the ServiceInvoker or could be a gateway in the ESB.

Example of JBossSTSLoginModule configuration:

<application-policy name = "jbossesb-saml">
 <authentication>
 <login-module code="org.jboss.soa.esb.services.security.auth.login.JBossSTSLoginModule" flag="required">
 <module-option name="serviceName">JBossSTS</module-option>
 <module-option name="portName">JBossSTSPort</module-option>
 <module-option name="endpointAddress">http://localhost:8080/jboss-sts/JBossSTS</module-option>
 <module-option name="username">admin</module-option>
 <module-option name="password">admin</module-option>
 </login-module>
 </authentication>
</application-policy>

The calling party does not have a SAML Assertion so one needs to be issued.
The issuing of a SAML Assertion will be performed by an action in the ESB called JBossSTSAction. This actions configuration is very similar to the
configuration of the JBossSTSLoginModule since they both use the WSTrustClient under the covers.

Example configuration of JBossSTSAction:

<action name="issueToken" class="org.jboss.soa.esb.actions.security.JBossSTSAction">
 <property name="serviceName" value="JBossSTS"/>
 <property name="portName" value="JBossSTSPort"/>
 <property name="endpointAddress" value="http://localhost:8080/jboss-sts/JBossSTS"/>
 <property name="username" value="admin"/>
 <property name="password" value="admin"/>
 <property name="tokenType" value="http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.1#SAMLV2.0"/>
 <property name="addToEsbMessage" value="false"/>
 <property name="addToEsbAuthRequest" value="true"/>
</action>

The properties 'addToEsbMessage' and 'addToEsbAuthRequest' might need some explaination.

addToEsbMessage means that the SAML Assertion will be set on the ESB Message object using the configuration location. This uses the the PayloadProxy so the normal options are available here. This would be used when you are about to call an external services and need access to the SAML Assertion.

addToEsbAuthRequest means that the SAML Assertion will be added to the ESB AuthenticationRequest. This would be set when your are will be calling other services in the ESB that require a valid SAML Assertion, i.e. that are using the JBossSTSLoginModule.

What still needs to be done is adding the extraction of the SAML Assertions in the gateway(s) and also have the Assertion injected into outgoing SOAP Message Security Headers. Using JAX-WS protocol handlers seem appropriate in this situation but I'll be looking onto this next

Workspace: http://anonsvn.jboss.org/repos/labs/labs/jbossesb/workspace/dbevenius/saml_support/
Quickstart: http://anonsvn.jboss.org/repos/labs/labs/jbossesb/workspace/dbevenius/saml_support/product/samples/quickstarts/security_saml/

Any thoughts or comments are welcome.

Regards,

/Daniel

[beve]

Regarding the adding of the SAML Assertion to the outgoing SOAP Security Header, perhaps a better solution would be to have the JBossSTSAction set the SAML Assertion as a ThreadLocal.
This way we could write a a protocol handler for SOAP which could add the SAML Assertion to the out bound SOAP Header.
This would also simplify the STSAction as it would not require the additional 'addToEsb*' options.

What do you think?

Regards,

/Daniel

[jeff.yuchang]

+1, I think we can go with ThreadLocal first and then see if there any problems.

Thanks
Jeff

[anil.saldhana]

"beve" wrote:
Regarding the adding of the SAML Assertion to the outgoing SOAP Security Header, perhaps a better solution would be to have the JBossSTSAction set the SAML Assertion as a ThreadLocal.
This way we could write a a protocol handler for SOAP which could add the SAML Assertion to the out bound SOAP Header.
This would also simplify the STSAction as it would not require the additional 'addToEsb*' options.

What do you think?

Regards,

/Daniel

Dan., I think this is what the WS-T integration code will do. All you need to use is the API. Provide any assertion that you have. Under the covers the ws-t api should be doing this for you. I think the api is not updated to take in pre-existing assertions. Talk to Stefan to get it added.

[anil.saldhana]

"beve" wrote:
Jeff Yu and I are working on adding SAML v2.0 support for JBossESB : http://jira.jboss.org/jira/browse/JBESB-2263

We have the following situations regarding authentication:

The calling party has a pre-existing SAML Assertion that is to be validated.
This option is taken care of by JBossSTSLoginModule which is a JAAS Login Module which will call JBossSTS (Security Token Service) to validate an existing SAML Assertion. The SAML Assertion will be extracted prior to calling the service by the client. The client could be an external client using the ServiceInvoker or could be a gateway in the ESB.

Example of JBossSTSLoginModule configuration:

<application-policy name = "jbossesb-saml">
 <authentication>
 <login-module code="org.jboss.soa.esb.services.security.auth.login.JBossSTSLoginModule" flag="required">
 <module-option name="serviceName">JBossSTS</module-option>
 <module-option name="portName">JBossSTSPort</module-option>
 <module-option name="endpointAddress">http://localhost:8080/jboss-sts/JBossSTS</module-option>
 <module-option name="username">admin</module-option>
 <module-option name="password">admin</module-option>
 </login-module>
 </authentication>
</application-policy>

The calling party does not have a SAML Assertion so one needs to be issued.
The issuing of a SAML Assertion will be performed by an action in the ESB called JBossSTSAction. This actions configuration is very similar to the
configuration of the JBossSTSLoginModule since they both use the WSTrustClient under the covers.

Example configuration of JBossSTSAction:

<action name="issueToken" class="org.jboss.soa.esb.actions.security.JBossSTSAction">
 <property name="serviceName" value="JBossSTS"/>
 <property name="portName" value="JBossSTSPort"/>
 <property name="endpointAddress" value="http://localhost:8080/jboss-sts/JBossSTS"/>
 <property name="username" value="admin"/>
 <property name="password" value="admin"/>
 <property name="tokenType" value="http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.1#SAMLV2.0"/>
 <property name="addToEsbMessage" value="false"/>
 <property name="addToEsbAuthRequest" value="true"/>
</action>

The properties 'addToEsbMessage' and 'addToEsbAuthRequest' might need some explaination.

addToEsbMessage means that the SAML Assertion will be set on the ESB Message object using the configuration location. This uses the the PayloadProxy so the normal options are available here. This would be used when you are about to call an external services and need access to the SAML Assertion.

addToEsbAuthRequest means that the SAML Assertion will be added to the ESB AuthenticationRequest. This would be set when your are will be calling other services in the ESB that require a valid SAML Assertion, i.e. that are using the JBossSTSLoginModule.

What still needs to be done is adding the extraction of the SAML Assertions in the gateway(s) and also have the Assertion injected into outgoing SOAP Message Security Headers. Using JAX-WS protocol handlers seem appropriate in this situation but I'll be looking onto this next

Workspace: http://anonsvn.jboss.org/repos/labs/labs/jbossesb/workspace/dbevenius/saml_support/
Quickstart: http://anonsvn.jboss.org/repos/labs/labs/jbossesb/workspace/dbevenius/saml_support/product/samples/quickstarts/security_saml/

Any thoughts or comments are welcome.

Regards,

/Daniel

Looks reasonable to me. Just ensure that you do not use any JAXB api as it can mess up the xml signatures. The STS will be the authority in validating as well as issuing assertions.

[beve]

Hi Anil,

Dan., I think this is what the WS-T integration code will do. All you need to use is the API. Provide any assertion that you have. Under the covers the ws-t api should be doing this for you. I think the api is not updated to take in pre-existing assertions. Talk to Stefan to get it added.

Great, I'll talk to Stefan and see I how this would work.

Thanks,

/Dan

[anil.saldhana]

http://anonsvn.jboss.org/repos/jbossidentity/identity-federation/trunk/jboss-identity-fed-api/src/main/java/org/jboss/identity/federation/api/wstrust/WSTrustClient.java

Looking at the signature, the validateToken takes in a dom element representing the saml2 token. So it is already there. Ensure that you parse the token as dom and then feed it to the sts via this api.

[beve]

Hi Anil,

http://anonsvn.jboss.org/repos/jbossidentity/identity-federation/trunk/jboss-identity-fed-api/src/main/java/org/jboss/identity/federation/api/wstrust/WSTrustClient.java

Looking at the signature, the validateToken takes in a dom element representing the saml2 token. So it is already there. Ensure that you parse the token as dom and then feed it to the sts via this api.

Thanks, this is actually what we are using in the ESB for two cases.
One is for a JBossSTSLoginModule to validate an existing SAML token when a call enters the ESB.
The second is in an action that can be used to issue a SAML Token.

My last question if with regard to calling an Web Service. In most case in the ESB a SOAP Message is expected to have been sent in by the client.
So a SOAP Message is the payload of the ESB Message in that case and we have added an action that can update a SOAP Message adding a SAML token.

The next step in our example is to call a Web Service deployed in JBoss AS. I went looking for a SOAP server side Protocol Handler for this but could not find one.
I was thinking that this handler would also use the WSTrustClient to validate the SAML token that should exist in the SOAP Security Header.

I've created an example of such a handler:
http://anonsvn.jboss.org/repos/labs/labs/jbossesb/workspace/dbevenius/saml_support/product/rosetta/src/org/jboss/soa/esb/services/security/auth/ws/JBossSTSSecurityHandler.java
This will take effect by configuring a the target web service will a handler chain:

<?xml version="1.0" encoding="UTF-8"?>
<jws:handler-config xmlns:jws="http://java.sun.com/xml/ns/javaee">
 <jws:handler-chains>
 <jws:handler-chain>
 <jws:handler>
 <jws:handler-class>org.jboss.soa.esb.services.security.auth.ws.JBossSTSSecurityHandler</jws:handler-class>
 </jws:handler>
 </jws:handler-chain>
 </jws:handler-chains>
</jws:handler-config>

This is just a sample but might be easier to see what I mean here with a code example.
I'm not sure if this is the best way to handle this use case either and any suggestions are welcome

Thanks,

/Daniel

[jeff.yuchang]

Looked at the JBossSTSSecurityHandler class, I'd like to propose that we move this kind of handler to the identity federation codebase, along with WSTrustClient class. As I thought this should be reused by other projecs, not only the ESB. Besides, this sort of class should more belong to JBoss STS more than esb itself.

In regard to the ESB, the JBossSTSAction and JBossSTSLoginModule should be enough.

What do you think?

Thanks
Jeff

[beve]

Hey Jeff,

sorry for not replying earlier. As discussed on IM this has now been added to the JBoss Identity project (http://jira.jboss.org/jira/browse/JBID-194)

Regards,

/Daniel

[beve]

Adding a SAML Assertion to outgoing SOAP Messages
=================================================
In what situations should the Assertion be added to the outbound SOAP Security Header:

1. SOAP Processor
SOAPProcessor expects the Body of the ESB Message to be a SOAPMessage. We could use an action that updates/adds a Security Header to the SOAP Message.
This can be done by adding the following action:

<action name="addSamlSecurityHeader" class="org.jboss.soa.esb.smooks.SmooksAction">
 <property name="smooksConfig" value="/smooks/smooks-saml-injector.xml" />
</action>

2. SOAPClient (soapUI)
This action uses soapui for its processing. SOAPUI creates the actual SOAP Message and returns it as a String. But this action also supports
a smooks tranformation. We can use the same Smooks confuration as shown above. So this could be used for the configuration of SOAPClient like this:

<property name="smooksTransform" value="/smooks/smooks-saml-injector.xml" />

3. SOAPClient (WISE)
Since WISE uses JAXWS then we should be able to use a protocol handler for SOAP to add the header.
WISE supports both specifying a 'smooksTransform', like the SOAPUI SOAPClient, and also custom handlers. One such handler can be found in
org.jboss.soa.esb.actions.soap.SOAPSamlHandler.

4. SOAPProxy
HTTPProxy also expects the Body of the ESB Message to be a SOAPMessage. Here too the same Smooks configuration can be used.


Anything you can think of that I've missed?

Thanks,

/Daniel

[jeffdelong]

You mention SOAPProcessor, but how would this work with EBWS?

You state:

One is for a JBossSTSLoginModule to validate an existing SAML token when a call enters the ESB.

What happens after the token is validated? Would SAML tokens contained in the incoming SOAPMessage from the client be propagated through the EBWS gateway? What role does the ESB Message Context play? How will this work with current ESB "rolesAllowed" and "runAs" configurations?

Thanks,

Jeff

[kconner]

I am just coming to this late and for that I apologise.

"beve" wrote:
The issuing of a SAML Assertion will be performed by an action in the ESB called JBossSTSAction.

Can someone please explain why it was decided to write an action to do this rather than use the LoginContext/LoginModule approach? Is there any technical reason why that would not work with SAML?

From what I understand, the SAML token is just another credential and it seems to make more sense for this to be handled indirectly, through javax.security, rather than through direct integration. This would also make it easier when we come to enforce the java security manager integration as we are likely to prevent all actions from modifying this context.

Kev

[beve]

Can someone please explain why it was decided to write an action to do this rather than use the LoginContext/LoginModule approach? Is there any technical reason why that would not work with SAML?

I can't really say that this was a technical reason for this. It just seemed appropriate that the LoginModule should only do one thing and that was to validate an existing token from a calling client.
The client would have somehow called an STS to have a security token issued for the target service. And if the client was the ESB itself it could use the action to have a security token issued for an endpoint that it is going to call.

From what I understand, the SAML token is just another credential and it seems to make more sense for this to be handled indirectly, through javax.security, rather than through direct integration.

Sorry, I'm not following your suggested solution here. Could you expand on what you mean for this to be handled indirectly with javax.security.

Thanks,

/Dan

[kconner]

"beve" wrote:
I can't really say that this was a technical reason for this. It just seemed appropriate that the LoginModule should only do one thing and that was to validate an existing token from a calling client.

Well login modules have two aspects to them, authentication is the first. The second stage is to associate Principals/Credentials with the current security context.

The generation of the SAML context could be handled by this mechanism.

"beve" wrote:
Sorry, I'm not following your suggested solution here. Could you expand on what you mean for this to be handled indirectly with javax.security.

JAAS.

Kev