Date: Fri, 29 Mar 2024 11:04:37 +0000 (UTC) Message-ID: <461224348.7871.1711710277772@ip-10-10-7-29.ec2.internal> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_7870_2033593873.1711710277772" ------=_Part_7870_2033593873.1711710277772 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html
This summary report of the GridShib Project spans the time peri= od 2004-12-01 to 2005-12-06. Where possible, items in each category are lis= ted in chronological order.
Table of Contents
The NMI GridShib project is a collaboration between NCSA and the Univers= ity of Chicago. The goal of the project is to allow for interoperability be= tween the Globus Toolkit and the Shibboleth Identity Federation system. In = the first year of this project basic interoperability has been achieved in = that a deployment of the Globus Toolkit can query and receive attributes fr= om a Shibboleth service regarding a Grid user, and then make an access cont= rol decision based on those attributes. In the second year, we turn our att= ention to refining this capability as well as addressing higher-level manag= ement issues such as management of the federation of name spaces between th= e Grid and campus worlds and the management of the trust configuration/meta= data between the Grid and Shibboleth components.
As computational Grids have grown, there has been increasing interest in= leveraging existing site infrastructure to support Grid authentication and= authorization. For example, Shibboleth has been developed by the Internet2= community and increasingly deployed both in the U.S. and abroad as a mecha= nism for cross-site access control for web-based resources. Shibboleth util= izes OASIS SAML standards for authentication and attribute assertions to ac= hieve its purpose.
GridShib is a software product that allows for interoperability between = the Globus Toolkit and Shibboleth. The complete software package consists o= f two plugins, one for the Globus Toolkit (GT) and another for Shibboleth. = With both plugins installed and configured, a GT Grid Service Provider may = securely request user attributes from a Shibboleth Identity Provider.
GridShib for Globus Toolkit is a plugin for Globus Toolkit = ;4.0. The plugin implements a policy decision point (PDP) based on attribut= es obtained from a Shibboleth attribute authority. A policy information poi= nt (PIP) does the actual work of requesting attributes. The separation betw= een PIP and PDP allows the plugin to be used in flexible ways within the to= olkit?s authorization framework.
The Grid Client obtains and uses a proxy certificate to authenticate to =
a Grid Service Provider (SP). The Grid SP extracts the DN from the proxy ce=
rtificate and uses the DN as the value of the NameIdentifier
i=
n a SAML AttributeQuery
.
GridShib for Shibboleth is a name mapping plugin for a Shibbole= th 1.3 Identity Provider (!IdP). The plugin allows the attribute autho= rity to map the DN of the user?s X.509 proxy certificate to a local princip= al name. Upon receiving an attribute query, the Shibboleth attribute author= ity maps the DN and utilizes the resulting principal name to resolve attrib= utes.
The name mapping is a memory-bound collection of name-value pairs. The n= ame (key) is a canonicalized DN that conforms to RFC 2253. The value i= s the local principal name.
The collection is initialized when the !IdP starts up. The current imple= mentation of the name mapping construct is file-based, that is, the name-va= lue pairs are read from an ordinary text file. This text file is similar to= the grid-mapfile used by Globus Toolkit.
The GridShib Attribute Exchange Profile is an extension of the Shibbolet= h Attribute Exchange Profile. The primary difference is the use of X.500 di= stinguished names (DNs) to identify principals.
The GridShib Attribute Exchange Profile is designed for a standalone att= ribute requester, that is, an attribute requester that does not participate= in a Shibboleth browser profile. As a result, the Grid SP does not have ac= cess to an opaque, transient handle typically issued by the !IdP on the fro= nt end of the browser profile. In lieu of a handle, the Grid SP uses the DN= obtained from the client?s proxy certificate.
Our use case involves a Grid Client that already possesses an X.509 end-= entity certificate (EEC). As is often the case in grid-based scenarios, the= established user uses this EEC to generate a proxy certificate as part of = single sign-on. The proxy certificate is then used to authenticate to Grid = SPs as part of the act of requesting service.
Beta software that implements the GridShib Attribute Exchange Profile may = be downloaded from the GridShib web site. A technical overview of the= GridShib Attribute Excha= nge Profile is also available.
As the Globus Toolkit (GT) is used by many different projects and by man= y different Grid communities, it is clear that GT cannot mandate the use of= particular technologies and mechanisms. Specifically in the area of attrib= utes and authorization policies, the toolkit has to be flexible enough to a= ccommodate locally preferred assertion formats and usage patterns. The Globus Toolkit Authorization Framework= is designed to handle these different mechanisms in a consistent manne= r and to combine authorization decisions from many different sources to yie= ld a single access decision for each invocation request.
The currently shipping GT 4.0 implementation includes a simplified = version of the described attribute collection and authorization framework, = but does not fully support attribute-based authorization and has no support= for fine-grained delegation of rights. It includes support for proxy certi= ficate delegation, call-out support to SAML 1.1-compliant authorizatio= n services, grid-mapfile authorization, and an XACML evaluator.
Enhancements to support Shibboleth and SAML attribute assertions have be= en added as part of the GridShib effort, and are part of the GridShib beta = release.
The full-featured authorization framework is under active development, h= as produced a number of prototypes, and will ship with our next major relea= se GT 4.2.
Almost completed development allows the Grid SP to use an embedded SAML =
AuthenticationStatement
as the value of the NameIdentifi=
er
in a SAML AttributeQuery
.
Also almost complete is the ability for the Grid SP to select from multi= ple !IdP endpoints and credentials from a configured SAML2 metadata instanc= e.
At the architectural level, the project has identified a number of chall= enges that lie before us in regards to managing different namespaces. These= challenges are described in more detail in the subsequent project plan as = well as our most recent publication to the 5ht Annual PKI workshop, but bri= efly how does one establish that a user's identity at a University should b= e linked to their Grid identity. We currently have manual administration to= solve this problem, but are concerned with scaling issues with this simple= approach.
The following limitations of the current beta software implementation ha= ve been identified:
The fact that the DN-principal name pairs are read from a file is a majo= r concern. Even if we were to provide administrative tools to manage the na= me mapping files, the administrative overhead associated with this maintena= nce would be prohibitive. Clearly, this overhead must be eliminated or at l= east reduced.
In step 1 of the = GridShib Attribute Exchange Profile, we assume that the Grid Client som= ehow includes the !IdP providerId in the request. Unfortunately, the curren= t implementation of the software does not satisfy this condition. Instead t= he providerId is configured into the Grid SP, which essentially forces both= the !IdP and the Grid SP to reside in the same security domain.
Trust in a GridShib deployment is based on a bilateral arrangement betwe= en the !IdP and the Grid SP. By virtue of the fact that the two entities ex= change and consume each other?s metadata, a trust relationship is establish= ed. The problem is that n entities give rise to O(n
2 ) bilateral relationships, which of course does not scale.
In this section we discuss our plans for work in the forthcoming year fo= r enabling the seamless integration of Shibboleth/SAML and Grid Security/X.= 509. We expect there is more here then we will be able to accomplish in the= remaining year, so we list these in order of priority. Many of these plans= are in collaboration with the MyProxy project, an online credential manage= ment system developed at NCSA. These plans result from discussions with the= MyProxy project management.
The file-based name mapping system will be augmented with a database imp= lementation. This will not solve the maintenance problem, but it will make = it easier to provide administrative tools. A database implementation will a= lso facilitate load-balancing of IdPs (an ongoing issue in the Shibboleth P= roject).
One approach to the !IdP discovery problem is to include the !IdP provid= erId into the proxy certificate itself. Thus we are considering a modificat= ion to MyProxy that produces such certificates. For this to work, we assume= initially that MyProxy resides in the same security domain as the !IdP. Fu= rther work will attempt to relax this restriction.
Metadata is an important aspect of GridShib (or any federated identity m= anagement system, for that matter). Therefore the following enhancements ar= e being considered:
On the !IdP side, tools to produce and consume metadata are being design= ed. In particular, a tool to automatically produce !IdP metadata would be v= ery helpful. Similar tools for the Grid SP are needed.
Testing a browser-based Shibboleth deployment remains a challenge. Testi= ng GridShib on top of Shibboleth is even more difficult. To address this pr= oblem, we provide a command-line testing tool that tests both a Shibboleth = AA and a GridShib AA. A discriminating test strategy is being built around = this tool.
In the simplest case, access to a grid service is managed by providing a= ll users with an EEC from a recognized CA, mapping the names in these EECs = to another namespace local to the grid service, and using these local names= in access control lists. To broaden the availability of the grid service t= o more users, additional naming authorities can be recognized. In particula= r, we wish to enable use of established naming authorities, such as those l= ocal to a user's home organization, and authentication tokens other than X.= 509 EECs. However, we are constrained by the requirement that an EEC must b= e presented to the grid service, and that only attributes correlated with t= he presented name in that EEC can be marshaled.
This presents two problems. One is the exchange of an original authentic= ation token for a suitable EEC to be presented to the grid service. The oth= er is mapping the presented name in this EEC to the name in the original au= thentication token, called the principal name, so that attributes = bound to the principal name can be marshaled by the grid service. Because t= he principal namespace is not local to the grid service, and to support pse= udonymous access scenarios, we propose to collocate this presented name to = principal name mapping function with the authority for the principal namesp= ace and the attributes that are bound to principal names.
We see two distinct but equally important scenarios in which this name b= inding must take place. In the first scenario, which we discuss in this sec= tion, the client application communicates directly with the service. The se= cond scenario, which we discuss in the next section, involves a web portal = intermediary.
When the client application and service communicate directly, end-to-end= X.509 authentication is performed as part of the protocol (which is either= based on TLS or SOAP with message-level security based on WS-Security). Th= e difficulty in this case is binding the identifier in the user?s X.509 cre= dentials back to principal name so that attributes may be obtained.
In this case, we believe that the online CA functionality in MyProxy can= be used to solve this problem. The user obtains short-lived X.509 credenti= als initially by authenticating to the MyProxy online CA using their princi= pal name and password. The MyProxy CA would then issue the X.509 credential= , embedding into it the user?s principal name. The service would then extra= ct the principal name and use it when communicating back to the Shibboleth = Attribute Authority.
We note that this approach has a distinct advantage over the current imp= lementation in that the Shibboleth AA does not need to maintain a DN-to-pri= ncipal name mapping since the principal name is in the SAML query.
An open issue is the appropriate mechanism for embedding the principal n= ame into the X.509 certificate. Current options being considered are to use= the Subject Alternate Name or the Subject Information Access extension of = the certificate. One could also embed the principal name into the DN itself= , however we are concerned about placing requirements on the contents of th= e DN.
Another use case involves the client using a web browser to access a web= server, which in turn accesses Grid services on behalf of the client. This= use case is becoming more common as a means to allow for easy access to Gr= id services with a minimal footprint installation on the client system.
The primary observation in this use case is that the portal effectively =
functions as a "chasm" that must be bridged. Either X.509 or Shibboleth/SAM=
L can be used to authenticate to the portal, but there is no general method=
in use today to delegate authority to the portal. This is the so-called
We note that MyProxy has been used traditionally in the Grid community t=
o enable a portal to use a client?s username and password to obtain X.509 c=
redentials for the client. As in the previous section, these X.509 credenti=
als would have the principal name, taken from the NameIdentifier element in the SAML assertion, embedded in them. This would allow the Gr=
id service to query the SAML Attribute Authority in an identical manner as =
described previously.
The GridShib Web Site is our primary, outward-facing online res= ource. It contains valuable information about the project (including a brie= f introduction along with news, announcements, reports, and presentations) = as well as important links to resources such as software distributions, arc= hives, repositories, and various sources of end-user support. The web site = is hosted by Argonne National Laboratory (whereas it was previously hosted = by NCSA).
The GridShib Wiki includes four broad categories of web content= : Installation, Deployment, Community, and Team. Currently, the Team sectio= n of the wiki, used primarily for internal collaboration, is most developed= . We expect the other sections of the wiki to become more developed over ti= me as the project and the software gain traction. The wiki is hosted by The= Ohio State University.
All project source code is stored in the GridShib CVS Repository, which is anonymously available to all users. GridShib software is licens= ed under the terms of the Globus Toolkit 4.0 Public License, which its= elf is based on the Apache License, Version 2.0. The repository is hos= ted by Argonne National Laboratory.
gridshib-beta
mailing list gridshib-beta@globus.org<=
/li>
gridshib-beta
is an archived mailing list for end-user supp=
ort. Users can obtain support for installing, configuring, and deploying th=
e GridShib software. The mailing list is hosted by Argonne National Laborat=
ory.
Software bugs and enhancement requests (both internal and external) are = posted to GridShib Bugzilla, which is hosted by Argonne National L= aboratory.
GridShib Alpha was an initial, unreleased software component ea= rly in the project development cycle. This pre-release implementation under= went rigorous internal testing before it was repackaged and released to the= general public.
Pre-beta versions of the software are available on the GridShib Archiv= es page. However, users are encouraged to obtain the latest release of = the software from the GridShib Downloads page.
GridShib Beta is the reference implementation of the GridShib Beta Attribute Exchange Pr= ofile. GridShib Beta consists of two separate components: GridShib = for Globus Toolkit and GridShib for Shibboleth. The two compo= nents may be installed and tested separately, but both components are requi= red for complete functionality and interoperability.
GridShib Beta is available on the GridShib Downloads page. The lat= est source code is available for download from the GridShib CVS Repository.
The Shibboleth !IdP Tester is a standalone software tool that t= ests a previously installed and tested Shibboleth Identity Provider (!IdP).= A deployer can have confidence that an !IdP that passes this test will acc= ept the GridShib for Shibboleth plugin.
The Shibboleth !IdP Tester is available on the GridShib Downloads = page. The latest source code is available for download from the GridShib CVS Repository.
The following handbook (included in NMI-R7 and NMI-R8) was devel= oped in collaboration with the Shibboleth Project:
Significant contributions have been made to the Shibboleth Wiki:
GridShib project members also organized a Workshop at GGF 15 in Bos= ton entitled "Leveraging Site Infrastructure for Multi-Site Grids". This wo= rkshop had nine different project presentations, including a GridShib prese= ntation and demonstration, and was well attended by the GGF community.