Authentication¶

The LinkedDataHub UI supports two authentication methods:

• WebID-TLS using TLS client certificates
• OpenID Connect using Google or ORCID

See how those authentication methods can be configured or how to get an account on LinkedDataHub.

Access control¶

All HTTP access to documents is subject to access control. Requesting a document with insufficient access rights will result in a 403 Forbidden response. That means either:

• the user is not authenticated and public access to the document is not allowed
• the user is authenticated but the associated agent does not have an authorization to perform the action on the requested document

Content negotiation¶

LinkedDataHub implements proactive content negotiation based on the request Accept header value. The following RDF media types are supported:

The same document, negotiated as N-Triples:

GET /products/1/ HTTP/1.1
Host: localhost:4443
Accept: application/n-triples

HTTP/1.1 200 OK
Content-Type: application/n-triples
ETag: "1e635b4-ntriples"

<https://localhost:4443/products/1/#this> <https://schema.org/name> "Chai" .
…

Error responses¶

LinkedDataHub provides machine-readable error responses in the requested RDF format. An example of 403 Forbidden:

@prefix xsd:  <http://www.w3.org/2001/XMLSchema#> .
@prefix http: <http://www.w3.org/2011/http#> .
@prefix sc:   <http://www.w3.org/2011/http-statusCodes#> .
@prefix dct:  <http://purl.org/dc/terms/> .

[ a http:Response ;
    dct:title "Access not authorized" ;
    http:reasonPhrase "Forbidden" ;
    http:sc sc:Forbidden ;
    http:statusCodeValue "403"^^xsd:long
] .

Hypermedia¶

Responses describe their context in Link headers (RFC 8288), so a client discovers the endpoint, the ontology or the administration dataspace from the response instead of constructing their URIs. All the links are folded into a single Link header.

On a proxied response the local relations are left out and the remote resource's own Link headers are forwarded instead, which is how federation finds the remote SPARQL endpoint; acl:agent is kept, since it describes the request.

curl -k -I -E cert.pem:password https://localhost:4443/

Caching¶

GET and HEAD RDF responses from the backend triplestores (not LinkedDataHub responses) are cached automatically by LinkedDataHub using Varnish as an HTTP proxy cache. You can check the age of the response by inspecting the Age response header (the value is in seconds). Anonymous SPARQL queries are cached too, on their body.

LinkedDataHub sends ETag response headers derived from a digest of the document's URL and its RDF content. Every representation (HTML, RDF/XML, Turtle, etc.) gets a distinct ETag value, and language-negotiated HTML representations factor the accepted languages into the tag. Treat the value as opaque: it is a validator to quote back in a conditional request, and nothing about the document can be read from it.

HTML responses carry a Content-Language negotiated against the languages the UI ships with, and advertise Vary: Accept-Language so shared caches keep the renderings apart.

Caching of LinkedDataHub responses can be enabled on the nginx HTTP proxy server by uncommenting the add_header Cache-Control directives in the platform/nginx.conf.template file. Caching of /uploads/ and /static/ namespaces is enabled by default.