OKTA SSO Integration

If you need to integrate OKTA SSO with AEM, you will need following things from the OKTA application-

1. IDP certificate
2. Single sign-on URL (also called IDP URL)
3. Okta Logout URL (If your application need to support logout)

OKTA Configuration

Below are the things which need to be done at OKTA side:
1. Go to Self service App for OKTA
2. Click on Register new application
3. Fill in required details. Below are few important fields which must be configured carefully-

• SAML Reciept: This is the returning URL to AEM  after successful user authentication in OKTA. This URL is generally in this format- https://youraemsitedomain.com/saml_login 
  
  It is Frequently found issue that this URL is not setup properly. So while trouble shooting validate that after successful authentication from OKTA user must return to exactly /saml_login page.  Validate this in SAML XML response too. No ending slashes or any other page. If user is not returning to /saml_login then there is an issue at OKTA side or at your web server side. In the most cases, correcting the SAML receipt URL at OKTA side fixes this issue. In worst case, check rewrite rules at your webserver if they are not screwing it up.
• SAML Audience: This is your AEM domain name. Example value- youraemsitedomain.com    Ensure no http or https or www.
• SAML Name Id: Use EmailAddress here.

AEM Configuration

Below are the key steps to configure OKTA SSO at AEM side:

1. Create certificate file
     Copy the certificate string in a text file and save it as idp_cert.cert in your local computer

2. Upload certificate in crx under path /etc/key using blow steps

• Go to crxde
• Create a node "saml" under /etc/key:

             jcr:primaryType- sling:Folder,
             idp_cert- Binary
        Save the node

• Double click on binary type for the property name "idp_cert" and upload the certificate file that was created in step 1 above.

     After step 2 - The node should look like this-

3. Now, Go to AEM admin console and navigate to: Tools > Security > Users

• Open user - "Administrator", Scroll down for Account settings
• Click on Create KeyStore, Enter a value for the password in both text boxes (Note down this password, this will be required to setup the SAML OSGi configuration)
• Click on Manage TrustStore. Click on Add Certificate from CER file
• Click on Select Certificate file, Navigate to idp_cert.cert file that you created in step 1 and uncheck Map Certificate to user
• Click on Submit.

   Screen should look like this-

   Note down the Alias Value on the left colum. This will be required to setup the SAML OSGi configuration.

4. At Tools > Security > Users

• Open user - "authentication-service", Scroll down for Account settings
• Click on Create KeyStore and provide the same password . Click OK. 

    This will initialize the Keystore and Authentication Service to use the certificate you provided earlier. On clicking manage trust store button on the same page, you can see your previously created certificate.

5. Configure Saml Authentication Service

• Go to /system/console/configMgr
• Open "SAML 2.0 Authentication Handler"
• Add required details

6. Configure the Referred filter

• On the System console configMgr, Open "Apache Sling Referrer filter"
• Add the Okta domain name e.g. "mysite.okta.com"

Other things you may need to setup this functionality is:

• Create new user group- for default user group configured in step 5
• Create CUG for the path (May be this can be skipped, as it worked for me without CUG setup)

This article is specifically articulated for OKTA integration. Refer the Adobe documentation  for integrating SSO with other SAML providers - https://helpx.adobe.com/experience-manager/using/aem63_saml.html

AEM6 | Export Users/ Groups with ACL Permissions

If you need to transfer users and groups in  AEM from one server to another or from one AEM instance to another then you need to create a package of users/groups along with rep:policy nodes. It is important to include rep:policy nodes as the permissions are stored at the individual target nodes instead of group/ user node. We need to Include all individual rep:policy nodes where you have given access to groups.

If users are included in the package then :
Add Exclude rule to users for token: /home/users/.*/.tokens

The Recommended option is to use acs-aem-commons tool to create a separate ACL package to migrate the ACLs. This utility picks the rep:policy nodes automatically so we don't have to worry about it.

Follow the below steps :

1. Create the ACL package as shown below -

2. Configure the ACL package

Once package is created open the ACL package page and configure it for groups and users definition.
While configuring package, it is important that you select all the principles i.e. users or groups which you want to export under "Principal Names". You can keep the "Include Patterns" field blank to ensure that all nodes which have rep:policy node are included automatically. You don't have to include them selectively because doing that may be cucumbersome and  there are chances you may miss few entries.

You need to check "Include principles" option if the selected principals do not exist in target environment otherwise you can keep it unchecked.

Set ACL Handling to overwrite (or Merge**)

**In case the "overwrite" does not work for you, try with "merge" option.

Now build the package and download.

Reference: https://adobe-consulting-services.github.io/acs-aem-commons/features/acl-packager.html

3. Install the package in destination AEM instance

Note :- I suggest to perform/ verify this in a test instance first. Ensure you take back of existing User/group definitions before you upload the package in destination AEM instance.

Troubleshooting: 

Once you have installed the package in destination, cross verify the users, groups and permission. Make changes in your filter definition in Step 1 as required if you see any issues and build/ install again.
In case the permissions does not reflect properly, check if you have given the permission at root level i.e. selecting the check all option at the top. Sometimes this give issue so instead of giving permissions at root level, give permissions at sub root level i.e. /content, /etc, /home, /libs etc.

Control component rendering in Touch UI Dialogs

RenderCondition comes very handy when you want to control rendering of your dialog. You can restrict display of field, button, tab etc. based on RenderConditions. I am going to take an  example of Carousel component where I will hide a tab panel from dialog to certain users. Consider the component dialog has two tabs- Carousel and List. Now to restrict display of one tab i.e. List to certain users who do not have "Create" access a certain path, perform following steps-

1. Go to cq:dialog component which you want to restrict for rendering, in this case go to - "/apps/myproject/components/carousel/cq:dialog/content/items/list" node

2. Create a new node "granite:rendercondition" of type "nt:unstructured"

3. Add following properties to this new node-
path- Type: String, Value: /content/mysite/en/homepage
privileges- Type: String, Value: jcr:addChildNodes
sling:resourceType-Type: String,Value: granite/ui/components/foundation/renderconditions/privilege

Another resourceType is - granite/ui/components/coral/foundation/renderconditions/simple which supports a expression property like this- 
expression="${param.item == '/content/mysite/en' || param.item == '/content/mysite/es'}" 
OR
expression="${granite:relativeParent(param.item, 1)== '/content/mysite'}" To ensure that just first level pages e.g. /content/mysite/en match the render condition.

Refer the screenshot below-

4. Save your changes. And go to useradmin console and revoke "Create" access on the following path- "/content/mysite/en/homepage". You can use regex also for the path value for pattern based matching as per your specific need.

5. Now go back to the page i.e. /content/mysite/en/homepage.html, Open the carousel component dialog, You should observe that the list tab does not appear to the logged in user as  the RenderCondition rule evaluates to false.

For more rendercondition options refer the link here-
https://developer.adobe.com/experience-manager/reference-materials/6-5/granite-ui/api/jcr_root/libs/granite/ui/docs/server/rendercondition.html