LDAP permissions persistence

[Conrad Leonard]

Hi;

I'm experiencing a few problems with LDAP authentication. In descending order of importance:

1. Permissions granted on users don't seem to persist after server restart. Here's what I'm doing:

I have the two groups set up in LDAP server with some users:

[conradL@qimr13054 stardog]$ ldapsearch  -LLL "CN=stardogSuperUsers" dn cn member -b "ou=Groups,dc=genomeinfo,dc=qimrberghofer,dc=edu,dc=au" -H ldap://bioldapv01.adqimr.ad.lan -D 'CN=manager,DC=genomeinfo,DC=qimrberghofer,DC=edu,DC=au' -y ~/.ldap.pwd

dn: cn=stardogSuperUsers,ou=Groups,dc=genomeinfo,dc=qimrberghofer,dc=edu,dc=au

cn: stardogSuperUsers

member: cn=conradL,ou=QIMR Users,ou=QIMR Accounts,dc=adqimr,dc=ad,dc=lan

[conradL@qimr13054 stardog]$ ldapsearch  -LLL "CN=stardogUsers" dn cn member -b "ou=Groups,dc=genomeinfo,dc=qimrberghofer,dc=edu,dc=au" -H ldap://bioldapv01.adqimr.ad.lan -D 'CN=manager,DC=genomeinfo,DC=qimrberghofer,DC=edu,DC=au' -y ~/.ldap.pwd

dn: cn=stardogUsers,ou=Groups,dc=genomeinfo,dc=qimrberghofer,dc=edu,dc=au

cn: stardogUsers

member: cn=johnPe,ou=QIMR Users,ou=QIMR Accounts,dc=adqimr,dc=ad,dc=lan

member: cn=oliverH,ou=QIMR Users,ou=QIMR Accounts,dc=adqimr,dc=ad,dc=lan

stardog.properties:

[conradL@qimr13054 stardog]$ cat $STARDOG_HOME/stardog.propertiessecurity.realms = ldap

ldap.provider.url = ldap://*************

ldap.security.principal = cn=manager,dc=genomeinfo,dc=qimrberghofer,dc=edu,dc=au

ldap.security.credentials = ***************

ldap.user.dn.template = cn={0},ou=QIMR Users,ou=QIMR Accounts,dc=adqimr,dc=ad,dc=lan

ldap.group.lookup.string = ou=Groups,dc=genomeinfo,dc=qimrberghofer,dc=edu,dc=au

ldap.users.cn = stardogUsers

ldap.superusers.cn = stardogSuperUsers

List the users:

[conradL@qimr13054 stardog]$ stardog-admin user list -u conradL
+----------+

| Username |

+----------+

+----------+

I kind of expected that, as users are defined in LDAP now.

List permissions on the sole superuser:

[conradL@qimr13054 stardog]$ stardog-admin user permission  -u conradL conradL

+---------------+---------------+-------------+-----------+

| Resource Type | Resource Name | Permissions |  Source   |

+---------------+---------------+-------------+-----------+

| *             | *             | CDRWGKX     | [conradL] |

+---------------+---------------+-------------+-----------+

List permissions on a non-superuser:

[conradL@qimr13054 stardog]$ stardog-admin user permission  -u conradL oliverH

User oliverH has no permissions.

Grant the non-superuser some perms:

[conradL@qimr13054 stardog]$ stardog-admin user grant -a read -o db:*  -u conradL oliverH

Successfully granted the permission.

[conradL@qimr13054 stardog]$ stardog-admin user permission  -u conradL oliverH

+---------------+---------------+-------------+-----------+

| Resource Type | Resource Name | Permissions |  Source   |

+---------------+---------------+-------------+-----------+

| db            | *             | --R----     | [oliverH] |

+---------------+---------------+-------------+-----------+

Server restart:

[conradL@qimr13054 stardog]$ stardog-admin server stop -u conradL && stardog-admin server start

Stardog server successfully received the shutdown request.

Jun 16, 2015 3:57:42 PM org.quartz.impl.StdSchedulerFactory instantiate

INFO: Using default implementation for ThreadExecutor

Jun 16, 2015 3:57:42 PM org.quartz.core.SchedulerSignalerImpl <init>

INFO: Initialized Scheduler Signaller of type: class org.quartz.core.SchedulerSignalerImpl

Jun 16, 2015 3:57:42 PM org.quartz.core.QuartzScheduler <init>

INFO: Quartz Scheduler v.2.1.3 created.

Jun 16, 2015 3:57:42 PM org.quartz.simpl.RAMJobStore initialize

INFO: RAMJobStore initialized.

Jun 16, 2015 3:57:42 PM org.quartz.core.QuartzScheduler initialize

INFO: Scheduler meta-data: Quartz Scheduler (v2.1.3) '33728776-263e-4407-afe5-67ab4e7c038c' with instanceId 'NON_CLUSTERED'

  Scheduler class: 'org.quartz.core.QuartzScheduler' - running locally.

  NOT STARTED.

  Currently in standby mode.

  Number of jobs executed: 0

  Using thread pool 'org.quartz.simpl.SimpleThreadPool' - with 10 threads.

  Using job-store 'org.quartz.simpl.RAMJobStore' - which does not support persistence. and is not clustered.

Jun 16, 2015 3:57:42 PM org.quartz.impl.StdSchedulerFactory instantiate

INFO: Quartz scheduler '33728776-263e-4407-afe5-67ab4e7c038c' initialized from an externally provided properties instance.

Jun 16, 2015 3:57:42 PM org.quartz.impl.StdSchedulerFactory instantiate

INFO: Quartz scheduler version: 2.1.3

Jun 16, 2015 3:57:42 PM org.quartz.core.QuartzScheduler start

INFO: Scheduler 33728776-263e-4407-afe5-67ab4e7c038c_$_NON_CLUSTERED started.

Jun 16, 2015 3:57:42 PM com.complexible.stardog.security.impl.AbstractExistingSecurityResourcesLoader permissionsMap

WARNING: Ignoring permission for unrecognized subject: tag:stardog.com:2011-10-11:stardog:security:User-4iwpi3j1tboxrtshhafjssdtv

************************************************************

This copy of Stardog is licensed to Conrad Leonard (conrad....@qimrberghofer.edu.au), QIMR Berghofer Medical Research Institute

This is a Community license

This license does not expire.

************************************************************

                                                             :;   

                                      ;;                   `;`:   

  `'+',    ::                        `++                    `;:`  

 +###++,  ,#+                        `++                    .     

 ##+.,',  '#+                         ++                     +    

,##      ####++  ####+:   ##,++` .###+++   .####+    ####++++#    

`##+     ####+'  ##+#++   ###++``###'+++  `###'+++  ###`,++,:     

 ####+    ##+        ++.  ##:   ###  `++  ###  `++` ##`  ++:      

  ###++,  ##+        ++,  ##`   ##;  `++  ##:   ++; ##,  ++:      

    ;+++  ##+    ####++,  ##`   ##:  `++  ##:   ++' ;##'#++       

     ;++  ##+   ###  ++,  ##`   ##'  `++  ##;   ++:  ####+        

,.   +++  ##+   ##:  ++,  ##`   ###  `++  ###  .++  '#;           

,####++'  +##++ ###+#+++` ##`   :####+++  `####++'  ;####++`      

`####+;    ##++  ###+,++` ##`    ;###:++   `###+;   `###++++      

                                                    ##   `++      

                                                   .##   ;++      

                                                    #####++`      

                                                     `;;;.        

************************************************************

Stardog server 3.0.2 started on Tue Jun 16 15:57:42 AEST 2015.

Stardog server is listening on all network interfaces.

SNARL server available at snarl://localhost:5820.

HTTP server available at http://localhost:5820.

STARDOG_HOME=/data/stardog 

LOG_FILE=/data/stardog/stardog.log

(notice the WARNING: Ignoring permission for unrecognized subject)

query permissions for the non-superuser:

[conradL@qimr13054 stardog]$ stardog-admin user permission  -u conradL oliverH

User oliverH has no permissions.

I note that I am using the cn attribute rather than uid in order to form user's dn, as this is the way that our LDAP schema is currently set up, and because docs don't explicitly state that uid is a special attribute in this regard (although I see that the examples provided use uid). The rest of Stardog LDAP integration seems happy enough to accept a dn formed using cn, but does the persistence of permissions in fact require that users have a uid attribute? If not, what else may be going on here?

2. An LDAP-authenticated user with read permissions on all databases and metadata gets 'Permission denied' message when attempting to log in from the webconsole login page http://<server>:<port>/#/login, although if they go directly to a permitted database url e.g.  http://<server>:<port>/<database>#!/schema then they are prompted with a pop-up login dialog, which correctly allows access.

3. When LDAP authentication is enabled, the Users screen under webconsole "Security" menu shows nothing, although both stardogUsers and stardogSuperUsers groups have members. This isn't a big deal, but I would expect that the users named in those groups should be displayed here.

[Conrad Leonard]

I should say, same behaviour in 3.1

This copy of Stardog is licensed to Conrad Leonard (conrad.leonard@qimrberghofer.edu.au), QIMR Berghofer Medical Research Institute

[Michael Grove]

Thanks for the report.  We're looking into this.

Cheers,

Mike

 

--
-- --
You received this message because you are subscribed to the C&P "Stardog" group.
To post to this group, send email to sta...@clarkparsia.com
To unsubscribe from this group, send email to
stardog+u...@clarkparsia.com
For more options, visit this group at
http://groups.google.com/a/clarkparsia.com/group/stardog?hl=en

[Michael Grove]

On Tue, Jun 16, 2015 at 2:30 AM, Conrad Leonard <conrad....@hotmail.com> wrote:

The disconnect between cn and uid is basically the issue here.  We're correctly using 'cn' for authz, but we're using the default of 'uid' when listing users, which was the give away on the issue.  You should have seen the full list of users when you listed them on the command line.  While LDAP handles user management, we treat it as a read only source, so you should still be able to list them, just not add to that list.

Because we're not correctly listing the users, on restart, when we try to associate the known permissions with the users coming from LDAP, that fails because we don't see any of the users.

This is also the cause of the third issue you mention.  We created an issue for this, #2354, and it will be fixed for the next release. 

 

2. An LDAP-authenticated user with read permissions on all databases and metadata gets 'Permission denied' message when attempting to log in from the webconsole login page http://<server>:<port>/#/login, although if they go directly to a permitted database url e.g.  http://<server>:<port>/<database>#!/schema then they are prompted with a pop-up login dialog, which correctly allows access.

This is due to a difference in LDAP vs native security.  When users are added to the system normally, we assert the permission that they can read themselves so that they're able to get their own roles for example.  Because with LDAP users are created externally, this permission is not asserted automatically.  So if you're using LDAP, you'll need to assert this permission.

The reason this affects the webconsole login is that part of the login is the check of whether or not the user logging in is enabled.  Since they do not have the permission to read their own information, you get the 403.

We'll add this note to the documentation for using LDAP authc in Stardog.

Cheers,

Mike

 

3. When LDAP authentication is enabled, the Users screen under webconsole "Security" menu shows nothing, although both stardogUsers and stardogSuperUsers groups have members. This isn't a big deal, but I would expect that the users named in those groups should be displayed here.

[Conrad Leonard]

Thanks very much for the quick response and detailed explanation.

cheers,

Conrad.

On Tuesday, 16 June 2015 16:30:53 UTC+10, Conrad Leonard wrote:

This copy of Stardog is licensed to Conrad Leonard (conrad.leonard@qimrberghofer.edu.au), QIMR Berghofer Medical Research Institute