Skip to content

Apache Marmotta Deployment Within HSLynk

Jump to bottom
Xavier Sumba edited this page Apr 23, 2018 · 35 revisions

Apache Marmotta is being evaluated as the mechanism by which we implement Entity Support within HSLynk. HSLynk, to support Linked Data (LD), will implement new components to talk with the data model used in LD, called RDF. In order to accomplish this, HSLynk will make use of Linked Data Platform (LDP). LDP is built on top of the principles of LD and describes the use of HTTP for reading/writing resources from servers that expose their resources as LD.

Some of the advantages that LDP bring are:

  • The use of a well-known data model: RDF.
  • URIs are identifiers.
  • Data can be extended and discovered, which means that it is also flexible.
  • There are a variety of serialization formats such as RDF/XML, Turtle, JSON-LD, etc
  • Support for RDF and non-RDF resources.

LDP Support

LDP uses containers (LDPC) to represent a collection of links to other resources. For example. the following figure illustrates the use of containers and resources (LDPR). First, we have a projects collection, which have the park and encampment entities. Next, an encampment might have temporary shelters, so a resource is also a container.

ldp

Architecture

The support of LD in HSLynk will need the implementation of a module to manage access and authentication to the HSLynk platform and the resources of the LDP server. For instance, Apache Marmotta is the LD server used. The interaction of HSLynk and the new LD components are illustrated in the following figure.

architecture

In general, the Marmotta Access Layer could be described as follows:

  • Authentication component checks if a user requesting a resource has a valid OAuth2 token.
  • Authorization action checks if a user has the necessary rights to access a resource.
  • An authorization request is in charge to make a request to the LDP server and filter resources in order to generate a response with only resources a user has access to.

The actual pipeline can be split into two steps, 1) a user request access to the LDP functionality and 2) a user makes LDP requests.

Getting access to LDP functionality

  1. An external third-party client (requester) asks for access to the LDP functionality to the HSLync Access Layer
  2. HSLynk Access Layer authenticates the user and returns an OAuth2 token to the requester, which is used to make LDP calls.

LDP request

  1. A user makes an LDP request
  2. The authentication component validates the OAuth2 token through the HSLynk Access Layer.
  3. HSLynk Access Layer returns to Marmotta Access Layer an access policy for the presented OAuth2 token. This policy has information of the type of requests a user can make, groups, roles, properties, etc. If the token is invalid, an HTTP 401 (unauthorized) status is generated.
  4. The authorization action component checks if the user is able to make the request (e.g. GET, POST, PUT, DELETE, etc.) based on the policy obtained. If the user does not has sufficient rights, an HTTP 403 (forbidden) status is returned.
  5. The authorization request component makes the LDP request to the LDP server and returns only the triples that the user has access to. These triples are filtered based on the policy obtained.
  6. The requester obtains the results of a call.

An example of LDP support

The following example shows the interaction for a user that has generated an OAuth2 token and is trying to get information about a park.

example

Full steps:

  1. LDP Authentication request from an external 3rd-party web client to HSLynk Gateway/OAuth 2 Server
  2. HSLynk OAuth 2 Server authenticates and sends back to the 3rd party web client an OAuth2 token they can use to make further requests (no HAL in this step; that comes later)
  3. 3rd party web client makes an LDP resource request with the OAuth2 token they just obtained, attached to it. LDP requests will have a projectId in the URI (eg GET /project/{projectId}/park/tree). There will be a LDP-BC for each /project/{projectid}
  4. LDP request gets routed to Marmotta Access Layer (MAL) for processing
  5. MAL gets from HSLynk Access Layer (HAL) the user policy associated with the presented OAuth2 token. HAL gives to MAL the project group, role, properties, etc.
  6. MAL determines, based on these policy, role, properties, etc. whether this user can make this kind of request (GET/POST/PUT,etc). [that is, MAL validates the request using the policy information]
  7. MAL make request through the LDP server.
  8. MAL filters the response based on policy information access.
  9. MAL returns the LDP REST response to the external 3rd-party web client.

Considerations

  • Access Control: Making sure a user can only see data from the project they are a member of (or also from projects sharing with their project). HSLynk already has a service allowing/disallowing this.
Clone this wiki locally