Cloud Connected

Thoughts and Ideas from the Gitana Development Team



 Newer Older 

Cloud CMS JavaScript Driver Release 1.0.3 is out!

Jul 4

The Cloud CMS team is pleased to announce the immediate availability of version 1.0.3 of the Cloud CMS JavaScript Driver for jQuery, Dojo, Javascript/HTML5 and Node.js applications.

Download today from http://github.com/gitana/gitana-javascript-driver.

JavaScript Driver for Cloud CMS

The Cloud CMS JavaScript Driver is a JS library that you can drop into your HTML5/JS applications to take advantage of the authoring and delivery APIs of the Cloud CMS server. It makes it easier for developers to utilize the Cloud CMS HTTP/REST APIs by providing native convenience functions via JavaScript.

The Gitana JavaScript Driver is ideal for use within either the browser or server-side JS environments (like Node.js). For a Node.js wrapped module, please check out: http://github.com/gitana/gitana-node-js.

What is Cloud CMS?

Cloud CMS is a cloud platform as a service for managing all of your business content - from formal business content like articles and news items to social content and interaction data coming from your applications. Cloud CMS puts all of your data into an innovative, high performance and scalable repository and gives your business powerful tools for collaboration, branching, merging and working with content with a secure and robust tools.

To learn more about Cloud CMS, please visit: http://www.cloudcms.com

Release Highlights

This release includes a number of highlights, including bug fixes and new features, which are worth mentioning. A few of the more important elements are shown below. For an itemized list of code level changes, please check the commit history.

  • Fix to map .each() iteration with nested property changes
  • Improved support for automatic application stack and data store caching
  • Preference for clientKey syntax (instead of clientId) (so as to be consistent with adjustments to Cloud CMS)
  • Support for application deployments, query and lookup via API
  • Fixes for missing clone() methods for proper type adherence on promise chaining
  • Improved ability to find stacks for contained data store elements
  • Added ability to specify parent and file paths on node creation and lookup
  • Enhancements to ticket based authentication
  • Support for HTML5 local and session based storage of OAuth2 credentials
  • Improved support for non-window (server-side) environments (like Node.js)
  • Better handling of OAuth2 credentials using refresh token
  • Support for Preview URIs (new feature in Cloud CMS)
  • Support for Identity Policies (new feature in Cloud CMS)
  • Support for partial tree loading (new feature in Cloud CMS)
  • Fix for miscalculated Application URIs

We encourage our community to upgrade to this new release of the Cloud CMS JavaScript driver. We encourage everyone to submit issues, pull requests or post questions to our forums at http://www.cloudcms.org.

To learn more about the Cloud CMS JavaScript Driver, please visit our open-source GitHub repository at http://github.com/gitana/gitana-javascript-driver.

Read more...

Users, Identities and SSO with Cloud CMS

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:

image

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:

image

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!

Read more...