[
https://jira.duraspace.org/browse/DS-1012?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=22305#comment-22305
]
Scott Phillips commented on DS-1012:
------------------------------------
Here is update for the DSpace.cfg that documents the parameters. To the best of
my knowledge all the configuration is backwards compatible with the previous
version but there are several new parameters added.
---------------------
#### Shibboleth Authentication Configuration Settings ####
# 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
##
## Shibboleth Sessions:
##
# When configuring your Shibboleth Service Provider there are two paradigms you
# may use: Active or Lazy Sessions. Active sessions is where the mob_shib
# module is configured to product a URL space. No one will be able to access
# that URL without first authenticating with Shibboleth. Using this method you
# will need to configure shibboleth to protect the URL: "/shibboleth-login".
# The alternative, Lazy Session does not protect any specific URL. Instead
# apache will allow access to any URL, and when the application wants to it
# may initiate an authenticated session. The Lazy Session method is preferable
# for most DSpace installations where you want public access to most of DSpace
# but restricted access to limitted areas - such as administration.
# Whether to use lazy sessions or active sessions.
authentication.shib.lazysession = true
# The url to start a shibboleth session (only for lazy sessions)
authentication.shib.lazysession.loginurl = /Shibboleth.sso/Login
# Force HTTPS when authenticating (only for lazy sessions)
authentication.shib.lazysession.secure = true
##
## Shibboleth Authentication Methods:
##
# 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 netted so all future
# authentications for this user will be based upon netted. One thing to note
# is that DSpace will prevent an account from switching NetIDs. If an account
# all ready has a NetID set and then they try and authenticate with a
# different NetID the authentication will fail.
# Authentication headers for Mail, NetID, and Tomcat's Remote User.
# Supply all parameters possible.
authentication.shib.netid-header = SHIB-NETID
authentication.shib.email-header = SHIB-MAIL
authentication.shib.email-use-tomcat-remote-user = false
# Should we allow new users to be registered automatically?
authentication.shib.autoregister = true
# Sword compatability will allow this authentication method to work when using
# sword. Sort 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 with out 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.
authentication.shib.sword.compatability = true
##
## EPerson Metadata:
##
# One of the primary benefits of using Shibboleth based authentication is
# receiving additional attributes about users such as their names, telephone
# numbers, and possibly their academic department or graduation semester if
# desired. DSpace treats the first and last name attributes differently because
# they (along with email address) are the three pieces of minimal information
# required to create a new user account. For both first and last name supply
# direct mappings to the Shibboleth headers. In additional to the first and
# last name DSpace supports other metadata fields such as phone, or really
# anything you want to store on an eperson object. Beyond the phone field,
# which is accessible in the user's profile screen, none of these additional
# metadata fields will be used by DSpace out-of-the box. However if you
# develop any local modification you may access these attributes from the
# EPerson object. The Vireo ETD workflow system utilizes this to aid
# students when submitting an ETD.
# Metadata Headers
# Shibboleth-based headers for the first and last name attirbutes
authentication.shib.firstname-header = SHIB-GIVENNAME
authentication.shib.lastname-header = SHIB-SURNAME
# Additional user attributes mapping, multiple attributes may be stored
# for each user. The left side is the Shibboleth-based metadata Header
# and the right side is the eperson metadata field to map the attribute to.
#authentication.shib.eperson.metadata = \
# SHIB-telephone => phone, \
# SHIB-cn => cn
# If the eperson metadata field is not found, should it be automatically
created?
authentication.shib.eperson.metadata.autocreate = true;
##
## Role-based Groups:
##
# 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
# "[email protected]". 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.<role-name>" which is a comma separated list of
# DSpace groups.
# The shibboleth header to do role-based mappings
authentication.shib.role-header = SHIB-SCOPED-AFFILIATION
# Weather to ignore the attribute's scope or value.
authentication.shib.role-header.ignore-scope = true
#authentication.shib.role-header.ignore-value = false
# Default mappings of roles values to a comma separated list of DSpace group
# names (Case Sensitive).
#authentication.shib.role.faculty = Faculty, Member
#authentication.shib.role.staff = Staff, Member
#authentication.shib.role.student = Students, Member
> DSpace Shibboleth authentication module needs to support Lazy Authentication,
> NetID based authentication, and additional EPerson metadata
> -----------------------------------------------------------------------------------------------------------------------------------------
>
> Key: DS-1012
> URL: https://jira.duraspace.org/browse/DS-1012
> Project: DSpace
> Issue Type: New Feature
> Components: DSpace API
> Reporter: Scott Phillips
> Assignee: Scott Phillips
> Fix For: post-1.8.0
>
> Attachments: ShibAuthentication.java, ShibAuthentication.java
>
>
> For a long time the Texas Digital Library has maintain a separate Shibboleth
> Authenticator that we've been using around the state for DSpace repositories
> and Vireo installations. This issue represents the work to migrate those
> custom modifications into the default Shibboleth Authenticator. There three
> key features that this provides for DSpace is:
> 1) Lazy Authentication. Apache no longer needs to protect a special url
> (/shibboleth-login) instead when the user needs to be authenticated DSpace
> assume the responsibility of sending the user to the Shibboleth Initiator.
> This allows for more flexable deployments because you can install any number
> of repositories on a domain without needed to adjust the apache settings for
> which urls are protected. Of course if you don't want to use lazy auth the
> old method still works.
> 2) NetID based identification. Users change their email address and if you're
> doing user lookup based upon email addresses when this happens you'll create
> two seperate user accounts and people will be confused. Since most shibboleth
> IDPs are just an interface over ldap it makes sense to configure shibboleth
> to identify users based upon netids. With Shibboleth 2.x you can also use
> targeted IDs. Of course if you don't want to mess with netids the old way
> still works just fine. There are three ways users are identified NetId,
> Email, and Tomcat Remote User.
> 3) Additional Eperson metadata. The EPerson object has get/setMetadata()
> methods to store additional metadata about a user. This authentication method
> allows you to take shibboleth attributes and store them on the eperson object
> as additional metadata. If you're using Vireo then some of these attributes
> will be used to aid in filling out ETD submission forms. This allows the form
> to be pre-filled with department, graduation semester, user's phone number
> and address. By it's self this feature dosn't do much because no other part
> of DSpace is looking for these metadata fields but it provides the underlying
> infrastructure to support it. Of course if you don't want additional metadat
> it works just fine as well.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.duraspace.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
------------------------------------------------------------------------------
Malware Security Report: Protecting Your Business, Customers, and the
Bottom Line. Protect your business and customers by understanding the
threat from malware and how it can impact your online business.
http://www.accelacomm.com/jaw/sfnl/114/51427462/
_______________________________________________
Dspace-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/dspace-devel
