Web services authorisathion based on Tomcat authentication?

Given the nature of the web, how do you guarantee that the session asking for the data is the same one that did the authentication unless it passes a token back and forth?

OpenEdge Web Services / the WSA do not give you access to any http information or the SOAP header information. You'll only get infromation to the SOAP body.

Whenever I need more flexible Web Services I create them as ASP.NET Web Services and communicate to the AppServer using the .NET Proxy. I assume, that you could do a similar setup with AXIS and the Java Proxy.

I might not see the entire picture here, please bear with me if that is the case.

As far as I know the http header contains a field Authorization which after a basic http authorization contains a Base64-encoded username:password. I was hoping there was some way to make Tomcat somehow pass this on via the soap-message (or somewhere else which makes it available to the progress code).

Somewhere along the lines of what is suggested as alternative 2 in this post:

http://www.psdn.com/library/thread.jspa?messageID=48023&#48023

@Thomas: Isn't this "token" the http Authorization field? If this field could be coupled with the Soap message wouldn't I be able to guarantee this?

@Mike: If the Soap header and http info is unavailable with OpenEdge Webservices I'll have to find another solution.

@Both/all:

The only solution that comes to mind if I'm sticking to Openedge Webservices is to have username and password as parameters for each procedure that requires authorization. Is that really the only way to go?

Are there any best practices as how to do authentication/authorization with web services in Progress? I haven't been able to find much information about this.

Lars, it's right - in a .p file, you have absolutely no access to anything part of the http header or the soap envelope.

The thread you have linked to seems to be related to Sonic ESB and that's completely a different story.

Passing username and password in the soap body (as part of the message) seems problematic if you are not able to provide a secure encryption/decryption algorithm.

That's why I prefer to build the Web Service (SOAP and http handling) in ASP.NET (C# or VB.NET) and use the OpenEdge .NET Proxy (built in the ProxyGen as well) to call the same .p you are using for the WebService now. The big advantage here is, that you have access to the SOAP envelope and http header as well and could transform the required information to regular parameters passed to OpenEdge.

Second advantage is, that it's much easier to implement a given WSDL file with a .NET Web Service (design WSDL first) as the Visual Studio is able to import that WSDL and build the required code to implement a service. For OpenEdge Web Services it's always .p file first and the WSDL file get's generated with very little chance to influence it. In the projects where I needed to implement a given WSDL file, I've never been able to implement exactly the required WSDL file with Progress.

Disadvantage: An IIS and licenses for the IIS are required for this approach. But that has been acceptable in my projects.

But: With little Java knowledge the same should be possible with Axis or Glasfish as well and use license free software.

A simple token based session management can actually be done by the WSA when the AppServer is using another operating mode then session-free (=State free).

But you have no influence on that from ABL code.

I was thinking more in terms of having the user log in and receive back an authentication token which could then be supplied in subsequent posts. Even with state-free there is no problem maintaining a list of current tokens and permissions in the database.