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?

 

 

 

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.

 

 

 

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

 

 

 

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) 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

_____________________________________________________________
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 )