Centralized accounts with a generic login: Username/password, CAS, ...

[TomNaessens]

This is a ticket for a discussion to implement a centralized account system. At the moment; login is only available through CAS and only FK-praesidiummembers are able to create and manage events. In time, we will probably receive questions if it is possible for non-FK organisations (other konvents, etc.) to use our system as well.

Therefore, I would like to ask the following two questions:

1. Do we want to include this functionality in Gandalf?
2. If yes, when? Is this something that can be added later on, when the need comes or is this a alteration that would need a lot of migration?

[maartenhbe]

About 1:

I would also include this functionality in Gandalf. Maybe simply split the logic (option A): FK organisations have to login via CAS because they have, per definition, at least 1 member of their organisation with a CAS-login.

Another option (option B) is to give everyone an account without CAS but they can link/register/login with their CAS-account to make the link with the FK organisations database. This can even be done by simply entering their UGent username in the backend. This way, they can login via both CAS and the normal account system (like Minerva and the very very old FK intranet). For each user you can then query the FK database via the API to check if they are an FK organisation or not and act accordingly.

About 2:

Adding something like this later on might be troublesome if the system is not designed to use multiple signup mechanism.

Option B from above would remove the need to migrate everything to the Gandalf server.

Sidenotes:

How will you handle the registration of new organisations to prevent random people from creating an account and create an event in th name of organisation X? Will this be done by Zeus?

[TomNaessens]

About 1: The easiest implementation would be to create an account with an empty password for CAS users that always have to log in through CAS and a normal username/password combination for non-CAS users. This way, we can work with one type of account in the application without having to define a lot of edge cases.

How I see it; we should limit the use of these accounts to the bare minimum: guests shouldn't have an account and neither should partners/VIPs/… The account would only be needed for administration and/or scanning purposes.

About the side notes: This would indeed need a sort of approval system. The way I see this is as follows: A guest is able to request to create an organisation. To do this, he needs to fill in some basic information and a motivation. These applications are stored in a table somewhere in the backend where a user defined as an admin can (dis)approve these requests.

A user will be defined as an admin if his username is part of some array of usernames in the configuration files. This way, we can allow multiple “superadmins”.

From: maartenhbe Sent: ‎Sunday‎, ‎5‎ ‎January‎ ‎2014 ‎10‎:‎10 To: ZeusWPI/Gandalf Cc: Tom Naessens

About 1:

I would also include this functionality in Gandalf. Maybe simply split the logic (option A): FK organisations have to login via CAS because they have, per definition, at least 1 member of their organisation with a CAS-login.

Another option (option B) is to give everyone an account without CAS but they can link/register/login with their CAS-account to make the link with the FK organisations database. This can even be done by simply entering their UGent username in the backend. This way, they can login via both CAS and the normal account system (like Minerva and the very very old FK intranet). For each user you can then query the FK database via the API to check if they are an FK organisation or not and act accordingly.

About 2:

Adding something like this later on might be troublesome if the system is not designed to use multiple signup mechanism.

Option B from above would remove the need to migrate everything to the Gandalf server.

Sidenotes:

How will you handle the registration of new organisations to prevent random people from creating an account and create an event in th name of organisation X? Will this be done by Zeus?

— Reply to this email directly or view it on GitHub.

[maartenhbe]

I was thinking, do we already need this next semester? I would postpone this for the summer and concentrate on the core functionality of a ticketing system. This way the main workflow can be tested thoroughly this year in a "controlled group" of people (FK organisations, the type of people and organisations we know best and not a random organisation).

[TomNaessens]

I don't see a case where we need this for the the second semester, so I agree to postpone it.

2014/1/17, maartenhbe notifications@github.com:

I was thinking, do we already need this next semester? I would postpone this for the summer and concentrate on the core functionality of a ticketing system. This way the main workflow can be tested thoroughly this year in a "controlled group" of people (FK organisations, the type of people and organisations we know best and not a random organisation).

---

Reply to this email directly or view it on GitHub: https://github.com/ZeusWPI/Gandalf/issues/261#issuecomment-32619934