Using SecureSpan XML Gateway to Enforce Access Control Rules Employs Native OpenSSO Integration Agent at Runtime
In their Sun Developer Network paper on Delegating XML Gateway Runtime Authorization to OpenSSO Francois Lascelles and Rick Palkovic describe how access control rules defined in OpenSSO can be enforced at runtime by SecureSpan XML Gateway through its native OpenSSO integration agent. XML Gateways, they explain, are dedicated applications that enable a centralized approach to security and identity enforcement.
XML Gateways, the article continues, 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, the authors write, and provides edge security for SOA, Web 2.0 and cloud-based web services.
The paper points out that an XML gateway appliance, in contrast to an XML Gateway that is part of the same architecture as an identity and access management (IAM) solution, is a secured and hardened device that is appropriate for deployment in a demilitarized 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.
The authors note that 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. Second, the SecureSpan Gateway must be configured to integrate with the OpenSSO instance.
The paper next treats the use of Secure Span OpenSSO custom assertion, pointing out that 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. When the policy is executed at runtime, the custom assertion achieves two goals: 1) manages the OpenSSO session on behalf of the requester and 2) asks OpenSSO if access to the resource is authorized. The authors write that a flow chart is included describing the runtime behavior of an OpenSSO custom assertion instance.
It should be noted that 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 final written section of the article provides guidelines for policy structure of SecureSpan.
Customized news reports about Sun Microsystems. Just the news you need, none of what you don't. 50,000+ Members. 20,000+ Articles Published since 1998.