Mixing forms auth and SSO/Windows Auth

I am in the planning stages and wondering if it is possible/what it would take to setup the following configuration:

1.
One URL (an internal only URL) has SSO/integrated windows auth setup,
so our content editors can seamlessly login without having to type a
user name/password.

2. A second URL (the public URL) has forms
authentication setup, so public users can create accounts and interact
with the site. It would auth against a SQL database.

I'm assuming this would need to be setup on two different URLs. I would be using claims authentication.

Just wondering what direction I would need to go to get this working.

Thanks!

Hi,

Backend and Frontend users are the same. We do not have such separation. One just has a different permissions set. If a user logs in on the frontenr and it has permissions to access the backend, he will be able to navigate to the Dashboard without problems.

Sitefinity cannot work in mixed mode. Authentication can be either Forms or Claims. The default mode for new projects is Claims. Upgraded projects will remain to work in Forms mode unless they are set manually after the upgrade.

More information could be found in our Sitefinity documentation.

Regards,
Stefani Tacheva
Telerik

So do you have any recommendations on how to have some users authenticating against Windows Integrated Active Directory and other users authenticating against a manually typed in user name and password?

It seems like I might need to code my own claims issuer that would:

1) Determine if the user is coming from an "internal" IP block and challenge their browser for credentials and then authenticate them against AD.

2) If they are coming from an external IP block, my issuer would provide a login form, let the users type a name and password, and auth them against a SQL database.

Does this sound like I am heading down the right road?

From reading the forums, it seems like this is a common scenario that prior to Sitefinity 5.x was accomplished by having multiple membership providers.

Thanks!

When we were on 4.4 and Windows auth wasn't supported,  Our workaround  (as suggested by Telerik at the time) was to have 2 sites which we synced on a schedule.  One with Windows auth that was strictly for front end browsing, and another with Forms auth that was strictly for content edits (aka 'staging system').  The only caveat to that is you then have to manage syncing of the two sites.  This wasn't a big deal for us, but I'm not sure what your exact requirements are.  Could something like that work for you?  One site with Windows Auth/SSO/Claims for backend edits and another with Forms auth for front end browsing?

Hi Jeff,

I am planning out our implementation and was considering the same approach that you outlined.

What did you end up doing to solve your problem? Did you end up implementing a custom claims issuer or did you do something else?

Vince,

No solution yet, still a work in progress. I opened a support ticket with Sitefinity and their response was roughly "haven't tried that yet.. might work.. let us know how it goes".

After further research, I'm thinking setting up a custom token issuer/STS may not be that difficult (I am going to try and use open source Techktecture IdentityServer. The bigger issue seems to be the Membership provider.

I was hoping to use two membership providers, the LDAP provider for internal users (who would auth off the Sitefinity provided STS ) and a SQL Membership provider for external users (who would auth off a custom STS/possibly IdentityServer). I'm not sure if this can be done with one site though, since the relying party config in sitefinity settings has a single parameter to supply the membership provider. Since I only have one site (and thus one relying party), I'm not sure if I can use two membership providers with one site.

The login form component in Sitefinity does have a parameter to supply the membership provider though, so that may be an avenue to get things working.

As I figure things out, I will post back.

Multiple membership providers aside, isn't the real issue not being able to have both Forms authentication and Claims based authentication enabled simultaneously?   I don't see how you could have one site that used either Claims or Forms... My understanding was you could use one or the other, but not both?

Mike,

That is true, but your ticket issuer is free to present a login form (or use other means) to authenticate the user. It's not using "ASP.NET forms authentication", but you can present the same end user experience using claims.

Gotcha... I'd be interested to hear what you come up with, particularly if you use Techktecture IdentityServer.   We've talked about using ADFS here, but I don't have much experience with that or similar offerings.  

Hi Jeff & BoaMike -

Jeff, I think you're headed down the same path as I am. Particularly, I plan to implement the LDAP provider for backend users (using the Telerik-provided STS (i.e.: SitefinityStsWebApp_6.1.4700.0.zip)) and a SQL Membership provider for front end users.

I realized this could be possible when I read this page:
www.sitefinity.com/.../creating-a-custom-membership-provider

And the short video that is posted on that same page (direct link shown below):
www.youtube.com/watch

Telerik's full explanation of how to hook it all up is here:
www.sitefinity.com/.../tutorial

I have yet to implement it but plan to do so in the coming days. I will report back what I find. If you don't hear back from me in a  timely manner in this thread, feel free to post a reply asking for an update.

Vince,

Thanks for all the great info, I hadn't seen all those articles yet.

I'll take a look at those and also keep this thread updated as well.

Hello Jeff,

First of all we'll give you 2 more options just to make sure that we have them on the table when we consider the editing of the content in Sitefinity and it's synchronization with the live site.

• The solution Michael proposed is a valid one. Thanks Michael!
• If this doesn't work for you I'll suggest you a second option - for your content editors - Sitefinity's Digital Asset Management tool - it will really make their life easier.
• And/Or Use Ldap provider (for content editors - in order to provide them access with their AD accounts but not automatically) and the Default provider - for the rest of the users.

Vince,

After I read some of the links you posted, I tried setting up SSO claims auth with Sitefinity's STS and the built in LdapUsers membership provider. Then I created a login page including a login widget with the widget's "MembershipProvider" property set to "Default", hoping it would auth against Sitefinity's local user DB.

The SSO claims auth with the LdapUsers membership provider worked fine. The login form with the Default membership provider didn't work though. After I used the login form, Sitefinity didn't seem to recognize that I was logged in, it kept sending me over to the STS for auth.

If I turned off claims auth, I was able to create two login forms, each with a widget pointing at the LdapUsers membership provider and Default membership provider respectively. That worked fine. It seems this config would work OK and while the internal users could access one form, external the other form. Internal users still have to type their user name and password, but at least it still authenticates off Ldap and their password stays in sync. I am wondering if this is a good idea to use in a new implementation since it seems everything is moving towards claims auth and if the older non-claims auth would be phased out.

Hi Jeff,

I think that your interpretation of when and why to use a "form" to authenticate users is different than my interpretation. Some background, as I understand things. Forgive me if this is too much info but I thought it would be useful... :)

I use the STS application for authenticating users in the backend only. The idea behind claims auth is that you have an application (Sitefinity) that doesn't know who the user is. To find out who the user is, Sitefinity redirects them to a trusted authentication provider: the STS website. In our case, the STS website use AD/LDAP to discover the identity of the user (in practice, under the hood the STS could look up the user in the database, make an OAuth call to Facebook, or whatever... it doesn't matter). The STS then redirects the user back to Sitefinity and includes an encrypted/hashed packet of information that Sitefinity opens up and sees the user's identity. Sitefinity now knows who the user is and trusts the STS to have provided this info (it trusts it because we configured Sitefinity to do so using the backend security settings). This process is seamless to the user ; they never see anything in their browser. This process, in effect, replaces the need for a login form.

For the frontend, I do not use the STS. In my case the reason is because my frontend users don't have AD accounts. Therefore I need to authenticate those people differently. I chose to implement Forms Authentication. So, the user is given a form in a web page to fill in their user name and password. When their credentials are submitted, I look up their credentials in a custom database (that my company manages separately from Sitefinity; Sitefinity has nothing to do with it). If the login is successful then I set a Forms Auth cookie and redirect the user to the "homepage" of the frontend website. Sitefinity sees the Forms Auth cookie, verifies that it's legit... and that's that.

So, you see, my authentication process for the backend and frontend are two completely different things.

To your point/question about non-claims auth "going away", I'm not worried about that because it will never happen. Telerik would never take that away because the Forms Auth scenario that I describe above is almost certainly very common - lot's of people do it.

Hopefully that makes sense and was useful.

Hi Vince,

Thanks for the detailed explanation. I think I understand what you're trying to do, which completely mimics what I am trying to do.

Have you actually tried what you wrote?

The reason I ask is that, based on my testing, it seems that once you turn on claims authentication, you can no longer auth the user by setting the Forms Auth cookie. Once you turn on claims, even if you are not using STS, if you are just using the out of the box Sitefinity login form (from /Sitefinity/Authenticate/SWT), it still issues you a ticket and sets a couple "FedAuth" cookies.

It seems that once I turn on claims and set the ticket issuer (setting the microsoft.identityMode/service/federatedAuthentication/wsFederation@issuer web.config attribute), it will only accept tickets from that issuer. I have tried to create a login form in Sitefinity and point the "serviceUrl" to /Sitefinity/Authenticate/SWT, to hopefully be able to authenticate users with the out of the box ticket issuer (the Default membership provider) and that doesn't work. When the /Sitefinity/Authenticate/SWT URL is accessed, a HTTP response is returned that says:

X-Authentication-Error: Missing configuration for the issuer of security tokens "domain.com/.../SWT"

and that request redirects over to my SSO STS (the URL I set on the issuer attribute in the web.config file).

OK, I'm a moron.

I was able to get the login form working (along with keeping SSO/STS working) by changing the "ServiceUrl" on the login wiget to domain.com/.../SWT and making sure in Sitefinity Settings > Advanced > Security > SecurityTokenIssuers, that an entry exists for domain.com/.../SWT with a key that matches http://localhost's entry.

I feel like I am throwing things against the wall to see what sticks, but this seems to be working and a viable option to having a SSO auth option for internal users and a form login for external users.

Hi Jeff,

I'm glad to hear that your login form is now working. If you have any other issues, do no hesitate to contact us again.

Regards,
Yavor Slavchev
Telerik

Jeff, sorry for the delay in responding. I'm glad that you got it working. I ran into the same challenges too as I went about figuring it out. I agree that it's basically like throwing darts at a board; Telerik's documentation leaves a lot to be desired.

Accessing and using Sitefinity's Forms Authentication cookie
On a different note but related note, I have just started working on the next step in my development: accessing and decrypting Sitefinity's the Forms Auth cookie from a non-Sitefinity website on the same base domain. I've configured Sitefinty to set the domain on its cookie to use the base domain (i.e. mydomain.com) and I intend to access the cookie from mysubdomain.mydomain.com. Once decrypted, I would like to suck out whatever object or data that Telerik has injected into the cookie.

My use case: my users will be logging into the Sitefinity front end using a custom MembershipProvider that I have built and hooked up (done!). Our company has many web apps already built that will continue to live alongside but separately from our Sitefinity installation. I want to use Sitefinity Authentication ticket to authorize users in my other applications; I don't want them to have to re-log in separately.

Have you seen any examples or posts that describe how to go about doing this? Any heads up would be greatly appreciated.

Hello Vince,

Thank you for your additional question.

What I could advise you is to read this article and see if this can help you for your use case.

http://www.sitefinity.com/blogs/svetlayankova/posts/svetla-yankovas-blog/2013/07/02/single-sign-on-between-sitefinity-and-3rd-party-applications-part-2-using-wif

Yo can also read and 'The basics' - part 1 if you are not familiar with some of the terms.

I hope this information is useful.

Regards,
Yavor Slavchev
Telerik

Hey Vince,

Did you ever figure out how to do the form authentication with sitefinity and other .net apps?