caspervdw
commented
4 years ago Proposal after talk on 1-10-2020 (@reinout @lirrypinter @joeriverheijden @jonasvsl @lisannewapstra):
1) A manager creates an invite for a user (supplies email address). 2) The user gets the invite by email with in it an invite link (like lizard.net/login?invite=dviahsroi3dwdfwvadew...2ah) 3) The link redirects to AWS Cognito where the user can sign in. 4) If the user returns, the invite takes effect and roles are assigned and a user is made / connection to existing user is done.
Big federated identity providers (University / Google / Facebook) These can be enabled per application, if needed. The application must reject these users if they don’t come from an invite. Some demo applications might be an exception: they could accept these users.
Do we need a public sign up page? What if a user got an invite, but has 0 accounts? He needs a new account. A public sign in page would be easiest.
Cons:
- all applications would have to deal with the fact that anyone can authenticate.
they would have to deal with this anyway. A user can get an AWS account from Lizard and use it to authenticate in EFCIS.
- customers can get a wrong impression if they make an account for Lizard, but then can do nothing with it
Maybe we can do some custom pre-signup lambda trigger to test whether the user got an invite: https://docs.aws.amazon.com/cognito/latest/developerguide/user-pool-lambda-pre-sign-up.html . TBD
Other open questions:
- How to gently tell users that have authenticated, but do not have a role in the application?
- Does Amazon replicate to the US? How local is the storage?
- Where to store Organisations UUIDs?
Currently, user management is done via
As users will migrate away, we need to decide how to change this.
Some thoughts are here: https://docs.google.com/document/d/1SnlCkQUhGcnqqJcglle33fAUpcKn1BIyIhRpfRJliYs/edit
The amount of work depends on the chosen solution. Functional requirements will be formulated by Joeri