Expand my Community achievements bar.

SOLVED

Need for internal users on publish instance other than Admin user

Avatar

Level 2

I am new to AEM.

I understand the need for user management on the Author instance. These users are internal users, i.e. their data is stored in JCR and login etc. functionality is provided by AEM itself. They are the content authors, DAM administrators etc.

Now on the publish instance we do need users like admin etc. for any configuration or related tasks. But should we make site visitors internal users of AEM publish instance by using the UserManager API. I don't see any purpose for this. If I want any user management related functionality in my web application, then I should not store my user data in the JCR right?

I should use an external database for this and validate the login credentials against this database, like we would normally do when making a web application without AEM.

1 Accepted Solution

Avatar

Correct answer by
Community Advisor

Hi @uroojkhan 

In general, there's no need to having users/group on publisher. Even for configuration related task, it shall be done via code instead of manually accessing and changing over publish instance. 

Coming to not allowing direct access of content over publish instance - there's something called Closed User Group (CUG) that you can implement in order to not allow open access of pages/assets.
Ref: https://experienceleague.adobe.com/docs/experience-manager-learn/assets/advanced/closed-user-groups.....



If you want to implement authentication on live website let's say you want user to show your profiles pages when they're logged in - in that case it depends how you want to implement authentication/authorisation mechanism. 

Usually, for live sites having restricted pages setup (e.g. user profile) have external database attached against which authentication happened and if that is successful (and if AEM pages are restricted over publish instance for anonymous access) then in same implementation class (code), an AEM user (who has access of pages) can be used to grant access to secured pages. 

To your query regarding storing user credentials in JCR (which are basically site users) -  those details we generally do not prefer to store in JCR. Instead use a dedicated database (may relational database) to store user details.

I hope it helps.

Best regards,
Himanshu Singhal

View solution in original post

1 Reply

Avatar

Correct answer by
Community Advisor

Hi @uroojkhan 

In general, there's no need to having users/group on publisher. Even for configuration related task, it shall be done via code instead of manually accessing and changing over publish instance. 

Coming to not allowing direct access of content over publish instance - there's something called Closed User Group (CUG) that you can implement in order to not allow open access of pages/assets.
Ref: https://experienceleague.adobe.com/docs/experience-manager-learn/assets/advanced/closed-user-groups.....



If you want to implement authentication on live website let's say you want user to show your profiles pages when they're logged in - in that case it depends how you want to implement authentication/authorisation mechanism. 

Usually, for live sites having restricted pages setup (e.g. user profile) have external database attached against which authentication happened and if that is successful (and if AEM pages are restricted over publish instance for anonymous access) then in same implementation class (code), an AEM user (who has access of pages) can be used to grant access to secured pages. 

To your query regarding storing user credentials in JCR (which are basically site users) -  those details we generally do not prefer to store in JCR. Instead use a dedicated database (may relational database) to store user details.

I hope it helps.

Best regards,
Himanshu Singhal