You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@jackrabbit.apache.org by Rory Douglas <ro...@gmail.com> on 2009/01/11 17:53:19 UTC

Admin identity for DefaultAccessManager and a JAAS LoginModule

Is there a way to configure the DefaultAccessManager (in 1.5) to recognize a
specific user/subject from a JAAS LoginModule as the Admin ID?

I see this is configurable for the DefaultLoginModule in repository.xml.  I
also see that DefaultAccessManager makes a determination based on the class
of the Principals a Subject has (o.a.j.c.security.SystemPrincipal or
o.a.j.c.security.principal.AdminPrincipal).  With a 3rd-party LoginModule, I
can't force the Principals to be of a particular class.

Do I need to extend DefaultAccessManager to enable configuring the AdminID,
or is there a configuration option for this I'm unaware of?  I'm using the
JDK 6 LdapLoginModule at the moment, and the latest trunk version of Sling
(but I'm fairly sure this is a purely Jackrabbit-related issue).

Regards
Rory

Re: Admin identity for DefaultAccessManager and a JAAS LoginModule

Posted by Angela Schreiber <an...@day.com>.
hi rory

> I placed my Admin user on the root ACL, because I couldn't figure out how to
> get the Sun LDAPLoginModule to provide Group principals.  I also use an
> Admin user with an identical ID to the default.

ok... let me take a closer look at it as soon as
i have some time left. i don't know the details
of the LDAPLoginModule.

> I was still getting errors on startup, but these turned out to be due to a
> lot of Session being created at Sling startup,

that's probably something for the Sling list, isn't it?

> Thanks for your help

you 're welcome

regards
angela

Re: Admin identity for DefaultAccessManager and a JAAS LoginModule

Posted by Rory Douglas <ro...@gmail.com>.
Thanks Angela

I placed my Admin user on the root ACL, because I couldn't figure out how to
get the Sun LDAPLoginModule to provide Group principals.  I also use an
Admin user with an identical ID to the default.

I was still getting errors on startup, but these turned out to be due to a
lot of Session being created at Sling startup, and my local OpenLDAP was not
handling all the concurrent logins.  Once these startup tasks complete, the
setup works fine.  I think I'll just stick with the default Jackrabbit
LoginModule for now, since it handles the concurrent logins far better.

Thanks for your help
Regards,
Rory


On Fri, Jan 16, 2009 at 4:12 AM, Angela Schreiber <an...@day.com> wrote:

> hi
>
>  Does anyone have an insight into this problem?  Are there people on this
>> list using pre-built JAAS LoginModules with Jackrabbit?
>>
>
> i didn't up to now.
>
> basically the access evaluation should work even if
> there is not admin/system principal. the workspace
> access if i'm not mistaken just uses it as shortcut
> (and so does the the access control provider) and
> otherwise starts the general access evaluation process.
>
>  If I start with a working configuration (using DefaultAccessManager and
>> DefaultLoginModule), and add a login.conf file that configures the Sun
>> LdapLoginModule, my Session logins throw exceptions "Unable to access
>> workspace 'default'".
>>
>
> but i'd say that this is not primarily caused by
> the principal classes but rather by the fact that your
> user doesn't have any acl-entries set thus isn't
> allowed anything.
>
> what happens is:
> - default security manager retrieves adminId from
>  config (or uses default values)
> - .. and creates system users:
>  > admin, anonymous and administrators
>  > adds admin to administrators group
> - acl provider creates minimal acls on the root
>  > allowing read for everybody
>  > allowing all permissions for the admins
>
> now, with your custom login-module i assume that you
> - don't pass the adminId to the security manager
> - don't have everybody principal added to the set of
>  principals present with the subject.
>
> consequently, the ac-evaluation will not find any
> matching aces for your set of principals.
>
> regards
> angela
>
>
>
>
>

Re: Admin identity for DefaultAccessManager and a JAAS LoginModule

Posted by Angela Schreiber <an...@day.com>.
hi

> Does anyone have an insight into this problem?  Are there people on this
> list using pre-built JAAS LoginModules with Jackrabbit?

i didn't up to now.

basically the access evaluation should work even if
there is not admin/system principal. the workspace
access if i'm not mistaken just uses it as shortcut
(and so does the the access control provider) and
otherwise starts the general access evaluation process.

> If I start with a working configuration (using DefaultAccessManager and
> DefaultLoginModule), and add a login.conf file that configures the Sun
> LdapLoginModule, my Session logins throw exceptions "Unable to access
> workspace 'default'".

but i'd say that this is not primarily caused by
the principal classes but rather by the fact that your
user doesn't have any acl-entries set thus isn't
allowed anything.

what happens is:
- default security manager retrieves adminId from
   config (or uses default values)
- .. and creates system users:
   > admin, anonymous and administrators
   > adds admin to administrators group
- acl provider creates minimal acls on the root
   > allowing read for everybody
   > allowing all permissions for the admins

now, with your custom login-module i assume that you
- don't pass the adminId to the security manager
- don't have everybody principal added to the set of
   principals present with the subject.

consequently, the ac-evaluation will not find any
matching aces for your set of principals.

regards
angela





Re: Admin identity for DefaultAccessManager and a JAAS LoginModule

Posted by Rory Douglas <ro...@gmail.com>.
Hi there
Does anyone have an insight into this problem?  Are there people on this
list using pre-built JAAS LoginModules with Jackrabbit?

If I start with a working configuration (using DefaultAccessManager and
DefaultLoginModule), and add a login.conf file that configures the Sun
LdapLoginModule, my Session logins throw exceptions "Unable to access
workspace 'default'".

Looking through the code, I can only see 2 options:

1) Implement my own WorkspaceAccessManager and configure via SecurityManager
2) Keep the working setup, add the admin ID to an ACL on the root path, with
all permissions, then switch to the JAAS setup

#1 doesn't look like a solution since in the case of a non-Admin ID I'd like
to delegate to the AccessControlProvider of the workspace, but
getAccessControlProvider(workspaceName) is private in
DefaultSecurityManager.

#2 might work, but I'm not sure I won't run into issues later, since several
of the default security/auth classes hard-code an isAdminOrSystem method
that only consider the 2 Jackrabbit principals as such.

There is an option #3 which is extend or (more probably due to
private/protected methods) re-implement all the Default... security classes
which seems crazy.

Any ideas/experience with this?

Regards,
Rory


On Sun, Jan 11, 2009 at 11:53 AM, Rory Douglas <ro...@gmail.com>wrote:

> Is there a way to configure the DefaultAccessManager (in 1.5) to recognize
> a specific user/subject from a JAAS LoginModule as the Admin ID?
>
> I see this is configurable for the DefaultLoginModule in repository.xml.  I
> also see that DefaultAccessManager makes a determination based on the class
> of the Principals a Subject has (o.a.j.c.security.SystemPrincipal or
> o.a.j.c.security.principal.AdminPrincipal).  With a 3rd-party LoginModule, I
> can't force the Principals to be of a particular class.
>
> Do I need to extend DefaultAccessManager to enable configuring the AdminID,
> or is there a configuration option for this I'm unaware of?  I'm using the
> JDK 6 LdapLoginModule at the moment, and the latest trunk version of Sling
> (but I'm fairly sure this is a purely Jackrabbit-related issue).
>
> Regards
> Rory
>