OSDB uses ACLs to protect access to its REST API and UI. When ACL protection is enabled, after authenticating through HTTPS, clients must provide a OSDB session cookie with each call. This is handled automatically by browsers. Non-browser clients must use a login API to capture the session cookie. The OSDB login API is described in OSDB REST API Documentation which includes sample Node.js clients for interacting with the OSDB login and REST APIs.
The resources to be protected are identified by URIs in a file
root.acl. An example
root.acl is listed below. Authenticated users, identified by their WebIDs, are granted access to specific resources via the
@prefix acl: <http://www.w3.org/ns/auth/acl#> . @prefix foaf: <http://xmlns.com/foaf/0.1/> . <#authorization1> a acl:Authorization ; acl:agent <http://ods-qa.openlinksw.com:8896/DAV/home/nobody/cmsb_ex_webid_170223.html#i> , <http://ods-qa.openlinksw.com:8896/DAV/home/nobody/cmsb_ex_webid_170223.ttl#identity> ; acl:accessTo <https://osdb.openlinksw.com/osdb/ui/services.*> , <https://osdb.openlinksw.com/osdb/ui/actions.*> , <https://osdb.openlinksw.com/osdb/api/v1/services.*> , <https://osdb.openlinksw.com/osdb/api/v1/actions.*> ; acl:mode acl:Read .
The rules contained in
root.acl are read and evaluated each time an OSDB endpoint is accessed. Any changes to the file take effect immediately, without needing to restart the server.
The initial implementation of OSDB supports only one permission,
acl:Read. This suffices for protecting OSDB endpoints, including those using HTTP POST and UPDATE.
Public access to a resource is granted using
agentClass foaf:Agent, rather than
OSDB allows the use of regular expressions in place of resource URIs. This allows a regexp to identify a set of resources as the value of
acl:accessTo as opposed to having to identify each protected resource explicitly by its own URI. The regexp
https://osdb.openlinksw.com/osdb/ui/actions.* protects all paths which are descendents of
https://osdb.openlinksw.com/osdb/ui/actions/, for instance:
The effect of this regexp is to automatically protect all imported actions accessed through the UI. There is no need to update the
acl:accessTo list after importing a set of new actions by loading a service description. Likewise, the OSDB REST API is fully protected by two regexps.
Ordinarily, OSDB will enforce ACLs in accordance with the rules defined in
root.acl. ACL protection can be disabled entirely by starting the OSDB server with the command line option
The OSDB server,
osdb_server, supports logging to the console and to a file
osdb.log. The logging level is controlled by a
-l startup option:
-l, --loglevel [info, verbose, debug] Log level (default: info)
-l debug emits the most detailed debug output and dumps some data structures.
-l verbose logs function calls but not data structures. Either log level traces OSDB's WebID authentication process.
info: OSDB server info: Server URL: https://localhost:8000 info: Service registry: http://localhost:8896/sparql verbose: ServiceRegistry#get_service_descriptors verbose: ACLChecker: Is an agent allowed Read access on https://localhost:8000/osdb/ui/services ? verbose: ACLChecker: Checking if ACL file root.acl exists verbose: ACLChecker: Read access NOT permitted to anonymous user verbose: ACLChecker: ACL file found but no matching policy found verbose: ACLChecker: Authentication required verbose: GET /osdb/ui/login verbose: GET /osdb/login verbose: #authenticate_using_web_id: verbose: CN: Carl Blakeley , SAN: URI:http://ods-qa.openlinksw.com:8896/DAV/home/nobody/cmsb_ex_webid_170223.html#i verbose: #authenticate_using_web_id: delegator: verbose: #ui_authentication_cb: Identified user: http://ods-qa.openlinksw.com:8896/DAV/home/nobody/cmsb_ex_webid_170223.html#i verbose: ACLChecker: Is http://ods-qa.openlinksw.com:8896/DAV/home/nobody/cmsb_ex_webid_170223.html#i allowed Read access on https://localhost:8000/osdb/ui/services ? verbose: ACLChecker: Checking if ACL file root.acl exists verbose: ACLChecker: Read access permitted to user: http://ods-qa.openlinksw.com:8896/DAV/home/nobody/cmsb_ex_webid_170223.html#i verbose: GET /osdb/ui/services verbose: GET /osdb/logout
In additional to standard WebID, OSDB supports WebID+TLS+Delegation (WTD). WebID authentication with delegation allows a user accessing an OSDB resource to delegate identity authentication to an intermediary software agent identified by its own WebID. The benefit of authentication using delegation is that it requires only one certificate, for the software agent. The delegates/users being authenticated require only their own profile document, not a personal public/private key pair. Without delegation, WebID authentication requires each user to have their own key pair. For a large user base, this presents a signficant security and administrative overhead.
The semantics of this kind of delegated identity authentication are expressed through reciprocal relationship types
oplcert:onBehalfOf represented by RDF statements stored in WebID profile documents of users and software agents. WTD configuration for OSDB, as regards profile documents and certificates, is similar to that for Virtuoso. For a detailed explanation of WTD, albeit in the context of Virtuoso, please refer to: