Chapter 6. SOA Security

With the advent of the public Internet and the World Wide Web, security risks have increased dramatically. Systems are exposed to public access and email messages can carry or link to corrupting software. Automation and electronic communications have added new dimensions to security concerns. Electronic integration of services, extending beyond the walls of the enterprise, has created new security exposures. Fortunately, SOA technology and related industry standards have created new opportunities for accountability and control.

Many enterprises still have access control defined at an application level:

• Identity management uses local user identifiers.
• Authentication involves local user passwords.
• Authorization involves a local access control list for each user.
• Access control may be embedded in the application using the access control lists.
• Accountability may be implemented by tagging records with user identifiers and an application audit trail.

Such approaches are only suited to small, closed communities of users. The design of security mechanisms has been delegated to technical people and security administration has been delegated to clerical people. Managers often don't understand the nature of the risks and the necessary countermeasures until they hear about failures. For example, recently Societe Generale, one of France's largest and most respected banks, lost $7 billion in undetected fraudulent trades by an employee.

Fragmented security systems increase complexity, diminish control, and increase security risks. Government regulations such as the Sarbanes-Oxley Act demand that managers take responsibility for ensuring accountability and control of enterprise assets and operations. Security is a fundamental aspect of accountability and control. Agility and efficiency require infrastructure consistency and thus consistency of security mechanisms. SOA improves accountability and control through clarification of responsibilities, and though SOA creates a number of new security concerns, its consistent architecture, technical infrastructure, and clarification of responsibility bring with them opportunities for improving the quality and consistency of security mechanisms.

The fundamental security issues have not changed and there are well-defined standards to support the capabilities necessary to address them. Nevertheless, the consistency, scale, and management participation necessary to an agile enterprise require significant technical investment and organizational transformation. Security is a major business issue for which top management and managers of each service unit must take responsibility and exercise control.

This chapter does not engage in a comprehensive discussion of information systems security but instead focuses on security concerns that arise or are amplified for the agile enterprise, particularly concerns raised by SOA. The chapter assumes that attention has already been given to such concerns as physical security, threats of intrusion from the World Wide Web, and virus protection. The purpose here is to provide an understanding of the requirements and approaches for optimizing security for services, from an enterprise perspective, so that management can plan for and commit to the necessary enterprise transformation.

In previous chapters, we made references to the security fundamentals of authentication, authorization, access control, and auditing. This chapter expands on these topics and goes on to describe the specific technical mechanisms that provide data secrecy (assurance that a message is not read by any but the intended recipient), data integrity (assurance that the message has not been modified in transit), and nonrepudiation (proof that the message was actually created or approved by the stated sender).

The following are primary sources of security concerns for a service-oriented enterprise:

• Expanded number of access points. When organizations are divided into finer-grained service units, each of the services becomes a point of access from other systems and people. Each must have appropriate access controls.
• Expanded communities of users. Each of the more granular service units also has more users and more people interested in accessing data. These people may be in various organizations that would previously have been denied access. Each person must be identifiable, and authorization may involve a greater variety of specific restrictions.
• Perimeter security. It is no longer sufficient to protect against intrusions by building barriers around the enterprise internal network. The internal network is typically accessible from many insecure sites, and there is an increasing number of internal points of access, particularly with SOA.
• Dynamic service relationships. Service units can be replaced when responsibility is assigned to a new organization or new technology is installed. Service users should be redirected without disruption of service, but there must be assurance that redirection does not give access to an imposter.
• Access across trust domains. Some services require access from business partner or customer organizations that manage employee identities, authorizations, and access control policies independently, so there must be a transformation from partner authorizations to appropriate local authorization.
• Electronic documents. Paper is being replaced by electronic documents, which serve as the medium of exchange for assets and commitments between organizations both inside and outside the enterprise. Documents must be protected and participants must be authenticated and accountable for their contributions and approvals.
• Indirect access. A user may request a service that in turn may access other services that the user might not otherwise be authorized to access.

In the following sections we describe the security technologies that most enterprises must upgrade or strengthen to achieve a security capability appropriate for an agile enterprise.

Encryption and Signatures

Encryption is a fundamental security requirement. Data are encrypted to protect them from exposure in an unprotected environment or medium of exchange. Encryption may also be used to enable a recipient to determine whether data have been changed.

Simple encryption can be performed by a transformation using a secret algorithm. Since it is difficult to define new, secret algorithms for every situation, current practice is to perform encryption with a standard encryption algorithm and a unique key. The key makes the encrypted data infeasible to decrypt simply by knowing the algorithm. Note that there is no perfect form of encryption; the more secure forms simply make decryption exceptionally difficult.

Secret key encryption, however, requires that both the originator and the intended recipient of the encrypted data know the secret key as well as the algorithm. That requires, first, that the two parties establish agreement on a secret key, and second, that a different secret key agreement be established for every exchange relationship. Secret key encryption is, nevertheless, a commonly used technique.

Public Key Encryption

In another form of encryption, called public key encryption, an entity possesses two complementary keys: a public key and a private key. The public key can be known by anyone, but only the owner knows the private key. The application of public key encryption is illustrated in Figure 6.1.

Figure 6.1. Public Key Encryption.

Data encrypted with one of the keys can only be decrypted by the companion key. This allows a sender to encrypt data with a recipient's public key, and only the recipient can decrypt the data using the private key. Conversely, a sender can encrypt data with its private key, and a recipient can decrypt the data with the sender's public key; this assures that only the sender could have originated the data and the data have not been changed (but it does not keep the data secret). This system not only authenticates the sender, it establishes nonrepudiation of the content (in other words, the sender cannot deny sending it).

Public key encryption is the foundation of many industry security standards supporting Web services and SOA. A fundamental application is to create electronic signatures.

Electronic Signatures

The World Wide Web Consortium (W3C) has used public key encryption technology to define XML-Signature as a standard for creation and expression of electronic signatures in XML documents. An electronic signature is formed by first processing the data to be signed with a standard digest algorithm that creates a “hash value” that is unique (as a practical matter) for the digested data. A change to the data would result in a different hash value. The hash value is then encrypted with the signer's private key. To validate the signature, a recipient of the signed data applies the same digest algorithm to the data to recompute the hash value. This result is then compared to the signature value decrypted using the signer's public key. If the two hash values are the same, the signature is valid and the integrity of the data is assured.

Though public key encryption alone can ensure message integrity, the XML-Signature mechanism provides data integrity and nonrepudiation without incurring the cost of encrypting/decrypting entire documents.

The following is an example digital signature. Digest, key, and signature values are replaced with ellipses ( … ):

• <Signature Id="SampleSignature" xmlns=“http://www.w3.org/2000/09/xmldsig#”>
•  <SignedInfo>
•   < CanonicalizationMethod Algorithm=“http://www.w3.org/TR/2001/REC-xml-c14n-20010315”/>
•   <SignatureMethod Algorithm=“http://www.w3.org/2000/09/xmldsig#dsa-sha1”/>
•   <Reference URI="#MySignedDocument">
•    <Transforms>
•     <Transform Algorithm=“http://www.w3.org/TR/2001/REC-xml-c14n-20010315”/>
•    </Transforms>
•    <DigestMethod Algorithm=“http://www.w3.org/2000/09/xmldsig#sha1”>
•    <DigestValue>…</DigestValue>
•   </Reference
•  </SignedInfo>
•  <SignatureValue>…</SignatureValue>
•  <KeyInfo>
•   <KeyValue
•    <DSAKeyValue>…</DSAKeyValue>
•   </KeyValue>
•  </KeyInfo>
• </Signature>

A brief description of these elements follows:

• Signature. The signature element (includes all of the following):
  • SignedInfo. Specification of the information being signed (includes CononicalizationMethod, SignatureMethod, and one or more Reference elements)
  • Canonicalization Method. The algorithm used to structure the SignedInfo in a standard way.
  • Signature Method. The algorithm used to compute the signature.
• Reference. A link to the item being signed along with digest specifications (includes Transforms, DigestMethod, and Digest Value)
• Transforms. An optional set of transforms applied to the item being signed (includes one or more Transforms elements).
• Transform. A specific transform applied to the item being signed.
• Digest Method. The digest algorithm applied to the item being signed.
• Digest Value. The value computed by the digest method.
• Signature Value. The value computed by encryption of the SignedInfo, which includes the Signed Info structure and the referenced content.
• Key Info. Optional information that may contain a key, certificate, name, or other key management information since the key may be available from other sources (includes Key Value in the example).
• Key Value. The public key of the signer (contains DSA Key Value in the example).
• DSA Key Value. The key value for DSA encryption as opposed to RSA encryption.

There may be multiple Reference elements for signing multiple objects. A reference may be to an element of the same document (which could be a complex structure) or documents referenced by URL.

Accountability and Nonrepudiation

Accountability is a deterrent to undesirable behavior and a basis for enforcement of commitments. For example, employees are less likely to embezzle funds if they know they will get caught. A customer is more likely to pay for a service if the customer agreement cannot be repudiated and acceptance of a product or service can be proven.

In the past, and still today to a great extent, accountability is established through written signatures on documents. A signature on a paper document can be written in the presence of a witness, and the identity of the signer is established not only by the writing but by personal acquaintance of the parties and possibly credentials such as a passport or driver's license.

There are three important issues concerning enforcement of electronic documents: (1) documents as evidence, (2) compound documents, and (3) preservation of authenticity.

Electronic Documents as Evidence

Today, agreements and commitments are increasingly established electronically; many are in the form of XML documents. Traditional computer applications were developed for recordkeeping within departments. Users of these traditional application must establish their identity to access the system, and actions they take can be captured for accountability. Essentially the computer record of their input is their signature. However, this “signature” is meaningful only within the context of the application, and it is reliable only to the extent that the records cannot be changed to misrepresent responsibility.

When an enterprise records information or commitments from an external person or organization, the existence of the record in a system that belongs to the enterprise is not sufficient to resolve a dispute over the content. Enterprises are increasingly outsourcing business functions that have traditionally been held within the corporation. Without proof of message authenticity, a corporation cannot hold employees of outsourcing providers or the providers themselves legally accountable for the actions documented in electronic records. Even within an enterprise, where substantial assets are at stake, individuals should have greater assurance that their responsibility cannot be forged through tampering with electronic records, and the enterprise should have assurance that people really can be held accountable. In addition, government regulations are requiring greater assurance of accountability for operating decisions and controls.

For example, when an engineer submits a purchase request with an attached specification, the engineer must be accountable for the content of the request and the associated specification. When his or her manager approves it, the manager also becomes accountable. It should be possible to prove what the originator submitted and what the manager approved.

The solution to this dilemma is electronic signatures. The mechanism for applying and validating an electronic signature was discussed above. A signer is accountable and also protected from forgery because the signature could only have been created with his or her private key.

Electronic signatures should be used wherever written signatures would have been used in the past. This should include not only documents created with customers and business partners but documents created internally to authorize expenditures and transfers of assets. Support for signing and exchanging electronic documents should be incorporated into or associated with business process management systems so that signed documents can be an integral part of business processes. Few if any business process management systems currently support signatures on associated documents. An SOA infrastructure with support for public key encryption provides the necessary environment.

Compound Documents

The processing of business transactions frequently involves actions by multiple people or organizations; each of them contributes or approves aspects of the transaction, resulting in a compound document. The document defines the context and data associated with the particular business transaction. The document or portions of it move from one participant or service to the next to establish the context for activities and to capture results.

For example, extending our example, a purchase request and attached specification are originated by an engineer. That person's manager may be required to approve the expense and can add information regarding the approval. The request may then be directed to the purchasing organization to be reviewed and approved by a purchasing agent for compliance with corporate policies. The purchasing organization then proceeds to issue a purchase order (which may also be signed by the purchasing agent) that is incorporated by reference into the compound purchase request document.

Approvers cannot change what they received since it has been electronically signed by those who came before. Thus a compound electronic document may pass through different organizations for different purposes. The primary document may incorporate additional electronic documents by reference—for example, the specification attached to the purchase request might have been included by reference, and the electronic signatures would apply to the primary document and the referenced version of the specification.

Such situations are commonplace in paper-based systems. Current automated systems generally rely on records that are captured, processed, and retained in a single enterprise application with a defined set of authorized application users. With the automation of business processes and the movement of electronic documents among shared services, there must be consistent document integrity and participant accountability mechanisms that are effective across multiple business units as well as in exchanges with other enterprises.

XML-Signature allows each signature to apply to different portions of a compound document. Additional parts do not invalidate signatures on previous parts as long as the signed parts are not changed.

Preservation of Authenticity

Signatures ensure the integrity of the exchange of electronic documents; however, electronic business documents must remain valid for years. This fact places additional requirements on the handling of these documents.

First, a signed electronic document cannot be changed without the signature becoming invalid. In the signing and validation processes, a canonicalization algorithm is applied to ensure that the document is formatted in a standard way. This means that variations such as indentations and extra spaces produce the same signature value. But if the document is modified in any other way, the signature is no longer valid. This might occur, for example, if the document is converted to an internal computer form for processing and then regenerated for forwarding.

Thus a document cannot be transformed to comply with alternative data formats or element names required by a receiving application or service. If a transformation is necessary, the result must be considered a working document to be used by the recipient but distinct from the signed document. This creates some risk to the recipient that he or she (or the entity) may act on a misinterpretation or erroneous transformation of the original document as represented by the working document.

Signed documents should be archived in their original form. Note that documents included by reference must exist in their original form at the URL referenced in the composite document, since the reference is part of the signed data. This should be considered in the creation of the document so that the referenced documents continue to be available and the signature continues to be valid.

Over time, signatures may become questionable. A signer may claim that at the time he or she signed the document, his or her private key was compromised, so the document is a forgery. Records of a certificate authority (discussed later) can provide evidence to the contrary. If the signer gave no notice of revocation of the certificate within a reasonable time of signing the document, that would suggest that the signature was valid.

As a further measure, an “electronic notary” service might be employed. The electronic notary should be operated by a trusted third party. The notary can independently contact the signer to confirm his or her signature on the document. The notary signs the document as an independent third party. The notarized document and signatures can then be archived.

Identification and Authentication

Identification refers to associating a known identifier with a party. Authentication refers to determining if the party is legitimately using the identifier. There are three fundamental forms of identification and authentication: (1) what you know (such as an identifier and password), (2) what you have (such as a credit card, preferably a smart card with encrypted key), or (3) what you are (such as a fingerprint).

The traditional form of identification and authentication is through the use of an identifier and password. This approach has limited value. We refer to the entity to be identified as the requesting party and the entity requiring the identification as the relying party. The requesting party and relying party must first establish an initial trust relationship so that they agree on values of the identifier and password for the requesting party. For subsequent contacts, the requesting party's identifier is recognized by the relying party, and the password is a secret associated with the requesting party's identifier and known only to the requesting party and the relying party. If the requesting party uses the same password for other relationships, there are multiple relying parties that know the requesting party's secret password, and there is an increased risk of exposure where all relationships would be at risk. In addition, various recipients may require different identifiers for the same requesting party. Consequently, the requesting party must keep track of multiple identifiers and passwords.

The use of multiple identifiers also makes it difficult to recognize where the same person should be authorized to access the same business transaction from different applications or when a person is violating a separation-of-duties requirement by performing two mutually exclusive roles.

Digital Certificates

Public key encryption and electronic signatures provide a more robust and convenient form of identification and authentication. To establish an initial relationship, the identity of a participant is established with a trusted third party. The trusted third party provides a digital certificate that the third party has signed containing the identifier and public key of the participant. The participant can then establish its identity by demonstrating that it holds the complementary private key.

A standard form for a digital certificate is specified by International Telecommunications Union-Telecommunications Standards (ITU-T) X.509v3. A certificate authority (CA) is a trusted third party whereby entities can register their identities and public keys and obtain digital certificates signed by the CA. The CA also provides a certificate revocation list (CRL) of certificates for which the private keys have been compromised.

An X.509v3 digital certificate typically contains the following fields:

• version. V1, v2, or v3, designating the version of the certificate standard.
• serialNumber. A unique serial number that identifies the certificate.
• signature. Identifier for the algorithm used by the CA to sign the certificate.
• issuer. A unique identifier for the certificate authority that issued this certificate.
• validity. The valid time interval, two times indicating the earliest time the certificate is valid and the latest.
• subject. A unique name that identifies the entity for which the certificate is issued.
• subject Public Key Info. Contains the public key for the identified entity along with an identifier for the encryption algorithm used with the key (next two items).
• signature Algorithm. Identifier for the algorithm used by the CA to sign the certificate.
• signature Value. The value of the certificate authority signature.
• issuer Unique ID (optional). A unique identifier for the CA that would resolve possible reuse of the issuer identifier used previously.
• subject Unique ID (optional). A unique identifier for the subject entity that would resolve possible reuse of the subject identifier used previously.
• extensions (optional). Optional extensions that address special cases and restrictions, such as a certificate that identifies a CA and a certificate restricted to use for a specific purpose, such as for signatures only.

A public key infrastructure (PKI) is a set of facilities to support the use of digital certificates for identification and authentication. Minimally this involves a registration authority (RA) that validates the identity of entities seeking a certificate, a CA that issues and signs digital certificates and maintains a certificate revocation list, and directories where the certificates (containing the public keys) are available for access. An enterprise should implement a PKI for identification of its employees and service units.

Authentication of a party presenting a digital certificate is somewhat different from authentication with a password. The following steps describe an example exchange:

1. A requesting party submits its digital certificate.
2. The relying party validates the signature of the certificate authority. This establishes that the certificate is valid.
3. The relying party checks the validity time interval to ensure that the certificate has not expired.
4. The relying party checks the certificate authority revocation list to ensure that the certificate has not been revoked.
5. If the certificate is valid, it contains the identifier and public key of an identified party, but it is not yet established that this certificate belongs to the requesting party. The relying party may then encrypt a “nonce” (a unique bit string) with the certificate owner's public key and send it to the requesting party.
6. The requesting party returns a checksum computed with a standard algorithm and encrypted with its private key, using several established elements known to both parties, such as the requesting party's name, public key, the nonce value, and the requested service URL.
7. The relying party receives and decrypts the checksum and performs the checksum algorithm on the same elements to verify that the requesting party was able to correctly decrypt the nonce and encrypt the checksum (with the private key). The nonce prevents an imposter from copying an encrypted checksum from a different exchange by the requesting party.

At the end of this exchange, a valid link has been established for subsequent exchanges. If the requesting party is a person, essentially the link is established with the person's personal computer and browser, with the assumption that the person is in control of the computer. In high-security circumstances, it may be necessary to establish that the person using the computer is actually the owner of the certificate through other forms of identity verification, such as queries about personal information or use of biometric devices such as fingerprint verification. This is described as multitoken authentication.

Two-Way Authentication

The described protocol shows how a requester can be properly authenticated, but there are circumstances in which the provider must also be authenticated. On the public Internet, people are often victims of identity theft or other fraudulent activities because they are directed to interactions with an imposter of a trusted provider such as their bank. Within an enterprise, service users should be able to have their requests redirected when a service provider is replaced or upgraded with a new address, but there could be a risk of being redirected to a fraudulent service.

Where these risks are a concern, the service user should also authenticate the service provider. Service providers should provide a complementary protocol by which a requester can request and validate the provider's credentials.

Single Sign-On

A PKI provides the basis for single sign-on. An individual signs on to his or her personal computer to enable access to the private key; generally users are not expected to remember their private key but have an easier-to-remember password to sign onto their personal computer. On the basis of their certificate and their private key, they can be automatically identified and authenticated for multiple systems. Legacy systems can be enabled with adapters to accept the certificates for identification. The approach reduces security administration and improves security by reducing risk of exposure of conventional passwords, since the user never reveals the secret key.

For SOA, service units and personnel must have identities that are recognized throughout the extended enterprise. It should be possible to establish ad hoc interactions with services to support enterprise-level planning and decision making and to quickly adapt to changing business requirements. PKI and single sign-on are fundamental steps to achieve this flexibility.

Unified identification and authentication also enable one service to pass the identity of a requester through to other services needed to support the original request. This ensures that the requester does not do indirectly what he or she is not authorized to do directly. It also provides support for accountability back to the originator of a request.

The WS-Security standard from OASIS defines a generally accepted approach to integration of standard elements to convey authentication information and ensure message integrity.

Authorization

It is not sufficient for a participant in an exchange to be authenticated and have a reliable identifier. The participant must also have appropriate authorization to participate in an exchange or access certain resources.

System access control is no longer a matter of defining which members of a department are authorized to perform particular operations or access certain data. Users of a shared service may come directly or indirectly from many different organizations, potentially outside as well as inside the corporation. Authorization and access control must be addressed at an enterprise level and, eventually, at an extended enterprise level, with an approach and administrative processes that work for all users and all services.

An example authentication and authorization exchange is illustrated in Figure 6.2. Central to this exchange is the use of Security Assertion Markup Language (SAML), a standard developed by OASIS that defines the form of expression of the authorization request and response in steps 6 to 9 of the exchange described at the end of this paragraph. Different security mechanisms may be used in conjunction with SAML, but a PKI is recommended. Note that in the diagram, arrows that loop back past the requester are redirections of the request through the requester, so responses always come back to the requester from the last-requested site:

1. The requester requests Service X.
2. Service X access control determines that the requester is not currently signed onto this service and redirects the request to the security service with an associated URL for the Service X artifact receiver that expects to receive a SAML assertion.
3. Security service access control determines that the requester is not currently signed on to the security service and issues a credential challenge to the requester. If the requester has already signed on to the security service, skip to step 5.
4. The requester responds to the credential challenge and the response is processed by the authentication authority.
5. The original request to Service X along with authentication information is directed to the local intersite transfer service.
6. The request is then redirected to the original service site artifact receiver function, along with a SAML “assertion” that specifies the requester's attributes, the “responder” (next step), and the URL for the original service request being forwarded from the security service.
7. The Service X artifact receiver submits a SAML authorization request, which includes the SAML artifact along with information about the request, to the security service's responder.
8. The responder applies appropriate policy rules to the SAML artifact and the request information and returns a decision.
9. An authorized request is redirected to the requested Service X; otherwise the request will be rejected as unauthorized.

Figure 6.2. Access Authorization.

This architecture separates the determination of authentication and authorization from the requested service. The attributes of the requesters and the services as well as the security policies are managed and evaluated by the security service. This allows these factors to be managed and controlled independent of changes to the requesters and services, and the overall permissions granted to individuals can be analyzed for consistency and appropriateness. Specialized hardware products, described as XML appliances, are designed for optimal performance of these access control functions.

Since this approach removes access control decisions from the resource being accessed, a legacy application may be protected by the same mechanism as current applications and services. This enables single sign-on within the scope of the enterprise and provides consolidated specification of access control for improved analysis, control, and accountability for authorization.

Role-Based Access Control, Extended

Role-based access control (RBAC) is a widely accepted approach to authorization. The general concept is that the “subject” (the person, system, or other business entity to be authorized) is assigned certain roles that associate authorization policies with resource access control rules. RBAC relationships are depicted in Figure 6.3. The roles have a user focus and effectively characterize the kinds of actions a user should be able to take to fulfill his or her responsibilities within the enterprise. The policies and rules have a service focus and define the details of the authorization of specific roles to specific resources.

Figure 6.3. Role-Based Access Control Relationships.

The exclusive use of roles to specify access authorization has some limitations. We extend basic RBAC by requiring that the subject have attributes that are relevant to his or her authorization, such as the subject's position in the organization. These attributes can be references within policies to further restrict authorization for particular roles.

An RBAC management facility should support a role inheritance mechanism, as depicted in Figure 6.3. Roles may be defined as incorporating the characteristics of other roles. Elementary roles are the most limited and specific, whereas compound roles incorporate the characteristics of less complex roles. So, in the figure, the subjects are assigned the roles that directly and indirectly point to them. This reduces the duplication of access control specifications and allows roles to be composed to more closely align to the access authorization requirements of job assignments.

These roles represent a different perspective from the roles in business processes and organizations. Process roles define a need for a performer, with selection based on attributes required to meet the need, and the process defines the bounds of required behavior—participation in the process. Organizational roles, or positions, define a more generic need, with qualifications (which may be more subjective), and the job description characterizes the bounds of required behavior. Security roles are assertions of the roles a person or system—a subject—is allowed to perform, and access control policies are the limits of expected behavior with respect to accessing resources. The security role assignments reflect consideration of the activities in which the subject is qualified to participate based on his or her responsibilities.

Security roles tend to be more specific than organizational roles and more general than process roles. So, a person in a given position may be assigned several security roles that characterize different types of activities, whereas a single security role may incorporate access authorization that is adequate for the person to participate in a number of similar process roles.

Sometimes security roles and positions can be identified as the same—for example, manager and salesperson—but these roles likely characterize only a primary responsibility of the position, so the same person will likely require other security roles from time to time based on assignments. Sometimes a process role and a security role can be identified as the same, such as editor or reviewer, but the process role designations are more likely to be meaningful only in the process context.

Note that the authorization specifications are also a protected resource, and managers must be authorized to make role assignments and specify resource security policies. This is discussed in more depth later in the chapter.

The definitions of these various roles should be considered orthogonal so that they can be managed independently; otherwise, a change could mean that each of the others would require changes. That is, job descriptions, process definitions, and security authorizations would be tightly coupled. At a minimum, references to roles should be appropriately qualified so that there is no confusion about roles that have the same name but different meanings.

Security roles are defined as required to address the access authorization needs of individuals and systems according to the nature of their business activities. A person likely has several roles that together define that person's authorization. The grantor of authorization, the person who assigns the roles to the person, should be able to think in general terms about the things the person needs to be able to do, and the roles should incorporate appropriate authorization.

RBAC is particularly important in SOA because of the expanded community of potential users of services and the need to authorize people as well as systems for appropriate access before their activities are disrupted and delayed by denials of access.

The manager authorizing access is not usually the manager of the service for which access is required. RBAC enables a separation of responsibilities so that the service manager can specify the access authorization of certain roles, and the managers of employees can assign roles to employees, giving them the necessary authorization to do their jobs.

Of course, assignment of roles, in many cases, is not a unilateral decision by an employee's manager but instead involves an approval process in which other managers, perhaps the service unit manager, have the opportunity to scrutinize the authorization.

Development of a specification for business-oriented modeling of RBAC specifications has been initiated at the Object Management Group (OMG).

Definitions of Roles

The following are a number of examples of types of roles to be considered:

• Organizational role. The position of a person in an organization determines certain types of authority, such as an expense authorization limit as well as hiring and firing authority, that are applied by approval processes. The position also implies certain access authorization required to perform in the position.
• Financial role. The relationship of a person to a budget account determines his or her authority with respect to that account. This authority is usually related to organizational position. For example, a person should only be able to approve expenditures against a specified budget account.
• Process role. A subject (person or system) may be assigned a role in a particular process. The subject should have authorization to access associated operations and data for that particular process instance but not other instances of the same process.
• Process management role. A person may have authority to make process role assignments, resolve exceptions, and approve variances in specified business processes.
• Agent role. A subject may participate in certain types of activity or agreements with specified authority to make commitments on behalf of another person, organization, or enterprise. This may reduce to authorization to participate in processes in which such agreements are being established and the context defines the principal of the agreement as a client of this agent.
• Surrogate role. A person (surrogate) performs as another person (grantor) in certain designated roles of the grantor that the grantor is authorized to delegate.
• Proxy role. A person grants authorization to another to act with the grantor's authority in a particular activity or process, so the authorization is restricted to a specified context, as opposed to all similar activities or processes.
• Employee role. Any employee should have authorization to access certain personal information, submit time and expense reports, and access other enterprise information related to employment and employee benefits. Similar general controls may be defined for contract employees and employees of business partners.

The goal of this complex set of role definitions is to improve the ease and accuracy of authorization. A new employee is assigned one or more roles that are typical of the job. It is not necessary to examine each person's responsibilities and authority with respect to everything they may do and every system with which they might interact. The result is that the authorization is actually more considered and complete because it is expressed in appropriate business terms. The same applies when the employee gets a new assignment. Furthermore, as systems change or new systems are implemented, it is not necessary to change the authorization of every potential participant, only to redefine the authorization specifications for the affected, elementary roles.

Role Authorization Requirements

Each type of role discussed previously places different requirements on the rules that specify the access authorization of a role. The most straightforward specifications of authorization grant access to service operations including requests for data. Rules for data access might restrict access to certain classes and attributes or relationships on those classes. However, there are often further restrictions on authorization, such as those discussed in the following sections.

Attributes of the Subject

The subject (person or system being authorized) may have credentials, such as a license or certification, that qualifies them for access to certain resources, regardless of the person's organization position or current assignment. This can be addressed simply by assignment of a role that reflects the necessary authorization in its access policies.

The Subject's Organizational Relationships

The policies associated with an organizational position may define authorization based on the relationship of the position to people in other positions. So a manager can access personnel records of subordinates but not personnel records of other employees such as subordinates of other managers. (This also requires reference to context data, for example, the employee in the record.) For financial records, a subject might be restricted to records pertaining to the organization in which the subject has a managerial position.

Note that a person may be assigned to multiple positions at the same time, such as department manager, member of a task force, and project leader. Each of these positions may bring a different set of roles.

The Subject's Relationship to a Process

A subject may be a requester of a process, a participant in a process, or a manager of a process. A requester may have authorization to initiate a process, but then, for an active process, access is restricted to process instances he or she requested. A participant in a process generally is restricted to access of processes and associated data for process instances to which he or she is assigned to a role. Generally, a process manager has administrative access to all instances of a process type, but in some cases different organizations may use the same processes and a manager might be restricted to administrative access to process instances initiated within his or her department.

In all cases where the subject is restricted to less than all instances of a process, the rules must refer to context data of the process instance, to establish the subject's relationship. For example, the rule for a process participant must find that the participant identity matches the identity of the person assigned to the process role. Rules may then authorize access to data associated with the context, such as product data for the associated product.

The Subject's Relationship to Data Being Accessed

A subject's access to data may be restricted to data that is in some way related to the subject. For example, an employee is authorized to read but not update his or her personnel records. In this case the requester's employee identification must match the employee identification of the record. A general policy might authorize an employee to read any document that he or she signed.

Grant of Authorization by Another Subject

Each grant of authority is made by someone else with authority to make that grant of authority. A subject's authorization should be by reference to the authorization of the grantor. A grant may be constrained by (1) the role(s) the grantor intends to delegate, (2) the role(s) the grantor is allowed to delegate, and (3) additional restrictions imposed by the grantor. This includes surrogates and proxies where the authority to designate surrogates or proxies may be restricted to certain persons and certain contexts. As in other situations, the subject should be accountable for his or her actions, but here the grantor should also be accountable for actions taken by the subject under the grantor's authorization. In all cases, an audit trail should identify the grantor of authorization and when the grant of authorization was effective.

Runtime Authorization

At runtime, a service unit should not need to deal with the details of the participant's roles or the details of the policies. Those data are maintained and applied by the security service, and the authorization determinations are made by the security service.

When a participant requests a particular service operation, a request is sent to the security service, specifying the participant, the type of request, and context data. The security service retrieves the participant's role specifications, evaluates the relevant policies against the roles and the context of the intended action, determines whether permission should be granted, and returns that result to the requesting service.

Note that a request for authorization evaluation may occur not only when the participant accesses a service but could occur when the service is about to take a protected action or return a result that might have different restrictions from the initial request.

When a party invokes a service and that service unit invokes another service, the actions of the second service unit must be based on appropriate authorization. This may occur in two ways: (1) the original party may authorize the intermediate service unit to act on its behalf, so the access to the second service is based on the party's credentials, or (2) the intermediate service unit acts on its own behalf on the basis that its actions are authorized to fulfill authorized requests it receives.

The first alternative creates the risk that the intermediate service unit could use the originating party's credentials to access resources it would otherwise not be authorized to access. This could be addressed by requiring both the originating party and the intermediate service to have appropriate authorizations. The second alternative relies on the intermediate service unit having an understanding of appropriate limitations on use of the second service and the results it returns.

XACML Policies

eXtensible Access Control Markup Language (XACML) is an OASIS standard for specification of policies and rules that define access authorization. Figure 6.4 depicts an abstraction of an XACML authorization structure.

Figure 6.4. XACML Policy Set Structure.

A PolicySet contains one or more policies and may contain PolicySets, making it potentially recursive. A Policy contains rules for determination of authorization.

A PolicySet contains a Target element, and a Target element may also appear in a Policy or a Rule. The Target element limits the number of policies and rules that must be considered for an authorization request based on the context.

A Target defines circumstances and things for which the associated PolicySet, Policy, or Rule applies. It contains DisjunctiveMatch (logical or) elements that in turn contain ConjunctiveMatch (logical and) elements that each contain Match elements. The result is a set of alternative sets of Match conditions that apply to one or more subjects (that is, participants) of the authorization request and the resources, actions, or environment to be accessed. Each Match contains an attribute value and a reference to an attribute in the context or subject attributes. When the target matches, the policy set, policy, or rule is further evaluated.

A PolicySet or a Policy may contain Obligations. These are specifications of required actions to be taken at the point of authorization enforcement. There are currently no standards defined for obligations.

Within a policy, each Rule contains a Condition and an Effect. The Condition contains expressions that evaluate to true or false. These operate on attributes similar to those of the Match elements, but there are more complex functions that may be applied to determine the result. The Effect is the associated result if the condition is true and returns a value of Permit or Deny. Policy qualifiers can determine whether rule evaluation stops when the first Permit or Deny is encountered.

This discussion has been an oversimplified representation of XACML policy specifications. PolicySet and Policy have a number of other elements that qualify the interpretation and application of the policies. Rule conditions can also be very complex. The language is capable of expressing diverse authorization policies. The difficulty is that, as an XML form, it is quite verbose and the intent of the policies is obscured by the XML details. A graphical tool is needed to provide appropriate abstractions.

XACML 2.0 is expected to complement SAML 2.0 so that XACML expressions can operate on SAML subject attributes. Of course, the attributes referenced in an XACML policy must be present in the authorization request and the roles and attributes of the associated subjects, and the attribute names must match. Additional qualifiers can determine the action to be taken if the attributes cannot be found.

XACML policies should not be confused with policies defined by WS-Policy, another specification under consideration by the W3C for definition of service policies. The focus of WS-Policy is to express requirements and capabilities of services so that service users can determine whether potential providers are compatible. The WS-Policy assertions are essentially service specifications, whereas XACML policies are rules that must be evaluated to determine whether access is allowed or denied.

Access Control Administration

Roles and policies must work together to achieve the desired access control. Responsibility for access control policies is primarily the responsibility of managers of the services to be accessed. Responsibility for role specifications for a subject is primarily the responsibility of the individual's manager. When a service unit acts as a subject, it also needs role assignments that, for the most part, are the responsibility of the service unit manager.

Administration of roles and policies is a highly sensitive capability and must be protected by appropriate access controls. For administration, the access control roles and policies must define authorization to create or change roles and policies of others. Managers with authorization to assign roles or define policies must be restricted regarding the roles they can assign, the entities to which they can assign roles, and the services for which they can define access policies.

Changes to roles, role assignments, and policies should be managed through appropriate business processes. In the course of their work, individuals encounter needs for access authorization and should have a defined process for requesting authorization. The request should be given appropriate approval, the change should be defined by a qualified person, and, depending on the nature of the authorization, the proposed change should be reviewed and approved by other managers.

Many of the changes are required only at the time a new service is implemented or a person is assigned to a new position in the organization. However, other changes, particularly to role assignments, may occur more often. Primary examples are delegation of authorization such as the surrogate and proxy roles and temporary assignments such as participation in a project or task force.

A surrogate role requires that the primary individual grant authorization to their surrogate to perform with certain authorization defined by the organizational position of the primary individual. The grantor must be able to redirect requests to the surrogate and define the roles the surrogate is authorized to perform.

A proxy role is similar to a surrogate role except that the grant of authorization is restricted to a specific context such as a process, a project, or a design review. In this case, the delegation must include an attribute that specifies the particular context.

Both these delegations require supporting policies. In general, security policies should be generalized to avoid identifying specific personnel, organizations, resources, or processes and should relate variables in an authorization request to attributes of participating entities and the context in which they seek authorization. So there should be general rules to authorize the grant of surrogate and proxy authorization, and there should be general rules to enable the surrogate or proxy to exercise their restricted authorization at runtime. In addition, there must be accountability for changes to role assignments and policy specifications. It should be possible to determine who granted authorization for an entity to take a specific action, and grantors should be able to periodically review the authorization (that is, role assignments) they have granted.

Clearly, the development of roles and policies is a complex undertaking. Special skills and tools are required to establish the initial framework, to define administration processes, and to enable businesspeople to manage routine changes such as assignments of roles by managers. This may require assistance from a person skilled in the specification of policies, but the managers have clear responsibility and the policies should not change very often.

On the other hand, assignment of roles to people does occur frequently, and certain roles may be assigned frequently throughout the enterprise. The assignment of roles, itself, must be the subject of formal business processes that ensure appropriate criteria are applied and appropriate approvals are obtained.

Modeling tools are needed to appropriately specify grants of authorization. Managers must be able to easily express role assignments and policies and to periodically review all the specifications for which they are responsible as well as the subjects that have been granted authority to access their resources by other managers. Modeling tools are discussed further in Chapter 10.

Federation of Trust Domains

A large enterprise may have separate divisions or subsidiaries that each manage security data about their personnel separately—that is, those in different trust domains. At the same time, there is the potential for shared services that personnel from multiple divisions or subsidiaries should be allowed to access. In addition, an enterprise may have close relationships with certain business partners where business partner personnel should be allowed to access certain enterprise systems and services, and conversely, enterprise employees should be able to access certain business partner systems and services.

For example, a business partner employee may represent the business partner in a business transaction, and the receiving service must determine whether the employee has the authorization to act on behalf of the business partner organization. Similarly, different customers may submit requests in the form of product or service orders. These requests may be submitted by authorized customer personnel. The receiving enterprise must determine that the customer is trustworthy and that the request is appropriately authorized by the customer organization or other trustworthy entity.

Essentially, these participants come from other trust domains. They are not known to the enterprise. Their trustworthiness must be established by another source that has been previously established as sufficiently trustworthy.

An extended enterprise may involve a number of suppliers and customers. Each of these has mechanisms for identity authentication and authorization of their employees and others who are expected to access their systems and services.

There is currently no industry standard for federation. A WS-Federation specification has been proposed and is the subject of an OASIS technical committee formed in May 2007.

Federation involves a cooperative relationship between trust domains so that participants known to one domain can obtain access privileges in another domain. The following steps are an example of the type of exchange required for service of one enterprise to allow access to an employee of a trusted business partner.

1. The relying domain security service locates the participant's home trust domain.
2. The home trust domain provides the participant credentials that specify attributes for relevant roles. These may be restricted to roles and attributes that are allowed to be shared with other trust domains.
3. The relying domain security service must accept the identity of the participant, probably as a temporary entity for the duration of the login, to support subsequent authorization requests.
4. The relying domain security service must transform and filter the participant's credentials to its local requirements (including limitations on acceptable roles), and the subject's credentials must be made available for subsequent access decisions.
5. The relying trust domain then proceeds with its normal response to the initial request using the subject's ad hoc identity and security assertions.

The requested service subsequently requests authorization(s) that apply the local policies and rules to the request context and the participant's credentials.

There may be different approaches to step 1. For example, the Liberty Alliance has defined an approach to work with Web browsers. This approach requires that a participant first log in at a home trust domain. The authentication service calls a common domain server to send a cookie to that participant and create a record that the user is logged in. The common domain server is accessible from all affiliated trust domains.

The relying security service acting in step 1 sends a request to the common domain service, which has access to the participant's cookie. (A cookie is only accessible to the domain that created it.) The common domain then returns the identity of the user's home security service to the relying security service. The relying security service must then obtain the participant's credentials as described in steps 2 through 5. The common domain service tracks the domains in which the participant is signed in so that it can propagate a logout or expiration of the session.

The Liberty Alliance protocol only works with Web browsers, involves more message exchanges to establish access authorization, and relies on a common domain server that represents a potential single point of failure for all participating trust domains.

In the absence of an industry standard, the most straightforward approach is to establish partner employee identities within the enterprise security system and grant restricted access similar to that granted to contract personnel. This results in some increased administrative effort but avoids the need to develop and implement custom strategies and techniques that require continuing attention as business partners or their systems change.

Perimeter security

Enterprise security has focused on access control at a protected perimeter, between the internal systems of the enterprise and the outside world. In early data centers, the perimeter was the walls of the data center. As the scope of access was expanded to remote access, the perimeter expanded to controlled use of online devices. As access was expanded to the Internet, firewalls controlled access from outside the enterprise.

Although the Internet does represent a major threat to security, there are nevertheless threats within the enterprise from both employees and from nonemployees who gain access to the intranet. Internal networks are often accessible from conference rooms or other less secure sites. The sheer size of internal networks and number of systems accessible from the enterprise intranet represent a significant security risk.

Enterprises that implement the high degree of integration, accessibility, and flexibility represented by SOA have an increased risk of intrusion. This risk can be reduced by creating smaller protected domains within the enterprise network.

SOA enables compartmentalization. Each service unit represents a compartmentalized capability that is integrated through well-defined interfaces. Service unit applications can be isolated behind their Web servers. An access control perimeter with firewall and proxy server can be established around each service unit that manages highly sensitive data or operations. Consequently, access to service units is still limited when there is intrusion into the enterprise intranet.

Vulnerability Scanning and Intrusion Detection

SOA increases the number of access points for enterprise systems, and many of these access points are exposed to the public Internet. XML technology provides a common target for identification of vulnerabilities by potential intruders. The widespread use of popular middleware products, XML appliances, and XML processing algorithms all increase the risk of exposure by enabling intruders to exploit vulnerabilities in those products. Of course, critical business transactions provide a very appealing target to intruders.

For requests from known requesters, strong authentication and accountability mechanisms provide a deterrent. In addition, a new class of product has emerged: XML hardware in the form of a firewall or appliance. These are hardware products that scan XML messages for known problems essentially equivalent to the scanning of email messages for viruses. The XML firewall extends traditional firewall capabilities to address these XML concerns. By implementing these capabilities in hardware, the performance impact can be minimized.

Increased exposure also results from efforts to detect and respond to disruptive events from various external sources as discussed in the next chapter. Fraudulent events could trigger false alarms or emergency response that would disrupt business operations or worse.

Monitoring, Logging, Alerts, and Audits

Monitoring, logging, alerts, and audits are not new business requirements—they were common practice before computers. What has changed is the volume of activity, the number of participants, the obscurity of business operations occurring within computer systems, and the exposure of systems and communications to Internet access.

The security service unit should produce a log of restricted activity and provide reports for periodic review by the application or process owners so that monitoring and analysis span the enterprise. Managers should be aware of the ways in which their employees are using their grants of authorization. Monitoring and query capabilities should be provided for observation and investigation of potential improprieties. The level of tracking accesses should reflect the level of sensitivity of the resource and the type of operation so that queries about the status of a purchase order are not tracked with the same level of concern as queries against personnel records. It should also be possible to program various alerts to provide notice when certain unusual operations are performed or the occurrence of certain requests exceeds normal thresholds. Periodic audits should be conducted to assess controls, analyze authorization criteria, and sample current activity.

Monitoring, logging, alerts, and audit support should be incorporated into sensitive business processes and applications as well as the security infrastructure. Commercial products are available to support monitoring and logging at an access control level, but standards are needed for monitoring and assessing process activity to identify questionable business transactions. Such capabilities should be incorporated in business process management systems (BPMS), discussed in Chapter 3, and business activity monitoring (BAM), discussed in Chapter 5.

Though organizational roles are orthogonal to security roles, organizational roles define responsibility for resources. Consequently, reporting of access activity should be directed to the management chain of the protected resources. Furthermore, reporting of denied requests for access to sensitive resources should be reported to the management chain of the individual making the request. Thus the organization structure is an important consideration in the monitoring of security as well as the implementation of access controls. We will discuss the nature of the agile organization structure in the next chapter.