This section describes how security is mapped between Digizuite and Episerver.
Introduction
The API connection to the DAM is running the secure protocol (HTTPS). The username and password is what provides Episerver access to the DAM web services. If the user requires additional security, there are different possibilities to choose between, for example:
- configuring IP restrictions on the communications between Episerver and the DAM
- limiting the Episerver user in the DAMto only access content published to the Episerver channel.
Cache
There is an on-disk binary cache for images and documents, but not for videos. When a request for a specific assets is transfered to Episerver, the Content Data (metadata) is retrieved from memory cache (or if it doesn't exist fetched from the DAM) and the binary file is retrieved from disk-cache (or if it doesn't exist, from the DAM). The local cache can be cleared by one of the 2 methods:
- a "Time To Live" setting in the configuration
- by a scheduled job in Episerver that checks for changes in the DAM.
When a change happens in the DAM, it will clear the Episerver cache for that asset as well as send out a distributed event to other Episerver front-end servers (loadbalancing) so they can also clear their cache.
The only exception is video binaries, for which Episerver is acting as a pseudo-streaming proxy. It forwards the video requests to the DAM and then returns the data as a stream. It can be configured to redirect video streaming directly to the DAM, which in turn can utilize a CDN for the streaming in order to improve the performance.
Roles
In the configuration there is a mapping of DAM roles and Episerver roles. When a DAM asset metadata is returned to Episerver, there happens a real-time mapping of access rights. It means that only Episerver users with read access to the asset can see it (typically everyone), and only Episerver users with write access can edit metadata and upload new assets (typically editors).