cxf-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alex Sarafian (JIRA)" <j...@apache.org>
Subject [jira] [Created] (FEDIZ-68) Submitting a token through a rich client.
Date Fri, 17 Jan 2014 10:01:21 GMT
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)

Mime
View raw message