Trackman 2.0: Auth/Authz support

[echarlie]

From @matthazinski on April 27, 2015 5:41

Trackman 2.0 should require LDAP auth. This is a major schema change. The advantage of this is that it makes a distinction between users and shows and increases security in case we eventually want to expose it to the Internet.

Users login using their WUVT LDAP credentials (and must be a member of at least one group from a list of TRACKMAN_ALLOW_GROUPS in config.py). From there, they are presented with a list of shows they are a member of, with the option of creating a new one.

For each show that is created, users specify:

• On-air name
• Show name
• List of space-separated LDAP usernames that have access to this. (You can't create a group that you don't have access to yourself)

Any user with access to the show may change any parameter of it, including the allowed users. Any user in any group in the list TRACKMAN_ADMIN_GROUPS (in config.py) may edit any show, regardless of whether they have been granted access by the show creator. The use case of this is staff heads, FMPD staff, technical staff, and talk shows.

Any user in the librarians group (or whatever LDAP group list parameter we use in config.py) may edit historical tracks in Trackman (e.g. the ones that come up in search results).

Another ticket to follow with trackman UI changes for version 2

Copied from original issue: wuvt/wuvt-site#158

[echarlie]

From @mutantmonkey on May 16, 2016 4:50

I don't really like the idea of this, honestly. My concern is that DJs will use a forgotten password as an excuse for not logging tracks.

[echarlie]

From @matthazinski on May 28, 2016 18:6

I want to eventually move automation further along the airchain so we could require authentication to get on air in the first place.

[echarlie]

From @matthazinski on October 2, 2016 20:18

Revised design per IRC discussion with @mutantmonkey :

• Accessing trackman requires either LDAP auth (with user in fmdjs group) OR a guest login. Choosing the guest option requires the user to select/enter a reason for choosing this option, and emails a configurable list of people.
• Once logged in (as LDAP or guest), the user can choose an arbitrary show in the shows list or create a new one, as was previously the case.
• Store a list of LDAP accounts associated with a show and make these clearly visible to authenticated users. This would prevent users from using someone else's show.

Future enhancement ideas:

• Allow non-guest login outside the internal address space
• Store playlists online to allow users to queue up tracks before their show. These would likely need to be associated with a show rather than an LDAP account
• Stricter ACLs and/or alerting for which LDAP users are allowed to choose which shows.

[echarlie]

With more complete OIDC support (and support for multiple auth backends), we could allow DJs to log in with their facebook or gmail account (passwords for which I know they won't forget). This reduces the burden on IT for creating accounts.

[echarlie]

From @mutantmonkey on February 21, 2017 4:25

So, after some discussion on IRC, we've decided to split this into two separate tasks: authentication and authorization.

We're not going to look at authentication right now, but will in the future.

For authorization, there is very little to do. We already store a djset_id on the Flask session. We just need to add a check that the djset_id matches what the user is trying to access.

[echarlie]

so, some observations about potential issues with this (should we do automation lock-out):

• allowing automation to take over the airchain requires relays or something ugly until we have AoIP
• if we move to AoIP, a lock-out is easier, but it would be difficult to handle a DJ logging into trackman allowing them to take over the airchain
  • how do we know which console they are able to take on-air? suppose I log into trackman from FM, but the DJ in AM hits the user key to take the console on air; how do we prevent that
  • what sort of intermediate hooks would we need to control the routing salvos or whatever to make this work?
• If you have a guest DJ who is trained but doesn't DJ regularly (e.g. josh arritt), how do you ensure they can go on-air?

[mutantmonkey]

Refer to #56 for the implementation plan for authentication. I have no plans to require authentication for the DJ-facing interface in the station at this time.