locked
Identifying the client application RRS feed

  • Question

  • Hello,
    We have a scenario where we want to identify the client application that is authenticating with the STS using WS-Trust.  

    We have built a custom STS using WIF and want to create a response depending on which client is being used.  For example, if the user is signing on using a desktop application or a smart phone application might produce a different set of claims.

    The general idea is to distribute some type of secret that get's used when building the client applications. (Much like OAuth's consumer key.)

    How can I approach this scenario in WIF for WS-Trust?

    /Martin Altenstedt


    • Edited by Altenstedt Monday, December 19, 2011 9:24 PM Formatting
    Monday, December 19, 2011 9:21 PM

Answers

  • Is this an active or passive trust?

    If it's passive you could pass the identifier in the context parameter. If it's active you could pass it through a RST parameter.

    You could also use the audience URI to identify the client. Say you use a web service with a uri of "urn:my:app". Depending on the app you could append a client identifier like "urn:my:app:client123", but then you would have to be careful on the STS side making sure you parse the URI properly.

    From the perspective of identifying the client securely, there are probably a dozen different ways to do it, and each of them have their limitations. The biggest problem is that it's possible for someone to reverse engineer your client and spoof any identifiers with relative ease.

    What are you trying to accomplish with identifying the client?


    Developer Security MVP | www.syfuhs.net
    • Marked as answer by Altenstedt Tuesday, December 20, 2011 8:27 PM
    Tuesday, December 20, 2011 5:55 PM

All replies

  • Is this an active or passive trust?

    If it's passive you could pass the identifier in the context parameter. If it's active you could pass it through a RST parameter.

    You could also use the audience URI to identify the client. Say you use a web service with a uri of "urn:my:app". Depending on the app you could append a client identifier like "urn:my:app:client123", but then you would have to be careful on the STS side making sure you parse the URI properly.

    From the perspective of identifying the client securely, there are probably a dozen different ways to do it, and each of them have their limitations. The biggest problem is that it's possible for someone to reverse engineer your client and spoof any identifiers with relative ease.

    What are you trying to accomplish with identifying the client?


    Developer Security MVP | www.syfuhs.net
    • Marked as answer by Altenstedt Tuesday, December 20, 2011 8:27 PM
    Tuesday, December 20, 2011 5:55 PM
  • This is active trust.  The default clients are Silverlight and desktop applications.

    I read the WS-Trust specification and figured I might be able to use the SecondaryParameters element within the RequestSecurityToken message.  Is that the right choice?

    I realize the inherent difficulties with providing a third party with a secret since we have absolutely no control over the handling of that information, either within the other company or the way it is embedded in their client.

    The intended use for this approach is licensing of access to our services.  Any client that wish to call our services would need to provide information that identifies the client application being used.  We would then return claims based on the licensing information associated with the client identity.

    /Martin Altenstedt

    Tuesday, December 20, 2011 6:14 PM
  • In that case, yes the SecondaryParameters are probably what you would want to use. I can't really say for sure what the best way to handle the licensing bit is though.
    Developer Security MVP | www.syfuhs.net
    Tuesday, December 20, 2011 6:27 PM