Single sign-on (SSO) is a property of access control of multiple, related, but independent software systems. With this property a user logs in once and gains access to all systems without being prompted to log in again at each of them. If you have an existing web application and want your members to access Communifire community without explicitly creating a registered account and logging in, then you need to use SSO.
You can use Single Sign-on (SSO) between domains, when you have different sites in two different sub-domains, but within the same second-level domain.
You can also use Active Directory for Single Sign-on (SSO)
Axero Cloud - Active Directory ADFS/SAML SSO
Self Hosted - Active Directory SSO
Follow the below mentioned steps in order to implement SSO in Communifire. Your existing website can be in any technology (PHP, Java, or ASP.NET) as long as it can create and support cookies. Note that your point of registration (creating new users) would be your existing application and you can use CF API to make sure that your new users are also saved in the CF DB (so that it is in sync with your existing app DB).
STEP 1. First check the CFSSOSettings.config file of CF installation directory ad find the <SingleSignOn> config section. If Enabled is set to true, then SSO is enabled, else it will be disabled (by default it is disabled).
Here is the detailed explanation of this section in the CFSSOSettings.config file:
NOTE: If you have set the option "Allow ONLY members to access the community?" from the cf-admin->manage general settings page, then guests will not be able to view the community unless a valid cookie is found (if SSO is turned ON) or they sign-up and become members.
STEP 2. Now configure your existing web application to create a cookie needed by CF for SSO. In this cookie write the user's username and email address (using key names as specified above in the config section). You have to change the name of the cookie to whatever name you set in CFSSOSettings.config in step 1 (it is set to CommunifireUser by default) and set its expiry date as per your requirements.
STEP 3. While creating your cookie, make sure that it has the Domain property set to the parent domain, for example, in our current example it would be set to:
cookie.Domain = ".existing-website.com";
You may use Communifire.Common.Security DLL to encrypt cookies in your own application (if you application is ASP.NET based).
STEP 4. Required for IE8 (cookie fix): IE8 needs the domain attribute to be set for the FormsAuthentication cookie in the CF web.config file. So set the domain attribute by editing the web.config file in the CF installation directory as follows:
<forms loginUrl="login.aspx" domain=".existing-website.com" path="/" />
This fix is needed only for IE8 as other browsers are able to handle the domain issue automatically.
STEP 5. Final step: make sure that the CFSSOSettings.config file in the CF installation directory has the same settings as the cookie you created.
Note: In cases where you cannot access Communifire.Common.DLL, please check the end of this page to see the wiki for using your own sncryption method.
//Create encrypted cookie
Communifire.Common.Security sc = new Security();
sc.PassPhrase = "externalcookie";
string encryptedUserNameKey = HttpUtility.UrlEncode(sc.Encrypt("CFUsername"));
string encryptedEmailKey = HttpUtility.UrlEncode(sc.Encrypt("CFUserEmail"));
string encryptedUserName = HttpUtility.UrlEncode(sc.Encrypt("USER_NAME_GOES_HERE"));
string encryptedUserEmail = HttpUtility.UrlEncode(sc.Encrypt("USER_EMAIL_GOES_HERE"));
HttpCookie cfCookie = new HttpCookie("CommunifireUserCookie");
cfCookie.Domain = ".your-exisiting-domain.com";
The page to which the community will be redirected to after login will be based on value of Community Homepage property in cf-admin->settings->general settings-> advanced settings tab.
If the value is MyAccount, user will be redirected to myaccount's default page else to the default landing page of the community.
If you encounter this error in the event log...
Event message: Forms authentication failed for the request. Reason: The ticket
supplied has expired.
... it means that the forms authentication ticket is not matching with the generated original value, a situation which may arise on a web farm deployment.
In fact the application uses “machinekey” definition to generate the authentication cookie. If “machinekey” properties are not initialized in the web.config file, the application uses different values on the different servers. This way when you have been logged in on server X and then try to login on server Y it may happen to use the cookie from server X which is different from the one that server Y uses. Then you cannot login.
Therefore machinekey properties must be always defined for applications that are moved from server to server.
This issue can often be caused by having auto-generated <machineKey /> keys in your server'smachine.config file. Each time your application starts afresh it will generate new keys. This invalidates any existing encrypted viewstate or forms authentication tickets.
Try setting the <machineKey /> validationKey and decryptionKey to fixed values. See the following link for more information: How To: Configure MachineKey in ASP.NET 2.0 (MSDN)
If you are working with HTTPS (SSL) your web.config's authentication tag should have requireSSL="true"
<forms loginUrl="login.aspx" requireSSL="true" />
is requesting access to a wiki that you have locked: https://my.axerosolutions.com/spaces/5/communifire-documentation/wiki/view/232/single-sign-on-sso