I need to run some test with my colleague tomorrow morning to get
supportive data. Have better understanding now...
On Tue, Jun 5, 2012 at 10:11 PM, Gina Choi <[email protected]> wrote:

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

Reply via email to