Web service security callbacks

[heiko.braun]

The current WS implementation has a dependency on the JSDK API in order to provide principal and credential. Since the ESB does provide it's own transport layer I am wondering how the security information should be obtained for a web service invocation?

[tfennelly]

Not sure actually Heiko, but you can help us figure it out ;-)

So is the security info not part of the SOAP payload?

[marklittle]

Heiko, are you concerned about how we might provide the principal/credential information to JBossWS via the ESB, or how the ESB is going to do this in general, i.e., across different transport types and not just SOAP/HTTP?

[heiko.braun]

Integrated with the AS we receive principal/credential from the invocation layer, which then internally delegates to the security framework. It's basically JBossWS doing a callback to either the servlet or ejb tier.

For the ESB with it's own invocation layer (you setup your own transport) it doesn't seem to be defined yet. So yes, I think this addresses a general problem across different transport types and not just SOAP/Http in particular.

[marklittle]

Yes, it's not defined yet and yes, it does no to be addressed cross-transport. My concern was that you may have been assuming we'd be tying security to WS-Sec. We'll use that where applicable, but that's not always the case.

[heiko.braun]

Well, WS-Sec is just one example of what doesn't work unless we have a solution ;)

Do you know when this will be addressed? I need to reschedule that issue accordingly:
http://jira.jboss.org/jira/browse/JBWS-1910

[marklittle]

Not until after the SOA-P release, I'm afraid. Hopefully in the first CP release for the platform.

[kconner]

My understanding of the issue is that the WebServiceContext (or should I say it's creation) currently has a hard dependency on servlets and it is this dependency which is causing our problem. As we are not calling into jbossws via a servlet container we do not have servlet contexts etc.

It would be much better if the InvocationContext supported the methods required by the WebServiceContext (such as user principals/roles) in a generic manner and therefore break any hard dependency with the container. The WebServiceContext could then defer its functionality to the InvocationContext.

What I have still to understand is why this is not evident from your JMS support. Looking at the code would suggest that it would suffer the same issues as are displayed from invocations coming through the ESB.

Is my understanding correct?

[marklittle]

This is my understanding too, but I was hoping to defer any long discussions until after SOA-P is released (timing is everything ;-)

[kconner]

I was trying to point out that the JBWS work should not depend on any ESB work and that there should be no reason for delaying it.

It was not my intention to enter a protracted discussion :).

[marklittle]

Hey, I know how our conversations start so I was extrapolating ;-)

[heiko.braun]

Well, it works a little different. The container integration needs to supply a WebServiceContextFactory implementation, which is responsible to provide a WebServiceContext implementation particular to the invocation.

See [1] for further explanations.

As I pointed out several times [2], we need to consider ESB a container on it's own and provide a customized integration layer for it. I think the current SPI will do.

Regarding the JMS example: It's a EJB invocation the delegates to the EJBContext. Thus no problem there.

[1] http://jbws.dyndns.org/mediawiki/index.php?title=SPI

[2] http://jbws.dyndns.org/mediawiki/index.php?title=ESB

[heiko.braun]

However, if this doesn't lead to an instant solution ;) I'll reschedule the related issue for subsequent releases. Maybe we find some time to talk about this at the dev conference in Orlando.

[kconner]

Interesting documents, I'll go through them this weekend and have a play around.

[marklittle]

However, if this doesn't lead to an instant solution ;) I'll reschedule the related issue for subsequent releases. Maybe we find some time to talk about this at the dev conference in Orlando.

We need to remember that what we have at the moment in terms of WS support fits the release requirements for the initial platform. Unless there's a clear need, I can't see this changing until the first CP at the earliest.

JBW would be a good place to discuss. Don't forget to register ;-)