On Mon, May 20, 2013 at 02:02:14PM +0000, Alumno Etsii wrote:
> Ok, I'm replying myself with some little advances.
>
> This snippet is used in the authenticate funcion of CAS, when eperson ==
> null and the cas.autoregister option is false:
>
> + else
> + {
> + // No auto-registration for valid netid
> + log.warn(LogManager.getHeader(context,
> "authenticate",
> + netid+" type=netid_but_no_record,
> cannot
> auto-register"));
> + return NO_SUCH_USER;
> + }
>
> I see similar logic is in Shibboleth or LDAP authentication metods, but I
> don't get the point of it. Does that mean that if autoregister option is
> set to false and they doesn't have stored credentials as EPerson in the DB,
> users shouldn't be able to login?
Correct. To say that a DSpace user is logged in means that the
session is associated with an EPerson ID. If this user is not
currently registered as an EPerson, and auto-registration is disabled,
then there will be no EPerson ID with which to associate the session
so it cannot be logged in. The EPerson record would have to be
created by some other means.
Fundamentally, there must be an EPerson record before a session can be
logged in. The authentication methods only determine whether a user
can prove his association with his EPerson record. When
autoregistration is enabled, an authentication method can also create
a new EPerson record if it does not yet exist.
> Then what's the autoregister option for,
> as it should always be set to true in order to work?
Autoregistration might be disabled if it is desired to restrict
logged-in access to a subset of the people who hold accounts in the
external authentication provider. Presumably an administrator would
create the necessary EPerson records.
> If I replace NO_SUCH_USER by SUCCESS, I see that I get correctly
> authenticated vs. CAS only once, but DSpace shows the AuthenticationFail
> error. The question is: What steps would be necessary to create a one-time
> session for the authenticated user without storing their credentials in the
> DSpace DB?
I believe that there is no way to do that. An EPerson record must
exist before a session can be logged in.
It would not be necessary to store a password in the EPerson record,
if the user will always use an external authentication provider (such
as CAS). But there must be an EPerson record with a unique ID field
value and a name that can be matched to the external provider's
records.
You can see some of this in
org.dspace.app.xmlui.aspect.general.AuthenticatedSelector, which
returns true/false depending on whether the session is logged in:
EPerson eperson = context.getCurrentUser();
if (eperson == null)
{
// No one is authenticated.
return false;
}
The test asks whether there is an EPerson ID for the session.
--
Mark H. Wood, Lead System Programmer [email protected]
Machines should not be friendly. Machines should be obedient.
signature.asc
Description: Digital signature
------------------------------------------------------------------------------ AlienVault Unified Security Management (USM) platform delivers complete security visibility with the essential security capabilities. Easily and efficiently configure, manage, and operate all of your security controls from a single console and one unified framework. Download a free trial. http://p.sf.net/sfu/alienvault_d2d
_______________________________________________ DSpace-tech mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/dspace-tech List Etiquette: https://wiki.duraspace.org/display/DSPACE/Mailing+List+Etiquette
