Version 1 (modified by prateek, 7 years ago)



Authorization in ORCA is based on Attribute Based Access Control (ABAC), which itself is based on attributes being assigned to identities. In the ORCA world, subjects and possibly objects too constitute the ABAC identities. Identities and the attributes assigned to the same are represented using X509 identity and attribute certificates. The certificates are stored either in a local or a global (ORCA-POD) certificate repository. Each certificate is associated with a subject and/or an object and can be fetched from the store using the same.

In a typical scenario where an experimenter E tries to perform an operation on object O that requires a capability C, the experimenter needs to prove to the authority A that he/she has the required capability. The same can be represented in ABAC terms as A.C_O <-?- E. This needs to be proved in accordance to authority A's policy, which again is represented using a set of identity and attribute certificates and can be stored in a certificate repository.

So, for the ABAC inference engine to query the required, it needs to be provided with the corresponding set of certificates, known as a context. Fetching the related certificates from the certificate repository based on the corresponding subject(s) and object(s) can form an ABAC context. The inference engine runs the query over the given context and returns a boolean result.

Certificate Repository

In the current ABAC implementation, each subject is identified by the SHA-1 hash of it's public key and each object is identified by the SHA-1 hash of it's object id.

Local Certificate Repository

Directories corresponding to subjects and subject-object pairs are created directly under the credential context home. Certificates associated with a subject (that are not scoped to any particular object) are put under a directory named as <subject's public key hash>, whereas certificates corresponding to a subject and scoped to a particular object are put under a directory named as <subject's public key hash>_<object id hash>. When a subject needs to prove it's capabilities with respect to an object, certificates corresponding to both, the subject and the subject-object pair are loaded to form an ABAC query context and the required query is run on the same.

Global Certificate Repository

A global certificate repository can have any independent structure for storing certificates. However, its needs to have a standard way of letting clients fetch certificates corresponding to a given subject and a subject-object pair. The currently implemented global store known as ORCA-POD does this by accepting requests of the following form


ABAC Configuration

A properties file named "" is put under $ORCA_HOME/config/. It contains the following properties.

The ABAC checks can be turned on/off by setting this value ot true/false.

Set this value to true if the certificate repository is available on the local machine, otherwise, a global repository is considered to be available.

If a local certificate repository is available, then set this value to the root folder for the same.
In case an ORCA-POD instance serves as a global certificate repository, set this value to the corresponding instance’s url.

Sample policy and subject/object certificates

A class named AbacTest? under package is available to create a sample policy and subject/object certificates and store the same in a local repository. To generate the required it needs to be provided with the path to the keystore files for the three actors, a SM, a Broker and an AM. It also needs to be provided the slice id for which the credentials need to be generated. As of now, the user identity is created afresh and the same needs to be used while requesting an operation. The subject private and public key that needs to be used can be found under <ABAC_Context_Home>/temp/.

Note: The AbacTest? class when run would search for the file under <Current Active Directory>/config/.