Testing Raven-authenticated web sites and applications

Testing Raven-based web sites and applications

It is difficult to test web sites and applications that use Raven for user authentication, given that people only have access to a single Raven-established identity. These difficulties are magnified for applications and sites that use information from Lookup (either directly over LDAP, or via the Lookup API, or indirectly when using Raven's SAML service) to make access control decisions and for personalisation.

This document sets out some approaches that can be used to address these difficulties. It also identifies two new facilities that UIS could provide which might significantly simplify many testing scenarios (highlighted in red here and in the attached table).

This document ignores possible future issues of testing web sites and applications that use the Blue Active Directory for authentication or access control.

Terminology

Raven provides two separate identity services: one based on the local Ucam-WebAuth protocol – often just called 'Raven', and one based on SAML (the Security Assertion Markup Language) – often called 'Shibboleth' after the software often used to implement it.

Ucam-WebAuth only provides a user identity (in the form of a CrsID). Access control<ref name="ftn1">The Apache web server project uses the term 'Authorization' for what this document calls 'Access Control', and uses 'Access Control' to refer to limiting access based on client network address or similar.. The author of this document thinks that 'Authentication' and 'Authorization' look too similar to be helpful.</ref> decisions and personalisation need to reference other data, which might be maintained locally or which could come from Lookup (or other central source).

The Raven SAML service provides both a user identity and a collection of data about that user extracted from Lookup in the form of key=value attributes. Access control decisions and personalisation can use these attributes or, as with Ucam-WebAuth, reference other data which might be maintained locally or which could come from Lookup or elsewhere.

The process of authenticating users and making access control decisions can be implemented either inside a web server such as Apache, IIS, Tomcat, etc. This approach is often called Container-managed security. Alternatively they can be implemented entirely inside a web application. This approach is often called Application-managed security. Web server agents for Ucam-WebAuth and SAML normally make user identity and attributes available in the environment of web applications that they run. This makes a third Hybrid security approach possible that uses container-managed authentication and application-managed access control.

The problem

The problem space has several axes:

• Authentication protocol: Ucam-WebAuth or SAML
• Security approach: Container-managed, Application-managed, Hybrid
• Access control and personalisation information source: local, Lookup direct, Lookup via SAML attributes.
  
  In addition, testing may be targeted at the application itself or at the interaction between the application itself and Raven and central access control information sources. Some testing approaches are not suitable for the latter purpose.

Test instance

Almost all testing scenarios require a separate 'test' or 'development' instance. Providing test facilities as part of a production instance is fraught with difficulty and comes with some security risks. Consider having at least one 'test' or 'development' instance of you site or application. Note that this might have licensing implications.

Test instances mustn't have trusted read or write access to any real-world information since they are likely to be working internally with identities that don't correspond to the people actually using them. Trusted read or write access to real-world information could lead to unauthorised disclosure or modification.

Test authentication and access control information servers

Some approaches listed involve the creation of a local clone of the lookup service (or at least enough of a clone to support the functionality being used), or the creation of a local SAML Identity Provider. While both are clearly possible, setting up either would be a significant amount of work and could be technically challenging. Doing so is unlikely to be practical except as part of a shared resource supporting a significant amount of development. Scenarios based on such approaches are shown in grey in this document.

Possible approaches

Note: a summary of all these approaches appear in the attached table.

Own ID, change local access control information (optionally with local Lookup clone)

A single ID can be used to test operation for different types of user if the access control and personalisation information associated with the ID is under local control and can be modified. This approach can be used when the information is managed locally, or with systems that collect information from Lookup by creating a local clone of the Lookup service.

Developers often use their single Raven identity to grant 'super-user' or 'Admin' access to a web application. In this case it can be difficult to also use that identity to test what normal users will see since this would involve giving up enhanced access which would then be difficult to recover. Consider using a separate authentication system for managing super user access from whatever controls normal user access.

This approach works in most scenarios except where access control is managed by SAML attributes (but see below).

Own ID, change access control rules

Where access control and personalisation is managed by SAML attributes there are usually a set of rules by which particular attribute values trigger particular behaviour. If these rules can be modified then a single ID can be used to test operation for different types of user. For example if 'student' behaviour is normally triggered by misaffiliation=student then a member of staff would experience student behaviour if the rule were changed to misaffiliation=staff.

As above, problems will arise if the rights to make such rule changes were tied to the ID being used for testing.

This approach is best suited were access control or personalisation is managed by SAML attributes.

Replace web server authentication and or access control configuration

When authentication and/or access control is being managed by the web server container, one approach is to re-configure the web server to use different authentication and/or access control systems on a test server. For example a production application on Apache might use mod_ucam_webauth to implement Ucam-WebAuth authentication and mod_authnz_ldap to implement Lookup-based access control in production. Test instances could alternatively use mod_auth_basic and mod_authn_file which would allow unlimited test accounts with any configuration needed.

This approach only works for application-managed and (partially) for hybrid security schemes. It can't be used to test interaction between applications and Raven, and may be difficult to retro-fit to existing applications that don't already support it.

Impersonation support

Applications can be built with a testing mode in which authorised users, or sometimes anyone, can choose the identity under which the application will run. Access control information and personalisation information can then be looked up based on this impersonated identity.

This approach only works for application-managed and (partially) for hybrid security schemes. It can't be used to test interaction between applications and Raven, and may be difficult to retro-fit to existing applications that don't already support it.

Replace application authentication and/or access control configuration

As with the scenario above, if authentication and/or access control is being managed by the application then an approach would be to allow the application to use different authentication and/or access control systems on live and test instances. This would also allow test configuration to have unlimited test accounts with any configuration needed.

Rather than actually implementing support for additional authentication and/or access control systems, the standard development technique of replacing the real interface to authentication and/or access control systems with a 'mock' one that returns data under local control<ref name="ftn2">https://en.wikipedia.org/wiki/Mock_object</ref> could be used.

This approach only works for application-managed and (partially) for hybrid security schemes. It can't be used to test interaction between applications and Raven, and may be difficult to retro-fit to existing applications that don't already support it.

Test & Demo Ucam-WebAuth Server (optionally with local Lookup clone)

In addition to the main Raven service, a separate 'Test & Demonstration server exists<ref name="ftn3">http://raven.cam.ac.uk/project/test-demo/</ref>. This is a copy of the main server with near-identical configuration but configured with 500 test accounts with well-known passwords. A test server configured to use this for authentication can use these accounts for any purpose. This approach can be used when access control or personalisation information is managed locally, or with systems that collect information from Lookup by providing a local clone of the Lookup service.

Care is needed if any of these accounts grant to 'super-user' or 'Admin' access to the test system, since their passwords are well known. As suggested elsewhere, consider using a separate authentication system for managing super user access from whatever controls normal user access. As also mentioned elsewhere, it is important that test systems using the Test & demonstration Raven server don't have trusted read or write access to any real-world information

This approach works for any system using Ucam-WebAuth, but not otherwise. It can't be used to test the interaction between the application and Lookup.

Implement own SAML Identity Provider (optionally with local Lookup clone)

A number of SAML identity provider solutions are available, including the Shibboleth Consortium IdP software used by Raven<ref name="ftn4">https://shibboleth.net/products/identity-provider.html</ref>. A local identity provider allows a test application to receive authentications on behalf of an unlimited number of test accounts with arbitrary associated attributes. SAML explicitly supports the idea of application using more than one identity provider, opening the possibility of a test instance supporting local test identities and Raven identities at the same time. Applications that use Lookup directly as an access control information source would additionally need access to a local clone of the Lookup service containing information on the test accounts supported by the local identity provider.

This approach works for any system using SAML, but not otherwise. It can't be used to test interaction between applications, Raven and Lookup.

[Future development] Test & Demo Shibboleth server and/or Test & Demo Lookup server

Rather than requiring developers to create their own test Shibboleth server or Lookup clone, it would b possible to extend the existing Test & Demo Ucam-WebAuth server by creating a analogous Test & Demo Shibboleth server and a test Lookup server populated with data corresponding to the test accounts provided by the Test & Demo Ucam-WebAuth server. Ideally this data would be aligned to a set of universality applicable core ‘personas’.

Such services don’t currently exist, though they appear as long-term aspirations on the current Raven service development backlog.