[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[EP-tech] LDAP login



We have viewed the LDAP auth/users subsystem and the creator/author/browse views subsystems as separate.

We abstracted it out one extra level, so the author_identifier, isn't their employee/staff id (you know, for privacy's sake ;) ).. it instead links to an 'author' system we built.
The staff directory etc, used an api call (passes in the employeeID and gets the AuthorID), to build the url for the publications chunk, to include in the staff profile page.
We also have 6 usertypes, so we can allow LDAP or NON-LDAP logins.

This way we can remove/disable user accounts, and have no impact on the ePrint pubs side of things.
How does your system handle the removal of ex-staff from the user tables, but if there are linked ePrints to that userID... does it cause any problems?


From: eprints-tech-bounces at ecs.soton.ac.uk [mailto:eprints-tech-bounces at ecs.soton.ac.uk] On Behalf Of Andrew Beeken
Sent: Friday, 10 February 2017 1:59 AM
To: eprints-tech at ecs.soton.ac.uk
Subject: Re: [EP-tech] LDAP login

The use case for us is the generation of pages for creators. As a background, we currently do LDAP login via a bulk import, but the script that controls this is quite destructive and is intrinsically tied into a number of core EPrints files which I want to get away from - basically it tears down the user table nightly, reimports a fresh dump from LDAP but also harvests off any users who may have left the university into a separate table. One of the things that using their internal staff number, which is a six digit numeric string, does for us is it allows us to use a constant identifier for that member of staff across all systems we want to join up.

Take, for example, a user John Smith with username jsmith and staff ID of 123456. John can log into the system using his normal user details through LDAP authentication which is fine, but when his creator browse page is created it is as http://eprints.lincoln.ac.uk/view/creators/123456.html which is great for us to be able to point other systems or apps at to drag his records back and use on, say, our internal staff directory. For us it's that single point of truth that we know we can use everywhere as an identifier, as well as not making members of staff use a different login for different systems.


From: eprints-tech-bounces at ecs.soton.ac.uk<mailto:eprints-tech-bounces at ecs.soton.ac.uk> [mailto:eprints-tech-bounces at ecs.soton.ac.uk] On Behalf Of Lizz Jennings
Sent: 09 February 2017 14:50
To: eprints-tech at ecs.soton.ac.uk<mailto:eprints-tech at ecs.soton.ac.uk>
Subject: Re: [EP-tech] LDAP login

What's the use case for the id being the internal one, rather than an EPrints one?

We've got the internal id as the username, which seems to be effective.

Lizz

--
Lizz Jennings BA MSc ACLIP MCLIP (Revalidated 2015)
Research Data Librarian (Systems)
The Library 4.10, University of Bath, Bath, BA2 7AY UK
Ext. 3570 (External 01225 383570)
E.Jennings at bath.ac.uk<mailto:E.Jennings at bath.ac.uk>
Research Data Management: http://www.bath.ac.uk/research/data


From: eprints-tech-bounces at ecs.soton.ac.uk<mailto:eprints-tech-bounces at ecs.soton.ac.uk> [mailto:eprints-tech-bounces at ecs.soton.ac.uk] On Behalf Of Andrew Beeken
Sent: 09 February 2017 14:27
To: eprints-tech at ecs.soton.ac.uk<mailto:eprints-tech at ecs.soton.ac.uk>
Subject: [EP-tech] LDAP login

Okay, related to but separate from my ongoing quest to migrate and improve our EPrints install, I'm looking into options for getting an LDAP authentication script up and running. I've had a look online and found a couple of different ways to implement this, one of which (http://wiki.unimas.my/unimaswiki//bin/view/HOW-TO,+Tutorial+&+User+Manual/HOW-TO+:+Install+Eprints+v3.3.12++on+Ubuntu+14.04+With+LDAP+Authentication<http://wiki.unimas.my/unimaswiki/bin/view/HOW-TO,+Tutorial+&+User+Manual/HOW-TO+:+Install+Eprints+v3.3.12++on+Ubuntu+14.04+With+LDAP+Authentication>) I've tried to no avail.

Does anyone have any particular way of implementing this that they can recommend? I'm on the fence as to whether we should be doing this on a bulk import or creating users as and when they log in, however I DO want to ensure that the ID associated with the user is the one from our internal system and not a naturally generated one from EPrints.

As always, thanks in advance!
Andrew

The University of Lincoln, located in the heart of the city of Lincoln, has established an international reputation based on high student satisfaction, excellent graduate employment and world-class research.

The information in this e-mail and any attachments may be confidential. If you have received this email in error please notify the sender immediately and remove it from your system. Do not disclose the contents to another person or take copies.

Email is not secure and may contain viruses. The University of Lincoln makes every effort to ensure email is sent without viruses, but cannot guarantee this and recommends recipients take appropriate precautions.

The University may monitor email traffic data and content in accordance with its policies and English law. Further information can be found at: http://www.lincoln.ac.uk/legal.


_____________________________________________________________
This email (including any attached files) is confidential and is for the intended recipient(s) only. If you received this email by mistake, please, as a courtesy, tell the sender, then delete this email.

The views and opinions are the originator's and do not necessarily reflect those of the University of Southern Queensland. Although all reasonable precautions were taken to ensure that this email contained no viruses at the time it was sent we accept no liability for any losses arising from its receipt.

The University of Southern Queensland is a registered provider of education with the Australian Government.
(CRICOS Institution Code QLD 00244B / NSW 02225M, TEQSA PRV12081 )

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ecs.soton.ac.uk/pipermail/eprints-tech/attachments/20170209/4c4901b3/attachment-0001.html