none
How To: Create Custom Client and Service Credentials

    Question

  • I read this article on MSDN, but it doesn't describe how you consume a custom ClientCredentials on the service side. I'm fairly new to WFC and am looking to create a custom ClientCredentials class that includes additional meta information about the user that can be used to determine what authority they have to perform a particular function within the service.

    Maybe a custom ClientCredentials class isn't the correct way to do this but I would like to make it as easy as possible for the client side of my services to just instantiate the client proxy and have it use my custom ClientCredentials so that on the service side that meta information will be available to make certain decisions about how to process the request.

    The article I am referencing is: http://msdn2.microsoft.com/en-us/library/ms730868.aspx

    Tuesday, January 16, 2007 11:17 PM

Answers

  • So my end solution was nothing related to custom client or service credentials. I ended up using IContractBehavior to add a IClientMessageMessageInspector that adds the meta information to the headers.

    I did this so that if the client is using this WCF code it'll automatically attach the meta information, else they are going to have to spoof it but since I'll only allow Windows integrated authentication to these services, I'll be able to know which application is trying to bypass the metadata collection ... about the device.

    Wednesday, January 17, 2007 6:26 PM

All replies

  • Hello:
    1) Typically, a custom ClientCredentials is used to provide new types of security tokens to secure the messages sent by the client to the service or to change the way the tokens are obtained.

    2) Regarding the additional meta-information, who will be the issuer of this information? If it is a third-party, then you should use an issued token scenario:
        2.1 Create an STS (Security Token Service) associated with the entity that creates the meta-information.
       
    2.2 The clients should use a federation binding (no need for custom ClientCredentials). When the client wants to send a message to the service, it will use the WS-Trust specification to request a security token to the STS.
       
    2.3 The STS, after authenticating the client, will create a SAML token containing the meta-information.
       
    2.4 The message sent by the client to the service will contains this issued SAML token.
       
    2.5 At the service side, you can create a custom authorization manager that uses the information inside the token (available in the form of claims) and uses it to make the authorization decision. You can also use this information inside the service operations.

    Hope it helps

    Pedro Felix
    Wednesday, January 17, 2007 10:45 AM
  • The issuer of the meta-info should come from the client. This information should be passed to the service so that when the service does authorization of the user, if certain meta-info is not present it should reject the request and if it is present, perform the authorization based on the authorization store the service uses to store who can do what and under what circumstances.

    So, the client would create a client proxy to the service, and during the call, meta-info about the client should be gathered and packaged with the call so that the service (or some process before the service) can use it.

    I need to use a method like this so I can simply turn on or off this collection at the client level and also so that each service won't have to read and parse this meta-info but it'll be done for them automagically, one for authorization, two for logging.

    Make sense? Is this not possible? Would I be creating a new token based on this meta-info and how would I turn that into a ClaimSet on the server side?

    Wednesday, January 17, 2007 12:56 PM
  • I found this blog entry that looks sorta like what I want to do.

    http://weblogs.asp.net/avnerk/archive/2006/04/26/Adding-custom-headers-to-every-WCF-call-_2D00_-a-solution.aspx

    Though it doesn't have code on how to consume the headers on the service side, I'll probably figure it out.

    In case the link goes dead sometime in the future, it says to use an IProxyMessageInspector to add the custom headers. You can then just create an attribute (IChannelBehavior, IOperationBehavior) that you decorate each service or operation with to get the headers added on the client.

    I'll post a solution for consuming them on the service side if this all works out like I hope it will.

    Note: IClientMessageInspector is available, I guess the other interface was beta stuff.

    Wednesday, January 17, 2007 1:13 PM
  • Hello:

    From a security perspective, I found it strange for the client to self-assert this authorization meta-information. What forbids a client of inserting authorization information for resources that he is not allowed to access?
    This information should also be protected inside the message so that is not reused or replayed by an eavesdropper.

    One way of accomplishing what you want is by using custom headers.
    Other option is to use a custom security token or embedded the authorization meta-information in a SAML token.

     In the service side, the headers can be accessed via the OperationContext.Current.IncomingHeaders property.


    Hope it helps
    Pedro Felix
    Wednesday, January 17, 2007 2:28 PM
  • So my end solution was nothing related to custom client or service credentials. I ended up using IContractBehavior to add a IClientMessageMessageInspector that adds the meta information to the headers.

    I did this so that if the client is using this WCF code it'll automatically attach the meta information, else they are going to have to spoof it but since I'll only allow Windows integrated authentication to these services, I'll be able to know which application is trying to bypass the metadata collection ... about the device.

    Wednesday, January 17, 2007 6:26 PM