>the 'closer' the entitlement decision may be done to the requester's >network location, the less risk of illegal interception you acquire
. beyond the security aspects Michael noted above, there are definite performance aspects to consider when deciding upon the deployment topology (Local PEP, remote PDP; PEP&PDP co-located etc.. etc.), especially when it comes to highly transactional, and/or intermittently connected, and/or low bandwidth environments. I've discovered that when it comes to attribute-retrieval/policy/policy-decisions that caching has a significant impact and the flexibility of an implementation that supports caching at various points as well as multiple deployment topologies should be one of the decision factors in choosing an implementation. Regards, - Anil From: [email protected] [mailto:[EMAIL PROTECTED] On Behalf Of Michael Poulin Sent: Sunday, December 07, 2008 7:50 AM To: [email protected] Subject: Re: [service-orientated-architecture] policy-driven security +1 to Anil (glad to hear from you again!) In addition to what Anil said about XAMAL, I can add that we evaluated a few vendors of XACMAL-based entitlement system back in 2005 but found them not mature enough for production use. An additional benefit I see in XACMAL ("with open eyes") is in that the Points of Interception and even Points of Decisions may be dynamically distributed from a centralised engine onto the consuming applications/components sides: the 'closer' the entitlement decision may be done to the requester's network location, the less risk of illegal interception you acquire. - Michael _____ From: Anil John <[EMAIL PROTECTED]> To: [email protected] Sent: Sunday, December 7, 2008 3:32:34 AM Subject: RE: [service-orientated-architecture] policy-driven security 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 Error! Filename not specified.
