Adding role-based authentication

[pgwillia]

Currently, we're using basic authentication with a single username and password.

https://github.com/ualbertalib/library-cms/blob/712fdaa848fa87311417536d9e2a2f961305414e/app/controllers/profiles_controller.rb#L37

We would prefer having role-based authentication where we can audit changes and manage access.

[murny]

Have some questions for this work:

• Roles: Do we actually need different roles like maybe author, editor, admin, etc? ? Or just a generic "Admin" role is good enough (e.g. anyone who has an account in the system is an admin by default)?

• Do we want to use SAML with Ualberta login system like we did with Jupiter? AKA, you are using your ualberta email and account to login (via https://login.ualberta.ca/) into library cms? Or will we manage this ourselves and have our own library-cms accounts?

• How will new accounts be created? Can users sign up for an account? Do they get invited? Possibly a bit of both? E.g. they can "log in" via ualberta's SAML but can't do anything until a current admin approves their account?

  • My thinking is we might have to create the first users in the database via console access or a rake task or something? Then new users can be invited by or approved by other admins?
  • If we cannot ssh into production or use production console, then we might have to live in a dual world of the current basic auth and the new user stuff? Then, once we have some initial users, we can remove basic auth?

• Do we need a UI for users in the admin area? Maybe this looks like the one we have in Jupiter, where you can view users, disable users, invite new users, etc?

My guess is we want Ualberta login via SAML (but maybe the MVP just has a simple authentication via our own sign in page), we don't have a requirement for roles, we probably require some UI screens in the admin area to manage our users. Such as being able to view users, invite users, disable users, etc. Later on this can be expanded to offer audit trials of user actions etc.

But looking for feedback on the requirements for this story.

Have any thoughts about this @nnunn?

[nnunn]

Sorry it's taken me so long to reply!

Roles: A generic Admin role is sufficient.

I would prefer SAML with ualberta login if possible, and yes we would need some UI screens to approve and manage users.

I'm not sure if this is in scope, but there has been some interest in having some areas of the UAL website (specifically staffhub) password protected so that only staff can access them.

[murny]

Thanks for the feedback and requirements.

I'm not sure if this is in scope, but there has been some interest in having some areas of the UAL website (specifically staffhub) password protected so that only staff can access them.

Sounds like password protecting specific pages is more than doable. Sounds like you can put them under a certain path and then have that path requires login: https://github.com/comfy/comfortable-mexican-sofa/wiki/HowTo:-Password-protecting-pages

So could have a path like anything under https://www.library.ualberta.ca/secret/* could require login (have to log into your Admin account, or make this just generic basic Auth or something). Then assign pages under this path to "protect" them. So think this is more than doable and could definitely be in scope.

Roles: A generic Admin role is sufficient.

I would prefer SAML with ualberta login if possible, and yes we would need some UI screens to approve and manage users.

Awesome!

My plan for this since I only have a couple of weeks to work on this (from now until middle of August, I'm planning on fixing up the CSS/JS assets and Webpacker migration work. Then from middle of August until end of August I plan to work on this Authentication project) will be the following:

• Bring in Devise and Omniauth gems and configure them
  • We will add an "Admin" model. This would hold the account info for the admin user. Think this be better then "User" model? As anyone with an account is just an admin? (unless protected pages are viewable by "users" which are not "admins"? or we want users to signup then we "approve" them as admins? If so, then maybe "User" model be better with an admin? boolean)
  • We won't add Ualberta Login via SAML right away. But I'll leave the elevator shaft in place for this to be done. The main reason is it took a long time and lots of back and forth with IST to get this to be added when we did this for Jupiter. So I'd imagine it to be the same thing. But I will add Omniauth and bring in Omniauth-Saml and have this all ready to go. Just someone will have to go talk to IST and share the metadata with them for us to get added. I can document this process though and someone will just need to add this metadata to our app and to a bit of configuration.
  • Add Sign In/Sign out workflow and maybe password reset workflow (which requires emails?) which comes out of the box from Devise
• Create an Admin UI for managing Admins that will be inside the ComfyMexicanSofa Admin dashboard
  • Guide for adding a custom page in ComfyMexicanSofa admin area is here: https://github.com/comfy/comfortable-mexican-sofa/wiki/HowTo:-Reusing-Admin-Area
  • Will need to be able to view Admins, make Admins "Active" or "Disabled", etc.

Then we need to figure out how to provision admins? Initial admins are done inside Rails console? Then after that are they invited by an existing admin (needs email)? Or do they sign up and an admin approves them? Or another way?