nonLDAP users cannot log in when LDAP is enabled

an75824 · November 18, 2015, 4:59pm

Hello,

I would like to allow non-institutional users to register and log-in on my OJS web site. When they get registered, they can’t login because their credentials are not recognized (LDAP users have no problem). I do not care to have a single sign on system. Any idea?

Thank you in advance.

asmecher · November 20, 2015, 8:57pm

Hi @an75824,

When the LDAP plugin is set up, whenever a user registers in OJS, it should attempt to create an LDAP account. Has your LDAP server been configured to disallow that?

Regards,
Alec Smecher
Public Knowledge Project Team

an75824 · November 23, 2015, 9:31am

Hello and thank you very much for your reply. Well, I have seen that option but I do not want the non-institutional users to be able to access my institutional pages. Can I redirect non-institutional users to OJS database for authentication?

asmecher · November 24, 2015, 5:48pm

Hi @an75824,

I don’t believe so, not without modifying OJS. Are you looking for a way to manage subscriptions through your institutional database, but to have users (e.g. editors, authors, etc.) managed within the OJS database? If so, maybe Shibboleth is a better solution than LDAP.

Regards,
Alec Smecher
Public Knowledge Project Team

ctgraham · November 24, 2015, 6:56pm

For 3.0, I think this question might be generalized to whether thought is being given to multitier, pluggable authentication. For example, I’ve heard of desires for authentication via:

local accounts
Shibboleth
LDAP
OAuth (such as ORCID)

All of these could potentially live side-by-side in a single instance.

an75824 · November 25, 2015, 11:57am

Thank you both for your valuable contribution. What I would like to have is not only authors etc but phd students (from my institution or from another) that can also get register with my OJS and access the publications. What if those students can’t use Shibboleth/openAthens etc? Anyway, it seems that I can’t solve the problem right now. Thank you!

ctgraham · November 25, 2015, 2:33pm

I agree that there should be the option for a hierarchical or parallel authentication options.

One benefit to the Shibboleth plugin is that it can now stand in parallel to the native OJS login:

github.com/pkp/ojs

pkp/pkp-lib#543 Allow implicit authentication to the be optional

pkp:ojs-dev-2_4 ← jcu-eresearch:optional-implicit-auth

opened 11:24PM - 02 Jun 15 UTC

davidjb

+126 -85

As discussed at http://pkp.sfu.ca/support/forum/viewtopic.php?p=50029sid=d391a4c…a8a1c1bb46ade0612db8e7fb4#p50029 onwards. This patch for OJS comes from an install I've set up that required simultaneous local login and Shibboleth (implicit authentication) access. It adds the ability to specify `implicitAuth = Optional` in the config.inc.php file. This handles the use case of allowing users with Shibboleth/SSO users and users with local accounts (managers, anyone who can't login via Shibboleth, etc) to both access OJS via their respective methods. This pull request is fully-backwards compatible with existing implicitAuth settings (`On` and `Off`). The only one difference that will be seen by users is a bugfix on the register form if `implicitAuth = On`; see below. This pull request consists of the following changes: - Any checks for implicit auth (`On` or `Off`) now also check for `Optional`, ensuring code paths or template content is shown in this case. - User validation (Validation.inc.php) checks the type of auth being used before proceeding - Updates config.TEMPLATE.inc.php with details about implicit auth - Register form prompts users to login first when implicit auth set as `On`. Previously, when implicit auth was on, a non-functioning register form was shown (bugfix). Other changes to this file are re-indentation. - When `implicitAuth = Optional`, display headings on login templates and sidebar to help users distinguish between implicit auth (Shibboleth) and local login. - Updates pkp-lib to make the login.tpl compatible with optional implicit auth (see https://github.com/pkp/pkp-lib/pull/542 for the commit). - Adds helper text to password change template when `implicitAuth = Optional`; password change needs to be available for local accounts but can't be used for Shibboleth login so the page explains this. - Adds relevant localisation for new strings.