Islandora starts with Drupal access, but leaves public derivatives and Fedora surfaces to verify
Islandora combines a Drupal website with repository storage and supporting services. Drupal presents the user experience and owns much of the repository object model, while Fedora can store binaries and metadata. The architecture creates useful separation, but it also means that a public Drupal page, a derivative file and a Fedora endpoint may not follow the same access rule.
On 2026-10-31, a count-only ZoomEye query returned zero matches for app="Islandora" and 28 for title="Islandora". The title query ran at 23:44:46 UTC and the application query at 23:44:45 UTC. Both used sub_type=all, page 1 and page size 1. Twenty-eight title matches are a modest sample. The zero application count may reflect a fingerprint gap, a branded Drupal page or a repository whose public title does not mention Islandora.
Islandora documentation recommends Drupal's access controls for repository objects. That is a good starting point, not a complete proof. The installation may generate derivatives into a public filesystem while the source object is stored in Fedora. A thumbnail or preview can be public even if the original file is restricted. Check the derivative policy for each media type and confirm that a public derivative does not reveal an object that should be private.
Fedora and the triplestore are separate control planes. Islandora documentation warns that anyone with access to Blazegraph can access all repository information in Blazegraph. Fedora should normally sit on an internal network, and its WebAC policies must be understood before they are treated as the primary enforcement layer. The default configuration may not rely on WebAC. Verify what the deployment actually enforces rather than what an optional policy could enforce.
Map the public entry points first. The Drupal site, search endpoint, IIIF image service, OAI-PMH feed, preservation exports and file downloads may be exposed under different hostnames. Use an authorized test account and an anonymous session to request the same object through each path. Record whether the response is a page, a metadata record, a derivative, an original bitstream or an error.
Role behavior needs a small but meaningful test matrix. A public visitor should see only published objects and approved derivatives. A depositor should manage objects they own without gaining access to other collections. A repository administrator may have broader access, but the administrative action should be logged and should not expose private content through a predictable URL. Test Drupal roles, collection membership and Fedora access together.
Maintain an inventory of Islandora components and versions. Drupal modules, Fedora, Blazegraph, Crayfish services and the message broker all have configuration and update responsibilities. A component that is not reachable from the internet still needs authentication and network restriction. A public site that has no obvious application fingerprint can still be discovered through a title, a repository link, a DOI or an embedded image service.
The 28 title matches are small enough that an owning organization can review every confirmed installation. The outcome should be a component map with a named owner, public exposure, authentication method and tested access path for originals and derivatives. Islandora can support a well-controlled digital repository. The security task is to ensure that every component tells the same access story.
Top comments (0)