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
