It’s a question that comes up almost every time we do a trade show, “Do you guys offer RBAC?” Why yes, yes we do. We understand the importance of the need to control who can do what in critical applications, and we do consider Enterprise Alert a critical application in your infrastructure. So Role Based Access Control is most definitely included in Enterprise Alert.

If you landed here, you’re probably already familiar with what role based access control is. And if so, you might want to go ahead and skip to the next paragraph. For the rest of you that clicked your way in, we’ll take a quick look at what RBAC is. Role Based Access Control is just a way to set what users can and cannot do in your system. This is usually done by allowing different types of users, with different types of access, in your system. That way, users can be assigned a role and given certain permissions. So, if you want your users to only see what’s going on and not make any changes, you can assign them an appropriate role that reflects those rights.
Enterprise Alert offers five standard, built-in roles that are pre-configured. But the real strength of the system in Enterprise Alert is being able to build out custom roles. In doing so, you can manipulate and change any of the 70 parameters. But the question then becomes…why?

Well, because not everyone fits into a cookie cutter world and the five roles we offer might not be quite restrictive or quite open enough to meet an admin’s needs.

Let’s take a look at Company XYZ. In XYZ’s IT department, they have things segregated out into R&D, Business Process Improvement, Infrastructure, Software Development, and Information Management. So a fairly robust IT Dept. They have Enterprise Alert (EA) assigned to the Infrastructure team, but it impacts every department, so they all have their fingers in the pot.

Because of this, the EA Admin needs to assign special roles to some of the users. With each section having a Team Leader role assigned, which is more or less an “Admin Lite”, they also want the manager of each department to have their own access rights, but not be quite as powerful as an Admin or Team Leader. So the EA Admin creates a “Manager” role, and names it as such in the system. With this role, they’re able to turn on/off different parameters. For instance, they don’t feel the manager needs to have access to edit Alert policies or deal with Active Directory imports, so these functions are turned off. But, they do want them to have more control over the alerts themselves, especially when they get escalated up. So, the EA Admin turns on the ability to close alerts acknowledged by someone else, as long as it’s in their “team.”

Looking further, the EA Admin creates a role for their everyday users based off of the Standard User role. For this, they call it XYZ IT User. The Standard User profile in EA is fairly restrictive on what can be done, but for XYZ, they feel it can be expanded a bit, giving the users a little a more flexibility to deal with issues when they get them. For this, they open up the ability to forward alerts to other users and teams, as long as the alert was sent to them (ie, their own alert). They also have “raise alerts to other users and teams” turned on for them so that they can send out alerts as needed within the system.

That’s just a quick look at some of the possibilities for Role Based Access Control in Enterprise Alert. Below, you’ll see the different parameters we allow to be manipulated to fit your needs. What you’ll see is that there’s a lot of flexibility to define exactly what your users can and cannot do.

If you’d like to learn more about how Enterprise Alert can meet your IT Alerting needs, visit us and reach out to our sales team for a demo.