FederatedSecurityTokenProvider exception when invoking mulitple methods over a delegated (ActAs) channel

Question

(note:  I'm moved this text from a previous posting because the issue has evolved into a more succinct question)


I am able to open a delegated channel to my active RP endpoint from my passive RP and generate an ActAs service proxy for my activeRP service.  The activeRP is secured by an issued token from my STS service.
The sts service issues the token, and it looks correct.

Here's the interesting part, using this channel, I can call a method on my service proxy, ONE TIME.  If I attempt to make a second call on my proxy (utilizing the same channel) I get the exception:  System.InvalidOperationException: ID3266: The FederatedSecurityTokenProvider cannot support the FederatedClientCredentialsParameters. The FederatedClientCredentialsParameters has already provided the ActAs parameter

In digging through the FederatedSecurityTokenProivder source (via Reflector), it appears as this error is thrown when the GetTokenCore is called on a delegated RSTR.  I do not understand why this code (GetTokenCore())  is being invoked on the 2nd call of an already open channel.  All the other examples of delegation (in labs, found on the web, etc) show only a single method call on the delegated service.  The security is performed at the channel level, not the operation level, correct?

What's going on here?

here's my proxy client code:

 

        const string endpointName = "IssuedTokenEndpoint";

        var principal = Thread.CurrentPrincipal as IClaimsPrincipal;

        ReadOnlyCollection<SecurityToken> callerTokens = principal.GetBootstrapTokens();

        var factory = new ChannelFactory<IShoppingCartService>(endpointName);

          factory.Credentials.ClientCertificate.Certificate = CertificateHelper.GetCertificateFromStore("76 42 47 aa c6 be b5 4f 4d cf 18 8c 40 43 5c b5 0b 4e c3 72", X509FindType.FindByThumbprint, StoreName.My, StoreLocation.LocalMachine);

        factory.ConfigureChannelFactory();

        var proxy = factory.CreateChannelActingAs(callerTokens[0]);

        try

        {

            lblProductDescription.Text = proxy.GetProductDescription("Called Once"); // This executes fine

            lblProductDescription.Text = proxy.GetProductDescription("Called Twice");  // This raises a FederatedSecurityTokenProvider exception
        }

        catch (Exception ex)

        {

            lblError.Text = ex.ToString();

        }

and the error info.

ID3266: The FederatedSecurityTokenProvider cannot support the FederatedClientCredentialsParameters. The FederatedClientCredentialsParameters has already provided the ActAs parameter.

Server stack trace:
   at Microsoft.IdentityModel.Protocols.WSTrust.FederatedSecurityTokenProvider.SetupParameters()
   at Microsoft.IdentityModel.Protocols.WSTrust.FederatedSecurityTokenProvider.GetTokenCore(TimeSpan timeout)
   at System.IdentityModel.Selectors.SecurityTokenProvider.GetToken(TimeSpan timeout)
   at System.ServiceModel.Security.SecurityProtocol.GetToken(SecurityTokenProvider provider, EndpointAddress target, TimeSpan timeout)
   at System.ServiceModel.Security.MessageSecurityProtocol.GetTokenAndEnsureOutgoingIdentity(SecurityTokenProvider provider, Boolean isEncryptionOn, TimeSpan timeout, SecurityTokenAuthenticator authenticator)
   at System.ServiceModel.Security.SymmetricSecurityProtocol.TryGetTokenSynchronouslyForOutgoingSecurity(Message message, SecurityProtocolCorrelationState correlationState, Boolean isBlockingCall, TimeSpan timeout, SecurityToken& token, SecurityTokenParameters& tokenParameters, SecurityToken& prerequisiteWrappingToken, IList`1& supportingTokens, SecurityProtocolCorrelationState& newCorrelationState)
   at System.ServiceModel.Security.SymmetricSecurityProtocol.SecureOutgoingMessageCore(Message& message, TimeSpan timeout, SecurityProtocolCorrelationState correlationState)
   at System.ServiceModel.Security.MessageSecurityProtocol.SecureOutgoingMessage(Message& message, TimeSpan timeout, SecurityProtocolCorrelationState correlationState)
   at System.ServiceModel.Channels.SecurityChannelFactory`1.SecurityRequestChannel.Request(Message message, TimeSpan timeout)
   at System.ServiceModel.Dispatcher.RequestChannelBinder.Request(Message message, TimeSpan timeout)
   at System.ServiceModel.Channels.ServiceChannel.Call(String action, Boolean oneway, ProxyOperationRuntime operation, Object[] ins, Object[] outs, TimeSpan timeout)
   at System.ServiceModel.Channels.ServiceChannelProxy.InvokeService(IMethodCallMessage methodCall, ProxyOperationRuntime operation)
   at System.ServiceModel.Channels.ServiceChannelProxy.Invoke(IMessage message)

Exception rethrown at [0]:
   at System.Runtime.Remoting.Proxies.RealProxy.HandleReturnMessage(IMessage reqMsg, IMessage retMsg)
   at System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke(MessageData& msgData, Int32 type)
   at ShoppingServices.IShoppingCartService.GetProductDescription(String productID)
   at ASP.default_aspx.DelegateBtn_Click(Object sender, EventArgs e) in c:\cSharpApps\Projects\Temp\MySTS\Websites\ClearTextPassiveRP\Default.aspx:line 68

Answer 1

Hi,

I can also replicate this issue using the samples from the Geneva Framework SDK and Identity Training kit. The samples are listed below:-

Invoking a WCF Service on the backend via delegated access in folder IdentityTrainingKit\Labs\WebServicesAndIdentity\Ex4-InvokingViaDelegatedAccess\End

Identity Delegation sample found in folder C:\Program Files\Microsoft Geneva Framework\Samples\End-to-end Scenario\Identity Delegation

My understanding is on the first method call on the actas channel, an implicit call is made to the ActAs STS to obtain a delegated token. Before the call is made to the ActAs Sts the callers token (issued token) from the previous auth handshake is added to the RST. I presuming the ActAs STS isn't being called again for the second method call, but perhaps it is?

Any thoughts?

---

Regards Wilko31

Answer 2

Great catch guys, this sounds like a bug and we'll investigate.

In the interim, there are several workarounds you can use:

1. Enable sessions to the backend service. This may or may not be feasible depending on your deployment topology.
2. Create one channel per call.
3. Use WSTrustClient + CreateChannelWithIssuedToken().

Answer 3

Is there an updated status on this from MFST?

Answer 4

We've confirmed that this is a bug, so it will eventually get fixed. However, I cannot make any promises in terms of when it will be addressed. Can you provide data on whether the workarounds are feasible for you? That will be good information for me to take back to the product team.

Answer 5

I've written a service helper for other developers to use when they want a proxy to a service via a delegated (actAS) token.  The helper, has a proxy property which is recreated everytime its accessed.

I don't think it will scale over time, but is functional enough to get users started.

Answer 6

I tested the third workaround on the samples I mentioned in the thread and it worked fine.

Does this bug need to be raised on the connect site so it can be tracked?

---

Regards Wilko31

Answer 7

We are already tracking this internally, so a new bug from Connect would probably just come back as "known issue". It might be useful for your tracking purpose though, so feel free to file one.