Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Within iSHARE, it is essential to provide fine-grained authorisation authorization. Besides rules on the authorisation authorization , it is important to have varying options to describe the resources and its attributes to which the rules apply.

XACML 3.0 is a specification for describing such authorisation such authorization rules, but it is XML-based. For iSHARE, a JSON port was created for expressing the XACML specifications regarding authorisation authorization . This 'delegation evidence structure' is discussed in more detail in the chapter on delegation evidence structure.

...

XACML (eXtensible Access Control Markup Language) is an XML-based specification that is designed to control access to applications. One of the main advantages of this specification is that applications and systems with their own and different authorisation different authorization structure can be integrated into one authorisation authorization scheme. Authorisations  authorization and the rules surrounding it can be managed centrally regardless of authorisation of authorization mechanism of the applications themselves. This phenomenon is called externalisation. XACML is derived from SAML and provides the underlying specification for ABAC (Attribute-Based Access Control). XACML is also suitable to be used in combination with RBAC (Role-Based Access Control).

Moreover, with the help of XACML authorisations XACML authorization can be arranged and managed in detail. This is called fine-grained authorisation authorization . XACML supports the use of security labels, rules with arbitrary attributes, rules with a certain duration and dynamic rules.

In XACML two main functions can be distinguished. One function defines the criteria with which authorisations which authorization are assigned, such as 'only an experienced user from department X is allowed to modify documents’. The other function compares the criteria with the rules or policies to determine whether a person is allowed to perform the operation on the object or not.

The architecture of XACML is fairly complex. This is partly due to the fact that it is difficult to fit the various components of XACML in the application landscape. These components should be positioned in such a way that the owner of the data can somehow control the authorisations the authorization to his or her data, but at the same time the components should be positioned in such a way that the performance is not negatively influenced. This is extra important when independent parties need to cooperate with each other and want to jointly organise the access to their applications. Finally, applications need to be compatible with XACML.