You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Maintaining secure access around client sites is extremely important. What I'm proposing is a means of standardizing, centralizing, and automating the majority of this effort.
What I'm thinking is to implement something similar to how WordPress VIP's Support Users are implemented, but instead of providing individual users with access, we would use a secondary website to create an oauth sign in to an Alley user on the client site.
The secondary website would contain a list of all Alley employees, and they would be able to be granted access to specific clients. We would likely want to maintain the ability to disable access to specific clients, but could begin by granting access to all clients.
This way, when an employee exits the company, their access would automatically be removed from the client sites.
What about password logins?
To secure the Alley user from password based logins we could either disable password logins for that user, or setup a cron to automatically rotate that account's password once per hour.
What about creating secondary accounts?
This is already a concern. Admittedly this change isn't a fix for this, but it also doesn't grant anyone any additional ability to perform this action than they already have. A follow up feature could be added to log actions by individuals, which would make this more secure.
Use Case
When a user leaves the company their access to client sites should be automatically removed so we can remove the risk of human error from this process.
The text was updated successfully, but these errors were encountered:
Description
Maintaining secure access around client sites is extremely important. What I'm proposing is a means of standardizing, centralizing, and automating the majority of this effort.
What I'm thinking is to implement something similar to how WordPress VIP's Support Users are implemented, but instead of providing individual users with access, we would use a secondary website to create an oauth sign in to an Alley user on the client site.
The secondary website would contain a list of all Alley employees, and they would be able to be granted access to specific clients. We would likely want to maintain the ability to disable access to specific clients, but could begin by granting access to all clients.
This way, when an employee exits the company, their access would automatically be removed from the client sites.
What about password logins?
To secure the Alley user from password based logins we could either disable password logins for that user, or setup a cron to automatically rotate that account's password once per hour.
What about creating secondary accounts?
This is already a concern. Admittedly this change isn't a fix for this, but it also doesn't grant anyone any additional ability to perform this action than they already have. A follow up feature could be added to log actions by individuals, which would make this more secure.
Use Case
When a user leaves the company their access to client sites should be automatically removed so we can remove the risk of human error from this process.
The text was updated successfully, but these errors were encountered: