[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] RE: SOAP-RPC and REST and security
> From: Paul Prescod [mailto:paul@p...] <snip/> > I talked to an EJB expert about REST. We were talking about security > models. I described how REST has a natural ACL or capabilities model. > What's the natural model of RMI (which is basically OO RPC with class > distribution)? He said that there is some interface you hook in > arbitrary code and throw an exception if something is wrong. I asked > "how is that different than just rolling most of the security > yourself." > He shrugged. Not really. Now do you think that your average > sysadmin is > going to write Java code to help secure the app? No, they can't. That > means that all security is in the hands of the developers. They are > required more or less to invent a new permissions model > (probably an ACL > workalike) for each app. I would dispute this. The "hooks" that J2EE provide is designed to allow plugging in standardized security models rather than handcrafting one for each individual app. Certainly, you have that option of just rolling most of the security yourself. But there are also vendors like Netegrity who have built their business model on providing middleware for standardized security models enforced across the enterprise -- both web-based and "traditional" client/server apps. When a company takes an existing ERP or other enterprise app and wishes to expose a web interface, why would they want to have to define a redundant security model just for the web server? Integrating the security model with the web server in a clean fashion may make sense -- and AFAIK you can do that with J2EE (as long as the web server supports that). J2EE does not force you to hand roll security yourself; it just gives you that option, as well as the option of having a security model that is standardized across the enterprise -- even for non-web-based apps. Beyond that, many systems need security models that go beyond simple ACLs. We have field-level security in our system, and ACLs don't cut it for that. I think that it is increasingly common for enterprise systems to use more dynamic, rule-based security systems, and evaluating the rules properly requires intimate knowledge of the internals of the system. Many of the applications that will be exposed as web services will also have other interfaces that are not web-based. They will need mechanisms that permit *all* of their interfaces to share a common security model. And typically this will entail security that goes beyond a simple ACL on a method call. Maybe I'm just naive, but based on the sort of work I've done, I don't see how HTTP security alone is going to be anywhere near adequate for the typical enterprise application. Although web servers with an open architecture that permit you to hook their authentication mechanism into external apps so that the security model can be shared would certainly facilitate, I think, a more REST-ful approach to this. I would be happy to learn more about how REST can help, here, but I am doubtful that it will be anywhere near a complete enough solution for many enterprise apps, much less an enterprise-wide or cross-enterprise integration strategy. The web is just an interface for these things, and security can not be web-centric; it just needs to integrate cleanly with web protocols.
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|