HTTPS rest and soap RRS feed

  • Question

  • After four hours of googling internet after a solution I can't stand it anymore!

    We have a wcf service with a soap and a rest binding and we want to switch from http to https but the rest service in https doesn't work because the web methods are secured with the PrincipalPermission attribute and we set the Thread.CurrentPrincipal=HttpContext.Current.User but this works with http but it doesn't in https, why? Who knows?

    There is a thread about the PrincipalPermission and https:

    We could switch the behavior of the service like suggested in the article

        <behavior name="">
            <serviceDebug httpHelpPageEnabled="true" includeExceptionDetailInFaults="true" />
            <serviceAuthorization principalPermissionMode="None"/>

    And it works in the rest version but it doesn't in the soap version! Can you define two different service behavior for two different end point? NO! Thanks!

    So, how the most flexible service provider of the world, with the most complicated configuration ever that you get an headache only when you hear its name can be configured to work with https and the principal permission in rest and soap?

    Friday, March 15, 2013 2:36 PM

All replies

  • Hi there!

    I'm not sure how to solve your problem, but if you are pressed for time as an intrim solution/alternative you could perhaps try and implement an encryption proxy application like stunnel ( Stunnel acts as an SSL encryption wrapper between server and client. Clients connect to stunnel implementing SSL and your server/service connects as a client to a local non SSL port exposed by Stunnel. All messages are then fowarded by stunnel facilitating comunication between server and client.


    Dewald Esterhuizen


    It's like software, by default - Just me taking a jab at people who pronounce my name wrong :) Have a look at my blog - Open source all the way or get me on twitter @DefaultSoftware

    Sunday, March 17, 2013 8:13 AM
  • Thanks for the reply, we aren't pressed with time, we are just testing it out because we would like to use https. Setting a proxy isn't a solution, we don't want to add more complexity, it should be possible  by just changing something in the wcf service configuration, otherwise why do we have to get an headache each time with a such complicated configuration system when it can't do a simple thing like this one?

    The requirement are very easy: REST authentication with Asp.Net (form authentication), SOAP authentication with soap header. The web methods are secured with the attribute PrincipalPermission, the user must be logged in to use the service.

    Is this a too complicated requirement for wcf?

    Monday, March 18, 2013 8:22 AM
  • Buddy, can you please check this link

    This guy created RESTful service then added a SOAP endpoint. I think you also looking for the same.


    • Marked as answer by Haixia_XieModerator Friday, March 22, 2013 9:48 AM
    • Unmarked as answer by Ticino73 Tuesday, March 26, 2013 8:53 PM
    Monday, March 18, 2013 9:06 AM
  • An easy way of doing it is to download the WCF project template "WCF SOAP and REST simple service". It has a picture of bathing soap on it :).


    Monday, March 18, 2013 9:23 AM
  • Thanks but nothing was useful, so I have create a mini project for this problem, hopeful somebody can solve it:

    There are two configuration, one for VS development server, where everything works, and the other for IIS with https, where it doesn't work.

    You can login with the following url: /Authentication/login?user=admin&password=123456

    And you can test the different behaviors with the following url: /Service/Insecure

    The Thread.Current.User, which is used from the PrincipalPermissionAttribute, is set in the service constructor:
    public Service()
      Thread.CurrentPrincipal = HttpContext.Current.User;

    And the result with visual studio development server is:

      <string>GenericPrincipal admin True</string>
      <string>GenericPrincipal admin True</string>

    And in IIS with https is:

      <string>WindowsPrincipal  False</string>
      <string>GenericPrincipal admin True</string>

    So something is different with https, the Thread.Current.User is changed after the service constructor, what is changing it? How can the PrincipalPermission, which uses the Thread.Current.User, work with https in IIS?

    Tuesday, March 26, 2013 5:06 PM
  • I couldn't find any demo of WCF Rest with HTTPS and PrincipalPermission, so I suppose that this is a bug of WCF and I would like that the WCF team address it.

    I can't imagine that you can't secure your services with HTTPS because otherwise the identity of the thread is always the generic user! This is a big flaw in the implementation of WCF!

    Tuesday, April 2, 2013 6:55 AM