[
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