Niclas,
Take a look at how the XACML folks are trying to represent
access controls. It might be worth basing the XML on XACML
or a subset of it.
I'm not very familiar yet (will be looking into it soon) but
I think there might be something there. If XACML becomes the
de facto standard for representing permissions in XML then
perhaps we should consider using it.
Alex
>
> From: Niclas Hedhman <[EMAIL PROTECTED]>
> Date: 2004/01/04 Sun AM 08:02:06 EST
> To: [EMAIL PROTECTED]
> Subject: Codebase level security
>
>
> Gang,
>
> Since deployment went fairly well, I now want to look into codebase level
> Security (scheduled for 3.4).
>
> NOTE!!! Please don't confuse this with Subject level Security and JAAS
> leveraging. That is the next step. This must be sorted out first.
>
>
> I have in mind that for each container's classloader declaration, the
> permissions are given;
>
> <container>
> <classloader>
>
> <classpath>
> :
> </classpath>
>
> <permissions>
> <permission
> class="java.util.PropertyPermission"
> name="java.home"
> actions="read" />
> <permission
> class="java.io.FilePermission"
> name="${merlin.home}/temp/"
> actions="read,write" />
> <permission
> class="java.awt.AWTPermission"
> name="accessClipboard" />
> </permissions>
> </classloader>
> </container>
>
> I hope you get the idea...
>
> For nested containers, I am planning to require that the outer container also
> declares the nested container's requirements.
> ( It would be a typical job for GUI tool to aggregate the security permissions
> up the hierarchy. )
>
> I am not planning to have the assembly figure out if the permission
> declarations are "compatible", i.e. if the inner-container is requesting more
> permissions than its parent container. At least not initially. I think that
> is also more of a tool thing.
>
> I think that the only position where the access control context can safely be
> established is in the BlockInvocationHandler and the
> ApplianceInvocationHandler, which are dynamic proxies forwarding the call to
> the component.
>
> The main "hurdle" I see now is to get the permission elements into the
> ClassloaderModel instance, which will create the access control context.
>
> Any comments so far???
>
> Niclas
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
