Executive Summary

Spocp is built using a well defined syntax (S-expression) to represent the authorization policy for a resource. It can be used either as a library linked directly into the application or as a local or Internet based service. In either case the connection can be guarded by using the SSL/TLS connection protocol. When an authorization decision needs to be made, Spocp uses the information provided in the request as well as external information, which is needed to evaluate constraints in the policy rules, in order to determine whether the request is to be granted or not.

The Spocp usage model follows the so-called push sequence model, that is the user connects to the resource and the resources checks with Spocp to find out if the user is allowed to use the resource in the way she wants to.

Spocp can act as a stand-alone server without any dependencies on other resources.

Background

With the continued development of Internet-based application services, it is no longer only the experts in an application field or of an information system that are users of the systems. Instead more and more of the processes in an organization involve at least self-service components of these applications. They are to a larger and larger extent supporting the everyday work process. We are therefore quickly approaching a situation where every member of every community affiliated with our organization needs to be a user of our major information systems. Until now, this has usually meant maintaining really large, separate, authentication and authorizationsubsystems (access control systems) - one for each of our Applications. When a person moves within or leaves the organization the information about this person has to be changed or removed from every system.

Our, and many others', analysis of this problem, is that we need to start a development process aiming at a situation where at least the "amateur" users are automatically given authorities in our systems based on attributes,characterizing or describing the individual, rather than on the identity of the particular individual.

To reach that goal, we need

• a good record of who belongs to our community
• knowledge of which attributes and other information that characterizes and categorizes the members of our community
• a policy for how these attributes are assigned
• an Information System where these attributes can be safely managed
• an attribute or role-based Authorization System, that can be served these attributes from a database or a directory.

SPOCP is an Authorization Server designed to solve the latter of these bullets. It is designed as a Network Based Infrastructural Service (a Middleware service) and we believe that SPOCP will prove quite useful, in different deployment models, for a variety of applications and application environments.

It is worth noting that SPOCP is designed to be able to use external information resources, such as an enterprise directory, when evaluating policies. So, in most cases there should not be any need for duplicating information into SPOCP that is already present in some accessible information resource.

Terminology and Framework

While describing SPOCP we will use the terminology and framework defined in RFC 2904.

The Spocp server is designed to work as RFC 2904, in what is termed the 'Pull Sequence', that is:

1. The user sends a request to the Service Equipment (the application),
2. which forwards it to the Service Provider's AAA server (Spocp in this case),
3. which evaluates the request and returns an appropriate response to the Service Equipment,
4. which sets up the service and tells the User it is ready (assuming, of course, that the response from the AAA server was positive)

Also as specified in RFC 2904:

  In general, it is assumed that the parties who are participating in the authorization process have already gone through an authentication phase. The authentication method used by those parties is outside the scope of this document except to the extent that it influences the requirements found in a subsequent authorization process.
        

SPOCP - The Policy Engine and the Policy Language

The core of the SPOCP Authorization Server is a Policy Engine, designed to decide if an authorization request (query) from an application satisfies the authorization policy for the particular application or not. Very basic to the design of the SPOCP Authorization Server was the choice of S-expressions as the syntax for expressing the rules of the policy as well as the authorization requests from the application. This approach was first conceived in work done by a group within the Swedish Institute of Computer Science. S-expressions were to our knowledge first described by Lampson and Rivest in SEXP and SDSI in 1996, but its origin can be traced back further to LISP. S-expressions were brought to our attention through the work of the SPKI working group within the IETF.

A request satisfies the policy if some rule in the policy permits the requested authority. Spocp decides this by, for each rule in the policy, calculating whether the query is less permissive than the rule. To say that a query is less permissive than a rule shall be interpreted as that the policy rule permits the authority requested and probably other and higher authorities as well. The idea behind writing a policy is also just that - with a "small" set of general rules, SPOCP shall be able to permit a large number of specific requests. The calculation is done by evaluating the formally defined Less-Permissive function. It has been shown by Bandmann and Dam that an authorization system based on a restricted form of S-expressions and the Less-Permissive function will always give formally correct advice to the querying application. It needs to be stressed that the policy engine only bases its authority advice to the application on the result of the evaluation of the Less-Permissive function - that is it makes purely syntactic evaluations. It is the responsibility of the policy writer to map an analysis of the authorization structure of the application to the syntax of S-expressions.

In authority structures the concepts of appointments and delegations are central. By appointment we mean assigning an authority you do not necessarily have yourself; - a person issuing driver's licenses does not need to have a driver's license. By delegation we mean transferring parts of your authority to someone else. Work by the SICS group is also behind our approach to appointment and delegation.

In a Internet draft from 1997 Rivest describes three different representations of an S-expression: the canonical, basic transport and advanced transport representation. The Spocp client protocol uses the canonical representation while we in this document will use the advanced transport representation, because it is much more user friendly. We have also choose to leave out "display hints" since we really think that 'normal' users should never have to see S-expressions.

An example of an S-expression policy rule is:

(spocp (resource etc passwd)(action write)(subject (uid 0)))
      

Which would mean that the subject with uid 0 has write access to /etc/passwd.

S-expressions have a well defined syntax but no defined semantics, that together with the fact that one can build an engine that can compare two S-expressions and answer the question whether one is equal or more specific than the other is the basis of the SPOCP policy engine.

To understand how this work one has to understand that an S-expression is made more specific by adding an item to the end of a list.

(resource etc password ) is for instance more specific than (resource etc)

Adding an item at some other place in a list creates a different S-expression which is neither equal nor more specific:

(resource usr etc) is neither equal nor more specific than (resource etc). It is just different.

Implementation issues

In order to make SPOCP really useful, we have refrained from specifying exactly one way of implementing the service. Instead SPOCP comes in a number of different shapes. Differing in the closeness to the application and also in the access protocol. In closeness order:

• As a library which can be linked together with your application. A simple C API consisting of a small set of function calls are provided.
• A standalone server that can listen to a Unix domain socket or a Internet IPv4/v6 port. Using TCP as transport protocol. The access protocol is the SPOCP client access protocol.
• Through a access control module, like the Apache module - mod_spocp - where the Policy Engine is being a sesimparate library module with a specified API.

Why you would choose one setup instead of another are factors like:

• speed
  • having to connect another server always takes more time than doing things locally,
• manageability
  • having SPOCP processes running on central systems managed by professionals, will probably give you better uptime. It will also make it easier to get new applications covered by the authorization system since the environment already is there.
• Application structures
  • Some application already have a defined access control API which it pays well to use.
• Security
  • In some cases revealing the traffic pattern between a application and a policy server is sensitive information

We have chosen to maintain and store rules in a policy repository that is tightly coupled to the policy engine. So in our world the authorization server always has all the policies in local storage.

Some of the information needed to set up a complete Policy may not be available when the modeling is done, or there may be other reasons that some information may be best provided through an external information source at the time of testing whether a Query complies. This often occurs when a Constraint is involved in the compliance test. SPOCP offers the possibility of using what we term boundary conditions. Examples of such conditions are:

• date and time
• information in an enterprise directory
• information in databases and/or files
• information in DNS ( for example Real timeBlack hole Lists )

Creating Policies

As stated above the SPOCP policy engine does not care about the semantics of the policy or request expressions. The policy engine only cares about whether the rules and requests follow the S-expression syntax . Even so, as a convention we have so far used a structure where the S-expressions consists of three parts: Subject, Action and Resource, the following presentation is therefore tinted by that choice.

The need to access external information

In lots of cases information, that is needed when a policy is to be enforced, is not present at the time when the rules as defined. Therefore a way of 'referencing' this external information is needed. We have chosen to implement it as constrains that can be included in the rules and which are evaluated/computed at the time when a request is evaluated.

Equally common is the case that information is already managed somewhere else. The organization might have a enterprise directory where it keeps information about users, groups, roles, organization structure and copying this information into rules might cause more problems then it solves.

Also, if you want to make rules active only at certain times, it might be more effective to defined the time constrains in the rules and then have them checked on evaluating the requests instead of adding and removing them as the time goes.

Appointment and Delegation

To illustrate the approach let R0 be some authorization such as the right to read document D.

The unspecific right to read document D can be expressed in a S-expression as:

(spocp (resource D)(action read)(subject))
      

Then the rule that allows A to delegate the right can be expressed as

(spocp (resource R0)(action delegate)(subject A))
      

Now, if we who have supreme power wants to give A the right to delegate to B to delegate to someone within the group G the right to read the document B, then this will be done through the chain:

R0: (spocp (resource D)(action read)(subject (group G)))
R1: (spocp (resource R0)(action delegate)(subject B))
R2: (spocp (resource R1)(action delegate)(subject A))
      

Obvious from this example is that the right to delegate a right never implicitly gives the right to use a right. B or for that matter A, is according to the chain above no allowed to read the file D unless they belong to the group G.

The SPOCP Server Software

Written in C, develop on a Linux system.

Has been ported to FreeBSD, Solaris 8.0 and Mac OS X .

Availability

Open source. ftp://ftp,catalogix.se/dist/spocp.tgz

References