Software Security - AAA(Authentication, Authorization, Accountability)

In software security, AAA stands for “authentication, authorization and accounting/Audit.

Authentication => who you are
Authorization => what you are allowed to do
Accounting/Audit => keeping track of what you do.

Authorization rules:
Authorization rules are defined to specify conditions that must be met before access to a protected object is permitted. A rule is created using a number of Boolean conditions that are based on data supplied to the authorization engine within the user credential, from the resource manager application, or from the encompassing business environment. The language of an authorization rule allows customers to work with complex, structured data by examining the values in that data and making informed access decisions. This information can be defined statically within the system or defined during the course of a business process. Rules can also be used to implement extensible, attribute-based, authorization policy by using attributes within the business environment or attributes from trusted external sources.

Authorization Approaches:

There are two basic approaches to authorization:

• Role based : Users are partitioned into application-defined, logical roles. Members of a particular role share the same privileges within the application. Access to operations (typically expressed by method calls) is authorized based on the role-membership of the caller.
  
  Resources are accessed using fixed identities (such as a Web application's or Web service's process identity). The resource managers trust the application to correctly authorize users and they authorize the trusted identity.
  
  
• Resource based : Individual resources are secured using ACLs(Access Controlled Lists). The ACL determines which users are allowed to access the resource and also the types of operation that each user is allowed to perform (read, write, delete and so on).

Role Based:
With a role-based (or operations-based) approach to security, access to operations (not back-end resources) is authorized based on the role membership of the caller. Roles (analyzed and defined at application design time) are used as logical containers that group together users who share the same security privileges (or capabilities) within the application. Users are mapped to roles within the application and role membership is used to control access to specific operations (methods) exposed by the application where within your application this role mapping occurs is a key design criterion; for example:

• On one extreme, role mapping might be performed within a back-end resource manager such as a database. This requires the original caller's security context to flow through your application's tiers to the back-end database.
  
  
• On the other extreme, role mapping might be performed within your front-end Web application. With this approach, downstream resource managers are accessed using fixed identities that each resource manager authorizes and is willing to trust.
  
  
• A third option is to perform role mapping somewhere in between the front-end and back-end tiers; for example, within a middle tier Enterprise Services application.
  
  
• In multi-tiered Web applications, the use of trusted identities to access back-end resource managers provides greater opportunities for application scalability (thanks to connection pooling). Also, the use of trusted identities alleviates the need to flow the original caller's security context at the operating system level, something that can be difficult (if not impossible in certain scenarios) to achieve.

Resource Based:
The resource-based approach to authorization relies on ACLs and the underlying access control mechanics of the operating system. The application impersonates the caller and leaves it to the operating system in conjunction with specific resource managers (the file system, databases, and so on) to perform access checks.
This approach tends to work best for applications that provide access to resources that can be individually secured with ACLs, such as files. An example would be an FTP application or a simple data driven Web application. The approach starts to break down where the requested resource consists of data that needs to be obtained and consolidated from a number of different sources; for example, multiple databases, database tables, external applications or Web services.

The resource-based approach also relies on the original caller's security context flowing through the application to the back-end resource managers. This can require complex configuration and significantly reduces the ability of a multi-tiered application to scale to large numbers of users, because it prevents the efficient use of pooling (for example, database connection pooling) within the application's middle tier.

Rules Engine can make use of Decision tables (or) Decision Trees:

Decision Tables:
Decision tables provide the ability to construct and update conditions and actions for rules as a table. Decision tables can be used to manage hundreds of rules in a compact grid, similar to a spreadsheet. Typical examples of decision tables include actuarial tables and tables used to calculate prices and rates. Decision tables allow users to map policy-governing tables that they use in their business

Decision tree:
Decision tree takes as input an object or situation described by a set of properties, and outputs a yes/no decision. Decision trees therefore represent Boolean functions. Functions with a larger range of outputs can also be represented.

Links:

SAML based Authorization - http://www.aaai.org/AITopics/html/trees.html

http://www.intelligenteai.com/print_article.jhtml?articleID=54200324

http://fuzzy.cs.uni-magdeburg.de/~borgelt/doc/dtree/dtree.html