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 >> > >
