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/RealityOfXACMLPEPPDPInteroperability. 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: [email protected] [mailto:[EMAIL PROTECTED] On Behalf Of henryk mozman Sent: Wednesday, December 03, 2008 8:05 AM To: [email protected] 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]> wrote: From: Michael Poulin <[EMAIL PROTECTED]> Subject: Re: [service-orientated-architecture] policy-driven security To: [email protected] 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>
