How To Control Access With Closed User Groups in AEM Assets | Perficient Digital

How To Control Access With Closed User Groups in AEM Assets

Each year companies invest valuable resources into the creation of assets designed to grow their business. In an effort to protect these assets in instances such as new product launches or other sensitive materials, many companies choose to enforce a security policy to control access.  And in many of these instances, Adobe Experience Manager (AEM) Closed User Group is applied to the assets.

As shown below, in AEM 6.3 the permission option for assets is not available straight out of the gate, as shown below.

But don’t worry! Luckily AEM provides functionality to customize the console to accommodate the specific needs of your business.  In this post, I will give you step-by-step instructions on how to add permission gates to individual assets.

Step 1: Add a permission tab

Navigate to Tools > Assets > Metadata Schemas

Select “default” checkbox and open the editor by clicking on “Edit”.

Add a new tab titled“Permission” and click save.

 

Next navigate to CRX/DE, to /conf/global/settings/dam node. Here you will see the newly created permission tab as shown below.

Step 2: Add your CUG fields

You’re now ready to create the CUG fields, which is demonstrated below.

Once complete, you will see the permission tab with CUG fields when you open the individual asset editor page.

Step 3: Add the custom UI validation and saving logic

To accomplish this step, navigate to crx/de. Once there, create a folder structure as shown below.

Customasseteditor client lib should be of category “dam.gui.coral.metadataeditor” and have dependency with “granite.ui.coral.foundation” and “granite.shared”.

As per the business needs, you can have the custom business logic validation and UI experience logic in JS and CSS file and customasseteditor.jsp.

In the custom JS file, after having the custom UI validation logic, to save the CUG value on the asset add the below line,

$.ajax(Granite.HTTP.externalize(assetPath + “.cugpolicy.conf”), settings);

Where assetPath is data-formid from the form on the rendered page,

var assetPath = $(“#aem-assets-metadataeditor-formid”).attr(“data-formid”);

Step 4: Map the custom validation logic to CUG widget

It’s now time to map the newly created customasseteditor component to CUG widget.

Navigate to: /conf/global/settings/dam/adminui-extension/metadataschema/default/items/tabs/items/tab5/items/col1/items/cug/items/cuglist

Add the sling: resourceType to “dam/gui/coral/components/admin/customasseteditor”

Congrats! You’re now ready to use CUG’s on individual assets.

To validate this change, apply a CUG on the asset and navigate to the asset in crx/de,. You should see the newly applied CUG in the rep:cugPolicy node as shown below.

Note: If you are migrating from older version of AEM to AEM 6.3, the CUG model is different.  Check out my previous blog post for more information on that process.

Do you have tips for migrating to a new version of AEM? Comment below and share them with us!

Subscribe to the Perficient Digital Weekly Digest

* indicates required

Leave a Reply