Persisting Users to external database

[Katrien1]

I want to persist /home/users to a location outside of the AEM application. I read I could connect AEM to an external database so I assume that's a way to do this. But in that case my entire JCR would be external, and I suspect this might have performance issues.

Hence my question. Would it be possible to only keep user data (password and username) outside of the JCR. I would like to still make use of CUG for protected pages. So in other words, I am looking for a solution that won't disrupt too much any OOB user functionality.

Apologies if this question has been asked before, but I can hardly search the forum at the moment, I get blank pages returned.

Many thanks, K

[Jörg_Hoh]

Why do you want to persist user data outside of the repository? If you already have an external IdentityManagement system, which offers LDAP connectivity, you can easily attach AEM to it. Or if you already have a SSO solution. But I haven't seen a convincing reason not to have an IDM or SSO, but to place userdata outside of the repository.

Jörg

[Ove_Lindström · Accepted solution]

No, you don't have to persist the whole JCR. Connecting to a database is the same as connecting to a REST service. You just setup a data connection in a Java class, same as you do with any database connection, then read the /home/user info and push it into the database.

Then, if you change the user in the database, you still need to sync the information into /home/users. If you search for SAML integration or LDAP integration, that is basically what they are doing.

/Ove

[smacdonald2008]

As Ove suggests - you can open a connection to an external database like MySql. You can use a DataSourcePool. See this community article on how to do this:

http://helpx.adobe.com/experience-manager/using/datasourcepool.html.

[Katrien1]

Thanks everyone.

So if I use SSO e.g. using SAML, does all other functionality then continues to work as it does with users inside the JCR? So, e.g. can I still use CUG on protected pages? Will the OOB login component work? 

The reason for not having users in the JCR is because that would mean the JCR needs to live in our data tier within our company's infrastructure. Perhaps I should have made that clearer when I first asked the question. 

Appreciate if anyone can reply to above question. Many thanks.

Katrien

[Sham_HC]

jcbsktrn1 wrote...

So if I use SSO e.g. using SAML, does all other functionality then continues to work as it does with users inside the JCR? So, e.g. can I still use CUG on protected pages? Will the OOB login component work? 

The reason for not having users in the JCR is because that would mean the JCR needs to live in our data tier within our company's infrastructure. Perhaps I should have made that clearer when I first asked the question. 

Yes all functionality will work.   With SSO enabled you will have own login page & can redirect there. No need to use OOB login component. If you need to use need some customization based on your requirement & integration point. 

[Katrien1]

Ok, one more question on SAML, will the user still exist within the JCR as well? But without password?

[Katrien1]

Ok, I think there is some confusion. I am actually talking about SITE users, not AEM users. I don't want to store any user data of site visitors in the JCR. I think that's where maybe the confusion is. For security reasons in my company we don't want to store customer data / user data in the JCR. Anyone tried that before? I have managed to set up SSO for backend users, that's no problem. But that's not the problem I'm trying to resolve.

[Sham_HC]

jcbsktrn1 wrote...

Ok, one more question on SAML, will the user still exist within the JCR as well? But without password?

yes

[Jörg_Hoh]

OK, I got it. you want to store user information outside of JCR and do the authentication via SSO. And your question is, if you still can use the authorization features of CQ. Is that correct?

[Katrien1]

Yes I guess that's the correct question. But the user in this context is not an author, but a site visitor. So will authentication, protected pages, commenting (with username) still work. And how would that best be configured?

Many thanks

[Ove_Lindström]

It is not a big problem if you want to use an external authenticator and create your own connector. You can even store everything in the external system and have AEM go and ask for the information everytime (like a Kerberos authenticator).

However, storing the absolute minimum of information about the user in the JCR of your system would have the benefit of being able to utilize the built in functionalities that needs a Principal object that holds the information about user id, user name and group belongings. If you can create that in runtime from your Authentication Service, that is perfectly fine, but in most cases, just having the user "cached" in the JCR would be the best way to do it. No information that is not stored in the comments, profiles or any other type of user created content are stored there anyway so the Security department argument that "no information about the user may ever be stored in any place that is outside of our safe box" is, sorry about the french, pure bu...it. The trick here is to not talk about user authentication data but about the user as a content. The Principal that tells the system who you are and what you can do should be handled with care. The information from the Principal that is used to create content is public.

You get the difference??

/Ove

[deepankard86318]

Hi Katrien​

I know it has been 3 years since this question, but were you able to use CUG features of AEM after storing the users outside JCR and authenticating user from external database?  I have a similar requirement, will appreciate if you could provide some information in this direction.

Thanks