Simple User Registration and Dynamic Enrollment : cms + ecommerce

1
 Simple User Registration and Dynamic
Enrollment cms ecommerce

• 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. Lets 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 systemLifeRay,
Magneto, and the Gluu Server. But only one system
holds the passwordthe Gluu Server. The apps
continue to use their local database as
normalthe password is not needed (except for
authenticationwhich 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
applicationsit 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
persons 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-registrat
ion-and-dynamic-enrollment-cms