Page Comparison

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 for some internal reasons, 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/JSTL templates, mainly used for the IdP’s status page

Virtually of the views supplied with the software right now 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.

...

For detailed information on the Velocity-related content of the views, see the VelocityVariables 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.

...

Despite the conventional wisdom, in fact the use of Javascript to install and respond to events is extremely non-portable, and that “recommended” technique in practice requires the adoption of JQuery or similar libraries to achieve portability. While we do rely on JQuery for logout status reporting (which itself is not really advisable to expose to end users), we have not adopted it across the views and believe the low level of complexity and releatively relatively small usage of Javascript doesn’t warrant it.

...

• shibboleth.CSPDigester – this is a StringDigester (that is a Function, with apply() called with a Javascript string as input) and produces a base64-encoded SHA-256 digest suitable for use in CSP’s unsafe-hashes “source expression”.

• shibboleth.CSPNonceGenerator – this is an IdentifierGenerationStrategy (an interface in our API) whose generateIdentifier() method will produce an adequately random value to use as a nonce.

Hash Example in Velocity

Hashes are the “strongest” rule possible because they specifically allow a single script that hashes to the matching value. They work well when the content of the script is maintained within a view, and in particular for simple one-liner event handlers for onLoad or onClick events. It is a simple matter (and is demonstrated in the new default views in various places) to assign a Javascript string to a Velocity variable, and apply the digester to produce the hash needed to generate the header.

...

As the example shows, changing the script in some way would only require changing the text in the #set macro, because the hash is computed against whatever is found in that variable. Later on the variable would be used to embed the script into the desired spot in the template.

Nonce Example in Velocity

When hashes are too unwieldy to use, nonces are usually the best fallback, and work well for scripts, particularly external ones. Nonces are generated and then added to both a header at the top of a view and in a nonce attribute in the <script> element:

...

Generally it’s fine to use the same nonce value in multiple places in a view, but it’s also a simple enough matter to produce multiple values if desired.

Reference