SAML token caching without an STS

["Gunnar G. Bergem" <gu...@bekk.no>]

We are using WSS4J 1.6.7 to enable SAML security for our webservice calls. Since there is some overhead with signing and
validating the SAML assertions, we would like to cache tokens on both the client and the service provider. However, we would like to avoid
using an STS since that would introduce a single point of failure in the organization. The problem is that all the code I have seen in WSS4J
about caching (the TokenStore) seems to be closely related to setups using an STS. This code exists in STSClient, STSTokenValidator etc.

Is there a way to enable caching of tokens without writing too much custom code?

We also have a question about re-sending of SAML assertions. Is there a way for the service provider to re-use the SAML token it receives
from the client and use it in a new webservice call, where the service provider will act as a client to a second service provider?

Best regards,
  Gunnar Gauslaa Bergem

Re: SAML token caching without an STS

[Colm O hEigeartaigh <co...@apache.org>]

Hi Gunnar,

As you have pointed out, the only caching exists around WS-Trust on both
the client and service side. It should be easy to implement caching on the
service side, by extending the default SAML Validator in WSS4J, and adding
a cache. A patch around this area would be quite welcome :-)

The client side is probably a bit more complicated. How are you generating
the SAML Token in the first place?

> We also have a question about re-sending of SAML assertions. Is there a
way for the service provider to re-use the SAML token it > receives from
the client and use it in a new webservice call, where the service provider
will act as a client to a second service
> provider?

Some functionality is there in this area in the
IssuedTokenInterceptorProvider. I'm guessing this will not work for the non
WS-Trust case. I suggest creating a JIRA that will allow the user to
configure storing SAML Tokens on the request context in much the same way
as it works for WS-Trust.

Colm.

On Mon, Oct 22, 2012 at 1:52 PM, Gunnar G. Bergem <gu...@bekk.no>wrote:

> We are using WSS4J 1.6.7 to enable SAML security for our webservice calls.
> Since there is some overhead with signing and
> validating the SAML assertions, we would like to cache tokens on both the
> client and the service provider. However, we would like to avoid
> using an STS since that would introduce a single point of failure in the
> organization. The problem is that all the code I have seen in WSS4J
> about caching (the TokenStore) seems to be closely related to setups using
> an STS. This code exists in STSClient, STSTokenValidator etc.
>
> Is there a way to enable caching of tokens without writing too much custom
> code?
>
> We also have a question about re-sending of SAML assertions. Is there a
> way for the service provider to re-use the SAML token it receives
> from the client and use it in a new webservice call, where the service
> provider will act as a client to a second service provider?
>
> Best regards,
>   Gunnar Gauslaa Bergem
>



-- 
Colm O hEigeartaigh

Talend Community Coder
http://coders.talend.com