There are several methods that can be used to enforce authorization. They are:
Operating system- or platform-specific mechanisms. If the user being autho- rized to take action is known to the operating system, the operating system can be used to authorize the action and then enforce the authorization. This usually happens when the operating system authenticated the user on the platform where the authorization is taking place. The service subscriber must be directly connected. The advantages of using the operating system to enforce authoriza- tion are that it can all be done transparently, and the application environment may be able to accept the operating system context and use it for authorization within the application server. Again, this can be transparent to the application. This option is only available where the system components are compatible, when, for instance all components are from a single vendor.
Web server mechanisms. Web server mechanisms, including Web SSO systems, are designed to protect Web pages. If protected resources can be mapped to URLs, then using Web server mechanisms can be effective. In order to take advantage of Web server mechanisms, the service subscriber must be directly connected to the Web server, because Web server authentication is based on con- nection-oriented authentication. A disadvantage of this approach is that the user’s authenticated identity is only known to the Web server authentication and authorization system. Authorization at any component beyond the Web server, because, say, finer-grained authorization is required, requires explicitly passing the user’s context to the component. Facilities for passing and accepting the context vary from system to system.
Application server mechanisms. Application servers are able to perform autho- rization based on the authentication they perform or the identity that is passed to them by front-end components. This assumes that the identity can be used to establish the user’s context in the application server’s environment. In most cases, this authorization is limited to allowing access to object methods, based on user roles. This is usually acceptable; but may be too coarse grained in some circumstances. The passing of context from one application server to another may be handled automatically or may need to be handled explicitly, depending on the specific implementation.
Application mechanisms. Applications alone or with the aid of a separate autho- rization system can enforce authorization. Since the application has intimate knowledge of the resource being protected, application-based authorization offers the finest-grained authorization when used together with policies that can be customized to the application. Authorization criteria can take advantage of user, resource, and environmental attributes. The biggest disadvantage of this
approach is that the application programmer, who is probably not well acquainted with the requirements of security programming, must implement security mechanisms. Another disadvantage is that the security for each applica- tion is usually implemented from scratch and does not take advantage of previ- ous efforts.
The implementation of many of the techniques we have discussed in this chapter is the responsibility of the application. Document-oriented techniques must be exercised by applications. XML Signature and XML Encrypt are examples of security services explicitly invoked by applications. Since most options for passing initiator information require inserting information about the initiator in the SOAP message, the application or its agent is the most likely decision point for authorization of the initiator of request.
System Characteristics
Let’s spend some time determining some of the authorization characteristics of this system.
What enforces the decision as to whether ePortal is permitted to make the SOAP request(s)?
Web Services architectures vary considerably. The Web server, the SOAP gateway that determines which application is actually invoked, the application system, and the application itself are potential candidates to make authorization decisions. But the granularity of the decision built into each component is different. While the Web server received the HTTP POST that delivered the SOAP request, the URL referenced may only allow coarse-grained authorization decisions.
The SOAP gateway or the application system is able to differentiate between specific applications referenced in the SOAP message. Therefore, it can authorize use of spe- cific applications.
Finally, the application itself is able to exercise the finest granularity of control. However, while the other components can potentially perform authorization transpar- ently, application-enforced security will usually require the inserting of code into the application. Initiator-based authorization, specifically making decisions based on the identity of the buyer being Joe, is application enforced. In addition, if encryption is used, the data must be available in decrypted form before any decision to authorize based on the encrypted data can be made.
While front-end components, such as the Web server, can be used to make some authorization decisions, since we have decided to use signatures and assertions, the application will need to be part of the authorization process.
What relevant attributes are established for the initiator by ePortal?
What attributes of the initiator will be useful to ePortal in making authorization decisions? Is the user a preferred customer? What is the user’s customer ID number in eBuyer? eBuyer must be prepared to send this information to ePortal in some mutually agreed-to format.
In this example, the initiator, Joe, is a gold customer who is able to purchase up to $50,000 worth of merchandise.
What is the mapping of attributes in ePortal to eBusiness?
If the user is a preferred customer in eBuyer, what does that translate to in privileges at eBusiness? Does that mean that he/she is allowed to buy $100 worth of merchandise or $10,000 worth of merchandise? This translation will, in all likelihood, vary for each of the service provider’s subscribers. This limit may also be different if eBuyer is the initiator rather than Joe. Again, this is a negotiated value and rules must be in place in ePortal to translate the preferred customer status to that of an initiator who is allowed to buy $50,000 of merchandise.
What granularity of authorization is needed and what attributes are needed to make this decision?
Is it sufficient to authorize the service subscriber to send a SOAP message or request the RPC, or is the authorization to perform some action on an instance of an object? As a rule of thumb, the finer the granularity, the closer to the application the authorization must be done. Ultimately, this means that some authorization decisions must be per- formed by the application, with or without the assistance of a separate authorization engine.
In our Web Services example, we must ensure that Joe is entitled to buy through ePortal. This is coarse-grained authorization and could be done by a Web server, assuming that the Web server receives the POST. We also need to ensure that Joe is enti- tled to purchase the quantity of merchandise specified. Is Joe a customer who is autho- rized to commit this amount of money? This is a fine-grained decision that is specific to this particular transaction. The attribute needed to make this decision is Joe’s buy- ing limit.