All Versions
- DSpace 7.x (Current Release)
- DSpace 8.x (Unreleased)
- DSpace 6.x (EOL)
- DSpace 5.x (EOL)
- More Versions...
Table of Contents | ||||||
---|---|---|---|---|---|---|
|
...
Configuration File: |
| ||||
---|---|---|---|---|---|
Property: |
| ||||
Example Value: |
| ||||
Informational Note: | The option specifies that the email comes from the mentioned header. This value is CASE-Sensitive. | ||||
Property: |
| ||||
Example Value: |
| ||||
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: |
| ||||
Example Value: |
| ||||
Informational Note: | Optional. Specify the header that carries user's last name. This is used for creation of new user. | ||||
Property: |
| ||||
Example Value: |
| ||||
Informational Note: | This option forces the software to acquire the email from Tomcat. | ||||
Property: |
| ||||
Example Value: |
| ||||
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: |
| ||||
Example Value: |
or
| ||||
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 | ||||
Property: |
| ||||
Example Value: |
| ||||
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: |
| ||||
Example Value: |
| ||||
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.
...
<Connector>
tag must include the attribute clientAuth="true"
so the server requests a personal Web certificate from the client.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: |
| ||
---|---|---|---|
Property: |
| ||
Example Value: |
|
...
Configuration File: |
|
---|
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. |
autoregister
configuration property to true
. This lets you automatically accept all users with valid personal certificates. The default is false
....