OKKAM project aims at enabling a web of entities by providing an infrastructure of decentralized online repositories, each owned by either a public or a private organization. A repository is designed to handle a large number of entries (as the Web identities are) where creators of entries are end-users. In this paper we present a semantic approach to access control that naturally scales to the large number of entries in a repository and defines a flexible association of access policies and repository entries based on semantic attributes. An automated enforcement of access control policies is presented allowing users to automatically establish necessary access rights with online repositories, and interoperate their credentials based on semantics of credential interoperability.
Online repositories comprise a vast catalog of database functionalities. The OKKAM project challenges the way entities are identified on the Web. The notion of entity in OKKAM is not restricted to computing entities. It refers to any entity such as people, places, real world objects, etc. The core OKKAM notion is the use of repositories for storage and retrieval of identity information on the Web. OKKAM provides a specicfi infrastructure for identity specification and a query process. Each identity in a repository has a unique identiefir and a set of (minimal) attributes characterizing the identity. The attributes have different classicfiation of protection and sensitivity. The project adopts an open attribute schema approach where the creators of identities denfie their own schema of attribute description.
Online distributed repositories. Potentially any company or organization can provide its own denfiition of identities specific for a given domain. Since the Web of entities is itself unbounded in terms of number of identifiable objects so OKKAM repositories inherit the large uncontrolled definition and expansion of identities. The repository infrastructure has to address the heterogeneity of organizations’ requirements holding OKKAM repositories, scalability and manageability of large number of identities while, at the same time, it has to adapt to the dynamic nature (evolution) of the Web of entities.
OKKAM denfies a decentralized peer-to-peer interaction model for repository storage, replication, entries creation, update and query. There are two types of interactions: repository-to-repository and user-to-repository. Repository-torepository interactions occur because of query forwarding (e.g., from a private to a public node) or repository replication/synchronization. User-to-repository interactions occur when users query a repository or wish to perform an action on a repository (create, modify, or delete entries).
An OKKAM network is identiefid as having two types of nodes: public and private nodes. Public nodes are owned by a non-proprietary owner while private nodes are owned by proprietary organizations or companies. The public domain is open to potentially unknown users while the private domain has the specicfis of being under the control of a proprietary organization.
Unbounded number of entries in a repository. An OKKAM repository is expected to have unbounded number of entries. There is neither an upper-bound of expected number of entries nor a requirement to limit them. An OKKAM repository is designed to handle unbounded number of creators of entries. Any user is a potential creator of an entry or multiple entries. The use of resources, entries or identifiers (IDs) is interchangeable throughout the document and they all refer to identity elements in a repository.
We will focus on user-to-repository interactions as these comprise the main OKKAM functionality. Repository-to-repository interactions can be handled similarly to the user-to-repository interactions in the case of query forwarding (e.g., a private node becomes as a client when querying a public node).
Access control and certification management. Trust in the OKKAM infrastructure is based on certicfiate authorities that qualify OKKAM repositories and user privileges by means of digital certificates. The access control process will be based on digital certicfiates attesting users’ roles and access rights. Digital certificates are well suited for decentralized peer-to-peer identification and authorization. Management of digital certicfiates as well as privacy of their usage is a key issue in OKKAM. 1.1
Paper contribution: Interactive semantic access control
In this paper we present a model that converges a semantic access control
approach [
Hierarchical models
Certificates structure
The interactive access control model is applied on top of the semantic
access control specification for on-the-fly establishment and enforcement of
necessary access rights between user-to-repository (or repository-to-repository)
interactions. The automated trust negotiation process is extended with semantic
interoperability of credentials [
Section 2 provides a background on existing identity and attribute certicfiation. Section 3 reviews the core certification model of the OKKAM infrastructure. Section 4 overviews the semantic access control model. Section 5 describes the negotiation model and its association to semantic interoperability of credentials. Section 6 concludes the paper and outlines the future work. 2
Public Key Infrastructure. A Public Key Infrastructure1 (PKI) [
A public-key certificate is a digitally signed document certifying that a
particular individual owns a certain public key. A public-key certicfiate has a special
data structure and is digitally signed by a third party called the Certicfiate
Authority (CA). A public-key certicfiate serves to bind a public key to an individual
holding the corresponding private key, and the correctness of the binding is
guaranteed by the CA [
In this framework, condfience regarding an unknown party identity is derived from existing trust relation between the verifying party and the CA. Since there are multiple CAs, a mechanism is needed to allow vericfiation of an unknown CA integrity. This is achieved by distinguishing between two types of certicfiates: end-user certificates and CA certificates. An end-user certificate is a public-key certificate issued by a CA to a subject that cannot be an issuer of other publickey certicfiates. By contrast, a CA certificate is a public-key certificate issued (signed) by a CA to delegate to another party the right of issuing public-key certificates. Through this certificate, the delegate takes the function of a CA which (if the delegation policy allows) can further delegate this right to new parties.
With such a model, trust in a given CA can be built through the establishment of a certification path from an end-user certicfiate to a trusted CA’s certificate. A certification path corresponds to an unbroken chain of CAs’ publickey certificates that serves as a proof (of trust) to authenticate parties. Figure 1(a) shows a graphical representation of the hierarchical trust relationship established between CAs. In this hierarchy, the CA with the highest authority is called the root CA and has a self-signed certificate.
Privilege Management Infrastructure. A Privilege Management
Infrastructure (PMI) [
An attribute certicfiate binds an attribute statement (or a set of attribute statements) to an individual. Trust in such certicfiate is derived from the trust in the AA authority to issue specific attributes. For instance, the University of Trento has the authority to state that Mario Rossi is an associate professor in this university. If a party trusts the University of Trento, then it can trust its assertion about Mario Rossi being employed there or not. Figure 1 shows the core structure of the certicfiate document used in both models.
Currently, only few PKI/PMI compliant implementations have reached a
very broad deployment states. The most widely used such standards today are
X.509 [
In the following we will review the core certification model suitable for the OKKAM public and private domains. Trust in OKKAM infrastructure and its 2 Simple Public Key Infrastructure
authenticity is an essential element that we will start from. In the model we will unify CAs and AAs under one physical authority, i.e. any entity identified as CA will have the authority to issue not only public-key certicfiates but also attribute certificates. Hereinafter, whenever we refer to a CA we will implicitly refer to its ability as an AA.
A root CA, as in any PKI model, is the entity that trust starts from. The root CA is the most sensitive authority which will set up trust in the OKKAM infrastructure. As such, the root CA will have the authority to identify subordinate CAs and delegate the right to be a CA. Each node has an OKKAM repository under its own administration. Each node has a CA that has the authority to manage public-key and attribute certificates only to the scope of its domain.
The root CA has the responsibility to certify any OKKAM node so that any third party can verify (trust) that node as being part of the infrastructure. Thus, the rfist level authority delegation forms the trust in the OKKAM infrastructure where each CA corresponds to only one OKKAM node. Note that the rfist level delegation includes public and private OKKAM nodes, which means even proprietary nodes are to be certiefid by the root of trust.
Next level of delegation includes the end-user certification. Within a CA’s authority each entity should register as a specicfi user type. The root CA will never issue end-user certicfiates since its role is to serve as a root of trust and, as such, it will only authorize OKKAM nodes to be part of the infrastructure.
Across all public nodes there will be a common classification of users to roles and responsibilities that each CA should conform to. Regarding private nodes, the common classicfiation of users to roles may differ due to specific organizational settings. However, if private nodes want to share part of their users with those of public nodes, or vice versa, they have to conform (interoperate) with the public domain of users to roles classification. Semantics of credential interoperability is discussed in the following section. 4
The semantic access control model (SAC) [
Semantic definition of access policies. The SAC model denfies a Semantic Policy Language (SPL) in order to express access policies in terms of credential definition and requirements applicable to some semantic properties. A separate specification called Policy Applicability Specicfiation (PAS) is used to dynamically relate policies to objects based on semantic information of objects. Additionally, each object (identifier) is described by a set of semantic properties so that when a request for accessing an object arrives, the access control module derives the relevant object properties and evaluates all PAS specicfiation to select which semantic policies match the object properties. Both SPL policies and PAS use semantic information about objects, and other contextual information. Additionally, policies can be composed using imported elements from other policies without ambiguity. This compositional approach allows us to denfie an abstract meaning of policy elements which helps in reducing the complexity of management.
By using the semantic denfiition of policies one can specify independent policies, so that, for each newly generated entry the user does not need to explicitly denfie a policy for the entry but to specify some entry’s properties protected by some of the predefined policies. The notion of predenfied semantic policy denfiitions is relevant to the OKKAM’s nature where potentially any user can create identities but the same is not expected to be aware of how to denfie (qualify level of protection) for the identities it creates. SAC will allow a policy developer to denfie even policies for fine grained actions on objects (e.g., modify, merge, delete, split etc.).
In the following we show simple (rather informal presentation of) SPL policies and a corresponding PAS specification. The rfist SPL policy denfies the credential requirements for a trusted OKKAM user. The second policy defines the requirements for an empowered administrator (with a delete authorization permission). The third SPL policy (#OpenAccessPolicy) denfies no access restrictions.
SPL policy identifier Credential requirements #TrustedUserPolicy registered user OR administrator #PoweredAdminPolicy administrator AND delete authorization #OpenAccessPolicy
The following PAS defines some policy applicability on objects’ properties and operations.
Object property Social security number Social security number Social security number OKKAM ID OKKAM ID OKKAM ID #ANY# #ANY# #ANY#
Property operations Applicable policies
read #TrustedUserPolicy modify #TrustedUserPolicy delete #TrustedUserPolicy read #OpenAccessPolicy modify #PoweredAdminPolicy delete #PoweredAdminPolicy read #OpenAccessPolicy modify #TrustedUserPolicy delete #TrustedUserPolicy For simplicity we only consider operations: read, modify and delete. The PAS states that a property Social security number on read, modify and delete operations is protected by a trusted user policy, meaning that only identifiable users are allowed to access the Social security number of objects in a repository.
The second protected attribute is an OKKAM ID defining objects’ identiefirs, as generated by a repository system. OKKAM ID is assigned uniquely to each identity object. Read access to an object’s OKKAM ID is unprotected (any user is allowed to see it), while modify and delete operations are restricted to only empowered administrators. Since a delete operation is very sensitive in the OKKAM settings only administrators with an explicit delete authorization permission are allowed to perform the operation.
The third attribute identifier (#ANY#) serves as a default protection on attributes not explicitly protected by an access policy. The PAS here defines a default read operation to be unprotected, while modify and delete operations are only allowed to trusted users.
Now, if a user created an object in a repository with properties First name, Last name and Social security number (for example generating its own identity information), on receive of a request and action on that identity the following semantic policy composition would apply: Object property OKKAM ID OKKAM ID OKKAM ID Social security number Social security number Social security number First name First name First name Last name Last name Last name
Attribute-based access control vocabulary for policy applicability. One of the main project challenges is to allow end users to use their own attribute schema for describing identities on the Web. This open attribute schema poses an inherent challenges to the access control protection on identities in a repository. An approach adopted is to denfie a predefined access control vocabulary for generic attribute protection, so that creators of identifiers can use it to semantically describe the attributes of the identities they create. The motivation is that creators best know the exact semantics behind the attributes they denfie when generating identities. In this case, for each attribute of an identity, the creator can ”describe” it by means of the pre-defined access control vocabulary, thus providing a semantic description of protection on the given attribute.
The predefined access control vocabulary is to be easy perceived by the end users and, at the same time, to be eflxible in describing desired level of protection on a priori unknown attribute schema. To address the last feature we need to denfie an evolvable access policy vocabulary that best qualifies, at a given time, the protection requirements of identities’ attributes.
Thus, on entity creation time, the creator can use a semantic policy language,
such as OWL [
Figure 2 shows a semantic policy applicability process. The semantic applicability layer evaluates for a given repository entry and its attributes what access control qualification it applies based on the entity semantic access control description. We have specifically defined vocabulary attributes managed by a repository administrator. An inportant aspect here is the resulting policy composition out of the semantic policy applicability process. A research direction is to explore how to approach a possible policy composition based on what semantic information current protected attributes may leak out of the identity when used together. 5
Most authorization approaches are based on locally issued credentials (attributes or privileges) bound to user identities. When these schemas are applied to open distributed settings, like the OKKAM nature, they result in limited and inconvenient credential management with a lack of interoperability of attributes. It is unlikely to expect that different heterogeneous systems would unify a common homogeneous set of authorization criteria.
The SAC model introduces an extension of the core semantic policy
definition [
For example, a user in a public domain could be either a registered user or an administrator user of a node under the CA’s authority, while in the private domain a user could be qualified with different attributes, for example, being a PhD student, or an assistant, or a professor at an Italian university.
Let assume that the OKKAM public domain wants to open (semantically expand) access to its repositories to professors at Italian universities by qualifying them as having an administrator privileges. To do so, each CA of a public node will include in its respective SOAD the following semantic implication:
The rule states if an entity is a recognized professor at CRUI4 then the entity obtains semantically equivalent permissions of a local administrator at an OKKAM public node (under a given CAOKKAM ). The implication essentially delegates trust to CRUI as an external equivalence for recognizing Italian professors. Now, let the SOAD of CACRUI have the following implications identifying the role professor at University of Trento, University of Bari and University of Roma as a recognized professor role at CRUI:
If a professor at the University of Trento tries to access a public OKKAM repository, the enforcement module will recognize his position as a CRUI professor and will provide him with equivalent permissions to those of a local administrator. The semantic interoperability approach assumes that CA’s SOADs are networked and known by entities trusting the CAs. In our example, the public repository obtains (or cached from previous connections) the SOAD of CRUI and all other SOADs of external trust implications.
Automated credential negotiation. OKKAM management policy postulates that all CAs under a public domain will have a same level of trust in each other, for example, a registered user/administrator at one node is recognized as a registered user/administrator at another node. This can be flexibly achieved by uniforming the role names among all public nodes. However, between public and private nodes trust relationships are established on a bilateral manner and often the necessary access rights for a resource are unknown at a request time.
The work in [
satisfying server’s access policy or there is no missing set to be asked to the client and the server denies access.
The work in [
Let us take our own example of a repository (a server) that protects an OKKAM identity object having the attributes OKKAM ID, Social security number, First name and Last name, and its associated semantic access policy as denfied in the previous section. Figure 3 shows an example of a possible negotiation scenario between a user and a repository server.
The disclosure policy on the repository site states that the need of roles Registered user and Administrator is disclosed on demand to potentially any requestor, while the need of Delete authorization permission is disclosed to those clients who have presented their Administrator role. Since a delete permission is sensitive information its need is only disclosed to administrator users.
The credential policy states that the repository own public-key certicfiate is given to anybody who needs to see it, while the repository own credential of being a public node is given only to registered users or administrator users, thus ensuring only legitimate system users can obtain the node public status.
Let us look at the user side. We note that a user has no access control policy since it provides no resources/objects. The user has an Administrator certified privilege which is given only to repositories identified by their publickey certificates, and a Delete authorization permission given only to repositories running under an OKKAM public domain.
Automated negotiation with semantic interoperability of credentials. An important aspect of a cross-domain semantic access control process is the ability of opponents to establish an agreement on necessary access rights whenever possible. The use of SOADs, as part of the SAC model, provides a scalable solution to inter-domain semantics of credentials. The challenge here is to customize a negotiation process to allow SOAD documents to be evaluated on the fly achieving a smooth and automated credential agreement.
If the user in Figure 3 is replaced with a user belonging to a private node, let us take the example of a professor at the University of Trento. In this case, a solution is to allow a repository server along with its request for an Administrator role, to communicate to the client the SOAD specicfiation imported from the CA authoring the public repository. Since the user has no administrator role, the same can evaluate the attached SOAD specification, verify if the CRUI’s SOAD qualifies professors at the University of Trento, and derive the semantic equivalence of his professorship with the local administrator authority.
Next, the user evaluates what counter requirements it has for giving its professorship certificate and counter-requests the repository. Analogously, the user will also send a SOAD specification of the University of Trento’s CA along with the counter request. In that way, the repository evaluates what equivalent credentials it has with respect to the university’s SOAD and proceeds accordingly. The negotiation process continues until a semantic credential agreement is reached or denied. Figure 4 shows the newly identified semantic interoperability layer for automated trust negotiations. The semantic layer is bootstrapped from SOAD specifications of CAs trusted to the two opponents. We have presented a semantic access control approach, its extension for semantic interoperability, and its automated negotiation-based enforcement suitable for decentralized online repositories in the context of the OKKAM project. We have shown how the semantic access control model could scale to the large number of entries in a repository. We have introduced an extention to an automated credential negotiation model that provides entities with ability to bilaterally establish necessary access rights using semantic interoperability of credentials.
Future work will follow on the research directions below. – Research on a suitable access control vocabulary and representation, and how to define policy compositions based on the semantics of repository entries’ attributes. – Integration of the semantic interoperability of credentials model into an automated negotiation process, and how to scale to deriving indirect interoperability of credentials. The use of the OWL as a description language of SOAD-based documents.