Login v3 updates

[djmitche]

A few changes, but the project-member:<project> one is the one I'm particularly interested in getting feedback on.

[jonasfj]

I would think that members of a project should get the scope assume:project:<project>:*

I'm not entirely sure how the project:<project>:... role-pattern is supposed to be used?
When you say "controlled by the corresponding project" that seems weird...

I maybe wrong... but let's say releng does a special nightly project which is a server that run nightly builds.
I would think the role project:releng:nigtly-cron is then given to the client-id that the cron server has, right?

Or do you think that the server would be allowed to programmatically create roles on the form project:releng:nightly-cron:* ??

[jonasfj]

Most of this looks good.. .But I'm not sure I have brain cycles to consider the project related scopes just yet...

@djmitche, so I think we have to rethink the scope-delegation stuff... Particularly, what scopes protect {crud} for client and role... Maybe it's two simple auth:manage-client:... and auth:manage-role:... scopes.

There is some problems with respect to activate and login and preventing people from persisting scopes after they've been revoked.
I tried to outline something in: https://public.etherpad-mozilla.org/p/jonasfj-scope-delegation-draft
But never finished it, this was weeks ago... It contains quiet a few crazy ramblings, feel free to add someone.

Note: it's also possible that this doesn't have to be solved perfectly at first... But I suspect it would be bad not too, since we've built a bit to get to this point.

[djmitche]

A use-case for project:<project>:* roles would be as "utility roles" for a particular group. For example, releng might create, say, project:releng:repo:gecko-clone that contains the scopes required to build a git clone of the gecko tree (for some hypothetical try-via-github-clone thing). Then they bless particular github repositories with the abliity to build by adding assume:project:releng:repo:gecko-clone to the repo:github.com/<whoever>/gecko:branch:* role. So basically they might be a good way to write a large set of scopes once and use it in many places.

I chose project-member:<project> instead of project:<project> to avoid confusion between project:<project> (granting admin over the project) and the very similar project:<project>:* (granting all project-related roles).

I wouldn't mind switching to auth:manage-{client,role}:<id> -- it would save some typing anyway (and match that for hooks).

As for delegation, I need you to spell out the problems you're seeing explicitly. With the addition of projects, I think the current plan covers all of the use-cases I know of.

[jonasfj]

As for delegation, I need you to spell out the problems you're seeing explicitly. With the addition of projects, I think the current plan covers all of the use-cases I know of.

Oh, yeah that seems unrelated to this... My concern is a different use-case, nvm...

I'll think a bit about the project-member: thing... Looks interesting..

[djmitche]

@jonasfj: would project-admin:<project> make more sense?

[djmitche]

I'm going to land this since it's documenting what's in place now. It's easy to change later (easier if I do it programmatically rather than copy/pasting scopes in the tools UI!) and we can just adjust the docs at that time.