AEM Asset Share Commons: Building Public Asset Portals That Scale
Public asset portals are a common requirement for organisations that need to expose curated media collections outside the firewall. Museums, government departments, sports bodies and media agencies all face the same problem: how do you make thousands of images and documents available to the public without giving them direct DAM access? For Adobe Experience Manager developers, the answer has matured into a reusable framework, and the full CIRCUIT agenda tracks working sessions where practitioners have shared their patterns for Asset Share Commons.
The framework is an open-source project on GitHub that ships as an AEM application layered on top of an existing AEM Assets implementation. It is not a licensed product, and there is no vendor hotline to ring at 2am AEDT. The codebase ships a reference site, search templates, download components and a permissive search API. Teams in Sydney, Melbourne and Brisbane have adopted it for tourism boards, university media libraries and federal press kits because it lets them reuse an existing AEM investment rather than build yet another bespoke microsite.
Why Off-the-Shelf DAM Access Falls Short
The natural first instinct when asked to "expose our assets to the public" is to share the underlying /assets.html URL or open up read-only access to the DAM console. That approach creates problems immediately. Folder structures designed for editorial workflows expose internal taxonomy, metadata schemas leak HR-sensitive fields, and CDN caching becomes a nightmare when every render depends on the requesting user's ACLs.
The framework flips the model. It treats the portal as a separate application that queries the asset repository through a search service, applies a curated metadata projection, and serves results through dispatcher-friendly URLs. Search is driven by predicates that authors configure, not arbitrary user input into the JCR query builder.
A second pain point often overlooked until launch is auditing. Public sector clients in Canberra frequently need to demonstrate who downloaded which asset, when, and under what licence terms. The reference implementation records download events through a reporting endpoint, which makes compliance conversations with the Office of the Australian Information Commissioner considerably less stressful.
The Pieces That Make the Framework Tick
The project ships with a small set of building blocks that compose cleanly. There is a Search component driven by a JSON model, a Results component that renders cards or list views, a Detail page for individual assets, and a Download endpoint that respects configured licensing rules. The licensing model itself is a content hierarchy under /content/dam/acs-commons/en/settings that defines allowed usage types, embargo windows and required acknowledgements.
For Australian deployments, the licensing step is often the make-or-break conversation. Agencies working with the National Archives or Screen Australia have obligations around Indigenous cultural rights and moral rights that the standard licence template does not capture. Teams usually fork the licence policy and add an extra acknowledgement predicate that requires the user to tick a checkbox before the download endpoint returns a 200.
Search predicates are wired through Sling Models and a Java service registry, so extending the codebase is straightforward for anyone comfortable with AEM. Front-end work happens in HTL, the templating language formerly known as Sightly. Because HTL is HTML-first, templates are easy to hand to a design agency in Surry Hills or Fitzroy without an extensive AEM knowledge transfer.
Building a Portal Workflow That Editors Can Run
The real value shows up when you think about the editor experience. Authors gain a metadata profile editor that lets them define which fields are searchable, which are displayed on the detail page, and which are required at upload time. They can also curate collections that map to specific landing pages without involving a developer.
A typical workflow for a state government looks like this. The communications team receives media from photographers across regional offices in places like Cairns, Ballarat and Launceston. Each upload is tagged with the photographer's name, location coordinates and licence terms. A collection editor in head office then assembles a "Tourism Campaign 2026" landing page by picking assets from a smart collection driven by metadata rules. When the campaign ends, the collection is unpublished without touching the underlying assets.
For teams already using Slack for daily stand-ups, the deployment notifications workflow is a useful companion pattern. Editors get a Slack alert when a portal page is republished, and the same webhook can notify a marketing channel in Brisbane time without anyone needing to log into the author instance.
Prerequisites worth ticking off first
A small number of baseline items need to be in place before any build starts, and the licence taxonomy is the one most often skipped. Australian teams working with the Audio-Visual Copyright Society need to think through whether assets are downloadable at all, watermarked, or gated by an email capture form.
- AEM 6.5 or AEM as a Cloud Service with the Sites and Assets modules provisioned
- A working Dispatcher configuration with caching rules that respect query strings, not just cookies
- A documented metadata schema signed off by legal, communications and asset owners
- An agreed licence taxonomy that maps to your jurisdiction's copyright requirements
Comparing the Built-in DAM UI with Asset Share Commons
The choice between AEM's stock /assets.html interface and standing up an Asset Share Commons portal comes down to audience, security model and search complexity. The comparison below summarises the practical trade-offs that came up repeatedly at CIRCUIT sessions.
| Capability | AEM Assets Admin UI | Asset Share Commons Portal |
|---|---|---|
| Primary audience | Internal authors and DAM admins | External public or partner users |
| Authentication | Mandatory AEM user with permissions | Anonymous or SSO via header auth |
| Search experience | Full-text JCR search across repository | Configurable predicates, faceted, brandable |
| Caching compatibility | Poor due to ACL-dependent rendering | Strong, designed for Dispatcher and CDN |
| Audit and reporting | Server logs only | Built-in download tracking and CSV export |
| Theming flexibility | Limited, admin UI constraints | Full HTL/CSS, design agency friendly |
| Best fit | Editorial production work | Public-facing media libraries |
For most public-facing requirements, the right column wins. The built-in DAM UI is excellent for the people who manage assets but unsuitable for the people who consume them. Trying to bend the admin UI into a public site usually leads to an over-engineered ACL strategy that breaks under CDN load.
Performance, Caching and the Real-World Gotchas
Performance is where the framework differentiates itself from a hand-rolled solution. Because every render is driven by a configured set of predicates, the dispatcher can cache aggressively. Search results pages typically have a TTL of several minutes, while detail pages can be cached for hours provided asset renditions do not change.
The gotchas are real, though. The first is selector misuse. Developers occasionally build query strings that exceed dispatcher limits when filter combinations grow. The second is asset rendition invalidation. If you change a smart crop policy on a parent folder, every cached detail page that references the old rendition needs to be invalidated, and the framework does not do this automatically. The third is timezone handling for embargoed assets, which can cause an asset to appear before its Australian release window if the server timezone is not pinned to Australia/Sydney or Australia/Perth.
Teams running on AEM as a Cloud Service get an easier ride because the platform handles cache invalidation through its CDN tier, but the framework behaviour is identical. Either way, a load test with a synthetic dataset of around 50,000 items is worth running before launch. Numbers above that expose slow predicates, and rewriting them as native Oak queries rather than JCR-SQL2 makes a measurable difference.
Integration patterns that save weeks
A handful of integration patterns have proven themselves across production deployments. Wiring these in early keeps the editorial team productive, and the WebDAV option is particularly useful for regional offices without bandwidth for the AEM web UI.
- Deep links from a public marketing campaign back to specific collection landing pages
- Embed widgets that surface a single asset on a third-party page using signed URLs
- Bulk upload from editors using WebDAV, similar to the workflow described in the CIRCUIT bulk upload guide
- Automated metadata enrichment from an external DAM or PIM through a Sling scheduled job
Where to Take It Next
The framework is mature enough that the first portal you build can be production-ready within a sprint or two, depending on design complexity. The fastest path is to clone the reference site, wire it up to an existing AEM Assets deployment, and customise the metadata profile and predicates to match your organisation's needs. Treat the licence template as a first-class deliverable rather than an afterthought, and engage legal early.
For teams looking to extend further, the recordings linked from the main conference archive include talks from AEM architects who have deployed the framework at scale in Australia and abroad. Watching two or three of those sessions before you start will save weeks of trial and error, particularly around the dispatcher configuration and the Sling Model patterns that drive custom predicates.
Pick a small pilot and get it live. A working portal in three weeks beats a beautiful spec deck in three months, and your stakeholders in head office and the regions will appreciate seeing real progress, fair dinkum.