[
https://issues.apache.org/jira/browse/FEDIZ-68?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14028932#comment-14028932
]
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: 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.2#6252)
