ACEGI Authentication and WSDL

[res1st]

Hi!

The ACEGI authentication example of the airline app is interesting, but i have problem to understand it completly.

The client has a callback handler which sets the username and password. That's ok. But i thought i get something like a session ticket back to call web services. But i doesn't see one.
I also thought i should at something like the session ticket to my wsdl specification.

<operation name="myWebService">
  <input>
    <soap:header use="literal" message="tns:Header" part="mySessionHeader"/>

How does it work in the airline app? Needs the authentication done for every request again in the airline example?

How can i archive the session key strategy with Spring-WS and ACEGI?

Cheers,

Ingo

[Arjen Poutsma]

Hi!

The ACEGI authentication example of the airline app is interesting, but i have problem to understand it completly.

The client has a callback handler which sets the username and password. That's ok. But i thought i get something like a session ticket back to call web services. But i doesn't see one.
I also thought i should at something like the session ticket to my wsdl specification.

<operation name="myWebService">
  <input>
    <soap:header use="literal" message="tns:Header" part="mySessionHeader"/>

How does it work in the airline app? Needs the authentication done for every request again in the airline example?

How can i archive the session key strategy with Spring-WS and ACEGI?

The recently added security module implements WS-Security. WS-Security does not rely on the underlying transport (HTTP in this case). Instead, it places all security-related stuff in the soap message itself. Therefore, it doesn't (or can't) rely on the HTTP session to contain security credentials.

This becomes more clear when you think of a setup where messages don't come in via a HTTP transport, but via JMS. Clearly, JMS does not have a HTTP session, so you cannot rely on it being there all the time. If you're looking at the future of SOAP, you will notice that more and more stuff is being put in the message itself, and the underlying transport is used less and less.

So to answer your question: WS-Security does indeed require a new authentication every time you send a message. And while using a session may sound as a good idea, it is not compliant with the spec. You could add the session id in a header, of course, but that would mean that all clients would require custom code to call your WS and cannot use a standard WS-Security implementation any more.

Cheers,

[res1st]

Thank you for the answer!

WS-Security does indeed require a new authentication every time you send a message. And while using a session may sound as a good idea, it is not compliant with the spec. You could add the session id in a header, of course, but that would mean that all clients would require custom code to call your WS and cannot use a standard WS-Security implementation any more.

Ok, my clients would need custom code to call my service, if i would use a session key. Is there any reason why they didn't support this way? I think the session key strategy is common, easy and much faster.

Another question. How does a client know, that the operation defined in my wsdl is a WS-Security protected web service?
I've looked in the WS-Sec spec, but doesn't found anything.

Cheers,

Ingo

[Arjen Poutsma]

Ok, my clients would need custom code to call my service, if i would use a session key. Is there any reason why they didn't support this way? I think the session key strategy is common, easy and much faster.

They did this because they want SOAP to be independent of the underlying transport layer. If you depend on HTTP-specific features like the session, you cannot forward the message to something like a JMS queue.

Another question. How does a client know, that the operation defined in my wsdl is a WS-Security protected web service?
I've looked in the WS-Sec spec, but doesn't found anything.

Ws-Security doesn't cover this, but WS-Policy does. I have not looked into it much, but there is a page here.

Cheers,

[res1st]

They did this because they want SOAP to be independent of the underlying transport layer. If you depend on HTTP-specific features like the session, you cannot forward the message to something like a JMS queue

I think a session can also be application specific, it doesn't needs to be a http session. The server app needs to identify which user has sent a message. It's faster to look for a valid session number (=> authenticated user) than to reauthenticate username/password. An JMS message can also include an session key. That's why i doesn't understand the problem.

Ws-Security doesn't cover this, but WS-Policy does. I have not looked into it much, but there is a page here.

Ahh thank you.

[Arjen Poutsma]

I think a session can also be application specific, it doesn't needs to be a http session. The server app needs to identify which user has sent a message. It's faster to look for a valid session number (=> authenticated user) than to reauthenticate username/password. An JMS message can also include an session key. That's why i doesn't understand the problem.

Well, I'm not going to argue with you here: it is faster to use some sort of session mechanism. It's just that it isn't in the spec .

[res1st]

Ok, i'll blame the WS-Sec guys for that.

Ingo