Re: [Dspace-tech] Authenticating users without creating EPerson in DB
Will this be part of 1.8? Or 3.1? Or both? (Please say 1.8, please say 1.8, or
both)
Anyway … I am very interested in CAS integration as well.
Thanks,
Patrick West
Senior Software Engineer
Tetherless World Constellation
Rensselaer Polytechnic Institute
On May 20, 2013, at 9:52 AM, Alumno Etsii todos.somos...@gmail.com wrote:
Again, thanks so much for your kind help! Then I can say the CAS
authentication is working ok, in a few days - when I get a few days with less
work, I'll apply those changes to a git clone of DSpace and provide the patch
for the latest version of DSpace so CAS auth. can be *AT LAST* officially
integrated :-)
Should I uploadit it to JIRA, send it to this list...?
Regards.
2013/5/20 Mark H. Wood mw...@iupui.edu
On Mon, May 20, 2013 at 02:02:14PM +, 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 mw...@iupui.edu
Machines should not be friendly. Machines should be obedient.
--
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
DSpace-tech@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dspace-tech
List Etiquette:
https://wiki.duraspace.org/display/DSPACE/Mailing+List+Etiquette
--
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.
Re: [Dspace-tech] Authenticating users without creating EPerson in DB
On Tue, May 21, 2013 at 7:33 PM, Patrick West we...@rpi.edu wrote: Will this be part of 1.8? Or 3.1? Or both? (Please say 1.8, please say 1.8, or both) Both 1.8.2 and 3.1 are already released and it's not part of DSpace yet. However, authentication plugins are probably the easiest custom code to add because it's just one file you have to add and rebuild DSpace, then simply point your configuration to it. So you can download the code from the Jira ticket and try it. The more people report back, the sooner all the problems will be resolved and the sooner it gets to DSpace. Next chance is DSpace 4.0 (to be release by the end of this year) if we can get it in by August. Regards, ~~helix84 Compulsory reading: DSpace Mailing List Etiquette https://wiki.duraspace.org/display/DSPACE/Mailing+List+Etiquette -- Try New Relic Now We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may ___ DSpace-tech mailing list DSpace-tech@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-tech List Etiquette: https://wiki.duraspace.org/display/DSPACE/Mailing+List+Etiquette
Re: [Dspace-tech] Authenticating users without creating EPerson in DB
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? Then what's the autoregister option for,
as it should always be set to true in order to work?
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'm really stucked here, any help would be very appreciated!
Regards.
2013/5/18 Alumno Etsii todos.somos...@gmail.com
Hi all!
I'm trying to addapt a CAS solution I found on JIRA (
https://jira.duraspace.org/browse/DS-1028) and I'm having problems
authenticating without auto-registering.
There's a boolean parameter in the .cfg determining whether auto-register
the user or not after logging in; if it's set to true, I was able to
arrange it to work with current version correctly. But if the parameter is
set to false, all the authenticate function does is to return NO_SUCH_USER,
as you can see in the proposed code.
Practically, integrating this with CAS means that the user identifies once
vs. CAS, but I don't know why, after it DSpace tries to validate him again
and that's an error (as a CAS ticket can be validated just once). The
question is: why does DSpace keep trying to validate the user when the user
once validated itself and the result was successful? I tried to change
NO_SUCH_USER to SUCCESS, but the same happens.
Another question is: Is it even possible to create a session to a user
without creating the eperson registry in the DB? What objects would be
needed to set for that, just EPerson?
Thanks so much for your help!
--
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
DSpace-tech@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dspace-tech
List Etiquette: https://wiki.duraspace.org/display/DSPACE/Mailing+List+Etiquette
Re: [Dspace-tech] Authenticating users without creating EPerson in DB
Hi Miguel, I don't have many answers for you, just some more information. Mark Wood has in fact recently proposed that we don't need to store user's data in our DB, but we currently do that: https://jira.duraspace.org/browse/DS-1547 What steps would be necessary to create a one-time session for the authenticated user without storing their credentials in the DSpace DB? I don't think you can easily do that by simply by modifying an authentication plugin. You can see that an authentication plugin always calls eperson.update(), which in turn updates a row in the eperson table (see LDAP, Shibboleth). So you'd have to change the EPerson class, too. The alternative, as in IPAuthentication, is just to add the user to a special group, but I don't think that would be enough for you because in that case you cannot tell individual users apart - so you couldn't use CAS for users who submit content. Regards, ~~helix84 Compulsory reading: DSpace Mailing List Etiquette https://wiki.duraspace.org/display/DSPACE/Mailing+List+Etiquette -- 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 DSpace-tech@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-tech List Etiquette: https://wiki.duraspace.org/display/DSPACE/Mailing+List+Etiquette
Re: [Dspace-tech] Authenticating users without creating EPerson in DB
On Mon, May 20, 2013 at 02:02:14PM +, 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 mw...@iupui.edu
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
DSpace-tech@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dspace-tech
List Etiquette: https://wiki.duraspace.org/display/DSPACE/Mailing+List+Etiquette
Re: [Dspace-tech] Authenticating users without creating EPerson in DB
If you submit a patch, please attach it to Jira https://jira.duraspace.org/browse/DS-1028. Even better would be a GitHub pull request and a link to that pull request in Jira comments. Regards, ~~helix84 Compulsory reading: DSpace Mailing List Etiquette https://wiki.duraspace.org/display/DSPACE/Mailing+List+Etiquette -- 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 DSpace-tech@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-tech List Etiquette: https://wiki.duraspace.org/display/DSPACE/Mailing+List+Etiquette
[Dspace-tech] Authenticating users without creating EPerson in DB
Hi all! I'm trying to addapt a CAS solution I found on JIRA ( https://jira.duraspace.org/browse/DS-1028) and I'm having problems authenticating without auto-registering. There's a boolean parameter in the .cfg determining whether auto-register the user or not after logging in; if it's set to true, I was able to arrange it to work with current version correctly. But if the parameter is set to false, all the authenticate function does is to return NO_SUCH_USER, as you can see in the proposed code. Practically, integrating this with CAS means that the user identifies once vs. CAS, but I don't know why, after it DSpace tries to validate him again and that's an error (as a CAS ticket can be validated just once). The question is: why does DSpace keep trying to validate the user when the user once validated itself and the result was successful? I tried to change NO_SUCH_USER to SUCCESS, but the same happens. Another question is: Is it even possible to create a session to a user without creating the eperson registry in the DB? What objects would be needed to set for that, just EPerson? Thanks so much for your help! -- 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 DSpace-tech@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-tech List Etiquette: https://wiki.duraspace.org/display/DSPACE/Mailing+List+Etiquette
