Hi, I have the similar use case in one of the projects.
Agree with Sergei's suggestions: Scenario 1: If you have to call service with another identity, I see the following options: a) client itself authenticates new identity against IDP and creates SAML; b) if STS (SecurityTokenService) is used in your infrastructure, the client can delegate the authentication and SAML creation to STS with the help of CXF (WS) STSClient. c) if your IDP supports SAML SSO, the client can reuse CXF SAML SSO implementation: http://cxf.apache.org/docs/saml-web-sso.html On the next step, inject SAML into request HTTP Header / Form Value / Envelope in Message Body (depending on what your service supports) and call the service. Scenario 2: Reuse Subject principals of logged user to create SAML assertion. Inject SAML into request HTTP Header / Form Value / Envelope in Message Body (depending on what your service supports). Not necessary to re-authenticate user on the client side. On the server side, if server trusts the SAML issuer, it will be necessary just to check a signature and SAML principle can be used as logged user. Regards, Andrei. > -----Original Message----- > From: Sergey Beryozkin [mailto:[email protected]] > Sent: Donnerstag, 6. November 2014 22:41 > To: [email protected] > Subject: Re: JAX-RS Client to handle SAML (+OAuth2) in SSO > > Hi > On 06/11/14 17:46, rareddy wrote: > > Sergy, > > > > Sorry for not being clear. In previous comment to above you said it > > correctly about my usecase. > > > > I have a JEE application with already authenticated subject, with in > > the workflow of that application, I am trying call another 3rd party > > JAX-RS service that requires SAML authentication (I am not sure yet > > about enveloped or header yet). > > > > scenario 1 - Call 3rd party service using WebClient. The confusion for > > me here is how to write the WebClient such that it can handle identity > > challenge comes back from that service's IDP programatically. > > > Right. We did some work with Colm few months back on enhancing the HTTP > conduit auto-redirection features, especially with respect to dealing cookies > and restricting the auto-redirection as needed. So one option here is > experiment with enabling an auto redirection on the client. > > Another option, more secure IMHO, is to do it manually, have a JAX-RS > RedirectException caught, authenticate against the IDP and re-invoke against > the protected server with the assertion returned from IDP encoded as a header > for example. > > > scenario 2 - Call 3rd party service using WebClient, but use the > > current Subject for any identity challenges. I see your answer. I do > > not have any suggestions. I am asking if there were any. > > > > Well, as far as I understand you need to convert this Subject into a SAML > assertion; I'm not sure how to avoid the re-authentication in this case > though at > the target server. Kerberos is probably more suitable, not sure about SAML. > > May be Colm has some ideas ? > > Cheers, Sergey > > Thanks > > > > Ramesh.. > > > > > > > > -- > > View this message in context: > > http://cxf.547215.n5.nabble.com/JAX-RS-Client-to-handle-SAML-OAuth2-in > > -SSO-tp5750699p5750802.html Sent from the cxf-user mailing list > > archive at Nabble.com. > >
