You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sling.apache.org by Christophe Lombart <ch...@gmail.com> on 2009/09/14 16:59:44 UTC
Managing users/group from an external system
Hi,
In our Sling application, we would like to externalize the user/group
management.
I'm not the jackrabbit security expert but it seems that should be
possible with a custom UserManager. I think it is not possible to plug
my custom UserManager implementation as a bundle.
So, what is the best approach for that kind of externalisation ? Do I
have create my own JackrabbitSecurityManager ?
Can you just let me know if I'm in the good direction ?
thanks
Christophe
Re: Managing users/group from an external system
Posted by Juan José Vázquez Delgado <ju...@gmail.com>.
> It was my first idea for create a LoginModulePlugin and maybe an
> AccessManagerPlugin but I'm wondering if it is not easier in my case
> to just create a custom implementation of UserManager because my
> authentication process is the same as the Sling default one but with
> the usage of a different/external user storage.
>
> What do you think about that ? Is not a good solution ?
You might have a look at [1]. This approach would be to implement a
custom o.a.s.engine.auth.AuthenticationHandler like it´s done in [2].
Regards,
Juanjo.
[1] http://svn.apache.org/repos/asf/sling/trunk/bundles/extensions/openidauth
[2] http://svn.apache.org/repos/asf/sling/trunk/bundles/extensions/openidauth/src/main/java/org/apache/sling/openidauth/impl/OpenIDAuthenticationHandler.java
Re: Managing users/group from an external system
Posted by Vidar Ramdal <vi...@idium.no>.
On Tue, Sep 15, 2009 at 1:30 PM, Christophe Lombart
<ch...@gmail.com> wrote:
> It was my first idea for create a LoginModulePlugin and maybe an
> AccessManagerPlugin but I'm wondering if it is not easier in my case
> to just create a custom implementation of UserManager because my
> authentication process is the same as the Sling default one but with
> the usage of a different/external user storage.
You don't have to implement an AccessManagerPlugin unless you want
something else than an Access Control List.
In my case, I wanted to implement access control policies such as "let
this node be available only on Fridays", so I had to implement my own
AMP.
If you're happy with setting access control rights as you would in an
operating system, go with the default AccessManager.
I'm not sure, but I suspect it would be sufficient to implement a
LoginModulePlugin. The LMP will then issue Principals, consumed by the
AM. The UserManager is only used when you want to store your user data
in the Jackrabbit repository itself - which it sounds you won't do
("externalize the user/group management").
--
Vidar S. Ramdal <vi...@idium.no> - http://www.idium.no
Sommerrogata 13-15, N-0255 Oslo, Norway
+ 47 22 00 84 00 / +47 21 531941, ext 2070
Re: Managing users/group from an external system
Posted by Christophe Lombart <ch...@gmail.com>.
Hi,
It was my first idea for create a LoginModulePlugin and maybe an
AccessManagerPlugin but I'm wondering if it is not easier in my case
to just create a custom implementation of UserManager because my
authentication process is the same as the Sling default one but with
the usage of a different/external user storage.
What do you think about that ? Is not a good solution ?
Christophe
2009/9/14 Juan José Vázquez Delgado <ju...@gmail.com>:
> Hi,
>
>> I'm not the jackrabbit security expert but it seems that should be
>> possible with a custom UserManager. I think it is not possible to plug
>> my custom UserManager implementation as a bundle.
>
> You might want to have a look at jackrabbit-usermanager [1] and
> jackrabbit-accessmanager [2] bundles.
>
>>
>> So, what is the best approach for that kind of externalisation ? Do I
>> have create my own JackrabbitSecurityManager ?
>
> I don´t know if it´s the best approach but consider to leverage [1] to
> write your own user manager module. For instance:
>
> /**
> * @scr.component label="%myCustomLoginModule.name"
> description="%myCustomLoginModule.description" immediate="true"
> * @scr.service
> interface="org.apache.sling.jcr.jackrabbit.server.security.LoginModulePlugin"
> */
> public class MyCustomLoginModule implements LoginModulePlugin {
>
> .....................
>
> public AuthenticationPlugin getAuthentication(Principal principal,
> Credentials creds) throws RepositoryException {
> return new CustomAuthenticationPlugin();
> }
>
> ....................
>
> }
>
> Hope this helps.
>
> BR,
>
> Juanjo.
>
> [1] http://svn.apache.org/repos/asf/sling/trunk/bundles/jcr/jackrabbit-usermanager
> [2] http://svn.apache.org/repos/asf/sling/trunk/bundles/jcr/jackrabbit-accessmanager
>
Re: Managing users/group from an external system
Posted by Juan José Vázquez Delgado <ju...@gmail.com>.
Hi,
> I'm not the jackrabbit security expert but it seems that should be
> possible with a custom UserManager. I think it is not possible to plug
> my custom UserManager implementation as a bundle.
You might want to have a look at jackrabbit-usermanager [1] and
jackrabbit-accessmanager [2] bundles.
>
> So, what is the best approach for that kind of externalisation ? Do I
> have create my own JackrabbitSecurityManager ?
I don´t know if it´s the best approach but consider to leverage [1] to
write your own user manager module. For instance:
/**
* @scr.component label="%myCustomLoginModule.name"
description="%myCustomLoginModule.description" immediate="true"
* @scr.service
interface="org.apache.sling.jcr.jackrabbit.server.security.LoginModulePlugin"
*/
public class MyCustomLoginModule implements LoginModulePlugin {
.....................
public AuthenticationPlugin getAuthentication(Principal principal,
Credentials creds) throws RepositoryException {
return new CustomAuthenticationPlugin();
}
....................
}
Hope this helps.
BR,
Juanjo.
[1] http://svn.apache.org/repos/asf/sling/trunk/bundles/jcr/jackrabbit-usermanager
[2] http://svn.apache.org/repos/asf/sling/trunk/bundles/jcr/jackrabbit-accessmanager
Re: Managing users/group from an external system
Posted by Christophe Lombart <ch...@gmail.com>.
Thanks to all for the inputs. We will start with a custom
LoginModulePlugin & AccessManagerPlugin.
Christophe
2009/9/15 Ian Boston <ie...@tfd.co.uk>:
>
> On 15 Sep 2009, at 00:59, Christophe Lombart wrote:
>
>> Hi,
>>
>> In our Sling application, we would like to externalize the user/group
>> management.
>> I'm not the jackrabbit security expert but it seems that should be
>> possible with a custom UserManager. I think it is not possible to plug
>> my custom UserManager implementation as a bundle.
>>
>> So, what is the best approach for that kind of externalisation ? Do I
>> have create my own JackrabbitSecurityManager ?
>
>
> Creating or extending the default JackrabbitSecurityManager impl will give
> you complete control over the various other security related classes that
> are required by Jackrabbit.
> I have also extended/reimplented that class so that I could replace the
> AccessControlProvider and other core items. The only difficulty with doing
> this is the default JackrabbitSecurityManager implementation is relatively
> complex and has some package protection, so I had to repackage/extend the
> standard jackrabbit server bundle in order to modify the behavior.
>
> If you decide that you want to get near to externalizing AuthZ as apposed to
> AuthN, then one thing that becomes relevant is the performance of the AuthZ
> system, which is highly optimized and is unlikely to work with external
> sources of information unless some care is taken. For instance, the
> principals associated with a user are resolved at the session login which in
> sling is pooled with user affinity (ie the same session can be retrieved
> from the pool with some state on subsequent requests), so if you modify the
> AccessControlProvider (or reimpliment it) then you will need to make certain
> that each ACL resolution does not result in a network operation, as
> Jackrabbit will certainly crawl if that happens.
>
> The same is true, to a lesser extent with the UserManager which needs to
> resolve group membership questions. If these result in masses of network
> operations, Jackrabbit will also crawl.
>
> Rather than replace the highly efficient UserManager and
> AccessControlProvider, we have opted to create patched versions that use the
> default functionality for many of the operations, but provide extension
> hooks for integration with 3rd party data sources where necessary. I
> recently updated some of the documentation associated with the project at
> [1],[2] which may give you an insight into the approach, with code at [3].
> This is not core Sling or Jackrabbit and represents a patch to both, which
> cant easily be accommodated in core Jackrabbit.
>
> Ian
>
> [1]
> http://confluence.sakaiproject.org/display/KERNDOC/Sling+AuthZ+Implementation+Plan
> [2]
> http://confluence.sakaiproject.org/display/KERNDOC/Configuring+Users+and+Groups
> [3]
> http://github.com/ieb/open-experiments/tree/master/slingtests/osgikernel/bundles/server/
>
>> Can you just let me know if I'm in the good direction ?
>>
>> thanks
>> Christophe
>
>
Re: Managing users/group from an external system
Posted by Ian Boston <ie...@tfd.co.uk>.
On 15 Sep 2009, at 00:59, Christophe Lombart wrote:
> Hi,
>
> In our Sling application, we would like to externalize the user/group
> management.
> I'm not the jackrabbit security expert but it seems that should be
> possible with a custom UserManager. I think it is not possible to plug
> my custom UserManager implementation as a bundle.
>
> So, what is the best approach for that kind of externalisation ? Do I
> have create my own JackrabbitSecurityManager ?
Creating or extending the default JackrabbitSecurityManager impl will
give you complete control over the various other security related
classes that are required by Jackrabbit.
I have also extended/reimplented that class so that I could replace
the AccessControlProvider and other core items. The only difficulty
with doing this is the default JackrabbitSecurityManager
implementation is relatively complex and has some package protection,
so I had to repackage/extend the standard jackrabbit server bundle in
order to modify the behavior.
If you decide that you want to get near to externalizing AuthZ as
apposed to AuthN, then one thing that becomes relevant is the
performance of the AuthZ system, which is highly optimized and is
unlikely to work with external sources of information unless some care
is taken. For instance, the principals associated with a user are
resolved at the session login which in sling is pooled with user
affinity (ie the same session can be retrieved from the pool with some
state on subsequent requests), so if you modify the
AccessControlProvider (or reimpliment it) then you will need to make
certain that each ACL resolution does not result in a network
operation, as Jackrabbit will certainly crawl if that happens.
The same is true, to a lesser extent with the UserManager which needs
to resolve group membership questions. If these result in masses of
network operations, Jackrabbit will also crawl.
Rather than replace the highly efficient UserManager and
AccessControlProvider, we have opted to create patched versions that
use the default functionality for many of the operations, but provide
extension hooks for integration with 3rd party data sources where
necessary. I recently updated some of the documentation associated
with the project at [1],[2] which may give you an insight into the
approach, with code at [3]. This is not core Sling or Jackrabbit and
represents a patch to both, which cant easily be accommodated in core
Jackrabbit.
Ian
[1] http://confluence.sakaiproject.org/display/KERNDOC/Sling+AuthZ+Implementation+Plan
[2] http://confluence.sakaiproject.org/display/KERNDOC/Configuring+Users+and+Groups
[3] http://github.com/ieb/open-experiments/tree/master/slingtests/osgikernel/bundles/server/
> Can you just let me know if I'm in the good direction ?
>
> thanks
> Christophe