Shibboleth - Revision history

Drn@ecs.soton.ac.uk: Changed from sp_metadata.xml to sp-metadata.xml for better filename convention

2026-02-04T18:01:19Z

Changed from sp_metadata.xml to sp-metadata.xml for better filename convention

Drn@ecs.soton.ac.uk: /* With attribute-map.xml */

2025-11-17T10:45:43Z

‎With attribute-map.xml

Drn@ecs.soton.ac.uk: /* Shibboleth Configuration Issues */

2025-11-17T10:45:19Z

‎Shibboleth Configuration Issues

Libjlrs: /* Using Remote IdP Metatdata */

2025-08-07T15:33:53Z

‎Using Remote IdP Metatdata

Ejo1f20: /* Configuring Shibboleth */

2025-01-21T15:17:36Z

‎Configuring Shibboleth

Ejo1f20: /* Configuring Shibboleth */

2025-01-21T14:47:45Z

‎Configuring Shibboleth

Ejo1f20 at 14:22, 21 January 2025

2025-01-21T14:22:54Z

Ejo1f20: typo

2025-01-21T14:20:27Z

typo

Ejo1f20 at 14:19, 21 January 2025

2025-01-21T14:19:49Z

Drn@ecs.soton.ac.uk: Advice about added ns to metadata generated for service provider

2024-10-25T15:23:23Z

Advice about added ns to metadata generated for service provider

@@ Line 93: / Line 93: @@
 * Run '''metagen.sh''' from the '''/etc/shibboleth/''' directory, as follows replacing '''foo.eprints.org''' with your EPrints repository hostname.  You will ultimately need to send the output of this to the person managing the Shibboleth IdP server with which you want to register your EPrints repository as a service.
    root> cd /etc/shibboleth
-   root> ./metagen.sh -ALO -c foo/sp-cert.pem -h foo.eprints.org -e https://foo.eprints.org/shibboleth > foo/sp_metadata.xml
+   root> ./metagen.sh -ALO -c foo/sp-cert.pem -h foo.eprints.org -e https://foo.eprints.org/shibboleth > foo/sp-metadata.xml
-* Modify ''' foo/sp_metadata.xml''' to add in the namepace definitions by separately changing the <code>md:EntityDescriptor</code> and <code>ds:KeyInfo</code> lines as follows from:
+* Modify ''' foo/sp-metadata.xml''' to add in the namepace definitions by separately changing the <code>md:EntityDescriptor</code> and <code>ds:KeyInfo</code> lines as follows from:
   <md:EntityDescriptor entityID="https://foo.eprints.org/shibboleth">
     ...
@@ Line 312: / Line 312: @@
 * In a web browser go to the '''/shibboleth/login''' page for your repository, (e.g. ''https://foo.eprints.org/shibboleth/login'').  Like before with ''/cgi/shibboleth'' you should be taken to your Shibboleth IdP's site albeit displaying an error message.
-* The Shibboleth IdP shows an error message because EPrints as a Shibboleth Service Provider is not yet registered with it.  To do this you need to send the administrator of the Shibboleth IdP the metadata for your Service Provider.  You will have generated this earlier when you ran <code>metagen.sh</code>.  Copy off your EPrints server the file that this wrote (e.g. to <tt>/etc/shibboleth/foo/sp_metadata.xml</tt>) and send it to the Shibboleth IdP administrator.  They should be able to upload this to register EPrints as a Service Provider application.
+* The Shibboleth IdP shows an error message because EPrints as a Shibboleth Service Provider is not yet registered with it.  To do this you need to send the administrator of the Shibboleth IdP the metadata for your Service Provider.  You will have generated this earlier when you ran <code>metagen.sh</code>.  Copy off your EPrints server the file that this wrote (e.g. to <tt>/etc/shibboleth/foo/sp-metadata.xml</tt>) and send it to the Shibboleth IdP administrator.  They should be able to upload this to register EPrints as a Service Provider application.
 * Once registered, use a web browser to go to '''/shibboleth/login''' page for your repository, (e.g. ''https://foo.eprints.org/shibboleth/login'') again.  This time you should be prompted for a username and password on the Shibboleth IdP site. Once you have typed this in and clicked to login, you should be returned to EPrints on the '''/cgi/users/home''' page for your repository.  If not, see [[#Login_Issues|Login Issues]] under [[#Troubleshooting|Troubleshooting]] below.

@@ Line 357: / Line 357: @@
    <Attribute name="givenName" nameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic" id="givenName"/>
-A typical Shibboleth IdP would have both a namespaced attribute name and would not apply a format to an attribute that is a simple text string.  Therefore it is worth enquiring with the IdP provider if either of these two happen to be the case.  The Shibboleth Service Provider can be [[run in debug mode|Shibboleth Debug Logging]], which may help your figure out what attributes are being mapped..
+A typical Shibboleth IdP would have both a namespaced attribute name and would not apply a format to an attribute that is a simple text string.  Therefore it is worth enquiring with the IdP provider if either of these two happen to be the case.  The Shibboleth Service Provider can be [[Shibboleth Debug Logging|run in debug mode]], which may help your figure out what attributes are being mapped..
 ==== With idp-metadata.xml ====

@@ Line 350: / Line 350: @@
 -09-09 09:26:43 INFO Shibboleth.AttributeExtractor.XML [2]: skipping unmapped SAML 2.0 Attribute with Name:  givenName, Format:urn:oasis:names:tc:SAML:2.0:attrname-format:basic
-# The attribute itself has no namespace it is just ''''givenName''' rather than '''urn:mace:dir:attribute-def:givenName'''
+# The attribute itself has no namespace it is just '''givenName''' rather than '''urn:mace:dir:attribute-def:givenName'''
 # The attribute has a format that most also be defined in the attribute-map.xml attribute.
@@ Line 357: / Line 357: @@
    <Attribute name="givenName" nameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic" id="givenName"/>
-A typical Shibboleth IdP would have both a namespaced attribute name and would not apply a format to an attribute that is a simple text string.  Therefore it is worth enquiring with the IdP provider if either of these two happen to be the case.
+A typical Shibboleth IdP would have both a namespaced attribute name and would not apply a format to an attribute that is a simple text string.  Therefore it is worth enquiring with the IdP provider if either of these two happen to be the case.  The Shibboleth Service Provider can be [[run in debug mode|Shibboleth Debug Logging]], which may help your figure out what attributes are being mapped..
 ==== With idp-metadata.xml ====

@@ Line 124: / Line 124: @@
   chown shibd:shibd /etc/shibboleth/foo/idp-metadata.xml
-* To test Shibboleth you will need to make sure your '''LD_LIBRARY_PATH''' is set the same as shibd would have when started using ''systemctl shibd start''.  This should return the message: ''overall configuration is loadable, check console for non-fatal problems''.
+* To test Shibboleth you will need to make sure your '''LD_LIBRARY_PATH''' is set the same as shibd would have when started using ''systemctl shibd start''.
   LD_LIBRARY_PATH=/opt/shibboleth/lib64:$LD_LIBRARY_PATH shibd -t
 * The above message is because it is now advised not to leave the MetadataGenerator enabled unnecessarily.  However, whilst you are setting up Shibboleth, it is useful to have the metadata generator, save you needing to build your own Service Provider metadata file to register with your Identity Provider.  Later on you can comment out the MetadataGenerator line to stop getting this warning message.

@@ Line 96: / Line 96: @@
 * Modify ''' foo/sp_metadata.xml''' to add in the namepace definitions by separately changing the <code>md:EntityDescriptor</code> and <code>ds:KeyInfo</code> lines as follows from:
-  <md:EntityDescriptor entityID="https://for.eprints.org/shibboleth">
+  <md:EntityDescriptor entityID="https://foo.eprints.org/shibboleth">
     ...
       ...
         <ds:KeyInfo>
 to:
-  <md:EntityDescriptor xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata" entityID="https://for.eprints.org/shibboleth">
+  <md:EntityDescriptor xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata" entityID="https://foo.eprints.org/shibboleth">
     ...
       ...

@@ Line 80: / Line 80: @@
    root> ./keygen.sh -f -h foo.eprints.org -e https://foo.eprints.org/shibboleth
-* Move the new '''sp-cert.pem''' and '''sp-key.pem''' to '''/etc/shibboleth/foo/''' amd move the ''.old'' files back in place:
+* Move the new '''sp-cert.pem''' and '''sp-key.pem''' to '''/etc/shibboleth/foo/''' and move the ''.old'' files back in place:
    root> cd /etc/shibboleth
    root> mv sp-cert.pem sp-key.pem foo/

@@ Line 1: / Line 1: @@
 {{Manual}}
-'''This page details how to install and integrate Shibboleth with EPrints 3.3.x or 3.4.x on a CentOS 7 operating system.'''  The process should be fairly similar for other comparable Red Hat based Linux distributions such as RHEL 7 and Fedora 21/22.  These instructions should also be generally applicable to later versions of RHEL-based Linux (e.g. Rocky Linux 8, Red Hat Enterprise Linux 9, etc.). However, they ma be somewhat different for Debian-based Linux, such as Ubuntu and Debian itself and other Linux distributions.  Typically, this will just be different package names and different commands to manage applications.
+'''This page details how to install and integrate Shibboleth with EPrints 3.3.x or 3.4.x on a CentOS 7 operating system.'''  The process should be fairly similar for other comparable Red Hat based Linux distributions such as RHEL 7 and Fedora 21/22.  These instructions should also be generally applicable to later versions of RHEL-based Linux (e.g. Rocky Linux 8, Red Hat Enterprise Linux 9, etc.). However, they may be somewhat different for Debian-based Linux, such as Ubuntu and Debian itself and other Linux distributions.  Typically, this will just be different package names and different commands to manage applications.
 Generally, it is a good idea to run EPrints with '''HTTPS''' when using Shibboleth authentication for increased security on the attributes being sent back by the Shibboleth Identity Provider (IdP).  Therefore, it is assumed that EPrints has already been set up to use HTTPS and there already exists an '''ssl/securevhost.conf''' under the archive directory structure.