Skip to content

Apache Marmotta Deployment Within HSLynk

Jump to bottom
Eric Jahn edited this page Apr 26, 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 control module called the Marmotta Access Layer (MAL) to receive client requests, verify authorization from the HSLynk Access Layer (HAL), and return (if authorized by the HAL) the requested resources of the LDP server to the client. 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's function could be described as follows:

  • MAL receives a client LDPR request with an OAuth2 token. The token was obtained by the client earlier directly from the HAL (using https://app.swaggerhub.com/apis/hslynk/hmis-authorization_service/1.0.0#/default/GET_authorize ).
  • MAL forwards the request onto HAL for a simple "accept" or "reject" determination (using standard HTTP Auth codes). HAL checks if a user has the necessary rights to access a resource.
  • If the HAL sends back an "accept" message, the MAL fulfills the request for the client, fetching the requested LDPR and transmitting it back to the client.

The actual pipeline can be split into two steps, 1) user requests access to HSLynk and 2) a user makes LDP requests to MAL

Getting access to HSLynk

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

LDP request

  1. A client requester makes an LDP request to MAL
  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 LDP action component makes the LDP request to the LDP server.
  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, etc.
  6. MAL determines, based on these policy, role, 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 a request through the LDP server.
  8. MAL returns the LDP REST response to the external 3rd-party web client.

Future Improvements

A main feature that Mamotta Access Layer could bring to HSLynk is not only return resources based on HTTP requests access, but also in filter information to a triple-level. In other words, return resources that a user can query and filter results based on access restrictions.

In order to acomplish this. The actual LDP action component will need to change, adding the following behaviour (see the changes below).

  • 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, and This 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.

architecture

An example of the complete pipeline when filtering triples

future_example

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