Forms Authorization, SSL and a WCF Service

Ok, I've got my ASP.NET site working pretty much how I want. I have a login page, which redirects properly to a data entry page if the user puts in valid credentials. The data entry page can access a WCF service, and the WCF service can access the login credentials via HttpContext.Current.User.Identity.Name. I've even set up a new user page that lets people create an account. It all works great on regular HTTP!

My problem is that I don't really know how to set up SSL for this scenario. I have a certificate installed, and I can access all the aspx pages using HTTPS. But when I switch to HTTPS, the WCF service doesn't work anymore.

Has anyone else set up an application similar to this?

Here's some relevant parts of my web.config file:

Code:

<authentication mode="Forms">
      <forms loginUrl="Login.aspx"
        cookieless="UseCookies"
        requireSSL="false"
        defaultUrl="COEDataForm.aspx" />
</authentication>
<authorization>
      <deny users="?"/>
      <allow users="*"/>
</authorization>
<httpCookies requireSSL="true"/>

Code:

<!-- Allow Anonymous Access to New User creation page-->
  <location path="NewUser.aspx">
    <system.web>
      <authorization>
        <allow users="?" />
      </authorization>
    </system.web>
  </location>

Code:

<system.serviceModel>
   <!-- AspNetCompatibility lets the service use Forms authorization -->
   <serviceHostingEnvironment aspNetCompatibilityEnabled="true">  
   </serviceHostingEnvironment>
   
   <services>
    <service behaviorConfiguration="DataServiceBehavior" name="DataService">
       <endpoint behaviorConfiguration="DataServiceEndpointBehavior" address="" binding="webHttpBinding" contract="IDataService" >
       </endpoint>
       <endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange" />
    </service>
   </services>
   
   <behaviors>
       <endpointBehaviors>
         <behavior name="DataServiceEndpointBehavior">
           <enableWebScript/>
         </behavior>
       </endpointBehaviors>
       <serviceBehaviors>
        <behavior name="DataServiceBehavior">
          <serviceMetadata httpGetEnabled="true" />
          <!-- TODO: Turn off debugging here before deploying -->
          <serviceDebug includeExceptionDetailInFaults="false" />
        </behavior>
       </serviceBehaviors>
  </behaviors>   
 </system.serviceModel> 

 

Ok, so I would need a custom binding if I want my service to use HTTPS?

But now I'm wondering if my service even needs HTTPS. If my login page uses HTTPS to verify the user identity and then redirects to a HTTP ASPX page that accesses the service - would that be just as secure? I'm blocking access to the ASPX page to anyone that's not logged on, and the service is using HttpContext.Current.User.Identity.Name to verify that it's a legitimate user making the request.

Or is there some way that someone could intercept the information in the cookies if I'm not using HTTPS?

 

Well, the only data that I wouldn't want intercepted by hackers would be the username/password. All the other data going back and forth is not sensitive at all. I just wouldn't want someone to be able to impersonate a registered user of my site.

 

You don't think I need it even for the login page? I would think that at least should be HTTPS. Or is there some kind of security built in to the ASP.NET login control?

Thanks for your input, by the way. I really appreciate it.

 

I take an all or nothing view on SSL. The reason being is that if you take in a username and password on an encrypted page and then transfer to an unencrypted page a hacker can still intercept the authentication cookie that tells your app "hey, I'm legit" and can then send the same cookie to your app, and, viola, they have the same credentials as the user they intercepted. So, either use SSL to protect ALL pages where you need to be logged in to see or not at all. Otherwise you're only giving yourself a false sense of security. GMail users who have SSL turned off in their account settings have learned this the hard way. If you don't do this, then you have to implement various other restrictions such as IP verification and host identification verification for each request sent to your app even if someone presents your application with an authentication cookie.

You can tell your cookies to be transferred via SSL while leaving the rest of your page unSSL-ed, I believe, but if you have it setup for cookies then why not just set it up for the whole page?

 

Well, I have the following in my Web.Config ...

Code:

<httpCookies requireSSL="true"/>

If I understand correctly, this means the login cookies will be transmitted via SSL. So that part should be safe, right?

The main reason I don't want the whole site to be HTTPS is that it seems to make the WCF service stop working.

 

The presence or lack of SSL should not disable or enable .NET components, respectively. Though, you may need to configure your WCF service to work with SSL as it works on different ports and the HTTP handshake process has a few different steps. I found this link by a simple Google search. I hope it helps.

http://icoder.wordpress.com/2007/06...p-bindings-with-ssl-transport-level-security/