Infrastructural Network Services
SPOCP - Project Definition, Proposal for
 

 

Document Status: Approved by the Steering Committee:xx-xx-2002

1 Introduction and Background

The accelerating trend towards system integration and self-service makes every student and employee a user in almost every one of our systems. The cost of maintaining separate authorisation information for each of these increase rapidly, and it is difficult to maintain the quality of the information.

The assignment for SPOCP is to develop/provide software for network based infrastructural services (middleware) for PKI-based authentication and authorisation. The purpose of SPOCP is to increase the efficiency and quality of maintaining and checking user identities (authentication) and of granting or refusing the authenticated user access to functions in our IT-systems (authorisation).

The result of the project shall be separate but interoperable software packages for authentication and authorisation services.

The authentication service shall offer authentication through both user name/passwords and x509-certificates. The authentication service software will probably be deployed as a local authentication service. Typically there will be exactly one authentication service per university. It is expected that the authentication service software developed in Uninett's FEIDE-project can be used directly or after a smaller adaptation. The plan in the FEIDE community is to set up a federation of authentication services and to include in FEIDE a federation directory, pointing the client to the relevant local authentication service based on information about where in the federation the user belongs.

SPOCP (from now on SPOCP - Simple POlicy Control Protocol - denotes the authorisation service) shall offer policy controlled authorisation advice to its clients, using information provided by

  • the user/client: authentication strength and an assumed role; and
  • directories or other information services (user and resource attributes such as roles and identity).

For SPOCP there is at least four deployment models:

  • ONE instance of the SPOCP software serves ONE application and may then for efficiency or security reasons be very tightly integrated with that application by whatever means that are available.
  • SPOCP serves a common application that is configured centrally but deployed locally, together with an instance of SPOCP.
  • SPOCP uses a general role database for a university and serves several smaller web applications at that university.
  • One instance of SPOCP provides authorisation advice to an application that has users in different universities. (The policy server uses authorisation information provided by different universities.)

The project is a cooperative effort between five swedish universities (Karolinska Institutet, Lunds Universitet, Stockholms Universitet, Umeå Universitet, and Uppsala Universitet) and Uninett, the norwegian research network. The project is financed by the partners and by Sunet, the swedish research network, and NyA, the project developing the new swedish system for admittance to higher education.

2. Project description

The development shall be carried out in construction packages. The main items in the scope of the project shall be these packages with two defined packages: A Minimal Package and an Administration package. The Steering Committee shall identify additional optional construction packages and shall assign priorities to the optional construction packages. The project shall deliver as many of these items as possible within the allocated resources.

A first version of the software shall be released 12 months after the start of the project.

2.1 In Scope

The following items are within the scope of the project:

  1. The possibly required adaption of FEIDE to be the provided Authentication Service software.
  2. A Minimal Construction Package consisting of a Policy Engine with minimal ABC-parts (administration, client and backend):
    A - flat file format for policy rules
    B - LDAP, flat file and time-constraint backends and with
    C - client (query) interfaces and protocol.
  3. An A Package
  4. Optional construction packages as decided by the Steering Committee such as OS Package for other platforms than the development platform which is Linux
  5. A model for maintenance of the software.

2.2 Out of Scope

The scope does not include the design of the information services providing the policy server with information about resources and persons. The task of developing such services is not trivial and must not be underestimated.

Most universities that have an enterprise directory, with students and personnel, can communicate with the directory using LDAP. The LDAP backend shall be provided in the Minimal Package.

2.3 Deliverables

The following deliverables are identified:

  1. Authentication Package - The Authentication Service Software
  2. Initial (I) Package - The Policy Engine with initial C and B components
  3. Minimal (M) Package - The I Package plus components necessary for the M Package to constitute an authorisation service software package
  4. Administration (A) Package (perhaps split in a mandatory and an optional package)
  5. OS Package - optional
  6. A suggestion for maintenance of the software

Deliverables for optional packages decided by the Steering Committee will be added to this list. The I Package deliverable is a milestone in that process. After that the decision shall be taken about the optional packages.

The I Package shall be delivered 2002-xx-vv

2.4 Estimated Duration

The project started the 14th of May 2002, with a design meeting, and is planned to end on May 31 2003.

2.5 Estimated Costs

The total estimated cost is 1500 KSEK.

2.6 Termination Criteria

The project shall be terminated when all deliverables are produced or the allocated resources are used.

2.7 Project change

Changes of the project definition is decided by the Steering Committee, and shall be documented in additions to this document.

Changes are done after requests from some member of the project organisation. The request shall be submitted to the Steering Commitee. The reason for the proposed change and its consequencies for the scope, budget and schedule shall be described.

2.8 External Dependencies

For deliverable #1, the project is dependent on the authentication software produced by the FEIDE project.

For deliverable #2, the package is affected by the authorisation requirements of NyA.

3 Project Organisation

The project is organised after the model
http://www.umu.se/it/umu_internt/ithandbok/projekt/org.html,
with the modifications listed below:

The Steering Committee has the added responsibility of assigning the task and thus also being the Project Sponsor. Members:

  • Olof Eggestig, Uppsala Universitet
  • Kjell Gullberg, Stockholms Universitet
  • Hans Nordlöf, Karolinska Institutet
  • Jon Strömme, Uninett
  • Arne Sundström, Lunds Universitet.

Project Manager: Torbjörn Wiberg, Umeå Universitet. The project is formally a project at Umeå Universitet.

Project Team: A Design Team and a Construction Team.

  • Design Team: Set up by the Project Manager. Each partner may in addition assign one member of the design team
  • Construction Team: It is set up by the Project Manager and consists of personnel contributing to the construction. The members of the Steering Committee are responsible for providing personnel to the construction team.
    Chief constructor: Roland Hedberg, Umeå Universitet. 

The cooperation with NyA project is based on the expectation and ambition that SPOCP can be used as the Authorisation component of NyA. There is however no requirement document for that component.

4 Reports

The Steering Committee is responsible for reports to their own organisations. The Project Manager is together with the Chief Constructor responsible for informing about the project and the software. Information will be given in at least the following communities: SUHF, HITS, Unitcf, Sunet, Nordunet, Trefpunkt, Susek, Gnomis, TF-AACE, Terena, Eunis, The Commission, Internet2.

The reports shall be given with three perspectives: the use in an application; a general network service; the methods and the technique.

The progress and results of the project is continuously documented on the web. Minutes from the Steering Committee are in Swedish, most other documents will be in English.

5 Risks

It is a risk for the goodwill of the project that there is no requirement document for the authorisation component of NyA.

The success of the project from a the point of view of an individual university depends on the interoperability with and quality of information in existing directories or databases of personnel. Probably, the current directory in many universities dont have the infomation structure and the quality needed. The routines for maintenance of directories may also have to be revised. Included in this revision is to make sure that the authorisation to make changes to directories reflects the delegation of responsibilities to assign roles. SInce the task of doing these revisions is nontrivial they must not be underestimated. This constitutes another goodwill risk for the project.

6 Costs and Resources

The time spent on the different activities and deliverables of the project shall be reported.
[an error occurred while processing this directive]