river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gregg Wonderly <ge...@cox.net>
Subject Re: Subtleties of JAAS in an internet djinn (was Distributed Network Security)
Date Sun, 22 Jul 2012 18:39:48 GMT

On Jul 22, 2012, at 5:04 AM, Peter Firmstone wrote:

> Since Gregg hasn't utilised traditional jvm style Permissions for Principals, there is
no possibility of elevating privileges when calling Subject.doAs, so granting "doAs" to untrusted
code doesn't present any security risk in Gregg's use case.

Just to make it clear, I do this precisely because the JVM permissions and principals with
SecurityContext and all the other details are horribly complex for a developer and deployer
to evaluate.  It becomes very problematic over the lifetime of a deployment to know when someone
maybe calling from a new context that requires a specific security configuration to confine
a use case to some limited set of permissions.

Practically, I just don't see the value in that.  I'd rather write utility methods, and call
them from validated contexts with only the single entry point to validate.  The Apple world
drove security down the path it went, because there was no "authentication" possible, at first,
and then when signed jars were added, the code source, not the user was responsible for declaring
it's intent.

My PAM login module uses password access in my applications.  My customers use a product that
provides PAM access to the Windows directory services for authentication.  So there is no
local administration of that, on the servers.  

> Also it's worth noting the Policy implementation can provide support, so changes to Subject
Principals are effective immediately, leading to a much more programmer friendly JAAS.

I think that this security stuff, is a fairly large reason why Jini becomes overwhelming so
quickly.  The simple fact that XXX.doAS and the security manager are never part of general
Java programming education makes their introduction into the thought process very problematic.

Gregg Wonderly
View raw message