UserInterface

Overview

Most of the user interface involves Spring MVC “views”, which are rendered with a templating engine theoretically chosen from a number of supported options. While this is extensible, the three view resolvers installed by default, in order, are:

  • org.springframework.web.servlet.view.BeanNameViewResolver – used rarely, it resolves a view against a bean of the same name in the Spring context

  • net.shibboleth.ext.spring.velocity.VelocityViewResolver – the most commonly used, supports the Velocity template engine used in other places in the IdP

  • org.springframework.web.servlet.view.InternalResourceViewResolver – a fallback that relies on JSP templates, mainly used for the IdP’s status page

Virtually of the views supplied with the software are Velocity templates (with a “vm” extension). A handful are installed by default because they are core functionality and not installed by a specific Module. The rest are installed as specific modules that manage them are enabled. For example the “login form” consists of a couple of views that are actually part of the Password login flow, which is enabled by default.

When Spring looks for a view template, it will search for one with the “vm” extension in the location(s) specified by the idp.views property, and if it can’t locate one, it will search inside the war within WEB-INF/jsp for a template with the “jsp” extension and run that instead.

For detailed information on the Velocity-related content of the views, see the https://shibboleth.atlassian.net/wiki/spaces/IDP4/pages/1265631615 topic.

Look and Feel

The main purpose of the supplied templates is to define the necessary form submission / link interface contracts required for proper functionality of the various features. In some cases, the views render information from the IdP to the user (e.g., the Consent features) while in others they merely collect information from the user. Logout is the most complex case, and has a bit of both.

The actual look and feel of the views is not in general expected to meet anybody’s needs in particular. Deployers are not only encouraged but expected to change them fairly extensively in most cases. The goal of the installation process is to ensure that functionality is usable and can be tested or demonstrated before the work of aligning the look and feel to meet local expectations is done.

Defaults aside, do NOT use the delivered style sheet or image filenames in production, and always adjust the relevant values in messages/messages.properties to reflect your own chosen names for these files (or replace the use of the properties entirely):

idp.css = /css/osu.css
idp.logo = /images/osu-logo.png

While the original style sheets and images will not be overwritten by upgrades, the properties that refer to them could have their default values changed, which could alter the appearance of your pages if you haven’t defined values for them yourself to supplant the system values.

As in V3, the original V4 releases rely on the following conventions:

  • A couple of sample logos are installed to edit-webapp/images and one is referenced by default via the message property idp.logo

  • Most views link to /css/main.css explicitly. Two more CSS files are installed for specific use cases (consent.css and logout.css).

V4.2 includes a new set of views with updated HTML and references to a new global stylesheet and (empty) placeholder logo. The HTML is intended to be more modern, mobile friendly, and hopefully improve accessibility.

  • A (new to V4.2) sample logo is installed to edit-webapp/images/placeholder.png and is referenced by default via the message property idp.logo

  • All views link to a style sheet installed to edit-webapp/css/placeholder.css; this is referenced by default via the message property idp.css

Upgrades are meant to be safe, but prior to V4.2, the default CSS and logo files (which were strictly provided as examples) have been overwritten during upgrades. This should be corrected in V4.2, but please heed the caution box above: do NOT rely on the default filenames for your “final” configuration. Even if you make use of the provided CSS, copy it to a filename of your own and set the idp.css property to switch to it.