Monday, 17 December 2012

Drupal - Sharing Users Data between different Domains in Multisite Approach


1.       Backery Module to share User Data between different Domains :
a.       In Drupal, we have a module called "Backery" [http://drupal.org/project/bakery].
b.      It provides a "single sign on" feature for Drupal based sites that are on the same second-level domain (i.e. sample.com, developer.sample.com, community.sample.com).
c.       It also provides support for any other website that implements the same web cookie, xmlrpc, and POST methods.
d.      Backery works based on browser cookies for storing shared tokens.
e.      We couldn't share authentication between http://www.sample.com and http://www.sample-solutions.com. Because, those two will be treated as a different sites.
f.        Bakery is well-maintained and stable
2.       Services Module to share User Data between different Domains :
a.       In Drupal, we have a module called "Services" [http://drupal.org/project/services]
b.      It provides a framework for sharing Drupal data with other sites.
c.       It also provides mechanism for authenticating remote clients and granting those clients programmatic access to Drupal information.
d.      It will useRepresentational State Transfer (REST), provides an HTTP-based API (Application Programming Interface) to which other network programs can connect.
e.      It takes help of 2 other modules Services SSO Client [http://drupal.org/project/services_sso_client] and Services SSO Server Helper [http://drupal.org/project/services_sso_server_helper]
f.        It isbest way to share sign-in data between sites on a general multi-site configuration.
3.       Share User Database Tables: [http://drupal.org/node/22267]
a.       In this method all the Subdomains will use same User DB Tables [Shared tables. Which will be configured in settings.php of each sub domain]
b.      If we are going to take this approach, Upgrading is tremendously complex.
c.       There are lot of Security issues existed to use this approach.
d.      It is not a Recommended Approoach
4.       LDAP and other Directory Services: [Not a Recommended Approach]
a.       Using a local directory server or authentication service like LDAP, ActiveDirectory, CAS, or Kerberos.
b.      This approach is useful for large internal networks (like corporations and educational institutions), but is probably overly complex for a simple multi-site.
c.       One advantage in this solution is that accounts can be handled independently.
d.      But the disadvantage is that maintaining directory or authentication servers adds another layer of complexity to your configuration. Managing directory and authentication services is as complex (if not more complex) than managing a web server application stack.
5.       Open ID and authentication Services:
a.       In Drupal, we have a module called "Open ID" [Which is a Core Module in Drupal 7]
b.      This allows users to use a specific shared ID (an Open ID) and use it on many different sites.
c.       This same OpenID account can be used not only on your sites, but on other Internet sites that support OpenID authentication.
d.      If we use an external OpenID provider, we can enable and use the OpenID module.

No comments:

Post a Comment

Thank you so much for providing your valuable feedback. I will will look into them and update my skills & technologies accordingly.