This page contains notes building towards a formal document regarding the role of Shibboleth with grids. It necessarily challenges some basic assumptions of the way that authentication and authorisation are currently managed in grids.

This work forms the bulk of the eSP-grid workpackage five (Shibboleth Evaluation).

Contents

1. [#intro Introduction: how to use this document]
2. [#contempassumpts Contemporary Assumptions]
   • [#mustscale Grids must scale] ; [#identitymanscalability Identity management is a scalability bottleneck] ; [#identtrustorg Identity is best managed by a very trustworthy organisation] ; [#attributemanscale Attribute management is a scalability bottleneck] ; [#trustminimum Trust must be kept to a minimum on grids] ; [#securityieinadeq Security levels in the 'information environment' are inadequate]
3. [#PKIvsassumpts How does PKI live up to these assumptions?]
   • [#PKImustscale Grids must scale] ; [#PKIidentitymanscalability Identity management is a scalability bottleneck] ; [#PKIidenttrustorg Identity is best managed by a very trustworthy organisation] ; [#PKIattributemanscale Attribute management is a scalability bottleneck] ; [#PKItrustminimum Trust must be kept to a minimum on grids] ; [#PKIsecurityieinadeq Security levels in the 'information environment' are inadequate]
4. [#SHIBrole How could Shibboleth play a role?]
   • [#SHIBmustscale Grids must scale] ; [#SHIBidentitymanscalability Identity management is a scalability bottleneck] ; [#SHIBidenttrustorg Identity is best managed by a very trustworthy organisation] ; [#SHIBattributemanscale Attribute management is a scalability bottleneck] ; [#SHIBtrustminimum Trust must be kept to a minimum on grids] ; [#SHIBsecurityieinadeq Security levels in the 'information environment' are inadequate]
5. [#conclusions Conclusions]

Anchor(intro)

Introduction: how to use this document

Following this introduction, this document is arranged into three major sections. The first addresses the [#contempassumpts Contemporary Assumptions] of grid security and other aspects of access management. Most of the assumptions portrayed are based on sound security principles, but some are possibly a little misplaced. Following this assertion of the current basic principles, we consider (briefly) [#PKIvsassumpts How PKI lives up to these assumptions], considering each assumption in turn. This is followed by a similar treatment regarding [#SHIBrole How Shibboleth could play a role]. This is followed by the general [#conclusions Conclusions].

Anchor(contempassumpts)

Contemporary Assumptions

Anchor(mustscale)

Grids must scale

"The Grid" or "grids" are currently viewed by many as to be at the equivalent stage of conceptual development as was the world wide web and information environment intranets in the late 1980s. There is a widespread assumption that grid use will grow enormously as more people (and other end entities) find a use for high powered and distributed (computing) resources. It is also clear that access management is a far greater issue than for the web, as much more than 'read only' access is required. We have to assume, therefore, that secure access management is a current limiting factor for the ability of the technologies to scale to serve high numbers of users. As an extension to this assumption, resource owners of computing power and expensive instrumentation are far more likely to open up their resources to a grid if they are confident that their resources are secure from harm and the use of unauthorised others outside their (grid) community.

Anchor(identitymanscalability)

Identity management is a scalability bottleneck

Unlike a resource that is meant to be accessed 'read-only', a grid needs to identify its users. The management of those identities is an onerous task and one that needs to be executed via policies which all owners of grid resources can trust. As the numbers of users (or end entities) increases, this becomes an even more difficult task.

Anchor(identtrustorg)

Identity is best managed by a very trustworthy organisation

The concept of authentication is often (erroneously) associated with the separate elements of identity establishment and subsequent on-line authentication. Authentication is the act of verifying that an electronic identity (username, distinguished name etc.) is being employed by the entity, person or process to whom it was issued. Therefore, this relies upon the fact that the electronic identity was issued accurately in the first place. Thus, this early establishment of identity and the subsequent use of the identity needs to be managed by a trustworthy organisation.

Anchor(attributemanscale)

Attribute management is a scalability bottleneck

A user's attributes (roles, status etc.) change frequently, whereas his/her identity should change very infrequently. Therefore, the management of such attributes - which may be used as decision-triggers during authorisation - may be more onerous than the management of the identity.

Anchor(trustminimum)

Trust must be kept to a minimum on grids

This is always true as a general principle. Nevertheless, people often do not consider the related question of the difficulty of the task that they are choosing to trust another entity to carry out. For example, it may be better to trust a total of three entities to carry out a task (if it can be divided and where each sub-task is appropriately handled by each entity) than to trust one entity to carry out that same task (if the task is too difficult for that one entity).

Anchor(securityieinadeq)

Security levels in the 'information environment' are inadequate

By 'information environment' we mean the environment that is managed for most of the users who join a local network and access many (often web based) resources. It is in contrast to a 'grid' environment.

This assumption has been included so that it can be explored further, below. Many consider that large grids cannot trust the identity management and authentication credentials issued from users' home organisations where levels of security may reflect the historic situation where users play more passive roles. In short, many grid users believe that universities, businesses and government agencies - to name a few examples - cannot be trusted to manage identities and user attributes that are used on grids.

Anchor(PKIvsassumpts)

How does PKI live up to these assumptions?

Anchor(PKImustscale)

Grids must scale

The eSP-grid project remains agnostic on this issue. Some experienced commentators believe that the scalability of 'the grid' is being limited by the difficult usability problems of client-based PKI. In the background to this project is the DCOCE project (http://www.dcoce.ox.ac.uk) which found that the usability problems tend to come from many small issues, most of which would be trivial to fix. Nevertheless, the usability problems are many and this affects the user experience very deleteriously.

Anchor(PKIidentitymanscalability)

Identity management is a scalability bottleneck

PKI-based grids address the requirement of good identity management by authorizing nominated, trustworthy Registration Authorities (RAs) to check the identity of the certificate applicant. This system requires the RAs to work to strict security policies, which is good. However, as the RAs usually have to attend a training course in order to be deemed to be trustworthy, there tends to be fewer of them than there should be, ideally. This therefore becomes a scalability bottleneck. Many users have to physically travel large distances to visit their nearest RA. This is likely to deter some ligitimate users.

Furthermore, even though the main purpose of the RA is for authentication and identity management, there is some implicit authorisation taking place during the transaction. This is greatly undesirable, but most PKI implementations mandate it. For example, consider a regional RA performing duties for users at 3 educational establishments, 2 businesses and one government office. The RA may require users to bring proof of identity, such as a passport, and/or a university/security card/pass with their name (and/or photograph) on it. The user will subsequently be issued a certificate where their 'organisational unit' (OU) is (for example) University A. To perform the role of RA properly, the RA should, therefore, check the lists of whoever leaves the 6 organisational units for which s/he performs RA duties. This is an onerous task that is probably never properly fulfilled. Failing this, the Certification Authority (CA) should take on the task. However, the CA is at an even greater distance - organisationally - from the end units than is the RA, and therefore this is a near impossible task.

We conclude that identity management via PKI should work effectively, but only if the RA is an integral part of the home organisation (or truly ideally, the OU) of the end user. Further, the RA should therefore be in prime control over the revocation process. As neither of these are usually true, the PKI is fundamentally flawed, or at best very difficult to scale (as large numbers of RAs are needed).

Anchor(PKIidenttrustorg)

Identity is best managed by a very trustworthy organisation

As noted above, identity is easier to manage than attributes such as role and status. Again, as noted above, it is futile that a very trustworthy body or person is trusted to carry out a task that is nearly impossible for it to achieve to an adequate level of service in practice. As identity in PKI is almost always closely coupled with OU status, then most RAs are unable to manage this task, despite being well trained and trustworthy. RAs have to trust the personnel or registration departments within the OUs in order for them to carry out this task. This extra 'leaf' to the chain of trust is rarely, if ever, acknowledged.

If identity could be truly un-coupled from changeable attributes, such as OU and other status information, then PKI may be more reliable, but this seems to be difficult to implement.

Anchor(PKIattributemanscale)

Attribute management is a scalability bottleneck

Attribute management is not usually performed using PKI (although there are some possibilities using attribute certificates, or even attribute fields in the certificates themselves: the use of which should generally be greatly discouraged!). In the two sections immediately above, we argue that RAs are in a very poor place to manage attributes that will be used for authorisation decisions. Therefore this may be considered as either a flaw of PKI or a necessary absence.

Anchor(PKItrustminimum)

Trust must be kept to a minimum on grids

As noted above, this general principle is true. Due to the difficulties of handling authorisation-triggering attributes via PKI, authorisation is almost synonymous with authentication at most grid resources. i.e. authorisation decisions are usuallly based upon knowledge of identity. For example, a resource considers that these 200 distinguished-name-holders are able to use the resource. This level of sophistication with respect to authorisation is unlikely to be satisfactory in the future where many more grid users exist and where the membership of virtual organisations change dynamically.

As a resource owner, it may not be possible for you to manage more than n users, as there must be an optimum number with whom you could have a direct relationship. Therefore you will have to trust third parties. Even for a very low number of users, a grid resource owner may be the last to find out that a user has been convicted for fraud, or has been determined to have hacked another resource.

Anchor(PKIsecurityieinadeq)

Security levels in the 'information environment' are inadequate

In the above sections, we highlight the flaws in the current arrangements with respect to PKI implementations. Because it is a fact that PKI can support very high levels of security, there is a danger that people perceive that the technology=security, rather than the careful implementation of the technology and following strict policies=good security. It is our assertion that PKI would work well if RAs were embedded deeply in the organisational units (OUs). This is mostly due to security policies and knowledge of the status of individual users.

It follows that the concept of deeply embedded RAs is nearly that which exists with registration or personnel officers that manage the information environment authentication process. On this level, the information environment processes are more secure. Some of the technology used may be less secure (although this is rapidly changing). Therefore, with a greater knowledge of security pervading these 'information environment' managers, it could be that an adequate level of security could be achieved for grid use.

Anchor(SHIBrole)

How could Shibboleth play a role?

Anchor(SHIBmustscale)

Grids must scale

Having considered that identity management performed centrally may be a threat to the scalability of grids, Shibboleth as a system of supporting devolved authentication can be seen to be a solution. The need for devolved authentication is highlighted by the arguments within the [#PKIidentitymanscalability Identity management is a scalability bottleneck] (PKI) section above. Some assume that PKI avoids the difficulties of devolved authentication by using RAs and long term, secure digital authentication credentials. This is clearly false as RAs rely on third parties to vouch for the identities and statuses of the applicants that come before them. This is (conveniently) not generally recognised. However, who issued that user's university card? It was a trusted devolved third party.

Anchor(SHIBidentitymanscalability)

Identity management is a scalability bottleneck

Shibboleth would avoid this bottleneck as, almost by definition, the identity providers already support all of the users that are necessary. The only bottleneck would be if there were different authentication policies required by the grid communities: a reasonable request in some cases, but one which may place more demands on the identity managers than they have currently.

Anchor(SHIBidenttrustorg)

Identity is best managed by a very trustworthy organisation

If identity can be separated completely from status, roles and other attributes - a separation in which Shibboleth excels - then identity becomes of lesser importance. Identity can be established once, using strict security policies and does not need active management.

Anchor(SHIBattributemanscale)

Attribute management is a scalability bottleneck

In a grid that relied upon Shibboleth, this would be true. Active attribute management would become the most onerous part of the security matrix. This is as it should be. Organisationally and procedurally, this is the most complex responsibility. Therefore, identifying this as the true bottleneck should be as expected. Nevertheless, using attribute authorities (AAs) and Shibboleth/SAML transport, attributes could be managed so that they can change frequently and in near-real time. Most advantageously, they can be managed by the individuals who are truly in a position to judge or control their status.

One area where the Shibboleth architecture may fall a little short is in supporting virtual organisations (VOs). Currently, there is space in the main architecture for only one attribute authority (AA) to be associated with an identity provider (IdP). For VOs to be managed easily, a users main/home AA must be able to chain or devolve to third party AAs. An alternative model would be for the resource to initiate a new query to the secondary or VO AA (let's call this AA2). These two possible mechanisms are illustrated below:

Chaining/devolving AAs

In a Shibboleth transaction, a user tries to access or use a grid resource and is directed back to his/her IdP to actively authenticate. This is followed by the resource contacting the user's AA to pick up attributes with which to make the authorisation decision. (For the sake of our example, consider that the resource only allows access/use to entities which belong to a particular VO and have some particular attributes managed by that VO). The VO manages lists of users (or unique IDs) and the users' attributes. The resource 'asks' the home/main AA whether the user is a member of the VO. The AA is unable to manage this information but contains a pointer to the VO's AA2. The AA thus queries AA2 and sends the information back to the resource in the SAML exchange.

(In this way, the VO AA2 trusts the IdP to authenticate the user - something which it cannot do itself - but then confirms back to the home/main AA that the user is (not) a member of the VO and he/she holds these attributes. Of course, the AA would also have to transmit the signed assertion from AA2 to the resource).

The only difficulty with this model is that it is incumbent on the AA to know where is the appropriate AA2. This may be achieved by setting it as a user-editable attribute.

Secondary query to AA`2`

This is a possibly simpler mechanism whereby the resource has the IdP authenticate the user, and possibly supply some attributes, but initiates a separate transaction to the VO AA2 to find out whether the user is a member and to obtain his/her VO attributes. This is achievable using the current Shibboleth architecture (although the query to the AA2 would be an extension). However, the AA would have to always pass a permanent unique user identifier to the resource.

There will, therefore, be some future use cases where this model will break an anonymity or pseudonymity requirement. The user will always have to present the same unique identifier to the resource to gain access or use. This is likely to be an uncommon requirement, but will almost inevitably exist in some cases. Therefore, it may be that the chaining/devolving AAs model is preferable as it should be usable in both of these situations.

Anchor(SHIBtrustminimum)

Trust must be kept to a minimum on grids

We hope that the arguments put forward in the sections above, but especially in the [#PKIidenttrustorg Identity is best managed by a very trustworthy organisation] (PKI) section help to prove that there are more levels of trust in PKI than are usually acknowledged. In a devolved authentication system, the trust is always explicit and this may be seen as an advantage. With the planned support of virtual organisations (VOs) comes a necessary devolution of authorisation-supporting attributes. Shibboleth is generally a good architecture to support this.

Anchor(SHIBsecurityieinadeq)

Security levels in the information environment are inadequate

See the above [#PKIsecurityieinadeq Security levels in the information environment are inadequate (PKI)] section as it is equally applicable here.

Anchor(conclusions)

Conclusions

Devolved authentication

The first argument to explore is the need for devolved authentication, which Shibboleth can support easily, and which PKI could support, but usually does not. We believe that there is a strong argument for devolved authentication for both good security and high scalability reasons. As long as the mal-practicing user can be successfully and quickly traced by the resource provider or grid node, then devolved authentication is very nearly a necessity for a highly scalable and secure grid. Shibboleth provides possibilities for devolved authentication that should be secure enough for grid use as long as Federation security policies are followed by the home organisations (Identity Providers: IdPs).

Authorisation and attribute management

The blurring of what is authorisation and where it occurs often confuses thinking on these matters. It is our assertion that resource owners should set authorisation policies. Home organisations and virtual organisations should associate attributes (such as roles and status) with users and entities that allow the grid resources to make the authorisation decisions. We make no apologies for re-stating these principles. However, much thinking seems to be along the lines that a virtual organisation grants access to a resource; whereas this may be true in practice in many cases, it is theoretically a subset case of main principle that has just been stated.

In any case - and especially for virtual organisations to be a possibility - it must be possible for the appropriate 'managers/administrators' to be able to set user attributes as easily as possible, and to be able to change these frequently and easily. Shibboleth could be easily extended to provide this functionality (see the section on [#SHIBattributemanscale Attribute management is a scalability bottleneck] (Shib) above for ideas as to how this may be achieved. See also the [http://gridshib.globus.org/ GridShib project] for further ideas and proposed solutions. Solutions such as VOMS [xxxxref] are addressing this with in the PKI arena.