This article concerns a technical Integration between Centercode and an internal system outside Centercode control. Assistance from your IT team may be required.

This document should begin the conversation about moving to a User Authentication setup within your Community. Attached is a Visio diagram with notes that describe the process flow of each of our External Authentication methods. A Visio viewer can be obtained free from Microsoft at the following link:

Microsoft Visio Viewer

Note: This document describes a Centercode Enterprise Edition feature that can be enabled and configured within your Enterprise Edition Community. To configure User Authentications within your Community you will need to log in as a Community Manager and navigate to Community Tools > Settings > User Authentications.

We have three External User Authentication (EA) types available: Silent Authentication, Direct Authentication and SAML. Each of these types is described in more detail below.

Silent Authentication

Using Silent Authentication will allow you to bypass the Centercode Log-in screen altogether. If your system deems a user to have access to your Centercode Implementation then it may present a link or automatically redirect the user to the beta system. That redirection would send the user through the Silent Authentication Gateway with an access key generated either through a call to our web services or by your system, and once validated the user may enter to use the Centercode system just as they ordinarily would following log-in. From the end user's perspective, if they have the appropriate access, these processes occur invisibly.

Once a Silent EA is in place, Centercode can be configured to redirect users from the local Centercode log-in page to your log-in page including a return path and, if appropriate, a message key (for example: "Session_Expired"), entirely bypassing the local Centercode log-in system.

End-User Process:

User Logs In:

  1. Your system checks for 'Msg' messages that Centercode may have sent and acts accordingly.
  2. Your system checks for a 'Ref' reference address, and remembers the 'Ref' to be used when sending the User back to Centercode.
  3. User provides their personal credentials and your system validates the User as necessary; User enters your system.

For Higher Volume Implementations (User sent to Centercode Silent Authentication Gateway):

  1. Your system generates a one-time-use 'Key'.
  2. User is sent to the Centercode Silent Authentication Gateway and includes the Key and the Ref as necessary : http(s)://your_Connect_URL/loginsa.html?key=Your_one-time-use_key&ref=reference_address

Centercode Process Log-in Request:

  1. Centercode links to your server and sends the Key.
  2. Centercode receives Username, Email, First and Last Name of User and whether or not the Key is valid.

For Lower Volume Implementations (User sent to Centercode Silent Authentication Gateway):

  1. Your system calls the Centercode LoginKey Web Service and provides Username, Email, First and Last Name of User... the service returns a one-time-use 'Key'.
  2. User is sent to the Centercode Silent Authentication Gateway and includes the Key and the Ref as necessary: http(s)://your_Connect_URL/loginsaws.html?key=Your_one-time-use_key&ref=reference_address

Centercode Process Log-in Request:

  1. Centercode validates the OTU Key.
  2. Centercode validates Username, Email, First and Last Name of User.

- If valid, User enters Centercode.

- If invalid, User is sent back to your Log-in page with the appropriate 'Msg' Message.

What you will need to do on your side:

  • Create an HTML log-in page for your end users to use to log-in.

- This page needs to accept and remember the "Ref" parameter. This parameter will need to be repeated back to Centercode (/loginsa.html | /loginsaws.html) when the User is sent back.

- This page needs to accept and act on the following MSG parameters:

Session_Expired - This message can be triggered from anywhere within Centercode, and indicates that the end-user's Centercode session has timed out.

Session_Expired_Overload - This message can be triggered from anywhere within Centercode, and indicates that the end-user's Centercode session was release due to the server being too busy. This message can also be triggered while the Centercode server is being taken offline for an update.

Logged_Out - The end user opted to log out of the Centercode application. This was done by clicking on the 'Log Out Now' link or by choosing to log out from the 'Your Session Is About To Expire' message.

EAS_MISSING_KEY - This message was raised by the Silent Authentication Gateway (/loginsa.html). The Authorization Key is missing or is invalid.

EAS_MISSING - This message was raised by the Silent Authentication Gateway (/loginsa.html). This is a configuration error that indicates that there were no EA servers defined.

EAS_NO_NEW_TEAMS - This message was raised by the Silent Authentication Gateway (/loginsa.html). This is a configuration error that indicates that New User's default teams were not defined.

EAS_NO_USER - This message was raised by the Silent Authentication Gateway (/loginsa.html). The User was authorized by your system, but the user was not identified by your system.

EAS_NO_AUTH - This message was raised by the Silent Authentication Gateway (/loginsa.html). This message indicates that the User was not authorized by your system.

EAS_NO_AUTH_NO_USER - This message was raised by the Silent Authentication Gateway (/loginsa.html). This User was not authorized and was not identified by your system.

EAS_USER_ERROR_NOT_UNIQUE_USERNAME - This message was raised because your Implementation already has a user account that uses the provided Username. Username must be unique.

EAS_USER_ERROR_NOT_UNIQUE_EMAIL - This message was raised because your Implementation already has a user account that uses the provided email address. In most cases email Address must be unique.

EAS_ERROR_500 - This message was raised by the Silent Authentication Gateway (/loginsa.html). Your authorization server returned an error (HTTP 500). This type of error generally indicates that your script resulted in a source code error.

EAS_ERROR_404 - This message was raised by the Silent Authentication Gateway (/loginsa.html). Your authorization server was not found (HTTP 404/Page Not Found). This could be a configuration error.

EAS_ERROR_302 - This message was raised by the Silent Authentication Gateway (/loginsa.html). Your authorization server attempted to redirect the connection that was used to consume the Key and gather information about the end user (HTTP 302/Redirected).

EAS_MISSING_DATA - This message was raised by the Silent Authentication Gateway (/loginsa.html). This is a configuration error that indicates your authorization server was defined but Configuration is incomplete.

- If valid, User enters Centercode.

  • In cases where your side is generating the One Time Use Keys the following should be considered:

- Typically a GUID is used, but you can use an Encrypted and/or Hashed value. Centercode will repeat this key back to you, so Encryption Keys will not need to be shared.

- This Key needs to be unique.

- This Key should not be easy to guess... you should not use incrementing numbers or patterned key generation.

- This Key needs to be invalidated once the End User uses it. This is important in order to prevent End Users from repeating the URL used when they are sent back to Centercode.

- This key should expire after a short amount of time. Centercode will 'Consume' the key immediately after the user is sent back.

  • Create an interface for Centercode to redeem the Key.

- Centercode will send the Key back as a Querystring (GET) parameter using the same name. Your system will need to gather User information and invalidate this key.

- This interface will need to respond as if writing text to an End User's screen. This response will need to include whether or not the Key is valid, User's Username, Email, First and Last Name as defined for your 'User Authentication' configuration.

Security Considerations: It is very important that special care be taken to ensure the return links are not repeatable. If a returned key can be used more than once then it can very easily be bookmarked and shared. SSL should be required for all context changes between systems and wherever user credentials or used information is passed.

Major Benefits of Silent EA

  • It is possible for users to enter the Centercode system without being prompted to log-in. You will have complete control over when to request or re-verify a user's credentials.
  • You can present the end user with a more unified user experience by providing navigational links between Centercode and your other end user systems.
  • End users need only one user name and password for your Centercode implementation and your other online resources.
  • You can extend these capabilities through the use of the Centercode Web Services. For example, you can detect whether or not a user is actively using the Centercode system, gather a list of Projects to which a user has access, or submit Feedback on behalf of the user from your external systems.

Drawbacks of Silent EA

  • Centercode no longer has access to end user credentials. This can affect some Centercode functionality, such as User Agreement Notices (commonly NDA Agreements), and can affect compatibility with third party download managers for Secure File Downloads. Use of Silent EA can be combined with use of Direct EA, which allows you to regain some of this functionality by using both in tandem.
  • Customization or development may be required to implement this with your other systems.

Direct Authentication

Using Direct Authentication end user credentials can be provided directly to Centercode as if users were logging in with a local Centercode user account. Centercode will look first for a matching local user account, and if appropriate will relay the user's credentials to your site for approval. In response to that approval request Centercode expects back the user's First Name, Last Name, Email and User Name, along with whether or not they have access to the system. If that information is returned and they are determined to have access to the system, the user is allowed to enter the site.

End-User Process:

User Logs In:

  1. User provides their personal credentials directly to the Centercode Log-in screen.

Centercode Processes Log-in Request:

  1. Centercode connects to your server and sends the Credentials it has received from the End User.
  2. Centercode receives Username, Email, First and Last Name of User and whether or not the Key is valid.

- If valid, User enters Centercode.

- If invalid, User is sent back to Centercode Log-in screen with the appropriate message.

What you will need to do on your side:

  • Create an interface for Centercode to validate User Credentials.

- Centercode will send the credentials as a Form Post (HTTP POST).

- Your system will need to respond as if writing text to an End User's screen. This response will need to include whether or not the credentials are valid, User's Username, Email, First and Last Name as defined for your 'User Authentication' configuration.

Security Considerations: User credentials passed between systems can and should be encrypted. SSL should be used for all connections that are made between systems. With the Direct Authentication method, user credentials are provided to the Centercode implementation and then relayed to the external system, however Centercode never stores a plain text copy of the user's password.

Major Benefits of Direct EA

  • End users need only one username and password to access your Centercode implementation, as well as your other online resources.
  • Functionality within Centercode that requires direct entry of end user credentials will continue to work properly.
  • It is possible to extend the use of Intranet logins to your employees to simplify the Centercode experience for your internal employees.

Drawbacks of Direct EA

  • End users will be asked to log-in when they move from another of your systems to your Centercode implementation, even if they have logged in to your other resources recently.
  • Customization or development may be required to implement this with your other systems.
  • Special access through your firewall may be necessary if the external interface is not already publicly accessible.

SAML Authentication

Centercode supports basic SAML 2.0 authentication. Centercode will replace the local login page with your SAML based log-in experience for use when SAML External Authentication configuration exists. Alternately, for testing communities where only Internal accounts are externally authenticated, we can provide an "Employee Login" option in parallel to the standard Centercode login page.

In order to fully establish a SAML authentication configuration, we require your SAML Metadata providing the following 4 attributes:

  • Email Address (unique per account and required)
  • Public Alias / Forum Handle (to be used in collaborative spaces, should be publicly consumable)
  • First Name
  • Last Name

If any of the three non-required fields cannot be supplied by the Identity Provider system, it can be requested of the user upon their first entry into the system. Ex: If your system cannot supply a public alias, the user can supply it on their first login.

External User Authentications

In general each EA methods allow you to present a more unified experience to your end users, across many systems that you may provide. Some processes may need to be adjusted when shifting from using local Centercode user accounts to using an EA. For example, if you use multiple Sign-Ups in Centercode, you may need to use multiple EA configurations instead. Sign-Ups are tools within Centercode to create Centercode User Accounts. After moving to an EA system Centercode may no longer be responsible for the creation of those accounts. Other user management processes will need to be thought through before implementing a change on this scale.

Major Benefits of each EA Methods

  • End users have one username and password, rather than multiple.
  • From your external systems, you have control over which users are granted access to the Centercode system.
  • You can keep track of which users are Centercode users, which can be very helpful when integrating with other third party systems that are only appropriate for Centercode users.

Drawbacks to each EA Methods

  • May require co-operation with your IT to set up, and scheduling time with Centercode staff, your group, and your IT department may be difficult. Centercode does not necessarily have access to your existing user base to complete this integration.
  • Possibility of abandoned user accounts. If, for example, this integration is linking users between systems solely by their email address, it would be possible for a user to change their email address in your system then log-in to the Centercode system resulting in the creation of a new Centercode user account... abandoning their existing participation. This can be fixed by a Community Manager after the fact by Merging both user accounts together. This issue will need to be addressed while planning the use of an external authentication integration.
  • Possibility of assumed user accounts. If, for example, this integration is linking users between systems solely by their email address, it would be possible for a user to change their email address in your system to an email address that was previously used in the Centercode system, then log-in to the Centercode system resulting in assumption of that existing Centercode user account... gaining access to existing participation that may or may not be their own. This issue will need to be addressed while planning the use of an external authentication integration.

Note: It is very important when planning these integrations to ensure the systems match on a value that is consistent -- or if linked information is changed at the source Centercode Web Services are called to reflect the change on the Centercode side.

Did this answer your question?