次の方法で共有

WCF Security Spike – Day 1

  • [アーティクル]

My first goal was to secure a service.  I’m happy to say I managed to get a service that allowed one user and didn’t allow another by using a PrincipalPermission with wsHttpBinding (I gave up on netTcpBinding for now – one monster at a time right?)

I created a simple service and declared a service with an endpoint as you see in the web.config (from .NET 4)

 <system.serviceModel>
    <services>
        <service name="Security">
        <endpoint address="" binding="wsHttpBinding" bindingConfiguration=""
         contract="ISecurity" />
    </service>

Then I implemented my service with a security demand

 [PrincipalPermission(SecurityAction.Demand, Role="BUILTIN\\Administrators")]
public string AdminOperation()
{
    return GetSecurityInfo("AdminOperation");
}

Easy huh? Wait a minute… not so fast.  I started testing this.

The machine is joined to the REDMOND domain and when I tested using my domain account it worked just fine.

However when I fired up the WCF Test Client using a local machine account that is a member of the Administrators group I get “Access Denied”.

In fact, if I allow the call and then test for role membership using IsInRole(“SomeGroup”) with any local group, all of them returned false.  The only time I got IsInRole(“Administrators”) to return true was when I used my domain account to call the service.

Oh the mysterious ways of Active Directory…  Who can plumb the depths of kerberos?  Perhaps I could (should? ) look at Windows Identity Foundation for help…

Comments

  • Anonymous
    December 03, 2009
    also "BUILTIN" will only work with english versions of Windows....

  • Anonymous
    December 03, 2009
    You need to set the identity for the service. When using Windows security, the URL isn't enough information to call the service. You also need to know the identity of the user that is running the service. If you host the service as the machine account, then it will be a SPN in the form "host/machineName" (make sure to verify it is setup using setspn... which of course requires you to be domain admin to create it if it is not setup). If hosting as a user account, it will be a UPN in the form of user@domain. Yes. Not exactly the easiest thing to configure when the team doesn't ship tools to help you configure things properly and help diagnose problems.

  • Anonymous
    December 03, 2009
    At first glance, it looks like an issue with identity propagation as you are hosting the service in one domain (REDMOND) and the client application is using an account in the local domain, is that correct ?. If that's the case, Kerberos will not propage the user identity across different domains.

  • Anonymous
    December 03, 2009
    @cibrax - no the service and client are on the same machine in this test and the machine is joined to the REDMOND domain.  I used RUNAS to run the WCF Test Client in the other account