← Back to team overview

launchpad-dev team mailing list archive

Re: using PermissiveSecurityPolicy when serving private xmlrpc requests

 

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.


-- 
Björn Tillenius | https://launchpad.net/~bjornt



Follow ups

References