Here is one more aspect of access control in services - data visibility, i.e. access to particular field in the database or to particular element in the message content.
To really protect your data ( before "data protection policies (e.g., encryption and signature)" applied), the service provider should not retrieve restricted data from the data store in the first place. Encryption protects data confidentiality and signature - data integrity. WS*-'security' does not address data visibility because it is considered as security means behind the interface but, for the consumer, it does not matter where the information may be tempered - in communication to the interface or behind it. While XACML cannot do this protection directly, it can carry appropriate policy to be applied to the data retrieval mechanism. You can find more detailed explanation on this type of security in my article Service Reuse and Entitlement, http://soa.sys-con.com/node/523434 - Michael ________________________________ From: Anne Thomas Manes <[EMAIL PROTECTED]> To: [email protected] Sent: Monday, December 8, 2008 5:28:56 PM Subject: Re: [service-orientated-architecture] policy-driven security Henryk, Policy-driven SOA security is a function of your infrastructure architecturemore than any particular technology. 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. The issue of a standard, universally adopted policy expression language (PAL) is secondary to the enforcement architecture. XACML is a useful language for expressing access control policies, but it isn't designed to express all types of security requirements. And even in the access control arena, it tends to fall a little short when dealing with fine-grained policies -- particularly those that rely on application context. WS-SecurityPolicy provides a PAL for expressing authentication and data protection policies (e.g., encryption and signature) for SOAP-based interactions. It could be used for other types of interactions, although I haven't seen anyone do so. It can also be used in conjunction with XACML for access control. But 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. Anne On Mon, Dec 8, 2008 at 5:41 AM, henryk mozman <henrykmozman@ yahoo.com> wrote: > 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] com> wrote: > > From: Anil John <[EMAIL PROTECTED] com> > Subject: RE: [service-orientated -architecture] policy-driven security > To: service-orientated- architecture@ yahoogroups. com > 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 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 > >
