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 both of our External Authentication methods (Direct and Silent). A Visio viewer can be obtained free from Microsoft at the following link:

Microsoft Visio Viewer

Note: This document describes a Connect 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 two distinct External User Authentication (EA) methods... Silent and Direct. Both integrations can use a web form HTML based system or a Web Service that accepts HTTP POST. Information sent is formatted exactly as if it were submitted by any common form found on the Internet ("application/x-www-form-urlencoded"). Information received is 'parsed' from the response that is returned from that request. Regular Expressions are used to parse the individual response fields and can be defined by a Community Manager within the Connect Community Settings UI.

Silent Authentication

Using Silent Authentication will allow you to bypass the Centercode Connect Log-in screen altogether, and instead provide one of your own. This shifts ownership of the affected accounts and their credentials to your central system. If your system deems a user to have "beta" access then it may present a link or automatically redirect the user to the beta system. That redirection would be made to a specific page on the Connect site and will reference a one time use access key that your system provides as well as a reference path representing the location within Connect that the end user should wind up on after successful entry. Connect will verify that the key is valid by making an HTTP post to your system behind the scenes. That behind the scenes check of the key expects the user's User Name, Email, First Name, Last Name and whether or not the user can be granted access. If that information is returned, and if they are deemed to have access they will enter the system from that point just as they do after log-in today. From the end user's perspective, if they have the appropriate access, this happens quite invisibly.

Once a Silent EA is in place, Connect can be configured to redirect users from the local Connect 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 Connect log-in system.

End-User Process:

User Logs In:

1. Your system checks for 'Msg' messages that Connect 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 Connect.
3. User provides their personal credentials and your system validates the User as necessary; User enters your system.

User to be sent to Connect Silent Authentication Gateway:

1. Your system generates a one-time-use 'Key'.
2. User is sent to the Connect 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

Connect Processes Login Request:

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

- If valid, User enters Connect.

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

What you will need to do on your side:

• Create a 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 Connect (/loginsa.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 Connect, and indicates that the end user's Connect session has timed out.

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

Logged_Out - The end user opted to log out of the Connect 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 inicates 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 inicates 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 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 E-mail address.  In most cases E-mail 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 inicates your Authorization server was defined but it's Configuration is incomplete.

• Create a mechanism to generate and save a Key that will be used to allow the End User to enter Connect.

- Typically a GUID is used, but you can use an Encrypted and/or Hashed value.  Connect 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 Connect.

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

• Create an interface for Connect to redeem the Key.

- Connect 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 Connect 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 Connect and your other end user systems.
• End users need only one user name and password for your Connect implementation and your other online resources.
• You can extend these capabilities through the use of the Connect Web Services. For example, you can detect whether or not a user is actively using the Connect 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

• Connect no longer has access to end user credentials. This can affect some Connect 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 Connect as if users were logging in with a local Connect user account. Connect 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 Connect 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 Connect's Login screen.

Connect Processes Login Request:

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

- If valid, User enters Connect.

- If invalid, User is sent back to Connect Login screen with the appropriate message.

What you will need to do on your side:

• Create an interface for Connect to validate User Credentials.

- Connect 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 Connect implementation and then relayed to the external system, however Connect 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 Connect implementation, as well as your other online resources.
• Functionality within Connect 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 Connect 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 Connect 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.

External User Authentications

In general both 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 Connect user accounts to using an EA. For example, if you use multiple Sign-Ups in Connect, you will need to use multiple EA configurations instead. Sign-Ups are tools within Connect to create Connect User Accounts. After moving to an EA system Connect 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 Both 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 Connect system.
• You can keep track of which users are Connect users, which can be very helpful when integrating with other third party systems that are only appropriate for Connect users.

Drawbacks to Both 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 Connect 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.