James McGovern asks: "Are XML firewall vendors such as reactivity and vordel considering making their products XACML PEPs?". I can't speak for Reactivity, but Vordel has had XACML PEP support for four years now. Along with Allan MacPhee from Entrust, I've written an ISTR paper about our joint rollout for a large telecoms customer where Vordel acts as the XACML PEP and Entrust acts as the XACML PDP. [to read it, go to http://dx.doi.org and insert the following document ID: doi:10.1016/j.istr.2005.02.002]. Before this customer went live, I can tell you that they tested every aspect of the PEP/PDP interchange, including pulling the plugs from machines and ensuring that Vordel's products would detect missing PDPs, would prioritize PDPs, perform load-balancing, and failover. As a telco, the customer had a special interest in having no single point of failure and in ensuring high throughput and low latency.
As well as deploying with Entrust's PDP, we also interoperate with other PDPs, including Oblix (now Oracle) and Sun. For a long time now, we've advocated the PEP/PDP model as a great way to enforce access control while keeping a central policy store.
In the comments on James's blog post, Gunnar asks "If you are MS, what do you want out of XACML that you don't already get from WS-SecurityPolicy, WS-Security, WS-Trust, et. al.?" Good question. The PEP/PDP model, used by XACML, originally comes from RFC 2753. What XACML does is to define a standardised way to request authorization using an AuthorizationDecisionQuery message that can return a SAML Assertion if the authorization is successful. Examples of an AuthorizationDecisionQuery message and response is provided in the ISTR paper linked above. So, in essence the XACML service is being asked to issue a token. WS-Trust also defines a message to request a token, and that's the RequestSecurityToken message. This is sent to a Security Token Service. You could argue that a SAML assertion is just another token, and therefore why give it special treatment by using XACML, why not just use WS-Trust. This is quite a compelling argument. Vordel supports both WS-Trust and SAML, so we do not force our customers into the pure WS-* methodology or into just using SAML and XACML. That's the advantage of working with vendors like Vordel - we can be the "Switzerland" between the Sun and Microsoft positions.
Sometimes there are good architectural reasons for not using XACML PEP/PDP model. I mentioned a Security Token Service (STS) in the previous paragraph. I believe there are very good reasons for using an STS to issue attribute tokens that are used for fine-grained authorization, and then binding these attributes to the XML messages themselves as they flow into/through an SOA. You can even include the attributes without including the identity of the user or client, for privacy reasons. At the Web Service endpoints, these attributes are right there in the message, meaning that you can do authorization without having to call out to a PDP. This is the same architecture principles as how Web Access Control products from vendors like Netegrity are often used - for (a) authentication and (b) attribute lookup and insertion into HTTP headers - so that applications can use these attributes for fine-grained authorization at the endpoint without having to connect to a PDP. This especially works in situations where repeated calls to the PDP from the endpoint would not make sense. Vordel provides all sides of this STS functionality - the attribute lookup, attribute issuance, binding to XML messages (or headers), and authorization based on attributes. An STS often makes more sense than using the XACML model. But, again as the "Switzerland" vendor, Vordel supports both.
4:23:35 PM 
|
|
