You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cxf.apache.org by St...@faa.gov on 2014/05/06 14:20:44 UTC
Validation of X.509 certificate in RST/UseKey in CXF STS
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
Re: Validation of X.509 certificate in RST/UseKey in CXF STS
Posted by St...@faa.gov.
Actually, this issue may resolve itself. If I can verify that the UseKey
cert is the same as the cert that signed the RST, then I shouldn't need to
repeat the checks on the UseKey cert. My issue right now is that the
UseKey cert I'm sending is different from the RST cert, which violates our
profile. When I sign the message with an expired cert that is checked and
rejected appropriately, so if I can verify that they are the same then I
should be covered.
Stephen W. Chappell
From: Stephen CTR Chappell/ACT/CNTR/FAA@FAA
ANG-B31, Information Security Branch
To: users@cxf.apache.org,
Date: 05/06/2014 11:32 AM
Subject: Re: Validation of X.509 certificate in RST/UseKey in CXF
STS
The certificate in question is not in the keystore, only the trust chain
for the issuer and the STS's own keys.
I'm not set up with a debugger right at the moment, I'll get something
setup and get back to you.
Stephen W. Chappell
From: Colm O hEigeartaigh <co...@apache.org>
ANG-B31, Information Security Branch
To: "users@cxf.apache.org" <us...@cxf.apache.org>,
Date: 05/06/2014 10:59 AM
Subject: Re: Validation of X.509 certificate in RST/UseKey in CXF
STS
Is the certificate in question in your keystore? I think if it is, it does
not check expiry. However, cert path validation should fail if the CA of
the certificate is in the keystore, and the cert is expired.
If only the CA of the certificate is in the signature keystore, could you
verify with a debugger that it is actually hitting Merlin's verifyTrust
method with the UseKey certificate?
Colm.
On Tue, May 6, 2014 at 3:14 PM, <St...@faa.gov> wrote:
> 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: users@cxf.apache.org,
> 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 <co...@apache.org>
> ANG-B31, Information Security Branch
> To: "users@cxf.apache.org" <us...@cxf.apache.org>,
> 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, <St...@faa.gov> 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
>
>
>
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
Re: Validation of X.509 certificate in RST/UseKey in CXF STS
Posted by St...@faa.gov.
The certificate in question is not in the keystore, only the trust chain
for the issuer and the STS's own keys.
I'm not set up with a debugger right at the moment, I'll get something
setup and get back to you.
Stephen W. Chappell
From: Colm O hEigeartaigh <co...@apache.org>
ANG-B31, Information Security Branch
To: "users@cxf.apache.org" <us...@cxf.apache.org>,
Date: 05/06/2014 10:59 AM
Subject: Re: Validation of X.509 certificate in RST/UseKey in CXF
STS
Is the certificate in question in your keystore? I think if it is, it does
not check expiry. However, cert path validation should fail if the CA of
the certificate is in the keystore, and the cert is expired.
If only the CA of the certificate is in the signature keystore, could you
verify with a debugger that it is actually hitting Merlin's verifyTrust
method with the UseKey certificate?
Colm.
On Tue, May 6, 2014 at 3:14 PM, <St...@faa.gov> wrote:
> 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: users@cxf.apache.org,
> 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 <co...@apache.org>
> ANG-B31, Information Security Branch
> To: "users@cxf.apache.org" <us...@cxf.apache.org>,
> 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, <St...@faa.gov> 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
>
>
>
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
Re: Validation of X.509 certificate in RST/UseKey in CXF STS
Posted by Colm O hEigeartaigh <co...@apache.org>.
Is the certificate in question in your keystore? I think if it is, it does
not check expiry. However, cert path validation should fail if the CA of
the certificate is in the keystore, and the cert is expired.
If only the CA of the certificate is in the signature keystore, could you
verify with a debugger that it is actually hitting Merlin's verifyTrust
method with the UseKey certificate?
Colm.
On Tue, May 6, 2014 at 3:14 PM, <St...@faa.gov> wrote:
> 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: users@cxf.apache.org,
> 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 <co...@apache.org>
> ANG-B31, Information Security Branch
> To: "users@cxf.apache.org" <us...@cxf.apache.org>,
> 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, <St...@faa.gov> 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
>
>
>
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
Re: Validation of X.509 certificate in RST/UseKey in CXF STS
Posted by St...@faa.gov.
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: users@cxf.apache.org,
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 <co...@apache.org>
ANG-B31, Information Security Branch
To: "users@cxf.apache.org" <us...@cxf.apache.org>,
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, <St...@faa.gov> 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
Re: Validation of X.509 certificate in RST/UseKey in CXF STS
Posted by St...@faa.gov.
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 <co...@apache.org>
ANG-B31, Information Security Branch
To: "users@cxf.apache.org" <us...@cxf.apache.org>,
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, <St...@faa.gov> 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
Re: Validation of X.509 certificate in RST/UseKey in CXF STS
Posted by St...@faa.gov.
Hi Colm -
Thanks for the reference to the SCTCanceller matchKey method, with a few
tweaks that does exactly what I needed. The only glitch I had was that
when I loop through the WSSecurityEngineResult's, the signing certificate
(which comes over in a wsse:BinarySecurityToken) is hashed with
TAG_X509_CERTIFICATE rather than with TAG_BINARY_SECURITY_TOKEN. Not
really an issue, just a little weird.
In any case, thanx for you help, I appreciate it!
Stephen W. Chappell
From: Colm O hEigeartaigh <co...@apache.org>
ANG-B31, Information Security Branch
To: "users@cxf.apache.org" <us...@cxf.apache.org>,
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, <St...@faa.gov> 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
Re: Validation of X.509 certificate in RST/UseKey in CXF STS
Posted by Colm O hEigeartaigh <co...@apache.org>.
> 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, <St...@faa.gov> 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