You are viewing a plain text version of this content. The canonical link for it is here.
Posted to oak-dev@jackrabbit.apache.org by Jukka Zitting <ju...@gmail.com> on 2013/02/19 10:52:41 UTC
Time for jackrabbit-jcr-auth?
Hi,
When looking at the login() code for OAK-634 I realized that there's a
a lot of duplication between jackrabbit-core and oak-core in this
area.
Would it make sense to split out the authentication code to something
like jackrabbit-jcr-auth that could be used by both jackrabbit-core
and oak-core.
AFAICT there aren't too many places in the authentication code that
require deep integration with the repository internals (unlike in
authorization), so it should be possible to extract the relevant code
to a separate component. Or am I mistaken?
BR,
Jukka Zitting
Re: Time for jackrabbit-jcr-auth?
Posted by Angela Schreiber <an...@adobe.com>.
hi jukka
honestly, i fail to see the duplication apart from the fact the
there is a certain structure and flow of control given by the
java LoginModule base class.
the authentication in jackrabbit core was heavily depending on
jackrabbit core internals while the rewrite in oak doesn't make
use of JCR API altogether but only uses OAK API and the various
security related plugins (token provider API, principal look up
and so forth)...
in addition, what has been forced into a single login-module in
jackrabbit-core with a lot of ugly configuration options, has
been properly split up in oak in order to allow for proper
pluggability of different login-modules.
so, i don't see how a jackrabbit-jcr-auth module will add any benefit
in this particular situation... could it be that you mix your personal
view on how authentication may look like with the way it actually
works?
in summary and based on the APIs used the level of repo intergration
is actually the same for both authorization and authentication.
kind regards
angela
On 2/19/13 10:52 AM, Jukka Zitting wrote:
> Hi,
>
> When looking at the login() code for OAK-634 I realized that there's a
> a lot of duplication between jackrabbit-core and oak-core in this
> area.
>
> Would it make sense to split out the authentication code to something
> like jackrabbit-jcr-auth that could be used by both jackrabbit-core
> and oak-core.
>
> AFAICT there aren't too many places in the authentication code that
> require deep integration with the repository internals (unlike in
> authorization), so it should be possible to extract the relevant code
> to a separate component. Or am I mistaken?
>
> BR,
>
> Jukka Zitting
Re: Time for jackrabbit-jcr-auth?
Posted by Angela Schreiber <an...@adobe.com>.
hi felix
as explained in my reply to jukka the oak authentication doesn't
make use of JCR API but only uses OAK API and some additional
oak level pluggins.
you may want to follow OAK-608 that covers runtime pluggability
of the authentication setup as well as the various subtasks of
OAK-17 for the various other security related APIs that have
to be pluggable.
just yesterday i fixed an bug in the commit-hook setup (they
used to be immutable after the initial repo-setup) in order
to assert that runtime changes to the security modules get
reflect in the commit hook(s) as well... in other words: not yet
there but take for granted that it's not going to be left out
this time :-)
regards
angela
On 2/19/13 11:21 AM, Felix Meschberger wrote:
> Hi,
>
> If that's all, that is required, I am fine.
>
> Regards
> Felix
>
> PS: DefaultLoginModule uses SessionImpl, NodeImpl, and UserImpl. That would have to be fixed, I would assume ?
>
> Am 19.02.2013 um 11:08 schrieb Jukka Zitting:
>
>> Hi,
>>
>> On Tue, Feb 19, 2013 at 12:02 PM, Felix Meschberger<fm...@adobe.com> wrote:
>>> Can you separate API from implementation in the same step ?
>>
>> The way I see it, the APIs used by such a component should ultimately
>> be just JAAS and JCR.
>>
>> BR,
>>
>> Jukka Zitting
>
>
> --
> Felix Meschberger | Principal Scientist | Adobe
>
>
>
>
>
>
>
Re: Time for jackrabbit-jcr-auth?
Posted by Felix Meschberger <fm...@adobe.com>.
Hi,
If that's all, that is required, I am fine.
Regards
Felix
PS: DefaultLoginModule uses SessionImpl, NodeImpl, and UserImpl. That would have to be fixed, I would assume ?
Am 19.02.2013 um 11:08 schrieb Jukka Zitting:
> Hi,
>
> On Tue, Feb 19, 2013 at 12:02 PM, Felix Meschberger <fm...@adobe.com> wrote:
>> Can you separate API from implementation in the same step ?
>
> The way I see it, the APIs used by such a component should ultimately
> be just JAAS and JCR.
>
> BR,
>
> Jukka Zitting
--
Felix Meschberger | Principal Scientist | Adobe
Re: Time for jackrabbit-jcr-auth?
Posted by Jukka Zitting <ju...@gmail.com>.
Hi,
On Tue, Feb 19, 2013 at 12:02 PM, Felix Meschberger <fm...@adobe.com> wrote:
> Can you separate API from implementation in the same step ?
The way I see it, the APIs used by such a component should ultimately
be just JAAS and JCR.
BR,
Jukka Zitting
Re: Time for jackrabbit-jcr-auth?
Posted by Felix Meschberger <fm...@adobe.com>.
Hi
Can you separate API from implementation in the same step ?
Currently API and implementation is "nicely" mixed, which makes it close to impossible to properly use in an OSGi context.
Regards
Felix
Am 19.02.2013 um 10:52 schrieb Jukka Zitting:
> Hi,
>
> When looking at the login() code for OAK-634 I realized that there's a
> a lot of duplication between jackrabbit-core and oak-core in this
> area.
>
> Would it make sense to split out the authentication code to something
> like jackrabbit-jcr-auth that could be used by both jackrabbit-core
> and oak-core.
>
> AFAICT there aren't too many places in the authentication code that
> require deep integration with the repository internals (unlike in
> authorization), so it should be possible to extract the relevant code
> to a separate component. Or am I mistaken?
>
> BR,
>
> Jukka Zitting
--
Felix Meschberger | Principal Scientist | Adobe