第 11 章 Web 服务安全模式

CHAPTER 11 Patterns for Web Services Security

You are what you do, not what you say you’ll do.

Carl Gustav Jung

11.1 Introduction

Service-oriented architectures (SOAs) and web services are special cases of distributed systems. Distributed systems are typically heterogeneous systems that are accessible to a wide variety of institution partners, customers or mobile employees, and introduce a new variety of security threats. To protect its assets, an organization needs to define security policies, which are high-level guidelines that specify the states in which the system is considered to be secure. These policies need to be enforced by security mechanisms. In large organizations, the policies may be issued by different actors, making their management difficult. Moreover, they need to be enforced for a variety of resources. To make things more difficult, they may have to follow government or institution regulations. One way to allow interoperability, apply security, and enforce compliance with regulations is through the use of standards that define architectures to guarantee that all participants will follow the same rules in their interactions.

There are many web services security standards, which are rather complex and sometimes overlap; representing them as patterns makes them easier to understand and to compare with other patterns. This chapter presents our work on security patterns for web services and their standards. Many patterns have been identified in the web services community, at various level of granularity. For example, [Ben02] and [Zir04] propose patterns for web services composition, while [Ima03] and [Tat04] identify security patterns.

However, most of the proposed web services security patterns are low-level patterns. They are effectively implementation patterns that give solutions to concrete problems in terms of specific technologies. Erl has written a whole book on patterns for web services [Erl09]. However, his patterns are rather abstract, for example Brokered Authentication, and do not consider any aspects of standards: they are also mostly descriptive. At present, only our patterns deal with the security of web service standards. We have also written web service reliability patterns [Buc09b], as well as misuse patterns for web services [Mun11]. A survey of our work is given in [Fer12c].

Web services standards tend to be complex and verbose, and it is not easy for designers and users to understand their key points. Web services standards are typically long documents: for example, the XACML 3.0 Core Specification run to 150 pages, and is written to be comprehensive but not to be easy to understand. It uses a combination of XML, UML and natural language [Mos05]. By expressing web services security mechanisms and standards as patterns, we can verify whether an existing product implementing a given security mechanism supports some specific standard [Fer06d]. Conversely, a product vendor can use the standards to guide the development of the product. By expressing standards as patterns, we can also compare them and understand them better, and discover overlapping and inconsistent aspects between them. A standard defines a generic architecture, and this is a basic feature of any pattern; it can then be confirmed as a best practice by looking at products that implement the standard (and implicitly the pattern). There are many security standards for web services [Fer 10b] defined by several committees, including W3C, OASIS and IETF.

The patterns described here are specialized versions of more fundamental and more general patterns. For example, XACML [Del05] is a specialization of the AUTHORIZATION pattern. As such it carries the general properties of an AUTHORIZATION pattern and adds aspects specific to XML access control. The new aspects may themselves be patterns; for example, the Composite pattern [Gam94] appears frequently in these models to indicate recursive composition. Identifying patterns as part of a more complex pattern makes it easier to understand the functions of the complex model.

The pattern diagram shown in Figure 11.1 shows the relationships between our patterns for web services standards.

Figure 11.1: Pattern diagram for web services standards

WS-SECURITY (page 330) describes how to send secure and authenticated messages by leveraging a standard for XML Encryption, and how to authenticate messages by using the XML Signature standard [Has09c].
Authorization to access specific parts of an XML document is defined by the XACML standard, which is composed of rule definition (XACML Policy) and rule enforcement (XACML Evaluation) [Del05].
Authorization and authentication assertions can be conveyed to different domains by using SAML [Fer06d].
General policies are described using WS-POLICY, which is used in turn to define trust among entities (WS-TRUST).

We describe patterns for all these standards except WS-Federation and WS-Secure Conversation. We also include patterns for application and XML firewalls [Del04]. All these patterns were written with Nelly Delessy and Ola Ajaj [Aja 10a][aja 10b].

11.2 Application Firewall

ALSO KNOWN AS CONTENT FIREWALL

The APPLICATION FIREWALL pattern allows filtering of calls and responses to/from enterprise applications, based on an institution’s access control policies.

EXAMPLE

Consider an application for handling medical records in a hospital. One of the services it provides is to allow patients to look up their personal medical records from home. To ensure that only patients can access this service, a user must first be identified as a patient and must then be authenticated. Finally, the application must ensure that only the medical records belonging to the patient are returned (that is, it must match the name in the medical record with that of the user).

One way to provide this security is to let the application maintain a list of all valid patients with their authentication credentials, and implement the code for blocking unauthorized access. This approach has several problems. In the future, if the hospital decides to give patients the ability to schedule appointments, it will have to repeat the implementation of the access control code for the scheduling application as well. Furthermore, if there are changes in hospital business policies – for example, to allow external primary care physicians to access the medical records of their own patients – these applications will have to be rewritten. In this changing scenario, a new access control list for authorized primary care physicians will have to be added to the medical record application, and a list of patients will have to be associated with each physician to indicate the patients belonging to a specific doctor. Such application modifications are time-consuming, difficult to manage, expensive and error-prone.

CONTEXT

Enterprise applications executing in distributed systems accessed from a local network, the Internet, or other external networks. These distributed systems typically include packet filter and/or proxy-based firewalls.

PROBLEM

Enterprise applications in an organization’s internal network are accessed by a broad spectrum of users that may attempt to abuse its resources (leakage, modification or destruction of data). These applications can be numerous, and thus implement access control independently in ad hoc ways, making the system more complex and thus less secure.

Moreover, traditional network firewalls (application layer firewalls or packet filters), do not make it possible to define high-level rules (role-based or individual-based rules) that could make the implementation of security policies easier and simpler.

How can we control the hostile actions of users who access our applications? The solution to this problem must resolve the following forces:

There may be many subjects that need to access an application in different ways; the firewall must accommodate this variety.
There are many ways to filter application inputs. We need to separate the filtering code from the application code.
There may be numerous applications that may require different levels of security. We need to define appropriate policies for each application.
The security policies are constantly changing and need to be constantly updated. It should therefore be easy to change the firewall filtering configuration.
The number of users and applications may increase significantly. Adding more users or applications should be done transparently and at proper cost.
Network firewalls cannot understand the semantics of applications and are unable to filter out potentially harmful messages.
Any type of security policy should be enforceable by the firewall.
There are many ways to perform authentication. The firewall must support this variety.

SOLUTION

Interpose a firewall that can analyze incoming requests for application services and check them for authorization. A client (user, role) can access a service of an application only if a specific policy authorizes it to do so. Policies for each application are centralized within the APPLICATION FIREWALL, and they are accessed by the firewall through a policy authorization point. Each application is accessed by a client through a policy enforcement point that enforces access control by looking for a matching policy in the policy base (the set of policies). This enforcement may include authenticating the client through its data stored in the identity base (the database of identities).

STRUCTURE

Figure 11.2 shows the class diagram for the APPLICATION FIREWALL pattern. The classes Client and Service have the usual meaning. A Client accesses a Service provided by an application. The access requests are controlled by authorization rules (denoted here as policies to follow the usual industrial notation), and represented by the Policy class. Policies are collected in the PolicyBase class. Clients are denoted as subjects in the authorization rules.

Figure 11.2: Class diagram for the APPLICATION FIREWALL pattern

The firewall consists of a PolicyAuthorizationPoint which centralizes the definition of the policies and identities throughout the institution, and several PolicyEnforcementPoints, which are used to check the accesses to the applications. The data flowing through the firewall is checked by the ContentInspector.

The enterprise applications are represented by the class Application, which is made up of Services. A service is identified by a serviceId, which is usually a URI or a URL.

DYNAMICS

We describe the dynamic aspects of the APPLICATION FIREWALL pattern using sequence diagrams for two use cases: ‘Filter a client’s request with user authentication’, and ‘Add a new policy’.

Use Case: Filter a Client’s Request with User Authentication – Figure 11.3

Figure 11.3: Sequence diagram for the use case ‘Filter a client’s request with user authentication’


Summary	A Client requests access to a service of an Application to either input or retrieve information. The access request is made through the PolicyEnforcementPoint, which accesses the PolicyAuthorizationPoint to determine whether to accept or deny the request (page 238).
Actors	A Client.
Precondition	Existing IdentityBase and PolicyBase classes must be in place in the firewall. The IdentityBase contains the data necessary to authenticate a Client. The PolicyBase contains specific policies defined by the organization.
Description	1 A Client requests access to an Application.
	2 An ApplicationFirewall, through its PolicyEnforcementPoint, intercepts the request and accesses the PolicyAuthorizationPoint.
	3 The PolicyAuthorizationPoint authenticates the Client through its IdentityBase. This step may be avoided for subsequent requests through the use of a Session class.
	4 Once the Client is identified and authenticated, the PolicyAuthorizationPoint filters the request according to the PolicyBase. The request is accepted or denied according to the defined policies.
	5 If the request is accepted, the firewall allows access to the service of the Application and the access is logged by the ApplicationFirewall.
Alternate Flows	If the Client is not recognized, or if no policy allows the specific Client to access the specified service, the firewall rejects the access request to the service.
	If the user has already been authenticated, the Client may not be authenticated again (single sign-on use).
Postcondition	The firewall has provided the access of a Client to a service, based on verifying the identity of the Client and the existence of a matching policy.

Use Case: Add a New Policy – Figure 11.4

Figure 11.4: Sequence diagram for the use case ‘Add a new policy’


Summary	The security administrator intends to add a new policy to the set of policies. Before adding it, the firewall checks that the new policy to be added does not already exist in the policy set (page 239).
Actors	Administrator.
Precondition	The Administrator must have authorization to add rules.
Description	1 After having been authenticated, the Administrator initiates the addition of a new rule.
	2 If the rule does not already exist in the rule set, then it is added.
	3 The firewall acknowledges the addition of the new rule.
Alternate Flow	The rule is not added because it already exists in the rule set.
Postcondition	A new rule is added to the rule set of the firewall.

IMPLEMENTATION

To implement the APPLICATION FIREWALL the designer needs to understand the semantics of the application. The following tasks need to be performed:

Define subjects. These are the active entities, users or roles, who will apply operations to some of the classes in the application model.
Define subjects’ rights and implement them as policies. Apply a need-to-know policy and give users only the rights they need to perform their functions with respect to the application. For example, a manager needs to have the right to create accounts, but not the right to withdraw money from the accounts they create.
Assign individual users to the roles in the application.
Add/remove policies when needed. Users come and go, and their association with specific roles needs to be kept up to date.
Define criteria for logging. Some activities, for example performing transactions, need to be recorded for future audit.

Two architectural configurations are possible: reverse proxy and multiple agents.

REVERSE PROXY

With the reverse proxy implementation, the input flow is intercepted on a single point (Figure 11.5). There is only one policy enforcement point, and all the flow should go through it [Sch06b].

Figure 11.5: Reverse proxy configuration

MULTIPLE AGENTS

With this implementation, several policy enforcement points are distributed on the network, close to the different applications that have to be controlled (Figure 11.6). These enforcement points together intercept every request to the application. It is also possible to control access for requests coming from internal networks.

Figure 11.6: Multiple agents configuration

EXAMPLE RESOLVED

Application firewalls allow separation of the access control code from the application code. This allows reuse of the basic access control code in different applications. For example, in the example discussed at the start of the pattern description, the bulk of the access control code will be common to both medical and scheduling applications.

When application firewalls are used, all accesses to applications (medical or scheduling) have to pass through these firewalls. The application firewall ensures that the users are properly authenticated, and have privileges to the service they are accessing based on configurable policies.

CONSEQUENCES

The APPLICATION FIREWALL pattern offers the following benefits:

The institution’s policies for controlling access are easily defined and administered, as the policies have centralized administration. This makes the whole system less complex, and thus more secure.
The pattern could be combined with an intrusion detection system to facilitate the prevention of some attacks.
The application firewall lends itself to a systematic logging of incoming and outgoing messages.
As authentication of clients is performed, users can be held responsible for their actions.
Different types of users or types of access just require specific rules.
Filtering is separated from application functions. Because of their separation, the application and the filtering policies can evolve independently.

The pattern also has the following potential liabilities:

The application firewall could affect the performance of the protected system, as it is a bottleneck in the network. This can be improved by considering the firewall a virtual concept and using several physical devices in the implementation.
The solution is redundant for existing applications that already implement their own access control.
The application itself must be built in a secure way, or normal service operations could allow attacks through the requests.
We still need the operating system and the network infrastructure to be secure.

KNOWN USES

This pattern is used in several commercial products, such as Cerebit InnerGuard [Cer03] and Netegrity SiteMinder [Net03].
This model is also used as an underlying architecture for the XML FIREWALL pattern (below).
There are also products called application security gateways that incorporate these functions, plus others.

11.3 XML Firewall

The XML FIREWALL pattern allows filtering of XML messages to/from enterprise applications, based on business access control policies and the contents of the message.

CONTEXT

Enterprise applications executing in distributed systems accessed through a local network, from the Internet or from external networks. The applications communicate through XML messages and could be applications using web services. The messages can contain a remote procedure call or a document.

PROBLEM

Some enterprise applications use tunneling into authorized flows (HTTP, SMTP) to communicate with external sites. They use higher-level protocols such as SOAP and communicate through XML documents or XML-wrapped remote procedure calls. The XML content of these messages can contain harmful data and can be used to perform attacks against applications.

Network firewalls provide infrastructure security, but become useless when these high-level protocols and formats are used.

The solution to this problem must resolve the following forces:

Document or remote procedure call formats are subject to change; some new ones may appear (XML dialects). The firewall must adapt easily to these changes.
New types of harmful data may be used by attackers; the firewall must adapt easily to these new types of attacks.
There are many ways to filter; we need to separate the filtering code from the application code.
There may be numerous applications that may require different levels of security.
New applications may be integrated into the system after the firewall has been put into operation. This integration should not require significant additional costs.
Network firewalls cannot understand the contents of XML messages or application semantics, and do not stop potentially harmful messages.

SOLUTION

Use a firewall that intercepts XML messages and can understand their contents. A client can access a service of an application only if a specific policy authorizes it to do so and if the content of the message is considered safe for the application. Policies for each application are centralized in the XML FIREWALL and accessed through a policy authorization point. Each application is accessed by a client through a policy enforcement point that enforces access control for the applications. The authorization decision may include authenticating the client through its identity data stored in the identity base. It also includes looking for a matching policy for the request in the policy base, and checking the contents of the message. First, its structure is validated through a list of valid XML schemas, and the data it conveys is checked through a harmful data detector.

STRUCTURE

Figure 11.7 shows the class diagram for this pattern. Some of the classes are similar to those of Figure 11.2 (page 236). They include an IdentityBase, a collection of the Client identities registered in the system. A PolicyBase stores authorization policies that define the rights of those users. A PolicyAuthorizationPoint collects both identity and authorization information. A PolicyEnforcementPoint performs access control checks. The new classes include the ContentInspector, which checks the content of the XML messages sent from/to the applications.

Figure 11.7: Class diagram for the XML FIREWALL pattern

The ContentInspector consists of a HarmfulDataDetector, an XMLSchemaValidator, an XMLSigner/Verifier and an XMLEncryptor/Decryptor. The HarmfulDataDetector perform checks for harmful data embedded in the content of the message. The XMLSchemaValidator checks the validity of the XML documents sent to the application. The XMLSigner/Verifier and XMLEncryptor/Decryptor respectively sign/verify and encrypt/decrypt XML messages that access the firewall, in accordance with the XML Digital Signature [W3C08] and XML Encryption [W3C02] standards proposed by W3C. These mechanisms are used to guarantee confidentiality, data authenticity and integrity of the XML documents, as well as non-repudiation.

DYNAMICS

Figure 11.8 (page 246) illustrates the dynamic aspects of the XML FIREWALL pattern using a sequence diagram. It corresponds to a use case in which the XML message is encrypted and signed, and whose user needs to be authenticated. A more basic use case would be obtained by removing some of these requests.

Figure 11.8: Sequence diagram for the use case ‘Filtering an encrypted and signed client’s request with user authentication’

Use Case: Filtering an Encrypted and Signed Client’s Request with User Authentication – Figure 11.8


Summary	A Client requests access to a service of an application to either transfer or retrieve information via an XML message. First, the content of the message is checked, so that only harmless messages are given access to the applications. Then, the access request goes through the PolicyEnforcementPoint, which accesses the PolicyAuthorizationPoint to determines whether to accept or deny the request.
Actors	External Client.
Precondition	Existing IdentityBase and PolicyBase classes must be in place in the firewall. The IdentityDatabase contains the data necessary to authenticate a Client. The PolicyDatabase contains specific policies defined by the organization.
	An existing XML schema database contains the XML schemas trusted by the organization.
Description	1 A Client requests access to an Application.
	2 An XMLFirewall, through its ContentInspector, checks the validity of the XML message and decrypts it.
	3 The PolicyEnforcementPoint intercepts the request and relays it to the PolicyAuthorizationPoint.
	4 The PolicyAuthorizationPoint authenticates the Client through its IdentityBase. This step may be avoided for subsequent requests through the use of a Session class.
	5 Once the Client has been authenticated and identified, the PolicyAuthorizationPoint filters the request according to the PolicyBase. The request is accepted or denied according to the defined policies.
	6 The contents of the message is checked. If the message contains harmful data, it is rejected.
	7 The signature of the XML document is verified.
	8 The firewall allows access to the service of the application and the access is logged into the XMLFirewall.
Alternate Flows	If the XML message is invalid, or the XML message contains harmful data, or the Client is not authenticated, or no policy allows the specific Client to access the specified service, the firewall rejects the access request.
	If the user has already been authenticated, the Client may not be authenticated again (single sign-on use).
	If the signature is not verified, the request may be relayed, depending on the existing policies.
Postcondition	The firewall has filtered the access of a Client to a service, based on the content of the message, the authentication of the Client, and the existence of a matching policy.

IMPLEMENTATION

The same architectural structures used for the APPLICATION FIREWALL pattern (page 234) – reverse proxy, multiple agents – can be used to deploy XML FIREWALLs.

CONSEQUENCES

TheXML FIREWALL pattern has the same benefits as the APPLICATION FIREWALL pattern, and the following additional benefit:

It provides a higher level of security than the APPLICATION FIREWALL pattern for inputs which are XML documents or requests.

The pattern also has the following potential liabilities:

The application could affect the performance of the protected system, as it is a bottleneck in the network, and as the XML content checking may create a large overhead. This can be alleviated by using a multiple-agents configuration.
The solution may be redundant or intrusive for existing applications that already implement their own access control or their own filtering.
The application firewall needs to manage the corresponding cryptographic keys necessary to encrypt/decrypt data or verify digital signatures.

KNOWN USES

This model is used in several commercial products, such as Reactivity’s XML Firewall [Rea03], Westbridge’s XML Message Server [Wes03], Netegrity’s Transaction Minder [Net03], DataPower’s Security Gateway [Dat04], Sarvega’s XML Security Gateway [Sar04], Xtradyne’s WS-DBC [Xtr04] and Forum Systems Xwall [For04a].
Web application servers such as IBM’s WebSphere also include similar devices [WeS].

11.4 XACML Authorization

eXtensible Access Control Markup Language (XACML) can be used by an organization to represent authorization rules in a standard manner.

EXAMPLE

Consider a company that provides financial services to its customers. Their computer systems can be accessed by customers who send orders to the company for buying or selling commodities (stocks, bonds, real estate, art) by e-mail or through their website. Brokers employed by the company can carry out the orders of the customers by sending requests to the systems of various financial markets, or by consulting information from financial news websites. Also, a government auditor visits periodically to check for application of laws and regulations.

All these activities are regulated by policies with various granularities within the company. For example, the billing department can have the rule ‘only registered customers whose account status is ok may send orders’, the technical department can decide that ‘e-mails with attachments bigger than x Mb won’t be delivered’, the company security policy can state that ‘only employees with the ‘broker’ role can access the financial markets’ web services’ and that ‘only the broker custodian of a customer can access its transaction information’, whereas the legal department can issue the rule ‘auditors can access all transaction information’, and so on.

All these policies are enforced by different components of the company’s computer system (e-mail server, file system, web service access control component, financial application). This approach has several problems: the policies are described in possibly different syntaxes, and it is difficult to have a global view of what policies apply to a specific case. Moreover, two policies can be conflicting, with no way to combine them in a clear way. In summary, this approach could be error-prone and complex to manage.

CONTEXT

A complex environment such as a large enterprise with many partners, contractors and relations with other enterprises. These various actors access the organization’s resources, comprising web services, sensitive documents or system components.

PROBLEM

An organization’s resources are usually of various types (XML documents, web services, web components, CORBA services). Access to these resources is controlled by distributed enforcement mechanisms, according to the security policies of the institution. Since the resources are of different types, the enforcement mechanisms come in various forms: they can be part of a web server, an application firewall, and so on. Therefore, policies have to be implemented in many locations, using different syntaxes. It is important to define precisely the policies about accessing these resources.

Moreover, security policies in an organization are typically issued by different actors from its departments (human resources, legal, marketing departments), and the policies they write may concern a wide and overlapping set of resources. Defining these policies in such a way that the correct policies can be applied to each access may be complex, and thus error-prone.

How can we unify the definition of access policies throughout the organization, making the whole system simpler and less error-prone? The solution to this problem must resolve the following forces:

The policies are issued by a variety of actors and may be stored in many locations. This means that they may be expressed in different forms.
The policies are constantly changing and need to be constantly updated.
An active entity accessing a resource can be represented in a variety of ways, including certificates.
Some policies can require a set of actions (or obligations) to be performed in conjunction with policy enforcement (auditing, notification).
The environment in which an access is requested can also affect the access decision. For instance, an access may only be permitted at some hours of the day.

SOLUTION

Write all policies in a common language using a standard format. This format is generic enough to implement some common high-level policies or models (open/closed systems, extended access matrix, RBAC, multilevel). In addition, define a way to compose policies so that when several policies apply to one access, it is possible to render one unique decision: the policies have a combining algorithm.

STRUCTURE

Figure 11.9 shows the class diagram of this pattern. A PolicyAdministrationPoint is a rule repository that centralizes the definition of policies throughout the organization. The Subject intending the access, the Resource at which the access is targeted, and the Environment of the access are described through their attributes. The Environment represents the characteristics of an access that are independent of the Subject or Resource. It could include the current date, time or other environmental properties.

Figure 11.9: Class diagram for the XACML AUTHORIZATION pattern

A Rule is a basic unit of policy and has the usual meaning. In the access matrix model, it defines a set of Subjects, Resources (protection objects) and Actions (access types). However, in this pattern, a Rule associates not only one, but a set of Subjects, with a set of Resources and a set of Actions. It also includes a set of Environments to which the rule is intended to apply, a condition and an effect (‘permit’ or ‘deny’ – that is, positive and negative rules). The condition refines the rule by imposing constraints on the Subjects, the Resources or the Environment. The Target of the rule is made up of the sets of Subjects, Resources, Actions and Environments to which the rule is intended to apply. A Target is used for identifying the applicable rules in a given context.

Policies are composed of Rules. When evaluating a Policy, Rules are combined according to the Policy’s ruleCombiningAlgorithm (deny-overrides, permit-overrides, first-applicable, only-one-applicable or a user-defined algorithm).

Policies are structured according to a Composite pattern [Gam94], where a PolicySet is the composite element. Similarly, when evaluating a PolicySet, Policies are combined according to the PolicySet’s policyCombiningAlgorithm. (We could use a Strategy pattern [Gam94] here to have more than one algorithm.) This indicates that policies have a tree structure. Each PolicyComponent may include an obligation that defines an operation that should be performed after enforcing the access decision. For example, an obligation could be an audit operation, or a notification to an external client.

In addition to its rules’ Targets, each PolicyComponent may be associated with a Target. A Target at this level is either specified by the Policy writer, or calculated as the union or the intersection of the Targets of the Rules comprising this Policy.

DYNAMICS

We describe the dynamic aspects of the XACML AUTHORIZATION pattern using a sequence diagram for the use case ‘Create a new policy’.

Use Case: Create a New Policy – Figure 11.10

Figure 11.10: Sequence diagram for the use case ‘Create a new policy’


Summary	A PolicyWriter intends to create a new policy component.
Actors	PolicyWriter.
Precondition	The PolicyWriter must have authorization to create Policies.
Description	1 The PolicyWriter creates as many rules as necessary, specifying the target, the effect and possibly a condition for each rule.
	2 The rules are added to the set of existing rules.
	3 The PolicyWriter creates a Policy by specifying the rules, optionally some obligations and targets, and the ruleCombiningAlgorithm.
	4 The PolicyAdministrationPoint acknowledges the creation of the new Policy.
Postcondition	The new Policy is added to the Policy set of the PolicyAdministrationPoint.

IMPLEMENTATION

The enterprise must have decided to use XACML to provide security for its documents and services. This decision is based on the fact that XACML is a standard and several products support its use. Once this decision is made, we need to:

Define semantics for the subject, the resource and the environment’s attributes for each intended authorization. These attributes can be from existing standards (LDAP attributes, SAML and so on) and are extensible.
Translate existing rules into the XACML format.
Define new rules and implement them as XACML rules and policies.
Add/remove policies when needed.

For example, we can have rules describing authorization for individual users, roles or any relevant active entity. A complete example of use is given in [Ver04].

EXAMPLE RESOLVED

The use of XACML authorization rules makes it possible for the company to centralize a wide range of policies and rules. Those can be easily managed, and the conflicts can be resolved by using algorithms that combine rights when evaluating an access request.

CONSEQUENCES

The XACML AUTHORIZATION pattern offers the following benefits:

The organization’s policies to control access are easily defined using the constructs of the language. This makes the whole system less complex, and thus more secure.
A variety of policy types can be described, as the policy language includes the resource, the subject and the environment’s attributes.
Similarly, a variety of subject types can be described.
Policies and rules can be combined easily.
A policy writer can specify complex conditions.
The pattern enables logging or other actions by means of obligations.

The pattern also has the following potential liability:

The structure of a policy is complex. It is verbose even for simple rules, and may require increased processing time to evaluate a request.

KNOWN USES

This pattern is used in several commercial products, such as Xtradyne’s WS-DBC (an XML firewall) [Xtr04] and DataPower’s XS40 XML Security Gateway [Dat04].
Parthenon Computing produced a suite of policy products based on XACML (Policy Tester, Policy Engine, Policy Server) [Par05].
Sun provides an open source implementation written in Java [Sun04b].

11.5 XACML Access Control Evaluation

The XACML ACCESS CONTROL EVALUATION pattern describes how to decide whether a request is authorized to access a resource according to policies defined by the XACML AUTHORIZATION pattern.

EXAMPLE

Consider the same financial company as was discussed in the XACML AUTHORIZATION pattern. Its policies and rules are enforced by different components of its computer system: by the e-mail server, file system, web service access control component and financial applications. It requires much time and money to administer access control for those different systems.

CONTEXT

A complex environment such as a large enterprise with many partners, contractors and relations with other enterprises. These various actors access the organization’s resources, comprising web services, sensitive documents or system components. These accesses are controlled at several enforcement points, according to security policies.

PROBLEM

An organization’s resources are usually of various types. Accesses to these resources are controlled by distributed enforcement mechanisms, according to its security policies. Since the resources are of different types, the enforcement mechanisms come in various forms: they can be a part of a web server, an application firewall, and so on. Therefore, the organization has to set up and maintain numerous authorization systems for its networks.

How can we enforce the rules defined in the institution policies? The solution to this problem must resolve the following forces:

Enforcement points could be implemented in a variety of systems (part of a web server, in a WAN and so on).
Any type of security policy should be enforceable.
Enforcement may require reading system or environment variables.

SOLUTION

Protect resources by policy enforcement points. All access requests to a policy enforcement points are evaluated by submitting them to a unique policy decision point in a common format. This policy decision point returns the access decision, based on the applicable policy corresponding to the access context. The policy information point provides attributes from the subject.

STRUCTURE

Figure 11.11 shows the class diagram of the XACML ACCESS CONTROL EVALUATION pattern. A Subject can access a Resource in the current environment only if an XACMLAccessResponse authorizes it to do so. The Subject, Resource and environment are described through their attributes. The specific aspect of this pattern is that an access is realized through three entities, the Subject, the Resource and the environment, instead of just the Subject and the Resource. This enables a full description of the characteristics of an access to be evaluated.

Figure 11.11: Class diagram for the XACML ACCESS CONTROL EVALUATION pattern

The PolicyEnforcementPoint requests an access decision from the PolicyDecisionPoint through a ContextHandler, which is an adapter between any specific enforcement mechanism and the XACML PolicyDecisionPoint. The PolicyDecisionPoint is responsible for deciding whether or not an access should be permitted, by locating the ApplicablePolicySet, the set of policies that is applicable to the particular access attempt applying it to the XACMLAccessRequest, and issuing a corresponding XACMLAccessResponse.

The ContextHandler can also get additional attributes from a PolicyInformationPoint, which is responsible for obtaining attributes from the subject.

DYNAMICS

We describe the dynamic aspects of the XACML ACCESS CONTROL EVALUATION pattern using a sequence diagram for the use case ‘Control an access request to a resource’.

Use Case: Control an Access Request to a Resource – Figure 11.12

Figure 11.12: Sequence diagram for the use case ‘Control an access request to a resource’


Summary	A Subject requests access to a Resource. The access request is made through its PolicyEnforcementPoint, which in turn accesses the PolicyDecisionPoint through its ContextHanlder, in order to determine whether to accept or deny the request (page 258).
Actors	A Subject.
Precondition	An existing PolicyAdministrationPoint must be accessible by the PolicyDecisionPoint. It contains policies defined by the organization.
Description	1 A Subject sends a request for access to a Resource to its PolicyEnforcementPoint.
	2 The PolicyEnforcementPoint sends the request to the ContextHandler in its native format.
	3 The ContextHandler sends a corresponding XACML request to the PolicyDecisionPoint.
	4 The PolicyDecisionPoint retrieves the ApplicablePolicy for this XACML request from the PolicyAdministrationPoint.
	5 The PolicyDecisionPoint may request additional attributes from the ContextHandler.
	6 The ContextHandler obtains the attributes from a PolicyInformationPoint and returns them to the PolicyDecisionPoint.
	7 The PolicyDecisionPoint evaluates the ApplicablePolicy corresponding to the XACML request and returns an XACML response to the ContextHandler, or sends a request to the PolicyInforcementPoint if the attributes are insufficient to make a decision.
	8 The ContextHandler translates the response into the native response format of the PolicyEnforcementPoint.
	9 The PolicyEnforcementPoint fulfills the obligations contained in the response.
	10 If the access is permitted, the PolicyEnforcementPoint allows the Subject to access the Resource.
Alternate Flows	If the XACMLAccessResponse’s decision is ‘deny’, the PolicyEnforcementPoint denies access to the Resource.
	If the XACMLAccessResponse’s decision is ‘indeterminate’ or ‘not applicable’, the decision has to be made by the PolicyEnforcementPoint.
Postcondition	Access control to a resource has been realized, based on the Subject’s attributes, the Resource’s attributes, the environment’s attributes and an applicable policy.

Appendix A includes pseudo-code for the functions retrieveApplicablePolicy() and evaluateApplicablePolicy().

IMPLEMENTATION

To implement the XACML ACCESS CONTROL EVALUATION pattern, the following tasks need to be performed:

Implement a ContextHandler for applications that already have a PolicyEnforcementPoint but which use another access decision language.
Implement an XACML PolicyEnforcementPoint for those applications that do not implement access control.
Add the translated existing authorization rules to the PolicyAdministrationPoint.
Add the new authorization rules to the PolicyAdministrationPoint.

EXAMPLE RESOLVED

The use of the XACML ACCESS CONTROL EVALUATION pattern allows the company to centralize the decisions of accesses to resources in the company. Consequently, applications no longer not need to care about access control decisions. Every access request or response is in the XACML format.

CONSEQUENCES

The XACML ACCESS CONTROL EVALUATION pattern offers the following benefits:

Since access decisions are requested in a standard format, an access decision becomes independent of its enforcement. A broad variety of enforcement mechanisms can be supported and can evolve separately from the policy decision point.
The pattern can support the access matrix, RBAC or multilevel models for access control.

The pattern also has the following potential liabilities:

It is intrusive for existing applications that already have security, since they require the implementation of a context handler.
It could affect the performance of the protected system, since XML is a verbose language.

KNOWN USES

This pattern is used in the commercial products listed on page 254 for the XACML AUTHORIZATION pattern.

11.6 Web Services Policy Language

The WEB SERVICES POLICY LANGUAGE (WSPL) pattern describes how to represent access control policies for an organization’s web services in a standard manner, and to enable a web services consumer to express their requirements in a standard manner.

EXAMPLE

Our company has a variety of web services for different purposes. Applications incorporate them as part of their structure. Application users pay for the use of these web services. If we want to make any money, we need to control access to them.

CONTEXT

Applications that use web services. Providers have security policies to control access to their web services, consumers have requirements for a web service invocation.

PROBLEM

Web services are services that are accessible by means of messages sent using standard web protocols, notations and naming conventions [Pap03]. In addition, they are self-describing through Web Services Description Language (WSDL) and can be discovered (perhaps automatically) using Universal Description, Discovery and Integration (UDDI). Therefore, using different syntaxes for their policy descriptions would reduce the two properties of self-description and discoverability.

Moreover, security policies are typically issued by different actors in different departments, and the policies they write may concern a wide and overlapping set of web services. Applying the right policies to each access to a web service may also be complex, and thus error-prone.

How can we describe policies to control web services invocations? The solution to this problem must resolve the following forces:

The policies are issued by a variety of actors in an organization and may be stored in many locations.
Web services consumers can also issue policies (requirements). For example, a consumer could require a service to have a certificate from a well-known certification authority.
Any type of security policy should be enforceable.
The policies are constantly changing and need to be constantly updated.
We have a variety of subjects (roles).
The environment in which an access is requested can also affect an access decision.
Some policies can require a set of obligations to be performed in conjunction with policy enforcement (auditing).

SOLUTION

WSPL binds each WSDL web service component to an XACML component. In addition, define combination rules for such policies.

STRUCTURE

Figure 11.13 shows the class diagram for this pattern. Each WSDL web service component – Endpoint (port), Message and Operation – involves several Aspects, such as reliable messaging, privacy, authorization, trust, authentication or cryptographic security.

Figure 11.13: Class diagram for the WEB SERVICES POLICY LANGUAGE pattern

Each of the web service components respectively corresponds to an EndpointPolicy, MessagePolicy and OperationPolicy and are described by XACML PolicySets.

An EndpointPolicy, MessagePolicy or OperationPolicy consists of Objectives that govern an aspect of the web service components. All Objectives must be achieved by the service invocation. An Objective is defined by an XACML Policy.

Each Objective consists of a set of ordered Strategies. At least one Strategy must be achieved for its Objective to be achieved. This ordering may enable functions such as policy or trust negotiation. Strategies are represented by XACML Rules.

An XACML attribute is refined, as an unconstrained attribute can have its value assigned by the policy user, whereas a constrained attribute cannot. An authorized attribute must have its value assigned by an authority.

IMPLEMENTATION

A detailed discussion of some implementation aspects can be found in [And04].

EXAMPLE RESOLVED

Using WSPL, we can define precise rules about who can access which resources and in what way. We can then provide security to our users and prevent users who have not paid for using our services from accessing them.

CONSEQUENCES

In addition to the benefits of the XACML AUTHORIZATION pattern (page 248), the WEB SERVICES POLICY LANGUAGE pattern presents the following benefit:

Consumers’ and providers’ policies can be combined to decide how a service invocation should occur.

The pattern also has the following potential liabilities:

It is intrusive for existing web services that already implement security, since they require the implementation of a context handler.
It could affect the performance of the protected system, as XML is a verbose language.

KNOWN USES

OpenWSPL is an open source Java implementation of the Web Service Policy Language [WSPL].

11.7 WS-Policy

The WS-POLICY pattern describes how to define a base set of assertions that can be used and extended by other web services specifications to describe a broad range of service requirements and capabilities, including security, reliability and others. This pattern also provides a way to check the requests made by requesters in order to verify that they satisfy their assertions and their conditions before interacting with a web service.

EXAMPLE

Ajiad is a travel agency that intends to provide online services to its customers. Ajiad now offers many of its everyday operations as a web services-based system. In the current situation, some of Ajiad’s customers have been accessing web services they are not allowed to access, as some outdated and insecure services do not have systematic guidelines to control their use. Also, some of the services are not available when needed. As a result, Ajiad is losing money because of its reliability and security problems.

CONTEXT

Distributed applications need to communicate in a collaborative way to perform work in a web services environment. For this objective, they use the Internet, which is an unreliable and insecure environment.

PROBLEM

In order to assure reliability, availability and security, web services need to apply policies. Without them, they will have no means of specifying what quality factors they enforce and require from their users. This situation would result in all kinds of problems for the institution and its users.

The solution to this problem must resolve the following forces:

Data security of web services. Malicious users may try to read or modify sensitive information stored in a web service. We need to define appropriate policies to protect this information.
Guaranteed message exchange. We need to assure the delivery of messages between partners and give a requester the ability to verify whether the message was delivered.
Policy integrity. Malicious users may try to replace or remove policy assertions for their own benefit. We need to ensure that policy assertions have not been modified.
Mutual authentication. Clients and services must be able to mutually authenticate.
Denial of service. An attacker could try to use malformed assertions to produce a non-terminating loop of policy evaluations.

SOLUTION

Policies can be defined for security, reliability or other business constraints. For example, web services can be protected against unauthorized access by having policies that provide conditions that must be met for the service to be accessible. Requesters wishing to use protected web services are required to comply with these policies. Each policy is defined in terms of nested assertions that describe the restrictions implied by the policy. When the policy is attached to a web service, clients wanting to transact with that web service must comply with its assertions (for example, signing, encryption, timestamp and username) as specified in the policy.

In general, any entity in a web services-based system may expose a policy to convey conditions under which it provides service. Satisfying assertions in the policy usually results in behavior that reflects these conditions. For example, if two entities – requester and provider – expose their policies, a requester might use the policy of the provider to decide whether or not to use the service. A requester may choose either policy – requester or provider, since each is a valid configuration for interaction with the service – but only one of them.

STRUCTURE

Figure 11.14 shows the class diagram for this pattern. A Policy is a collection of policy alternatives that has its own name, reference (accessed from other subjects) and ID. A policy with zero alternatives contains no choices; a policy with one or more alternatives indicates choice in requirements or capabilities within the policy. A PolicyAlternative is a collection of policy assertions. Alternatives and assertions are not necessarily ordered.

Figure 11.14: Class diagram for the WS-POLICY pattern

A PolicyAssertion represents a capability, a constraint or a requirement of the behavior of a web service (for example, a guarantee of message delivery). Or it could be defined as a declaration of facts, such as ‘Jad was granted update privileges to database X at time Y’. We can alternatively define a PolicyAssertion to be a set of requirements. For example, a PolicyAssertion might specify the security token types that are used to digitally sign or encrypt SOAP messages between the client and web service.

A PolicyAssertion identifies behaviors that are requirements for an entity (for example human, computer, message, an endpoint, interaction, resource). Satisfying assertions in the policy usually results in behavior that reflects these conditions. A PolicyAssertion has two parameters, used to define the behavior indicated by the assertion: attributes and children. A PolicyAssertionType represents a class of policy assertions to indicate domain-specific semantics (for example security, transactions). A PolicyAssertion may refer to another policy.

The formal term for a policy is policy expression, and we use it to convey a policy in an interoperable form. In other words, a PolicyExpression is a set of one or more policy assertions that, combined together, will perform a specific task. It could be interpreted also as a form (document) that is either structured in a normal or a compact form to express a policy.

A PolicyAttachment is a mechanism for associating a policy with one or more entities, such as web services. It details how policies are attached to bindings, and is essentially the glue that enforces a web service to adhere to a policy. A PolicySubject is an entity with which a policy can be associated, while a PolicyScope is composed of a collection of PolicySubjects to which a policy applies.

DYNAMICS

We describe two of the most important use cases, ‘Create a policy for a web service’ and ‘Request a service’.

Use Case: Create a Policy for a Web Service – Figure 11.15

Figure 11.15: Sequence diagram for the use case ‘Create a policy for a web service’


Summary	A Provider creates a new Policy for an existing web service.
Actors	Policy Provider.
Precondition	The Provider has already created a WebService.
Description	1 The policy Provider creates the policy by specifying its required alternatives, assertions and requirements. The Provider creates as many assertions as necessary to meet the conditions for the WebService.
	2 All the alternatives, assertions and requirements are added to the created Policy.
	3 The Provider sends a request to the PolicyAttachment to associate the Policy with the end entity (WebService).
	4 The PolicyAttachment attaches the Policy to the WebService, which in turn updates its content, adds the Policy and acknowledges the PolicyAttachment.
	5 A reply from the PolicyAttachment informs the Provider that the attachment process is completed.
Postcondition	The Provider has attached the policy to its designated WebService.

Use Case: Request a Service – Figure 11.16

Figure 11.16: Sequence diagram for the use case ‘Request a service’


Summary	A Requester requests the use of a WebService that has an existing policy.
Actors	Requester.
Precondition	A Provider had already created a WebService with a policy that controls its services.
Description	1 The Requester sends a request to use the WebService.
	2 The WebService forwards the request to the PolicyAttachment.
	3 The WebService applies its policies for verification of assertions and alternatives.
	4 The WebService shows its PolicyAlternatives to the Requester.
	5 The Requester selects from the alternatives, satisfies the chosen alternative’s assertions, and sends a request to be verified against the policy.
	6 The WebService checks all possibilities that result and approves or denies.
	7 The PolicyAttachment responds to the WebService, which in turn forward it to the Requester.
Postcondition	The Requester can now use the WebService after satisfying its policy conditions.

IMPLEMENTATION

In order to ensure effective implementation, we need to take in consideration the following:

A policy may or may not reference another policy(ies), depending on the level of authentication that is required.
A policy alternative may contain multiple assertions of the same type. Policy assertions within a policy alternative are not ordered. However, providers can write assertions that control the order in which behaviors are applied.
Policy assertions are the main blocks of the policy that specify a particular behavior. For example, the AsymmetricBinding assertion is intended to support a specific reliable messaging mechanism, while the SignedParts assertion is used to indicate message-level security, and the EncryptedParts assertion is used to indicate the parts of a message that require confidentiality.
A policy expression conveys policy in an interoperable form, either in a normal form, the most straightforward XML representation of the policy data model, or in an equivalent compact form, used to compactly express a policy with more description about definitions and outlines.
A PolicyExpression should not refer to itself directly or indirectly, because in that case its resolution may be ambiguous.

The example on page 270 defines a policy (starting with a <wsp:Policy> tag and ending with a </wsp:Policy> tag) for a web service offered by the Ajiad travel agency. This policy will accept X.509 certificates and Keberos tokens, with X.509 certificates preferred. The web service also requires the UTF-8 character encoding, any form of the English language, and specifies the SOAP version. Finally, the policy suggests using the AES algorithm for encryption.

EXAMPLE RESOLVED

Ajiad’s web-based system has decided to use the WS-POLICY pattern to convey conditions on the interactions between entities (provider, broker, requester and so on). This was supported by the fact that WS-POLICY is a standard and several products support its use.

Ajiad defined systematic rules to specify the way in which its web services should be accessed, in terms of who, when and in what way, as well as conditions. Ajiad’s new web-based system now has more control over its services, by applying prerequisite conditions and security constraints through policies. So, in order to use any service, all customers are required to comply with its policy conditions and satisfy its requirements (for example, by using the required security token types specified by the policy) and agree with its terms before using the web service.

<wsp:Policy xml:base=“http://ajiad.com/policies” wsu:Id=“AJIADPOLICY”>
<!– This web service has the policy of accepting X.509 certifcates and Kerberos, With X.509 certificates preferred–>
  <wsp:ExactlyOne>
  <wsse:SecurityToken TokenType=“wsse:x509v3”
  wsp:Usage=“wsp:Required” wsp:Preference=“50”>
  </wsse:SecurityToken>

  <wsse:SecurityToken TokenType=“wsse:Kerberosv5TGT”
  wsp:Usage=“wsp:Required” wsp:Preference=“10”>
  </wsse:SecurityToken>
  </wsp:ExactlyOne>

<!– The web service requires the UTF-8 character encoding, any form of the English language, and SOAP version 1.1 –>
  <wsp:All>
  <wsp:TextEncoding wsp:Usage=“wsp:Required” Encoding=“utf-8”/>
  <wsp:Language wsp:Usage=“wsp:Required” Language=“en”/>
  <wsp:SpecVersion wsp:Usage=“wsp:Required” URI=“http://www.w3.org/TR/2000/NOTE-SOAP-20000508/” />

<!– Using AES algorithm is required –>
  <wsse:Integrity wsp:Usage=“wsp:Required”>
  <wsse:Algorithm Type=“wsse:AlgSignature” URI=“http://www.w3.org/2000/09/xmlenc#aes” />
  </wsse:Integrity>
  </wsp:All>

</wsp:Policy>

CONSEQUENCES

The WS-POLICY pattern offers the following benefits:

Data security of web services. It is possible to secure the data of web services, since we can use policies from other web services standards such as WS-Security [IBM04], XML Digital Signature [W3C08] and WS-Metadata Exchange [W3C09].
Policy protection. It is possible to define policies to protect the policies themselves.
Guaranteed message exchange. The pattern offers a way to assure messages exchange between the partners, by giving policy providers the ability to avoid older or weaker policy alternatives, and by giving the requester the ability to verify the policy provider.
Policy integrity. Using the appropriate signing mechanism will protect the policy assertions from tampering: for example, requesters can discard a policy that is not signed by the provider, or when not presented with sufficient credentials.
Availability. The pattern mitigates the chance of denial of service threats by forcing the policy implementers to use a model with defaults for the policy alternatives, the number of assertions in an alternative and the depth of nested policy expressions.

The pattern also has the following potential liabilities:

WS-Policy is an immature specification that is still changing.
The WS-Policy standard is a lengthy document with a lot of detail, some of which we left out to avoid making the pattern too complex. For more details, check the WS-Policy Standard web page [W3C07].

KNOWN USES

HP SOA Systinet Standard Edition is a platform for SOA Governance. This SOA architecture tool provides different levels of governance [HP09].
The Layer 7 SecureSpan XML Virtual Appliance provides security and threat protection for internal and cloud-based XML and web services applications [VMW09].
Xtradyne’s WS-DBC is an XML/SOAP firewall that claims to be specifically designed for use in environments that demand performance, scalability, availability and policy management [Pri05].
DataPower’s XS40 XML Security Gateway is a network appliance that operates as an XML proxy. It provides security functions for XML-based communications [IBM05].

11.8 WS-Trust

The WS-TRUST pattern describes how to define a security token service and a trust engine that are used by web services to authenticate other web services. Using the functions defined in this pattern, applications can engage in secure communication after establishing trust.

EXAMPLE

The Ajiad travel agency offers its travel services through several different business portals to provide travel tickets, hotel and car rental services to its customers. Ajiad needs to establish trust relationships with its partners through these portals.

Ajiad supports different business relationships and needs to be able to determine which travel services to invoke for which customer. Without a well-defined structure, Ajiad will not be able to know if a partner is trusted or not, or be able to automate the trust relationships quickly and securely with its partners, which may lead to missing a key business goal: offering integrated travel services as a part of the customer’s portal environment.

CONTEXT

Distributed applications need to establish secure and trusted relationships between themselves to perform work in a web-service environment that may be unreliable and/or insecure, such as the Internet. The concept of ‘trusting A’ mainly means ‘considering true the assertions made by A’, which does not necessarily correspond to the intuitive idea of trust in its colloquial use.

PROBLEM

Establishing security relationships is fundamental for the interoperation of distributed systems. Without applying relevant trust relationships expressed in the same way between the involved parties, web services have no means of assuring security and interoperability in their integration. How can we define a means by which the parties are able to trust each other’s security credentials?

The solution to this problem must resolve the following forces:

Knowledge. In human relationships, we are concerned with first knowing a person before we trust them. That attitude applies also to web services. We need to have a structure that encapsulates some knowledge about the unit we intend to trust.
Policy consideration. The web service policy contains all the required assertions and conditions that should be met to use that web service. The trust structure should consider this policy for verification purposes.
Confidentiality and integrity. Policies may include sensitive information. Malicious consumers may acquire sensitive information, fingerprint the service and infer service vulnerabilities. This implies that the policy itself should be protected.
Message integrity. The data to be transferred between the partners through messages may be private data that needs to be protected. Attackers may try to modify or replace these messages.
Time validity. For protection purposes, any interactions or means of communications (including the trust relationships) between the web services should have a time limit that determines for how long the trust relationship is valid.

SOLUTION

We define explicitly an artifact (a security token) that implies trust. This artifact implies the kinds of assertions that are required to make trustworthy interactions between the web services involved. We should verify the claims and information sent by the requester in order to obtain the required security token that becomes a proof that is sufficient to establish a trust relationship with its target partners.

STRUCTURE

Figure 11.17 shows the class diagram for this pattern. A Claim is a statement made about the attributes of a client, service or other resource (for example name, identity, key, group, privilege, capability and so on). Claims are assertions, for example ‘I am Joman’, ‘I am an authenticated user and I am authorized to print on printer P’. Claims are used to validate the requests made by a sender and need to be verified. A SecurityToken is a collection of Claims. It is possible to add signatures to tokens. SecurityToken also is a generalization of two classes: SignedSecurityToken, which is cryptographically endorsed by a specific authority (for example an X.509 certificate or a Kerberos ticket), and ProofofPossession (PoP), a token that contains a secret data parameter that can be used to prove authorized use of an associated security token, and which provides the function of adding a digital signature. Usually, the proof-of-possession information is encrypted with a key known only to the recipient of the PoP token.

Figure 11.17: Class diagram for the WS-TRUST pattern

The SecurityTokenService (STS) is a web service that issues security tokens. It makes decisions based on evidence that it trusts. The STS is responsible for:

Generating security tokens.
Providing challenges for the requester to ensure message freshness (the message has not been replayed and is currently valid).
Verification of authorized use of a security token.
Establishing, extending and removing trust in a domain of services.

The STS is the heart of WS-TRUST and forms the basis of trust brokering. The main output of the STS is a trust relationship between the requester and the receiver, expressed as a security token. This represents the characteristic that one entity is willing to rely upon a second entity to execute a set of actions and/or to make set of assertions about a set of subjects and/or scopes in a secure, reliable and time-relevant manner.

Each STS has a TrustEngine that evaluates the security-related aspects of a message using security mechanisms, and includes policies to verify the requester’s assertions. The TrustEngine is responsible for verifying security tokens and verifying claims against Policies. A Policy is a collection of policy assertions that have their own name, references and ID. Policies form the basic conditions for establishing a trust relationship. Verifying the requester’s claims against policy assertions generates an approval to use the target service. A Policy may reference another Policy or Policies to check the tokens sent by the requester or verified by the Receiver.

DYNAMICS

We describe the dynamic aspects of the WS-TRUST pattern using sequence diagrams for the use cases ‘Create security token’ and ‘Access a resource using a token’.

Use Case: Create a Security Token – Figure 11.18

Figure 11.18: Sequence diagram for the use case ‘Create a security token’


Summary	STS creates a security token using the claims provided by the Requester.
Actors	A Requester.
Precondition	The STS has the required policy to verify the Requester’s claims, and the Requester provides parameters in the form of claims and RequestType signed by a signature.
Description	1 The Requester requests a security token by sending the required claims and RequestType signed by a signature to the STS. The signature verifies that the request is legitimate.
	2 The STS contacts the TrustEngine to check the Requester’s claims.
	3 The TrustEngine contacts the web service’s Policy to verify the claims, including attributes and security token issuers of the requester.
	4 Once approved, the STS creates a SecurityToken containing the requested claims.
	5 The STS sends back its securityTokenResponse with a SecurityToken issued for the Requester.
Postcondition	The Requester has a security token that can be used to access resources in a trusted unit.

Use Case: Access a Resource using a Token – Figure 11.19

Figure 11.19: Sequence diagram for the use case ‘Access a resource using a token’


Summary	An STS allows the use of resources by establishing trust by verifying ProofofClaims sent by the Requester.
Actors:	A Requester.
Precondition	The TrustEngine has the required Policy to verify the Requester’s security token.
Description	1 The Requester asks for a service access by providing the required security token.
	2 The Receiver sends the security token to the STS for verification.
	3 The STS use its TrustEngine to verify the security token claims.
	4 Once approved, the STS notifies the Receiver that the security token is valid and verified.
	5 The Receiver gives the Requester a token that implies the right to use the service.
Postcondition	The Requester has a security token that can be used to access services in a Receiver web service.

IMPLEMENTATION

In this solution, the concept of trust is realized by obtaining a security token from the web service (the SecurityTokenService in Figure 11.17 on page 274) and submitting it to the Receiver, which in turn validates the security token through the same web service. Upon approval, the Receiver establishes a valid trust relationship with the Requester that lasts as long as the security token is valid.

In order to assure effective implementation, we need to take in consideration the following:

To communicate trust, a service requires proof, such as a signature to prove knowledge of a security token or set of security tokens. A service itself can generate tokens, or it can rely on a separate STS to issue a security token with its own trust statement.
Although the messages exchanged between the involved entities are protected by WS-SECURITY (page 330), three issues related to security tokens are possible: security token format incompatibility, security token trust and namespace differences. The WS-TRUST pattern addresses these issues by defining a request/response protocol (in which the client sends a RequestSecurityToken and receives a Request-SecurityTokenResponse) and introducing a SecurityTokenService (STS), which is another web service.
Based on the credential provided by the Requester, there are different aspects of requesting a security token, each of which has a unique format that the requester should follow:
The issuing process: formed as RequestSecurityToken (RequestType, Claims). This is our use case ‘Create a security token’ in the Dynamics section.
The renewal process: formed as RequestSecurityToken (RequestType, RenewTarget).
The cancel process: formed as RequestSecurityToken (RequestType, CancelTarget). The cancelled token is no longer valid for authentication and authorization.
The validate process: formed as RequestSecurityToken (RequestType, ValidateTarget).

[Bha04] proves security properties of combinations of WS-TRUST and WS-Secure conversation to implement secure sessions.

The WS-Trust specification was created as part of the Global XML Web Services Architecture (GXA) framework, which is a protocol framework designed to provide a consistent model for building infrastructure-level protocols for web services and applications [Box02]. It was authored by Microsoft, IBM, Verisign and RSA Security, and was approved by OASIS as a standard in March 2007.

EXAMPLE RESOLVED

Ajiad now has the ability to automate its trust relationships with its partners, by managing the registration tasks for all its partners and issuing customers a unique ID. In this case, Ajiad acts as a mediator between the customers and its participating partners, playing the role of a negotiator and third-party player who is trying to satisfy both sides.

Ajiad now can offer a security token service for its business partners, who may find useful ways to take advantage of its credit processing and other services, giving Ajiad new business opportunities.

CONSEQUENCES

The WS-TRUST pattern offers the following benefits:

Security. By extending the WS-SECURITY mechanisms, we can handle security issues such as security tokens (the possibility of a token substitution attack), and signing (where all private elements should be included in the scope of the signature and the signature must include a timestamp).
Trust. With this solution, we have the choice of implementing the WS-Policy framework to support trust partners by expressing and exchanging their statements of trust. The description of this expected behavior within the security space can also be expressed as a trust policy.
Confidentiality. We can achieve confidentiality of users’ information. Since policy providers now can use mechanisms provided by other web services specifications such as WS-SECURITY (page 330) [ibm09b] to secure access to the policy, XML Digital Signature [W3C08] to authenticate sensitive information, and WS-Metadata Exchange [W3C09].
All the security tokens exchanged between the involved parties are signed and stamped with unique keys that are known only to the recipients.
Time validity. We can specify time constraints in the parameters of a security token issued by STS. This constraint will specify for how long that security token is valid. Upon expiring, the security token’s holder may renew or cancel it.

The pattern also has the following potential liabilities:

The efficiency of WS-TRUST may suffer from the repeated round-trips for multiple token requests. We need to make an effort to reduce the number of messages exchanged.
The WS-Trust Standard is a lengthy document and several details were left out to avoid making the pattern too complex. Interested readers can find more details via the WS-Trust Standard web page [OAS09].

KNOWN USES

DataPower’s XS40 XML Security Gateway [Dat05] is a device for securing web services that provides web services access control, message filtering and field-level encryption. It centralizes policy enforcement, supporting standards such as WS-Security, WS-Trust, WS-Policy and XACML.
SecureSpan XML Firewall [lay09] enforces WS* and WS-I standards to centralize security and access requirements in policies that can be run as a shared service in front of applications.
Vordel Security Token Service [Vor09] is used to issue security tokens and to convert security tokens from one format to another. The security tokens created by an STS are bound to the messages travelling between web services.
PingTrust, a standalone WS-Trust security token server [pin06] creates and validates security tokens that are bound into SOAP messages according to the Web Services Security (WSS) standard.

11.9 SAML Assertion

The SAML ASSERTION pattern describes how to provide a way to communicate security information about a particular subject between different security domains.

CONTEXT

One or several security domains in a distributed system, typically using web services. A security domain is a set of resources (web services, applications, CORBA services and so on) in which the administration of security is performed by a unique entity, which typically stores identity information about the subjects of the domain. Those subjects can perform actions inside or outside their security domain.

PROBLEM

A subject may need to access a resource in a domain that does not know about it because the relevant user is from a different security domain. In order to apply access control to the target domain’s resources, security information about the subject should be transmitted between those two domains.

How can we communicate this information? The solution to this problem must resolve the following forces:

The target security domain may implement different levels of security functionalities (authentication or not, access control or not).
The identity management unit of the subject’s domain and the target security domain may be implemented using different platforms. We need a platform-independent way of communicating identity information.
Different domains may express security constraints or apply authentication in different ways. We need a unifying structure.

SOLUTION

Define an identity management unit in the subject’s domain that issues assertions about subjects in that domain. A SAML assertion is a collection of security-related statements about the subject. It is defined in a common XML format, so that the semantics of the assertions can be extended easily. The target security domain uses the security-related information contained in the assertion to make its access control decisions. A trust relationship must have previously been developed between the identity management unit of the subject’s domain and the target security domain.

STRUCTURE

Figure 11.20 shows a class diagram for this pattern. SAMLAssertions are issued by the identity management entity of the source domain, the SAMLAuthority. The TargetSecurityDomains use the security information in the SAMLAssertions to compute an access decision. The SAMLAssertion consists of Statements about the subject. A Statement is a basic piece of security-related information about the subject, such as an attribute, the fact that they have been authenticated, or a capability. It also comprises the identity of the SAMLAuthority that issued it, and a possible set of conditions, advice and an XML digital signature for integrity and authenticity purposes.

Figure 11.20: Class diagram for the SAML ASSERTION pattern

DYNAMICS

We describe the dynamic aspects of the SAML ASSERTION pattern using the sequence diagram for the use case ‘Subject accesses a resource in the target security domain’.

Use Case: Subject Accesses a Resource in the Target Security Domain – Figure 11.21

Figure 11.21: Sequence diagram for use case ‘Subject accesses a resource in the target security domain’


Summary	A Subject requests a SAMLAssertion from a SAMLAuthority and forwards it to the TargetSecurityDomain. The TargetSecurityDomain uses the security information contained in the SAMLAssertion to compute an access decision.
Actors	Subject, SAMLAuthority, TargetSecurityDomain.
Precondition	The Subject has been previously registered with the SAMLAuthority. A trust relationship exists between the SAMLAuthority and the TargetSecurityDomain.
Description	1 A Subject sends a request for a SAMLAssertion to the SAMLAuthority.
	2 The SAMLAuthority creates a SAMLAssertion based on the Subject’s credentials, inserts in it statements about the Subject, and sends it to the Subject.
	3 The Subject requests access to a Resource and includes the SAMLAssertion.
	4 The TargetSecurityDomain computes an access decision based on the security information contained in the SAMLAssertion.
	5 If access is granted, the TargetSecurityDomain sends back a response corresponding to the request, and the Subject accesses the Resource.
Postcondition	The access to the TargetSecurityDomain has been controlled based on the security information contained in the SAMLAssertion.

CONSEQUENCES

The SAML ASSERTION pattern offers the following benefits:

Identity information can be exchanged between domains implemented on different platforms.
The target application or domain can implement various levels of security controls.
The security constraints or authentication methods are expressed using a common language.

The pattern also has the following potential liabilities:

A prior trust relationship must exist between the SAML authority and the target security domain. This relationship will allow the target security domain to verify the origin and integrity of the assertion.
Possible identity misuse by the SAML authority.

VARIANTS

This pattern has three variants, depending on the type of statement in the assertion:

Attribute-based SAML assertion. Because the subject and the resource accessed may be from different domains, only a fraction of the identity of the user may be useful to the target domain. This variant provides a common format for communicating attribute-based identity information, such as a role or membership, between different security domains. The SAML assertion states that a subject is associated with a set of pairs of attribute names/attribute values. In that case, the target domain has its own access control functionalities. It should base its authorization decision on the value of these attributes.

This variant has an additional advantage: the use of attributes provides a way to represent a broad range of identity-related information types.

Authentication SAML assertion provides a common format for communicating authentication information between different security domains. In this case, the target domain has its own access control functionalities. The SAML assertion states that a subject was authenticated by a particular means at a particular time.
Authorization SAML assertion provides a common format for communicating authorization information between different security domains. The target application or target domain may not have its own access control functionalities. The SAML assertion states that a request to allow the subject to access the specified resource has been granted or denied. The target domain just needs to apply the decision contained in the assertion.

This pattern variant offers an additional advantage: the target application does not need to implement access control functionalities. But it has an additional liability: the security of the scheme relies on the trust granted to the identity manager of the source domain.

KNOWN USES

The Liberty Alliance Identity Framework [Libb] uses SAML as a foundation for protecting the security of identity information.
Several vendors use SAML in their access management products, for example IONA Orbix E2A XMLBus [ION], Netegrity SiteMinder [Net03], IBM Tivoli Federated Identity Manager [IBMc], Sun Java System Access Manager [SunC] and RSA [Wre04].

Files

ch11.md

Latest commit

History

ch11.md

File metadata and controls

第 11 章 Web 服务安全模式

11.1 Introduction

11.2 Application Firewall

ALSO KNOWN AS CONTENT FIREWALL

EXAMPLE

CONTEXT

PROBLEM

SOLUTION

STRUCTURE

DYNAMICS

Use Case: Filter a Client’s Request with User Authentication – Figure 11.3

Use Case: Add a New Policy – Figure 11.4

IMPLEMENTATION

REVERSE PROXY

MULTIPLE AGENTS

EXAMPLE RESOLVED

CONSEQUENCES

KNOWN USES

SEE ALSO

11.3 XML Firewall

CONTEXT

PROBLEM

SOLUTION

STRUCTURE

DYNAMICS

Use Case: Filtering an Encrypted and Signed Client’s Request with User Authentication – Figure 11.8

IMPLEMENTATION

CONSEQUENCES

KNOWN USES

SEE ALSO

11.4 XACML Authorization

EXAMPLE

CONTEXT

PROBLEM

SOLUTION

STRUCTURE

DYNAMICS

Use Case: Create a New Policy – Figure 11.10

IMPLEMENTATION

EXAMPLE RESOLVED

CONSEQUENCES

KNOWN USES

SEE ALSO

11.5 XACML Access Control Evaluation

EXAMPLE

CONTEXT

PROBLEM

SOLUTION

STRUCTURE

DYNAMICS

Use Case: Control an Access Request to a Resource – Figure 11.12

IMPLEMENTATION

EXAMPLE RESOLVED

CONSEQUENCES

KNOWN USES

SEE ALSO

11.6 Web Services Policy Language

EXAMPLE

CONTEXT

PROBLEM

SOLUTION

STRUCTURE

IMPLEMENTATION

EXAMPLE RESOLVED

CONSEQUENCES

KNOWN USES

SEE ALSO

11.7 WS-Policy

EXAMPLE

CONTEXT

PROBLEM

SOLUTION

STRUCTURE

DYNAMICS