Forum OpenACS Development: Re: Permissions on webservices

Collapse
2: Re: Permissions on webservices (response to 1)
Posted by Gustaf Neumann on 09/08/07 11:13 AM
I would not recommend to invent new mechanisms for remoting, but using existing one as far as possible. Concerning authentification, it seems that HTTP basic authentification is approach is at least a start and provide accounts for the remote sites. We designed the xotcl remoting services to be compatible with xotcl-core policies (e.g. dependent on package_ids). In principle it should not matter, whether a request was submitted via URL, xml-rpc, SOAP or whatever. One might want to offer certain permissions to certain users to one package instance but not to others (e.g. update some xowiki pages of the documentation, but not for some announcements). It should be possible that the package administrator (or community administrator) makes this decision in a decentralized way.
Collapse
3: Re: Permissions on webservices (response to 2)
Posted by Tom Jackson on 09/08/07 06:08 PM
In TWiST, with OpenACS, you use the normal cookies and session to identify the user.

Prior to invoking the service, you have to establish an account for the client.

Then you have two options:

1. create an additional operation for web services for login. They present the credentials and you return the session cookies and other info so that the client can reuse them.

2. Client reuses info above either as a cookie or as part of the request.

For example Google's AdSense web service uses SOAP headers to provide the credentials. But Amazon's S3 web service (the WSDL interface) uses additional params in the Soap body document. Both use a long lived credential (I think). TWiST uses a session and HTTP cookies.

Once the user is identified, the next question is can they perform the operation, first generally on the object type and second on a particular object. If there are different classes of users of an object, how do you control both the definition of the webservice and their access to it?

Query-writer already provides a HTTP/GET/POST interface which handles all of this. Extending it to a remoting interface of any type would not be difficult. One thing missing for extending to WSDL is a mapping of internal types (database or filters) to XML-Schema types. Query-writer can also be configured to run any other permission checks on any other attributes before performing the operation (for instance if you add a wiki page, you need permission on the wiki package, but also, if you can set the owner, you need permission on the value of that attribute as well.

Collapse
4: Re: Permissions on webservices (response to 2)
Posted by Stefan Sobernig on 09/08/07 06:15 PM
As Gustaf Neumann pointed out already, for remoting by our xotcl remoting services, you can use policies quite similar to xowiki's (though with some extra privileges/ conditions) on service implementations (in the sense of acs-service-contract). In this context, we call them "invocation access policies".
Concerning authentification, it seems that HTTP basic authentification is approach is at least a start and provide accounts for the remote sites.
These policies refer more or less to the enforcing part of such an access scheme, the way how you can transfer identity information in a remoting setting is quite manifold:
  • One might use basic http authentication mechanisms to transfer credentials.
  • Cookies can also be used!
  • You can pack the credentials as header information into SOAP messages etc.
Trust-related issues are a bit more complex to handle, but there are ideas around (WS-Security, WS-Trust) to tackle these. The above, however, should be sufficient to start with.