locked
netTcpBinding & Windows security - how to pass credentials along RRS feed

  • Question

  • If I'm using the netTcpBinding and transport security with Windows credentials, how do I extract the credential information on the service side, using the AuthorizationContext?

    If I have my SQL Server setup so that people in certain AD roles can perform actions, how can I pass my client information down to the SQL server so it can detect the role? From what I understand transport based security cannot survive service to service and further hops.

    Thanks!
    EM
    Wednesday, December 9, 2009 1:01 AM

Answers

  • Hi EM,

    For extract the client credential info, you can use the OperationContext.ServiceSecurityContext property in your service operation code. e.g.

    public string GetData(int value)
            {
    //windows identity
                OperationContext.Current.ServiceSecurityContext.WindowsIdentity;
    //client identity when not using windows authentication
                OperationContext.Current.ServiceSecurityContext.PrimaryIdentity;

                return string.Format("You entered: {0}", value);
            }

    Also, as you said, so far windows authenticated credentials cannot be forward to another remote machine(double hop). Therefore, you may consider using some custom authorization approaches or just let your service using a least privilege service account to access the backend database.



    Please remember to mark the replies as answers if they help and unmark them if they provide no help.
    Tuesday, December 15, 2009 7:56 AM

All replies

  • Hi EM,

    1. You can use a custom User Name and Password Validator to supply the user credential to service. Then service use this credential to access the SQL server. In this situation you need to grant the permission to this user.
    http://msdn.microsoft.com/en-us/library/aa702565.aspx
    When a client authenticates to the front-end service using a user name and password that correspond to a Windows account on the back-end service, the front-end service can authenticate to the back-end service by reusing the client’s user name and password. This is a particularly powerful form of identity flow, because passing user name and password to the back-end service enables the back-end service to perform impersonation.

    2. You can have a look at Impersonation. Impersonating a client on a Windows Communication Foundation (WCF) service enables the service to perform actions on behalf of the client. For actions subject to access control list (ACL) checks, such as access to directories and files on a machine or access to a SQL Server database, the ACL check is against the client user account. This topic shows the basic steps required to enable a client in a Windows domain to set a client impersonation level.
    http://msdn.microsoft.com/en-us/library/ms731090.aspx


    Best regards,
    Riquel
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.
    Welcome to the All-In-One Code Framework! If you have any feedback, please tell us.
    Tuesday, December 15, 2009 6:58 AM
  • Hi EM,

    For extract the client credential info, you can use the OperationContext.ServiceSecurityContext property in your service operation code. e.g.

    public string GetData(int value)
            {
    //windows identity
                OperationContext.Current.ServiceSecurityContext.WindowsIdentity;
    //client identity when not using windows authentication
                OperationContext.Current.ServiceSecurityContext.PrimaryIdentity;

                return string.Format("You entered: {0}", value);
            }

    Also, as you said, so far windows authenticated credentials cannot be forward to another remote machine(double hop). Therefore, you may consider using some custom authorization approaches or just let your service using a least privilege service account to access the backend database.



    Please remember to mark the replies as answers if they help and unmark them if they provide no help.
    Tuesday, December 15, 2009 7:56 AM