Notice: In order to edit this ticket you need to be either: a Product Owner, The owner or the reporter of the ticket, or, in case of a Task not yet assigned, a team_member"

Task #6248 (closed)

Opened 10 years ago

Closed 9 years ago

Last modified 9 years ago

LDAP - remove user from security group

Reported by: wmoore Owned by: sylittlewood
Priority: major Milestone: OMERO-Beta4.3.2
Component: Configuration Version: n.a.
Keywords: n.a. Cc: cxallan, jamoore, atarkowska
Resources: n.a. Referenced By: n.a.
References: n.a. Remaining Time: 0.0d
Sprint: 2011-09-15 (5)

Description (last modified by jmoore)

If a user is removed from the LDAP security group used to create their OMERO account, they can still log in:

https://www.openmicroscopy.org/community/viewtopic.php?f=4&t=748

The user_filter property should (optionally?) be applied on every login.

Note: In discussions with Ola, there are at least two issues that this solution will not cover:

  1. since the original DN is stored in OMERO, there is the possibility that it will become out of sync, e.g. if the user changes his/her OMERO username. The current plan will be to signal an InternalException to the user.
  2. this will only work for LDAP configurations in which group membership is a property on the user so that it can be filtered via omero.ldap.user_filter. In cases where group membership is a property of the groups, then we will need to rework how group_filter and new_user_group interact.

Change History (29)

comment:1 Changed 10 years ago by wmoore

If there's anything we can suggest to the user just now (see forum), please go ahead on the forum.

comment:2 Changed 9 years ago by jmoore

  • Remaining Time set to 0.5
  • Sprint set to 2011-08-04 (2)

As mentioned on the forum, this should be just a matter of re-checking against the filter on every login. I'll add that logic and then pass to Ola for testing. We can decide from there if we want to add any configuration options to maintain the previous logic, or to make the "user in a group" logic easier to implement.

comment:3 Changed 9 years ago by jmoore

  • Description modified (diff)

comment:4 Changed 9 years ago by jmoore

  • Description modified (diff)

Output when logging in with mismatched DNs:

~/git/dist $ bin/omero login foo@localhost
Password:
Internal error. Please contact your administrator:
DNs don't match: '' and 'cn=foo,o=example'
Password:

comment:5 Changed 9 years ago by jmoore

  • Cc jmoore added; atarkowska removed
  • Owner changed from jmoore to atarkowska

Pushed:

~/git/dist $ git push team HEAD:refs/heads/feature/6248-ldap
Counting objects: 1046, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (499/499), done.
Writing objects: 100% (794/794), 1.81 MiB, done.
Total 794 (delta 627), reused 325 (delta 253)
To ssh://git.openmicroscopy.org/home/git/team.git
 * [new branch]      HEAD -> feature/6248-ldap

Passing to Ola for testing.

comment:6 Changed 9 years ago by atarkowska

  • Sprint changed from 2011-08-04 (2) to 2011-08-18 (3)

comment:7 Changed 9 years ago by atarkowska

  • Status changed from new to accepted

comment:8 Changed 9 years ago by atarkowska

  • Owner atarkowska deleted
  • Status changed from accepted to new

comment:9 Changed 9 years ago by atarkowska

  • Owner set to atarkowska

I can't test it because ldap-dev is down. Waiting for response from Support team.

comment:10 Changed 9 years ago by atarkowska

  • Status changed from new to accepted

comment:11 Changed 9 years ago by atarkowska

New implementation was put on to tests against 2 different ldap server.
First:

  • user entry does not contain any group information:
    dn cn=jsmith,ou=edit,ou=people,ou=department,o=city
    
    cn	jsmith
    gidNumber	1614
    homeDirectory	/homes/jsmith
    objectClass	top
    objectClass	inetorgperson
    objectClass	person
    objectClass	organizationalPerson
    sn	Smith
    uid	jsmith
    uidNumber	1234
    employeeNumber	M1234
    givenName	John
    
  • group entry contains user DN and CN:
    cn	group1
    gidNumber	1234
    objectClass	top
    objectClass	groupOfUniqueNames
    displayName	group1
    manager	cn=jsmith,ou=edir,ou=people,ou=department,o=city
    memberUid	jsmith
    ...
    uniqueMember	cn=jsmith,ou=edir,ou=people,ou=department,o=city
    ...
    

Second:

  • user entry contains group assignment"
    dn=JSmith,ou=users,o=CITY
    
    cn	JSmith
    gidNumber	123
    homeDirectory	/home/jsmith
    objectClass	inetOrgPerson
    objectClass	organizationalPerson
    objectClass	Person
    objectClass	ndsLoginProperties
    objectClass	Top
    ...
    sn	Smith
    uidNumber	1234
    uniqueID	JSmith
    fullName	John Smith
    givenName	John
    groupMembership	cn=DEPARTMENT,ou=groups,O=DUNDEE
    groupMembership	cn=DEPARTMENT2,ou=groups,O=DUNDEE
    ...
    groupMembership	cn=DEPARTMENT3,ou=groups,O=DUNDEE
    
  • group entry contains user DN:
    dn cn=DEPARTMENT,ou=groups,o=CITY
    
    cn	DEPARTMENT
    objectClass	groupOfNames
    objectClass	Top
    ...
    member	cn=JSmith,ou=users,O=DUNDEE
    ...
    

First ldap server was tested against group_filter, conclusion:

  • First time log in: if users is not a member of a group, omero account was not created. If user was assign to the group specified in filter omero groups and account was created. WORKS OK
  • Second time log in: if user was removed from the group entry on the ldap server still could log in to the omero server. DOESN'T WORK

I couldn't establish connection against second ldap server.

Last edited 9 years ago by atarkowska (previous) (diff)

comment:12 Changed 9 years ago by atarkowska

  • Cc atarkowska added
  • Owner changed from atarkowska to jmoore

Josh, please ping me about the above comment.

comment:13 Changed 9 years ago by jmoore

  • Owner jmoore deleted
  • Status changed from accepted to new

comment:14 Changed 9 years ago by jmoore

  • Owner set to atarkowska

As discussed via IM, the issues above were probably caused by a mismatched SHA1. Ola, I'm passing to you to see where we are on testing.

comment:15 Changed 9 years ago by jmoore

To follow up on another IM conversation, the commit in question is:

~/git $ git log -p team/feature/6248-ldap
commit 0fd9cc001e377f39e8979217b2ba03503424f437
Author: jmoore <josh@glencoesoftware.com>
Date:   Wed Aug 3 11:13:16 2011 +0200

    Add user_filter check on every ldap password check (See #6248)

What's changed is that on every login the user_filter gets applied. This means that if a sysadmin configures OMERO to only allow users of a particular LDAP group to login to OMERO (for example), and then a user is removed from that group, that the user will then no longer be able to login.

comment:16 Changed 9 years ago by atarkowska

  • Owner changed from atarkowska to sylittlewood

Pushing this to Scott, as he is going to test the patch.

comment:17 Changed 9 years ago by jburel

  • Sprint changed from 2011-08-18 (3) to 2011-09-01 (4)

Moved from sprint 2011-08-18 (3)

comment:18 Changed 9 years ago by sylittlewood

  • Status changed from new to accepted

comment:19 Changed 9 years ago by sylittlewood

  • Owner sylittlewood deleted
  • Status changed from accepted to new

comment:20 Changed 9 years ago by sylittlewood

  • Owner set to sylittlewood

comment:21 Changed 9 years ago by sylittlewood

Unable to create new ldap groups or users on the mirrored LDAP server, don't seem to have permissions. UNable to test at the moment

comment:22 Changed 9 years ago by jburel

  • Sprint changed from 2011-09-01 (4) to 2011-09-15 (5)

Moved from sprint 2011-09-01 (4)

comment:23 Changed 9 years ago by sylittlewood

Josh has pushed new ldap functionality to his branch at : https://github.com/joshmoore/openmicroscopy/tree/integration/4.3.2-ldap

This allows for resynchronisation of group membership with ldap on user login.

Current limitations:

Any custom groups will be removed from the user membership if they do not exist in LDAP.

LDAP is treated as the authority.

comment:24 Changed 9 years ago by sylittlewood

Bug: When adding a user with no groups to a group in LDAP on inital login the groups synchronise from LDAP but no default group is selected.

comment:25 Changed 9 years ago by jmoore <josh@…>

(In [0fd9cc001e377f39e8979217b2ba03503424f437/ome.git] on branch develop) Add user_filter check on every ldap password check (See #6248)

comment:26 Changed 9 years ago by jmoore <josh@…>

(In [92e8bf71f51cc00bc95801bcc2b494ff09e2aa35/ome.git] on branch develop) Prevent stack trace on non-DN like guest (See #6248)

comment:27 Changed 9 years ago by jmoore <josh@…>

  • Remaining Time changed from 0.5 to 0
  • Resolution set to fixed
  • Status changed from new to closed

(In [74f175d86e7b0e496b982692548dcd255c994539/ome.git] on branch develop) Correct user_filter and user filtering (Fix #6248, #6703)

comment:28 Changed 9 years ago by jmoore <josh@…>

(In [40380bc96e91309cd49241b6185c240fe5a7c364/ome.git] on branch develop) Merge branch 'integration/4.3.2-ldap' into develop (Fix #6248, #6501)

comment:29 Changed 9 years ago by jmoore <josh@…>

(In [45cab53df4d1084c31a3e56f7358183a5c71b007/ome.git] on branch develop) Passing test for uuid login (See #5648, #6248, etc)

Seems that the LDAP+uuid login case was handled by other
recent changes to the LdapPasswordProvider?.

Note: See TracTickets for help on using tickets. You may also have a look at Agilo extensions to the ticket.

1.3.13-PRO © 2008-2011 Agilo Software all rights reserved (this page was served in: 0.84441 sec.)

We're Hiring!