Colm -
Now that I am looking at it, I have this in my StaticSTSProperties:
<bean id="globalSTSProperties"
class="org.apache.cxf.sts.StaticSTSProperties">
<property name="signatureProperties"
ref="bstSignatureProperties"/>
<property name="signaturePropertiesFile"
value="stsKeystore.properties" />
<property name="signatureUsername" value="mystskey" />
<property name="callbackHandler" ref="iamStsCallbackHandler" />
<property name="encryptionPropertiesFile"
value="stsKeystore.properties" />
</bean>
with this in my stsKeystore.properties file ....
org.apache.ws.security.crypto.merlin.keystore.type=jks
org.apache.ws.security.crypto.merlin.keystore.password=<password>
org.apache.ws.security.crypto.merlin.keystore.alias=<keyalias>
org.apache.ws.security.crypto.merlin.keystore.file=stsstore.jks
Do I need to set some additional properties or explicitly create a
signatureCrypto object? It looks like that should happen by virtue of
setting the properties file, but I could certainly be missing something.
The certificate that I am testing with was issued by a trusted issuer, but
it has expired, which I thought would have caused it to be rejected.
Thanx,
Stephen W. Chappell
From: Stephen CTR Chappell/ACT/CNTR/FAA@FAA
ANG-B31, Information Security Branch
To: [email protected],
Date: 05/06/2014 10:09 AM
Subject: Re: Validation of X.509 certificate in RST/UseKey in CXF
STS
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
