Hi Oliver, We just made it work. We had to mimic browser behaviour - which expect three steps. So, Fediz WS-Federation satisfy our needs and most likely we may adopt it. If you have a formal release version, please let me know.
Thanks. Gina On Fri, Jun 8, 2012 at 9:30 AM, Gina Choi <[email protected]> wrote: > Hi Oliver, > > We have two application - One is .NET based(Agency) and the other is Java > based(Airline) both use ADFS as a STS and Active Directory as an attribute > store. Both are are SSO. As you know I am using Fediz WS-Federation. .NET > application is using WIF. When a user logon Agency, the Agency is caching > security token as Fediz does. Therefore, when Agency make a call to Airline > it has security token already. What we try to do is first, passing the > security token in the field of the "wresult", and get authenticated, get > cookie and Principle is get cached. We call this is login step from .NET > http client. Second time, the client inject the cookie to make REST call to > Airline. > > The problem we have is that even we authenticated, get cookie, but > Principle is not being cached because of "wa" condition that I mentioned in > the previous email. > > My colleague is also working in different timezone, so I only have an hour > a day overlapping time. That's why we make slow progress. > > Thanks. > > Gina > On Fri, Jun 8, 2012 at 2:56 AM, Oliver Wulff <[email protected]> wrote: > >> Hi Gina >> >> >> >> I think I misunderstood you. I thought you grabed the cookie after a >> successfull authentication thus the .NET client sends the cookie which >> relates to an authenticated session. >> >> >> >> Maybe an option is to not do a redirect if the original URL is missing. >> WS-Federation PRP supports destination/sp first which means you must first >> access the application. >> >> >> >> Could you please explain the use case? How is the .NET client getting >> into the possession of the wresult without accessing the application first? >> >> >> >> Thanks >> >> Oli >> >> >> >> >> >> ------ >> >> Oliver Wulff >> >> Blog: http://owulff.blogspot.com >> Solution Architect >> http://coders.talend.com >> >> <http://coders.talend.com>Talend Application Integration Division >> http://www.talend.com >> ------------------------------ >> *From:* Gina Choi [[email protected]] >> *Sent:* 07 June 2012 22:57 >> *To:* Oliver Wulff >> *Cc:* [email protected] >> *Subject:* Re: Handling Cookies in Fediz WS-Federation web sso >> >> Hi Oliver, >> >> You must be busy with preparation work with Fediz release. >> >> I looked at authenticate(Line 140 - 444) method code for inside >> org.apache.cxf.fediz.tomcat.FederationAuthenticator.java class and I know >> what our problem is, but don't have a solution yet. >> >> For a user to be authenticated through a browser, three steps happening. >> >> When a user type >> https://wkensv0305.global.sdl.corp:8443/Airline/code/Welcome.jsp on the >> browser following things happen. >> a. principal == null >> b. wa == null >> -> saveRequest(request, session) -- requested URL is cached in the >> session >> ->redirectToIssuer(request, response, wfProc) - redirected to STS >> c. When come back from sts, wa !=null and wresult != null(Line273) >> ->validate token >> d. Redirect to original URL happen >> response.sendRedirect(response.encodeRedirectURL(uri))(Line 438) >> e. Step (d) redirect call meet following condition. This allow caching >> Principal. >> *if* (matchRequest(request)) { (Line 205) >> >> Line211-Lin213 >> principal = >> (Principal)session.getNote(Constants.FORM_PRINCIPAL_NOTE); >> register(request, response, principal, >> FederationConstants.WSFED_METHOD, null, null); >> >> My colleague try to use one call to get authenticated and get cookie, but >> since he is passing wa="wsignin1.0", The original URL is not cached, so >> step (d) above is not happening. As the result, Principal is not cached. >> Therefore next REST will fail. authenticate method is designed for browser >> behavior, so for a http client hard to get in. Need to meet different >> condition. >> >> Following is part of .NET client code for login. The problem we have is >> with "wa" attribute. Having value for "wa" is a problem(causes not caching >> originally requested URL). It is also a problem not having value since it >> try to redirect to STS even you bring value for "wresult". >> >> loginFields.Add("wa", "wsignin1.0"); >> loginFields.Add("wctx", Common.URIConfiguration.Airline); >> loginFields.Add("wresult", wresult); >> We are planning to try it again tomorrow morning. Meanwhile, if you >> have a solution please let me know. >> >> Thanks. >> >> Gina >> On Thu, Jun 7, 2012 at 2:39 PM, Oliver Wulff <[email protected]> wrote: >> >>> Hi Gina >>> >>> >>> >>> If you get into the possession of the cookie it should work to send a >>> request with another HTTP client. >>> >>> >>> >>> In your test, could you paste the HTTP headers? >>> >>> >>> >>> In Tomcat, you could configure the RequestDumperValve: >>> >>> >>> http://tomcat.apache.org/tomcat-6.0-doc/config/valve.html#Request_Dumper_Valve >>> >>> >>> >>> Haven't found the link for Tomcat 7 but I think it's still there. >>> >>> >>> >>> HTH >>> >>> >>> >>> >>> >>> ------ >>> >>> Oliver Wulff >>> >>> Blog: http://owulff.blogspot.com >>> Solution Architect >>> http://coders.talend.com >>> >>> <http://coders.talend.com>Talend Application Integration Division >>> http://www.talend.com >>> ------------------------------ >>> *From:* Gina Choi [[email protected]] >>> *Sent:* 06 June 2012 04:11 >>> *To:* [email protected]; Oliver Wulff >>> *Subject:* Handling Cookies in Fediz WS-Federation web sso >>> >>> Hi Oliver, >>> >>> I applied Fediz WS-Federation web sso to a Java sample web application >>> called Airline(All web services are REST). Everything went well so far. My >>> colleague try to make a web service to call to Airline REST web service >>> from his .NET client. He programmatically logged on Airline(get SAML token >>> and passed authentication) and obtained a cookie. Then he try to inject >>> this cookie to his succinct REST calls(I am not sure if this is a common >>> practice in securing REST web service), but he got 401 unauthorized >>> exception. >>> >>> First call: >>> https://wkensv0305.global.sdl.corp:8443/Airline/code/Welcome.jsp >>> Second call: https://wkensv0305.global.sdl.corp:8443/Airline >>> /code/SDLecheckin.jsp?request=flightstatus<https://wkensv0305.global.sdl.corp:8443/Airline/code/SDLecheckin.jsp?request=flightstatus> >>> >>> When .NET client make second call, it is being treated as >>> unauthenticated but it still keep same >>> session(917E67F5E54E8CAAD62B9D9367E4E340) since it has cookie. I have >>> attached Tomcat log for your reference. Authentication is determined by the >>> following code. So, it means either Principle is not cached from first call >>> or second call retrieves Principal in different way from the the cache. >>> >>> Principal principal = request.getUserPrincipal(); >>> >>> Does Fediz treat both browser and client(.NET) differently in terms >>> of caching Principal in the context? Injecting cookie worked when we cache >>> user info in the session. We have don't his in the past. >>> >>> Thanks. >>> >>> Gina >>> >> >> >
