Re: [service-orientated-architecture] Greenemeier on SOA & AJAX Security Attacks

[Keith Harrison-Broninski]

Steve Jones wrote: "Most developers will throw a Web service up, make a database call that is probably SQL injectable, and have no session authentication to protect the transaction" So the summary here is that people who should be fired will continue to write bad code? This issue is nothing to do with AJAX security and everything to do with bad practice, poor design and a lack of understanding of how systems work.  Its fine for security folks to talk about not repeating the bone-head mistakes of before in these applications, but one of the big problems has always been that security people fail to innovate in ways that make things simpler, which means they are always doing catchup on new technologies. Rather than complaining that people should avoid stupid mistakes it might help more if there were people actually solving the distributed and federated trust model in a way that makes it simple to use.  Its one of the big challenges (along with federated data) that Shadow IT gives to organisations and so far the security world's only response has been "don't do that". Yes.  However, distributed and federated trust is a very tough problem - perhaps even insoluble (I think it may be mathematically "complete") - if you follow current IT industry approaches to implementing enterprise software.  I am talking about this in my blog at the moment: A very common business situation is that the parties to a collaborative work process may change as the process unfolds - not just the assignment of identities to Roles, but the Roles they play and the nature of these Roles. Think about any work process you personally engage in. By and large, the nature of your work (and that of each of your colleagues) is likely to change at some point during the process, often repeatedly. This is what I mean by "dynamic" RBAC. We are moving to a world in which work processes are distributed across the Internet, so we need Internet-wide dynamic RBAC systems to secure these processes. However, current RBAC systems - which tend to be server-based - do not provide for this situation. They may allow for identities to be set dynamically, and sometimes for their assignment to Roles to be updated in use (though this can be cumbersome and poorly managed), but generally you must pre-configure the system with a set of Role definitions on deployment. To date, there is no operating platform in widespread usage that implements RBAC in a dynamic enough fashion to support the kind of adaptive business processes typical of modern human working practice. You can find the latest entry in this blog series, together with suggestions for solving the problem, at http://www.ebizq.net/blogs/it_directions/archives/2006/06/controlling_dis.php Some of you may recognize my position, since I outlined it a while back in this forum.  In brief, I think too much enterprise software assumes that interactivity should be controlled by servers.  I suspect we will settle in the end on a model in which interactive functionality including security is shunted onto clients, and servers are used mainly for non-interactive archiving/monitoring/analysis purposes. -- All the best Keith http://keith.harrison-broninski.info __._,_.___ SPONSORED LINKS Computer software Computer aided design software Computer job Soa Service-oriented architecture YAHOO! GROUPS LINKS  Visit your group "service-orientated-architecture" on the web.    To unsubscribe from this group, send an email to:  [EMAIL PROTECTED]    Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service. __,_._,___