User management in MSM | Community
Skip to main content
J
Julio_Baixauli
Level 4
October 16, 2015
Solved

User management in MSM

  • October 16, 2015
  • 3 replies
  • 944 views

Hi masters!

 

I’m involved in a MSM (multisite mgmt.) project in AEM6.

We need to manage different users for each site. I mean, a registered user in siteA, cannot login to siteB. Also, if John Doe registers itself in siteA and siteB, the users have to be different (different passwords, different profiles, etc.). So, I don’t think this should be a permissions/roles issue.

The above means that we need to think in different functionalities to be reviewed/configured/customized (?), like these:

  • User registration (sign up)
  • User login (sign in)
  • Password recovery
  • Newsletter registration
  • …

We’ve reviewed the geometrixx examples, and we think these examples are suitable for one site (or shared users for different sites), but not for a MSM scenario (not-shared users).

The documentation about Identity Management [1] refers to geometrixx-outdoors pages, not to the underlying APIs, so it don’t clarify very much.

 

We would like to know the best approach to implement these requirements. Any idea, help, suggestion… would be very appreciated! Thank you very much!

 

[1] http://docs.adobe.com/docs/en/aem/6-0/administer/security/identity-management.html

This post is no longer active and is closed to new replies. Need help? Start a new post to ask your question.
Best answer by PaulMcMahon

In general I don't think the standard approach to user management is going to help you much with this use case, the system doesn't provide a lot of multi-tenancy support. You are correct that you will probably have create as custom components almost anything having to do with user data (all the things you listed and more). You can probably meet most of your requirements without too much trouble, however the requirements for different passwords across the different sites will be the biggest challenge. The system will not allow duplicate usernames - so once a username is created for Site A, a user on Site B would not be able to create a account with that username. 

Thinking about it your best bet might be to prefix usernames with a site ID. So the a user for Site A would have a user name that looks like sitea_john.doe@site.com. You'd have override pretty much every component having to do with user management to make sure that prefix got hidden from users but always got added before requests go to the back end. A lot of work and major customization but it might work. 

3 replies

J
Julio_BaixauliAuthor
Level 4
October 16, 2015

Any other point of view or more information about the proposed solution will be very appreciated!

Thank you very much!

P
PaulMcMahonAccepted solution
Level 8
October 16, 2015

In general I don't think the standard approach to user management is going to help you much with this use case, the system doesn't provide a lot of multi-tenancy support. You are correct that you will probably have create as custom components almost anything having to do with user data (all the things you listed and more). You can probably meet most of your requirements without too much trouble, however the requirements for different passwords across the different sites will be the biggest challenge. The system will not allow duplicate usernames - so once a username is created for Site A, a user on Site B would not be able to create a account with that username. 

Thinking about it your best bet might be to prefix usernames with a site ID. So the a user for Site A would have a user name that looks like sitea_john.doe@site.com. You'd have override pretty much every component having to do with user management to make sure that prefix got hidden from users but always got added before requests go to the back end. A lot of work and major customization but it might work. 

J
Julio_BaixauliAuthor
Level 4
October 16, 2015

Thank you very much Paul!

That was the first option that came to my mind. The major challenge will be the lack of documentation to engage this issue :-)

Terms & ConditionsAccessibility statement

Loading footer...