EqualifyEverything / equalify

A web accessibility platform, managing issues by integrating with A11Y services.
https://equalify.app
Other
118 stars 21 forks source link

Multiple users account #86

Closed kgrimley-bu closed 1 year ago

kgrimley-bu commented 2 years ago

It would be beneficial for multiple users from the same institution to access the same account with their own creds. This was we would be able to look at the same dashboard, pass issues as needed, and so on.

kreynen commented 2 years ago

https://service.equalify.app/ already has some level of authentication running at https://service.equalify.app/_private/index.php

Most large, higher ed implementations are going to require SSO. For CU, it's SAML via Ping. We leverage simpleSAMLphp in the Drupal CMS. I know a number of schools use https://www.apereo.org/projects/cas. Finding a way to support SSO without overly complicating the Equalify codebase would be an ideal solution, but if the goal is to manager users/groups/roles access to sites and reports in Equalify UI this could get complicated.

The way CiviCRM handles this was to always require a "host" CMS. While roles and permission a user had was managed in CiviCRM while how the user authenticated was managed by Drupal, WP or Joomla.

If the desire is to allow Equalify to be run as a standalone service with no authentication (or authentication at the network/server/container level) we are potentially talking about supporting 3 or 4 different authentication configurations.

  1. Standalone - This is the current configuration OotB. All users with access to the instance have access to all functions, sites and reports.
  2. Local user management - This is where users and roles are created within each instance. My Equalify username/password would be unique to that service. I think some version of this already exists for the equalify.app service.
  3. SSO - This is where authentication is managed somewhere else, but roles are still managed within the instance. The external authenticated could be Google or GitHub, but in most higher education implementations they will already have a Identity Management or Identity and Access Management group with a service they require solutions support.
  4. SSO + Group Management - This would be the most complicated configuration where the service not only uses an external service for authentication, but it also gets group/role membership from a service like Grouper or even Active Directory.

In our use case, the MVP version of this feature would just be SSO for authentication. Most of our services still require logging into the service to add users to roles.

There are a few different PHP solutions that could be leveraged as an integration instead of building a custom account/role management in Equalify.

https://www.userfrosting.com / https://github.com/userfrosting/UserFrosting - MIT Licensed, requires Symfony 5.1 (or ^?). There was an attempt to add simpleSAMLphp support, but the issue was never resolved and has gone stale. This is a full blown solution with a UI, but it is also still using JQuery.

https://packagist.org/packages/friendsofsymfony/user-bundle / https://github.com/FriendsOfSymfony/FOSUserBundle - MIT Licensed, requires Symfony 2.8+.

https://github.com/auraphp/Aura.Auth is a smaller package that offers suggestions for LDAP, but doesn't support SAML.

I'm sure there are other solutions out there as well, but doing this right/well is going to be important to being able to manage a large number of sites and users in a single instance.

bbertucc commented 2 years ago

@kgrimley-bu - What would SSO users be doing? Any imagined use cases? We would want the auth system to anticipate real-world use cases. If users just needed to access reports, we might not even need any auth. All the info that Equalify currently displays is public information (you can use any WCAG scan to get the info). As soon as we host proprietary info or any WRITE controls, we need to think about auth.

Related to @kgrimley-bu's issue, a few users are getting around the lack of multiple accounts by using a shared email address as their account name. That's not ideal, but it works for now.

kgrimley-bu commented 2 years ago

I don't think SSO is as important to us as it maybe to other institutions. We use Auth0 as our SSO solution. I honestly don't know much about the setup/config as others handle that.

While we use it on most of our self hosted applications it's not a requirement and a decent number of our internal dept. applications just use local accounts. I should mention that we have a centralized IT dept for a single campus university, so probably a 180 from @kreynen's use case.

For our third party/vendor supplied services there's also no requirement for SSO. We use it if they offer it, think Google, Adobe, MS and the like.

So, if we're talking about app.equalify what we're really interested in is just a single account that allows multiple users access. Each with their own username/password. Yes, a SSO solution would be excellent but not a must have for us.

As far as the self hosted version. We wouldn't put that behind any type of authentication.

bbertucc commented 1 year ago

A driving feature of the Equalify architecture is that the open-source version won't have an accounts area. However, this feature will be incorporated into our managed version: https://equalify.app