[
Lists Home |
Date Index |
Thread Index
]
> From: Paul Prescod [mailto:paul@prescod.net]
<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.
|
