This chapter is from the book
This chapter is from the book
This chapter is from the book
Access Control
The primary reason for creating services is to make it easier to access their functionality, but at the same time you need to exercise some control over who is using the services. You may need to control who can perform certain operations. After all, you don't want some stranger making withdrawals from your bank account! You may need to limit the volume of usage. Services have finite capacity, and an unbounded demand may cause undesired performance degradation or outright failure. For a variety of reasons, you often need the ability to control access to your services.
Access control can be thought of as a set of policies applied at one or more policy enforcement points. An access control policy is a rule governing the access to the service. These rules may specify actions that individual parties are either allowed to take or must take under specific circumstances, or they may specify conditions under which access may be granted. One of the access control policies governing access to your bank account from an ATM is that you must provide a PIN (a required action on your part), and that PIN must match the one the bank has associated with your bank account (a condition that must be satisfied).
A policy enforcement point identifies the specific place in the architecture (usually an interface) at which the policy is enforced. In the ATM example, the enforcement point may be in the ATM (which would require the bank to provide the real PIN for the account to the ATM), or it may be at the bank when the transaction request is approved (a safer alternative).
Access control policies can cover many topics. Authentication (validating your credentials), authorization (establishing that the supplied credentials give you the right to access this particular account), and encryption (protecting your PIN from unauthorized viewing) are common topics for access control policies, but there are many others as well. Digital signing of message contents, the non-repudiation of requests (making an undeniable record that a particular message was received), and the creation of an audit trail of service utilization are frequently found to be requirements in business processes.
Policy Enforcement Points
While it may be easy to state a policy, finding the appropriate place to enforce the policy is often not as straightforward as you might like. The enforcement of a policy requires the interception of the request, and possibly the reply as well. Setting up the system to intercept the request and reply requires a change to the architecture.
There are a number of places at which access control policies might be enforced. The choice of where to locate the policy enforcement point and which participant will initiate the policy enforcement depends very much upon the technique used to access the service. When services are being directly accessed, the enforcement point for these policies is generally the service interface, and the required functionality for enforcement is generally provided by the service provider (Figure 4-15). Of course, the service provider will likely employ other supporting services to aid in this enforcement, but it is the service provider that is responsible for intercepting the requests (and possibly the replies as well) and ensuring that the policies are checked and enforced.
)
Figure 4-15 Access Control Policy Enforcement in Direct Service Access
While placing policy enforcement within the service provider may make logical sense, it does require a change to the service provider design. For some service providers, particularly purchased software applications, this may not be an option. Even when it is possible, changing the service provider design may be complex. From a software maintenance perspective, this can be an expensive option.
Access Control with Proxies
Proxies provide an alternative location for policy enforcement—one that allows access control policies to be added without altering the service provider (Figure 4-16). This style of access control is commonly used when services are being provided via HTTP interfaces. In many cases such proxies are introduced into HTTP-based systems specifically to provide access control. Proxies used for this purpose are often referred to as policy agents.
)
Figure 4-16 Access Control Policy Enforcement with Proxy Access
Moving policy enforcement into the proxy provides a nice separation of concerns from a software engineering perspective. With this approach, policy enforcement can be added or modified without altering the underlying service provider. The policies and policy enforcement can be tested and managed independently of the service provider.
The proxy approach has an access control weakness: In the strictest sense, the original service interface remains unprotected. Any component that can gain access to this service interface is in a position to use it—or abuse it. Because of this, when the proxy pattern is employed, the actual service provider is generally located on a physically secure private network protected by a firewall. To guard against unauthorized access, the proxy is placed in a demilitarized zone (DMZ), which is separated from the public network by another firewall, resulting in the configuration shown in Figure 4-17.
)
Figure 4-17 Typical Proxy Deployment
Beyond the access control weakness, there are other drawbacks to the proxy approach. The introduction of the proxy requires a configuration change on the part of the service users to redirect their requests to the proxy interface. The use of a proxy also introduces additional inter-process communications. In high-volume low-latency applications, the increase in latency caused by these additional communications can be an issue.
When asynchronous result delivery is required, there is additional work that must be done. To control access to the results delivery interface, either the existing proxy must be extended to also be proxy for the service user or a second proxy must be introduced. Since every proxy is dependent upon the location of the interfaces it is guarding, it becomes increasingly difficult to manage this approach as the number of services and service users increases. Every deployment change to every interface requires a proxy update.
Access Control with a Mediation Service
The use of a messaging service for communications between the service user and the service provider presents yet another possible location for policy enforcement (Figure 4-18). Because of the extended functionality, this expanded service is more appropriately termed a mediation service. The mediation service contains within it both the messaging service and the policy enforcement.
)
Figure 4-18 Access Control Policy Enforcement with Message-Based Access
As with the messaging service, the mediation service provides the interfaces for both the service user and service provider. Since the mediation service provides both interfaces, there are no dependencies on the location of either the service user or service provider. The symmetric nature of the sending and receiving interfaces makes it easy to support all of the basic service interaction patterns.
The mediation service can enforce policies governing access to its own interfaces. It can authenticate the component trying to gain access and check that component's authorization to use the mediation service. Beyond this, it can check the component's authorization to send or receive from a particular messaging destination. It can require encrypted communications at both interfaces, perhaps using SSL. This ability to secure the connection to the service provider overcomes one of the shortcomings of the proxy approach, which cannot protect the service provider's interface from direct access.