in JavaScript, Uncategorized

Simple permission handling in AngularJS

Despite of a simple authentication, a lot of applications have a concept of authorisation. An user is not only logged-in, but has a set of roles which allow him to perform certain actions or see certain views. For example an user with the role ADMIN will probably be able to do more things as an user with the role CUSTOMER.

How can we support this in AngularJS?

Get the user

Before we can deal with any kind of user permissions, we first must have access to the login context of the user. We can do so, by implementing a backend REST-controller which returns the current user. This user object holds a list of permissions (or roles, privileges or what ever you call them).

We can wrap this backend controller in an AngularJS service:

Now we have access to the current user and access its roles.

Check the permissions

With the user in our hands we can check its permissions. We can compare the permissions which the user actually has against a list of permissions which are needed to execute or view a certain thing.

Protecting components

The last step is to actually protect components of our AngularJS application. There are a lot of different approaches in doing that, for example by routing configurations. However, I want to demonstrate a more simple solution which can not only be used for routes, but for any AngularJS component.

The idea is to implement a directive which is configured with a list of permissions. If the user has none of these permissions the directive will hide the element which it annotates. The element will only be visible of the user has a least one of the given permissions.

By putting this directive to an arbitrary HTML element, the element will only be visible if the user has the given permissions:

In the example above, the Home view can be seen by everyone. It’s not protected. The Admin Panel on the other hand can only be seen by an user with the permission VIEW_ADMIN_PANEL. Last but not least, the Payment Panel is available for any user which either has the permission VIEW_ADMIN_PANEL or VIEW_PAYMENT_DATA.

Pros and Cons

The solution is very simple and requires no additional framework or library. The protection can be applied to any HTML element, which makes it very flexibel. A downside is that the permission handling might be scattered around the whole frontend. It will not be in a single place as it would be with an approach based on routing.

Is it secure?

Of course not! Any security pattern applied to the UI will be unsecure. The UI runs on the client side and the user is able to modify all of its code. No matter which pattern we use, the user can easily get around it. In the end, any REST call can be send to the backend directly without even using the UI.

This being said, it’s very important to protect and secure the backend in the first place. The backend must apply and enforce the permissions. The frontend is just an unsecure client which nobody can trust. It’s only concern is to offer a good experience to the user.

Best regards,

Write a Comment