launchpad-dev team mailing list archive

[Jonathan Lange <jml@xxxxxxxxxxxxx>]

On Mon, Mar 1, 2010 at 7:27 AM, Bjorn Tillenius <bjorn@xxxxxxxxxxxxx> 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.

Yeah, I have no idea on the best way to do the "on behalf of" thing.

jml