Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [equinox-dev] principal based permissions in osgi 
Hi Pascal,
IANAE (I am not an expert), but I've had some recent experience with this in my 'day job' that I thought I would quickly share.
I learned that with the default vm Policy implementation (java.security.Policy), a call to Subject.doAsPriviledged results in the java.security.Policy.getPermissions(ProtectionDomain domain) method being called. With the default security Policy the PermissionCollection returned by this call is the set of permissions associated with the Subject in the (vm-wide) security.policy file. 
For example, something like:

grant principal javax.security.auth.x500.X500Principal "cn=Alice" {
    permission java.io.FilePermission "/home/Alice", "read, write";
};
would specifiy that FilePermission (as specified above) would be included in the PermissionCollection returned when the Subject calling doAsPriviledged was called (and the Subject had the principal "cn=Alice" attached to it via login).
In my recent work, we replaced the default Policy with our own, overriding the getPermissions(ProtectionDomain domain) method and look up Principal->Permissions assignments in a db. This works extremely well for us, as we can specify permissions associated with each Principal separately, and use the same Policy code to implement the getPermissions call to use our Principal->Permissions relationships rather than from the security policy file's 'grant principal ...' as in the example above.
The interesting thing is that the ProtectionDomain *only as of 1.4.X* standard edition has the method domain.getPrincipals() even existed. This returns a Principal [], which is potentially *different for every call* of getPermissions(), as the Subject.doAsPriviledged provides the context of which principals are associated with the getPermissions() call (those principals associated with the given Subject...i.e. Subject.getPrincipals()).
I've thought for some time that one thing Eclipse/RCP could do is to implement an eclipse-specific security policy implementation, which assumes that the principal->permissions association is persisted via some plugin (or in some Eclipse/RCP-specific way). It would also be possible to make this getPermissions call much more efficient (i.e. short circuiting the typical calls in the case of certain permissions) and reduce some of the runtime complexity of turning on the security manager and running Eclipse/RCP with the default Policy.
Again, I'll qualify my comments with IANAE, but these have been my recent experiences. 

Scott


Pascal Rapicault wrote:



Hi,
Lately I've been looking at JAAS and its capability to dynamically associate permissions based on principals (usually declared in a policy file) and from that to use Subject.doAsPriviledged. Given that OSGi has its own way of expressing permissions, I would like to understand how principal based permissions can be declared. 

Thank you,

PaScaL

------------------------------------------------------------------------

_______________________________________________
equinox-dev mailing list
equinox-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/equinox-dev

Back to the top