launchpad-dev team mailing list archive

[Michael Hudson <michael.hudson@xxxxxxxxxxxxx>]

Bjorn Tillenius wrote:
> On Mon, Mar 01, 2010 at 07:17:25AM -0500, Jonathan Lange wrote:
>> On Thu, Feb 25, 2010 at 3:50 PM, Michael Hudson
>> <michael.hudson@xxxxxxxxxxxxx> wrote:
>>> Bjorn Tillenius wrote:
>> ...
>>>> So, I thought a bit more about this. I think it makes sense for the
>>>> private XML-RPC server to work in a similar manner as scripts work.
>>>> However, I do want us to get rid of the PermissiveSecurityPolicy, since
>>>> it's a bit too permissive. Instead, I want the scrips (and private
>>>> XML-RPC server) to set up an interaction using a special "system user"
>>>> principal, or a principal more specific to the current task. The latter
>>>> is better, but the former might be enough, at least to start with. The
>>>> normal security policy can now look for this special principal, and give
>>>> appropiate access.
>>> This all sounds reasonable to me.  Being a bit more sophisticated about
>>> principals for the private XML-RPC server also sounds nice because there
>>> are some methods (translatePath, createBranch) which act on behalf of a
>>> Launchpad user and currently use the test helpers 'login_person' and
>>> 'logout', which is a bit ick.
>> I guess this is a bit orthogonal, but I've been thinking about whether
>> we could use the API for our internal services (such as codehosting).
>> If we did, what would the security model look like?
> 
> It would look pretty much how I described it. We would keep our existing
> web app security policy, and would have to define one or more "system"
> users, as which the internal systems would authenticate. It's a bit
> trickier here, since our web service API users don't have the same
> freedom as our internal API users. For example, scripts can do things on
> behalf of other users. When the link a branch, they can say which person
> should be registered as linking the branch. I think we would have to
> rework how the API works, in order for our internal systems to use it,
> but maybe not.

I think it makes sense to think about the authorization/authentication
split here.

Requests to the app server can be authenticated in two ways -- via a
session cookie and via an OAuth token.

In practice, requests to the private xml-rpc server are currently
authenticated by simply saying that if it's possible to make the request
at the network level, you're authenticated to make it as well.

I guess I started this thread by asking for a way to authorize these
requests differently too.

For the "on behalf of" requests to the internal xml-rpc server, we avoid
Launchpad's usual authentication and use login_person.  Now I've stared
into the zope vortex for a bit longer, I think I can see different ways
of doing this (e.g. adding a X-Launchpad-User: mwhudson http header to
the request), although they'll require hacking at slightly scary
publication code.

Having said all this, what could "we could use the API for our internal
services" mean?  There are a few different aspects I guess:

1) We could use OAuth for authentication, presumably as some kind of
not-yet-invented principal.  This would make the system more secure in
some sense, but isn't really solving the problem I wanted to solve in
this thread, and it wouldn't help the "on behalf of" API calls.

2) We could use lazr.restful for serializing the requests and invoking
the code on the server side.  This would be great, as XML-RPC faults and
xmlrpclib's string/unicode handling both make me want to scream.  James
Westby is working on a twisted lazr.restful client which I guess we'd
use in our Twisted services.  This is entirely orthogonal to both
authentication and authorization.

3) We could direct our services at api.launchpad.net.  I don't think
this would be a very good idea -- translatePath for example has no place
in a public-facing API.

In summary, something like running an api.lp.internal service that did
authentication in its own special way and a 'system user' principal
would seem like very useful things to have.  A fair bit of work though.

Cheers,
mwh