Chapter 2. Architecture patterns for externalizing security from
2.4 Application level approach
There will be scenarios where the previous approaches may not prove sufficient, either because of specialized application needs or specific authorization
requirements. In some cases, the organization's needs might not align with container based approaches, even if they are supported for their application platform. The business will still need to influence the behavior of applications through external policies, and explicitly leverage an IT security policy
management system. This approach is called the
application level approach
. IT security policy management and decision making is still being externalized, so all the advantages of centralization still apply. The only functions that need to be implemented beyond policy enforcement are the creation of the policy decision request, the invocation of the decision point interface, and acting accordingly on the returned decision.As mentioned before, none of the patterns are meant to be exclusive; they can be combined with each other for specific situations and business needs. In our current discussion, the application level approach in particular is most likely to be combined with other approaches, such as the intermediary or container level externalization pattern.
Let us review the application integration approach through the following services organization example.
2.4.1 Customer example
A highly specialized IT services organization provides premium services to tax counselor firms that are generally small or medium sized. Tax laws are complex in most countries and undergo frequent changes, so the supporting software is equally complex; it must not produce false results (because this would break the law), which means it has to be thoroughly tested to the extreme, and
modifications due to legislation changes have to be in place precisely on the effective date. The target market for these types of services consists of a limited number of tax counselors. Their most important asset by far is the quality of their software based service, that is, the quality of the software itself.
Let us take a look at some of the security implications in this industry:
Counselors’ offices are likely to have several employees. These employees have individually assigned customers and they must not have access to other customers’ sensitive tax data. So the IT services provided require a two stage authentication process, one level for the counselor’s organization as a whole, and one for the individual employee with his dedicated customers.
Entitlement policies must take the authentication level into consideration. The counselors’ employees are working with the firm’s local IT environment,
so they need to log in locally first. Identity federation is a user-friendly and secure integration approach with the premium service provider. IT security policy management should integrate with federated identities.
As stated above, tax data is extremely sensitive and requires thorough protection at all stages based on the context of the request.
Auditing takes an important role not only to prove compliance of the provided applications and services with legal obligations, but can also serve as a monitoring tool for attempted attacks, especially insider attacks and privileged user attacks. Trustworthiness is essential in this industry. A single breach can destroy the services organization’s reputation beyond repair.
Tax regulations change frequently over time. Tax data sometimes needs to be processed some time after the fact, possibly even years later. In such a case, the respective laws and regulations that date back to that point in time must be applied. The respective versions of the software and possibly respective versions of the corresponding IT security policy must be applied. An adequate version control regime for IT security policy must be in place to support this situation.
High availability is often a requirement driven by business needs. Tax
obligations generally have a deadline attached, which, if not met, has serious implications, such as fines and hefty interest being added to the amount due. Therefore, the premium services must not fail, as covered by a service level agreement. IT security policy management, being an essential component of the solution, needs to provide that same service level.
2.4.2 Integrating policy at the application level
We now take a look at the steps required to establish the application level security policy enforcement approach. More than in the other patterns, this pattern should be used as an example only, because this pattern is not as standardized as the other patterns described previously.
Application resource discovery
With a custom-written application, it is less likely that the relevant resources can be captured by a standardized method, so there is a need for a custom made provider of resource metadata. Ideally, this provider would be integrated with the software development environment of choice to extract the resources directly from the source code. We already observed, with the container level pattern, that it is desirable for the IT security policy management to have an intermediate descriptive format. This situation equally applies here, especially when the two patterns are combined in a solution.
Application security policy modeling and authoring
If the application design and development takes place at the same time as the creation of the related IT security policies, both could be undertaken in a synchronized fashion and benefit from each other. High level application design could then be accompanied by policy modeling, which may include simulation of policies as a way of early testing at a high level. This situation might reduce the cost of application development substantially, because errors cost less the earlier they are detected during the development cycle.
In a similar way, policy authoring could be done during the software coding and testing phase, and again both activities would benefit from each other.
Policy configuration and distribution
A strict separation between policy decision making and policy enforcement characterizes the application level integration pattern. We have seen that new applications in particular benefit from this approach. Conversely, there may be some extra migration effort required for existing applications. There are situations where a nonstandard user repository with nonstandard interfaces is being used for complex granular authorization. Integrating such technologies with a new, standards-based IT security policy management solution can be achieved by using custom policy information points. Standards such as XACML provide enough flexibility to map to existing complex policies.
Policy enforcement
From the sample scenario that we have discussed so far, it can be assumed that there will be intermediaries playing a role in the connection between the service provider organization and the counselors’ offices. A centralized overall IT security policy management solution can benefit from this architecture by using an optimized placement of the respective enforcement functions. For example, message security is often best placed at the intermediary, both from an architectural and a performance perspective; the same may apply to coarse-grained access control. Fine-grained authorization and entitlements, however, typically make more sense in the application context.
Although the effort of implementing an enforcement point adds to the amount of development, the interfaces used by the application to communicate with the policy decision point play an important role with respect to the resulting
maintenance cost. A published industry standard interface is desirable, as it can be expected to remain stable and it avoids vendor lock-in.
More information about the application level approach can be found in Chapter 8, “Application level integration” on page 213.