The Enterprise Library’s security block is very handy, and pretty easy to use, but the one complaint I see about it most often is that people don’t want all of their security rules living in the app.config file usually due to security concerns.  This can be easily solved by encrypting the config, but this will only really keep out casual hackers.  You could also implement the SqlConfigurationSource which is provided as a sample with the EL source, and store the EL configuration in the database, but by default, the EL is going to want to store ALL of its settings in the database, not just the ones you wanted to hide.

Initially, the client I’m working for just wanted a simple interface to map primitive rights to roles via a CheckBoxList or something.  When I explained that I could get more flexibility in less time by using the EL security block, the choice was clear, and I got the go-ahead to investigate whether I could make it work or not.  The difficulty here was that while security rules aren’t normally subject to much change after deployment, in this case there was an actual requirement to edit the rules from within the application itself.  We did not want to use the app config, and the SqlConfigurationSource route would have required us to use the EL’s configuration tool in order to maintain the rules in the database.

Unlike my previous experience with trying to bend the EL to my will, the security block is actually much easier to use in non-standard ways.  Instantiating the AuthorizationRuleProvider class requires you to pass in an IDictionary containing the rules that the instance will enforce.  This means I could load and save my rules from wherever I want.  In this case we’ve used a Linq entity class called SecurityRule, and a static class called AuthorizationManager.  The constructor for AuthorizationManager loads the rules, adds them to a dictionary, and then instantiates the AuthorizationRuleProvider class as follows:

        private static Dictionary<string, IAuthorizationRule> _securityRules = new Dictionary<string, IAuthorizationRule>();

        static AuthorizationManager()
        {
            // Get the security rules from the database
            SecurityRuleLogic logic = new SecurityRuleLogic();
            foreach(SecurityRule rule in logic.GetActive())
            {
                _securityRules.Add(rule.Name, new AuthorizationRuleData(rule.Name, rule.Expression));
            }

            _ruleProvider = new AuthorizationRuleProvider(_securityRules);
        }

After this, it’s just a matter of asking the AuthorizationManager whether a user is or isn’t allowed to perform a certain action by calling the AuthorizeCurrentPrincipal method:

        public static bool AuthorizeCurrentPrincipal(string ruleName)
        {
            if (_securityRules.ContainsKey(ruleName))
            {
                IPrincipal principal = Thread.CurrentPrincipal;
                return _ruleProvider.Authorize(principal, ruleName);
            }
            else
            {
                return false;
            }
        }

Simple, right?  In the real world it might be a little more complex.  I’ve omitted things like caching of the current principal, etc.  The point is that all the EL blocks should be this flexible.  The designers have hit the 90% that most people are going to need, but there’s always that 10% case where you have to do something weird.  This time I was lucky.