Henryk,
As Anne noted in her response "You must design an architecture that inserts policy enforcement points (PEPs) into the communications path. You must also ensure that communications cannot circumvent the PEPs". And she is right on when she notes that ".even when you combine WS-SP and XACML, you still fall short of a complete SOA security PAL system. Many PEP solutions also rely on regular expressions, external databases lookups, rules engines, and code-based algorithms to augment the standard PALs" So, before I answer your question, please know that the focus for my environment was/is on building out a policy driven infrastructure for a web services environment. And the motivations for going down that path include: 1) Consistent enforcement of policy (and in this particular case, access control policy) across multiple services 2) Minimize the number of interception points in the message path 3) Take the burden/complexity/headache of security policy out of the hands of the development teams who are deploying the services and move it into the infrastructure As such, what I was particularly interested in having happen is for the XML Security Gateways in my environment to act as a XACML PEP to a remote XACML PDP. So to answer your question, you need to look at both the PEP and the PDP side: One the PEP side, the answer is "It depends" on how flexible the product is. *Most* of the gateways provide you some mechanism for making an external "call-out" as part of the decision making process. i.e. Incoming request comes in to the PEP; PEP intercepts, does some basic threat and malicious content scanning, Authenticates the user/entity, then formulates an AuthZ request, sends it out in an "external call-out" to a PDP, and acts on the decision when it is returned. The ease of how you can do this, and the ability to customize that call-out depends on the particular product. You basically have on one extreme the need to engage the consulting services of the vendor to customize that call, to the other of being able to have the ability to do-it yourself using nothing more that message templates. So in short, you can bend the metal to make the PEPs generate a XACMLAuthzDecisionQuery and I am aware that at least a couple of the vendors in this space have it on the roadmap to be a native XACML PEP, but I am unsure of exactly what they mean by that term. On the PDP side, what I will say is that silence as answer to the question is an answer in itself.. J Pretty much all of the PDP vendors have some sort of a web service interface to their "Authorization Service". To date my experience working with multiple products (both on the PEP and the PDP side) has been that you simply cannot point a PEP to PDPs implemented by multiple vendors and expect it to work without custom "franken-code" on either/both the PEP and PDP ends (Even though this was exactly the point of the Catalyst Demo that I noted in my blog entry). These days my response to the vendor response of "Oh, Sure we do that!" is a request for a pointer to the WSDL and the XSDs of their Authorization/Entitlement Service of their current shipping product to prove that they indeed do it. For some reason, the conversation seems to just die out at that point . <shrug> Regards, - Anil From: [email protected] [mailto:[EMAIL PROTECTED] On Behalf Of henryk mozman Sent: Monday, December 08, 2008 7:42 AM To: [email protected] Subject: RE: [service-orientated-architecture] policy-driven security Anil, Thanks for these comments Since you first posted you article about interoperability, did you find out" "Who among you actually implement this interoperable interface specification in your current shipping product?" Henryk --- On Sat, 12/6/08, Anil John <[EMAIL PROTECTED]> wrote: From: Anil John <[EMAIL PROTECTED]> Subject: RE: [service-orientated-architecture] policy-driven security To: [email protected] Date: Saturday, December 6, 2008, 10:32 PM Henryk, There is a desire, when implementing SOA infrastructure, to drive it via policy. Security functions are often one of those low hanging fruits that are often abstracted into the infrastructure such that it can be consistently implemented across non-infrastructure services. As always there is a trade-off here; The benefits of consistent enforcement vs. potential aggregation of risk that each organization has to resolve. XACML does provide a mechanism for coding access control rules and is gaining more and more traction, but would suggest when it comes to implementation, you go into it with open eyes, and take vendor claims with a grain of salt. I wrote up something about this some time ago (http://www.aniltj. com/blog/ 2008/09/28/ RealityOfXACMLPE <http://www.aniltj.com/blog/2008/09/28/RealityOfXACMLPEPPDPInteroperability. aspx> PPDPInteroperabi lity.aspx) and that entry was in some ways motivated by conversations with some vendors in the Fine Grained AuthZ/Entitlement Management space, who when pressed on the actual implementation details of their current shipping products and their ability to support a multi-vendor environment, seemed to find silence the best answer J Regards, - Anil From: service-orientated- architecture@ yahoogroups. com [mailto:service- orientated- architecture@ yahoogroups. com] On Behalf Of henryk mozman Sent: Wednesday, December 03, 2008 8:05 AM To: service-orientated- architecture@ yahoogroups. com Subject: Re: [service-orientated -architecture] policy-driven security Thank you Michael for your sponse. Is XACML the only viable approach to policy-driven SOA security ? Henryk --- On Tue, 12/2/08, Michael Poulin <[EMAIL PROTECTED] com> wrote: From: Michael Poulin <[EMAIL PROTECTED] com> Subject: Re: [service-orientated -architecture] policy-driven security To: service-orientated- architecture@ yahoogroups. com Date: Tuesday, December 2, 2008, 5:41 AM Henryk, this is not much different from the application security (including all interfaces and UI, business logic layer, and data access). Since policies are usually expressed via rules, you can automate not only policy creation and storage but also development and run-time policy enforcement (though the latter is managerial, not governance function) In Governance, you have to identify types of risk and threats, define mitigating and remediating means (methods, instruments/ tools, controls), and specify the security control procedures. Based on this you may need using WS*-Security and related standards or may not need them at all. The only 'specific' in SOA security is the specific of security in distributed environment. Since 75-80% security violations happen inside the companies, SOA security stresses inter-service security. Another special aspect is in the service comparabilit y. In SOA, the service design should not consider and build-in special knowledge about future consumers and the environment where it might be used. This means, that service resources may have no idea about the end-user identities and credentials, i.e. it would not make sense propagating them inside the services. For the audit purposes, you can have full and strong security control of the user at the initial request point and use security trust federation below that point while collecting the IDs of the services and components that have been engaged into the user's request processing. Good luck, - Michael _____ From: henryk mozman <henrykmozman@ yahoo.com> To: service-orientated- architecture@ yahoogroups. com Sent: Tuesday, December 2, 2008 6:01:34 AM Subject: [service-orientated -architecture] policy-driven security Hello all, I am looking into SOA policy-driven security (as in Governance) What is the current of this technology ? Henryk <http://geo.yahoo.com/serv?s=97476590/grpId=9428360/grpspId=1705007181/msgId =12100/stime=1228333885>
