1. Here are many unique business requirements and workflows that determine how new
people are registered at an organization. This blog will focus on a single, relatively simple
use case: an organization that uses password credentials, where there is a CMS that
manages content, an ecommerce platform that completes the sale, and active directory
single sign on. Let’s just say for the sake of argument that the CMS is Life Ray, and the
ecommerce platform is Magneto. So how could a person initially register in Life ray, and
then seamless access Magneto? Consider this diagram below:

2. One thing to note is that there is a database record for the person in each system–
LifeRay, Magneto, and the Gluu Server. But only one system holds the password–the
Gluu Server. The apps continue to use their local database as normal–the password is
not needed (except for authentication–which is now centralized).
So how do these user records get created? As with everything related to identity and
security, the answer is “it depends”. But here is one example where the CMS is used for
registration. The choice to use the CMS to register a person is common for many
consumers facing web applications–it enables the developers to present the exact look
and feel that they desire, and to use the development tools with which they are familiar.
Here are the steps:
Person fills out registration form on CMS
CMS validates the information (sends email, calls fraud detection APIs, etc)
CMS uses SCIM API of Gluu Server to add person (including the password) to the Gluu
Server LDAP database.

3. Now that the Gluu server has the user in the LDAP server, the CMS could either make
the person Login using OpenID Connect (Gluu Server) or a fancy alternative is to use
the password from the registration form to initiate the OpenID Connect session
behind the scenes.
Person browses CMS for a while… then person follows a link to Magneto
Magneto can detect that the person has already authenticated at the Gluu Server, but
Oh no! There is no database record for the person in Magneto! Dynamic enrollment
is needed. Magneto can present a form to the person to enter any information that is
not sent via the OpenID Connect id_token or it can simply use the information in the
id_token to create the local Magneto database record for the person

4. Voila!
The other consideration is logout. When a person ends his session in Life ray, how do
other applications find out that the session has ended at the OpenID Connect
Provider (the Gluu Server)? In the current Session Management specification,
JavaScript in the Magneto tab would detect that the session has ended, and would
notify the Magneto server (otherwise the Magneto session may exist on the server
until the person’s session is automatically timed out).
This approach allows the CMS to maintain control of Registration, and future proofs
the applications by ensuring that they no longer have to store local user credentials
or implement any other business logic for two factor security.
Article resource:-http://thegluuserver.tumblr.com/post/91117059024/simple-user-
registration-and-dynamic-enrollment-cms