1. O. Otenko PERMIS Project Salford University © 2002
How-to: Authorise
O. Otenko
PERMIS Project
Salford University
© 2002
During the past two years I have been participating in the pan-European PERMIS project designing and developing authorisation modules. Now the project has finished. As the result the project under JISC to compare the Akenti and PERMIS authorisation systems has been started. It aims to evaluate the architectures of the two and do performance and manageability comparisons. As part of the research we have studied other systems to pin-point the most important design questions - the questions that have rigid solutions and affect the usability of the system.
We will have a look at how existing systems are coping with them and how the solutions affect extensibility and flexibility.
I am assuming the audience is familiar with the architectural concepts of the authorisation systems.

2. Key Issues Issuing Authorisation Tokens
(who is the Issuer?) Extension and flexibility
Distributing Authorisation Tokens
(Push vs Pull)
distribution = publicity - impersonation
Looking at AuthZ from Server
(who is protecting the Server?)
Among the key design issues there are these three.
It is important to decide who and how issues the authorisation tokens. The question is down to how the trust relationship is established between the verifier and the issuer of the privileges. Indeed, the question of establishing trust between all of the parts of the system is important, only that other parts of the system are bound in a pretty static way.
Answering a chain of questions: “why do you trust the user? Because I trust the issuer.” “and why do you trust the issuer?..” It should always end with “because I trust me”. The chain in general can be quite long, but in fact there is hardly any delegation involved, so a lot more ways to do that are feasible. However, in long run not all of them are equally flexible and extensible.
The tokens can be put in a publicly accessible places, which diminishes privacy. There are also questions of impersonation and what can be revealed to others. On the other hand the tokens can be given to the users directly, which causes its own set of problems.
Finally, a very important point is what the decision mechanism is actually returning. This affects the complexity of the decision-enforcement modules.

3. Issuing AuthZ Tokens PAPI: authentication server (trusted)
Client Name ?
AuthZ Token
PAPI: authentication server (trusted)
Shibboleth: handle service (impersonation)
CAS: server issues short-living PKCs
IBM: CA issuing PKCs (can be configured)
Akenti: CAs issuing proprietary ACs
PERMIS: AAs issuing X.509 ACs
In PAPI the tokens are issued by the authentication server. The server uploads the tokens to the user’s browser after successful authentication. Such approach works for impersonation of the holder and simplifies the decision-making module as we will see later. However, there are complications related to delegation and also there is a requirement for the Target to trust all the existing authentication servers to issue the authorisation tokens (which is a difficult case).
In Shibboleth there is a simple PMI introduced with Attribute Authorities issuing the attributes to the users of the system. The Shibboleth developers applied main effort to ensure user privacy, so the certificates do not contain the holder name, only the digest of his PKC, nor does it contain the issuer name - so it should be cumbersome to extend the PMI without changing the policies of all the Targets that are intended to accept the attributes.
The CAS server is acting like a CA to issue short-living PKCs with authorisation attributes as extensions. There is the same problem as in PAPI that the Targets should trust the policy of the CAS on issuing the certificates and requirement to update the rules on all the CAS servers when the policy changes. The IBM access control system can be configured to understand various infrastructures and certificate format, but by default it uses PKCs, like the CAS. It is questionable, if the PKCs should be used to contain the authorisation information.
Akenti and PERMIS have infrastructures of authorities issuing ACs.

4. Token Distribution & Delegation
Push
revocation
no software available
delegator’s tokens
Pull
locating the tokens: naming
privacy and impersonation
(no delegation implemented anyway)
controlling what is revealed
The tokens can either be stored by the user and presented to the Target on request, or the Target would retrieve the user’s tokens on its own, knowing the user’s identity. The models are respectively called the Push and Pull models.

5. Token Acquisition Tokens acquired using PAPI Shibboleth CAS IBM Akenti
PERMIS
Push; tokens go as cookies
Pull; WAYF service locates the server
Push; token goes as the signing PKC
Push; token goes as PKC in SSL (can pull)
Pull; policy-specified servers
Pull; configured servers (can be pushed)

6. Who is Protecting the Target?
Client Name
AuthZ engine ?
PAPI: explicit ACL statement
Shibboleth: attributes (Grant/Deny in DAC mode)
CAS: attributes
IBM: roles
PERMIS: Grant/Deny
Akenti: Grant/Deny
This slide shows what is the output of the authorisation engines. The simpler the output, the more complicated the Target Access Control policy is. The more complicated the output is, the more work should be done on the part of the software integrating the engine into the Access Control system.
The PAPI system sends just an ACL - very simple to implement, very difficult to control.
The Shibboleth system does provide a policy to return simple answers Grant/Deny, but the policy is DAC, which implies difficulties in extension and managebility. It is possible to derive a more complicated decisions by intercepting the attributes the Shibboleth Handle Service returns, but this should be done by the integrating code.
The CAS server just returns the attributes, so there is the same problem, as with Shibboleth.
The IBM Access Control system returns the roles that are assigned correctly to the user, but the policy does not have the role specification, and it has to be implemented by the integrating code.
The PERMIS and Akenti systems return a Grant/Deny reply, which is easy to enforce by the AEF. The policies are quite complicated and contain both role assignment rules and role specification.