CXF 2.7.7. Service is expecting SAML 2 tokens via IssuedToken policy.
The token that the STS issued via the CXF STSClient expires after 5 minutes.
After 5 minutes is when my service is rejecting the token as expected and
throwing a SOAP fault for token expired.
Error is: SAML Token condition
Hi,
I'm trying to figure out if a workaround is feasible.
I want to have the ability to have have arbitrary xml and map that to some
generated JAX-WS Client classes and then invoke it as a regular service.
I've been able to use JAXB to map the xml string into Request Wrapper
objects generated
Hi Sergey,
thank you for the conclusion - it's good to know what the situation is. I hope
that you'll find a solution eventually.
For the time being I tried using ApplicationPath as the only working solution.
However, it has one really funny side-effect. The paths to the services contain
an
Hi
Looks like it is caused by:
On 24/04/14 07:11, Thorsten Jugert wrote:
Caused by: java.net.SocketTimeoutException: Receive timed out
at java.net.TwoStacksPlainDatagramSocketImpl.receive0(Native Method)
meaning the server is blocking probably ?
Cheers, Sergey
Hi Petr
On 24/04/14 08:55, Dolezal, Petr wrote:
Hi Sergey,
thank you for the conclusion - it's good to know what the situation is. I hope
that you'll find a solution eventually.
For the time being I tried using ApplicationPath as the only working solution. However, it has one
really funny
Hi Sergey.
I think one solution can be to combine resources and providers from multiple
applications
into a single application and serve it on a single servlet, not sure it will
make sense
in your case though, but this is something I'd try.
I was thinking about this possibility as well.
Hi
On 24/04/14 11:53, Dolezal, Petr wrote:
Hi Sergey.
I think one solution can be to combine resources and providers from multiple
applications
into a single application and serve it on a single servlet, not sure it will
make sense
in your case though, but this is something I'd try.
I was
milestone2, right I wonder if it is the endpoint overriding issue
showing itself in OSGI...
It has been disabled in milestone2, but I wonder if it is still there in
milestone2 in OSGI.
Try 3.0.0-SNAPSHOT ?
Cheers, Sergey
On 24/04/14 12:04, Sergey Beryozkin wrote:
Hi
On 24/04/14 11:53,
Tokens are cached by the client according to the Lifetime of the response
from the STS. Could you check and see whether the token Lifetime that is
returned is greater than the SAML NotOnOrAfter value?
Colm.
On Thu, Apr 24, 2014 at 7:37 AM, jeffc jeff_carbe...@bcbsil.com wrote:
CXF 2.7.7.
Actually, as it happens, Christian has done a brilliant job in
introducing a bundle activator for initializing the default HTTP OSGi
transport and at this point of time we can simply support a property
optionally disabling the default CXF OSGI transport.
I've introduced an
Hi Andrei,
Currently, I am simply removing stackTrace node from SOAPFault Element.
We are required to log the stack traces to a table, via sending the logs to
an MQ server, and have a listener application (of some sort) to insert them
to the database table as they become available (haven't
Hi,
I am not sure that I understand your use case.
If you would like just to send arbitrary xml to the web service, Dispatch
interface is exactly what you need.
The code will look like:
Service service = Service.create(SERVICE_NAME);
service.addPort(PORT_NAME,
In regards to lifetime, we are using Layer 7 STS and have not configured any
lifetime settings. But there is an option to set lifetime for the returned
security token in the Layer 7 STS RSTR configuration. But we currently
have this option unchecked. While greyed out, it does show 60 minutes
Could you also post the complete RSTR from the STS?
Colm.
On Thu, Apr 24, 2014 at 6:58 PM, jeffc jeff_carbe...@bcbsil.com wrote:
In regards to lifetime, we are using Layer 7 STS and have not configured
any
lifetime settings. But there is an option to set lifetime for the returned
security
Hello,
I am running into a problem if I extend the
org.apache.cxf.ws.security.wss4j.WSS4JOutInterceptor via spring beans.
I have a bean definition defined as(haven't shown complete bean
definition) :
bean class=org.apache.cxf.ws.security.wss4j.WSS4JOutInterceptor
id=interceptor
I don't quite follow. Could you paste your entire spring config please?
Colm.
On Thu, Apr 24, 2014 at 7:08 PM, Giriraj Bhojak girira...@gmail.com wrote:
Hello,
I am running into a problem if I extend the
org.apache.cxf.ws.security.wss4j.WSS4JOutInterceptor via spring beans.
I have a bean
Sorry looks like I posted the ws-trust request before and not the response.
Here is the response. I also unchecked that box on our STS and set its
lifetime on the SAML token it returns to 7 minutes to match the NotOnOrAfter
and it now has a lifetime element, but I am still getting the same error
Here is the working config:
beans xmlns=http://www.springframework.org/schema/beans;
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; xmlns:jaxws=
http://cxf.apache.org/jaxws;
xmlns:util=http://www.springframework.org/schema/util; xmlns:cxf=
http://cxf.apache.org/core;
In addition to the above confusion on Lifetime versus NotOnOrAfter, I want to
force my STSClient to do a issue on a expired token since our STS is not
setup to do renew at this time.
My thought was that the below CXF renewToken code would execute a issue if I
set the STSClient property
If I understand what your goal is, it is to avoid having the passwords for the
keystore in plain text in a properties file?
The way that I handled that was to create a class that extends properties, put
your code to decrypt the property values in that class.
Then, configure an instance of
The problem here is that the Lifetime expiry returned by the STS does not
match the NotOnOrAfter Condition in the Assertion. So the Lifetime expiry
is 18:13:11 but the NotOnOrAfter expiry is 18:11:11. In my opinion the
fault lies with the STS, as the Lifetime of the token should match the
The STSClient property that controls this behaviour is allowRenewing not
allowRenewingAfterExpiry.
Colm.
On Thu, Apr 24, 2014 at 8:27 PM, jeffc jeff_carbe...@bcbsil.com wrote:
In addition to the above confusion on Lifetime versus NotOnOrAfter, I want
to
force my STSClient to do a issue on a
Thanks, good to know, is this documented anywhere or in a blog post?
I created for my own purpose this little cheat sheet:
property name=allowRenewingAfterExpiry value=false/
Will cause the ws-trust request to STS to have:
wst:Renewing OK=false/
property name=allowRenewing value=false/
Will
Can I be removed from tins mailing list please
Sent from my iPhone
On 25 Apr 2014, at 00:19, jeffc jeff_carbe...@bcbsil.com wrote:
Thanks, good to know, is this documented anywhere or in a blog post?
I created for my own purpose this little cheat sheet:
property
It does.
The unit test works properly.
It's only when I integrate this into a web app, I start seeing issues. I am
not sure why. All the spring dependencies are common between junit's
classpath and web app's classpath
Andy,
I am currently trying the SignaturePropRefId option. I have written a
25 matches
Mail list logo
