There's not much that compares to the thrill of creating a user in a parent application Cookie and seeing that username appear in the top right-hand corner on a Community Server page, especially when that user hadn't previously existed in Community Server.
Operation Custom Cookie Authentication Single Sign-On is now complete.
The Quest will continue with
ASP.NET Forms Authentication Single Sign-On, but first, the Field Notes on Operation Custom Cookie Authentication.
To review,
the Cookie Authentication Add-on integrates Community Server in a pre-existing site with its own authentication interface, without needing to create an account, register, or login again to Community Server. I created a parent ASP.NET application at http://cscookies and installed Community Server in an application directory at http://cscookies/cs.
I followed the directions
in the ReadMe, added the two DLLs and
installed the XML license in the CS Control Panel.
The next step was to update the communityserver.config file to provide it with information about the authenticating cookie that contained the user account information.
So if we look at the Cookie created in the http://cscookies Parent Application we see
HttpCookie userCookie = new HttpCookie("DomainUser");
userCookie.Values.Add("Name", tbUsername.Text);
userCookie.Values.Add("Email", tbEmailAddress.Text);
userCookie.Expires = DateTime.Now.AddYears(1);
Context.Response.SetCookie(userCookie);In our communityserver.config file we will specify that cookie information.
< add name="CustomAuthentication"
extensionType="Security"
type="Telligent.CommunityServer.Security.CookieAuthentication, Telligent.CommunityServer.SecurityModules"
allowAutoUserRegistration="true"
authenticatedUserCookieName="DomainUser"
usernameKey="Name"
emailAddressKey="Email"
useEncryptedCookie="false"
cookieValueStringFormat="Base64"
cookieValueEncryptionFormat="ValuesOnly"
/ >
Notice the items in bold. "DomainUser" is the name of the Cookie. "Name" is the key value for the username, and "Email" is the user's email address.
Okay, we can go to the Parent Application now and enter a user that doesn't exist in Community Server. Because we have allowAutoUserRegistration set to TRUE in the cs.config file, the user account will be created when we go to the Community Server application.
We create user "jose" and enter an email address, the two fields that are required for Cookie Authentication Single Sign-On. We click "Save Cookie" to create the cookie and establish our identity in the parent application. We'll "Display Cookie" to confirm (red arrow,) then click the "Go to Community Server site" where "Jose" will be created in the CS database and logged in.
THRILLIN'!
The only other bit of housecleaning I did was to change the address of the Login page, so that when a user clicked the "Sign In" link in Community Server they were directed to the parent application's "login" page (shown above.) This was a simple matter of changing the URL in the SiteUrls.config file.
< url name="login" location = "common" path="/default.aspx?ReturnUrl={0}" / >
< url name="login_clean" location = "common" path="/default.aspx" / >Now for a brief R&R and we'll hit it again with ASP.NET Forms Authentication Single Sign-On, with the initial step being to create the parent ASP.NET app and a login page at http://csforms.
Stay tuned for our next exciting episode.
[tags: Community Server]