XML gateways are dedicated applications that enable a centralized approach to security and identity enforcement. They insert an abstraction layer between web service requesters and web service endpoints in order to govern and secure their transactions. They establish transit points across service-oriented architectures (SOA), Web 2.0, and cloud security zones. One such XML gateway is SecureSpan Networking Gateway, from Layer 7 Technologies. SecureSpan acts as a policy enforcement point and provides edge security for SOA, Web 2.0 and cloud-based web services. This article describes how access control rules defined in OpenSSO can be enforced at runtime by SecureSpan XML Gateway through its native OpenSSO integration agent. Contents
Although XML gateways typically enforce edge security for web services including authentication and access control, they are often part of the same architecture as an Identity and Access Management (IAM) solution such as OpenSSO. In these cases, it is usually preferable to manage access control rules at the IAM layer rather than in the policy enforcement point. These access control rules can then be enforced at runtime by the XML gateways acting as the edge policy enforcement points. The principal goal of such integration is typically not to provide a single sign-on (SSO) experience to the web service requester, which often is not even a human being, but rather to establish a single point of management for access control rules across web applications and web services for a specific environment. Business-to-business (B2B) web service interactions typically cross security boundaries. In situations where threat protection and security in general is highly sensitive, direct access to the IAM layer is not possible. One such IAM layer is OpenSSO Enterprise, formerly Sun Java System Access Manager. An XML gateway appliance, in contrast, is a secured and hardened device that is appropriate for deployment in a demilitiarized zone (DMZ). Using this pattern of separation between the enforcement and management of access control rules, the XML gateway cannot redirect requesters to OpenSSO for authentication. Because the requester does not interact directly with OpenSSO, the XML gateway intermediary instead negotiates sessions with OpenSSO on behalf of the requesters.
Figure 1: XML Gateway Appliance Intermediary
In general, configuring the integration between SecureSpan and OpenSSO requires two steps. First, a policy agent profile is needed in order for SecureSpan to communicate with OpenSSO. This policy agent profile must be defined in OpenSSO. Briefly, you define the policy agent profile as follows:
Second, you must configure the SecureSpan Gateway to integrate with the
OpenSSO instance. For this configuration, you must install the OpenSSO
Custom Assertion. The installation is through an RPM package manager file,
which you must transfer to the gateway and install. After installation, you
must edit the properties file
Table 1: OpenSSO Custom Assertion Properties Descriptions
When this process is completed, the OpenSSO Protected Resource assertion appears in the SecureSpan Gateway Manager, under the Access Control category. The next section describes how to use this assertion.
Like any other assertion in the SecureSpan Gateway Manager palette, you can add the OpenSSO Custom Assertion to any policy with drag-and-drop. Each instance of this custom assertion has its own set of properties. At runtime, the custom assertion uses those properties to construct its query to OpenSSO. These properties are Realm, Resource and Action. The values for these properties can use context variables. For example, instead of hard-coding the Resource being accessed, it is typically constructed using the incoming URL, as illustrated in Figure 2.
Figure 2: Setting OpenSSO Custom Assertion Properties When the policy is executed at runtime, the custom assertion achieves two goals. It will
The flow chart shown in Figure 3 describes the runtime behavior of an OpenSSO Custom Assertion instance.
Figure 3: OpenSSO Custom Assertion Flow Chart The OpenSSO Custom Assertion instance is part of a policy and does not in itself implement the entire access control decision delegation. Rather, the custom assertion instance interacts with other assertions in the policy by reading from and writing to the transaction context. The following section provides guidelines for such policies including the OpenSSO custom assertion.
As illustrated in Figure 3, the OpenSSO Custom Assertion requires a number of conditions to function properly. Either an OpenSSO cookie is present and is associated with an OpenSSO session, or credentials must be provided in order for a new session to be established. In the policy being enforced, this choice is generally represented in a logical OR branch: at least one assertion must evaluate to true, where credential assertions and cookie test assertions are tested in a specific order. This logic is illustrated in Figure 4.
Figure 4: SecureSpan Policy Including OpenSSO Custom Assertion The credential assertions each in turn test the presence of the credential. If the test is successful for a credential, it is loaded into the transaction context, where the OpenSSO Custom Assertion can read it. If a test fails, the next assertion in the logical OR tree structure attempts to find credentials using its own mechanism.
|
| |||||||||||||||||||||||||||||||||||||
 | |
| ||||||||||||
