RADIUS-Aware Gateway to Shibboleth

The RADIUS-aware Gateway to Shibboleth’s main drive is to allow the combination of the JANET Roaming Service (JRS) Framework with a number of Shibboleth Federations. This provides existing JRS users to seamlessly access resources that were previously only available to Shibboleth enabled sites.

The RADIUS-Aware Gateway to Shibboleth requires the Shibboleth Identity Provider to be installed locally, along with libraries from JRadius. Both these applications have dependencies in order to install correctly. The Installation Guides Section contains helpful installation walkthroughs for Shibboleth, JRadius and RAGS, that also cover the applications they are dependant on.

The Downloads Section contains a variety of useful items. From there you can get your hands on the RAGS source code, which is comprised of the Java files of the RadiusLoginModule, and various Shibboleth configuration files.

All promotional materials can be found there too, including the initial project proposal to Jisc, a short powerpoint presentation as well as the poster shown at the recent Jisc Access Management showcase event in London.

Shibboleth is clearly gaining some traction in the UK academic community, helped by pilot work by the SDSS. There is significant JISC funding to kick-start Shibboleth deployment projects and to support early adopters.

At the same time, the JRS is also gaining traction. Indeed, there are already at least 30 UK sites that are members of the JRS, and who have taken part in the pilot phase of the deployment - while the JRS was known as LIN - in the past 12-18 months. This has been successful, and there is every indication that the JRS will grow to many more sites.

So that leaves us with an interesting situation. On the one hand there is Shibboleth as a framework for access control for (web-based) applications, on the other we have the JRS for network layer access control, aimed at Wireless LANs, but with utility for wired networks also.

We propose that the JRS should be considered as an authentication back-end to Shibboleth. Many sites already have a RADIUS presence, either for JRS or some other network access application, but few have a Shibboleth presence. Having surveyed the Shibboleth early adopter list, and the JRS site list, we believe that of the 25 initial JRS sites (and 5 committed sites) and 30 or so Shibboleth sites, the overlap is only 11 sites. That means that there is plenty of potential for JRS sites to utilise such a facility.

The basic model for bolting the JRS on as a back-end to Shibboleth would be to provide a trusted proxy server that could be selected by a user from a WAYF service. That server would be a proxy to the JRS authentication infrastructure, presented as a (potentially customised per site) web login screen. We refer to the proxy as a Virtual Identity Provider (VIdP)

One of Shibboleth’s strengths is its ability to handle (assert) attribute values between the Identity Provider (IdP) and the Service Provider (SP). A UKEduPerson attribute set for the UK Shibboleth federation has been defined, based on EduPerson, and has laid out a (limited) set of recommended attributes. These may be sufficient for many - if not most - applications, but there is nothing to prevent an IdP and a SP agreeing their own additional bespoke attributes. There seem to be three classifications of attribute-linked authorisation:

Scenario A - No attributes required; just being a UKEduPerson is enough; in this case authorisation is in effect authentication

Scenario B - The basic recommended UKEduPerson schema is sufficient; authorisation decisions can be made on a common set of pre-agreed attributes

Scenario C - Additional bespoke attributes are required; this is the more complex scenario.

Given these three scenarios, the question is now how the JRS can support those classes. Scenario A is essentially what the JRS offers now, so could be utilised as is. Scenario B would require some specific injection of attribute data in RADIUS (from the VIdP to the JRS site), where that set of attributes is well-known. Scenario C would present a significant challenge, because bespoke changes are almost certainly needed for each additional attribute type.

While Scenario C would be problematic, one would imagine that most IdP’s would want to maintain only a common, standardised set of attributes, for the sake of their own administration effort. We thus target Scenario A and Scenario B with the proposed VIdP service.

The RADIUS-Aware Gateway to Shibboleth’s architecture builds on top on the existing Shibboleth architecture, and so we present details of the processes involved between the original Shibboleth components and those of the RADIUS-Aware Gateway to Shibboleth. In its current state the RADIUS-Aware Gateway to Shibboleth satisfies the objectives laid out in Scenario A, detailed above.

Shibboleth is comprised of four core components; the client, the service provider (the resource owner), the identity provider (usually the user’s home site) and the WAYF (Where Are You From) service. In turn the JRS uses the RADIUS protocol to relay authentication requests from a local wireless network device, gateway or application to a site’s local RADIUS server. The convergence of these two entities is brought about by the RADIUS-Aware Gateway to Shibboleth as depicted below.

The interactions between these components can be complex, but can loosely be summarised as follows. The client attempts to use a Shibboleth ‘controlled’ web resource at the SP. The SP redirects the client to the WAYF, so the client can select (declare) their home site (IdP). The client then authenticates with their IdP; if successful, further attribute information may be requested from the IdP by the SP, upon which to base a final access decision.

With the RADIUS-Aware Gateway to Shibboleth the user selects the Virtual IdP, the IdP representing all the organisations that make up the JRS. The user is redirected to the Single Sign-On service where they enter their JRS credentials. The RADIUS Login Module, constructed from JRadius Java classes, uses these credentials to create a RadiusRequest packet. The RadiusRequest is then tunnelled over EAP-TTLS to the user’s home organisation via the National RADIUS Proxy Server (NRPS) which proxies the request through the JRS Framework. If the user successfully authenticates they are redirected to the protected resource with a Shibboleth assertion in hand granting them access.

For additional information, please email the Lichen Mailing List.