Simple User Registration and Dynamic Enrollment : cms ecom

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. 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