| Re: [higgins-dev] STS Certificate Usage |
|
Mike,
Are you ok if I just go ahead and check in the proposed fix to MetadataExchangeService.java?
Daniel
>>> Michael McIntosh <mikemci@xxxxxxxxxx> 5/2/2008 5:24 PM >>> Daniel, I agree - please enter a bugzilla and ref your email message. Regards, Mike higgins-dev-bounces@xxxxxxxxxxx wrote on 05/02/2008 03:23:56 PM: > Mike, > > We would like to use a certificate other than our IdP STS SSL > certificate to sign tokens. At first glance, it appeared that the > Higgins STS had provided for this by having two different settings > in the configuration file: IssuerCertificate and SSLCertificate. > However, when we tried to make them different we ran into problems. > > The IssuerCertificate is inserted into the mex policy in place of > the "urn:CERTIFICATE" string (see MetadataExchangeService.java). It > is also used to sign tokens (see TokenGeneratorHandler.java). It > appears that SSLCertificate is only used in the ProfileService. If > the certificate inserted into the mex data is not SSL certificate of > the IdP STS, CardSpace will complain. You get an error in the event > log stating that the IdP's SSL certificate thumbprint does not match > the thumbprint of the certificate in the mex data. We asked > Microsoft about this, and this was their response: > > "CardSpace checks that the same identity cert in the mex policy is > the same cert used to set up a channel with the sts. This is to > build a chain of trust from the policy, to the IP STS." > > They also point out that the token signing certificate can be > different than the identity cert in the mex policy. > > The problem in the Higgins STS is that if we insert the > IssuerCertificate in the mex data, it means that IssuerCertificate > has to be the same as the SSL cert for the IdP STS. Because > IssuerCertificate is also used for token signing, it effectively means that: > > IssuerCertificate == IdP STS SSL Certificate == token signing certificate > > We are effectively left in a situation where the signing certificate > has to be the same as the SSL certificate. It doesn't seem that > this was intentional, but perhaps an oversight. We would like to be > able to get away from that limitation and use use a different > certificate than the SSL certificate for token signing. > > It appears that this problem could be fixed very easily by modifying > MetadataExchangeService.java to insert the SSLCertificate into the > mex data instead of the IssuerCertificate, and then only use > IssuerCertificate for token signing. > > Does this seem like the right solution to you? > > Thank you, > > Daniel Sanders > _______________________________________________ > higgins-dev mailing list > higgins-dev@xxxxxxxxxxx > https://dev.eclipse.org/mailman/listinfo/higgins-dev _______________________________________________ higgins-dev mailing list higgins-dev@xxxxxxxxxxx https://dev.eclipse.org/mailman/listinfo/higgins-dev |