| Infrastructural
Network Services |
|
SPOCP, short for Simple Policy Control Project, is a cooperative project whose goal was to provide the partners with software for authentication and authorisation services. The partners are 5 Swedish universities (Karolinska Institutet, Lunds Universitet, Stockholms Universitet, Umeå Universitet and Uppsala Universitet) and Uninett, the Norwegian National Research Network. The project started June 1 2002 and should be finished by the May 31 2003. The steering committee decided that what ended May 31 was the first phase of the project. So this is the Final Report for SPOCP - Phase One. The task was initially formulated as to design and implement an Authentication Server and a Policy Engine for an Authorisation Server end. It was decided early to narrow down the focus and concentrate on the Authorisation Server. The Authorisation Policy is written in a Policy Language based on S-expressions. More information about the project can be found on http://www.umu.se/it/projupp/spocp This Final Report presents the results of SPOCP - Phase One and summarises the design and implementation status for components that we believe will be parts of the SPOCP Authorisation Server Package. In section three there are som brief comments on the status of the Open Source Organisation. In this area most of the work remains to be done. There remains things to do but SPOCP Phase One has reached its goal: Design and implement software for an Authorisation Server based on a Policy Engine, that evaluates if an authorisation request written in a Policy Language based on S-expressions should be permitted according to an Authorisation Policy written in the same language. Among the remaining things are one large set of components: Support tools for developing and managing a Policy. There are also some tasks around for example the Client/Server protocol and the server operations The project were dimensioned by allocating 1.5M Sek, including 100K Sek from each partner, for one year. The project has not used all its resources, partly because we concentrated on developing a stable policy engine before developing components based on it. Another reason is that we switched focus somewhat around christmas to establish better contacts with the rest of the AA Community and with some application areas. The purpose was to do some proof-of-concept work of mainly the policy language supported by backends in the form of boundary conditions. The result has been overwhelming and we are confident that our approach moves the authorisation area in an interesting direction. We have not yet detected any serious deficiencies. One uncertainty is whether the Policy Language is powerful enough for most applicatios and if you can manage to keep an intuitive feeling of what you have authorised with a particular policy. SPOCP has been deployed in two large projects: NyA, the new admission system for swedish higher education, and Ladok på Webb (LpW), the self service application for teachers and students - a part of the Student Record System for swedish higher education.
The design of the SPOCP Server Software can be split into three parts:
The two first parts are almost completed, the third remains- The implementation of SPOCP has had the implementation of the Policy Engine as the first priority. We consider the Policy Engine to be of product quality. Some things remain to be done in the second part. For the third part only som minor experiments have been carried out.
The tools to support the development and maintenance of an authorisation policy has been discussed at design meetings, but we have not reached far enough to do the design in Phase One. During the discussions we have reached consensus on the vision that we need three levels of management: A top level where the initial rule set in an authorisation policy is set up; An intermediate level where authorisation profiles for different typical uses of the applicationis set up; And a level where a particular user is assigned a profile. We see a need for management support at all the three levels. Perhaps the third level is best managed by assigning attributes in an LDAP-directory or database. On the intermediate level, one typical tool is matrix based. A tool for handling a matrix of resources and authorisation profiles, where the application administrator can introduce new profiles and configure a profile by marking which activities a user, assigned a certain profile, shall have authority to perform on a particular resource. We had hoped to be able to base our design on a more powerful model getting somewhat closer to the power of the policy language. The first thing that comes to mind is to add one dimension to the matrix by being able to assign values, perhaps even snippets of s-expressions, to the elements in the matrix. We have though not made any real efforts to test these ideas. One source of inspiration is the Firewall Builder - www.fw-builder.org. Does anybody know of others? The tools at the intermediate level are provided to support the application area specialist in managing authorities. An issue of particular importance is: How powerful a tool is it reasonable to expect a typical application area specialist to be able explore? Currently, our view is that we sall not expect that they know so much about the Policy Language.
We have chosen to describe the implementation status from different perspectives. The reason for that is that we want to emphasise that SPOCP is stable enough to be used in critical applications even if it still is under development. The chosen perspectives are:
There is an efficient and stable implementation of the Policy Engine. The facility to handle delegation is the least tested part of the code. The Policy Language is stable but we may well be extended if a particular need becomes apparent when we get more experience with real implementations. There is a difference between extensions that makes it possible to express rules more efficiently and rules that expands the set of well-formed sentences in the language. The first category does not change the semantics of the language and can be introduced just to make life easier for policy writers. Even more so if the Policy Engine can analyse the query against one rule instead of a set of rules. A change of the second category means that we have to prove that the Policy Engine still can do its analysis in the same way as before. There has to be strong arguments for such an expansion of the Policy Language before we are willing to discuss it. We have implemented all Boundary Conditions, giving access to external information sources, being requested. This is one area where the first contributions to the code could be seen. The Client/Server message structure is still changing, and we don't expect it to be stable until we have developed tools to support the development and management of a Policy. The Protocol for communicating the Client/Server messages will probably not be one protocol. We have specified several protocols and implemented variants of the SPOCP Server with the corresponding frontends. One protocol is a native SPOCP protocol, and two other "protocol" is ??? sockets. We expect that there will be additions to this list. When it comes to Robustness and Security this will need periodic special focus. Sofar we have ... Authentication of authorised clients, protected communication channel (TLS), ... We have implemented several general Frontends for different protocols. We have also made proof-of-concept implementations of Clients with APIs to be used by applications using SPOCP. We expect this area to be developed through contributions to the code. Another way of frontending is to modify existing applications to use SPOCP. We have done some implementations of this tyoe. For instance for OPENldap, Apache 1.x och 2.x. This area should also be developed as contributions to SPOCP or to the code of the front application. We have certainly discussed the Open Source Organisation and there is a license distributed with the software but we have no further results to report. We are aware of the fact that the applications that have commited to use SPOCP have a right to expect a pofessional maintenance of the software. During Phase Two, the software will be maintained by the development project.
| ||
| [an error occurred while processing this directive] |