Authorization layer

[Aurelien Bompard]

Hey people!

Unless I'm mistaken, there is currently no authorization layer in Hubs. Nothing checks that only johnsmith can edit the johnsmith hub, or that only members of the design team can edit the designteam hub.

Is somebody working on that? Since I think we need it before we can consider a public release, I propose to find a library that would allow us to set and enforce those authorizations, and implement it in the current codebase. At the moment I think the main requirement is auth based on group membership. The library should allow us to assign people to groups based on their FAS groups, but I believe this is more the scope of the authentication library, so I shouldn't matter here.

What do you think? Is it a good time to start working on that?

Cheers!
Aurélien

[Paul W. Frields]

On Thu, Mar 23, 2017 at 10:42:02AM -0000, Aurelien Bompard wrote:
> Hey people!
>
> Unless I'm mistaken, there is currently no authorization layer in Hubs. Nothing checks that only johnsmith can edit the johnsmith hub, or that only members of the design team can edit the designteam hub.
>
> Is somebody working on that? Since I think we need it before we can consider a public release, I propose to find a library that would allow us to set and enforce those authorizations, and implement it in the current codebase. At the moment I think the main requirement is auth based on group membership. The library should allow us to assign people to groups based on their FAS groups, but I believe this is more the scope of the authentication library, so I shouldn't matter here.
>
> What do you think? Is it a good time to start working on that?

Sorry I didn't see this earlier... It would make sense to talk to
puiterwijk about the auth situation here.

[Aurelien Bompard]

Hey!

We talked about authorizations at the hubs meeting today[1], and I'll
try to summarize what I understood from the requirements.

[1] https://meetbot.fedoraproject.org/fedora-hubs/2017-03-28/hubs-devel.2017-03-...

- FAS users have groups in FAS itself, and they have roles for these
groups (member / sponsor / admin)
- OIDC provides a way to get the groups of a logged-in user
- the new API that puiterwijk is developing will provide (a way to
request) the roles a user has in a group
- hubs aren't necessarily named after their FAS group, this
association has to be done manually by a site admin (upon creation or
after)
- once that is done, the FAS groups and roles will be used to limit
actions on a hub
- it will be possible to request membership for a hub. Group members
with the sponsor or admin roles will be able to approve or deny it
directly from Hubs
- group admins will be able to set the hub metadata
- a hub can also have a global visibility setting :
  * public if anybody can see the content (including not logged-in visitors)
  * preview if some information is not accessible to anonymous users,
and the rest is accessible to any logged-in user.
  * private if only group members can see the content

In "preview" hubs, choosing which info will be public and which will
be restricted to logged-in users is going to be very tricky. I can
imagine adding a privacy level to widgets, but I don't know how to do
that on data that isn't coming from hubs (like a newsfeed item).
In the meeting there was also talk of reducing the number of visible
items in the feed for "preview" hubs. That will have to be implemented
in the feed widget itself when the hub setting is available.

Also, FAS groups that are not *-git, or ACL-oriented groups will have
a hub created for them (this is likely to be done by a cron job).

I hope I'm not missing something, otherwise please tell me.

Aurélien

[Máirín Duffy]

On 03/28/2017 01:08 PM, Aurelien Bompard wrote:
> I hope I'm not missing something, otherwise please tell me.

Looks exactly right to me! Thanks for the summary!!

~m

[Pierre-Yves Chibon]

On Tue, Mar 28, 2017 at 07:08:34PM +0200, Aurelien Bompard wrote:
> Hey!
>
> We talked about authorizations at the hubs meeting today[1], and I'll
> try to summarize what I understood from the requirements.
>
> [1] https://meetbot.fedoraproject.org/fedora-hubs/2017-03-28/hubs-devel.2017-03-...
> FAS users have groups in FAS itself, and they have roles for these
>
> groups (member / sponsor / admin)
> OIDC provides a way to get the groups of a logged-in user
> the new API that puiterwijk is developing will provide (a way to
>
> request) the roles a user has in a group
> hubs aren't necessarily named after their FAS group, this
>
> association has to be done manually by a site admin (upon creation or
> after)
> once that is done, the FAS groups and roles will be used to limit
>
> actions on a hub
> it will be possible to request membership for a hub. Group members
>
> with the sponsor or admin roles will be able to approve or deny it
> directly from Hubs
> group admins will be able to set the hub metadata

So far so good :)
> a hub can also have a global visibility setting :
> public if anybody can see the content (including not logged-in visitors)
> preview if some information is not accessible to anonymous users,
>
> and the rest is accessible to any logged-in user.
> private if only group members can see the content

Where would the data for preview and private be coming from?
If everything is coming from fedmsg, then everything is public.
I would caution going to retrieve private information off systems (I'm not sure
we should expose private pagure ticket into a 3rd party app (here hubs) as it
means more layers of security to consider/validate.

Pierre