Security Token Service Issues

Hi,

I'm trying to utilize the STS sample that was provided by Martin Gudgin. I have gotten the client to successfully request a security token based, and I can see the request coming into the STS and the token being issued. However, once the token is issued, and the service is contacted, I get the following error in the server diagnostics logs:

The SecurityKeyIdentifier that was found in the SamlSubject cannot be resolved to a SecurityToken. The SecurityTokenResolver must contain a SecurityToken that the SecurityKeyIdentifier resolves to.

I have both the client and server utilizing the wsFederationHttpBinding elements, and both are contacting the STS via identically configured wsHttpBindings. I've included the configuration entries below for reference.

<wsFederationHttpBinding>
<binding name="FederatedSecurity">
<security mode="Message">
<message issuedKeyType="SymmetricKey"
algorithmSuite="Basic256"
issuedTokenType="http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.1#SAMLV1.1"
negotiateServiceCredential="true">
<issuer address="http://localhost:8000/sts/x509" binding="wsHttpBinding" bindingConfiguration="ReliableHttp">
<identity>
<dns value="sts.com" />
</identity>
</issuer>
</message>
</security>
</binding>
</wsFederationHttpBinding>

<wsHttpBinding>
<binding name="ReliableHttp">
<reliableSession enabled="true" ordered="true"/>
<security mode="Message">
<message clientCredentialType="Certificate" />
</security>
</binding>
</wsHttpBinding>

I'm not certain where to go from here. All the various server/client certificates are located in the appropriate stores [I think] to allow the trust relationships to work properly. An interesting note is that during debugging on the STS, I get a message that the tokens.SecurityKeys.Count: 0, which seems odd, but maybe that's expected?

Any help would be appreciated.

Thanks!

[2560 byte] By [TheJet] at [2007-12-24]
# 1
One of the causes for your problem might be this:

- The STS must know the Server certificate, in order to encrypt the SAML subject confirmation information to the Server. For this, the STS ONLY needs the public key inside the certificate and NOT the private key (the encryption process only needs a public key). In Gudgin's STS, this certificate lookup is done at SecurityTokenService.cs, line 309 (the original source code looks for the "CN=localhost" certificate)

- However, the Server must have the private key associated with that certificate in order to decrypt the SAML subject confirmation information.

From the exception message that you've post, it seems that the Server cannot lookup the private key needed to decrypt the confirmation information in the SAML subject.
Does your Server have the certificate used by the STS for subject confirmation encryption? Does it have an associated private key? This certificate should be configured in the service credentials.

Hope it helps
Pedro Felix

PedroFelix at 2007-10-7 > top of Msdn Tech,Visual Studio Orcas,Windows Communication Foundation (Indigo)...
# 2

Okay,

I've gotten a little further, the error message is now slightly different. The error message I see now is:

Unable to resolve SecurityKeyIdentifier found in the SamlAssertion signature. The SamlAssertion signature can not be validated for the Issuer GudgeSTS.

Now, I would guess, based on the information posted above, that my service is unable to find the public key for the GudgeSTS [I'm using a certificate called "sts.com"]. This certificate is located in the TrustedPeople store on both the CurrentUser and LocalMachine stores [as well as existing in the LocalMachine 'My' store where it is referenced by the STS service], and I'm running both the client and services in a custom self-hosting console app.

So, it appears that I can successfully decrypt the security token, but the signing information can't be verified as coming from the STS..? Or am I reading the error message incorrectly.

Thanks!

TheJet at 2007-10-7 > top of Msdn Tech,Visual Studio Orcas,Windows Communication Foundation (Indigo)...
# 3

As an additional followup, looking at the ClaimAuthorization sample, there is a setting for "TrustedIssuers" which is set programmatically. Now, this has changed in the June CTP to something else, but is there a way to specify the list of "trusted issuers" in my service configuration file? I've tried both setting the identity element of the issuer element to both a DNS value of "sts.com" and a certificate reference which points to the certificate being used by the STS. Neither of these settings changes the end result, the error [as listed above] still remains.

EDIT: I've found something that looks promising, the issuedTokenAuthentication element within serviceCredentials, but now I'm getting an error about an untrusted certification chain and the configuration file doesn't seem to expose the setting on the IssuedTokenServiceCredentials object to set the certificate validation mode :( Any ideas on this one, other than hacking into our custom service host test harness?

TheJet at 2007-10-7 > top of Msdn Tech,Visual Studio Orcas,Windows Communication Foundation (Indigo)...
# 4
The trust relation between the service and the STS (the service trusting the token signatures made by the STS) is configured in the following property

credentials.IssuedTokenAuthentication.KnownCertificates

where "credentials" is the service credentials object.
You should add the STS certificate to this collection.

I've found this information in the following slides: http://wcf.netfx3.com/files/folders/teched_2006_chalk_talks/entry3745.aspx

Hope it helps.
Pedro Felix

PedroFelix at 2007-10-7 > top of Msdn Tech,Visual Studio Orcas,Windows Communication Foundation (Indigo)...
# 5

Heh, seems we've stumbled onto the same solution, at this point, it looks like I'll have to resort to some code fixes [or go through the trouble of getting fully trusted certs], because all the tweakables aren't exposed as configuration fields.

TheJet at 2007-10-7 > top of Msdn Tech,Visual Studio Orcas,Windows Communication Foundation (Indigo)...
# 6

Okay,

To get things working, I have created the following element in my configuration file:

<issuedTokenAuthentication>
<knownCertificates>
<add findValue="sts.com"
storeLocation="LocalMachine"
storeName="My"
x509FindType="FindBySubjectName" />
</knownCertificates>
</issuedTokenAuthentication>

And I also needed to put the following line of code into my custom service host implementation, which allowed me to successfully verify the token assuming that the STS cert was in my TrustedPeople store:

host.Credentials.IssuedTokenAuthentication.CertificateValidationMode = Security.X509CertificateValidationMode.PeerOrChainTrust

TheJet at 2007-10-7 > top of Msdn Tech,Visual Studio Orcas,Windows Communication Foundation (Indigo)...
# 7
The documentation is not clear, but it seems that setting the "AllowUntrustedRsaIssuer" property to true lets you use certificates without trustes issuers. This property can be setted in the config file.
However, I've never tried it and the SDK documentation is not clear.

Hope it helps
Pedro Felix

PedroFelix at 2007-10-7 > top of Msdn Tech,Visual Studio Orcas,Windows Communication Foundation (Indigo)...
# 8

Yes, I originally tried just setting that flag, but it doesn't appear to actually do anything at this time. There is also no documentation in the JuneCTP to indicate what the flag is intended to do/allow. The IssuedTokenAuthentication class has settings for both the AllowUntrustedRsaIssuer and the CertificateValidationMode setting, so it does seem like there's a bit of a conflict. Is it possible that the flag is used to allow you to accept tokens from STS's which you don't have entered in the KnownCertificates section? And if so, does that also default to not requiring that the certificates be known valid? The lack of documentation around this stuff [and the constant changing from release to release] gets a bit wearying after a while.

TheJet at 2007-10-7 > top of Msdn Tech,Visual Studio Orcas,Windows Communication Foundation (Indigo)...
# 9
The July CTP SDK says the following regarding theAllowUntrustedRsaIssuer property "true if untrusted RSA token issuers are allowed; otherwise, false. The default is false."
After reflecting a little (using reflector) I found that this property is associated to the usage of RsaSecurityToken security tokens and not X.509 tokens. So apparently it doesn't solve our problem :(

Best regards
Pedro Felix

PedroFelix at 2007-10-7 > top of Msdn Tech,Visual Studio Orcas,Windows Communication Foundation (Indigo)...

Visual Studio Orcas

Site Classified