Re: [equinox-dev] principal based permissions in osgi

[Thomas Watson <tjwatson@xxxxxxxxxx>]

I went ahead and released the FrameworkSecurityManager
patch provided by Ben so that progress can be made with Principal base
conditions.  There was one thing wrong with the PrinicipalCondition
implementation.  The static getInstance method should really be getCondition.
 Attached is a working PrincipalCondition implementation.



Tom

Benjamin Reed <breed@xxxxxxxxxxxxxxx>
Sent by: equinox-dev-bounces@xxxxxxxxxxx

09/17/2005 11:52 PM

Please respond to
Equinox development mailing list

To	equinox-dev@xxxxxxxxxxx
cc	Pascal Rapicault <Pascal_Rapicault@xxxxxxxxxx>
Subject	Re: [equinox-dev] principal based permissions in osgi

Here is a patch to FrameworkSecurityManager and an
implementation of 
PrincipalCondition. Subject.doAsXXX() methods function as normal. Principal
to Permission bindings are done through ConditionalPermissionAdmin. For
example, a ConditionalPermissionInfo of the form:

[...BundleLocationCondition http://www.ibm.com/-]
[...PrincipalCondition SuperMan]
(java.security.AllPermission)

says that when classes from a bundle from www.ibm.com are run with SuperMan
set as the current Subject, they will have AllPermission.

Initial tests (thanx Pascal) indicate that it's working.

One thing (of many) to remember when playing with JAAS is that 
Subject.doAsXXX() is a glorified AccessController.doPrivileged(). The biggest
outcome is that a Subject (and it's principals) get associated with a new
 
AccessControlContext. A subtle effect of this is that if a doPrivileged
is 
done inside of a doAsXXX() the new AccessControlContext setup by the 
doPrivileged will lose the Subject.

The current AccessControlContext (ACC) can be extracted using 
SecurityManager.getSecurityContext(), passed around, and evaluated directly
using SecurityManager.checkPermission(Permission, Object). It is for this
reason that PrincipalCondition needs to get a reference to the ACC being
checked, since it may not be the same as the one returned from 
AccessController.getContext().

The attached patch adds a method for the PrincipalCondition to get the
ACC 
being evaluated so that we can get the Subject of correct ACC. Because
PrincipalCondition depends on a SecurityManager that has the added methods,
the implementation of PrincipalCondition is not portable (it cannot be
run on 
other OSGi implementations). It would be nice to standardize a way for
Conditions to get the ACC being evaluated. If in the future DomainCombiners
are used in other ways, corresponding conditions would also need the ACC.

ben

On Thursday 15 September 2005 12:00 pm, 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
[attachment "FrameworkSecurityManager.patch" deleted by Thomas
Watson/Austin/IBM] [attachment "PrincipalCondition.java" deleted
by Thomas Watson/Austin/IBM] _______________________________________________
equinox-dev mailing list
equinox-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/equinox-dev

Attachment: PrincipalCondition.java
Description: Binary data