Security Policy Infrastructure

Effective management of security policies requires a holistic approach that manages security policies throughout the life cycle of applications. Policies in the context of SOA are the means by which processes and services express the conditions and manage the behavior of the underlying infrastructure, in order to secure access to information, information availability and retention, audit, and so on.

Policy management includes authoring business policies that gets refined to service specific policies like security, performance indicators and metrics, trust policies, and so on. As shown in Figure 2-9 on page 39, these policies in turn get enforced by the infrastructure when they get configured as requirements that the infrastructure should meet.

Policies are defined and managed centrally. When there is a

Service Registry and

Repository

(SRR) in the environment, then the

Security Policy Management

obtains service definitions and meta data from an SRR and defines polices based on that information. Once the effective policy is obtained, the polices are distributed to the

enforcement points

. Policies are distributed in a common format (Web services policy standards) from the Security Policy Management to the enforcement points. When there is a Service Registry and Repository in the environment, the Security Policy Management will publish polices to the SRR so that the enforcement points derive service definition and policies, and enforce them locally.

Figure 2-9 Security Policy Management: Definition and Enforcement

Figure 2-10 highlights the Security Policy Infrastructure within the IBM SOA Security Reference Model.

Figure 2-10 Components of Security Policy Infrastructure Security Policy Management

Service Registry & Repository (as intermediary for policy exchange, distribution)

Portal Transform to URL level

policies and portlets Canonical form (e.g WS-Security Policy, XACML)

Application Server

Canonical form (e.g WS-Security Policy, XACML)

Transform to application policies and configuration Transform to appliance

configuration on service interfaces Canonical form (e.g WS-Security Policy)

Metadata &

Services

Publish policies

Security Policy Infrastructure Policy

Administration

Policy Decision and Enforcement Policy Distribution and

Policy administration

Administration of the policies deals with the life cycle of a policy. This includes the activities of creating, managing, and importing/exporting the security policies using the security management tools available. There can be different kinds of policies. The following are two major categories:

Message protection policies

These policies focus on the capabilities and the constraints a service consumer needs to implement in order to invoke a service. The following items make up the message protection policies for the service consumer:

򐂰

Service information

: The protocol to use to reach the service and the address of the service. For example, the service can be invoked using a Web service request over HTTP. If there are some intermediaries, the interaction policies between the service consumer and the intermediary also have to be known.

򐂰

Message protection information

: Additional information about signing and encrypting of the message can be included in the policy; also, whether point to point or message level protection is required. This includes the encryption algorithms supported and the privacy rules that apply.

򐂰

Identity information

: The type of security token required by the service provider (user name, SAML, Kerberos, or X.509 certificate).

Provider policies

The provider policies focus on the policies a specific provider applies based on its internal requirements. This can include authentication, authorization, privacy and audit policies. These policies are provided to the provider PDPs and enforced by the provider PEPs.

Taking an example, a service provider validates an incoming security token and performs authorization, ensuring, for example, that only account owners have access to their account information. This policy is checked based on the provided user information (user identifier and any other attributes from the user) and the information a user tries to access (the account number).

Policy distribution and transformation

The security policies created need to be distributed to the enforcement and decision points within the infrastructure with the appropriate information (see Figure 2-11 on page 41). The policies may be defined centrally and then are distributed to the enforcement points in a canonical format, for example, XACML, WS-Policy, or WS-Security Policy. The binding information to enforce the polices is also distributed appropriately. These policies are then transformed at the enforcement point to a local representation so that they can be enforced.

Figure 2-11 Policy Transformation and Distribution

Standards like WS-Policy and WS-SecurityPolicy provide descriptions on how service consumers and providers can specify their requirements and capabilities in a Web services world. Policy assertions can be defined for use within SOAP messages. Assertions can cover the authentication schemes (the required security tokens and the encryption algorithms), the transport protocol selection, the privacy policy, as well as information related to the quality of service.

The OASIS eXtensible Access Control Markup Language (XACML) provides a markup language to specify access control policies. It can be used as a generic format to store policies although it also provides a request/response model (based on XML format) for enforcement and decision points. It can be used to provide policies to a service provider as defined in “Provider policies” on page 40. Service Provider Service Consumer c Distribute policies

Policy Distribution and Transformation

Transform policies into generic format Map generic policies to

local policies

Map generic policies to local policies

Map generic policies to local policies

Service Provider

Policies

Note that there may also be a policy that controls the transformation and distribution of the policies.

Policy decision and enforcement

At runtime, there are two distinctive components of policy:

򐂰

Policy Decision Point

(PDP): A PDP makes a decision based on the policy and request. So, for example, it may consult an authorization policy to see if the user is permitted to access a service. The decision is provided to the policy enforcement point.

򐂰

Policy Enforcement Point

(PEP): Access to a resource is controlled by an appropriate resource manager or PEP. The PEP implements access control after making decision requests to PDPs using, for example, XACML

(Appendix C, “Security standards and technology” on page 371).

In a typical deployment, you can find several enforcement points. Each of these enforcement points can have its own mechanisms to enforce security for the incoming requests.

The enforcements points rely on

decision points

to make decisions. These decision points contain the security policies defined in the infrastructure. The requirements and thus the policies are different, depending on the security domains and the application platforms.

򐂰 The

service consumer

can enforce a first level of security on the client side. Security controls based on the policies provided for this service can be made so that the request matches the requirements.

򐂰 The

service provider

can enforce security policies for incoming requests and provide a first level of defense for the infrastructure. These include enforcing message protection, provide token validation and exchange, as well as authorization and audit services as defined in the security policy.

One of the challenges of enforcement and decision points is to have multiple enforcement points within the infrastructure talking to several decision points. Providing integrated and centralized decision capabilities reduces the

administrative tasks related to policy management.

Note: More detailed information about the standards are available in

Monitoring and reporting

It is necessary to keep track of applicable policies, any modification to them, as well as the assessment of compliance of lower-level policies against corporate policies. Traceability of policies from high level business policies to enforced configurations and runtime requirements is necessary to track what the goal is and what the runtime behavior is based on. This helps identify policy changes that occurred and can help manage accountability of policy changes. Closely linked to this practice is the enforcement of these policies in the infrastructure and the monitoring of the behavior of system elements throughout the life cycle of the business. Security policies need to be developed and deployed throughout the stages of the life cycle of an application.

Once an application is made available to be accessed, application related policies get administered to reflect any changes that may happen during the lifetime of the application. Changes to security policies include authorization policy changes (for example, adding new roles that may access the resources or assigning roles to new user groups or users), user management changes (for example, users assigned to additional user groups), or other changes, including audit requirements, and constraints like integrity or confidentiality.

When administering security policies, it is necessary to adhere to changing corporate business security policies and industry and government regulations, and compliance requirements. In addition to these sources of change, another key input factor for change in policies is the discovery of vulnerabilities and new risks that may be identified through solution monitoring activities. These changes to security policies must be tightly controlled and access to them should be traced and audit trails supplied so that the processes may be adequately monitored.

In document Understanding SOA Security (Page 54-59)