Fin Server

The Fin server, developed by the UC Davis Library, is a simple Digital Access Management System (DAMS) based on the Fedora Linked Data Platform (LDP). The server is meant to be:

• Standards Based - Although we are targeting fedora as a server, we have built a system with some plugable standards based services;
  • LDP - The Linked data platform (LDP) is a simple but powerful and pleasant framework. As much as possible, we leverage that platform and expect application developers to use that framework as well. We anticipate many specialized tools will be developed to access our DAMS data, and putting data into this server should not restrict other tools from accessing it.
  • WebAC - Fedora supports Web Access Control (WebAC) for authorization of information within the the LDP, and we use that same access control mechanism. Part of the fin server’s purpose is to define some best practices in how WebAC authorizations should be used for users and collection data.
  • JWT Authentication for the LDP - We have standardized on a JWT token-based authentication method for the fedora LDP and supporting services. We separate out the rest of the authorization fromthe LDP. The goal is to simplify adding additional authorization strategies. Alternative authorizations should not affect the default Fedora configuration.
• Extensibile - At it's core, the Fin server is just a set of applications and standard practices built around an LDP application. We want the DAMS to have a superset of the capabilities of an LDP, and we do not hide any LDP functionality from the general user. There are a couple of things to keep in mind.
  • Our goal is to allow the server to be extended with new services without modifications of the core services. Though we are using an extension method based on the Fedora [APIX] methodology as our strategy, currently,our extension system is not a one-to-one correspondence with the [APIX] standard.
  • Generic UI - Our implementation includes a server that provides a User Interface with some generic search and faceting features. The UI is built with web-components. This client works only with the exposed ElasticSearch and LDP APIs. However, it is very simple to build alternative interfaces on top of our setup, and use of this UI is not required.
• Docker Ready - Our implementation deploys as a set of docker containers, and we use that system in the development of our service extensions.

Service Configuration

The default configuration supports the following components that we think are required for a basic DAMS. These include authentication, a Linked Data platform, an indexing tool, index synchronization, and a UI. Since many digital assets include images, our default configuration also includes an IIIF service for images. Each of these components are created as separate containers in our Docker configuration. The overview figure shows these different components.

The short names correspond to the container names in our default docker-compose file. Each line in the overview indicates network connections in the docker environment. Also indicated are proxied requests from outside users, and MQ message passing based on Fedora activity.

One of the goals of our server is to provide access to the existing APIs tor various services. Therefore many requests to the server are simply proxy requests to the underlying components. For example, investigation of the Client shows that our client uses these API calls exclusively to interact with the server.

server

The server provides four components. First it provides the static web components that make up the client UI. Secondly, the server provides authentication. The server can either maintain a local set of users; or it can coordinate with an external authentication system. Currently, we have included CAS as our primary authentication mechanism. Regardless of the source of authentication, the server also maintains a list of what agents can access fcrepo (the LDP component) as an administrator, ignoring all webac controls on the system.

The server also proxies requests among the service containers. In the default configuration, the server forwards fcrepo and loris requests. With the fcrepo and loris components are built directly into the default server configuration.

The essync and loris services are components that are dynamically added to the system. The ideas are similar to the Fedora API-X specification. However, it differs from that implementation in a number of ways, 1) service switching is performed by the server container and 2) link headers for these services are provided by the server as well.

The server also provides a framing service. This service is a standardized method where LDP descriptions are transformed into application specific outputs. The service makes available generic frames to be applied to flattened JSON-LD files. This additional service is used, for example, to provide inputs for the elasticsearch service. It's also a mechanism for developing API specific interfaces.

fcrepo

The Fedora fcrepo component is the Linked Data Platform (LDP) for the DAMS. Once the server authenticates the user, insert, update, and access commands are used directly with the LDP. All access for the data is managed by the Web Access Control webac built into the LDP.

essync and elasticsearch

These two services combine to maintain a consistent index for the DAMS. The elasticsearch container is an unmodified standard container provided by the elastic search group. This provides search capabilities to the LDP. The essync container maintains the consistency between the LDP and the search index. Fcrepo and essync communicate via messages passed by fcrepo on insertion and update events. essync listens for these messages, and provides commands to elasticsearch to update the index appropriately.

loris

The loris service provides IIIF image server capabilties to LDP binaries of appropriate mime-types. This service is an API-X like addtion. This means the when the server starts, it adds this service as an extension. The server then intercepts requests to /fcrepo targeting this service, and instead redirects the service to the loris container. The request also includes a path to the original source of the service request. This container is a modified version of loris but otherwise includes other components of loris, like it's caching mechanism.

redis

Currently the only role of the redis server is to support user and admin lists for the server as well server session caching.

Standards and Best Practices

In addition to making an LDP server, a search index, and some associated services available, the fin server is also comprised of some decisions and best practices in terms of how data is organized and represented in the LDP. These include metadata standards, container organization, and access control methods. One thing to note is that because we make the full LDP protocol available, users are actually free to work outside these strategies. The goal here is to encourage experimentation on other ways to use the server. Also, we hope that parts of the services can be made available without need to implement every aspect of a DAMS.

Metadata Standards

LDP Organization

Collections are organized and maintained using the Schema.org specification and nomenclature. In addition, we have added some additional higher levels.

• Collections placed in the $R/collection, where $R is the fedora root(/fcrepo/rest by default) are the only collections included in the default client view. Our fin-example-repository]uses a BasicContainer of this, but it could also be a more complex method, like an LDP DirectContainer as an example.
• In addition to collections, we've added a $R/user area to provide a more open access for experimentation for certain users of the system.

Access Control

The fcrepo LDP includes partial support of the W3C Web Access Control. They currently support the Read and Write components. Our initial goal is to keep access control compartmentalized as much as possible at the collection level. Therefore, our basic setup is to provide a new set of access control rules for every new collection. In addition, group management will be at the collection level as well, and collection managers will maintain these setups without any special other permissions on the site. Other than that, we maintain one set of system access control for the other areas of the LDP.

Data Framing

One important component of the fin server is that it be designed for the ability to provide more specialized APIs to the data. That is, individual collections may have individual metadata,or required access points. Our system provides that in three ways. First we provide the ability to register new ProxyServices so that additional service links can be associated with certain data on the system. This allows a pretty open framework to build specialized services particular to a certain data set. In a similar manner, we provide hooks to the the MQ message passing system, so that new services can listen to all incoming events. The third method is a built in framing service. This service uses the JSON-LD Framing specification to reformat flattened metadata entries into more specific JSON representations. This is the service we use internally for reformatting and standardizing our elasticsearch index, but it could also be used to develop simple API extensions for other datasets.

Fin Command Line Tools fin-cli

Since programmatically, the majority of the import capabilities for the system are directly related to standard input of data into a the LDP, an important idea of the fin-server is that there may be more than one way that data will be entered. Since access control is handled within the fcrepo, any general purpose client for the LDP protocol should work, once a user is authenticated. The first set of data that we envision, however, are more related to the bulk import of existing collections of data. In this case we typically have an external source of metadata and associated data sets, and our workflow is simple in the sense of doing bulk imports into the system. To that end, we are focusing on command line tools that wrap basic HTTP commands with the fin authorization method, and then build from that to provide higher level interactions with the fin server based on some of the best practices that we've developed for our services. These tools are designed to be used in two methods. First, simple shell scripts can use these commands in order to create easy import from existing data sources. Second, the cli tools themselves are simple wrappers for a Node Client Library. This library can also be used as the start of new applications designed to interact with the services. These tools are maintained in the fin-cli and fin-node-api github repositories. See the fin-cli for installation instructions and command descriptions.