WS-Trust Integration in JBoss Identity

[anil.saldhana]

Currently Stefan has implemented a JBoss STS building on the object model in the JBoss Identity project.
http://www.jboss.org/community/docs/DOC-13642

Given this, from an user's perspective, there are two options:

Option A:
====
User configures the JBoss STS from JBID. In this case, the delegation of the core WS functionality needs to be sent to the JBossWS stack (irrespective of which underlying stack exists - native, cxf or metro). I think Stefan is pretty clear on this end (except that the client code has some JBossWS classes). Apart from that, it is plain Jax-WS usage.


Option B:
=====
User would like to use the WS-Sec implementation that is present in the JBossWS stack. During the usage, the user would like to delegate the ws-trust token handling to the JBID infrastructure. For this use case, Stefan needs to know what handlers/interceptor chain or such exists in the JBossWS stack to provide token handlers for ws-t (saml token profile, x509 etc).

Maybe something here? http://anonsvn.jboss.org/repos/jbossws/legacy/tags/jbossws-2.1.0.Beta1/jbossws-core/src/main/java/org/jboss/ws/extensions/security/

[asoldano]

Hi Anil/Stefan,
I'll be commenting more in details on this soon (need to take a look more in details at CXF).
Regarding JBossWS-Native, perhaps you'd need to refer to the latest tag: http://anonsvn.jboss.org/repos/jbossws/stack/native/tags/jbossws-native-3.1.1.GA/modules/core/src/main/java/org/jboss/ws/extensions/security/
The ws-security processing basically occurs starting from a handler running before jaxws user handlers for incoming messages and after them for outcoming ones.

[anil.saldhana]

Alessio, I think we will continue to do the Option A for the SAML token profile handling. Once that is done, we will look at option B for both the username and saml profiles. That will also give you time to look into CXF.

[asoldano]

Anil,
I've done some basic research regarding CXF. First of all, let me clarify there's currently nothing implemented in Native stack regarding ws-trust, so the only way I see users using ws-trust is they call the STS you're implementing as they would do with any other service endpoint. Then they manually create the messages for the service provider, etc.
I think that's basically the Option A you wrote before, isn't it?

We'll offer WS-Trust functionalities with JBossWS-CXF instead. I've just committed some testcases adapted from the Apache CXF sources that basically call the WS-Trust 1.0 test STS and endpoint of the WCF interoperability plugfest (http://fisheye.jboss.org/changelog/JBossWS/?cs=9974).
A brief chat with Daniel Kulp (the CXF prj lead) confirmed that currently CXF has implementation for WS-Trust client side only, so no token validation at server side, etc.

On client side, CXF currently have means of easily configuring the STS client: http://cwiki.apache.org/CXF20DOC/ws-trust.html: that works fine in JBossWS-CXF and would work with any STS implementation I think. We might want some kind of better integration tough.

So, to sum up, the whole server side is still missing, so there's currently no interception point for that. I'll take a look at the identity stuff to understand what we could do better on client side for now.

Please tell me if I'm missing something in the whole picture (which might be)

[sguilhen]

Alessio,

I've done some basic research regarding CXF. First of all, let me clarify there's currently nothing implemented in Native stack regarding ws-trust, so the only way I see users using ws-trust is they call the STS you're implementing as they would do with any other service endpoint. Then they manually create the messages for the service provider, etc.
I think that's basically the Option A you wrote before, isn't it?

Yes, that's it. We currently have no ws-trust integration code for the STS service, so clients must call the STS just like they would need to do with any other service endpoint.

Of course, this doesn't prevent us from implementing profiles for the STS (SAML, Kerberos, X.509, etc), but we want to have this integrated with JBoss WS at some point. I don't know how much work would be involved in implementing ws-trust (IssuedToken policy assertions) support for the native stack, so we could probably start with the JBossWS-CXF stack, even though it lacks server-side support for token validation.

What about JBossWS-Metro? Does it have support for ws-trust as of now?

[asoldano]

Hi Stefan,
implementing WS-Trust in JBossWS-Native is not an option at all. JBossWS-CXF is the way to go for WS-* right now. I didn't look in details at the Metro implementation of WS-Trust, but even if I think that might even be complete and interesting from a JBossWS community point of view, I think the integration with the CXF stack should be considered first. This might even be something we focus on in the collaboration with CXF.

[sguilhen]

Hi Alessio,

that sounds good to me. I think we can start with JBossWS-CXF, as it has the ws-trust client side already working, and see later if we can collaborate with CXF on the server-side implementation of the token validation logic.

For now we will focus on the implementation of the SAML token profile.
Thanks for your input!

[anil.saldhana]

Alessio/Stefan, let us keep this communication channel (namely this thread) active. Going forward, we need to be in proper sync with the multitude of SOAP stacks, xml binding libraries and internal JDK WS/xml stacks (starting JDK6) all playing havoc. The key here is to be in sync and proper documentation. :)