none
The token provider cannot get tokens for target RRS feed

  • Question

  • We are accessing WCF services in a windows application. We are using WSHttpBinding and Windows authentication when accessing the WCF services.

       We have installed the windows application on some client machines and the authorization worked fine. However on one machine, the authentication fails with the below message:
        "The token provider cannot get tokens for target 'http:\\xyz.com\abc.svc'"

       We have the below security configuration:
         <security mode="Message">
                <transport clientCredentialType="Windows" proxyCredentialType="None"
                  realm="" />
                <message clientCredentialType="Windows" negotiateServiceCredential="true"
                  algorithmSuite="Default" establishSecurityContext="false" />
         </security>

      We have tried setting the security mode as None in both client and service configuration files. But this didn't resolve the issue. We actually need the above security.
    Tuesday, December 7, 2010 12:28 PM

Answers

  • this is the cause of the problem.

    you can still use message level security, for example username or certificate. transport will also work. you need to decide what client credentials best fit your scenario (username, certificate).

     


    http://webservices20.blogspot.com/
    WCF Security, Interoperability And Performance Blog
    • Marked as answer by Yi-Lun Luo Tuesday, December 14, 2010 2:02 AM
    Thursday, December 9, 2010 5:11 PM

All replies

  • possibly the failing machine is out of the windows domain or the running user has low permissions.
    http://webservices20.blogspot.com/
    WCF Security, Interoperability And Performance Blog
    Tuesday, December 7, 2010 5:58 PM
  • Thanks for your reply. All the client machines are in a work group. So we are assuming the permissions are also same.

    Could you explain more about the user having low permissions?

     

    Wednesday, December 8, 2010 11:28 AM
  • try to log in to one machine with both the working and non working user, to see if this is a machine or a user issue.
    http://webservices20.blogspot.com/
    WCF Security, Interoperability And Performance Blog
    Wednesday, December 8, 2010 7:03 PM
  • Actually this new client machine is in a different domain. The services are hosted in a different domain. We are using Windows Authentication at Message level for WSHttpBinding. 

    Is this the cause of the problem? Should we use Transport level security?

    How can we achieve this Message Level security using WSHttpBinding?

    We don't want to use impersonation on client side. Also we can't provide server credentials on client side for security reasons. Please suggest any other alternative for accessing services in a cross domain environment.

     

    Thursday, December 9, 2010 8:36 AM
  • this is the cause of the problem.

    you can still use message level security, for example username or certificate. transport will also work. you need to decide what client credentials best fit your scenario (username, certificate).

     


    http://webservices20.blogspot.com/
    WCF Security, Interoperability And Performance Blog
    • Marked as answer by Yi-Lun Luo Tuesday, December 14, 2010 2:02 AM
    Thursday, December 9, 2010 5:11 PM
  • I know this is a REALLY old post but I just wanted to say that we had this error message today on a client / server set-up that has worked without issue for over a year.  It turns out the error was caused because the server certificate had recently expired and had a new one generated; this issue was caused by the client no longer trusting the server.

    Exporting the new server certificate and installing it in the client's Trusted People certificate store fixed this right up. 

    As I say; an old post; but it would seem the error message is still as useless as it always has been.

    Rob

    Thursday, June 30, 2016 1:50 PM