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.
The AGAST architecture appears below.
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
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.
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
AtInstitutionFooclasses. In this case, the access-control SPARQL query consists simply of a SPARQL
ASKquery, asking whether an individual
Xis a member of this
Xis a member of the
PermittedReadersclass (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
Xis in the union of the
AtInstitutionFooclasses. 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.
PermittedReader, but more likely it would assert something more low-level such that
Xis 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.
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
(indicating that one named class is a sub-class, or specialisation of,
owl:SymmetricProperty (indicating that the
property thus qualified is a symmetric one).
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
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
Sister, together with the relationships between
classes (for example
Sister rdfs:subClassOf Person) and
the definition of properties (such as
owl:SymmetricProperty; rdfs:range Person). When combined with
assertions about individuals, such as
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
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
urn:example#X is simultaneously a
Person and not a
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').
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.
/usr/bin/loginprogram 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]
/usr/bin/logincase, this would I think be the crypt(3) function] [std:x812]
/usr/bin/logincase, this is, I think, the username/password pair] [std:x812]