The ws-trust client built into native WCF enables me to talk my custom STS - equipped to consider the entropy supplied in the RST. Adding its own entropy, it even formulates a per-recipient-token in the subject field of the SAML assertion delivered in the response - an RSA-wrapped key derived from the 2 elements of entropy. WIF libraries, equipped with resolvers for the asymmetric wrapping key, unwrap the key within - just fine.
Below, I show the WCF client - that logically has no access to the intended-recipient's private key - used in unwrapping, as above.
IssuedSecurityTokenProvider provider = new IssuedSecurityTokenProvider();
provider.SecurityTokenSerializer = new WSSecurityTokenSerializer();
//Relying Party's identifier
provider.TargetAddress = new EndpointAddress(new Uri("https://me:44303/FederationSample/BookStoreService/store.svc"));
provider.IssuerAddress = new EndpointAddress(new Uri(baseUri));
provider.SecurityAlgorithmSuite = SecurityAlgorithmSuite.Basic256;
provider.MessageSecurityVersion = MessageSecurityVersion.WSSecurity10WSTrustFebruary2005WSSecureConversationFebruary2005WSSecurityPolicy11BasicSecurityProfile10;
HttpsTransportBindingElement tbe = new HttpsTransportBindingElement();
tbe.AuthenticationScheme = AuthenticationSchemes.Negotiate;
CustomBinding stsBinding = new CustomBinding(tbe);
provider.IssuerBinding = stsBinding;
provider.Open();
//Request a token from ADFS STS
SecurityToken issuedToken = provider.GetToken(TimeSpan.FromSeconds(30));
In this NON-WIF world, does the issuedToken.securitykeys have the client's COMPUTED proof-key?
ie, for a computed key regimed, is this the value computed from considering the RSTR's server-side entropy, the algorithm for key-computation, and the stored copy of its client entropy - all of which WOULD logically be used to calculate the (never-wrapped) client-side key to be applied to HOK processes (i.e. Red Book proof of origin/receipt/deliver security services)?