Hm, well multiple typos was the actual problem for question #2, so I think I am
good. Thanx.
-Original Message-
From: Chappell, Stephen CTR (FAA)
Sent: Friday, August 18, 2017 11:28 AM
To: users@cxf.apache.org
Subject: Keystore Properties Encrypt/Decrypt w/ STS
I'm working on adding
I'm working on adding property encryption/decryption to my STS configuration
using Jasypt, with CXF 3.1.12. Integrating my Spring properties file works
fine, but I'm trying to encrypt/decrypt in the keystore properties as well, as
described at
You're right, I was working from memory instead of looking at the code.
DefaultSubjectProvider gets the Principal from the ActAs if there is one ...
public SubjectBean getSubject(
TokenProviderParameters providerParameters, Document doc, byte[] secret
) {
...
If an RST contains an ActAs element that contains a SAML Assertion, the STS is
supposed to stick that Assertion into the Advice element of the new Assertion
it is creating. The STS doesn't do that by default but as I recall I
implemented a SAML custom handler to do that. What the STS does do by
Hi -
When I send an RST to my STS (CXF 2.7.14) to get a holder-of-key token with
Advice, it looks like the token I get back has a Subject that matches the X509
cert in the Advice rather than its own cert. It looks like it's supposed to be
this way based on what I see in DefaultSubjectProvider,
Neglected to mention - this is with CXF 3.1.0 / WSS4J 2.1.2. Thanx.
Stephen W. Chappell
-Original Message-
From: Chappell, Stephen CTR (FAA)
Sent: Wednesday, August 03, 2016 7:51 AM
To: users@cxf.apache.org
Subject: Configure STS client on jaxws:endpoint
In certain use cases, I have a
In certain use cases, I have a requirement for the server to retrieve a SAML
token from our STS and stick it in the response message. It's pretty clear I
think how to do this on the client side via the security.sts.client property.
Is this property also used on the server side, or will I need
Oh, well that explains it then. Thanx!
Stephen W. Chappell
From: Colm O hEigeartaigh [mailto:cohei...@apache.org]
Sent: Wednesday, March 23, 2016 8:45 AM
To: Chappell, Stephen CTR (FAA)
Cc: users@cxf.apache.org
Subject: Re: STSClient.validateSecurityToken expects
Solved. Sucking in the WSDL and using the WS-SecurityPolicy did the trick, once
I set up the ws-security.signature.* properties in the property map. One weird
thing though is that I had to explicitly set the signature algorithm ...
...
I was used to using the interceptors from other projects, so I didn’t really
give it any thought; but it does make more sense to use the policy approach.
Now if I can just get the property map configured right …
Stephen W. Chappell
From: Colm O hEigeartaigh [mailto:cohei...@apache.org]
Sent:
Yeah, that is exactly what my wsdl looks like. I think the problem is that I
didn't specify a wsdlLocation in my client bean, only a location. That worked
fine for the issue operation, but not at all for validate. So I tried
configuring that and ran into some new problems, which I think is
Hi -
I'm using the CXF 3.1.4 STSClient to write a simple test client for my
CXF-based STS. Requesting tokens has worked as expected, but requesting
validation of a token is having a problem. It would appear that STSClient
creates a proper RST, and gets a proper RSTR from the STS. But something
No, I'm not configuring an AttributeStatementProvider, at least not yet. Bearer
tokens are an edge case for us so I probably haven't given them quite enough
attention. The default AttributeStatement should be fine for us in this case
though.
Thanx,
Stephen W. Chappell
-Original
I've recently done some work migrating my STS implementation from using CXF
2.7.14 up to 3.1.4. In testing the upleveled STS, I noticed that a change crept
in somewhere along the way when requesting a bearer token - in CXF 3, the
returned token has an additional AttributeStatement:
In our SAML profile, a SAML token issued with Advice should have a NotOnOrAfter
condition that does not come after the Advice token's NotOnOrAfter condition.
But apparently, the CXF STS (2.7.14) doesn't consider Advice conditions when
issuing a new token? If it doesn't I can add that capability
That's the problem, I failed to called WSSConfig.init(). Somehow I missed that
I needed to do that. Thanx.
Stephen W. Chappell
-Original Message-
From: Colm O hEigeartaigh [mailto:cohei...@apache.org]
Sent: Wednesday, July 29, 2015 4:55 AM
To: us...@ws.apache.org
Cc:
When processing a message with a malformed timestamp, I'm getting the following
detail text back in my WSSecurityException:
org.apache.wss4j.common.ext.WSSecurityException: No message with ID
invalidTimestamp found in resource bundle
org/apache/xml/security/resource/xmlsecurity
Am I missing a
Thanx, Colm. There's a few more things that have migrated somewhere that I'm
having trouble finding ...
1. WSSecurityUtil used to have some DOM methods that mostly look like they were
moved to XMLUtils. But there's one I can't find - storeElementInContext. Is
that one still around, or will I
In my ongoing quest to upgrade legacy code, I've noticed a slimming down of
what's held in WSSConfig objects. That's fine, but I'm having trouble figuring
out where things have moved, or if the things I'm looking for are
necessary/relevant anymore. Here's a couple of specific cases:
1. At one
Thanx, Colm. This isn't an immediate need, so we should be able to wait for the
next release.
Stephen W. Chappell
-Original Message-
From: Colm O hEigeartaigh [mailto:cohei...@apache.org]
Sent: Monday, June 22, 2015 5:43 AM
To: users@cxf.apache.org
Subject: Re: Querying for the
When processing a security header, you can determine the key transport
algorithm through WSSecurityEngineResult.TAG_ENCRYPTED_KEY_TRANSPORT_METHOD. Is
there a similar tag that lets you query the new Encryption MGF Algorithm? I
couldn't' find anything in WSSecurityEngineResult. Thanx.
Stephen
Some time ago, with WSS4J 1.6.x, I had a problem where if I was building a SAML
token that contained another signed SAML token in its Advice, the signature on
the inner token would be stripped clean - there'd be an element, but it would
have empty SignatureValue/ and DigestValue/ elements. The
Colm - that appears to have done the trick, thanx!
Stephen W. Chappell
-Original Message-
From: Colm O hEigeartaigh [mailto:cohei...@apache.org]
Sent: Thursday, June 18, 2015 6:42 AM
To: users@cxf.apache.org
Cc: us...@ws.apache.org
Subject: Re: NPE when calling
For what it is worth, Colm, I was able to crib your fix for the parser pool off
of Fisheye and stick it in my own code for the time being. With that in place
and the custom code below to set the signature, I end up with a signed SAML
assertion with advice that has the signature intact.
Thanx,
I'm having a problem with new validation that occurs for SAML tokens. Here is
the exception I am getting when a token containing an audience restriction is
received:
org.apache.cxf.binding.soap.SoapFault: A security error was encountered when
verifying the message
at
I think I answered my own question; I needed to set
ws-security.validate.audience-restriction to false on the server endpoint, per
Colm's blog entry at
http://coheigea.blogspot.com/2015/02/new-saml-validation-changes-in-apache.html.
Thanx,
Stephen W. Chappell
-Original Message-
In migrating some code up to WSS4J 2.1 (from 1.6.17), I'm getting an unexpected
NullPointerException where I previously did not. When calling this:
Node content = sa.toDOM(null); // sa is a SamlAssertionWrapper
I get this:
Caused by: java.lang.NullPointerException
at
Ok, I solved this one. I'm not even sure why I ever thought it worked the way I
had it. This is probably obvious to mostly everyone, but for anyone who is
interested, this is what I found: the schema for the wsa:addressing feature
lists messageIdCache as being an attribute on the addressing
Hi -
I have a requirement to prevent duplicate message id's for a period of at least
5 minutes, but not forever. It looks like the DefaultMessageIdCache will cache
them forever. So, some time ago, I implemented a custom cache that derives from
org.apache.cxf.ws.addressing.MessageIdCache, and
Colm –
That is the case, at least I thought it was. The truststore has certs for the
issuer, intermediate, and root CA, plus a few other miscellaneous certs. I’ll
run it through the debugger later this morning and see what turns up.
Stephen W. Chappell
From: Colm O hEigeartaigh
Well, that must be the issue. I just ran it through the debugger, and
getCertificateChain is returning null each time. I’ve added code in my
subclassed Merlin to be able to walk up the tree, but it’d be more efficient if
the truststore was built properly so I’ll try to figure that out.
Stephen
Thanx, Vishnu. I saw that, and spent most of the morning trying to build a cert
chain that way. I started with PEM certs, cat'd them together in the correct
order, converted them to PKCS7 with openssl crl2pkcs7, and imported the pkcs7
with keytool. In every case, keytool only imported one cert,
Colm -
This seems like it should be easier than it is, but can you point me to a
resource for properly building a truststore with a certificate chain? I have
separate keystores and trust stores for the STS, and the truststore should have
a chain something like:
Root CA Intermediate CA
I thought I needed PKCS7, not PKCS12?
Stephen W. Chappell
-Original Message-
From: Vishnu Radhakrishnan [mailto:vis...@10point1.com]
Sent: Tuesday, April 07, 2015 11:01 AM
To: users@cxf.apache.org; cohei...@apache.org
Subject: Re: Using a custom CertPathChecker
keytool -list -storetype
So here is where I am at ...
* If I cat the certificate pem files together, only one cert ever gets imported
no matter the order of cat'ing. Removing the - BEGIN and END tags
doesn't help at all
* If I use openssl crl2pkcs7 to create a pkcs7 file containing all the certs,
keytool
Vishnu, I don't have a private key, that was my point. I'm trying to build a
cert chain in a trust store from a root ca, an intermediary, and an issuing ca.
Stephen W. Chappell
-Original Message-
From: Vishnu Radhakrishnan [mailto:vis...@10point1.com]
Sent: Tuesday, April 07, 2015
Colm -
While I was mucking around in Merlin, I noted that in the second step section
of verifyTrust, only the immediate issuer of the cert to be checked is added to
the cert path (at least in my case, when getX509Certificates only returns a
single cert rather than a cert chain). I have a
I have a requirement to use a custom CertPathChecker in my code. With bare
JVM, I can add the checker to my PKIXParameters and validate away. But, using
Merlin (in WSS4J 1.6.17), there don't appear to be any hooks to add a custom
checker or customize the PKIXParameters that are being used. Is
Well, the issue I'm having is definitely occurring during the signing
operation. The handleActAs method below is called by my SamlCustomHandler's
handle method, which I neglected to post earlier because it's main mission in
life is to route between a SAML1 custom handler and a SAML2 custom
I've fixed this issue locally. For anyone who is interested, my fix is this:
when the RST has ActAs, I disable signing in the SAMLTokenProvider (see below),
then perform my own signature within my SAMLCustomHandler. My signature mostly
reuses the WSS4J code, but I don't perform any of the DOM
I am revisiting some STS code I was working on some time ago and found a sort
of major bug. I have a requirement to issue tokens with Advice when my RST has
an ActAs. At the time, I implemented that using a SAMLCustomHandler derivative,
which seemed to work until I started writing validators.
I have some requirements to add some additional profile checks to our STS SAML
token validation. Looking over the 2.7.14 SAMLTokenValidator, it looks like
tokens contained in Advice are not validated. Is that correct, or is Advice
validation kicked off somewhere else? I'm required to ensure
Colm - Thanx. I figured this one out - it was an issue with the Assertion DOM,
which I've fixed. Thanx !
Stephen W. Chappell
-Original Message-
From: Colm O hEigeartaigh [mailto:cohei...@apache.org]
Sent: Tuesday, November 25, 2014 5:02 AM
To: users@cxf.apache.org
Subject: Re:
I'm occasionally getting the below exception thrown out when (I think) WSS4J
tries to sign an Assertion. I can see the referenced ID getting created by the
AssertionWrapper, but sometime after that this exception is coming out, but
only under certain conditions that I'm still trying to
Thanx again, Colm! That was the issue - the assertion wasn't being properly
added to the security header. Thanx!
Stephen W. Chappell
Thanx, Colm. But the storeElementInContext() method is looking for a
domCryptoContext, that is created during computeSignature. I'm guessing I'll
have to override computeSignature to do that?
Stephen W. Chappell
-Original Message-
From: Colm O hEigeartaigh [mailto:cohei...@apache.org]
Colm -
That seems to resolve that issue, thanx! But now I have another issue - the
thing the STR refers to (the SAML assertion) can't be resolved. Here is the
exception that I get:
Caused by: org.apache.ws.security.WSSecurityException: Signature creation failed
at
Colm –
Doing that leads to another exception …
Caused by: javax.xml.stream.XMLStreamException: Trying to write END_DOCUMENT
when document has no root (ie. trying to output empty document).
at
com.ctc.wstx.sw.BaseStreamWriter.throwOutputError(BaseStreamWriter.java:1537)
No, not really, and it would be pretty difficult to extract some code to make
one. As I said, this is a large set of legacy code that I'm trying to migrate
up to CXF 2.7 / WSS4J 1.6. The original authors customized and overrode
CXF/WSS4J in a way that further complicates building a test case.
It turns out that I haven't completely resolved my issues from earlier, but I
think I'm in the home stretch (hopefully). In the code I'm migrating (from CXF
2.3 to CXF 2.7), the original authors created a WSSecSignature descendant that
does some security header customization, including
Ok, I've done some more investigation and realized that my question is really a
bit deeper than what I originally thought. I apologize in advance for the
lengthy post. In this large, legacy CXF 2.3 / WSS4J 1.5 based code that I have,
the intent is to add a SAML Assertion to a message as a
Well, I'm either making progress or finding more places to bog down in. As
before, I am still trying to insert a SAML assertion into the WS-Security
header as a signed supporting token. This is in part being handled by a
descendant class of WSSecSignature, which includes a local version of
In some legacy code that I am (still) migrating up to CXF 2.7 / WSS4J 1.6, we
have a class that extends WSSecSignature and overrides addReferencesToSign, in
order to add a transform for an Assertion. It looks like the way transforms are
done has changed significantly, so there's a bit that I
Colm -
Thanx, it looks like that was exactly the problem - my endpoint configuration
did not have a depends-on entry. I had scoured the doc at
http://cxf.apache.org/docs/jetty-configuration.html, but didn't see anything
obvious, so I assumed I was missing something elsewhere. I'm glad this was
I am migrating some (more) legacy code up to CXF 2.7 from 2.3. The code used to
build and run fine, but now I'm getting an exception (trimmed to the relevant
part) ...
Caused by: java.io.IOException: JSSE Security Exception
at
Yeah, I was afraid of something like that. It's caused a few problems here and
there elsewhere in my code as well. Back to the drawing board, I suppose...
Stephen W. Chappell
-Original Message-
From: Colm O hEigeartaigh [mailto:cohei...@apache.org]
Sent: Thursday, October 09, 2014 5:07
Well, what I got back from the OpenSAML list is not helpful. This is what they
had to say:
it looks questionable to me that you're dropping the DOM at the end, because I
don't recall the Java code ever having full round trip fidelity when the DOM
isn't cached, particularly when signatures are
Colm -
It looks like I have a solution for this. I had extracted some code to post to
the OpenSAML list, and posted the problem over there. While waiting for
something to happen, I tried a few things with the extracted code, mostly with
no positive changes. But then I tried this change, and
Thanx, Colm. I'll rework it using the OpenSAML API's directly as you suggest
and pursue it that way.
Stephen W. Chappell
-Original Message-
From: Colm O hEigeartaigh [mailto:cohei...@apache.org]
Sent: Monday, October 06, 2014 5:37 AM
To: users@cxf.apache.org
Subject: Re: Weird
In CXF 2.7.12, I'm having a weird problem when signing a SAML 1.1 assertion,
when the assertion contains another assertion in the Advice element. All SAML
assertions are required to be signed by the issuer, including assertions
embedded in the Advice element. But what is happening is that when
For any who are interested, it looks like I've solved this particular issue. I
had to retrieve the X.509 certificate from the Signature, build a SAMLKeyInfo
object, then use AssertionWrapper's verify to validate the signature. I also
needed a few extra packages in my pom. Here's some code,
In the legacy code that I am porting up to CXF 2.7, there is some code that
gets a SAML assertion from an STS and verifies the signature:
SecurityToken token = this.stsClient.requestSecurityToken();
SAMLAssertion assertion = new SAMLAssertion(token.getToken());
I'm working on migrating some legacy code I've been stuck with from CXF
2.3/WSS4J 1.5 up to CXF 2.7/WSS4J 1.6, and I'm having some troubles. The latest
issue is something that I'm sure is obvious and I'm just not seeing ... I am
getting this exception when I run one of my tests:
Thanx, Glen. I think the dependencies are there. There are several layers of
pom file to decode, but the pom file building this bit has this:
dependency
groupIdorg.apache.cxf/groupId
artifactIdcxf-rt-ws-security/artifactId
version${cxf-version}/version
scopetest/scope
Problem solved. I found a discussion here on a similar problem:
http://cxf.547215.n5.nabble.com/WS-Security-Properties-Reference-td5505704.html.
For anyone who is interested, SignaturePropRefId was used in WSS4J 1.5, but
was changed to signaturePropRefId in WSS4J 1.6.
Thanx,
Stephen W.
As usual, I spoke too soon. The problem has moved, not been solved. Now I have
this (very similar) exception, against the inInterceptor this time:
org.apache.ws.security.WSSecurityException: General security error
(WSSecurityEngine: No crypto property file supplied to verify signature)
Solved, again. Same problem, different file. Sorry about that.
Stephen W. Chappell
-Original Message-
From: Chappell, Stephen CTR (FAA)
Sent: Tuesday, September 23, 2014 2:54 PM
To: users@cxf.apache.org
Subject: RE: Help loading signature properties
As usual, I spoke too soon. The
I'm porting some legacy code to use CXF 2.7.12 that used
ContextUtils.getAction(Message) from CXF 2.3. Unfortunately, it looks like that
method was removed after 2.6 and is no longer available in 2.7. Does anyone
know, was the method moved to some other utility class, or do I need to
implement
I've inherited some legacy code that I need to update to handle SAML 2.0
assertions. Currently it handles SAML 1.1 assertions, which I still need it to
do. The legacy code uses various flavors of CXF 2.3, WSS4J 1.5, and OpenSAML 1,
so to do what I need to do I have to migrate to (at least) CXF
Thanx, Andrei. I've created Jira CXF-5913 for this issue.
Stephen W. Chappell
-Original Message-
From: Andrei Shakirin [mailto:ashaki...@talend.com]
Sent: Tuesday, July 29, 2014 6:11 AM
To: users@cxf.apache.org
Subject: RE: MapEventLogger not honoring logStacktrace?
Hi,
Seems the
I'm using org.apache.cxf.sts.event.map.MapEventLogger (from CXF
2.7.13-SNAPSHOT) to support auditing in my STS. I don't want it to log stack
traces in the audit log, so I've set the property logStacktrace to false in my
CXF bean config. But I'm getting stack traces anyway. I don't see where
Colm -
Thanx for the explanation, now it all makes sense. I'll keep an eye out for
2.7.13 then and see what I can do for a workaround in the meantime.
Thanx again,
Stephen W. Chappell
-Original Message-
From: Colm O hEigeartaigh [mailto:cohei...@apache.org]
Sent: Thursday, July 17,
I recently enabled audit logging in my STS (based on 2.7.12-SNAPSHOT), by
configuring eventListener in my TokenIssueOperation with an
org.apache.cxf.sts.event.map.EventMapper object. This works great in most
cases. But when my incoming RST contains an ActAs element, I get a
Oops, sorry about the mangled source line in my original message. This is the
line the exception is referencing...
map.put(KEYS.ONBEHALFOF_PRINCIPAL.name(),
params.getTokenRequirements().getActAs().getPrincipal().getName());
Stephen W. Chappell
-Original Message-
From: Chappell,
I'm having the same issue as Aaron, if anyone can give a few pointers. My
ultimate goal is to create an audit log as described at
http://owulff.blogspot.ch/2013/05/logging-in-apache-cxf-sts-enhanced.html. I've
done the following (running CXF 2.7.12-SNAPSHOT on Tomcat 7.0.52):
1. Added a bunch
I've made some progress, but I am not getting exactly what I expect. Using a
log4j.xml file to configure log4j does get me some logging redirected to
another file - DEBUG and INFO statements are redirected. But, I'm not getting
the audit logging I was expecting. My log4j.xml has this definition
I think I solved my issue. If anyone's interested, I had to fix the log4j.xml
config to start logging audit data to the right file now:
appender name=auditFile class=org.apache.log4j.FileAppender
param name=threshold value=DEBUG/
param name=File value=/tmp/stsaudit.log/
Well I solved both my issues. The latter issue - getting Unable to verify OCSP
Responder's signature exception no matter what signing certificate I had used
- was a responder issue, not a Java, CXF, or WSS4J issue at all. So that's
solved.
The original issue I had was that I needed to be able
Well strangely, after adding bcprov-jdk16 version 140 as a Maven dependency, I
consistently get the Unable to verify OCSP Responder's signature exception,
regardless of whether I have one OCSP signing cert or multiple OCSP signers in
the truststore. When I take out all the signing certs, I get
Well I was thinking more along the lines of completely removing it. It's
totally removed from the maven repository now, and I wasn't using it in my code
at all - I only added it as a dependency to test your theory about the ordering
of entries in the HashSet. It seems like there must be some
Andrei -
Before running your code, I ran a few tests to make sure I wasn't losing my
mind. Here's the results:
*** Test 1: STS trust store configured with only one OCSP signing certificate
(ocsp2) ...
When sending revocation checks to ocsp1, I consistently get an exception,
regardless of
Colm -
Adding bcprov-jdk16 version 140 as a Maven dependency did fix the consistency
issue - now I consistently get the Unable to verify OCSP Responder's
signature exception. I am guessing that's because of the order of certificates
in the truststore more so than anything else.
The issue I
My apologies if this is the wrong place for this question, as it's not strictly
a CXF issue, but I'm hoping someone might be able to kick me in the right
direction ...
In my architecture, the STS I am building will need to check certificate
revocation against one of a set of OCSP responders.
In order to support high availability and domain segregation requirements, our
STS deployment will likely consist of multiple STS being deployed between two
or more domains, each with their own certificate. In theory, all of the STS
should trust each other, i.e., each STS should accept tokens
Thanx, Colm, importing the STS certs should work for us. I don't think a shared
token cache is an option in our architecture but I'll definitely check it out,
thanx for the tip!
Stephen W. Chappell
-Original Message-
From: Colm O hEigeartaigh [mailto:cohei...@apache.org]
Sent:
Thanx, Andrei, I will give it a look.
Stephen W. Chappell
-Original Message-
From: Andrei Shakirin [mailto:ashaki...@talend.com]
Sent: Wednesday, May 28, 2014 8:20 AM
To: users@cxf.apache.org
Cc: Chappell, Stephen CTR (FAA)
Subject: RE: Trust between multiple STS
Hi,
If you choose
Colm -
That is great, thanx!
Stephen W. Chappell
-Original Message-
From: Colm O hEigeartaigh [mailto:cohei...@apache.org]
Sent: Monday, May 26, 2014 9:47 AM
To: users@cxf.apache.org
Subject: Re: Certificate constraints on non-signing certificates
I've merged a fix to get rid of the
In my CXF STS using 2.7.12-SNAPSHOT and running on Tomcat 7.0.52, I get several
messages in the logs whenever I undeploy the STS app:
SEVERE: The web application [/STS] created a ThreadLocal with key of type
[java.lang.ThreadLocal] (value [java.lang.ThreadLocal@84421d]) and a value of
type
88 matches
Mail list logo
