|
|
 |
|
Content Introduction
and Summary This is the final report from the project: PKI-based Authentication and Authorisation initiated by HITS (Högskolans IT-säkerhetssamarbete) - The IT Security Cooperation in Swedish Higher Education. Its task has been to seek answers to two questions: Is it possible, for many of our systems, to use a common, network based, infrastructural Authorisation Service (supported by catalogues of persons, roles and resources)? What are in that case the realistic requirements for such a service? The project started in September 2001 and has now ended. To summarize the results: We are convinced that it is feasible to implement a general authorisation system as a network based, infrastructural Service. The Authorisation Service gives advice on whether access to a resource is to be given or not. It contains a Policy Engine which computes the advice based on policy expressions containing roles, resources and other environment information such as time-of-day, membership-of-a-group, authentication-strength. The design typically assumes the availability of an Enterprise Directory of students and personnel. The Enterprise Directory typically contains the role information needed for the authorisation. The system includes a Policy Database (and an interface for its administration) and possibly a Resource Dirctory describing the properties of available resources. The reason for the interest in these questions is the following observation: Our IT-systems are becoming more and more integrated and the concept of a user is widening to, in many cases, include all our students and/or personnel. It is becoming more and more unrealistic to manage users, accounts and access control within each application. This project has a twin, whose task it is to give strategic advice on to what extent the service whose requirements and architecture we are specifying could/should be used in current and planned IT systems. A network based, infrastructural Authentication and Authorisation Service is really two services: An Authentication Service and an Authorisation Service that together constitute an infrastructure for Access Control. The Authentication Service is a broker for traditional and PKI based authentication mechanisms. The authentication request contains the credentials of the entity to be authenticated. The reply contains the result of the authentication and information on (the strength of) the authentication mechanism. The Authorisation Service provides its clients with advice on access control and authorisation. The authorisation request contains information on the identity of the entity requesting access (the Source), the strength of the authentication mechanism used, the resource the Source wants to access (the Target), and any constraints relevant to the reply of the Authorisation Service. The reply is a simple "access (not) adviced". The decision of whether the Source shall be authorised to access the Target is the responsibility of the client to the Authorisation Service. The authorisation policy used by the Authorisation Service to recommend different types och access to the Target is based on policy rules. In formulating the policy rules, roles may be used. The roles are stored as specific configuration information for the Authorisation Service and/or in an Enterprise Directory. Information on the role explicitly taken by a Source (its Hat) is included in the request. The mandate to wear this Hat is checked by the Authorisation Service. Additional information on possible roles the Source may assume is available to the Authorisation Service in a role data base. The administration of users, accounts and access control in the traditional model is thus replaced by administration of the rule, resource and role databases. Administrative interfaces for these tasks has to be available in the Authorisation Service application. Several deployment models can be envisioned. The Authorisation Service can be profiled to :
In the first situation the Authorisation Service has only one client - the particular application - and may be installed on a local net, behind a firewall or even on the same computer as the application. Consider Ladok as an example of an application in the second profile. A common configuration of the rule data base may then be done by the Ladok Consortium as a service to the universities. The third example can typically be a portal system where most of the available services (channels) in the portal well may be controlled by one role data base - the Enterprise Directory. The fourth profile can be conceptually visualised as one coordinated network logon for students, irrespectable of from which university they come. Several of these profiles require harmonisation of directories and role definitions between universities. This section contains a list of requirements that we have identified and agreed upon. The Authentication Service shall as a minimum be able to handle authentication based on Username/Password and on a PKI. The Authentication Service shall return
The Authorisation Service shall be based on the concept that its client seeks advice on whether to grant a Source authorisation to use a Target under certain circumstances. The circumstances may be explicitly formulated by the Target (such as when it states what Hat it is wearing) or by the client. The client shall express these circumstances in Constraints included in the request. The Authorisation Service shall be designed with an API to pluggable directories for roles and authorisation policies. It shall also be possible to articulate and evaluate rules that require information external to the Authorisation Service, for instance load information or information from external data bases or directories. The Authorisation Service shall return
The members
of the project group are: |
||
|
|
||
