Replacement SecurityProvider for oak-server.

[Ian Boston <ie...@tfd.co.uk>]

Hi,
I see that the SecurityProvider reference in the oak-server bundle is
marked as Greedy, indicating the intention to allow a replacement service
from another bundle. I assume that was the intention ?

However, when I attempt to extract the Oak security subtree from oak-core
ie org.apache.jackrabbit.oak.security.* to modify it there are bindings to
org.apache.jackrabbit.oak.plugins.tree.impl.* which, obviously is not
exported from oak-core. Looking at the code that depends on that, it looks
like its impossible to implement a security provider without access to the
impl classes, as by its nature it will need to access the internals of oak.

My question:
Since Oak Security Providers that do something real with security, can't be
implemented outside of oak-core, should, in Sling we be promoting an OSGi
approach ?

This reminds me of the JR2 repository, where the only solution to adjusting
the security model to cover use cases not considered in JR2 was to do some
fairly nasty, and unmaintainable hacks. If there is an alternative way,
please say. I would rather not expose impl details of Oak core, or ask for
the classes to be moved.

Best Regards
Ian

Re: Replacement SecurityProvider for oak-server.

[Ian Boston <ie...@tfd.co.uk>]

Hi,
I agree with the approach taken by the Oak team, no point in creating api
bloat if there is no demand for it.

However, it seems that trying to do what I am doing outside Oak core really
is too hard, so I have opted to patch Oak core. Fortunately Oak core
appears well structured and the patch is relatively small.

I am however finding the Sling Authentication stack hard to work with a
user name and password go through many transformations before they
eventually arrive at the ContentRespositoryImpl.login method. There are
many pathways which a login operation could take scattered through several
bundles, each transformation obfuscating the operation. Obviously only 1
path is used, but finding it is non trivial. Thats just an observation, not
a request for change.

Best Regards
Ian

On 18 May 2015 at 10:03, Robert Munteanu <ro...@apache.org> wrote:

> Hi Ian,
>
> On Sat, 2015-05-09 at 08:41 +0100, Ian Boston wrote:
> > Hi,
> > I see that the SecurityProvider reference in the oak-server bundle is
> > marked as Greedy, indicating the intention to allow a replacement
> > service
> > from another bundle. I assume that was the intention ?
> >
> > However, when I attempt to extract the Oak security subtree from oak
> > -core
> > ie org.apache.jackrabbit.oak.security.* to modify it there are
> > bindings to
> > org.apache.jackrabbit.oak.plugins.tree.impl.* which, obviously is not
> > exported from oak-core. Looking at the code that depends on that, it
> > looks
> > like its impossible to implement a security provider without access
> > to the
> > impl classes, as by its nature it will need to access the internals
> > of oak.
> >
> > My question:
> > Since Oak Security Providers that do something real with security,
> > can't be
> > implemented outside of oak-core, should, in Sling we be promoting an
> > OSGi
> > approach ?
>
> Right now I have the feeling that the Oak extension points are mostly
> there to help the Oak team with their own modularisation, not
> necessarily to ease contribution of alternative implementations.
>
> The Oak team has asked a couple of times for specific use cases for
> opening up APIs, rather than building up those APIs up front, see [1]
> for instance.
>
> So one suggestion would be to take this to the Oak team and ask for
> opening up more APIs. Another would be to embed to inline/embed the
> needed dependencies in your bundle ( or make it a fragment of an Oak
> bundle with the needed packages ).
>
> HTH,
>
> Robert
>
> [1]: http://oak-dev.markmail.org/thread/bphfhla7wzrhdwlj
>
> >
> > This reminds me of the JR2 repository, where the only solution to
> > adjusting
> > the security model to cover use cases not considered in JR2 was to do
> > some
> > fairly nasty, and unmaintainable hacks. If there is an alternative
> > way,
> > please say. I would rather not expose impl details of Oak core, or
> > ask for
> > the classes to be moved.
> >
> > Best Regards
> > Ian
>
>

Re: Replacement SecurityProvider for oak-server.

[Robert Munteanu <ro...@apache.org>]

Hi Ian,

On Sat, 2015-05-09 at 08:41 +0100, Ian Boston wrote:
> Hi,
> I see that the SecurityProvider reference in the oak-server bundle is
> marked as Greedy, indicating the intention to allow a replacement 
> service
> from another bundle. I assume that was the intention ?
> 
> However, when I attempt to extract the Oak security subtree from oak
> -core
> ie org.apache.jackrabbit.oak.security.* to modify it there are 
> bindings to
> org.apache.jackrabbit.oak.plugins.tree.impl.* which, obviously is not
> exported from oak-core. Looking at the code that depends on that, it 
> looks
> like its impossible to implement a security provider without access 
> to the
> impl classes, as by its nature it will need to access the internals 
> of oak.
> 
> My question:
> Since Oak Security Providers that do something real with security, 
> can't be
> implemented outside of oak-core, should, in Sling we be promoting an 
> OSGi
> approach ?

Right now I have the feeling that the Oak extension points are mostly
there to help the Oak team with their own modularisation, not
necessarily to ease contribution of alternative implementations.

The Oak team has asked a couple of times for specific use cases for
opening up APIs, rather than building up those APIs up front, see [1]
for instance.

So one suggestion would be to take this to the Oak team and ask for
opening up more APIs. Another would be to embed to inline/embed the
needed dependencies in your bundle ( or make it a fragment of an Oak
bundle with the needed packages ).

HTH,

Robert

[1]: http://oak-dev.markmail.org/thread/bphfhla7wzrhdwlj

> 
> This reminds me of the JR2 repository, where the only solution to 
> adjusting
> the security model to cover use cases not considered in JR2 was to do 
> some
> fairly nasty, and unmaintainable hacks. If there is an alternative 
> way,
> please say. I would rather not expose impl details of Oak core, or 
> ask for
> the classes to be moved.
> 
> Best Regards
> Ian