Versions Compared

Old Version 29

changes.mady.by.user Tim Donohue

Saved on

compared with

New Version Current

changes.mady.by.user Ivan Masár

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Table of Contents
minLevel2
outlinetrue
stylenone

Stackable Authentication Method(s)

...

Configuration File:

[dspace]/config/modules/authentication-shibboleth.cfg

Property:

email-header

Example Value:

email-header = MAIL

Informational Note:

The option specifies that the email comes from the mentioned header. This value is CASE-Sensitive.

Property:

firstname-header

Example Value:

firstname-header = SHIB-EP-GIVENNAME

Informational Note:

Optional. Specify the header that carries the user's first name. This is going to be used for the creation of new-user.

Property:

lastname-header

Example Value:

lastname-header = SHIB-EP-SURNAME

Informational Note:

Optional. Specify the header that carries user's last name. This is used for creation of new user.

Property:

email-use-tomcat-remote-user

Example Value:

email-use-tomcat-remote-user = true

Informational Note:

This option forces the software to acquire the email from Tomcat.

Property:

autoregister

Example Value:

autoregister = true

Informational Note:

Option will allow new users to be registered automatically if the IdP provides sufficient information (and the user does not exist in DSpace).

Property:

Code Block
role-header
role-header.ignore-scope

Example Value:

Code Block
role-header = Shib-EP-ScopedAffiliation
role-header.ignore-scope = true

or

Code Block
role-header = Shib-EP-UnscopedAffiliation
role-header.ignore-scope = false

Informational Note:

These two options specify which attribute that is responsible for providing user's roles to DSpace and unscope the attributes if needed. When not specified, it is defaulted to 'Shib-EP-UnscopedAffiliation', and ignore-scope is defaulted to 'false'. The value is specified in AAP.xml (Shib 1.3.x) or attribute-filter.xml (Shib 2.x). The value is CASE-Sensitive. The values provided in this header are separated by semi-colon or comma. If your service provider (SP) only provides scoped role header, you need to set role-header.ignore-Scope as 'true'. For example if you only get Shib-EP-ScopedAffiliation instead of Shib-EP-ScopedAffiliation, you name to make your settings as in the example value above.

Property:

default-roles

Example Value:

default-roles = Staff, Walk-ins

Informational Note:

When user is fully authN or IdP but would not like to release his/her roles to DSpace (for privacy reasons?), what should the default roles be given to such user. The values are separated by semi-colon or comma.

Property:

Code Block
role.Senior\ Researcher
role.Librarian

Example Value:

Code Block
role.Senior\ Researcher = Researcher, Staff
role.Librarian = Administrator

Informational Note:

The following mappings specify role mapping between IdP and Dspace. The left side of the entry is IdP's role (prefixed with 'role.') which will be mapped to the right entry from DSpace. DSpace's group as indicated on the right entry has to EXIST in DSpace, otherwise user will be identified as 'anonymous'. Multiple values on the right entry should be separated by comma. The values are CASE-Sensitive. Heuristic one-to-one mapping will be done when the IdP groups entry are not listed below (i.e. if 'X' group in IdP is not specified here, then it will be mapped to 'X' group in DSpace if it exists, otherwise it will be mapped to simply 'anonymous'). Given sufficient demand, future release could support regex for the mapping special characters need to be escaped by '\'

...

When configuring your Shibboleth Service Provider there are two paradigms you may use: Active or Lazy Sessions. Active sessions is where the mobmod_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 limited areas - such as administration.

...

When configuring your Shibboleth Service Provider there are two paradigms you may use: Active or Lazy Sessions. Active sessions is where the mobmod_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 limited areas - such as administration.

...

  1. See the HTTPS installation instructions to configure your Web server. If you are using HTTPS with Tomcat, note that the <Connector> tag must include the attribute clientAuth="true" so the server requests a personal Web certificate from the client.

  2. Add the org.dspace.authenticate.X509Authentication plugin first to the list of stackable authentication methods in the value of the configuration key plugin.sequence.org.dspace.authenticate.AuthenticationMethod

    Configuration File:

    [dspace]/config/modules/authentication.cfg

    Property:

    plugin.sequence.org.dspace.authenticate.AuthenticationMethod

    Example Value:

    Code Block
    plugin.sequence.org.dspace.authenticate.AuthenticationMethod = \
 org.dspace.authenticate.X509Authentication, \
 org.dspace.authenticate.PasswordAuthentication

...

Configuration File:

[dspace]/config/modules/authentication-x509.cfg

  1. You must also configure DSpace with the same CA certificates as the web server, so it can accept and interpret the clients' certificates. It can share the same keystore file as the web server, or a separate one, or a CA certificate in a file by itself. Configure it by one of these methods, either the Java keystore

    Code Block
    keystore.path =  path to Java keystore file
keystore.password =  password to access the keystore

    ...or the separate CA certificate file (in PEM or DER format):

    Code Block
    ca.cert =  path to certificate file for CA whose client certs to accept.
  2. Choose whether to enable auto-registration: If you want users who authenticate successfully to be automatically registered as new E-Persons if they are not already, set the autoregister configuration property to true. This lets you automatically accept all users with valid personal certificates. The default is false.

...