SHEBANGS
Shibboleth Enabled Bridge to Access the National Grid Service
M.A.S. Jones, S.M. Pickles, A. Nenadic, N. Zhang
We recognise that there exists a large proportion of the academic community that as yet has not bought into the use of grid technologies. We believe that this is due to the complex nature of the tools required.
While the emergence of portals to provide grid client tools in a more familiar Web browser setting has been well received, little has been done to address the technical and generally hard to manage requirements of gaining the authority to access grid resources. SHEBANGS addresses this by harnessing the Shibboleth (Web based) single sign­on environment currently being rolled out to the academic community in the UK and around the world.
Shibboleth provides a way of linking home­institute dependent authentication to site independent assertions of that individual's identity. Grids like the NGS on the other hand require Grid Security (X509/GSI) credentials and the membership of at least one Virtual Organisation.
SHEBANGS bridges the gap, providing a translation between the Shibboleth world of identity and the Grid world of cross­domain computing and data access, completing the path and allowing academics to gain access to grids while still driving from the comfort of their favourite Web browser.
Introduction
The National Grid Service[1] (NGS) relies on a Public Key Infrastructure (PKI) and X.509 certificates for the authentication of its users. The number of users making use of the NGS today can be counted in the hundreds[2].
Shibboleth[3] has been endorsed by the UK higher education community as the next generation authentication service to replace the widely used Athens[4] system. The potential size of the community that uses Shibboleth can therefore be estimated by the current number of Athens users (more than three million). Athens is a well established centrally administered username and password authentication system that governs access to services such as on­line journals, census data, satellite data, magazine articles etc. [5]. Being a central service the management of its user base is a huge task and the scalability of this system has been drawn into question. The Higher and Further Education communities have made a move towards a more devolved authentication system by adopting Shibboleth and establishing an identity federation.
The Shibboleth based federation provides the end­user with a simple and straightforward system to access online content. Within the federation the user need only remember one authentication mechanism – the one their institute requires; the one their institute supports.
Shibboleth is a browser based authentication mechanism that allows Security Assertion Markup Language (SAML)[6] messages to be passed between a user's home institute and the service provider. This allows an end­user to log into a Web­based services by logging into to their home institute instead. A Single Sign­on environment naturally emerges when HTTP cookies are used to maintain session between the user and their institute.
The shibboleth mechanism is straightforward. The user goes to the service, is redirected to a list of institutes within the federation (the Where Are You From service – WAYF), chooses theirs and logs into it. Access to the service is granted or denied based upon the SAML messages Shibboleth sends through the browser directly or by reference.
The NGS is not fundamentally browser based. It, like most other production grids, uses a highly complicated PKI based authentication system – the Grid Security Infrastructure (GSI). It also requires a more granulated authorisation mechanism based upon Virtual Organisations. Like Shibboleth it also attempts to address the issue of Single Sign­on (SSO) which it achieves by extensions to the PKI – GSI Proxy certificates. The PKI environment required for access to grids is complex and suffers from two main drawbacks:
1.
It is essentially a central service and therefore suffers the same scalability issues Athens has been said to suffer from. The UK eScience CA is currently the largest grid PKI and even so is three orders of magnitude smaller than the Athens community today.
2.
The end­user is entrusted to manage their own identity credentials. Most users have no interest in understanding the complex details of PKI required to do this safely and securely.
The portal technologies that have emerged to provide the tools by which one can access grids via a web browser have not addressed the gap between usability and security. The NGS currently makes use of two[7,8] which provide much of the client functionality needed to run jobs, store and move data but the NGS still needs to make use of the GSI for authorisation decisions.
SHEBANGS provides a method to make the NGS services and resources accessible to end users 'without' public key certificates, by adopting Shibboleth for its interactions with end­
users and translating the SAML assertions into hidden GSI credentials, thus removing the need for users to be part of the PKI.
Figure 1: The CTS first Approach
Architecture
The basic SHEBANGS architecture is shown in figure 1. It comprises of one extra element which sits between the Shibboleth federation's infrastructure and the grid infrastructure: the Credential Translation Service (CTS). The CTS appears to the user as a Shibboleth Service Provider (SP) and is accessed using a Web browser. To the grid infrastructure the CTS appears as a MyProxy Client, a Certificate Authority and a Virtual Organisation Membership Service (VOMS). To use the CTS in its basic configuration the user must visit it as a stand alone service (perhaps as a hyperlink from an existing portal). This is known as the CTS First Approach. In the figure 1 the process takes place as follows:
1.
A user, perhaps referred by a hyperlink from the portal, points their browser at the CTS.
2.
The user's browser is redirected to a trusted Where Are You From (WAYF) service.
3.
The WAYF server presents a simple form which the client completes and posts back to the server. 4.
The user's browser is now redirected to the appropriate institution’s IdP.
5.
Out of bands authentication takes place between the user and the IdP.
6.
The IdP redirects the browser back to the CTS (passing Shibboleth artefacts in the URL).
7.
The CTS uses the artefacts to obtain SAML Assertions from the IdP on a secure back channel. The CTS evaluates the SAML Assertions and issues a GSI Credential.
8.
The CTS delegates this credential to a MyProxy Server.
9.
The CTS returns a web page over HTTPS to the client which contains a MyProxy username:password:server triplet.
10. (11 and 12) The user logs into the portal using the MyProxy triplet, and is now able to use the Grid.
How this appears to the end user is shown in Figures 3­7.
With the addition of one more component the Which VO Are You From service (WVOAYF) the Portal First Approach can be used (figure 2). The Portal first approach provides a Shibboleth­
like redirection to the CTS immediately followed by a redirection to the federation's WAYF service. In this case the user goes to the portal and is asked which VO they are a member of, Figure 2: The Portal First Approach
followed by where are they from. They log in at their home institution and if successful are returned to the portal which retrieves all the necessary grid credentials.
In Figure 2, step 1 has the user accessing the portal first. Steps 2,3 and 4 represent the extra WVOAYF service. Step 12 represents the passing of MyProxy details to the portal rather than to the user. In this approach the user does not need to know anything about the GSI credential or where it has been stored. The user also benefits from not needing to manually point their browser at different URLs.
Implementation
The CTS is designed to be a self contained middleware component so as to be highly portable. It was also decided that the need to rely upon heavy­weight software such as those provided by Globus, LCG or gLite would hinder the uptake of this system and where possible these should be avoided. The focus was therefore placed upon the standard protocols used rather than the native APIs of the existing middleware. The CTS was designed to run from within a Shibboleth protected Apache Web server. It was therefore written assuming the usual Web server CGI environment where access to the Perl interpreter is often the case. The CTS is a CGI Perl script that can be dropped into a Shibboleth protected cgi­bin area of a Web server without recompilation. SHEBANGS also provides its own Perl library of functions for the examination and creation of grid credentials: VOMS­Lite. These have dependencies only to a handful of regular Perl libraries many of which are shipped with an operating systems' Perl installation or can be obtained from CPAN[9].
Identity Attributes – X509 credentials
The mapping between SAML attributes and X.500 names (as used in the Distinguished Name (DN) of an X.509 certificate) is not straightforward. SAML provides a number of schemes for identifying individuals, the grids being addressed by this project do not handle individuals with multiple identities well. A grid will treat an end­user who possesses different names as different individual entities. Therefore care must be taken when describing the end­user. Which attributes are released to describe a user is a decision made by the IdP. It is configurable on a per individual – per SP basis at the IdP. Thus the SAML attributes presented to a particular SP may remain constant for an individual within the administrative domain of their IdP. A bespoke algorithm was therefore established to create a suitable GSI identity as follows:
From the Shibboleth protected Web server the CTS CGI script inherits five pieces of information through environment variables:
1.
2.
3.
4.
5.
HTTP_SHIB_ATTRIBUTES, the end­
user specific XML SAML assertion encoded in base64,
HTTP_SHIB_IDENTITY_PROVIDER, A string representing the organisation to which the end­user authenticated,
SERVER_NAME, the server on which the CTS runs,
SERVER_PORT, the port through which the CTS is accessed,
(HTTPS, a variable which lets the CTS know whether the client accessed the CTS securely.)
The Distinguished Name Sequence of the X.509 credential produced is configurable. For the SHEBANGS demonstration the CTS is constructed according to the following template:
1.
2.
3.
4.
5.
6.
7.
countryName =
organisation =
organisation =
organisation =
domainComponents organisationalUnit commonName UK
SHEBANGS
NGS
TestCTS
from (3)
from (2)
from (1)
An example identity “ANOther” as asserted by the OpenIdP[10] produces a DN of the following form: “/C=UK/O=SHEBANGS/O=NGS/O=TestCT
S/DC=wallace/DC=mvc/DC=mcc/DC=ac
/DC=uk/OU=shib13.openidp.org/CN=
ANOther”
The commonName attribute is set according to the ranked element in the list below for which only one entry exists in the SAML assertion:
1.
2.
3.
4.
urn:oid:2.5.4.3 (X.500 commonName)
urn:mace:dir:attribute­def:
eduPersonPrincipalName
(OID 1.3.6.1.4.1.5923.1.1.1.6)
urn:mace:dir:attribute­def:
eduPersonTargetedID (1.3.6.1.4.1.5923.1.1.1.10)
ResponseID1.
In the case of the first three the DN would be constant between visits. ResponseID is always guaranteed to be there and was used as a fall back. If ResponseID is used however the identity seen by the corresponding grid is transient and lasts only as long as the credential. It is also pseudonymous.
Finally, if the Level of Assurance (LoA) attribute is passed in the SAML assertion – as is presented by the FAME PERMIS IdP[11] – (OID 1.2.826.0.1.3344810.1.1.104) this LoA is used to select which CA certificate is used to sign the X509 Credential. This representation of the 1 ResponseID is not a property of the individual but a property of the assertion carrying the identity, therefore is always available. It is never the same twice.
Level of Assurance allows a relying grid service to make authentication decisions based upon the LoA at the IdP. Alternative methods of representing the LoA were considered:
●
●
The addition of a non­critical extension to the X.509 certificate with the same OID, this was dismissed due to a lack of an X.509 binding for this information;
Adjusting the validity period allowable for the X.509 credential was dismissed as this was deemed an authorisation decision which the CTS is not designed to make.
The multiple CA option best fits practices adopted by the grid community. The IGTF[12] asserts the how trustworthy each CA is based on audit of its procedures and policies and ranks CAs according to a number of profiles. These are the Classic, Short Lived Credential Services (SLCS), Member Integrated X.509 Credential Services (MICS), Experimental and Worthless Profiles. Thus, a high security grid service may only want to trust CAs with a high level of trustworthiness and a low security grid service may want to allow access to people with a reasonably lower level of authentication. This can be achieved by placing the relevant CA certificate in the grid services' trusted CA directories according to the profiles.
Authorisation Attributes – VOMS credentials
The VOMS credential is constructed according to the current VOMS specification [13] and tied to the DN as constructed above. The VOMS VO is configurable and for the SHEBANGS demonstration CTS was set to “/shebangs.ngs.ac.uk”. Roles were obtained from
the
SAML
assertion eduPersonPrimaryAffiliation
and eduPersonAffiliation in that order.
Further Work
The CTS provides a mechanism for small to medium sized Virtual Organisations to issue grid credentials. This gives users communities the means by which to express themselves within a grid infrastructure without investing time and effort maintaining the heavyweight middleware technologies associated with VO management today (e.g. VOMS, CAS). However, to apply this mechanism to the wider grid community, the CTS would either have to become a recognised Naming Authority which itself is a heavyweight process, or make use of similar work from SHEBANG's sister project ShibGrid[14]. This would allow the CTS to concentrate on the VO side while leaving the Identity and Naming to a well established CA using the Shibboleth extensions to the MyProxy CA developed by that project.
References
[1]
The National Grid Service Web page http://www.ngs.ac.uk
[2]
The National Grid Service VOMS service https://voms.ngs.ac.uk:8443/ (restricted)
[3]
The Shibboleth Project web page http://shibboleth.internet2.edu/
[4]
The Athens web page http://www.athens.ac.uk/
[5]
A list of Athens protected resources http://www.athensams.net/allresources.aspx
[6]
The SAML 1.1 specification http://www.oasis­open.org/committees/download
.php/6837/sstc­saml­tech­overview­1.1­cd.pdf
[7]
The NGS Portal https://portal.ngs.ac.uk/
[8]
The P­Grade NGS Portal http://www.cpc.wmin.ac.uk/ngsportal/
[9]
Comprehensive Perl Archive Network http://www.cpan.org
[10]
The OpenIdP https://www.openidp.org/
[11]
FAME Permis Project IdP https://rpc56.cs.man.ac.uk/fame_login_server [12]
The IGTF http://www.gridpma.org/
[13]
VOMS Attribute Specification document from the OGSA AuthZ Working Group of the Open Grid Forum http://www.ogf.org
[14]
ShibGrid Project Page http://www.oerc.ox.ac.uk/activities/projects/inde
x.xml?ID=ShibGrid
Appendix
The following screen shots show the operation of the CTS from the view of an end­user.
Figure 3: The CTS redirects the browser to the federation's WAYF
Figure 4: The user, having selected their institution's Identity Provider (IdP), logs in.
Figure 5: The browser is redirected back to the CTS, which creates the Grid Credentials.
Figure 6: The user visits a grid portal and logs in using the CTS supplied details.
Figure 7: The portal runs tasks on the grid under the translated identity