TABLE OF CONTENTS

Ensuring your Shibboleth IdP is functioning

Before undertaking any customisation of your Shibboleth IdP and after each change you make to customise your Shibboleth IdP we recommend testing to ensure everything is functioning correctly. 


To facilitate this the AAF provides a useful tool, called AAF Attribute Validator. This tool will ensure that your IdP is working correctly with backend security processes and that it is capable of providing the attributes your users may be asked to present when accessing federated services.


A ‘private’ browser session as the best tool for working with AAF Attribute Validator. Different browsers will have different names for ‘private’ mode, e.g. Incognito Mode.


To access AAF Attribute Validator:

Follow the flow to login, ensuring you choose your new Shibboleth IdP when promoted at the Discovery Service.


How the Shibboleth IdP installer manages your configuration


IMPORTANT: All modifiable configuration is housed in the directory: 

/<INSTALL_BASE>/shibboleth-idp4-installer/repository/assets/<HOST_NAME>

By default <INSTALL_BASE> = /opt



The structure of your configuration directory will look similar to the following:


.
|---idp
| |---bilateral
| | |---credentials
| | |---filters
| | |---metadata
| |---branding
| | |---messages
| | | |---messages.properties
| | |---views
| | | |---admin
| | | | |---unlock-keys.vm
| | | |---client-storage
| | | | |---client-storage-read.vm
| | | | |---client-storage-write.vm
| | | |---duo.vm
| | | |---error.vm
| | | |---intercept
| | | | |---attribute-release.vm
| | | | |---expiring-password.vm
| | | | |---impersonate.vm
| | | | |---terms-of-use.vm
| | | |---login-error.vm
| | | |---login.vm
| | | |---logout-complete.vm
| | | |---logout-propagate.vm
| | | |---logout.vm
| | | |---spnego-unavailable.vm
| | | |---user-prefs.js
| | | |---user-prefs.vm
| | |---webapp
| | | |---css
| | | | |---consent.css
| | | | |---logout.css
| | | | |---main.css
| | | |---images
| | | | |---failure-32x32.png
| | | | |---logo-mobile.png
| | | | |---logo.png
| | | | |---success-32x32.png
| | | |---index.jsp
| | | |---js
| | | | |---Duo-Web-v2.js
| | | | |---Duo-Web-v2.min.js
| | | | |---jquery-3.4.1.min.js
| |---conf
| | |---access-control.xml
| | |---admin
| | | |---general-admin.xml
| | | |---metrics.xml
| | |---attribute-filter.xml
| | |---attribute-registry.xml
| | |---attribute-resolver.xml
| | |---attributes
| | | |---custom
| | | | |---auEduPersonSharedToken.props
| | | | |---README
| | | |---default-rules.xml
| | | |---eduCourse.xml
| | | |---eduPerson.xml
| | | |---inetOrgPerson.xml
| | | |---samlSubject.xml
| | |---audit.xml
| | |---authn
| | | |---authn-comparison.xml
| | | |---authn-events-flow.xml
| | | |---discovery-config.xml
| | | |---duo-authn-config.xml
| | | |---duo.properties
| | | |---external-authn-config.xml
| | | |---function-authn-config.xml
| | | |---general-authn.xml
| | | |---ipaddress-authn-config.xml
| | | |---jaas-authn-config.xml
| | | |---jaas.config
| | | |---krb5-authn-config.xml
| | | |---ldap-authn-config.xml
| | | |---mfa-authn-config.xml
| | | |---password-authn-config.xml
| | | |---remoteuser-authn-config.xml
| | | |---remoteuser-internal-authn-config.xml
| | | |---saml-authn-config.xml
| | | |---spnego-authn-config.xml
| | | |---x509-authn-config.xml
| | | |---x509-internal-authn-config.xml
| | |---c14n
| | | |---attribute-sourced-subject-c14n-config.xml
| | | |---simple-subject-c14n-config.xml
| | | |---subject-c14n-events-flow.xml
| | | |---subject-c14n.xml
| | | |---x500-subject-c14n-config.xml
| | |---cas-protocol.xml
| | |---credentials.xml
| | |---edugain-attribute-filter.xml
| | |---errors.xml
| | |---global.xml
| | |---idp.properties
| | |---intercept
| | | |---consent-intercept-config.xml
| | | |---context-check-intercept-config.xml
| | | |---expiring-password-intercept-config.xml
| | | |---external-intercept-config.xml
| | | |---impersonate-intercept-config.xml
| | | |---intercept-events-flow.xml
| | | |---profile-intercept.xml
| | |---ldap.properties
| | |---logback.xml
| | |---metadata-based-attribute-filter.xml
| | |---metadata-providers.xml
| | |---relying-party.xml
| | |---saml-nameid.properties
| | |---saml-nameid.xml
| | |---services.properties
| | |---services.xml
| | |---session-manager.xml
|---jetty
| |---root
| | |---favicon.ico
| | |---favicon-mobile.ico
|---tls
| |---intermediate.crt
| |---server.crt
| |---server.key


If you make configuration changes directly within /opt/shibboleth/shibboleth-idp, /opt/jetty or elsewhere your installation will become unsupported and you may have difficulties when upgrading. 


Here are some of the areas you should customise when preparing a Shibboleth IdP for a production environment:

  • The Shibboleth IdP MUST use valid certificates, verified by a widely trusted CA, for the client facing areas of the IdP application

       
  • Ensure all AAF CORE attributeson the AAF Attribute Validator are shown with green ticks to indicate successful release
    • A Not supplied for eduPersonEntitlement is acceptable as this attribute is currently rarely used. 


  • Branding should be consistent with your organisations corporate branding, images, logos, colour schemes, etc


  • Corporate links, eg Accessibility, Copyright, Disclaimers, Privacy, etc should be consistent with the corporate site


  • The name known by your users for their username / password should be consistently used on the IdP login page


  • Links to a corporate terms of use or similar page

 

  • Link provided to recover lost password, manage passwords or other credentials, et


  • Guidance for users about effectively logging out, particularly when using publicly accessible computer


  • Minimise and preferably eliminate the use of technical jargon

 

  • Showing the name of the service the user is logging into, possibly the logo as well if it is available



Updating the Shibboleth IdP with customisations

Deploy

To deploy the changes you have made to the IdP run the deploy script.

/opt/shibboleth-idp4-installer/repository/deploy

Changes to your assets area will be deployed to the operational IdP and the IdP will be restated. There will be a short outage of the IdP as it is restarted, usually less than 2 minutes.


Actions undertaken during an deployment

The deploy process will perform the following:

1. Update underlying operating system packages to ensure any security issues are addressed

2. Apply any configuration changes made within the assets directory for: 

  • Shibboleth IdP
  • Jetty


3. RESTART all dependant processes.


You MUST have a tested rollback plan in place before running an deployment to ensure any unanticipated changes can be reversed.


Upgrade

To upgrade to a later version of the IdP or supporting software run the upgrade script.

/opt/shibboleth-idp4-installer/repository/upgrade

This action only upgrades the Ansilbe configuration, tasks and templates used to deploy the IdP. It will NOT deploy the changes. You MUST deploy the IdP as a separate step for the changes to the Ansible files to be effected.


Actions undertaken during an upgrade

The Ansible configuration is synced with the contents of the AAF IdP v4 installer Git Hub repository. Changes made by the AAF will be reflected in your repository ready for the next deployment. Changes could include

  • Minor bug fixes and improvements to the installer
  • Changes to versions of software to be installer, generally Shibboleth or Jetty
  • Additional functionally being added to the IdP


Next Step

Once you’ve finalised customisations please continue to the operation stage.