Since webservice calls are stateless, your login wont persist across separate webservice request.
You should either implement a custom JAX-WS handler which does the login for you every time.
Or to get the stateful service, send the cid parameter from the webservice client when you make subsequent request after login call.
Seam sends you the cid parameter in the SOAP header after the first login, then by sending back the cid parameter in the header you should be able to join the same session. So you will have the identity information.
Ok cool that makes sense.
How exactly would I join the same session from the CID, and would i rejoin this session within the web service method?
if you sent the cid in the soap header as described in the doc, seam will pick that up and join you to the same conversation if a conversation with same cid exists.
Its like using conversation-id as key for state management.
If you are using a JAX-WS based client, you may need to write additional custom handlers to the add cid information to the soap header. And configure them to be apply on outgoing and incoming messages.
If you are constructing the whole request message manually then its easy to insert the cid to the SOAP header.
So are you saying that the action class must be conversational for it to work (i.e. @Scope(CONVERSATION))?
To implement a stateful webservice requires a extra coding in webservice client normally in any framework. Easiest is to use them as stateless services.
If all you need is authorization and restrictions to access the webservice. Then you should perform authorization at container level, or by custom SOAP handler code.
Or inject the webservice context through @WebServiceContext annotation, so you can access request and response objects within your webservice.
There are several ways to implement security in webservices.