Ethical Hacking

Learn to find vulnerabilities before the bad guys do! Gain real world hands on hacking experience in our state of the art hacking lab. Course designed and taught by expert instructors with years of penetration testing experience. 12 student maximum in every class. Certification attempt included in every package.
Computer Forensics Training at InfoSec Institute

Gain the in-demand skills of a certified computer examiner, learn to recover trace data left behind by fraud, theft, and cybercrime perpetrators. Discover the source of computer crime and abuse at your organization so that it never happens again. All of our class sizes are guaranteed to be 12 students or less to facilitate one-on-one interaction with one of our expert instructors.




Network Security Web-App-Sec
[Top] [All Lists]

Re: Achieving Sign On for non-web resource.

Subject: Re: Achieving Sign On for non-web resource.
Date: Wed, 9 Feb 2005 16:30:08 -0500
On Wed, Feb 09, 2005 at 08:14:32PM -0000, Babu Kopparam wrote:

I have provided single sign on for multiple web applications using domain 
cookies.
This works fine.

Now there is a requirement that, one particula link opens up a MS Excel 
client. This client will contact multiple services (web resources) spanned 
across multiple web applications.
As far as i know, i can't use cookies in the Excel.

Can some one help me in providing a single sign on solution for such a 
situation.

Can you pass information to Excel dynamically that it would use in its
web requests? If so, you might consider a token scheme. When a user needs
to use the Excel link, you could
 - devise a strongly random token (strongly random unique string ala
   J2EE JSESSIONID, or unique ID + strongly random component)
 - register information about that token with your SSO directory/system
 - pass the random token via the link to Excel
 - Excel would include the token in its requests, perhaps as a URL argument
 - the web services contacted by Excel would extract the token, contact the
   central SSO directory to validate the token & make appropriate authorization
   decisions

Depending on your environment, the "tokens" could be the same values as the
SSO cookies your client already possesses -- the main question here is whether
this would pose any security risks, and without knowing much about how Excel 
handles data (would the info be saved "invisibly" in a worksheet), or how your
network is configured, that's hard to say. If your dynamic links to Excel

I wouldn't give up on your SSO cookies, though, especially if your users are 
(stuck) using Internet Explorer as the regular web client -- I would expect 
that a combination of zone trust settings for your site and a little Visual 
Basic for Applications code would allow Excel to make http/https requests with 
the same authorization and cookie information that IE uses.

Some quick searching turns up promising pages on Win32 routines like 
InternetGetCookie that can be used within VBA. Surely if VBA can obtain
the cookies from IE, it can make requests with the same auth/cookie credentials
that IE possesses. If so, you're all set.

-Peter

<Prev in Thread] Current Thread [Next in Thread>