Jun 5
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.
Summary
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!
