Well, I do override DefaultSubjectProvider, but only to change the default KeyType when it's not specified, and to set the NameID format, prior to calling super.getSubject.
I haven't set any signatureCrypto properties in my StaticSTSProperties instance, I missed that I needed to do that. I'll work on setting that up and see what happens. Thanx! Stephen W. Chappell From: Colm O hEigeartaigh <[email protected]> ANG-B31, Information Security Branch To: "[email protected]" <[email protected]>, Date: 05/06/2014 09:47 AM Subject: Re: Validation of X.509 certificate in RST/UseKey in CXF STS > 1. If some-encoded-cert is expired, the STS is issuing a token for it > anyway. I have configured a TokenIssueOperation with a list of > tokenValidators, that includes an instance of an > org.apache.cxf.sts.token. > validator.X509TokenValidator. Shouldn't the > X509TokenValidator be checking for expiration, issuer trust, revocation, > and so on? Or will I need to derive a custom validator to handle that? The DefaultSubjectProvider verifies trust in the UseKey certificate, assuming that the STS's Signature Crypto instance is not null: https://git-wip-us.apache.org/repos/asf?p=cxf.git;a=blob_plain;f=services/sts/sts-core/src/main/java/org/apache/cxf/sts/token/provider/DefaultSubjectProvider.java;hb=refs/heads/2.7.x-fixes Are you plugging in a custom SubjectProvider implementation, or not supplying a Signature Crypto instance? > 2. A more fundamental problem is that the certificate provided in the > UseKey is supposed to match the certificate used to sign the RST (or > validate the signature, rather). In our profile, the RST must be signed, > with the certificate provided as a BST in the WSSE header. The UseKey > element is allowed to be a SecurityTokenReference to the BST, or to be a > copy of that certificate. I'm specifically working on the case where the > UseKey is a copy of the signing cert and not a reference. I would guess > that I would need a custom validator for this, which is fine, but I'm not > sure how I can access the BST to do a compare? Look at the SCTCanceller here: https://git-wip-us.apache.org/repos/asf?p=cxf.git;a=blob;f=services/sts/sts-core/src/main/java/org/apache/cxf/sts/token/canceller/SCTCanceller.java;h=7d2448780290ee7eab9efb3bd4ae007e5ddbdbd7;hb=refs/heads/2.7.x-fixes To cancel a SecurityContextToken, you must verify proof of possession. In particular, look at the matchKey method. Colm. On Tue, May 6, 2014 at 1:20 PM, <[email protected]> wrote: > Hi - > > In my STS, the RST message is supposed to include a UseKey element like > so: > > <UseKey> > <ds:KeyInfo> > <ds:X509Data> > <ds:X509Certificate>some-encoded-cert</ds:X509Certificate> > </ds:X509Data> > </ds:KeyInfo> > </UseKey> > > > I'm having two issues with it.... > > 1. If some-encoded-cert is expired, the STS is issuing a token for it > anyway. I have configured a TokenIssueOperation with a list of > tokenValidators, that includes an instance of an > org.apache.cxf.sts.token.validator.X509TokenValidator. Shouldn't the > X509TokenValidator be checking for expiration, issuer trust, revocation, > and so on? Or will I need to derive a custom validator to handle that? > > 2. A more fundamental problem is that the certificate provided in the > UseKey is supposed to match the certificate used to sign the RST (or > validate the signature, rather). In our profile, the RST must be signed, > with the certificate provided as a BST in the WSSE header. The UseKey > element is allowed to be a SecurityTokenReference to the BST, or to be a > copy of that certificate. I'm specifically working on the case where the > UseKey is a copy of the signing cert and not a reference. I would guess > that I would need a custom validator for this, which is fine, but I'm not > sure how I can access the BST to do a compare? > > Thanx, > > > Stephen W. Chappell > -- Colm O hEigeartaigh Talend Community Coder http://coders.talend.com
