Anil, Both you and Anne gave me excellent input and food for thought.
Thanks so much. Henryk --- On Mon, 12/8/08, Anil John <[EMAIL PROTECTED]> wrote: > From: Anil John <[EMAIL PROTECTED]> > Subject: RE: [service-orientated-architecture] policy-driven security > To: [email protected] > Date: Monday, December 8, 2008, 11:13 PM > 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>
