cxf-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Oliver Wulff (JIRA)" <>
Subject [jira] [Commented] (FEDIZ-68) Submitting a token through a rich client.
Date Thu, 12 Jun 2014 08:24:02 GMT


Oliver Wulff commented on FEDIZ-68:

WS-Federation defines two use-case: active and passive requestor profile. Active is for a
Web Services client and Passive is for the browser. If it is a Rich client (Web Services client),
you can use CXF to communicate with the STS (embedded in Fediz IDP) if it is a browser client
you deploy the Fediz Plugin into Tomcat. 
I don't understand exactly what your use case is.

> Submitting a token through a rich client.
> -----------------------------------------
>                 Key: FEDIZ-68
>                 URL:
>             Project: CXF-Fediz
>          Issue Type: Bug
>            Reporter: Alex Sarafian
>             Fix For: 1.0.1
> This is a very particular case so I'll try to explain first what we are trying to do.
> We have a rich client in .NET that creates a web client proxy targeting two potential
Web Application (one with .NET and one with JAVA).
> Both Web Applications use WS-Federation to enforce security.
> The .NET one uses the WIF (Windows Identity Foundation) hosted under IIS
> The JAVA one uses CXF-Fediz (currently 1.0.1 version) and is hosted under Apache Tomcat

> Here is the flow
> 1. Using WS-Trust (active profile) client goes to the STS and gets a token for the Web
> 2. Using WS-Federation (passive profile) client submits the token by simulating a browser's
> This flow works fine with the Web Application of .NET but with the JAVA one not.
> The problem is that the JAVA Web Application requires the Browser flow to happen. The
key difference between what we are doing and the browser is that the browser in essence has
a Step 0.
> 0. Browser goes to the Web Application and gets redirected to the STS.
> Along with the redirection, a cookie is issued in the form of JSESSIONID. The cookies
then is also pushed by the browser when submitting the token and then another JSESSIONID is
given to the browser.
> During development of Fediz 1.0.1 my JAVA colleague at the time tracked down the problem
 to a assertion of the Session before the code validated the token.
> We have adjusted our code to simulate this and it works for the proxy. The problem is
that this requirement is interfering with caching introduced on different levels which causes
performance problems. 
> My question is whether this is configurable? From the code I had seen back then, it wasn't.
> The second question is whether this is fixed by any form with version 1.1.0.  

This message was sent by Atlassian JIRA

View raw message