AngularJS SPA Controller Claims Authorization

Overview

In a previous article, we discussed the use of directives to enable claims based authorization on the user interface elements. For some scenarios, we notice that a directive can have performance issues as it is called everytime is declared on the mark-up. For the cases where there is an ngRepeat, this can lead to many calls depending on the size of the collection.

Read Directive Claims Authorization

CodeProject

With the auth directive implementation, we notice on the browser console the number of times the directive is called.  This lead us to explore other options with better performance, and that also can provide the same results. With that in mind, we now take a look a providing claims authorization with controller only implementation.

Security Service

This service has a simple implementation in which it checks if a particular claim already exists for the current user by managing the claims information as a property. This service is injected into the controller with the purpose to manage the validation of the claims for the user. The controller sets scope variables which can then be used on the view to enable some of the user interface behavior like hiding elements for which the user has no permissions.

Controller Implementation

If we look at the mark-up for the delete and edit buttons, we notice that we could manage the visibility of those controls by using the ngShow native directive. In addition, we need to have some controller variables which can be watched by Angular to enable the behavior. We can now take a look at the implementation details with the following JSFiddle.

On the JavaScript tab, we can see our controller implementation.  We are creating a controller variable for each of the claims that we need to validate (claimMapping). To figure out the if the claim is available, we pass the claims tags to the $svcAuth service which verifies if the claims  exists by calling hasClaim.  

The state of each variable is set by calling claimResuts. If the claim exists for the user context, the associated element is displayed. Otherwise, the element is not shown. We also need to track any changes on the claims, so we need to add a $scope.watch to evaluate the existent of our claims as we remove or edit them. Note that this watch is only added here to demo the behavior of editing the claims. On a live system, this would usually happen only when the user logs out as this resets his security context.

On the HTML tab, we only need to add the ngShow directive with the corresponding controller variable. For the the delete button, we use the ctrl.deleteAccess variable. For the edit button, we set the directive to the ctrl.editAccess variable.

Does It Work?

To check that this is working properly we can run a simple test. Run JSFiddle and delete both app.edit and app.delete claims. These should essentially remove all the icons on our list as shown below:

Areas of Improvements

This implementation was a lot simpler than having to use a directive, but it also has a big flaw. We can imagine an app with several controllers, and we need to do implement the claim validation logic in many of them. For those cases, we definitely would like to use some reusable component instead of adding the same code on the controller.  When the view has multiple elements like menus  and each menu has an independent claim/permission, we probably want to use the auth directive. For cases, when multiple elements are controlled by the same claim, we may just want to use the auth isolate directive.

Read Isolate Directive Claims Authorization

Originally published by ozkary.com

Overview In a previous article, we discussed the use of directives to enable claims based authorization on the user interface elements. For ...

Read Article →

AngularJS SPA Isolate Scope Directive Claims Authorization

Overview

In a previous article, we discussed the use of directives to enable claims based authorization on some the user interface elements. For some scenarios, a directive is the ideal approach, but because of the fact that a directive is called every time is declared on the mark-up, it is not ideal for cases where an item lists can have many items, and we just need to validate one or two claims.

Read Directive Claims Authorization

CodeProject

Directive Implementation

When looking at our previous implementation, we can see on the console windows the number of times that the directive is called. We want to optimize the approach by just calling the directive one time and validate the claims for the user.  A way to do this on AngularJS is by using an Isolate Scope Directive.  This means that the directive does not share the same scope as the controller, but it also provides the advantages that we can pass object references and functions which can be used to indicate what claims need to be validated all at once thus eliminating the additional calls.

New Approach Isolate Scope

Now that we understand our optimization approach, we can refactor our code by first removing the authorize directive from the button markup which is what causes the multiple directive calls. We can now define our new directive with isolate scope and restrict it to “E” which means that it can be used as an element only. The idea here is that we want to declare it only one time on the mark-up outside the ngRepeat scope.  

We also want to add two attributes to our element. These attributes are assigned to functions within the controller. We should notice that in order to pass evaluating expressions to our directive, the attributes need to be declare with “&”.

scope: {                   authorizeMapping: '&',                   authorizeCallback: '&',                          },//isolate scope

The function assign to the authorize-mapping attribute returns a JSON with all the claims that need to be validated on behalf of that controller. The function assign to the authorize-callback attribute is called by the directive to return the status of each claim (true when found). Let’s take a look at our new implementation:

Controller Kicks In

Once the controller has received the status of each claim, we can leverage the power of AngularJS by mapping claims to controller variables. At this point, we just need to add an ng-show directive and assign a controller variable to evaluate if the user is authorized to see that element. Yes, we are still using a directive for each element, but that is just evaluating a true or false expression, and it is not calling the authorization service to validate the claim.

We can now compare the console output with the isolate scope, and we should see that we no longer have multiple calls to our directive. The result should be just one entry.

Does It Work?

To check that this is working properly we can run a simple test. Run JSFiddle and set the app.edit claim value to an empty string or just click the delete icon. This should remove the permission on the rest of the list items as shown below.

Areas of Improvement

As usual, we should ask ourselves if there ways of improving this approach. Since we can now notice that this solution uses controller variables, do we really need a directive? If the concern is reusability, the directive approach is preferred over a controller only implementation as this can create code duplication. To show this, we can review the controller only solution on another article.

Read Controller Claims Authorization

Originally published by ozkary.com

Overview In a previous article, we discussed the use of directives to enable claims based authorization on some the user interface elements....

Read Article →

AngularJS SPA Directive Claims Authorization

CodeProject

Overview

When we talk about authorization of the elements on a web application, we make reference to the ability to hide or show some areas of the application based on the permissions that are granted to the logged on user.  These permissions are usually delivered to the application via claims on a security token like a JSON Web Token (JWT).

Security Service

For now, we assume that the claims have been populated in our security service. This service has a simple implementation in which it checks if a particular claim already exists for the current user by managing the claims information as a property. The purpose for this service is to be used by all controllers, directives and other services that require authorization services.

Specifications

We want to be able to create a simple user interface that contains a list of items with two action item buttons.  The delete button allows us to remove the item from the list. The edit button is used to edit the item information.   In order to understand what claim controls the access to what element, we must have some information that indicates what needs to be done.  The table below provides the information that we need. If the user has the respective claim, we display the element. Otherwise, we remove it from the DOM.

Element	Claim	Action
Delete Button	app.delete	Display the element
Edit button	app.edit	Display the element

Implementation

Now that we understand what claim and elements we need to look for, we can take a look at our app.  The image below shows a simple list with items. Each item has a delete and edit button. This maps well with what has was been defined on our specifications.

When using AngularJS, the recommended approach to change element behavior is by using directives.  With that in mind, we can implement an Authorize directive which takes a tag value. This tag is the actual claim value that can be used by the directive and the authorization service to verify that the user has the required claim.  Let’s take a look at our implementation next:

On the HTML tab, we have added the authorize directive with the respective claim tag for each of the call to action buttons (delete, edit). On the JavaScript tab, we can see our directive implementation (dirAuth) .  We read the claim tag from the element attributes and pass it as an argument to the auth service ($svcAuth).  If the claim is found on the claims collection, the result is set to true, and we show the element. Otherwise, we hide it.

Does It Work?

To check that this is working properly we can run a simple test. Run the JSFiddle and click on the delete icon for either the delete or  edit claim. We should see how all the icons for the remaining rows are no longer available. In the image below, the app.delete claim was removed. We could also just empty the claim value as this would evaluate as false and would remove the permission on the control.

Areas of Improvements

That was fairly easy to secure, but there is something there that bothers me a bit.  If we take a closer look, we can see that this list has multiple items, and each item has a delete and edit call to action buttons. As we can image, the directive will be called each time it is declared in the mark-up. In this example, there are five items with two buttons. This means that our directive will be called 5X2 times (n x 2 for any list).  We can see this by adding a trace call on the code and looking at the console window:

As suspected, our directive is called too many times, but we just need to check for two claim values. Clearly for this scenario, we need a better approach. We can address this concern by using a directive with isolate scope, but we can leave that for another article.

Read AngularJS SPA Isolate Scope Directive Claims Authorization

Originally published by ozkary.com

CodeProject Overview When we talk about authorization of the elements on a web application, we make reference to the ability to hide or sho...

Read Article →