David Garrison's Blog

David Garrison's Homepage
David Garrison is Senior Product Manager for AquaLogic Enterprise Security. David has been with BEA since 2005. Prior to BEA, he was a member of the Product Management team at Netegrity responsible for the SiteMinder Web single sign-on product and for the eProvision user provisioning product.

Entitlements and Business Process Management: What’s Possible?

Business Process Management tools are used to model, implement, execute and monitor the day-to-day processes a company follows. Products like AquaLogic Business Process management (ALBPM), recently acquired by Oracle, is used to bridge complex human workflows and the system-to-system integration of enterprise applications in a single process.

Entitlements management tools are used to manage access to complex applications. Products like AquaLogic Enterprise Security (ALES), recently acquired by Oracle, manage policies external to the application that control who can use the application and what they can do.

So what’s possible when you bring the two together? Let’s consider an example. The picture below is a simple business process for handling an employee expense report. The company’s expense report rule are as follows:

• Any single expense report whose total is > $5000 will be rejected and sent back to the employee. The employee will be informed about why their expense report was rejected.
• Employees in the Engineering organization can have expense reports pre-approved if the total amount is less than or equal to $1000.  If the total is greater than $1000, then it must be approved by a supervisor.
• Employees in the Sales organization can have expense reports pre-approved if the total amount is less than or equal to $2000. If the total is greater than $2000, then it must be approved by a supervisor.

In the process above, the activity called Check Company Policy implements the company’s rules about expense reports using ALBPM’s Process Business Language. It checks certain parameters of the expense report (e.g. date, submitter, amount, etc.) to determine how the report should be routed. Using the business process management tool alone means when those rules change, the business process has to be changed. That means taking the process out of production, editing it, testing it, and re-publishing it.

By adding an entitlements product like ALES, those rules can be externalized. The runtime APIs for the entitlements engine can be included in the process as a Catalog element making them available to any activity in the process. Now we can write the Check Company Policy activity to call out to the entitlements engine when a processing decision needs to be made. By doing that we can write the code for the Check Company Policy activity to look like this:

The activity now asks ALES to render an access decision using an authorization call to the policy engine. In the code above that call is isAccessAllowedWithResponseAttributes. This call provides an access decision along with a set of responses which provide additional data that will be used by the business process. In this example there are two responses that are returned by the ALES policy engine. The first is a comment that tells the employee the status of their expense report and the second is a nextstep that tells the ALBPM engine what to do next (how to route the expense report).

If we want to implement the company rules above, we would write our ALES policies to look like this:

The deny policy handles the case where the expense report total is > $5000. The two grant policies for the Sales organization determine if a report can be pre-approved or if it goes through the normal approval process. Two similar grant policies are used for the members of the Engineering organization.

Now, by using ALES, we’ve removed the logic for routing the expense report from the business process. Since those policies are managed by ALES they can be changed at any time without affecting the business process at all. They can even be changed when the business process is running in production. For example, the company may want to change the pre-approval limits for Engineering and Sales or add pre-approval limits for other organizations. At some point in time, they may want to implement a policy that prevents anyone from submitting an expense report within a week of the end of the quarter.

Granted, this is a pretty simple example, but I hope you can see the potential. You can design your business processes with certain key decision points. Those decision points can then call out to the ALES entitlements engine. The ALES policies will determine what happens at those decision points. The best part is that the policies are completely outside the business process engine so they can be changed at any time. Combining ALES with ALBPM makes your business processes more flexible and resilient to changing business requirements.

The Value of a Security Services Framework

In an earlier post, I described a generic architecture for an Entitlements Management Solution (see Building an Entitlements Management Solution, April 3, 2008). In that post, I discussed the role of a Security Services framework in the Policy Decision Point.  I want to expand on that topic in this post.

In an Entitlements Management system, the PDP is the runtime component that evaluates role and authorization policy and provides an access decision to the application. In many products that we see, the PDP provides an authorization engine but not much else. That means that the application has to get other security services from somewhere else. Those services might include authentication, audit, credential mapping, certificate validation and others.

We take a different approach with our AquaLogic Enterprise Security (ALES) product. The PDPs that we supply with ALES have a full set of security services. Those services can be centralized or distributed depending on how the PDPs are deployed. That security services framework provides a complete set of security services to the applications that are protected by ALES. It provides a platform for integrating ALES with other security infrastructure including Identity and Access Management products like Web SSO, Identity Management, Role Management, and User Provisioning systems.

Let’s start with a little history. Back in 2002, BEA released WebLogic Server 7.0 with a new security framework with a set of out of the box security services. That framework included a set of security providers for each service type – authentication, authorization, role mapping, audit, etc. The framework could be configured with one or more providers for each service. For example, you could configure two authentication providers – one to authenticate users with credentials stored an LDAP directory and another to authenticate users with credentials stored in a relational database. The framework also provided a public Security Service Provider Interface (SSPI) that allowed customers and third parties to write their own providers for any of the supported services. Over the years hundreds of custom providers have developed for use with the security framework.

Today, that security framework, known as Core Security Services (CSS), is used throughout the BEA product suite. It has been de-coupled from WLS so that it can be used in other environments. In particular, it is a foundation component of the ALES PDPs that we provide for protecting BEA’s products as well as other application environments and 3^rd party products (for a full list of ALES supported environments please see the ALES Security Integrations section on our Web site).

The picture below is a schematic of the CSS framework as used in ALES.

The use of the CSS component in the ALES PDPs means that any application that is protected by ALES also has access to the full range of security services and providers that can be used with WebLogic Server and other BEA products. This includes any 3^rd party security providers. It is the means by which ALES integrates with external security products like Web SSO.

Let look at some of those services and providers in more detail.

Authentication

An Authentication provider takes a set of user credentials (e.g. username/password, certificate, etc.) and validates them against an external user store. Authentication providers support a wide variety of LDAP directories and relational databases.

The authentication model is based on JAAS. When a user is authenticated the provider creates a subject for that user. The subject representing a user identity can contain one or more user principals with user attributes from multiple sources or one or more group principals with the groups the user is a member of and the group attributes. The JAAS model allows for multiple providers to be configured for a single application. Each provider is configured to be “required”, “requisite”, “sufficient”, or “optional”.

Identity Assertion providers are a special type of authentication provider that takes an identity from an external source and validates it. Identity Assertion providers do the following:

• gets a user token
• validates it (in some cases by calling an external system)
• passes user information extracted from the token to the authentication provider

The authentication provider then creates an authenticated subject. There are a number of out of the box Identity Assertion providers including SAML 1.1 & 2.0 and SPNEGO for desktop single sign-on. In addition, popular Web SSO products also provide Identity Assertion providers for ALES including CA SiteMinder, Oracle Access Manager, and IBM Tivoli Access Manager.

Role Mapping

Role Mapping providers resolve role membership. Those roles can then be returned to the application or used in subsequent authorization policy evaluation. ALES ships a special role mapping provider that assigns roles dynamically based on ALES role policy. Roles can also come from external systems (e.g. role management) using a custom role provider. You can use multiple role providers for a single application. If multiple providers have been configured, a user will get the aggregate set of roles from all providers.

Authorization

Authorization providers evaluate policy that controls access to application resources. ALES ships a very powerful authorization provider that determines access rights based on ALES policy. The ALES authorization provider can also collect attributes from external Policy Information Points including LDAP directories, databases, and SDO objects. It can return information to the application as a set of responses. Multiple authorization providers can be configured. If multiple authorization providers are present, a special adjudication provider is required to render the final authorization decision.

Credential Mapping

Credential Mapping providers store and retrieve credentials for integration with downstream applications. A credential mapping provider can map a user identity to an appropriate set of credentials for authentication to external systems. A common use case occurs when an application needs to retrieve data from a relational database on behalf of a user. The credential map securely stores and retrieves the username and password to access the database.

Out of the box, ALES includes username/password and PKI credential mapping providers. Applications can also use the SAML 1.1 & 2.0 credential mapping providers to generate SAML assertions for outbound messages.

Audit

Audit providers filter and record runtime and administrative events. ALES ships with a default audit provider that is based on log4j but users can create their own custom audit providers. Custom audit providers can send information to other systems like reporting or system management applications.

Like other security services, the security framework supports the simultaneous use of multiple audit providers. The CSS Audit Service uses a fan-out approach and delivers each generated audit event to all configured audit providers. Each provider can be of a different implementation and utilize different filtering and storage mechanisms.

Summary

So that’s an overview of the CSS framework that we use in BEA products and specifically in the ALES PDPs. In summary, the CSS framework provides value in the following ways:

• It provides a complete set of security services not just authorization.
• It provides a separation of the application from the security services. The application and security providers can evolve independently. For example, I can change the way I record audit events by changing the audit provider without impacting the application.
• Multiple providers can co-exist for the same service. For example, multiple authorization providers can be used together. This often happens with customers who have an existing home-grown entitlements system and want to migrate their entitlements management to ALES. In this case, they simply implement a custom authorization provider that calls their existing system and use that provider along side the ALES authorization provider. Both providers get called. The custom provider makes access decisions about older applications while the ALES provider makes access decisions about newer applications. Applications can be moved from the custom provider to the ALES provider over time.
• It supports all the security providers that have been written for the WebLogic platform. It is the mechanism by which we integrate ALES and other BEA products with identity and access management products like Web SSP, roles management, and user provisioning.

Building an Entitlements Management Solution

So what does it take to build an Entitlements Management solution? That depends on who you ask of course. However, when I look at commercial products in this area I see certain common architectural patterns. Many of the products that I’ve seen (including our own) make use of a set of common elements defined by the OASIS XACML standard (eXtensible Access Control Markup Language).

The picture below shows the typical components of an Entitlements Management solution. The XACML spec defines the role of the Policy Administration Point (PAP), the Policy Decision Point (PDP), the Policy Enforcement Point (PEP), and the Policy Information Points (PIP).

The Policy Administration Point (PAP) manages the creation and storage of policy data in the Policy Store. The administrator interacts with the PAP (typically) through a browser based management console where roles, policies, resources, actions and so forth are defined and managed. The policy store may be an LDAP directory or a database. The PAP may also provide facilities for policy import and export. Most products provide some management APIs that allow customers to embed administrative functionality into their own applications.

Runtime role or authorization decisions are determine at the Policy Decision Points. Typically I’ve seen two ways that PDPs are deployed:

• As a centralized entitlements server that can be invoked by remote clients via RMI, Web Service calls or using the XACML 2.0 request/response protocol.
• As an embedded PDP deployed in same process space as the application. The most common examples are PDPs embedded in a JVM for plain Java applications or embedded in an application server for J2EE applications.

The PDPs can be configured to get data from one or more Policy Information Points (PIPs). These PIPs can be user or application directories or databases that contain information that is required to make an access decision. Such information includes user, group, and resource attributes (e.g. user profile information, account balances and limits, etc.). These attributes can then be used in the policies which control access.

Most entitlements products that I’ve run across cache policy at the PDP so that the PDP can run independent of the PAP. But that means that there has to be some mechanism for the policy to get from the policy store to the PDPs. The two most common ways are to push the policies from the PAP or to have the PDPs poll the Policy Database. In the first model, the administrator takes an action in the management console that tells the PAP to distribute policies to the PDP. In more sophisticated systems, the administrator can control over which policies get pushed and to which PDPs. In the other model, the PDPs periodically poll the policy database to see if their policies have been changed. Personally, I prefer the push model because it gives the administrator more control over how and when the PDPs get updated.

The last thing I’ll mention is the little blue boxes in the picture above labeled “Security Services”. This is a security framework that provides a set of security services for more than just authorization. We provide such a security framework in our AquaLogic Enterprise Security (ALES) product. The ALES security framework provides services for authenticating a user, evaluating role and authorization policy, auditing, and consuming and producing security tokens of various types. Having this framework as part of the PDP is a very powerful feature for two reasons. It provides a complete set of security services for an application and it serves as an integration platform for other security products that may already be present in an enterprise – Web SSO, identity management, user provisioning, role management, etc.

More about the value of the Security Services framework in an upcoming post.

A Holistic Approach to SOA Security – Why WS-Security isn’t Enough

When people think about SOA security they generally think about message-level security. There is no question that message-level security is an important part of your SOA security solution. But there is more to think about than just protecting messages in transit.

A holistic approach to SOA security must consider three important components:

• Message-level security to protect messages in transit.
• A security framework that can integrate with existing security and identity management systems.
• Fine-grained authorization that can not only protect access to services but can control access to business functions and data within the service.

The first of these components is message-level security. There are a number of important standards for protecting a message in transit including WS-Security, WS-Trust, WS-SecurityPolicy, and WS-SecureConversation. These standards are used to facilitate trust between service provider and consumer and specify how encryption, signing, and identity propagation will be handled in the message.

The second component is a common security framework that is flexible enough to allow integration with 3rd party security providers. BEA products use the Common Security Service framework to provide this integration. CSS provides a common set of security services – authentication, authorization, credential mapping, certificate validation, audit, and others. Each security service has a set of out of the box security providers and can support multiple providers in parallel. Furthermore, CSS provides a public Security Service Provider Interface that allows users and 3rd parties to create their own security providers. As an example, the major Web SSO vendors provide an authentication plug-in to allow propagation of identity from the Web tier back into the application tier.

The last element is security policy to protect access to services and control access to business functions and data inside the services. This security policy provides fine-grained authorization where the security logic is externalized from the service and the container where the service runs. With this approach the access policy becomes consistent – not a disparate set of policies defined in each individual container. The access policy becomes centralized – created and managed from a single administration point. A fine-grained authorization system will be able to protect resources at different levels and protect both software components and business objects.

The objective is to provide a means to define and manage security access policy from a central point using a common policy model for all the elements of your SOA environment including

• Individual business services
• Presentation services
• Business processes
• Process orchestrations
• Data services
• Enterprise services buses

The advantage of managing access policy centrally is that

• Application resources to be protected can be managed in a single resource hierarchy
• All policies have the same format and are visible and managed from one place
• Access rights for users, groups, and roles can be anaylzed and reported

So what does it mean to external policy in a SOA environment? In general an authorization system that allows you to externalize security has two major components – a Policy Administration Point (PAP) and a set of Policy Decision Points (PDP). We start by deploying PDPs in the containers that host services we want to protect. Service (or application) resources are discovered or created in a resource hierarchy in the PAP. Access policies are defined for the resources in the hierarchy – typically the authorization system supports inheritance of policy from parent resources to child resources in the tree. Once the policies are completed, they are distributed to the PDPs for runtime evaluation – This provides two important advantages:

• The PDPs continue to evaluate and enforce access policy even if the PAP goes down
• Policies can be changes and re-distributed to the PDPs while the application is running

AquaLogic Enterprise Security (ALES) is BEA’s SOA Security solution for managing and enforcing access policy for services and containers in a composite application. It supports the centralized definition of complex application entitlements and the distributed runtime enforcement of those entitlements. ALES allows you externalize entitlements – remove security decisions from the application and from the individual services that comprise that application. To find out more about ALES, visit at our website www.bea.com.

Externalizing Application Security - What Does it Mean?

Application security has evolved dramatically over the last few years. The need has evolved from perimeter security focused on keeping the bad guys out to fine-grained control over what people are allowed to do in enterprise applications. Web single sign-on products have centralized authentication and management of identity across the Web tier and revealed the next layer of vulnerability in the application tier.

In addition, regulatory and privacy requirements have mandated new levels of control over company and customer information. A rapid rise in outsourcing of application development means that security logic embedded in the application tier is no longer directly controlled by the enterprise. These changes in the regulatory and development environments mandate a change in how access to the application tier is managed.

Let’s start with a couple of definitions. We’ll define entitlements as the set of privileges that govern what an user can do in an application. An entitlements system is used to create and manage those privileges and to make and record access decisions that are made at run time. Then the next wave of application security technology is the management of user entitlements and the externalization of application security logic from the application tier.

There are two ways to provide access control into an application.

The traditional way to control access in the application involves embedding the security logic inside of the application. The application has to know how to go out to other systems in the infrastructure to get information about the user and information about the application resource. This makes the application brittle and difficult to change. It also means security logic is visible only by inspecting the code. Finally, the access decision may not be audited.

The other way, involves externalizing the security logic from the application – Instead of complex logic coded inside the application, the developer uses a call to the entitlements system to get an access decision. When called by the application, the entitlements system gathers the required information, evaluates the policies that applies to application resources and returns an access decision. It also audits all the information about that decision.

This has a number of benefits including:

• Flexibility - applications do not have to change if the security or business requirements that govern access control change.
• Visibility - all security and access logic can be seen and managed from a single place.
• Traceability - the entitlements system audits all access control ddcisions and can report on how has access to what.
• Efficiency - developers don't write security logic leaving them free to concentrate on new value-added capabilities for their customers.

BEA is leading this new wave of entitlements management. BEA’s AquaLogic Enterprise Security (ALES) is an entitlements system that supports the centralized definition of complex application entitlements and the distributed runtime enforcement of those entitlements. ALES allows you to externalize entitlements – remove security decisions from the application. It provides the means to define application resources and application businesses objects, represent those objects in hierarchical relationships, and write policies that describes which users, groups and roles can access those objects.

May 2008

Search this blog:

Archives

May 2008
April 2008
July 2007
May 2007

Categories

Recent Entries

Entitlements and Business Process Management: What’s Possible?

The Value of a Security Services Framework

Building an Entitlements Management Solution