You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cxf.apache.org by Gina Choi <gi...@gmail.com> on 2012/06/06 04:11:09 UTC
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
Re: Handling Cookies in Fediz WS-Federation web sso
Posted by Gina Choi <gi...@gmail.com>.
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 <gi...@gmail.com> 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 <ow...@talend.com> 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 [ginachoi88@gmail.com]
>> *Sent:* 07 June 2012 22:57
>> *To:* Oliver Wulff
>> *Cc:* users@cxf.apache.org
>> *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 <ow...@talend.com> 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 [ginachoi88@gmail.com]
>>> *Sent:* 06 June 2012 04:11
>>> *To:* users@cxf.apache.org; 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
>>>
>>
>>
>
Re: Handling Cookies in Fediz WS-Federation web sso
Posted by Gina Choi <gi...@gmail.com>.
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 <ow...@talend.com> 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 [ginachoi88@gmail.com]
> *Sent:* 07 June 2012 22:57
> *To:* Oliver Wulff
> *Cc:* users@cxf.apache.org
> *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 <ow...@talend.com> 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 [ginachoi88@gmail.com]
>> *Sent:* 06 June 2012 04:11
>> *To:* users@cxf.apache.org; 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
>>
>
>
RE: Handling Cookies in Fediz WS-Federation web sso
Posted by Oliver Wulff <ow...@talend.com>.
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<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 [ginachoi88@gmail.com]
Sent: 07 June 2012 22:57
To: Oliver Wulff
Cc: users@cxf.apache.org
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 <ow...@talend.com>> 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<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 [ginachoi88@gmail.com<ma...@gmail.com>]
Sent: 06 June 2012 04:11
To: users@cxf.apache.org<ma...@cxf.apache.org>; 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
Re: Handling Cookies in Fediz WS-Federation web sso
Posted by Gina Choi <gi...@gmail.com>.
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 <ow...@talend.com> 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 [ginachoi88@gmail.com]
> *Sent:* 06 June 2012 04:11
> *To:* users@cxf.apache.org; 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
>
RE: Handling Cookies in Fediz WS-Federation web sso
Posted by Oliver Wulff <ow...@talend.com>.
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<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 [ginachoi88@gmail.com]
Sent: 06 June 2012 04:11
To: users@cxf.apache.org; 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
Re: Handling Cookies in Fediz WS-Federation web sso
Posted by Gina Choi <gi...@gmail.com>.
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 <gi...@gmail.com> 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
>