Conflicting Authentication Systems

I am developing a site with a few different authentication methods. Because there are so many, I have been experiencing conflicts between them and the Sitefinity authentication mechanisms.

First, obviously, there will be Sitefinity CMS users to administer the backend.

Second, visitors to the site will be able to sign up for accounts. We are discriminating these users from Sitefinity admins by putting them into a different database table and accessing using a different MembershipProvider. This decision was made as a security precaution so that public users do not use the same authentication pieces as the Sitefinity admins.

Finally, visitors will be able to log into the site using the Facebook platform. This will actually be integrated with the second option so this is really authentication method 2.5 (as opposed to 3).

The problem is, I think, with the Sitefinity Madam Discriminators. My other providers wouldnt work unless I took out the madam pieces. Because of this conflict, my first reaction is to split out the admin pages on a subdomain like sitefinity.mysite.com. Then the Sitefinity authentication will run on the subdomain and the custom and facebook authentication will run on the main domain, mysite.com.

Will this work? Is it even a good idea to break out public users into a separate table? Is there something I am missing here that would make this integration go more smoothly? Thanks!

Hello Jeff,

Can you please let us know if your public users membership provider is implemented based on the Mircrosoft Membership Providers? If this is the case, please note we are going to release wrappers for providers which inherit from the Microsoft ones in order to be able to integrate external membership providers with Siteifnity.

Best wishes,
Radoslav Georgiev
the Telerik team

Yes. It is based off of the Microsoft MembershipProvider pattern. It isnt the default SqlMembershipProvider that comes from running aspnet_regsql.exe. I took the source code provider for the SqlMembershipProvider and made a few tweaks. Basically, I consolidated the Membership and User database tables and removed a few columns. Then I updated the source code for SqlMembershipProvider to reflect these changes. The customized provider still implements the base class methods and retains 100% of the functionality of the SqlMembershipProvider.

Would the upcoming wrappers also apply to my custom provider?

This was suppose to be done for the Q1 release on wednesday.

Now I see this posted with an hour ago time stamp, this has to be a mistake.

I am hopeful this is just the forum showing very old posts as current on this thread

Hello,

The wrappers will come with Q1 release. They are fully implemented to support ASP.NET Membership providers.

Greetings,
Ivan Dimitrov
the Telerik team

@Bill Nope. This isn't an old thread. I created it last week.

@admin Thanks! I'll pretend like those features were added in just for me :) I searched and browsed the documentation and I couldn't find anything about how to work with multiple MembershipProviders. Do you have a link to some documentation on the topic?

Upon further examination, I determined that there is something wrong with FormsAuthentication.SetCookie(...). I am using this in my provider. When I strip the web.config of any lines pertaining to Sitefinity, my authentication works fine. When I add them back in I see a problem. FormsAuthentication.SetCookie is called and the cookie is being set on the client browser. However, upon subsequent requests to the server, requests continue to be unauthenticated despite the presence of the .ASPXAUTH cookie being sent to the server. I attached a screenshot of the authentication token being set and sent. This is consistent with other working examples I have done.

I checked out Telerik.Sitefinity.Web.SintefinityHttpModule and I am guessing that SitefinityHttpModule.Context_AuthenticateRequest() could be interfering with my other authentication pieces; it looks like this method could be overwriting some of the HttpRequest's properties that - had they been left alone - would have allowed my authentication to work.

After a few more tests, I'm quite sure that in the SitefinityHttpModule.Context_AuthenticateRequest event handler is causing my issue. Before this handler is run, I confirmed that the HttpRequest was in the expected state. After this method, things are wrong (e.g. HttpContext.Current.Request.IsAuthenticated = false despite the presence of the .ASPAUTH cookie) My guess is that SecurityManager.AuthenticateRequest(currentHttpContext) is overwriting the request and causing my problem.

Basically what I am looking for is that if a request is authenticated through some other mechanism other than Sitefinity that, that Sitefinity will not disregard that fact and overwrite the Request. Does that make sense? Will the 4.1 update address this issue? Is what I am attempting not possible with SF? Should I abandon this approach and try to figure something else out?

Hi Jeff,

In SF 4.1 (or Q1) we fixed an issue with SitefinityHttpModule - the default ASP.NET HttpApplication was overwriting our SitefinityPrincipal with its RolePrincipal. We added an additional PostAuthenticateRequest event handler that replaces the context.User property with the right SitefinityPrincipal.

Could this solve your issue?

That sounds like it will. I'll upgrade to 4.1 and hopefully this will do the trick. Thanks so much!

Does anyone have a solution for this? I upgraded to 4.1 and it is still not working..as Jeff mentioned the cookie can be set, but further requests are NOT authenticated altough the cookie exists!

--- update -----

I was able to read the cookie, set
                       HttpContext.Current.User = currentPrincipal;
                       Thread.CurrentPrincipal = currentPrincipal;
with my custom GenericPrincipial in the global.asax

afer rediredting to the original page i got the follwoing error

************************** error *******************************************



I really want to get this working, because it is such a basic requirement to use existing user in a cms!

Pascal - I ran into this as well. I believe it is because Sitefinity is expecting the principal to be the custom one that Sitefinity loaded but it isnt since you overwrote it. So, when SF tries to access it later on, it produces the error you see. Basically what is happening is that .NET loads up the principal, then Sitefinity overwrites it with its own principal, then you are overwriting it again with the original principal again.

Personally, I have abandoned trying to do this. I'm sorry to say that none of the response I have gotten from Telerik seem to understand my situation. My workaround is that whenever someone authenticates with my provider, instead of setting the forms cookie, I store the authenticated user in Session. Subsequent checks to see if a user is logged in will be checking the Session and not the HttpContext principal. It's not ideal but it works and I dont want to waste anymore time on this.

Thanks Jeff!
I was also thinking of doing such a "hack", I can access the cookie and that indicates the user is authenticated, for later use of user related stuff i will store those information in session..
Do you make use of a custom role provider?
If i turn role Manager enabled i got an error in the backend, which says something like: i should not use windows token  role provider which in fact is not true I make use of an SqlRoleProvider.

Thank for any help and hints :-)