In our example, we concentrate on eBusiness’s authorization needs. There are two aspects to authorization. eBusiness wants to ensure that it is only allowing ePortal to utilize the services it intends to make available. In fact, since eBusiness provides a range of services and ePortal may not have contracted to use them all, eBusiness needs to make sure that it restricts ePortal to the services it has signed up for. ePortal may have signed up to broker some products but not others.
Second, in the course of supplying the service, eBusiness wants to make sure that the initiator is entitled to request the service on its behalf. If the initiator is Joe Smith, the account used for the transaction should be the one Joe is entitled to use. It should not be Jane Brown’s.
Authorization Requirements
The basic authorization requirements that exist for eBusiness are:
■■ eBusiness wants to ensure that ePortal is entitled to use the services it has requested.
■■ eBusiness wants to ensure that the initiator, Joe, has the authority to purchase the merchandise.
Rules for authorization can be quite complex and require that we know the authen- ticated identity of the initiator or the service provider, the target of the request, and the action requested. Depending on the application, other entities may have a part to play in the authorization process as well. In concrete terms, the target could be merchan- dise, and the action could be a sale. So, we want to know if the requesting party is authorized to buy 5,000 items. This is the minimum information required. In practice, we may need even more information to make the authorization decision. We may need to know more about the requestor, the target, the action, or the environment in which this is all taking place.
We might care whether the time is outside of regular business hours or whether the purchase is larger than the amount allowed for retail customers such as Joe. In many cases, the service provider knows for itself most of the information it cares about. It knows about the environment, the target, and the action. It needs the attributes of the service subscriber, ePortal, or the initiator, Joe. Once they are made available to eBusi- ness by ePortal, eBusiness can interpret them as appropriate.
The authentication we performed earlier gave eBusiness the identity of the service subscriber or initiator. Using an identity to make authorization decisions doesn’t usu- ally scale well, and rather than basing an authorization decision on the identity of the requestor, most security systems collect users into groups or roles with identical privi- leges and then make the decision based on the user’s group or role. For instance, man- agers can sign timesheets or a project leader can authorize a purchase.
With Web Services, the privileges of a person called manager in ePortal may not be the same as the privileges of a person called manager at eBusiness. It is difficult for a large company to standardize names for groups or roles, let alone decide on a standard set of privileges for each. Standardization of groups or roles across two companies is practically impossible. Then, when another Web Services subscriber or even more sub- scribers must be accommodated, practically impossible becomes impossible.
For now, rather than using standard designations for groups or roles, these differ- ences are likely to be resolved by pair-wise negotiation between the Web Services provider and the Web Services subscriber that identifies how to map attributes from eBuyer to attributes in ePortal. This isn’t very satisfying and does not scale well. But, other more practical options have not presented themselves. The Web Services provider will have to understand how each subscriber wishes to map its attributes to attributes that are meaningful to the provider.
Earlier in this chapter, we discussed how to determine the needed authenticated identities for each company. If the SOAP message was signed, we assumed that the signer was an application or a person signing it on behalf of ePortal and that the sub- ject whose SAML assertion was in the header was the initiator. But, this is not assured. At this time, there is no standard guidance on if or how authentication information should be associated with the contents of the SOAP message. SOAP messages can involve more than one initiator, multiple companies, and one or more intermediaries. Additionally, multiple RPCs in the SOAP request can make sorting out the relationship of all the signers and assertions even harder. The relationship of various entities involved in the request must be negotiated, together with an understanding of how the information is to be conveyed.
The first thing to do is identify the entity that has the business relationship with eBusiness and determine if that entity is authorized to request the service. In this case, ePortal and eBusiness have the business relationship. ePortal has discovered that eBusiness, possibly through eBusiness’s business registry entry, offers some service or product that ePortal wants to offer its customers. ePortal and eBusiness have negoti- ated terms for use of the Web Services and probably signed some contract to formalize the relationship. The negotiation may entitle ePortal to receive a percentage of the sale for bringing the buyer to eBusiness.
Assuming that eBusiness is satisfied that ePortal originated the message, eBusiness can then verify that ePortal is authorized to send the document or make the request. If ePortal was able to authenticate itself directly to the operating system, then the operat- ing system can be used to enforce authorization requests. If ePortal was authenticated by the Web server, which did not use the operating system for authentication, or it was authenticated by a Web SSO System, enforcement of authorization begins with those two systems. These systems are usually set up to protect URLs, so the target needs to be a URL. The granularity represented by the URL varies from system to system.
Additional authorization checks may need to be implemented by the Web Service. How the user identity and whatever attributes are provided depends on the environ- ment in which the code executes. In some cases, there are automatic, transparent ways to pass the identity and use it to create a user context at the Web Services implementa- tion. In other cases, there are no transparent ways to pass the identity and set up a user context. Instead, passing the identity and establishing the user’s context become the responsibility of the application.
Now that it’s known that ePortal can make these requests, eBusiness sets about ful- filling them. However, it now needs to authorize the initiator. Since the initiator was never directly connected to ePortal, we assume that information about the initiator is contained in the message. The initiator’s identity could actually be an argument to the RPC for an RPC type message, or it could be contained in the document for a document style of message. Another option is to insert the initiator’s identity and some attributes for the initiator in a SAML assertion in the SOAP message header. There could be more than one SAML assertion in the SOAP header. In such cases, it is up to the parties, ePor- tal and eBusiness, to agree on a way to distinguish the initiator’s assertion from the other assertions that are in the header. In addition, there must be some understanding as to what roles the other assertions represent.
For our example, we will use the SAML assertion. It is a flexible way to include information about the initiator and allows ePortal to include attributes about the user as well. ePortal’s signature on the message must cover the assertion as well as the doc- ument or the RPC calls. This binds the assertion to the requested actions. When eBusi- ness verifies ePortal’s signature, it can also be confident that ePortal intended that the subject of the SAML assertion be the initiator of the transaction. eBusiness should also be confident that ePortal authenticated the initiator. These understandings should be carefully negotiated before the two companies agree to conduct business.
Besides the initiator’s identity, the assertion contains some of the initiator’s attrib- utes in ePortal. For instance, Joe could be a Gold customer in eBuyer. Unfortunately, this isn’t very useful in ePortal. But, because the two companies have worked out a mapping of the attributes in eBuyer to ePortal, ePortal can map the Gold attribute to a $50,000 purchase limit attribute for the user in eBusiness. eBusiness is now able to decide whether to go ahead and process the transaction.
It is unlikely that the initiator’s authority to request the transaction will be enforced by the operating system or the Web server. Depending on the implementation, the authorization could be performed by the application system or even the application itself with the aid of an entitlement engine. Again, the exact mechanism depends on the components that make up the system.