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