Policy based security in Flex – part II
10.07.08Filed Under: Flex
Since writing my first article about Implementing Policy Based Security In Action Script 3 I have had the opportunity to create a live demo with source code available for viewing/downloading. This is to give you a better notion of how implementing policy based security for user interface components can make sense. No more of those monster data binding expressions which determine whether a user has access or not.
Having this kind of logic seperated into Simple ActionScript Objects, SASO’s, (I’m sorry I could not resist to reuse the POJO catch phrase) which are simple to both understand and unit test. Unit testing and indeed understanding complex binding expressions or functions inline in MXML-code is hard when your application grows. Therefor making this kind of separation makes perfect sense.
In my previous posting I outlined how you could have stand alone classes for handling security. However the posting did not include a running sample as to how you would best implement the principles outlined. This posting comes with a more detailed description and a running sample with source code.
The Design
The implementation of the policy based security consists of three interfaces and an implementation class. Security policies are created in stand alone classes which are easily unit tested and gives you better control of what policies applies to performing certain operations in your applications.
The Policy interface has one method apply, which takes a criteria as parameter. Classes implementing this interface can be set on a class implementing the PolicyHandler interface. In the policy handler class all the “magic” happens. Based on the composed criteria, policies and targets.
Ease of use is important when writing library style components and the policy handler is design with this in mind. All you need to do in your application is to instanciate a policy handler class and then configure it with the required properties. Thanks to Flex’s data binding features the policies get applied whenever the criteria changes.
Using the policy handler
The implementation class, PolicyHanlderImpl of the PolicyHandler interface does all the heavy lifting and all you need to do is to pass it a callback function which gets called with the result of all the applied policies. In your callback method you can do make components appear/dissapear or enable/disable depending on the policy result.
public function applyToTargets(policyApplies:Boolean):void {
componentA.visible = componentA.includeInLayout = b;
}
...
<policyHandlers:PolicyHandlerImpl id="handler"
policies="{[AdminWidgetAccessPolicy]}"
criteria="{currentUser}"
callback="{applyToTargets}"
/>
The Sample
In order to make it a bit easier to review this way of securing access to parts of your application I have created a really horrible looking sample (can’t have a security sample which looks nice, that just does not seem secure enough) which shows the design in practice.
Pressing the button in the sample makes you change the current user between user A and user B. The policy in the sample ensures that only users with the role administrator sees the admin widgets. When looking at the source code, do not pay much attention to the lack of comments and nice coding. This is a quick and dirty sample code, not a best practice type sample.
In order to view this sample you must install the Adobe Flash Player.
View the sample in new window
View the source code
I appreciate all questions/comments, whether you think this is terrible or brilliant, just leave them over on the right.
UPDATE: Last night I detected an obvious flaw in my design, originally I had an abstract class which you had to extend in order to implement a new policy handler. In order to make using this design even easier I decided to have the PolicyHandler/ have a new method for setting a callback function which gets called after application of all the policies.
2 Responses to “Policy based security in Flex – part II”
Leave a Reply
Subscribe to comments feed (this is global, not just for this entry)
I haven’t searched through the code yet but I’m about to. In the mean time a quick question. Would this handle multiple roles? That is an array of roles. I’m guessing it would be a simple matter to adjust. I found this really helpful. Thanks.
March 1st, 2010 at 11:45 pmIt would handle multiple roles, it all depends on the Policy you implement and what criteria you want to be valid input. This solution is pretty generic and some people think it’s a bit too generic. I am currently working on a project where our design will be slightly different, but I’ll post an update here about it when it’s completed.
March 2nd, 2010 at 9:19 pm