|
Size: 34031
Comment:
|
Size: 12008
Comment:
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 1: | Line 1: |
| 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. | ~+ What is a VO? - towards a definition +~ |
| Line 3: | Line 3: |
| This work forms the output of the eSP-grid workpackages five and six (PKI and Shibboleth Evaluations). | ---- Contents |
| Line 5: | Line 6: |
| = Contents = 1. [#intro Introduction: how to use this document] 1. [#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] ; [#LoA Grids need good levels of assurance] ; [#trustminimum Trust must be kept to a minimum on grids] ; [#securityieinadeq Security levels in the 'information environment' are inadequate] 1. [#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] ; [#PKILoA Grids need good levels of assurance] ; [#PKItrustminimum Trust must be kept to a minimum on grids] ; [#PKIsecurityieinadeq Security levels in the 'information environment' are inadequate] 1. [#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] ; [#SHIBLoA Grids need good levels of assurance] ; [#SHIBtrustminimum Trust must be kept to a minimum on grids] ; [#SHIBsecurityieinadeq Security levels in the 'information environment' are inadequate] 1. [#conclusions Conclusions] [#ConcsDevolvedAuthn Devolved authentication] ; [#ConcsAuthZAttribMgmt Authorisation and attribute management] ; [#ConcsTrustworthiness Trustworthiness and security] ; [#ConcsScalability Scalability] ; [#ConcsUsabilityCerts The usability of client certificates] ; [#ConcsSummary Summary] |
[#General General Expectations of a VO] [#1stPrinc First principles] [#Userperspec What is a VO from a user's perspective?] [#ServicePerspec What is a VO from a service developer's (or owner's) perspective?] [#RPsPerspec What is a VO from a resource provider's perspective?] [#ResVirtAbs Where resource virtualization is not present] [#ResVirtExists In the future, where resource virtualization exists] [#Respons Responsibilities diagram] [#Adef A definition?] [#GenNotes General notes and justifications] [#Definition First attempt at a definition] ---- [[Anchor(General)]] = General Expectations of a VO = [[Anchor(1stPrinc)]] == First principles == 1. AuthZ is performed at the resource or service. It isn't the responsibility of the VO to do this (although this is ''usually'' the effective outcome). 1. The VO houses and maintains attributes about users. These are given, on demand or 'up front', to the resource/service where the access decision is made. 1. AuthN is not normally performed at the VOs (this would arguably make them "O's"). 1. Groups of resources are not VOs. They might be "grids" or they may have another collective name. (e.g. a campus grid is not a VO: it is a set of resources used by a sub-set of people on and off the campus. The set of users (and other entities) may be a VO. 1. In the examples that follow, the term grid or grids denote groups of resources that are typically collaborating in some way. Typically, they would share the same middleware or key protocols. However, a single resource could theoretically belong to many grids. [[Anchor(Userperspec)]] == What is a VO from a user's perspective? == An (end) user (i.e. someone who does not run a service or own a grid node) should know (or find out) that for him to use a particular grid service, or collection of services, he must join a particular VO. For example, a biologist wants to run her data through the grid-based extinction-rate algorithm service. She finds out that this is provided by computer scientists working at the International Ecological Society. She joins the IES. When she attempts to use the Extinction Rate Grid Application, the underlying service finds out that she is a member of the IES and allows her to proceed. [[Anchor(ServicePerspec)]] == What is a VO from a service developer's (or owner's) perspective? == A service may be provided and maintained within a grid by someone who decides to (or is mandated to) serve users within a particular community. The VO represents that 'community'. For example, a developer has been funded by the IES to provide a service for all authenticated members of higher education instituations throughout the world as well as all members of the IES. The service developer is partly responsible for ensuring that the service cannot be used by people outside these communities. [[Anchor(RPsPerspec)]] == What is a VO from a resource provider's perspective? == A resource provider may own machines upon which grid services are run. The resource provider may have a personal preference (or one which comes from his organisation) as to which services are run on his resource. For example, the resource provider may wish to exclude all biological services in favour of providing resource for text-mining services. Therefore, he does not have to worry about biological VOs. Where the resource provider allows services, he may wish to account for the use of his resource. He could do this in two ways: 1. Count the cycles used by particular services or applications and bill the owners/maintainers of those services/apps (and leave them to charge their users if they wish to do so). 1. Identify every user and bill them directly for cycles used. 1. (As a combination of the above), identify every user, look them up in the VOs to exclude the VOs to which he wishes to provide his resource free of charge. Bill the appropriate users. (Clearly #1 in the above list is the easiest, logically, but mechanisms need to exist to enable this scenario). Those resource providers who are not deliberately joining a diverse grid may wish to restrict the use of their resources to only some services and only some VOs. In this case, the resource provider has the same concerns and * restricts the services and/or * restricts the VOs that can use the resource. [[Anchor(ResVirtAbs)]] === Where resource virtualization is not present === In grids where the end user is fully aware of using a particular grid node, then the node owner may be considered to have a similar interest to that of the service developer in the above examples. The node owner is directly concerned with users and what they do on her machine. [[Anchor(ResVirtExists)]] === In the future, where resource virtualization exists === End users will not have a direct relationship with resource owners. AuthN, AuthZ (access control) and accounting will ''have'' to be performed at either the application or service levels (whichever is appropriate). Alternatively, resource brokers may have to exclude users in certain VOs from accessing certain resources. Resource owners may wish to bill service providers and/or application providers (which may be synonymous to VOs) for the CPU time when those services or applications are active at their resources. [[Anchor(Respons)]] == Responsibilities diagram == {{{ Architecture Level: Resource Service/application User Authentication AuthN of AuthN of user (may be AuthN'ed by service devolved, but proof service or needed) resource or 3rd party trusted by serv/resource |
| Line 17: | Line 94: |
| [[Anchor(intro)]] = Introduction: how to use this document = Following this introduction, this document is arranged into four 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]''. |
Authorization AuthZ of AuthZ of user AuthZ at service <*VO lookup*> service -- OR -- AuthZ of AuthZ at all users --------------------------------> every <*VO lookup*> --------------------------------> resource -- OR -- AuthZ devolved to AuthZ at res. broker res. broker |
| Line 21: | Line 105: |
| [[Anchor(contempassumpts)]] = Contemporary Assumptions = |
Accounting/ Bills -----> Bills [1,2] -------> Is billed [1] Billing service/app User by service/app. or VO or VO -- OR -- Bills user --------------------------------> Is billed by directly --------------------------------> (possibly many) resources [1] Optional: Some services will not bill users, as they may be funded directly (without accounting) by the VO. |
| Line 24: | Line 117: |
| [[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 large 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 from the use of unauthorised others outside their (grid) community. |
[2] Service/app may have to provide usage info to VO so that VO can bill users accurately. |
| Line 28: | Line 120: |
| [[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. |
VO possible 1. Provide info. to service/app for AuthZ decision. responsibilities 2. Provide info. to resource for AuthZ decision. 3. Provide info. to res. broker for AuthZ decision. 4. Hold a repository of usage statistics for individual users. 5. Hold a mapping of identifiers from IdPs (e.g. DNs) to VOs own user identifier. VO mandatory 1. Provide user info. to service/apps and/or resources responsibilities and/or resource brokers for AuthZ decisions. |
| Line 32: | Line 132: |
| [[Anchor(identtrustorg)]] === Identity is best managed by a very trustworthy organisation === The concept of authentication is often (somewhat erroneously) associated with the separate elements of identity establishment and subsequent on-line identity assertion. 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/which it was issued. 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 need 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(LoA)]] == Grids need good levels of assurance == When a request is made and supported by an assertion that 'This is user 1234' or 'This user has been authenticated and I am happy that they are who they appear to be', there is a natural ''confidence level'' associated with the assertion. That level of confidence may be informed by the fact that I know that Organisation A doesn't issue their accounts (e.g. usernames/passwords, digital certificates etc.) in a secure way or that the Organisation has never been known to revoke a user, even though people obviously leave and are sacked etc. Conversely, I may know that Organisation B has excellent procedures and that ''this'' user has a digital certificate, so I am very confident that she is who she says she is. This confidence comes from the nature of the electronic credential, and how it is used, as well as the procedures (security policies) of the issuing organisation (the Identity Provider). Thus, when an assertion is made, either by something like Security Assertion Markup Language (SAML) or the presenting of a digital certificate a ''level of assurance'' (LoA) can either be inferred or asserted as well. Different LoAs are commonly expressed as 'Minimum Level', 'Basic Level', 'Medium Level' or 'High Level'. These different expressions have become associated with different encryption standards, security practices and, especially, how the original identity of the user was established. The current UK e-Science Grid uses client digital certificates (PKI - Public Key Infrastructure) and is considered to be at 'Medium Level Assurance'. Many currently believe that this is the minimum LoA that could be applied for grid use. We argue that this is too simplistic and short-sighted (see the discussion on ''[#PKILoA PKI Levels of Assurance]'' below). [[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. |
}}} |
| Line 59: | Line 135: |
| [[Anchor(PKIvsassumpts)]] = How does PKI live up to these assumptions? = |
[[Anchor(Adef)]] = A definition? = |
| Line 62: | Line 138: |
| [[Anchor(PKImustscale)]] == (PKI) 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 (Public Key Infrastructure). 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 with the passing years are ''not'' being fixed, and this has great negative effects on the user experience. |
[[Anchor(GenNotes)]] == General notes and justifications == |
| Line 66: | Line 141: |
| [[Anchor(PKIidentitymanscalability)]] == (PKI) Identity management is a scalability bottleneck == PKI-based grids address the requirement of good identity management by authorising 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 too few of them. 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 legitimate users. |
Foster et al. (2001) described VOs as "A Virtual Organization is a collection of individuals and institutions that is defined according to a set of resource sharing rules".[A] This definition seems too narrow and possibly alien to the real world. The reasons for saying this are: * "institutions" clouds the issue. In the last few years, VOs have been thought of as most likely to be subsets of users from within institutions linking with other subsets of users at other institutions. Perhaps the definition would be better with the word institution absent altogether or included as "and/or institutions" if necessary. * "a set of resource sharing rules" is again too narrow. Users can belong to a VO (such as the International Ecological Society) and resources (or services) choose to be available to the VOs users. * the definition also implies that the VO owns the resources (or at least drives the access policies of the resources) which it may or may not in the real world examples that have arisen recently. Although citing the above Foster et al. definition, in 2004, the community developing the Virtual Organization Membership Service (VOMS) software discussed VOs in terms of users, rather than institutions or resources. [B] Alfieri et al. noted that "VOs generally share resources", but they clearly will not ''always'' share resources and certainly there will be VOs in existence that do not own any resources at all. Later in the same document, Alfieri et al. stress the concept of the VO is that "VOs administer users, grant them permissions and establish agreements with resource providers (RPs). RPs, in turn, enforce local authorization." This seems far closer to a realistic definition of a VO. Alfieri et al. state that "the owner of a resource (i.e. the RP) should be able to enforce local user authorization based on various user characteristics such as his membership in a VO, roles he can have or his identity. |
| Line 70: | Line 148: |
| 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 photograph) on it. The user will subsequently be issued a digital 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 OUs for which 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. | [A] I. Foster, C. Kesselman and S. Tuecke, The Anatomy of the Grid, Interna- tional Journal of High performance Computing Applications, 15, 3, 2001 |
| Line 72: | Line 151: |
| We conclude that identity management via PKI ''should'' work effectively, but only if the RA is an integral part of the home organisation (or at the absolute ideal, the group or department) of the end user. Further, the RA should therefore be in prime control over the revocation process. As neither of these is usually true, the PKI is fundamentally flawed, or at best very difficult to scale (as large numbers of RAs are needed). | [B] R. Alfieri, R. Cecchini, V. Ciaschini, F. Spataro, L. dell'Agnello, A. Frohner and K. Lörentey, From gridmap-file to VOMS: managing Authorization in a Grid environment, xxxxURLxxxx, April, 2004. |
| Line 74: | Line 153: |
| For the sake of brevity, the above two problems - that of the RA having to trust another 'identity provider' and that of no appropriate person(s) managing the revocation process - are hereby summarised as the '''association-revocation gap'''. | === Characteristics of a VO === The following are therefore characteristics of a VO, expressed in terms that attempt to avoid over-restriction or promoting concepts such as "usually" or "generally" too highly. VOs * represent groups of users which may cross administrative boundaries * should imply difinable membership in such groups in that users can join and leave * (with respect to grids) represent a community for which access to grid resources or services or applications may be granted or denied * may contain varying statuses of user and attributes about those users * are definable in themselves as lists of members * do not normally provide identity, but instead rely on externally trusted parties for identity establishment (authentication). |
| Line 76: | Line 162: |
| [[Anchor(PKIidenttrustorg)]] === (PKI) 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 them 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 (again, due to the 'association-revocation gap'), 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' (or link) to the chain of trust is rarely, if ever, acknowledged. (This concept is very important, but difficult to express concisely. For more information, see Mark Norman's presentation ''[http://www.nesc.ac.uk/action/esi/contribution.cfm?Title=622 The case for devolved authentication: over-centralised security doesn't work]'' (Powerpoint format), given at the National e-Science Centre in Edinburgh, 20 October 2005). The same presentation is to be found here: ''[http://users.ox.ac.uk/~markn/Presentations/JiscNeSCMiddwareBriefingOct05.pdf Devolved authentication (lower file size and in PDF)]''.) 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)]] == (PKI) 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(PKILoA)]] == (PKI) Grids need good levels of assurance == In future we anticipate that there will be much grid use that is operated in a Customer-Service (like) manner and basic level assurance may be acceptable for these uses. Nevertheless, there will be much activity that requires medium or high level assurance, as users are able to - at least in part - control the behaviour of machines and to exclude others, temporarily, from using those machines. Thus medium level assurance will still be a requirement for many users, but a mixed economy of users will probably exist where basic level will be adequate for the majority of users. A confusing side issue is the high degree of trust in the electronic nature of the credential (e.g. digital certificate). This can mask the importance of the security policies that were used to issue the credential: so much so, that many people will forget this important, 'bureacratic' consideration altogether. Within the 'access management community' in the UK, there is certainly an emphasis at present in trusting the electronic credential more than the issuing policy and provenance of that credential. Thus, a high degree of trust is given to a user presenting with a digital certificate, but a lower degree of trust is given to a user who is known to have authenticated via username and password with HTTPS. The electronic credential is relevant, but may be secondary in importance to the policy by which the credential is issued. For example, some CAs will issue digital certificates to people who only need a valid email address[*], whereby other institutions have very careful procedures for handing out their usernames and passwords. In this case the latter is more trustworthy and should be given a higher level of assurance (LoA). We also argue that the 'association-revocation gap' in current practices of issuing digital certificates (see ''[#PKIidentitymanscalability (PKI) Identity management is a scalability bottleneck]'', above) means that the LoA of many 'information environment' identity providers (IdPs) is as good, if not better than that of the Grid CA. This is mostly due to the lack of active revocation by the CA. [*] Some certificate issuers will place a value in a field within the certificate or have the certificate signed by a particular root certificate that will indicate (in some way) 'Minimum Level Assurance'. Nevertheless people and machines often place too much trust in such certificates. [[Anchor(PKItrustminimum)]] == (PKI) 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 usually based upon knowledge of identity. For example, a resource owner may consider that 'these 200 distinguished-name-holders are able to use this 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 memberships 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)]] == (PKI) 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 changing rapidly). 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)]] == (Shib) 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 (PKI) Identity management is a scalability bottleneck]'' 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 the "association" part within the 'association-revocation gap' concept that was mentioned earlier. This is (conveniently) not generally recognised. However, who issued that user's university card? It was a trusted devolved third party. [[Anchor(SHIBidentitymanscalability)]] == (Shib) 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)]] === (Shib) 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)]] == (Shib) 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 attribute management as the true bottleneck should be as expected. Using attribute authorities (AAs) and Shibboleth/SAML transport, attributes can 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 user's 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 AA`2`). These two possible mechanisms are illustrated below: [We need diagrams for these models!] === (Shib) 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 AA`2`. The AA thus queries AA`2` and sends the information back to the resource in the SAML exchange. (In this way, the VO AA`2` 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 she holds these attributes. Of course, the AA would also have to transmit the signed assertion from AA`2` to the resource.) The only difficulty with this model is that it is incumbent on the AA to know where is the appropriate AA`2`. This may be achieved by setting it as a user-editable attribute. === (Shib) Secondary query to AA2 === This is a possibly simpler mechanism whereby the resource has the IdP authenticate the user, and possibly supply some attributes, but the resource initiates a separate transaction to the VO AA`2` 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 AA`2` 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 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(SHIBLoA)]] == (Shib) Grids need good levels of assurance == We hope that the arguments expressed in ''[#PKILoA (PKI) Grids need good levels of assurance]'' above have fully addressed this issue. In short, if there is a great distance between the day-to-day identity management and revocation and the central security system the (apparent) LoA is misleading. A user who robbed his university's computer suite last week and has had all his university passes, cards and accounts revoked is very likely to still hold his grid digital certificate because that is managed nationally. In this case, the university's HTTPS username/password system may provide far more ''assurance'' than his digital certificate that takes a year to expire. Of course, in the scenario above, the villain's identity has not changed, so you could argue that there is nothing wrong with assuring a third party that he is 'Mr Smith'. However, there are many scenarios where the university could have found that he is an identity fraudster and removed his cards and accounts. The over-centralised grid security personnel may be the last to know. [[Anchor(SHIBtrustminimum)]] == (Shib) 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 (PKI) Identity is best managed by a very trustworthy organisation]'' 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)]] == (Shib) Security levels in the information environment are inadequate == See the above ''[#PKIsecurityieinadeq (PKI) Security levels in the information environment are inadequate]'' section as it is equally applicable here. [[Anchor(conclusions)]] = Conclusions = [[Anchor(ConcsDevolvedAuthn)]] == 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 malpractising user can be traced, successfully and quickly, 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). [[Anchor(ConcsAuthZAttribMgmt)]] == 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 only a subset case of the 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 (Shib) Attribute management is a scalability bottleneck]'' 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 ''[http://edg-wp2.web.cern.ch/edg-wp2/security/voms/voms.html VOMS]'' are addressing this within the PKI arena. [[Anchor(ConcsTrustworthiness)]] == Trustworthiness and security == We outlined the difficulties of the 'association-revocation gap' in various sections above, but especially in ''[#PKIidentitymanscalability (PKI) Identity management is a scalability bottleneck]'' and ''[#SHIBmustscale (Shib) Grids must scale]''. If resource owners or grid middleware experts accept the premise that ''many trustworthy individuals performing tasks that are within their capabilities'' is a more secure situation than ''few very trustworthy individuals performing tasks that they cannot carry out securely'', then Shibboleth can be proved easily to be an excellent architecture for a next generation grid. Furthermore, Shibboleth allows for IdPs and Resource Providers to belong to Federations with specific security rules. It could be possible that Federations include specific security policies for grids. Another possibility is that the [http://www.oasis-open.org/committees/security/ SAML] assertions that underpin Shibboleth can transmit a value of 'Level of Assurance' and/or 'Authentication Method' (e.g. password, kerberos, certificate etc.). We would prefer ''Level of Assurance'' to be used, and for this to remain separate from the ''Authentication Method''. LoA could then be used with grid security policies without the heavyweight need to establish new Federations. [[Anchor(ConcsScalability)]] == Scalability == Current grid security methods and policies - for example, those used within the UK e-Science Grid community - will not scale to encompass many more users. The current policies are geared towards each resource owner having an active and trusting relationship with each user (individually). This is clearly unscalable. A scalable solution necessarily involves devolved authentication, or at least the devolution of the management of user identities to local organisations. This is very difficult to achieve - although not impossible - using PKI and client certificates. It is easier to achieve via Shibboleth, as devolved authentication was a primary driver behind its design. Another 'model' of grid use that will grow in popularity is the Customer-Service model whereby a service provider takes on the responsibility of authenticating and authorising users. This could be direct or could again be devolved, using Shibboleth, for example. With this model, the service provider is the entity that is truly the grid 'user' but will run jobs on the grid on behalf of the person or entity making the request. This model is likely to be the most frequently employed by 'users' and would usually break the [http://www.dcoce.ox.ac.uk/glossary/index.xml.ID=CPS Certification Practices Statement] (issuing policy) associated with client-certificate PKI, but does not necessarily break the use of the technology. [[Anchor(ConcsUsabilityCerts)]] == The usability of client certificates == There appears to be a tension between the belief that client certificates are too difficult for 'normal' end users and the need for high security. We hope that, in our clear arguments above, we have called into question the high security of client certificate PKI. The [http://www.dcoce.ox.ac.uk DCOCE project] found that digital certificates ''should'' not be too difficult for such users to employ successfully, but that currently they do pose difficulties. There are many small usability issues, each of which appears trivial for manufacturers and service providers to solve, but yet these issues remain, and their cumulative effect is of severe usability difficulties. Shibboleth would allow for the use of certificates as well as more user-friendly modes of authentication, such as https-based username/password authentication systems employed by a large number of organisations at present. This 'mixed economy' may provide the flexibility needed by the grid community. [[Anchor(ConcsSummary)]] == Summary == Shibboleth appears to provide a solution to the issues of scalability and of managing the large amount of identity information that is necessary. PKI could provide this solution in some forms, but it would require the policies that accompany PKI to be changed to devolve the identity management to people and bodies that are able to properly undertake this task. Whereas this ''can'' be achieved (as the [http://www.dcoce.ox.ac.uk DCOCE project] established), it should be far easier to integrate grid access management with that of the information environment community - i.e. using Shibboleth - and to concentrate efforts on security policies and Levels of Assurance. Thus, in practical terms, Shibboleth may be the best way of achieving grid access scalability and the high strength of the security and encryption that PKI provides can be used where it fits the purpose. Furthermore, it may be beneficial to allow many users who do not require 'deep' or 'technical' access to grid resources - but who nevertheless need to benefit from the grid - to avoid having to use client digital certificates. Shibboleth should provide an excellent mechanism to facilitate the use of many electronic identity/authentication credentials from username/password to digital certificates. |
[[Anchor(Definition)]] == First attempt at a definition == A VO is definable as a list of identified users that represents a real-world group of people that have a clear membership. The VO is not usually the primary point for the establishment or assertion of identity and may be relied upon by grid resources, services and applications to provide information for authorisation decisions. At its simplest a VO contains a list of members and their unique identifiers. At its most complex a VO may contain different status levels of members and many attributes about the members as well as accounting information regarding members' use of grid resources, services or applications. |
What is a VO? - towards a definition
Contents
[#General General Expectations of a VO]
[#1stPrinc First principles]
[#Userperspec What is a VO from a user's perspective?]
[#ServicePerspec What is a VO from a service developer's (or owner's) perspective?]
[#RPsPerspec What is a VO from a resource provider's perspective?]
[#ResVirtAbs Where resource virtualization is not present]
[#ResVirtExists In the future, where resource virtualization exists]
[#Respons Responsibilities diagram]
[#Adef A definition?]
[#GenNotes General notes and justifications] [#Definition First attempt at a definition]
General Expectations of a VO
First principles
AuthZ is performed at the resource or service. It isn't the responsibility of the VO to do this (although this is usually the effective outcome).
- The VO houses and maintains attributes about users. These are given, on demand or 'up front', to the resource/service where the access decision is made.
- AuthN is not normally performed at the VOs (this would arguably make them "O's").
- Groups of resources are not VOs. They might be "grids" or they may have another collective name. (e.g. a campus grid is not a VO: it is a set of resources used by a sub-set of people on and off the campus. The set of users (and other entities) may be a VO.
- In the examples that follow, the term grid or grids denote groups of resources that are typically collaborating in some way. Typically, they would share the same middleware or key protocols. However, a single resource could theoretically belong to many grids.
What is a VO from a user's perspective?
An (end) user (i.e. someone who does not run a service or own a grid node) should know (or find out) that for him to use a particular grid service, or collection of services, he must join a particular VO.
- For example, a biologist wants to run her data through the grid-based extinction-rate algorithm service. She finds out that this is provided by computer scientists working at the International Ecological Society. She joins the IES. When she attempts to use the Extinction Rate Grid Application, the underlying service finds out that she is a member of the IES and allows her to proceed.
What is a VO from a service developer's (or owner's) perspective?
A service may be provided and maintained within a grid by someone who decides to (or is mandated to) serve users within a particular community. The VO represents that 'community'.
- For example, a developer has been funded by the IES to provide a service for all authenticated members of higher education instituations throughout the world as well as all members of the IES. The service developer is partly responsible for ensuring that the service cannot be used by people outside these communities.
What is a VO from a resource provider's perspective?
A resource provider may own machines upon which grid services are run. The resource provider may have a personal preference (or one which comes from his organisation) as to which services are run on his resource.
- For example, the resource provider may wish to exclude all biological services in favour of providing resource for text-mining services. Therefore, he does not have to worry about biological VOs.
Where the resource provider allows services, he may wish to account for the use of his resource. He could do this in two ways:
- Count the cycles used by particular services or applications and bill the owners/maintainers of those services/apps (and leave them to charge their users if they wish to do so).
- Identify every user and bill them directly for cycles used.
- (As a combination of the above), identify every user, look them up in the VOs to exclude the VOs to which he wishes to provide his resource free of charge. Bill the appropriate users. (Clearly #1 in the above list is the easiest, logically, but mechanisms need to exist to enable this scenario).
Those resource providers who are not deliberately joining a diverse grid may wish to restrict the use of their resources to only some services and only some VOs. In this case, the resource provider has the same concerns and
- restricts the services and/or
- restricts the VOs
that can use the resource.
Where resource virtualization is not present
In grids where the end user is fully aware of using a particular grid node, then the node owner may be considered to have a similar interest to that of the service developer in the above examples. The node owner is directly concerned with users and what they do on her machine.
In the future, where resource virtualization exists
End users will not have a direct relationship with resource owners. AuthN, AuthZ (access control) and accounting will have to be performed at either the application or service levels (whichever is appropriate). Alternatively, resource brokers may have to exclude users in certain VOs from accessing certain resources. Resource owners may wish to bill service providers and/or application providers (which may be synonymous to VOs) for the CPU time when those services or applications are active at their resources.
Responsibilities diagram
Architecture
Level: Resource Service/application User
Authentication AuthN of AuthN of user (may be AuthN'ed by
service devolved, but proof service or
needed) resource or
3rd party
trusted by
serv/resource
Authorization AuthZ of AuthZ of user AuthZ at
service <*VO lookup*> service
-- OR --
AuthZ of AuthZ at
all users --------------------------------> every
<*VO lookup*> --------------------------------> resource
-- OR --
AuthZ
devolved to AuthZ at
res. broker res. broker
Accounting/ Bills -----> Bills [1,2] -------> Is billed [1]
Billing service/app User by service/app.
or VO or VO
-- OR --
Bills user --------------------------------> Is billed by
directly --------------------------------> (possibly many)
resources
[1] Optional: Some services will not bill users, as they may be funded
directly (without accounting) by the VO.
[2] Service/app may have to provide usage info to VO so that VO can bill
users accurately.
VO possible 1. Provide info. to service/app for AuthZ decision.
responsibilities 2. Provide info. to resource for AuthZ decision.
3. Provide info. to res. broker for AuthZ decision.
4. Hold a repository of usage statistics for individual
users.
5. Hold a mapping of identifiers from IdPs (e.g. DNs) to
VOs own user identifier.
VO mandatory 1. Provide user info. to service/apps and/or resources
responsibilities and/or resource brokers for AuthZ decisions.
A definition?
General notes and justifications
Foster et al. (2001) described VOs as "A Virtual Organization is a collection of individuals and institutions that is defined according to a set of resource sharing rules".[A] This definition seems too narrow and possibly alien to the real world. The reasons for saying this are:
- "institutions" clouds the issue. In the last few years, VOs have been thought of as most likely to be subsets of users from within institutions linking with other subsets of users at other institutions. Perhaps the definition would be better with the word institution absent altogether or included as "and/or institutions" if necessary.
- "a set of resource sharing rules" is again too narrow. Users can belong to a VO (such as the International Ecological Society) and resources (or services) choose to be available to the VOs users.
- the definition also implies that the VO owns the resources (or at least drives the access policies of the resources) which it may or may not in the real world examples that have arisen recently.
Although citing the above Foster et al. definition, in 2004, the community developing the Virtual Organization Membership Service (VOMS) software discussed VOs in terms of users, rather than institutions or resources. [B] Alfieri et al. noted that "VOs generally share resources", but they clearly will not always share resources and certainly there will be VOs in existence that do not own any resources at all. Later in the same document, Alfieri et al. stress the concept of the VO is that "VOs administer users, grant them permissions and establish agreements with resource providers (RPs). RPs, in turn, enforce local authorization." This seems far closer to a realistic definition of a VO. Alfieri et al. state that "the owner of a resource (i.e. the RP) should be able to enforce local user authorization based on various user characteristics such as his membership in a VO, roles he can have or his identity.
[A] I. Foster, C. Kesselman and S. Tuecke, The Anatomy of the Grid, Interna- tional Journal of High performance Computing Applications, 15, 3, 2001
[B] R. Alfieri, R. Cecchini, V. Ciaschini, F. Spataro, L. dell'Agnello, A. Frohner and K. Lörentey, From gridmap-file to VOMS: managing Authorization in a Grid environment, xxxxURLxxxx, April, 2004.
Characteristics of a VO
The following are therefore characteristics of a VO, expressed in terms that attempt to avoid over-restriction or promoting concepts such as "usually" or "generally" too highly. VOs
- represent groups of users which may cross administrative boundaries
- should imply difinable membership in such groups in that users can join and leave
- (with respect to grids) represent a community for which access to grid resources or services or applications may be granted or denied
- may contain varying statuses of user and attributes about those users
- are definable in themselves as lists of members
- do not normally provide identity, but instead rely on externally trusted parties for identity establishment (authentication).
First attempt at a definition
A VO is definable as a list of identified users that represents a real-world group of people that have a clear membership. The VO is not usually the primary point for the establishment or assertion of identity and may be relied upon by grid resources, services and applications to provide information for authorisation decisions. At its simplest a VO contains a list of members and their unique identifiers. At its most complex a VO may contain different status levels of members and many attributes about the members as well as accounting information regarding members' use of grid resources, services or applications.