org.dspace.authenticate

Class ShibAuthentication

java.lang.Object

org.dspace.authenticate.ShibAuthentication

All Implemented Interfaces:

AuthenticationMethod

public class ShibAuthentication
extends Object
implements AuthenticationMethod

Shibboleth authentication for DSpace Shibboleth is a distributed authentication system for securely authenticating users and passing attributes about the user from one or more identity providers. In the Shibboleth terminology DSpace is a Service Provider which receives authentication information and then based upon that provides a service to the user. With Shibboleth DSpace will require that you use Apache installed with the mod_shib module acting as a proxy for all HTTP requests for your servlet container (typically Tomcat). DSpace will receive authentication information from the mod_shib module through HTTP headers. See for more information on installing and configuring a Shibboleth Service Provider: https://wiki.shibboleth.net/confluence/display/SHIB2/Installation See the DSpace.cfg or DSpace manual for information on how to configure this authentication module.

Version:

$Revision$

Author:

Bruc Liong, MELCOE, Xiang Kevin Li, MELCOE, Scott Phillips

Field Summary

Fields inherited from interface org.dspace.authenticate.AuthenticationMethod

BAD_ARGS, BAD_CREDENTIALS, CERT_REQUIRED, NO_SUCH_USER, SUCCESS

Constructor Summary

Constructors

Constructor and Description
ShibAuthentication()

Method Summary

Methods

Modifier and Type	Method and Description
boolean	allowSetPassword(Context context, javax.servlet.http.HttpServletRequest request, String email) Indicate whether or not a particular self-registering user can set themselves a password in the profile info form.
int	authenticate(Context context, String username, String password, String realm, javax.servlet.http.HttpServletRequest request) Authenticate the given or implicit credentials.
boolean	canSelfRegister(Context context, javax.servlet.http.HttpServletRequest request, String username) Indicate whether or not a particular user can self-register, based on e-mail address.
int[]	getSpecialGroups(Context context, javax.servlet.http.HttpServletRequest request) Get list of extra groups that user implicitly belongs to.
void	initEPerson(Context context, javax.servlet.http.HttpServletRequest request, EPerson eperson) Initialize a new e-person record for a self-registered new user.
boolean	isImplicit() Predicate, is this an implicit authentication method.
String	loginPageTitle(Context context) Get title of login page to which to redirect.
String	loginPageURL(Context context, javax.servlet.http.HttpServletRequest request, javax.servlet.http.HttpServletResponse response) Get login page to which to redirect.
protected int	swordCompatibility(Context context, String username, String password, javax.servlet.http.HttpServletRequest request) Provide password-based authentication to enable sword compatibility.

Methods inherited from class java.lang.Object

clone, equals, finalize, getClass, hashCode, notify, notifyAll, toString, wait, wait, wait

Constructor Detail

ShibAuthentication

public ShibAuthentication()

Method Detail

authenticate

public int authenticate(Context context,
               String username,
               String password,
               String realm,
               javax.servlet.http.HttpServletRequest request)
                 throws SQLException

Authenticate the given or implicit credentials. This is the heart of the authentication method: test the credentials for authenticity, and if accepted, attempt to match (or optionally, create) an EPerson. If an EPerson is found it is set in the Context that was passed. DSpace supports authentication using NetID, or email address. A user's NetID is a unique identifier from the IdP that identifies a particular user. The NetID can be of almost any form such as a unique integer, string, or with Shibboleth 2.0 you can use "targeted ids". You will need to coordinate with your Shibboleth federation or identity provider. There are three ways to supply identity information to DSpace: 1) NetID from Shibboleth Header (best) The NetID-based method is superior because users may change their email address with the identity provider. When this happens DSpace will not be able to associate their new address with their old account. 2) Email address from Shibboleth Header (okay) In the case where a NetID header is not available or not found DSpace will fall back to identifying a user based-upon their email address. 3) Tomcat's Remote User (worst) In the event that neither Shibboleth headers are found then as a last resort DSpace will look at Tomcat's remote user field. This is the least attractive option because Tomcat has no way to supply additional attributes about a user. Because of this the autoregister option is not supported if this method is used. Identity Scheme Migration Strategies: If you are currently using Email based authentication (either 1 or 2) and want to upgrade to NetID based authentication then there is an easy path. Simply enable Shibboleth to pass the NetID attribute and set the netid-header below to the correct value. When a user attempts to log in to DSpace first DSpace will look for an EPerson with the passed NetID, however when this fails DSpace will fall back to email based authentication. Then DSpace will update the user's EPerson account record to set their netid so all future authentications for this user will be based upon netid. One thing to note is that DSpace will prevent an account from switching NetIDs. If an account already has a NetID set and then they try and authenticate with a different NetID the authentication will fail.

Specified by:

authenticate in interface AuthenticationMethod

Parameters:

context - DSpace context, will be modified (ePerson set) upon success.

username - Username (or email address) when method is explicit. Use null for implicit method.

password - Password for explicit auth, or null for implicit method.

realm - Not used by Shibboleth-based authentication

request - The HTTP request that started this operation, or null if not applicable.

Returns:

One of: SUCCESS, BAD_CREDENTIALS, CERT_REQUIRED, NO_SUCH_USER, BAD_ARGS

Meaning:
SUCCESS - authenticated OK.
BAD_CREDENTIALS - user exists, but credentials (e.g. passwd) don't match
CERT_REQUIRED - not allowed to login this way without X.509 cert.
NO_SUCH_USER - user not found using this method.
BAD_ARGS - user/pw not appropriate for this method

Throws:

SQLException

getSpecialGroups

public int[] getSpecialGroups(Context context,
                     javax.servlet.http.HttpServletRequest request)

Get list of extra groups that user implicitly belongs to. Note that this method will be invoked regardless of the authentication status of the user (logged-in or not) e.g. a group that depends on the client network-address. DSpace is able to place users into pre-defined groups based upon values received from Shibboleth. Using this option you can place all faculty members into a DSpace group when the correct affiliation's attribute is provided. When DSpace does this they are considered 'special groups', these are really groups but the user's membership within these groups is not recorded in the database. Each time a user authenticates they are automatically placed within the pre-defined DSpace group, so if the user loses their affiliation then the next time they login they will no longer be in the group. Depending upon the shibboleth attributed use in the role-header, it may be scoped. Scoped is shibboleth terminology for identifying where an attribute originated from. For example a students affiliation may be encoded as "student@tamu.edu". The part after the @ sign is the scope, and the preceding value is the value. You may use the whole value or only the value or scope. Using this you could generate a role for students and one institution different than students at another institution. Or if you turn on ignore-scope you could ignore the institution and place all students into one group. The values extracted (a user may have multiple roles) will be used to look up which groups to place the user into. The groups are defined as "authentication.shib.role." which is a comma separated list of DSpace groups.

Specified by:

getSpecialGroups in interface AuthenticationMethod

Parameters:

context - A valid DSpace context.

request - The request that started this operation, or null if not applicable.

Returns:

array of EPerson-group IDs, possibly 0-length, but never null.

allowSetPassword

public boolean allowSetPassword(Context context,
                       javax.servlet.http.HttpServletRequest request,
                       String email)
                         throws SQLException

Indicate whether or not a particular self-registering user can set themselves a password in the profile info form.

Specified by:

allowSetPassword in interface AuthenticationMethod

Parameters:

context - DSpace context

request - HTTP request, in case anything in that is used to decide

email - e-mail address of user attempting to register

Returns:

true if this method allows user to change ePerson password.

Throws:

SQLException

isImplicit

public boolean isImplicit()

Predicate, is this an implicit authentication method. An implicit method gets credentials from the environment (such as an HTTP request or even Java system properties) rather than the explicit username and password. For example, a method that reads the X.509 certificates in an HTTPS request is implicit.

Specified by:

isImplicit in interface AuthenticationMethod

Returns:

true if this method uses implicit authentication.

canSelfRegister

public boolean canSelfRegister(Context context,
                      javax.servlet.http.HttpServletRequest request,
                      String username)
                        throws SQLException

Indicate whether or not a particular user can self-register, based on e-mail address.

Specified by:

canSelfRegister in interface AuthenticationMethod

Parameters:

context - DSpace context

request - HTTP request, in case anything in that is used to decide

username - e-mail address of user attempting to register

Returns:

true if new ePerson should be created.

Throws:

SQLException

initEPerson

public void initEPerson(Context context,
               javax.servlet.http.HttpServletRequest request,
               EPerson eperson)
                 throws SQLException

Initialize a new e-person record for a self-registered new user.

Specified by:

initEPerson in interface AuthenticationMethod

Parameters:

context - DSpace context

request - HTTP request, in case it's needed

eperson - newly created EPerson record - email + information from the registration form will have been filled out.

Throws:

SQLException

loginPageURL

public String loginPageURL(Context context,
                  javax.servlet.http.HttpServletRequest request,
                  javax.servlet.http.HttpServletResponse response)

Get login page to which to redirect. Returns URL (as string) to which to redirect to obtain credentials (either password prompt or e.g. HTTPS port for client cert.); null means no redirect.

Specified by:

loginPageURL in interface AuthenticationMethod

Parameters:

context - DSpace context, will be modified (ePerson set) upon success.

request - The HTTP request that started this operation, or null if not applicable.

response - The HTTP response from the servlet method.

Returns:

fully-qualified URL or null

loginPageTitle

public String loginPageTitle(Context context)

Get title of login page to which to redirect. Returns a message key that gets translated into the title or label for "login page" (or null, if not implemented) This title may be used to identify the link to the login page in a selection menu, when there are multiple ways to login.

Specified by:

loginPageTitle in interface AuthenticationMethod

Parameters:

context - DSpace context, will be modified (ePerson set) upon success.

Returns:

title text.

swordCompatibility

protected int swordCompatibility(Context context,
                     String username,
                     String password,
                     javax.servlet.http.HttpServletRequest request)
                          throws SQLException

Provide password-based authentication to enable sword compatibility. Sword compatibility will allow this authentication method to work when using sword. Sword relies on username and password based authentication and is entirely incapable of supporting shibboleth. This option allows you to authenticate username and passwords for sword sessions without adding another authentication method onto the stack. You will need to ensure that a user has a password. One way to do that is to create the user via the create-administrator command line command and then edit their permissions.

Parameters:

context - The DSpace database context

username - The username

password - The password

request - The HTTP Request

Returns:

A valid DSpace Authentication Method status code.

Throws:

SQLException