Mailing-List: contact issues-help@cxf.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cxf.apache.org
Date: Fri, 17 Jan 2014 10:01:21 +0000 (UTC)
From: "Alex Sarafian (JIRA)" <jira@apache.org>
To: issues@cxf.apache.org
Message-ID: <JIRA.12689467.1389952858444.22909.1389952881976@arcas>
In-Reply-To: <JIRA.12689467.1389952858444@arcas>
References: <JIRA.12689467.1389952858444@arcas>
Subject: [jira] [Created] (FEDIZ-68) Submitting a token through a rich
 client.
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit

Alex Sarafian created FEDIZ-68:
----------------------------------

             Summary: Submitting a token through a rich client.
                 Key: FEDIZ-68
                 URL: https://issues.apache.org/jira/browse/FEDIZ-68
             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 Application
2. Using WS-Federation (passive profile) client submits the token by simulating a browser's behavior.

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
(v6.1.5#6160)