none
How to pass a security token to services and between services?

    Question

  • Hello,

    I have following scenario:

    A PassiveSTS with Username/Passwort Auth (Formsauthentication) from the Geneva sample: Web App with Multiple SignIn Methods.

    A web application which uses the PassiveSTS.

    This part is implemented and working.

    Now I created two WCF-services. They are called by the web application, but also they are called by each other.

    My question:
    1 . Is it possible to use the token from the web app in the services,
    2. and if yes, how do I realise this (which keywords here: delegation, impersonation, federation?). Or do I need to auth again with the wcf services to the same or an additional sts.

    It would be nice but not essential if all these configuration can be made in a config-file, not in code.

    Hopefully anybody can help me out

    Thanks
    Christian


    Thursday, January 22, 2009 8:51 PM

All replies

  • Christian_h said: 2. and if yes, how do I realise this (which keywords here: delegation, impersonation, federation?). Or do I need to auth again with the wcf services to the same or an additional sts.

    I have almost the same scenario.  I have one other question besides Christian's: How do I avoid having to re-authenticate to the STS on a per call basis when invoking operations on those downstream services?  Is there a way to use the FAM and SAM (SessionAuthenticationModule) in WCF or is there an analogous component?

    --

    Regards,

    Travis Spencer

    Friday, January 23, 2009 2:07 AM
  • Yes - this is possible - the term is identity delegation -

    there is a section in the whitepaper about that - as well as a sample in the SDK (end-to-end scenario)

    @Travis: you don't have to re-auth for every request - the token is cached in the channel factory - as long as you re-use the factory, you re-use the token.

     


    Dominick Baier, thinktecture - http://www.leastprivilege.com
    Friday, January 23, 2009 6:49 AM
  • I may be mistaken, but...

     

    In the Geneva Server setup, you need to setup passing of a second identity claim that will be used delegate to the service. SAML tokens have the an 'applies to' element, which indicates that the SAML token create for sending to a particular end-point.  If you have a token for end point (RP) http://www.app.com/  , can you use the same token as the ActAs internally to http://service.app.com/ ?  I wouldn't think the token would be accepted. 

    I have a similar situation. I want to the external IP to give me a token that I can authorize access to my web application.  The web application gets it's data from a series of internal web services. Ideally, the identity should flow from web application to the service. This is demonstrated by the identity delegation sample. However, wouldn't the IP be required to know about the internal service(s) and send a secondary token for the ActAs.

    Friday, January 23, 2009 9:55 PM
  • Thanks for the replies. The section in the whitepaper is really informative but very abstract. The example in the sdk is a bit too complex I think. There are two clients, two sts and two services, all mixed up together. Has anyone a bit more common example, like one sts, one web app, one wcf service :)

     

    edit:

     In my case I dont know, if impersonation / delegation is the right thing for me. My token, which I got from the STS has nothing to do with Windows / Kerberos. I authenticate against a sql database with username / password and get then a token with several claims which I need for the application.

    Now when I call the service with the application I want to (automatically) pass the token to the service. The service now must decide if the token from the client does match the claim requirements and if the service trusts the issuer from the token. Impersonation/Delegation is more "Act as" but what I need is just a SSO with an alltime present token with custom claims.

    Saturday, January 24, 2009 12:51 PM
  • I have a very similar scenario and would like to hear a suggestion.
    Wednesday, March 04, 2009 5:57 PM
  • @Travis: you don't have to re-auth for every request - the token is cached in the channel factory - as long as you re-use the factory, you re-use the token.


    After some testing, we've found that caching is being done in the channel not the channel factory.  I go into this on my blog: http://travisspencer.com/blog/2009/03/caching-tokens-to-avoid-calls.html. There are still issues with caching like I've described there, however.  Specifically, caching the SAML token on the client-side and sending the entire thing each time means that the RP has to completely decrypt the token with each request using asymmetric cryptography and it must reestablish the secure conversation (switch from asymmetric to symmetric key encryption) to optimize out the overhead associated with this costly crypto.  In establishing this symmetric key, the service is creating a cache of its own that never ends up being used because the client never sends the SCT back but send the entire SAML token instead :-(

    This becomes an issue when your have hundreds of concurrent requests.  We haven't found a way to take advantage of the symmetric key optimization provided by the secure conversation because closing the channel on the client-side sends a message to the service to purge the decrypted SAML token from the cache that it has there.  If we figure it out, I'll post about it on my blog and back here.

    Dominick, if you have any insight about this, it would be much appreciated!

    Regards,

    Travis Spencer
    http://travisspencer.com
    Tuesday, April 14, 2009 4:44 AM
  • Sorry about the confusion - of course i meant that the token is cached in the channel - not the factory.

    The way i see it is this:

    - if you make frequent calls to the same service and want all optimizations - use SecureConversation and keep the channel around. Of course, you now have to deal with session semantics (like expired sessions, faulted channels etc.).

    - if you make infrequent calls to the service and want to be "resource friendly" on the service side - disable SecureConversation and keep the channel around. This will give you "stateless" semantics, but you lose some optimizations.

    - for situations in between - use WSTrustClient to obtain a token (and cache it) and use the ChannelOperations extensions methods to create channels manually.

    In all cases i guess you need an agent pattern on the client side that abstracts away these details.

    HTH
    Dominick Baier | thinktecture | http://www.leastprivilege.com
    Tuesday, April 14, 2009 6:39 AM