The authorization framework provides a generic mechanism to authorize each user’s request to complete an operation. It could be a Database Write, Read or Delete. From a more generic view there exist the following entities
1. Principal: – Any actor or role who initiates or request for an operation or Service.
2. Resource: – A resource is something which stores the business data. It could be a database table, XML file, Flat file etc.. The Principal can access the Resources through any Services and change the data using operations.
3. Service and Operation: A service could be a set of operations performed against a set of business entities which causes a change in their internal state.
4. Access Rights: Access rights are security mechanisms which can prevent or allow any Principal to call a Service or do any operations on a Resource.
All the above entities could vary from a business to business. Hence they have been generalized in the framework. The specialization of the entities could be done in the Framework extensions. For instance when it comes to the Data Repository project, the Principal could be an Organization’s Windows Principal Object. A Windows Principal represents the user who belongs to an AD group in the Organization domain.
The framework also has some extension points or hooks which can be extended by the client.
1. Rules Reader: The rules reader constructs the rules entity by reading from any persistent data storages like DB tables, XML files etc. The Authorization engine accepts a Rules object for the authorization strategy.
The framework has some frozen spots like the Rules Configuration, Authorization Strategy and the Authorization Context as an Authorization engine.
2. Rules Configurations: The access rights for each role have to be configured in a permanent storage. The storage could an XML file or could be a data base table. A rules configuration screen would be developed for the admin user to configure the rules. The sample screenshot for the screen is provided in the Appendix 8.2 of this document.
3. Rule Entity: The rule entity would be constructed by the Rules Reader and would be cached in entity.
4. Authorization Context: The authorization context should hold the 3 business entities Principal, Resource and Service/Operation. The authorization context would be sent to the authorization engine. The authorization engine parses the necessary information from the entities and implements a strategy to read the Access Rights for the context from the Rules Entity.
5. Authorization Strategy: The authorization strategy expects an Authorization context and a Rule entity to process the request and returns a Boolean flag true if the Principal is authorized to do the operation. The frozen strategy uses SQL server tables to configure the Rules, Principals and Access Rights. The schema details are provided further this document.
//Call the Business Layer
BLLookUpCodes objLookUpCodes = new BLLookUpCodes();
/// Summary description for BLLookupCodes
public class BLLookupCodes
// TODO: Add constructor logic here
/// Calls the DAL to save the changes
public void Update(LookupCodeDataSet dataset)
//Create the authentication context
AuthenticationContext objContext = new AuthenticationContext();
//Set the Principal
objContext.Principal = HttpContext.Current.User.Identity.Name;
//Set the Table name
objContext.Resource = “InfLookupCodes”;
//Set the Operation name
objContext.Operation = “Update”;
//Build the Authorization Strategy
IAuthorizationStrategy objAuthStrategy= new OrganizationAuthorizationStategy();
//Authorize the user's role before calling the Data Access layer
//If Authorized call DAL
DALLooupCodes objDALLookupCodes = new DALLookUpCodes()
Configuration Schema details