Page Comparison

For most implementations, single sign-on is not necessary because CloudCard's secure login links provide excellent security with the least possible user friction, which increases user adoption.  However, in some cases SSO is required for IT compliance. 

Cloud SSO

CloudCard can implement SSO in the Cloud for most major identity providers including there are many use cases for which SSO improves the user experience.

For our A+ customers, CloudCard can deploy an SSO Connector in our Cloud for SAML2 identity providers which includes CAS, Shibboleth, and ADFS.  However, there are an associated implementation and annual service fees.

On-Premises SSO

Because CloudCard uses a stateless, token-based authentication protocol, implementing SSO on premises is relatively trivial. In most cases, CloudCard can provide an authentication connector for your organization to host on-premise.  All that is required of the customer is to load the cardholder data from the user session, database, LDAP, etc.  Estimated level of effort is 8-16 hours.

Displayed to the right is a simplified diagram of how a CloudCard SSO Auth Connector works.  The authentication connector is highlighted in red.  The exact implementation of a connector (i.e. PHP, JavaScript, ColdFusion, Java) depends on the customer's preferences.

Below an example of a connector is displayed in pseudocode to further explain the process.

/**
 * This connector should run on the server - NOT in a webpage
 * or any other client-side technology.
 */
const CLOUDCARD_API_ACCESS_TOKEN // CloudCard provides this

// cardholder data
var cardholder = {
  email : "",
  cardholderIDNumber: "" //optional; but highly recommended
  customFields : { //optional
    customField1 : "",
    customField2 : "",
    ...
    customFieldN : ""
  }
}

/**
 * This function loads cardholder data from the session,
 * a database, LDAP, etc.
 */
function loadCardholderData () {
  // this is written by the customer
}

/*** EVERYTHING BELOW THIS LINE IS ALREADY ***/
/*** WRITTEN AND PROVIDED BY CLOUDCARD ***/

/**
 * sends a POST request to CloudCard to request access for
 * the cardholder.
 */
function getLoginLink(var cardHolder) {
  // see Developer Docs: https://sharptop.atlassian.net/wiki/spaces/CCD/pages/74088466/Generate+a+login+link+for+a+user
}

var loginLink = getLoginLink (cardHolder)

// Finally redirect the user to the URL or return the URL
// to the view to be presented to the cardholder as a link
return loginLink;

Implementation Plan for On-Premises SSO

(Estimated level of effort is 8-16 hours.)

1. Inform CloudCard of your desire to host SSO on-prem and inform CloudCard of your prefered server-side technology, i.e. Java, C#, JavaScript, PHP, Python, ColdFusion etc.
2. CloudCard will provide you with a connector similar to the one described above implemented in your desired technology.
3. Request an API access token from CloudCard.
4. Install the connector on your webserver with hard coded values for the cardholder data and access token.
5. Test the connector with the hardcoded values.  Do not move on until the test is successful.
6. Implement the loadCardholderData() function (see pseudo code block above) and redeploy the connector to your webserver.
7. If desired, externalize the API access token in a configuration file.
8. Retest.

Process:

1. Install the metadata for our test SSO connector on your IdP.
2. Create a test login account for CloudCard Support
3. Securely communicate the following to CloudCard Support
   1. authentication credentials for the test login account
   2. the SAML attribute mapping for
      1. email address
      2. ID number*
      3. any custom fields if you want to provision or update users via SSO
4. CloudCard will configure the test SSO connector.
5. If applicable, CloudCard will request the creation the CNAME record that will point to the production SSO connector.
6. CloudCard will deploy your production SSO connector.
7. Install the production metadata in you production IdP.
8. CloudCard will conduct final testing and configuration.