[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [equinox-dev] principal based permissions in osgi
|
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