Thanks a lot, that helps, though I am not 100% sure I understood it correctly 😊. Therefore my use case (I should remember to start with a real use case first and then talk about my thinking instead of starting in the middle of it.):
A user logs into the decentralized system (4 different frameworks, running on Windows and Linux) using CAS single signon (which works like a charm in OpenACS by the way). The user goes to system A and says "I want to prepare a product to be produced", he does all the necessary steps of the preparation and once finished he says "Start Project". This is the moment that system A sends over information to OpenACS to create the project, fill in the workflow, add the users to the project and start the workflow with the first task. This is done by calling a webservice provided by OpenACS (TWiST or xosoap).
What do I have at this stage:
a) A single signon cookie, but maybe not an OpenACS cookie yet, because it is not guaranteed that the user signed on to OpenACS before that operation (and the OpenACS cookie is only set once he tries to access an OpenACS webpage).
b) A username / e-mail
As you can see I do not have the password, as the password is only stored in the CAS system. This pretty much rules out HTTP based authentication, am I right?
Even if the user had logged into OpenACS first, I cannot use the cookie as the call comes from the remote server (system A), not from the users browser. Or did I miss something?
I could use HTTP authentication to authenticate System A and provide the username in the SOAP headers, effectively allowing me to check for the permissions for that user. But then I would have to trust System A that noone could login to that system and "fake" the username to be used in the remoting service.
Therefore, is the last one the way to go or did I miss something on the way.
I am not entirely sure how we could use the cookies to do the authentication (as I am not sure that System A is allowed to read the cookie), but if we could send the CAS cookie then I could do the authentication checking (see if the session is still valid) and find out about the username that way (I assume).
Again, thanks a lot for your advise it is really appreciated.