Hi Lance, Actually your compromise might endanger your application's goals. If you are dealing with intellectual property or sensitive information, my 2cents is for you to give the vendor time to fix the issue and use the Cosign cookie. It is well worth the effort. Even if you have a VPN limiting access, there are a myriad of ways your application may be compromised. I can think of at least one simple way from internal authenticated users who know the application well,
Also, you might be entering into the non-repudiation arena as well where someone can claim that their submission was not actually theirs or was modified. [http://www.sans.org/security-resources/glossary.php Non-repudiation is the ability for a system to prove that a specific user and only that specific user sent a message and that it hasn't been modified.] Your compromise might be a bad technical solution depending upon the sensitivity of the information you're dealing with. -Shanti Quoting "J.Lance Wilkinson" <[email protected]>: > Unfortunately, we have no control over the way that the 3rd party > vendor we're dealing with has implemented their product. THEY are the > ones using swfupload. We can only compel them to work with us to > fix the issues by witholding payment on licensing or pointing out they > signed a contract in 2005 which COMMITS them to work seamlessly with > the customer's SSO solution, which at the moment is CoSign. > ... > This defeats our intent for unfettered access by the AUTHENTICATED > users who are EXPECTED to do the uploads, limiting them by more than > just their authentication to known IP addresses, too. We compromise > there by including the IP range assigned by our VPN, which cannot be > activated without AUTHENTICATION using the same credentials that CoSign > requires. > > Bennett, Steve wrote: >> Dunno if this might be a red herring, but this all stems from using >> swfupload, which doesn't support cookies. >> >> Are you required to use swfupload? >> >> I've just (like today) stumbled across plupload (http://plupload.com), >> which according to the docs uses a different flash API to avoid the >> cookie problems. Plus it seems to be able to use a variety of >> client-side runtimes, depending on what the client can support. Plus it >> does chunked uploads (which is what I was actually looking for, for >> those multimegabyte journal paper submissions that one of my users want >> to be able to accept...) > > I'll share this with our 3rd party vendor, as a suggestion to > consider making this an alternative to using swfupload. > > -- > J.Lance Wilkinson ("Lance") InterNet: [email protected] > Systems Design Specialist - Lead Phone: (814) 865-4870 > Digital Library Technologies FAX: (814) 863-3560 > E3 Paterno Library > Penn State University > University Park, PA 16802 > > ------------------------------------------------------------------------------ > Download Intel® Parallel Studio Eval > Try the new software tools for yourself. Speed compiling, find bugs > proactively, and fine-tune applications for parallel performance. > See why Intel Parallel Studio got high marks during beta. > http://p.sf.net/sfu/intel-sw-dev > _______________________________________________ > Cosign-discuss mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/cosign-discuss > > !DSPAM:4bb34243263971336712104! > > > > ------------------------------------------------------------------------------ Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev _______________________________________________ Cosign-discuss mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/cosign-discuss
