Scope Users to Particular Listeners
- What is the problem that this feature would fix?
At the moment, each listener uses the same user database to allow sign ins. This means that no matter the listener the user accesses, they will be allowed to sign in. There are some restrictions that you can put in place on what protocol they can sign in with, but no granularity on, say, two different HTTPS listeners.
- Why is it a problem?
This comes to be an issue when you want to separate two listeners completely due to different firewall restrictions, or even if the files for the listeners had legal restrictions that require different handling.
For example, having two listeners up, supersecure.company.com and public.company.com would allow users to sign into both of the portals without issue. If, say, CEO of the company was supposed to only sign into and upload documents via supersecure.company.com, they would be able to bypass any firewall restrictions put in place on supersecure.company.com and upload files via public.company.com
- Is there a workaround you currently have for this problem?
No. Our organization was given this requirement and I will be setting up a different FTP solution on a separate server to handle the separate listener to ensure the security.
This is a functionality that, if present, would allow cerberus to be more heavily used in our organization. I am quite happy with 95% of what the product has to offer and would like to see it grow, but this restriction basically causes us to have multiple ftp instances if we ever want to split our users for any reason.
- Do you have a suggestion on how you would like to see the problem fixed?
Adding an "allowed listeners" option to each user would be fantastic. It could either show an error message when trying to log in on a unsanctioned listener, or maybe even forward them to the right one.
If a larger user account change wouldn't be in the cards, allowing this to be set up via Events would work as well. For example: on log in event, if user group is X and listener IP is Y, block login. if you'd be able to pull secondary groups as well in the filter (instead of just primary) this would be awesome.
- How big is the problem? Who is affected by this problem (End Users, Admins, etc.)?
This is mostly an Admin/Security/Operations issue.
-
Hello Nick,
Thanks so much for submitting this request. I will get it sent over to the Product and Dev team for their review. If we end up needing more information on this, I will be sure to reach out here, or through a ticket.
1 -
Hello Nick,
I did just want to drop you a quick note, that this was accepted for future consideration. This means while we may not be adding it to the current release scope, it will be retained for a future release. If you have any questions around this, do let us know.
0
Please sign in to leave a comment.
Comments
2 comments