Solution Pattern

Security Policy

Facilitates the assigment and encorcement of security costraints to sensitive system resources, such as data and components, by providing a mapping between the resource and its access role.

[image]

Background

We have a resource to protect and a Role (page #) to protect it with. How do we associate the resource with its assigned role to ensure that only those authorized to access it may do so?

Value and Benefits

The Security Policy acts as a mapping between the protector and the protected. This mapping means that the piece parts of access management are decoupled. Therefore, the parts can be changed independently. This pattern is chiefly concerned with structure, while it does provide a fare share of behavior as well.

A Security Policy promotes maintainability, because it decouples the protected resources from the security constraints that authorize their access. Additionally, versatility is baked in. The decoupling implies that some system resources may be protected (policy exists) and others may not be (policy does not exist), at the discrimination of security administrators. Thus, if a resource is included in a Security Policy mapping, its access will be checked. If it is not included in any such mapping then access is not checked. Further, new components and potentially new kinds of constraints may be added to a working system without requiring either implement security directly.

Putting It to Work

All basic Security Policy instances in a system may be maintained in a dictionary or map object, which may serve as the underlying design pattern. A single Security Policy, therefore, may be as simply as a key and a value pair. The key is the name or other unique identifier of the resource. The value is the name of the Role (page #) that secures the resource by regulating its access to only those who qualify.

How can a resource such as a data object (e.g. a data source), or an executable component be uniquely identified? The following table provides some guidance for standard Web-based enterprise applications:

[table]

Enterprise platforms, such as J2EE and .NET, have standards for uniquely identifying each type of resource.

A security policy may be defined in any text file that can be used to express key-value pairs. A properties file may do, or an XML document. J2EE defines policies in XML documents that are deployed along with the component they apply to. Most J2EE application servers allow you to provide Security Policy definitions for data resources from within a custom management console. The .NET solution, provided by the Microsoft Access Manager product, uses Active Directory LDAP entries or XML document-based flat files to store policy definitions.

A Security Policy actually has two object representations. There is the composite representation illustrated in this pattern’s introduction. There is also the map or dictionary representation that allows quick and convenient lookup. The backing Map (or Dictionary) uses the resource identifier as the key, and the role name as the value.

[image]

Access to a non-Web identifier is straightforward:

[code]

One approach to dealing with Web policies is to insert a single entry in the SecurityPolicyMap for all URL resource identifiers. The key might be / or www. The value, in this case, is not a role, but an object that facilitates a hierarchy of directory names and contained filenames. Associated with each directory name are links to lower-level directories, contained filenames (which may include wildcards), and a role, if one is mapped to the directory. Filename entries will have associated roles. The class SecurityPolicies parses the requested URL to separate each directory and possible filename, and walk the links until there are no more URL segments. If a match is found, the associated role name is used to find the role and return it to the consumer:

accounting

*.jsp = Accountant (role)

controller

accounting = Accountant (role)

AccountingDataSource = Accountant (role)

BalanceSheet = Accountant (role)

GeneralLedger = Accountant (role)

The first entry is the Web site directory hierarchy. The second entry is a data resource, the AccountingDataSource. The third and forth entries are the BalanceSheet and GeneralLedger components, respectively. Each entry, including Web sub-entries, which have a role associate with them, may resolve as a valid Security Policy entry. Entries not having role associations are not valid Web Security Policy entries.

To help the SecurityPolicies deal with Web requests more efficiently it is best to provide a different method for requesting roles:

[code]

The method getWebResourceRole() distinguishes Web resource requests from those involving data and non-Web component resources.

Examples

The J2EE platform uses XML documents to define security policies. Web site security policies in particular are defined in the web.xml file that is part of a Web Archive, or WAR file. The following web.xml security constraint defines the Web sub-entries as shown in the above SecurityPolicies map layout:

[code]

As you can see, Security Policy may, of necessity, be more complex then a set of key-value pairs. In the above J2EE web.xml example the policy itself has a unique name, which is AccountingAppSecurity. The policy packet is named security-constraint. Within this single web-resource-collection you may declare multiple URLs or URL patterns in a single policy. What is more, you may distinguish between Web request types: GET and POST. In the case of the above policy both GET and POST are covered by the same access constraints. But in other cases you may want to allow everyone to read (GET), but only allow special roles to write/update (POST), for example. In the case of the above policy, any user that is in the Accountant role may perform both Web request types on all URLs that have the patterns accounting/*.jsp and controller/accounting.

While the J2EE Web implementation of Security Policy is more complex, the principles of the basic approach to the pattern apply. Admittedly the policy for an Enterprise JavaBean (EJB) is much simpler than the Web edition, because the EJB is accessed using an exact unique identifier. Even if the implementation you develop or otherwise obtain and use is of necessity a bit more complex, the basic name-value pair mappings comprise the essence of the pattern—a uniquely referenced resource is secured by a specific Role (page #) definition.

Consequences

Consider the completing forces related to this pattern:

Not Used: If you don’t use Security Policy the Access Authorization (page #) pattern will have to use another means of looking up the security permissions that must be enforced to access the resource. This will likely be cumbersome.

Related Patterns

The following patterns are closely related to the Security Policy pattern.

Access Authorization (page #): Uses Security Policy to check the access constraints of the system resource that the requester is attempting to access.
Role (page #): Defines the access constraints mapped by the Security Policy.

Frameworks and Tools

J2EE: See the J2EE specification, in particular the web.xml and ejb-jar.xml document types, for examples of this pattern.
Microsoft Access Manager: This Microsoft product provides an implementation of Security Policy.

[EOF]