AGAST architecture

1 Introduction

AGAST is a project, funded by JISC, to investigate the possibilities of making access control decisions using an OWL-based reasoner. The expectation is that this will make certain types of policy easier to express, in the sense that they will be logically more compact, and that they will be more readily intelligible to the policy author. Although the project will be informed by approaches such as PERMIS, SAML and XACML, it is not a primary goal to be compatible with these.

The two high-level deliverables of the AGAST project (http://purl.org/nxg/projects/agast) are:

It is the architecture of the prototype PDP/PEP which is described in this document.

2 AGAST architecture

The AGAST architecture appears below.

PDP architecture

In this diagram, the PDP is a service which allows clients to use a RESTful interface to upload RDF, both (ABox) instance data and (TBox) OWL models, after which it will respond to SPARQL [std:sparql] queries against the merged model.

For example, a client might upload an assertion that an individual as a at particular university, along with information that that university is in the UK, and that the UK is in Europe; after that, it might ask (with a SPARQL ASK query) whether that individual is at a European institution. This example is worked out in detail at http://nxg.me.uk/note/2006/access-control/. As this example illustrates, the PDP will always answer basically the same question: is the individual of interest provably a member of the class of individuals allowed access to this resource?

We emphasise that the PDP software is entirely generic – there is nothing about the service we envisage which is specific to the problem of policy management. We believe that the PDP is largely written, in that the Quaestor server can already do the generic work required here. Thus, the majority of the AGAST development work will probably be in the development of the PEP which uses this service, and its associated software and specifications.

The PEP is responsible for generating the ACI information which it then uploads to the PDP. It obtains this by translating information in other formats into RDF. In our overall model, we expect the PEP to be rather promiscuous in where it obtains information, taking it from LDAP servers to which it has access, or available SAML services, or even from the access request itself, if there is information within an X.509 certificate which is relevant to the policy decision: for example, an access-control policy might be such that the domain of a user's email address would be relevant ACI, and this might be reliably obtained from an access request which includes an X.509 certificate.

The access-control policy – in the sense of the precise formal specification of who is permitted access to the resource – is therefore expressed in up to three places.

  1. There might be policy explicit within the ontology or ontologies used by the PEP. For example, there might be a class within the ontology named PermittedReaders, along with a set of necessary and sufficient conditions under which an instance is a member of this class (in OWL terms, this is a ‘defined class’). The membership of this class might be declared to be the union of the AtEuropeanInstition and AtInstitutionFoo classes. In this case, the access-control SPARQL query consists simply of a SPARQL ASK query, asking whether an individual X is a member of this PermittedReaders class.
  2. There will be more or less policy explicit in the SPARQL query which the PEP makes of the PDP. Thus a PEP might use a SPARQL query to ask directly if X is a member of the PermittedReaders class (thus building on a policy defined in OWL), or, if such a class is not available, synthesise it by using the query to ask if X is in the union of the AtEuropeanInstition and AtInstitutionFoo classes. The two cases are asking the same question, but in the first case the logic is expressed as an OWL class definition, and in the second it is expressed within the syntax of the SPARQL query.
  3. In either case, the translators – which convert the heterogeneous available sources of information into RDF – must produce RDF which harmonises with the queries the PEP makes, and the OWL models which it queries against. At one extreme, a translator might assert that X is a PermittedReader, but more likely it would assert something more low-level such that X is a member of staff at university Y, doing so using the classes out of which the high-level OWL classes are composed, or the classes referred to in the PEP's SPARQL query.

Our goal is to investigate the practicalities of this division of labour and the ideal balance between then, to discover patterns in the solutions required for our various use-cases, and to produce stereotypical SPARQL queries or OWL class definitions which will generalise our experience in this project.

Appendices

A Technologies

A.1 RDF, OWL, and Ontologies

RDF is an abstract data model, standardised by the World Wide Web Consortium [std:rdf], but drawing on a long history of Knowledge Representation work within Computing Science. There is a large collection of tutorial and overview resources at http://www.w3.org/RDF/. The account below is intended to fix terminology and act as a pointer to fuller descriptions; it is too brief to act as an independent tutorial.

RDF represents a broad range of assertions as sets of triples, consisting of resources named by URIs, which have properties whose values are resources or literals. RDF, RDF Schema (RDFS) and OWL describe these resources and properties using a vocabulary which includes terms such as rdf:type (indicating that a particular resource is of a particular type, named by a URI), or rdfs:subClassOf (indicating that one named class is a sub-class, or specialisation of, another) and owl:SymmetricProperty (indicating that the property thus qualified is a symmetric one).

RDFS [std:rdfs] adds to RDF a deliberately small set of primitive extra concepts, such as the notion of subclass and subproperty. OWL [std:owl] adds to this a richer set of logical primitives, such as set union and intersection, and symmetric or transitive properties. The expressiveness of the RDFS and OWL languages (plus a few intermediate languages) is constrained by the requirement that the complete set of possible deductions can be derived by processors of a certain type, in non-exponential time. For example, a processor that understands RDFS will be able to deduce, from the pair of statements that A rdfs:subClassOf B and B rdfs:subClassOf C, that A rdfs:subClassOf C. This particular type of relationship is known, in this trade, as subsubmption, and is key to the access-control approach described in this Note.

A collection of relations of this sort is known as an ontology. It consists of the definition of a number of concepts, or classes, such as Person, Father or Sister, together with the relationships between classes (for example Sister rdfs:subClassOf Person) and the definition of properties (such as hasSibling rdf:type owl:SymmetricProperty; rdfs:range Person). When combined with assertions about individuals, such as urn:example#Norman hasSibling urn:example#X, the ontology allows a reasoner to derive facts about the resources which were not explicitly asserted. Given the information in this example, an OWL-aware reasoner could deduce the triples urn:example#X rdf:type Person (because hasSibling has a range of Person) and urn:example#X hasSibling urn:example#Norman (because hasSibling is symmetric).

A word of caution: the term `class' here might be better thought of as `concept'. The terms `class' and `subclass' also appear in the context of XML Schemas, and more generally in object-oriented programming. There is an analogy between the use of the terms in those contexts and in this one, but it is a loose analogy: the use of types in the XSchema and O-O contexts is broadly to constrain behaviour and help identify errors, whereas the corresponding assertions in the context of RDF allow a reasoner to deduce a larger volume of implicit information. In particular, RDF schemas do not function as constraints, and mistakes made when defining concepts in an ontology, or when asserting information about resources, do not manifest themselves as `schema violations', but instead more indirectly, when a reasoner finds it is able to deduce contradictory information, for example being able to prove that some resource urn:example#X is simultaneously a Person and not a Person.

A.2 Privilege management infrastructures (PMI)

PERMIS is an X.509 PMI. It's heavily based on LDAP servers, and turns out to be rather hard to use. The Shibboleth infrastructure involves where-are-you-from servers which exchange SAML assertions. WS-Policy, SAML, and the OASIS Extensible Access Control ML (XACML) are ways of expressing policies and assertions, as distinct from being systems which implement and reason about them. All of the systems mentioned here are, it seems, rather static, having problems with even moderately dynamic information. Related to that, though distinct, neither PERMIS nor Shibboleth does delegation very naturally (for example, `we'll let you use this resource if institution X would let you borrow from their library').

A.3 X.812 / ISO-10181-3

ITU-T Recommendation X.812 (identical to ISO/IEC-10181-3) defines a vocabulary for Access Control. This includes the usefully distinguished set of concepts below. Note that none of these are concerned directly either with authentication (the assertion that a user is who they claim to be) or with the secure transmission of assertions (such as that a given user is indeed a member of staff at a particular institution). Establishing and transmitting these assertions are problems orthogonal to authorisation, and their connection with the authorisation problem is that both are examples of ACI.

For definitions of the X.812 terms AEF, ADF, ACI and ADI, see the glossary below.

The above use-cases are all concerned with different types of ACI, including the ACI which represents the access policies, therefore they are effectively constraints on the ADF which we must employ. Because the Access Control methodology must work with a variety of different technologies, such as web pages, JDBC calls, or RPC -- that is, with a variety of different AEFs -- the ADF should probably be technology neutral.

B Glossary

AEF
Access-control Enforcement Function. This is the software which permits or denies access to a resource [the /usr/bin/login program is (as I understand it) such a function, as you have to go through this program to get access to a Unix box; it does or does not give you a shell]. That is, the AEF enforces the decision which the ADF makes. [std:x812]
ADF
Access-control Decision Function. This is the function which provides the yes/no decision. The AEF consults the ADF to decide whether to grant or deny access. [In the /usr/bin/login case, this would I think be the crypt(3) function] [std:x812]
ACI
Access Control Information. This is information such as the identify of the individual requesting access (the initiator), their group or role memberships, or information about the properties of the target, such as its confidentiality. [In the /usr/bin/login case, this is, I think, the username/password pair] [std:x812]
ADI
Access-control Decision Information. This is the subset of the ACI which is actually used as input by the ADF. Thus the offered password plus salt is what is given to crypt(3) and compared with the saved password hash, so I think these are part of the ADI, but the username isn't. The time of day, or the number of previous login attempts, if they were relevant to the decision, would also be ADI, though these aren't supplied by the individual. I think that time-of-day and so on would be ACI whether or not they were used by the ADF (and thus were ADI). [std:x812]
PDP
Policy Decision Point: The point where policy decisions are made. [std:rfc2753]
PEP
Policy Enforcement Point: The point where the policy decisions are actually enforced.[std:rfc2753]

C References

[std:sparql] Eric Prud'hommeaux and Andy Seaborne.
SPARQL query language for RDF. W3C Candidate Recommendation, June 2007.
[std:rdf] World Wide Web Consortium.
Resource Description Framework [online, cited February 2005].
[std:rdfs] Dan Brickley and R V Guha.
RDF vocabulary description language 1.0: RDF Schema. W3C Recommendation, February 2004.
[std:owl] The web ontology language [online].
February 2004.
[std:x812] Information technology -- open systems interconnection --- security frameworks for open systems: Access control framework (ITU-T Rec X.812 = ISO/IEC-10181-3:1996).
International Standard ISO-10181-3/X.812, 1996.
[std:rfc2753] R Yavatkar, D Pendarakis, and R Guerin.
A framework for policy-based admission control. RFC2753, January 2000.
Norman
Modified: 2013-04-05 14:36 +0100