Hi Sergei, > -----Original Message----- > From: Sergey Beryozkin [mailto:[email protected]] > Sent: Montag, 26. Januar 2015 11:51 > To: [email protected] > Cc: Colm O Heigeartaigh > Subject: Re: Reusing SAML Token issue/renew functionality in JAX-RS > > Hi Andriy > > I've looked at IssuedTokenInterceptorProvider, I'm not sure how much self- > contained code we can reuse from that interceptor.
It is not a lot of code we can reuse, I see following reusable parts: 1. Manage token cache 2. Request vs renew token logic 3. ActAs/onBehalfOf logic 4. Creating the STSClient 5. STS_APPLIES_TO logic for STSClient 6. Invocation of STSClient 7. Checking for token expiring > > How would a JAXRS client interceptor would look like ? I guess it should > invoke > on STSClient and set a SAML assertion on the current message ? Yeah, exactly. The JAXRS client interceptor will care about request/renew SAML assertion (either from STS server or from cache) and set it to the current message. Regards, Andrei. > > Thanks, Sergey > > > On 25/01/15 16:52, Andrei Shakirin wrote: > > Hi, > > > > I am working on scenario, where CXF JAX-RS service requests SAML token > from STS. > > Currently is quite easy to validate SAML against STS in JAX-RS Service and > issue SAML internally using SamlCallbackHandler: > http://cxf.apache.org/docs/jax-rs-saml.html. > > Unfortunately there is no easy way to request SAML from STS for the JAX-RS > services: it is necessary to write own interceptor, configure STS client, > implement issue and renew logic, etc. > > > > From my perspective it could make sense to reuse some functionality from > IssuedTokenOutInterceptor for JAX-RS services as well. In this case it would > be > necessary to extract some IssuedTokenOutInterceptor code into appropriate > utility methods (STSUtils ?) and make it independent from WS-Policy stuff. > After > that we can add new interceptor for JAX-RS services reusing code in utility > module. > > > > Any thoughts and objections? > > > > Regards, > > Andrei. > >
