Thread: SSO and overriding AspDotNetStorefront.Global.Application_Authenticat eRequest

We are in the process of investigating including our implementation of the aspdotnetstorefront site within a single sign scenario (.NET SSO and Claims based STS). Our current 'store' itself does not use credit card information for purchase therefore therefore security compliance is less of an issue.

Our issue is with the fact that aspdotnetstorefront requires the User.Identity.Name to be a guid and our other websites, including a Community Server installation has this property set as the username string.

As the code which fires the Authenticate_Request method is located in the encrypted ASPDNSFApplication.dll (AspDotNetStorefront.Global.Application_Authentica teRequest) we are currently unable to investigate how the guid is set nor are we able to come up with any workarounds to allow SSO integration. We have tried to include a custom Authenticate_Request method however we are currently unable to prevent the default method from firing. Our ideal scenario is that we have User.Identity.Name set as a standard username string and apply some other logic that converts to a guid where the store code requires it.

If anyone has come across this issue or could provide any help on this matter that would be great.

In our latest approach we are using the AppEvents class to add code to the Application_AuthenticateRequest method as below. However, we still run into the problem of the encrypted method firing and causing further problems. Should this code work or are we missing something ?

void Application_AuthenticateRequest(object sender, EventArgs e)
{
HttpContext context = HttpContext.Current;

string cookieName = FormsAuthentication.FormsCookieName;
HttpCookie authCookie = context.Request.Cookies[cookieName];

if (authCookie == null)
{
return;
}

FormsAuthenticationTicket authTicket = null;

try
{
authTicket = FormsAuthentication.Decrypt(authCookie.Value);
}
catch (Exception ex)
{
//Log errors
return;
}
if (authTicket == null)
{
//Couldnt decrypt cookie
return;
}

FormsIdentity id = new FormsIdentity(authTicket);
GenericPrincipal principal = new GenericPrincipal(id, new string[] { });

try
{
//This should be replaced by function to get guid from alternative source
//
// string username = principal.Identity.Name;
// string guidstring = AspDotNetStorefrontCore.Customer.GetCustomerGuidFr omAlternativeUsername(username);
// Guid guid = new Guid(guidstring);
//

Guid guid = new Guid("68f77085-6c58-4cea-b79d-16ed2117157f");

Customer customer = new Customer(guid, false);
AspDotNetStorefrontPrincipal storeprincipal = new AspDotNetStorefrontPrincipal(customer);
context.User = storeprincipal;

}
catch (Exception ex)
{
//Log errors
return;
}
}

We are running into the same problem did you get any further?

We ended up creating an sub application that essentially handled the SSO login, created an authentication token that aspdnsf could understand and then shared the token via the 'same cookie name/same machine key' approach.