EXTERNAL MODULE CONFIGS FOR AEM(LDAP)

In AEM authentication is one of the the important part, we will see few important specifics around OAK External Authentication framework  of which LDAP falls into.

The basic architecture representations of Authentication part build around OAK(Below diagram doesn't have External login module)

JCR Repository.login --> Oak Content Repository.login --> LoginModule.login -->LoginModule.commit 

Previously with jackrabbit, it used to be cumbersome and now it becomes easy with OAK through OSGI configs.
Oak LoginModule configuration all OSGI - no more jaas.conf.

Different Kinds of OAK Login Modules are as follows:

• AbstractLoginModule
• LoginModuleImpl(aka default login module)
• GuestLoginModule
• TokenLoginModule
• ExternalLoginModule

With External Login Module implementation digram should look like below as architectural scope:

In the OAK External Module flows something looks as below:

 In the above diagram

IDP : It is nothing but a proxy to authenticate with Third party system(for example LDAP).
         Provide profile information of external users and groups.

API highlights:  ExternalIdentity Provider
                            ExternalIdentity, ExternalGroup, External User
                            ExternalIdentityRef: It contains internal representation of external system. It also contains userInfo
                            SyncHandler: It is Used to Sync Users from IDP. It has two main properties.
                                rep:externalId: String representation of the external Identity Ref.
                                rep:lastSynced: It is used for expiration time tracking

Basic External Login Flows works as below listed:



With AEM 6 all LDAPS are configured via SYSTEM CONSOLE

Three OSGI configs that are required are as follows for LDAP to work is as follows:

1. An LDAP Identity Provider(LIP) 
     -  Used to define how users are retrieved from the LDAP server.
     -  It OSGI config with the  Apache Jackrabbit Oak LDAP Identity Provider can be identified.
2. A Sync Handler
     - It will define how identity Provider Users and groups will be synchronized with the repository.
     - Apache Jackrabbit Oak Default Sync Handler.
3. An External Login Module.
     - Apache jackrabbit Oak External Login Module
     - It holds the the definition of  which Identity Provider and Sync Handler to use.
  We may have scenarios like  where we may need configure multiple LDAP Configs for an AEM
  instance.

In AEM we can configure LDAP over ssl as well. If that is the case, we haver to make sure that SSL and TLS checkboxes are checked in LIP.

We even can create open SSL certificates. How to create and configure please refer citation link mentioned here.

Debugging is one of the important thing, when we ran into issues or to further understand issues or to trouble shoot. To enable debugging is as follows:

1. Go to the Web Management Console.
2. Find "Apache Sling Logging Logger Configuration" and create two loggers with the follwoing options:

• Log level: Debug
• Log File logs/ldap.log
• Message Pattern: {0,date,dd.MM.yyyy HH:mm:ss.SSS} *{4}* [{2}] {3} {5}
• Logger: org.apache.jackrabbit.oak.security.authentication.ldap

• Log level: Debug
• Log File: logs/external.log
• Message Pattern: {0,date,dd.MM.yyyy HH:mm:ss.SSS} *{4}* [{2}] {3} {5}
• Logger: org.apache.jackrabbit.oak.spi.security.authentication.external 

Citations:
 https://docs.adobe.com/docs/en/aem/6-3/administer/security/ldap-config.html
http://jackrabbit.apache.org/oak/docs/security/authentication/usersync.html
http://jackrabbit.apache.org/oak/docs/security/authentication/externalloginmodule.html
https://seminars.adobeconnect.com/p7th7m234c7/?launcher=false&fcsContent=true&pbMode=normal

Tagging mechanism in AEM

Taxonomy Root Node:

Generally all tags in the repository are stored in Taxonomy Root Node.

The taxonomy root node must be a node of type cq:Tag

In AEM base path is /etc/tags and root node of type cq:Folder

Tag Characterstics:

·       node type is cq:Tag

·       node name is a component of the TagID

·       the TagID always includes a namespace

·       optional jcr:title property (the Title to display in the UI)

·       optional jcr:description property

·       when containing child nodes, is referred to as a container tag

·       is stored in the repository below a base path called the taxonomy root node

Understanding of the Tagging structure in tabe format:

TagID	Namespace	Local ID	Container tag(s)	Leaf tag	Repository Absolute tag path
dam:fruit/apple/braeburn	dam	fruit/apple/braeburn	fruit, apple	braeburn	/etc/tags/dam/fruit/apple/braeburn
color/red	default	color/red	color	red	/etc/tags/default/color/red
sky	default	sky	(none)	sky	/etc/tags/default/sky
dam:	dam	(none)	(none)	(none, the namespace)	/etc/tags/dam
/etc/tags/category/car	category	car	car	car	/etc/tags/category/car

Moving and Merging Tags(Important point to be understood):

·       When a tag A is moved or merged into tag B under /etc/tags:

·       tag A is not deleted and gets a cq:movedTo property.

·       tag B is created (in case of a move) and gets a cq:backlinks property.

·       cq:movedTo points to tag B.
This property means that tag A has been moved or merged into tag B. Moving tag B will update this property accordingly. Tag A is thus hidden and is only kept in the repository to resolve tag IDs in content nodes pointing to tag A. The tag garbage collector removes tags like tag A once no more content nodes point to them.
A special value for the cq:movedTo property is nirvana: it is applied when the tag is deleted but cannot be removed from the repository because there are subtags with a cq:movedTo that must be kept.

·       cq:backlinks keeps the references in the other direction, i.e. it keeps a list of all the tags that have been moved to or merged with tag B. This is mostly required to keep cq:movedTo properties up to date when tag B is moved/merged/deleted as well or when tag B is activated, in which case all its backlinks tags must be activated as well.

·       Reading a cq:tags property of a content node involves the following resolving:

1.    If there is no match under /etc/tags, no tag is returned.

2.     If the tag has a cq:movedTo property set, the referenced tag ID is followed.
This step is repeated as long as the followed tag has a cq:movedTo property.

3.     If the followed tag does not have a cq:movedTo property, the tag is read.

·       To publish the change when a tag has been moved or merged, the cq:Tag node and all its backlinks must be replicated: this is automatically done when the tag is activated in the tag administration console.

·       Later updates to the page's cq:tags property automatically clean up the "old" references. This is triggered because resolving a moved tag through the API returns the destination tag, thus providing the destination tag ID

TAGGING API AND TAGGING FRAMEWORK:

Tagging Framework implementation in AEM allows management of the tags andtag conten using JCR API.

·       JcrTagManagerFactory - returns a JCR-based implementation of a TagManager. It is the reference implementation of the Tagging API.

           Ex: To retrieve a TagManager instance, you need to have a JCR Session and to    

                  call getTagManager(Session):

1 2 3 4

@Reference JcrTagManagerFactory jcrTagManagerFactory; TagManager tagManager = jcrTagManagerFactory.getTagManager(session);

·       TagManager -  allows for resolving and creating tags by paths and names.

Ex:  In the typical Sling context you can also adapt to a TagManager from         the ResourceResolver:

1	TagManager tagManager = resourceResolver.adaptTo(TagManager.class);

·       Tag - defines the tag object.

Retriving Tag Object

EX:  A Tag can be retrieved through the TagManager, by either resolving an existing tag or creating a new one:

1 2 3

Tag tag = tagManager.resolve("my/tag"); // for existing tags Tag tag = tagManager.createTag("my/tag"); // for new tags

For the JCR-based implementation, which maps Tags onto JCR Nodes, you can directly use Sling's adaptTo mechanism if you have the resource (e.g. such as /etc/tags/default/my/tag):

1	Tag tag = resource.adaptTo(Tag.class);

While a tag may only be converted from a resource (not a node), a tag can be converted to both a node and a resource :

1 2	Node node = tag.adaptTo(Node.class); Resource node = tag.adaptTo(Resource.class);

Basic customization steps, that should be done, when setting up AEM freshly for any organisation.

By default, when we first install AEM and run it, it will take us to projects.html or Content.html in Author and Publish environments. We can customize this to different paths, depending on organizational needs.

We can observe this in AEM content path  and  ConfigMgr  of  Felix console.
Under Content node properties, we can observe two properties sling:resourceType and sling:target, which will decide where it has to go.

• For sling:target property,  we can update the path on where it has to go.  For example, if we have a content package like content/xyzmobile and if we wanna redirect to that particular content, then update the sling:target with respective content package like /xyzmobile.

•  From the above step, the behaviour of the sling:resourceType with value sling:redirect will decide  and redirect it to value that was set with sling:target.  Go to ConfigMgr of the felix console and search for Day CQ Root Mapping and look for the target path and update according to your requirements.

   For ClientLibs:

           ClientLibs in AEM can be managed through Adobe Granite HTML Library
           Manager(Previously called as of Day CQ HTML Library Manager)

           the  OSGI configurations. There we can define the minification, packaging, library paths etc.. 

           This has to be set accordingly to the organizational level requirements.

                                                                                          (More points are coming up..)

Citations:
https://docs.adobe.com/docs/en/aem/6-3/deploy/best-practices/best-practices-for-queries-and-indexing.html
https://docs.adobe.com/docs/en/aem/6-3/deploy/platform/queries-and-indexing.html