(All sections must be completed) Cover Sheet for Proposals

Transcription

Cover Sheet for Proposals
(All sections must be completed)
JISC Capital Programme
Name of Capital Programme: e-Infrastructure
Programme Strand:
(Please tick ONE BOX ONLY, as appropriate)
e-Research Community Engagement & Support

Call I – Barriers to Take-Up
of e-Infrastructure Services

Call II – Support for Research:
Tools & Standards
e-Infrastructure Security
Call V – Virtual Organisation
Management Tools and
Services
9 a) Integration of Grid and
Shibboleth
a) Tools for the
establishment of VOs
b) Developing and
b) Services and UIs for
Applying n-tier Web Service
Architectures
management of VOs
c) Federation membership
c) Applying existing
Call III – Use Cases and
Service Usage Models
Knowledge Organisation
and Semantic Services
Call IV – Federated Tools
and Services
models for VOs
Call VI – Sematically
Coordinating Resources and
Services Across Registries
a) Area A – integration of
Resources and Services from
Existing JISC Services
b) Area B – Metadata for
Services, Data, and Published
Literature
d) Delegated
virtual home for identity
solutions
Name of Lead Institution:

authorisation
University of Kent
Name of Proposed Project: Shib-Grid Integrated Authorization (Shintau)
Name(s) of Project Partner(s): Offers of support have been received from several international
projects and experts – see letters of support from: Internet 2, SWITCH, Globus, Manchester Uni
Full Contact Details for Primary Contact:
Name: David Chadwick
Position: Professor of Information Systems Security
Email:d.w.chadwick@kent.ac.uk
Address: Computing Laboratory, University of Kent, Canterbury, CT2 7NF
Tel: 01227 823221
Fax: 01227 762 811
Length of Project:
25 months
Project Start Date:
1 March 2007
Project End Date:
Total Funding Requested from JISC:
31 March 2009
£183,012
Funding Broken Down over Financial Years (April - March):
Apr06 – Mar07
£2,705
Total Institutional Contributions:
Apr07 – Mar08
£21,057
Apr08 – Mar09
£159,250
£45,753 plus international experts
1
Percentage Contributions over the
Life of the Project:
NOTE. UK Partners Only
JISC
PARTNERS
80%
20%
Outline Project Description
Integration of grids and Shibboleth is being hampered because a users attributes are typically
held in different locations, under different identifiers, and there is no coherent way of collecting
them together and validating that they all belong to the same user so that they can be used for
authorization of the user’s request.
The first objective of this project is to work with the international community, primarily the
Internet2 consortium and the Globus Consortium, but including SWITCH, TERENA and others,
to develop the Shibboleth protocol specifications, based on SAMLv2 and other protocols, that
will allow a Shibboleth service provider (SP) to collect together a user’s attributes from multiple
authorities, whilst preserving the user’s privacy, so that the aggregated attributes can be used to
authorise the user’s request. This will significantly ease the integration of Shibboleth with grids.
However, the resulting attribute aggregation protocol will be of benefit to any Shibboleth
enabled SP be it a web service, a grid service, or a conventional Shibboleth SP etc.
The second objective is to build a Policy Information Point (the nAA-PIP) that will evaluate
the collected attributes (or credentials) according to the configured trust policy of the Service
Provider (SP) and will return the valid set of attributes to the SP’s Policy Enforcement Point
(PEP). The PEP can then pass the complete set of validated and aggregated attributes to a
conventional Policy Decision Point (PDP) for it to make access control decisions. The nAA-PIP
will be fully standards conformant, and will be called by the SP through either the standard web
services protocol that is being defined by the OGSA-Authz WG [8] or by a Java API that is
already implemented in Globus Toolkit and is also due to be published by the OGSA-Authz
WG.
The third objective is to implement the aggregation protocol within the nAA-PIP so that it is
capable of collecting the attributes itself from the multiple authorities, prior to validation.
The fourth objective is to build a pilot demonstrator for the National Grid Service that will
show how attributes from multiple AAs can be integrated together and used in authorisation
decision making at grid sites that use shibboleth IdPs.
The final objective is to release all the developed software as open source code through
NMI/OMII to the community at large, with a full set of specifications and documentation.
I have looked at the example FOI form at
Appendix A and included an FOI form in
the attached bid (Tick Box)
I have read the Circular and associated
Terms and Conditions of Grant at
Appendix B (Tick Box)
YES
NO
YES
NO
9
9
2
Shib-Grid Integrated Authorization (Shintau)
1. Introduction
1.1 The Shibboleth infrastructure works on the assumption that a user’s home institution will both
authenticate the user and provide the user’s attributes for authorisation. This assumption is valid in
Shibboleth’s primary application areas, for example, obtaining publications from Elsevier. The
user’s home institution (or identity provider – IdP) has a long term relationship with the user, and
with the Shibboleth service providers (SPs). The home institution stores the user’s long term
attributes in its central databases. These attributes include such things as: name, date of birth,
department, salary scale point, login id etc. and a selection of these, such as
eduPersonPrimaryAffiliation, can be made available to Shibboleth SPs for authorisation. The user’s
home institution typically does not store the user’s short term attributes that change on a day to day
basis1, as the administrative effort to maintain these would be prohibitively expensive. Nor does the
user’s home institution typically store authorisation attributes needed for access to the remote
resources of virtual organisations (VOs) and research groups etc. since it is not authoritative for
these.
1.2 Virtual organisations (VOs) are often much more dynamic and much shorter lived than a user’s
affiliation to his home institution. In fact, we are trying to move towards the situation where VOs
can be dynamically created and destroyed with a minimum of effort, and may last for less than a
day. The management of these VOs must be delegated to the people who are part of them. It is
inconceivable to think that a university’s central administration would be responsible for adding
attributes about a user’s VO memberships to its central databases on a daily basis. Consequently
tools such as VOMS [10] have been introduced which allow a VO manager to create his own
database and to record in there the attributes of the various VO members. Unfortunately, when
Grids and Shibboleth are attempted to be linked together we hit the problem that some attributes are
in the user’s home institution and some are in the VO database, and both are needed for
authorisation. SWITCH has already recognised this problem, as has the MAMS project in Australia
and GridShib in the USA. SWITCH is now working on a solution for adding Shibboleth attributes
into VOMS2. However, this includes only two attribute sources. SWITCH does not plan to add
support for more attribute sources within the time scale of their work in EGEE-II. The GridShib
solution is worse, and only uses attributes from the Shibboleth IdP (see section 1.7). However,
limiting the problem domain to just one or two attribute authorities is short term thinking and does
not provide a complete or general enough solution to the problem space. For example, medical grids
already need to consider attributes from other authorities, such as the General Medical Council
(GMC) which issues GP attributes to doctors. When asked by the author at the recent OGF18
Shibboleth Development BOF meeting in Washington when SWITCH would extend their model to
3 or more attribute authorities, they did not have an answer. But we need one now, and this project
proposes it.
1.3 The author and Nate Klingenstein from Internet 2 (amongst others) have been thinking about
this problem space for a year or more already. We want to enhance Shibboleth so that it is capable
of fully satisfying the authorisation requirements of grids and VOs, by being capable of accepting
attributes from multiple attribute authorities including the user’s IdP, VO management authority,
professional society, financial authority and any other relevant authority required by the SP, so that
integration with Grids will be much easier to accomplish, and much more flexible than now. The
author’s first proposed protocol for this is based on a profile of SAMLv2 and was published at the
2006 Wet-Ice conference [1]. This protocol, which is based on the SP interacting with various web
services and pulling the user’s attributes (see Figure 1), puts the user in full control of linking
1
We are not including application generated short term attributes in this discussion, such as time of login,
which are automatically created and deleted by applications during their normal operations.
2
Presentation given by Christoph Witzig at OGF meeting in Washington. See
http://grid.ncsa.uiuc.edu/events/ggf18-shib-bof/060911_witzig_GGF18.pdf
3
together his various attributes held by the various authorities, whilst retaining privacy protection for
the user, since no single authority on its own is able to link the different identities and attributes of
the user together. Since then the author has had discussions with Von Welch and others, and has a
revised model that includes greater privacy protection, so that the attribute authorities are not able to
collude between themselves to link the user’s attributes together. This is similar to Microsoft’s
CardSpace (formerly InfoCard) scheme [14].
1.4 Nate Klingenstein has also recently written a paper [12] that collects together all the various
models that have been proposed, and that can accommodate most conceivable configurations
including proxies and gateways. Many of these models are based on attribute push using redirects
via the user’s browser, see Figure 2.
1.5 In this project we propose to work with acknowledged international experts in this area in order
to agree upon a SAMLv2 profile, along with other supporting protocols as necessary, for collecting
attributes from multiple authorities that will be using Shibboleth developed by the Internet2
consortium. We will then build a new open source Policy Information Point (PIP), which we call
the nAA-PIP, which will be capable of receiving the different attribute assertions from the different
authorities and merging them all together, ready for passing to the PDP for authorisation decision
making. The nAA-PIP will have two standard interfaces for plugging into any web service and grid
environment, both based on the work of the OGF OGSA Authz working group. One interface will
be a Java API, the other, a protocol for carrying SAML attribute assertions.
1.6 It is not yet clear whether the SAMLv2 profile will be a push or pull protocol, or whether it will
specify both, one for pulling attributes, the other for pushing them. (A SAML profile is composed
of multiple protocols which themselves have bindings.) Both push and pull have their advantages
and disadvantages. Either way, the elegance of our proposal is that in both cases it does not need to
alter the integration or configuration of existing PDPs at the SP site. Existing PDPs such as
PERMIS [11] or XACML [9] can be used as is with their existing interfaces. But they will now be
given a richer set of user attributes, validated by the nAA-PIP, from which to make more effective
access control decisions. Furthermore, our proposal does not need to alter the integration work
being done at Manchester University in the SHEBANGS project, since SHEBANGS is primarily
concerned with enabling Shibboleth authentication for grids. Our work will complement that of
SHEBANGS by providing a Shibboleth multiple AA collection mechanism that will take over after
SHEBANGS authentication has finished and prior to PDP decision making taking place. However,
as noted in the FUSINGS proposal from Wallom and Pickles, standard Shibboleth mechanisms
cannot work in scenarios where the user’s web browser is not available. Therefore FUSINGS
proposes to build a multi-IdP collection client based on the protocols specified in this proposal, and
to insert this bag of credentials3 into a VOMS proxy certificate, for pushing to the nAA-PIP for
validation. FUSINGS therefore complements our proposal perfectly, and will implement the
protocols we define in WP1, and push the result to the nAA-PIP that we will build in WP2.
1.7 Note that our work is likely to replace the GridShib PIP module provided for Globus Toolkitv4
by the GridShib project, since this module has a number of limitations as described in [5]. In
particular it does not provide pseudonymous access, it is not scalable, and it only supports a single
attribute authority. Our new nAA-PIP will be a compatible direct replacement for the GridShib PIP
and will resolve all of its limitations (and more).
2. Outline Design
2.1 How will it work? Conceptually it will not be very different to how Shibboleth works today.
After user authentication, the user’s home IdP will return an identifier of the user (sometimes called
a handle) plus a URL/EPR to contact to pick up the user’s attributes/ credentials. In the pull model
this information is passed to the nAA-PIP and it performs the attribute/credential collection and
validation. In the push model, the SP contacts the URL/EPR and is returned the first set of
3
The difference between an attribute, an attribute assertion and a credential, is as follows: an attribute
assertion is an assertion made by some authority that a user has a particular attribute, whilst a credentials is an
attribute assertion digitally signed by the asserting authority.
4
attributes/credentials, optionally along with another URL/EPR to contact to get some more. After
collecting all the attributes/credentials together, this bag of credentials is pushed to the nAA-PIP for
validation. Figures 1 and 2 present schematic diagrams of the proposed architecture and message
flows for the pull and push models respectively. A hybrid is also possible (not shown) in which the
SP will accept the first assertion through push and retrieve additional information through pull. The
first protocol exchange that occurs in all cases is the Shibboleth authentication protocol exchange
between the user’s IdP and the SP’s PEP (which can be Apache, GT4, OMII web service etc).
2.2 The design and implementation of the authentication protocol is being carried out under the
Shebangs project (amongst others) and it can be extremely complex with many different entities
involved e.g. CTS, MyProxy, WAYF, onlineCA etc. and multiple message exchanges. We have
simplified this complex set of exchanges into a single arrow labelled Authn protocol in the figures,
since how the authentication occurs is largely immaterial to this project. This is not to minimise its
complexity, but rather to show that all we care about is the outcome rather than how it happens.
After authentication has finished, the SP is eventually given just two things: (i) the authenticated
identity or handle of the user, and (ii) the URL or End Point Reference (EPR) of the attribute
authority to contact for the user’s attributes. (Note in SAMLv2 the URL/EPR might be replaced by
a set of attributes, or a set of attributes plus a URL/EPR. We cannot say for definite which it will be
at this point in time.) What happens next depends upon what is returned and whether the SP will
work in push or pull mode. If only attributes are returned then the protocol exchange is finished and
these credentials are given to the nAA-PIP for validation.
2.3 If a URL/EPR is returned and the SP is working in pull mode, these are given to the new n-AA
PIP so that it knows who to contact (obtained from the URL/EPR) and which user ID to quote in
order to obtain the first set of user attributes held by the IdP. Note that this user ID can be a one
time handle or a permanent ID, it is immaterial to the model and the protocol which it is. Note also
that this information is already returned today in the existing Shibboleth protocol, so all we need to
ensure is that the PEP can pass this unaltered to the nAA-PIP. This feature has already been built
into the existing OGSA-Authz protocol by the author [13]. Once the nAA-PIP has the first
URL/EPR, the profile developed in this project will specify how the different IdPs are subsequently
contacted and the attributes collected. The net result will be a collection of attributes for the user
5
issued by different IdPs. The nAA-PIP will validate these and pass the valid ones back to the PEP.
Note that Liberty Alliance Web Service Framework Specifications (ID-WSF) defines standards for
much of this [16].
2.4 If a URL/EPR is returned and the SP is working in push mode, it will redirect the browser to
this URL/EPR for it to start the attribute collection process, according to the profile that will be
defined. The net result will be a set of attributes issued by different IdPs, returned to the SP that it
will forward to the nAA-PIP for validation. ID-WSF describes a framework for doing this with
wsf:Endpoint references.
2.5 Note that a feature of the protocol design will be that the IdPs do not need to know or care who
the requestor is i.e. whether it is the user or the nAA-PIP that is requesting the attributes from them.
All the IdPs need to know is that in either case the ultimate consumer of the attributes is the SP.
This is actually remarkably easily to achieve, by requiring each IdP to encrypt the user’s private
attributes so that only the SP can decrypt them, whilst returning the user’s public attributes in the
clear. If the SP/nAA-PIP is genuine it will have access to the decryption key, otherwise the private
attributes will remain locked. Theft of credentials by another user is prevented by including some
holder ID linking information inside the encrypted credential, such as the initial handle used at
authentication time. The precise details of this will be defined in this project.
2.6 The PEP will contact the nAA-PIP via one of two different interfaces. Both of these are
currently being specified by the OGF OGSA-Authz working group. The first is a Java PIP interface,
org.globus.wsrf.security.authorization.PIP, designed to be used by Java applications, and currently
supported by GT4. The second is a web services PIP protocol specification designed to be used by
any web service. The current version is based on SAML messages carried by WS-Trust [8]. (WSTrust is the protocol used by Microsoft’s CardSpace/InfoCard.) Both interfaces return essentially
the same thing, which is a set of XACML formatted subject attributes [9] ready for placing in an
XACML request context. Once the resource, environment and action attributes are added to the
XACML request context it can be passed to an existing PDP in order for an access control decision
to be made. We are already working closely with the OGSA-Authz working group to ensure that the
PIP protocol is completed in a timely manner ready to be implemented in this project.
6
2.7 The main innovative work in this project is the definition of SAML2 profile(s) and other
protocols that will allow the user or the SP or the nAA-PIP to collect the multiple attributes from
the multiple authorities, and the building of the nAA-PIP to parse and validate them according to
the SP’s policy, ready for the PDP to make the access control decisions with the validated attributes.
Note that in both the push and pull modes the user is ultimately responsible for enabling the
attribute aggregation to take place, by linking his IDs together in some way. In order to link his IDs
the user must contact all the IdPs, either dynamically during attribute collection (push mode) or as a
one-off prior to collection (pull mode). Without the user’s permission and explicit linking of IDs,
attribute aggregation cannot take place because the user is potentially known by different identities
in the different IdPs, and only the user knows what these different IDs are. The precise mechanism
to support the ID linking will be specified as part of this project, and may be transient or permanent,
and may use the user’s actual ID or a pseudonym. To this end we will work closely with the
Internet2 consortium, and other international experts, and we have letters of support from them
attached to this proposal.
2.8. Once the nAA-PIP has collected together or been given the various attribute assertions, they
will be validated according to its attribute aggregation policy (or trust rules), that are written by the
Service Provider. Examples of such trust/policy rules are: the SP trusts the GMC to issue GP
attributes, the IEEE to issue IEEE membership attributes, the user’s home IdP to issue
eduPersonPrimaryAffiliation attributes, and the VO Manager to issue VO membership and project
role attributes. Configured with the appropriate policy, the nAA-PIP will validate the various
attribute assertions that are returned and will return only the valid attributes to the PEP in the form
of XACML formatted attributes. The PEP can then subsequently call any PDP that supports the
XACML request/response protocol [15] in order for it to make an access control decision for this
user, based on the complete set of attributes obtained from the different authorities.
3. Aims and Objectives
3.1 The first objective of this project is to work with the international community, primarily the
Internet2 consortium and the Globus Consortium, but including SWITCH, TERENA and others, to
develop the Shibboleth protocol specifications, based on SAMLv2 and other protocols, that will
allow a Shibboleth service provider (SP) to collect together a user’s attributes from multiple
authorities, whilst preserving the user’s privacy, so that the aggregated attributes can be used to
authorise the user’s request. This will significantly ease the integration of Shibboleth with grids.
However, the resulting attribute aggregation protocol will be of benefit to any Shibboleth enabled
SP be it a web service, a grid service, or a conventional Shibboleth SP etc.
3.2 The second objective is to build a Policy Information Point (the nAA-PIP) that will evaluate the
collected attributes (or credentials) according to the configured trust policy of the Service Provider
(SP) and will return the valid set of attributes to the SP’s Policy Enforcement Point (PEP). The PEP
can then pass the complete set of validated and aggregated attributes to a conventional Policy
Decision Point (PDP) for it to make access control decisions. The nAA-PIP will be fully standards
conformant, and will be called by the SP through either the standard web services protocol that is
being defined by the OGSA-Authz WG [8] or by a Java API that is already implemented in Globus
Toolkit and is also due to be published by the OGSA-Authz WG.
3.3 The third objective is to implement the aggregation protocol within the nAA-PIP so that it is
capable of collecting the attributes itself from the multiple authorities, prior to validation.
3.4 The fourth objective is to build a pilot demonstrator for the National Grid Service that will show
how attributes from multiple AAs can be integrated together and used in authorisation decision
making at grid sites that use shibboleth IdPs.
3.5 The final objective is to release all the developed software as open source code through
NMI/OMII to the community at large, with a full set of specifications and documentation.
7
4. Work Packages
4.1 The primary functionality of the nAA-PIP already exists in PERMIS, and it is called the
Credential Validation Service (CVS) which is configurable with its own policy. The CVS in
PERMIS is capable of pulling multiple credentials (X.509 ACs) from multiple external LDAP
repositories. Consequently no significant changes will need to be made to the CVS conceptual
design. Rather incremental changes are needed, such as replacing the LDAP protocol with the
protocol defined in this proposal, replacing the identifiers of the IdPs from LDAP distinguished
names to URL/EPRs; and support for XML signatures, SAML assertions and credential encryption.
It is currently not known if either the pull and push profiles will be specified, or both. However, the
FUSINGS project is proposing to implement the push protocol in its front end. Consequently our
project plan is designed in an incremental fashion with the push version being produced first
followed by the pull version which builds upon it.
WP1. Work with Internet2 Consortium to define SAMLv2 profile(s)
This WP will form the core intellectual challenge of this project, and will specify the SAMLv2 profile
and other protocols that are needed for aggregating attributes from multiple IdPs. Whilst the effort in this
WP is relatively small from Kent, the timescale and total effort is much larger, due to the input by global
experts and the number of draft protocol versions that will need to be specified and reviewed before final
acceptance. Some international travel will also be required.
Task 1.1 Gather requirements from Grid and Shibboleth users internationally. This will be achieved by
creating a questionnaire and circulating it (possibly via TERENA) to all the European NRENS, and via
Intenet2 to US institutions.
Task 1.2. Specify push and/or pull profiles. Circulate for comment and review. Update and re-circulate
until a final version is agreed.
Effort: 2 man months (Kent). Est. 6 man months from International Community.
Deliverables
D1.1 The SAMLv2 profile as Internet2 best practice or OGF specifications
D1.2 A paper to an international conference describing the profiles to the research community.
Note. Both of the above are expected to have multiple authors from the international community
WP2. Modify the PERMIS CVS to accept pushed attribute assertions with different user IDs
Modify the PERMIS CVS to be able to aggregate and validate user attributes that have different
identities for the same holder, and that are optionally encrypted and in the format to be specified in the
new profile. Modify the PERMIS policy validation rules if necessary to accept new SOA identifiers, so
that the CVS is able to validate these attributes. Create a new type of attribute repository object that
accepts attribute assertions in the new format, and returns them in the existing internal PERMIS format,
using new credential parser, credential decipher and signature verifier objects. Create a new credential
parser object that can parse credentials in the new SAMLv2 format. Create a new credential decoder that
can decipher encrypted tokens. Create a new signature verifier object that can validate XML signatures.
Build a test driver. Document the new modules, thoroughly test them with the driver, integrate them with
PERMIS and then perform regression tests on the build. Build new regression tests for the new features
and add them to the PERMIS regression test suite.
Effort: 9 man months (Kent)
Deliverables
D2.1 The nAA-PIP that supports the push mode of attribute aggregation with optionally signed and
encrypted SAML assertions
WP3. Modify the nAA-PIP to pull attribute assertions using the new pull profile
Modify the repository object created in WP2 to encapsulate a “collector” object that talks the new
SAMLv2 pull profile and protocols to collect and store the attribute assertions issued by the various IdPs.
This may require the collector object to perform assertion decryption followed by ID mappings during
the protocol conversations. Document the new module, thoroughly test it, integrate it with PERMIS and
then perform regression tests on the build. Build new regression tests for the new features and add them
to the regression test suite. Note. This WP will require a new IdP that supports the new protocol to
8
respond to the requests from the CVS. If none is available we will need to build a test IdP as part of this
WP.
Effort: 4 man months
Deliverables
D3.1 The nAA-PIP that supports the pull mode of attribute aggregation.
WP4. Integrate with the Internet2 Shibboleth 2 Java SP implementation for Apache SP
The next version of the Internet 2 SP software is being written in Java. We will incorporate our collector
object from WP3 into this, and modify our mod_permis Apache module (developed under the JISC
funded SIPS project) to pick up the attributes from the collector object and push them to the backend
nAA-PIP developed in WP2.
Deliverables
D4.1 A modified mod_permis for Apache that picks up the collection of attributes and pushes them to
the backend PERMIS nAA-PIP and PDP.
WP5. Integrate with GT4
We will enhance Globus Toolkit to support both the push and pull models. The FUSINGS project from
Manchester (Wallom and Pickles) will build the proxy certificate with pushed VOMS assertions.
Alternatively the user’s submission can embed the URL of the first IdP (pull model). The nAA-PIP will
then extract this information from the request context and behave appropriately. (It might be possible in
a carefully crafted solution to support both pull and push simultaneously, if the proxy certificate contains
both embedded attributes and one or more URLs. This is part of the current OGSI-Authz protocol and
design [13]).
Deliverables
D5.1 An enhanced Globus Toolkit with a customizable nAA-PIP
WP6. Integrate with OMII
This will be the basis of a separate bid to OMII (UK) for funding if the current proposal is funded by
JISC.
WP7. Application demonstrator
Using an existing UK e-Science grid project we will work with them to demonstrate the effectiveness of
the nAA-PIP. The reason that the application demonstrator has not been selected today, is that very few
Grid projects that are currently funded will still be running in March 2009. However, we do not doubt
that there will be a suitable application demonstrator available in 2 years time, that we will be able to
recruit to this project. (A candidate is the follow on project to Manchester University’s PsyGrid which is
due to complete in October 2008). For this reason we are including a contingency cost of 4mm that we
will subcontract to a third party for them to use to pilot our software in their application during the last
months of this project.
Effort: 2 man months (Kent) 4 man months (Subcontractor)
Deliverables
D7.1 A working demonstration of the nAA-PIP in a current Grid project that will retrieve attributes from
at least 3 IdPs.
WP8. Dissemination
Build a project web site at the beginning of the project and add pointers to it from other web sites such as
PERMIS, Internet2 and GT. Publish working drafts of the profile on the site. Solicit input. Package the
final software for Open Source Release (BSD license) along with Globus Toolkit for release with the
NMI. Produce user friendly documentation, installation guides and tools.
Effort: 3 man months (Kent)
Deliverables
D8.1 The integrated software packaged with GT4, released as binaries and open source
D8.2. User, developer and administrator documentation for the package including information needed
for its support in a Shibboleth-enabled environment
9
D8.3 A paper for an international conference or journal publicizing the work
D8.4 Final report to JISC
.
Shintau Gantt Chart
Task
WP1 Define
Protocol
WP8 Dissemination
M1
M2
M3
M14
April 2007
M15 M16
M4
M5
M6
M7
M8
M9
M10
M11
M12
M13
April
2008
M17
M18
M19
M20
M21
M22
M23
M24
M25
WP2 Push nAA-PIP
WP3 Pull nAA-PIP
WP4 Apache
WP5 GT4
WP7 Demonstrator
WP8 Dissemination
April 2008
April 2009
5. Budget and Value for Money
Note that the following budget does not include the cost of the international experts, whose
expertise will be provided without charge to this project. Thus the actual cost will be higher and the
contribution from JISC will be lower than the figures presented below.
March 07
Apr 07– Mar
Apr 08– Mar
TOTAL £
08
09
Directly Incurred Staff at Kent
Total Staff (A)
Non-Staff at Kent
Travel
Consumables
Laptop & PC
Subcontracting (4mm+overheads)
Total Non-Staff (B)
Directly Incurred Total
(A+B=C)
Directly Allocated
0
91,379
91,379
4,000
750
2,000
750
2,000
4,750
30,000
2,750
6,000
1,500
2,000
30,000
39,500
2,000
4,750
94,129
130,879
Directly Allocated Total (D)
Indirect Costs (E)
1,029
352
13,366
8,206
22,700
52,233
37,095
60,791
Total Project Cost
Amount Requested from JISC
Institutional Contributions
3,381
2,705
676
26,322
21,058
5264
199,062
159,250
39,812
228,765
183,012
45,753
Percentage Contributions over
the life of the project
0
2,000
JISC
80 %
10
UK Partner
20 %
Total
100%
5.1 Kent are uniquely placed to perform this project for several reasons. Professor Chadwick has an
established reputation for providing leading edge security solutions, both conceptually through
research publications and materially through usable open source software products. Furthermore,
the existing PERMIS software already includes an open source standards conformant
implementation of an nAA-PIP, although it has some limitations and variances from the one being
proposed here. (It uses LDAP for pulling attributes rather than SAML; the attributes have to be
encoded as X.509 attribute certificates rather than SAML attribute assertions; it does not support
encrypted attributes; it can accept attributes from multiple providers but users have to be identified
by their globally unique LDAP distinguished names at each IdP.) The main innovation in this
project is to allow users to use different unrelated identities at each IdP. Due to PERMIS’s modular
construction, it is only an incremental task to build all the new features being proposed in this
project into the current product. As is our current practice with the PERMIS code, all the code will
be released as both open source code under the BSD license and ready to run binaries.
6. Risk Assessment
6.1 Reliance on other projects. I) We are reliant on the Internet2 consortium agreeing in a timely
manner to the SAMLv2 profile we define. This is only low risk, since we have a strong letter of support
from them, plus one of their staff members, Nate Klingenstein, has committed to participate in the work,
plus there is a large international momentum to solve the problem in a timely manner. The impact is
only small to medium, since we can start to implement the nAA-PIP before the protocol is finalised.
Contingency. We will implement the latest version of the profile that is available by the cut off date of
April 2008. We will migrate to the final version during the final year of the project. This is not so serious
since the protocol is only needed when we implement the pull mode in WP3 in month 19. The worst
case scenario would be that after the project is finished there are still some minor modifications to be
made to the software to make it conformant to the final protocol specification. II) We are reliant on the
Internet2 consortium implementing Shibboleth 2 SP in Java. This is already in development and is
unofficially scheduled for release in Spring 2007. The risk is therefore low as we do not need it until
September 2007. Failure to deliver is only low to medium impact because we can still do the GT4 and
OMII integrations without it. III) We are partially reliant on the OGF completing the specification of the
2nd generation OGSA AuthZ protocols. This is medium risk, but low impact. Contingency. As the PI is
joint chair of the OGSA AuthZ WG and editor of the specifications he can have some influence over the
production of the second generation AuthZ protocol specifications in a timely manner. If OGSA-Authz
do not specify the protocols in time, we have a fallback strategy of performing the integration and
demonstrator using the existing 1st generation Authz protocol or, for GT4, the existing Java interface,
both of which are already implemented and proven.
6.2 Beating the March 2009 Deadline. This is a hard deadline for JISC by which date all projects must
be finished. This is high risk due to its reliance on WP1 and external factors, and high impact since
money can be withheld from the project team. It is therefore essential that this risk is mitigated
successfully. Contingency. In order to offset this risk, Prof Chadwick and Nate Klingenstein have been
working on WP1 since October 2006, so that if/once the project is funded, WP1 will have been running
for 6 months. This should be a significant factor in helping to reduce this risk and may in fact mean that
we can finish WP1 early.
6.3 Project Management. This is the number one critical success factor in any project. Failures in
project management can lead to total project failures, so the impact is potentially very high. However
this is low risk to this project due to the track record of Prof Chadwick, who has successfully completed
over 25 IT R&D projects to date.
6.4 Staffing problems. Staff are always the second most important critical success factor in any project,
and the impact of staffing failures is potentially very high. In order to avoid staffing problems, we have
scheduled this project so that the bulk of the technical implementation work starts in month 14, which is
after the technical implementations have completed in the companion VPMan and nDoA proposals. This
means that, subject to the other projects being funded, we will have several highly skilled and
experienced staff who will be able to work on this project and whose learning curves will be minimal.
This means that the time to implement this proposal can be reduced from the plan by running more tasks
in parallel. If the other projects are not funded we would probably need to recruit at least one new staff
member for this project.
11
7. Impact and Sustainability
7.1. This project will have a major international impact, because R&D groups the world over who
are currently experimenting with Shibboleth and grids are hitting the problem identified in this
proposal. An internationally standardized solution is required, and this proposal suggests how one
can be arrived at. It has the support of major international players, notably Internet 2 and Globus
Consortium, and the offers of internationally recognized experts to help in the formation of the
solution. This project will serve to confirm to the world that the UK is a leading player in federation
technologies, and will contribute to the advancement of these technologies.
7.2. Long term sustainability is ensured in several ways. Firstly, the commitment of Internet2 and the
Globus Consortium to contribute to the project’s output, and the subsequent embedding of the software
solutions in their product lines, will facilitate its adoption and long term support. Secondly, all the
PERMIS software is open source under the BSD licence, and so is available unencumbered for anyone
to adapt, update, bug fix, and offer commercially. Furthermore PERMIS is being integrated into the
OMII-UK software release, and the latter has a long term commitment to the UK community to
commission the hardening, maintenance and support of software components that are useful and being
used by the UK e-Science community. We believe that the software outputs of this project will qualify
for such support. Finally, Kent will continue to provide support to integrators and to enhance PERMIS
with new features within the context of its ongoing and future R&D projects. The PERMIS web site lists
a number of these projects as well as new ideas for continuing R&D work in authorisation
infrastructures.
8. Key Personnel
8.1 Professor David Chadwick is the leader of the Information Systems Security Research Group
(ISSRG) at the University of Kent. He has written over 80 books, chapters, journal and conference
papers, mostly about security, and the latest of these can be downloaded from
http://www.cs.kent.ac.uk/people/staff/dwc8/pubs.html. He has been the principal investigator in over 25
research grants from a variety of sources including the EPSRC and the EC. He has participated in 5
previous Grid related JISC funded security projects including DyVOSE, DyCOM and FAME-PERMIS.
The results of these have been widely demonstrated and made available to the global community as open
source software under the BSD licence. Professor Chadwick was a member of the EPSRC e-Science
Security Taskforce, is still the BSI lead representative to ISO/ITU-T X.500 standards meetings which
includes X.509 PKIs and PMIs – the basic technologies used in Grid security. He is the editor of X.518
(1993), two Internet RFCs (2120 and 3876), the co-author of the GGF OGSA SAML Authorisation
profile [13], and numerous Internet and GGF draft documents. He is the co-chair of OGSA-AUTHZ
working group. He is therefore ideally suited to be an editor of the SAML2 profile proposed in this
proposal. As part of the EC PERMIS project he led the first group in the world to implement a policy
driven X.509 PMI. The resulting open source PERMIS software is now part of the public US NMI
Internet2/Grid software release and is integrated with Globus Toolkit, Shibboleth and Apache. It is the
only freely available open source X.509 based PMI toolkit in the world today.
8.2 Nate Klingenstein is a Technical Analyst with Internet2 and has been part of the Middleware
Initiative since 2001. During this time, he has worked on a wide variety of middleware and security
projects with international working groups and consortia. He has had deep experience covering
most themes in authentication, authorization, and security, including PKI, role-based access control,
federation, directories. He has worked with the Shibboleth project nearly since its inception,
directing the first U.K. Shibboleth install-fest in London, and is currently the lead for
documentation and support. He continues to assist on the architecture and packaging of Grouper
and Signet. His current research interests include formalization of federated identity theory and the
domain model, generalization of attribute aggregation and constrained delegation, tying grid
computing and other services to campus infrastructure, distribution and conservation of information,
and integration of PKI and federated identity. Nate’s services to this project will be provided free of
charge.
12
Appendix A
References
[1] David Chadwick. “Authorisation using Attributes from Multiple Authorities” in Proceedings of WET-ICE
2006, June 2006, Manchester, UK
[2] D.W.Chadwick, D.Mundy. "Policy Based Electronic Transmission of Prescriptions". Proc of Fourth IEEE
Int Workshop on Policies for Distributed Systems and Networks, Lake Como, Italy, 4-6 June 2003, p197-206
[3] Wensheng Xu, David Chadwick, Sassa Otenko. “Development of a Flexible PERMIS Authorisation
Module for Shibboleth and Apache Server”. Proceedings of 2nd EuroPKI Workshop, University of Kent, July
2005
[4] David W Chadwick, Sassa Otenko, Von Welch. “Using SAML to link the GLOBUS toolkit to the
PERMIS authorisation infrastructure”. Proceedings of Eighth Annual IFIP TC-6 TC-11 Conference on
Communications and Multimedia Security, Windermere, UK, 15-18 September 2004, pp251-261
[5] D.W.Chadwick, A. Novikov, A. Otenko.“GridShib and PERMIS Integration“. Campus-Wide Information
Systems. Vol 23, No 4. 2006. pp297-308 ISSN 1065-0741
[6] OASIS. “Assertions and Protocol for the OASIS Security Assertion Markup Language (SAML) V2.0”,
OASIS Standard, 15 March 2005
[7] LESC reference.
[8] David Chadwick, Linying Su. “Use of WS-Trust and SAML to access a CVS”. OGSA-Authz WG Draft
Standard. 12 April 2006.
[9] OASIS “eXtensible Access Control Markup Language (XACML) Version 2.0”
OASIS Standard, 1 Feb 2005
[10] Alfieri, R., Cecchini, R., Ciaschini, V., Dell'Agnello, L., Frohner, A., Lorentey, K., Spataro, F., From
gridmap-file to VOMS: managing authorization in a Grid environment, Future Generation Computer Systems.
Vol. 21, no. 4, pp. 549-558. Apr. 2005
[11] D.W.Chadwick, A. Otenko. “The PERMIS X.509 Role Based Privilege Management Infrastructure”,
Proc 7th ACM Symposium On Access Control Models And Technologies (SACMAT 2002), Monterey, USA,
June 2002. pp135-140.
[12] N.Klingenstein. “Attribute Aggregation and Federated Identity”. To be presented at SAINT 2007
[13] Von Welch, Rachana Ananthakrishnan, Frank Siebenlist, David Chadwick, Sam Meder, Laura Pearlman.
“Use of SAML for OGSI Authorization”, GFD.66. March 2006, Available from
http://www.ggf.org/documents/GFD.66.pdf
[14] Kim Cameron and Michael B. Jones. “Design Rationale behind the Identity Metasystem Architecture”
available from http://www.identityblog.com/wp-content/resources/design_rationale.pdf
[15] David W Chadwick, Linying Su, Romain Laborde. “Use of XACML Request Context to access a PDP”.
OGSA-Authz WG Draft Standard. 28 March 2006
[16] Liberty Alliance ID-WSF 2.0 Specifications. See
http://www.projectliberty.org/liberty/resource_center/specifications/liberty_alliance_id_wsf_2_0_specificatio
ns
13
Appendix B
FOI Withheld Information Form
We would like JISC to consider withholding the following sections or paragraphs from disclosure
should the contents of this proposal be requested under the Freedom of Information Act.
We acknowledge that the FOI Withheld Information Form is of indicative value only and that JISC
may nevertheless be obliged to disclose this information in accordance with the requirements of the
Act. We acknowledge that the final decision on disclosure rests with JISC.
Section / Paragraph No.
Relevant exemption from
disclosure under FOI
Justification
NONE
Please see http://www.ico.gov.uk for further information on the Freedom of Information Act and
the exemptions to disclosure it contains.
14
Appendix C
Interaction between VPMan, Shintau and nDoA
Technical
The main objective of VPMan is to integrate the VOMS user management and attribute assignment
function with the PERMIS policy based authorisation decision function. The main software objective of
Shintau is to develop a Policy Information Point (the nAA-PIP) that can aggregate and validate the
attributes assigned by multiple attribute authorities. The main objective of nDoA is to enable n-tier
delegation of authority between web services and/or people. All three projects complement each other as
described below.
VPMan and Shintau. The three demonstrators of VPMan will only collect attributes from a VOMS
server and use these to make authorisation decisions. The Shib, OMII, GT2 and GT4 demonstrator of
VPMan will use Shibboleth for authentication, and attributes from VOMS for authorisation, but still
wont use attributes from multiple authorities for authorisation. However, once the nAA-PIP from
Shintau is developed, this will be able to be seamlessly plugged into the VPMan infrastructure using
existing interfaces and allow PERMIS to make authorisation decisions based on attributes from VOMS
servers and from other attribute authorities such as Shibboleth IdPs, professional certifying authorities
such as the General Medical Council and learned societies such as the IEEE and the ACM.
VPMan and nDoA. Globus Toolkit already has a functioning n-tier delegation architecture based on
proxy certificates. This is limited in that it only delegates from a user to his job, nevertheless it is
sufficient for the Globus Toolkit demonstrator in VPMan. N-tier delegation of authority between users is
handled by the existing PERMIS DIS service piloted in the DyVOSE project. OMII currently does not
have an n-tier delegation capability. Its n-tier processing relies on the next tier trusting the previous tier
to have performed the correct checks on the user, and therefore the previous tier is trusted to do anything
on the next tier. The n-tier delegation of authority planned in nDoA will make a welcome addition to the
OMII infrastructure and provide a constrained delegation capability thus limiting the trust that the next
tier has to place in the preceding tier.
nDoA and Shintau. These two projects add orthogonal and complimentary capabilities to the VPMan
infrastructure. nDoA allows one service or person to delegate attributes to another service or person,
whilst Shintau allows a set of attributes for a person or service to be collected from different IdPs and
validated prior to access control decision making. They will not directly interact with each other unless
the policy of the nAA-PIP allows delegation of authority by its trusted IdPs. Note the PERMIS CVS
already allows this capability, as it was introduced in the DyVOSE project. When the IdPs delegation
policy is enhanced in nDoA, the validation mechanism in the nAA-PIP will also need enhancing, but this
has been planned for in the nDoA project. Note that when an IdP holds attributes that have been
delegated internally from one user to another (by nDoA, Signet, Grouper or any other delegation
capability) this will be transparent to Shintau if all the credentials are issued by the IdP in question, in
which case a knowledge of the delegation history prior to credential issuing is either hidden or not
relevant to the credential validation capability of Shintau. If one web service delegates to another web
service, and the nAA-PIP of the second web service then either pulls or is pushed the credentials of the
requestor (whether from one IdP or several), this delegation may or may not be relevant to the attribute
collection and validation undertaken by the nAA-PIP, depending upon its validation policy.
Financial and Managerial
All three projects are scheduled to run in parallel, with Shintau being longer than the other two. The
technical implementation for VPMan and nDoA is scheduled at the start of the projects with the piloting
towards the end. Shintau on the other hand is scheduled so that the start of the project (first year) is low
intensity long duration protocol design involving multiple iterations with technical staff around the globe.
The high intensity implementation work of Shintau starts after the implementation work of VPMan and
nDoA has completed, therefore the same technical staff at Kent can be used to implement Shintau once
15
they have finished implementing VPMan and nDoA. The benefits of this synergy have been built into
the Shintau project plan.
The piloting in VPMan and nDoA is being performed by NeSC. We were keenly aware of JISC’s tight
financial constraints when producing the budgets for these projects. Therefore we have described more
application scenarios in the nDoA proposal than we have costed for demonstrating. Thus if both projects
were to be funded, we would hope to be able to add an additional application domain to the nDoA
demonstrations.
The piloting in Shintau has not been determined yet, and no costs have been directly attributed to this in
this proposal. Therefore there cannot be any cost savings in the piloting phase of Shintau.
16
1 of 1
about:blank
To JISC,
The problem of integrating identity information from multiple
authorities was first identified in the Shibboleth project some four
years ago. It became quickly apparent that this situation uniquely
encountered in federated identity was extremely complex and difficult
to solve, and we placed the scenario on indefinite hold.
Since that time, the success of federated identity in deployment has
meant that attribute aggregation is no longer a theoretical need.
Fortunately, our understanding of how to solve it has evolved as well
through independent research and the efforts of standards bodies. We
now have several techniques to perform aggregation detailed in my
recent writings.
While there are many projects working on implementations of those
techniques, the University of Kent's proposal is unique in using one
general solution made possible by Liberty-style identity federation.
This is an excellent opportunity to begin development of the software
and deployment experience that will build a foundation for
incorporation of this technology in providers of the future. I fully
endorse David's proposal and will lend my support to the development of
the profile and the resulting software architecture and its
implementation, if his proposal is funded. For these reasons I am happy
for my brief CV to be included in his proposal.
Sincerely,
Nate Klingenstein.
19/11/2006 15:37
November 17, 2006
Dr. David Chadwick
Professor of Information Systems Security
The University of Kent
Canterbury, Kent, CT2 7NZ
Dear Dr. Chadwick:
I am very pleased to lend my support to your proposed project focused on
Attribute Aggregation strategies. This has the potential to fill an important
gap in the Shibboleth federated space as we move toward a more diverse set of
use cases, and will be particularly important in the higher education arena.
In particular, your emphasis on this project being a standards-based effort is
significant, and thus it could well become a widely deployed component of the
R&E infrastructure. In fact, your coupling of standards together to address this
critical issue of attribute aggregation seems inspired and could well become the
reference implementation for this requirement.
Thank you for your leadership in developing this project. I am certain that the
results of your work will be of interest to others in our community, and I look
forward to tracking your progress as you move forward. I support the funding of
this proposal, and I, and the Shibboleth team, look forward to collaborating
with you in realizing your goals.
We will, of course, provide forums for your work to be shared in the US and
provide other assistance to vet this work in the growing meritocracy of federated
identity. I hope to continue to have you as a partner in these interesting times.
Sincerely,
Ken Klingenstein
Director, Internet2 Middleware and Security
1000 Oakbrook Drive, Suite 300 • Ann Arbor, MI •48104 • (734) 913-4250
Manchester Computing
The University of Manchester
Oxford Road
Manchester M13 9PL
tel +44 161 306 6130
www.manchester.ac.uk
Professor David W. Chadwick
Information Systems Security
The Computing Laboratory
University of Kent
CANTERBURY
CT2 7NF
WTH/jd
8 November 2006
Dear David
Shintau Proposal
As Technical Director of the NGS and Principal Investigator of the SHEBANGS
project, I would like to express my whole-hearted support for your Shintau proposal.
Shintau addresses an important topic that will only become more pressing as
Shibboleth gets rolled out and is adopted in front ends to an increasing range of grid
services. In some of my research projects at Manchester, we are already anticipating
this problem, and would welcome a standards based solution that the whole
community adopts.
Yours sincerely
Stephen Pickles
Technical Director – National Grid Service
Tel: +44(0)161 275 5974
Stephen.pickles@manchester.ac.uk
Combining the strengths of UMIST and
The Victoria University of Manchester
SWITCH
Limmatquai 138
Postfach
CH-8021 Zürich
Telefon +41 44 268 15 15
Direktwahl +41 44 268 15 66
Fax +41 44 268 16 68
witzig@switch.ch
www.switch.ch
Zürich, November 17, 2006
To Whom It May Concern:
This letter is to express my support for the proposal “Shib-Grid Integrated Authorization” (shintau), as
described in the JISC Capital Programme Proposal, dated November 16, 2006, by Professor David
Chadwick. There is a need today for a SAML v2 profile that specifies how attributes from more than
one attribute authority can be aggregated. This proposal promises to address this issue and lead the
effort to develop this profile. Therefore it deserves to be supported.
Yours sincerely,
Christoph Witzig
Teamleader Middleware
SWITC H – Teleinf ormat ikdienste f ür Lehre und Forschung / Services de téléinformatique pour l’enseignement et la recherche
SWITC H / P.O. Box / CH-8021 Zür ich
www.switch.ch
Computing Laboratory
UNIVERSITY
Simon Thompson
OF KENT
Director
Tel:
Fax:
Email:
Web:
JISC e-Infrastructre bids
einfrastructure-bids@jisc.ac.uk
and Professor
of Logic and Computation
+44 1227 823820
+44 1227 762811
S.J.Thompson@kent.ac.uk
http://www.cs.kent.ac. uk!-s jt/
20 November 2006
Dear Sir or Madam,
Shintau Proposal
The University of Kent strongly supports the proposal Shib-Grid Integrated
Authorization from Professor Chadwick. This proposal will pull together leading
experts from Europe, the US and elsewhere in order to specify a standard profile for
aggregating attributes from multiple identity providers. We are pleased to support
Professor Chadwick in leading this work. At Kent we have already had success with
using Shibboleth in the early adopter's KUSP project, and we recognise the need for
using multiple attributes from multiple authorities in effective authorisation decision
making.
We are glad that Professor Chadwick's team in the Information Systems Security
Research Group will implement the standard profile after it has been defined, and we
will support the global distribution of the open source code from our department's
web server, once it has been implemented.
Yours faithfully,
~~lM
Prof Simon Thompson
Director, Computing Laboratory
.....
University of Kent
Computing
Canterbury,
Laboratory
Kent CT2 7NF. UK
Page1 of 1