Cloud Connected

"I have been searching for a product like Cloud CMS for over 10 years.

After false starts with some typical content management solutions, we were finally able to design the content repository that our business required."
James Baddiley
James Baddiley, CEO

Users, Identities and SSO with Cloud CMS

One of the really interesting use cases for Cloud CMS is that of maintaining users across multiple domains while having those users share a common identity context.  

A common identity context allows an authentication session to transition seamlessly (via an authentication swap) from one user to the next.  It also allows for properties (such as username, email, password or other custom user properties) to automatically synchronize across all of the user identities that are part of the context.

Here’s an example of how this is useful.

Let’s imagine that you run a platform that services educational institutions.  You might have hundreds of colleges, universities, test facilities and more.

To keep things simple, let’s imagine you have 4 colleges.  Each college has students, professors and administrators.  Some professors teach at other colleges.  And some students are enrolled in classes at other colleges as well.

For each college, you provision an application that lets the college administrators manage the students, professors and content for the education experience.

Since each college wants to have its own isolated user store, you provision each college with its own Domain.  The domain holds the users just for that single college.  Therefore, you have 4 domains.

Also, since each college wants to have its own content repository, you provision each college with its own Repository.  The repository holds content, rules, metadata and ACLs for that individual college.  Therefore, you have 4 repositories.

We also have a common Directory that we maintain for all of the colleges. A Directory is a place where we retain the credentials (or Identities) of any users.  We can have a single Directory or multiple - here we keep it simple and just have a single one.

The structure might look something like this:


When a student, professor or anyone else signs up using our college application, they get an account within that college’s domain.  All of the content they create goes into that college’s repository.  Thus, we have a nice clean separation of security context and content.  Each college can have a separate backup schedule to Amazon S3, independent ACLs and unique and efficient indexing for all of their underlying MongoDB collections.

Let’s imagine we have three students (U1, U2 and U3).  Each student takes classes across the colleges.

  • U1 signs up for College #1 and College #2
  • U2 signs up for College #2 and College #3
  • U3 signs up for College #3 and College #4

When the user signs up, by default, Cloud CMS will create a single Identity for each sign up in the common Directory.  In other words, if User #1 signs up for College #1 and then signs up for College #2, they essentially have two separate accounts with two separate usernames and logins.

This might be what you want.  However, this puts the burden on the user to remember their username and password for each college.  A few questions…

  • What if you wanted Single Sign On (SSO) so that a user logged into College #1 could seamlessly transition to College #2?
  • What if you wanted separate logins but a common user profile so that a change to User #1’s profile for College #1 auto-updated their profile for College #2?
  • What if you wanted a single username/password for the user across all colleges?

Fortunately, with Cloud CMS, you can take advantage of a clean separation between Identity, Identity Policies and Users to achieve any of these.

Shared Identity

One of the quickest solutions is to have your users share a single Identity. While Cloud CMS creates a single Identity by default for your users, you can also tell Cloud CMS to have two or more users on different domains share a single identity.  That way, they’re both signing in using the same credentials.  Furthermore, a shared identity allows for SSO between the two users who share the identity.

Common Identity Policy

Cloud CMS lets you achieve even greater control for identities through use of Identity Policies.  You define an Identity Policy and attach it to one or more Identity instances.  The Identity Policy lets you specify more astutely how synchronization across identities and users should occur.  You can specify things like:

  • Exactly which user fields should be synchronized for all users whose identities are part of the policy
  • Whether the password should be synchronized across all identities that are part of the policy
  • Whether the identities that are part of the policy should be able to swap their authentication

It looks a little something like this:


With Identity Policies, you can set things up so that a user logged into College #1 will have the same profile and login information as when they try to log into College #2.  And through swappable authentication, clicking over to College #2 is seamless - the user’s authentication works without the need to log in again.


Cloud CMS offers flexible and configurable data stores that let you address the needs of complex multi-tenant and multi-user scenarios.  Unlike other legacy CMS systems, Cloud CMS was designed on top of AWS in such a way as to let you instantiate as many data stores and services as you need for your exact application design.  This lets you provide ease-of-use for your end users while giving you a solid infrastructure for managing their data.

We invite you to check out Cloud CMS.  Register for a free trial or sign up for our newsletter.  We’d love to get to know you!

Easy Forms with Cloud CMS

Cloud CMS lets you easily design and deploy forms for your web applications and content contributors.  In this blog entry, we’ll walk through how you can do this within the Cloud CMS Administration Console.

In this example, we’ll create a form that allows parents to register a child for a summer camp.

Add a Definition

We begin by telling Cloud CMS what a registration is.  This is a bit like defining a word in the dictionary.  We will define a “registration” and tell Cloud CMS what schema it should have.  The schema describes the properties, types, constraints and structure of the content.

When someone fills out the form, Cloud CMS can then capture the content and store it in a way that is searchable and reusable.

Within the Console, we go to our branch’s definitions and click New Definition.


We provide a few properties for our new definition including a qname which defines a unique key (kind of like a dictionary “word”) which is ours.

Now we define the schema of this definition.  Cloud CMS uses JSON Schema for content modeling.  The console provides a good JSON editor to make things easier.


This schema has 5 properties (event, name, birthday, phone and notes).  Some properties are required.  Others are not.  The event property is allowed to take on one of three values (“wobegon”, “music” or “arts”).

Now we save our definition.  Cloud CMS instantly compiles the definition with no server restarts and no downtime.  The console shows us that our definition is loaded up and ready to go.


Add a Form

So far, we’ve defined what a camp registration is.  That is to say, we’ve defined the model for a camp registration.  We now want to add a form that can be used to create new camp registration content instances.

Cloud CMS lets you have many forms for a single definition.  You might choose have one form for administration that shows all fields and gets down and dirty.  You might have another form that simplifies things, has a simple layout and is intended for parents to use on a web site.

Let’s create a simple form.  All we have to do is click on New Form.


We now provide some configuration for our form.  We can do many things here such as modify the layout, the placement of fields, plug in custom templates and configure different kinds of fields (or controls) for our field elements.

Let’s use the following configuration to customize the fields for our form:


As you can see, each field has been given a label and a type.  The type identifies which field control to use.  The Cloud CMS forms engine provides 31 out-of-the-box fields.  Here we use “select”, “text”, “date”, “phone” and “textarea”.

We now save our form.  Cloud CMS automatically compiles the form and brings it online.  The console tells us that our camp registration form is ready to go.


Create Content using our Form

Now we can create content using our form.  We can do this from within the console or from our own web applications.

In the console, we click Create Node and we pick our form.  The form is presented to us and we can begin using it.  Here is an example of our Camp Registration form partially filled out.  


Notice that Cloud CMS automatically fires validation logic for things like required files.  The Cloud CMS forms engine is very configurable and provides drop downs for selectors, date pickers, custom formatters and much more.

Learn More

In additional to content entry forms, Cloud CMS provides storage and reporting facilities for analyzing form submissions.  It provides the ideal low-cost, cloud-based backend for your business.

Interested in learning more?  

We invite you to sign up for a Cloud CMS free trial account.  It’s instant and without any pressure.  We’re ready to help you to build great apps.