UAA login pages are insufficiently customisable

What version of UAA are you running?

This is present in v4.7.2.

How are you deploying the UAA?

Using cf-release.

What did you do?

Tried to alter UAA’s authorisation webpages.

What did you expect to see?

We expected a built-in way to modify these pages, for instance by overridding the HTML templates in server/src/main/resources/templates/web.

What goal are you trying to achieve with the UAA?

As part of GOV.UK, we have to follow an organisational style-guide and accessibility guidelines. We’d like to customise the UAA webpages to meet these requirements.

What did you see instead?

The built-in customisation options are insufficient:

• The branding properties can only change things like the name and logo.
• The asset_base_url property can be used to load custom CSS but is documented as deprecated.
• There is no way to alter the HTML templates short of maintaining our own BOSH release.

We’re using asset_base_url for now to specify custom CSS. As it is marked deprecated, we implemented an automatic test that it still works. We’ve also implemented tests that UAA’s templates have not changed very much and that our stylesheet still works.

Why is this an issue?

We think that a lot of organisations have or will have this same issue, and that maintaining our own BOSH release would be a lot of work just to change these pages.

18F have a separate BOSH release that deploys their own custom pages, but this is quite unpleasant and has frightening comments.

An in-built solution, or guidance, on modifying these pages would seem a good idea.

[brittag]

Thanks for filing this! Yes, our 18F/cloud.gov team has this need too, and I agree that this is likely to be common across many organizations, especially in governments and other regulated environments.

As an example, among our other needs for customizing our login pages, we have a specific critical requirement: AC-8 in the NIST standard for security controls. This requires U.S. federal systems like ours to warn readers that their actions may be monitored and recorded. They must explicitly acknowledge that warning (in our case, by clicking our “agree and continue” button) before we can present them with login options.

We would love to see a built-in way to do this rather than maintaining our correctly-described customizing BOSH release. 😃

[keymon]

We don’t have plans to support this level of customization with the UI.

@sreetummidi I think this feature request is important, and even if there are no plans for your team to implement it, we can discuss alternate approaches:

• Would you welcome a PR?
• Can we document a way to customise this login page?