> This is critical financial app , requires high availability and security well, it should then be worthwhile to uplevel the discussion, and research web SSO per se unto itself. There's been tons of research and development on it, and there are drop-in, open source packages available (the below barely scratches the surface).. http://simplesamlphp.org/ http://shibboleth.internet2.edu/ Plus there's commercial things.. http://www.janrain.com/solutions/industry/technology It's worth using one of the above (or another) because designing web SSO is quite tricky and this thread is already heading down that path. It's been re-invented, with widely varying quality, multitudes of times since the mid-1990s. You and we don't need to do it again. For example, that's exactly where this comment from the thread is headed.. > Why not send the session info from the old application to the new one out > of band, negotiate a token representing the session, then hand the token to > the client to pass to the new application? Also, for example, there's offhanded mention (in the thread) of encrypting then signing data.. > You could additionally sign the encrypted XML blob and ensure it was > properly signed prior to use. Such an apparently simple couple of operations are actually quite nuanced and if not concocted properly can result in essentially no security against moderately talented attackers. See for example.. Donald T. Davis, "Defective Sign & Encrypt in S/MIME, PKCS#7, MOSS, PEM, PGP, and XML.", Proc. Usenix Tech. Conf. 2001 (Boston, Mass., June 25-30, 2001), pp. 65-78.(180 Kbytes) (PDF, 200 Kbytes) (HTML, 80 Kbytes) Also, a shortened version of this paper appeared in Dr. Dobb's: Don Davis, "Defective Sign-and-Encrypt," Dr. Dobb's Journal #330, v.26(11) (Nov. 2001), pp. 30-36. http://world.std.com/~dtd/#sign_encrypt http://world.std.com/~dtd/sign_encrypt/sign_encrypt7.html http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.28.7379&rep=rep1&type=pdf HTH, =JeffH

Thanks Jeff , SAML is definitely a good option , this is being put forward as a temporary solution for a set of customers , a kind of beta testing , eventually every one gets it at the end in about two months the whole thing is a throw away and every body directly gets the new application, so looks like the business is not willing to invest in implementing SAML . Looks like this is an already existing solution that was designed to be implemented else where but now We are evaluating the risks involved in using that for the legacy - new site switch over There is definitely a risk though Thanks Subin Sent from my iPhone On Mar 15, 2012, at 1:29 AM, =JeffH <Jeff.Hodges@KingsMountain.com> wrote: >> This is critical financial app , requires high availability and security > > well, it should then be worthwhile to uplevel the discussion, and research web SSO per se unto itself. There's been tons of research and development on it, and there are drop-in, open source packages available (the below barely scratches the surface).. > > http://simplesamlphp.org/ > > http://shibboleth.internet2.edu/ > > Plus there's commercial things.. > > http://www.janrain.com/solutions/industry/technology > > > It's worth using one of the above (or another) because designing web SSO is quite tricky and this thread is already heading down that path. It's been re-invented, with widely varying quality, multitudes of times since the mid-1990s. You and we don't need to do it again. For example, that's exactly where this comment from the thread is headed.. > >> Why not send the session info from the old application to the new one out >> of band, negotiate a token representing the session, then hand the token to >> the client to pass to the new application? > > > Also, for example, there's offhanded mention (in the thread) of encrypting then signing data.. > >> You could additionally sign the encrypted XML blob and ensure it was >> properly signed prior to use. > > Such an apparently simple couple of operations are actually quite nuanced and if not concocted properly can result in essentially no security against moderately talented attackers. See for example.. > > Donald T. Davis, "Defective Sign & Encrypt in S/MIME, PKCS#7, MOSS, PEM, > PGP, and XML.", Proc. Usenix Tech. Conf. 2001 (Boston, Mass., June 25-30, > 2001), pp. 65-78.(180 Kbytes) (PDF, 200 Kbytes) (HTML, 80 Kbytes) Also, a > shortened version of this paper appeared in Dr. Dobb's: > Don Davis, "Defective Sign-and-Encrypt," Dr. Dobb's Journal #330, v.26(11) > (Nov. 2001), pp. 30-36. > http://world.std.com/~dtd/#sign_encrypt > http://world.std.com/~dtd/sign_encrypt/sign_encrypt7.html > http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.28.7379&rep=rep1&type=pdf > > > HTH, > > =JeffH >

Hello! Look at this paper by Oasis. http://docs.oasis-open.org/security/saml/v2.0/saml-sec-consider-2.0-os.pdf Even it's recommendations for SAML you can have some ideas for your in-house protocol. Th3D34D On Thu, Mar 15, 2012 at 1:05 PM, Subin <subin.net@gmail.com> wrote: > Thanks Jeff , SAML is definitely a good option , this is being put forward as a temporary solution for a set of customers , a kind of beta testing , eventually every one gets it at the end in about two months the whole thing is a throw away and every body directly gets the new application, so looks like the business is not willing to invest in implementing SAML . > > Looks like this is an already existing solution that was designed to be implemented else where but now We are evaluating the risks involved in using that for the legacy - new site switch over > > There is definitely a risk though > > Thanks > Subin > > Sent from my iPhone > > On Mar 15, 2012, at 1:29 AM, =JeffH <Jeff.Hodges@KingsMountain.com> wrote: > >>> This is critical financial app , requires high availability and security >> >> well, it should then be worthwhile to uplevel the discussion, and research web SSO per se unto itself. There's been tons of research and development on it, and there are drop-in, open source packages available (the below barely scratches the surface).. >> >> http://simplesamlphp.org/ >> >> http://shibboleth.internet2.edu/ >> >> Plus there's commercial things.. >> >> http://www.janrain.com/solutions/industry/technology >> >> >> It's worth using one of the above (or another) because designing web SSO is quite tricky and this thread is already heading down that path.  It's been re-invented, with widely varying quality, multitudes of times since the mid-1990s. You and we don't need to do it again. For example, that's exactly where this comment from the thread is headed.. >> >>> Why not send the session info from the old application to the new one out >>> of band, negotiate a token representing the session, then hand the token to >>> the client to pass to the new application? >> >> >> Also, for example, there's offhanded mention (in the thread) of encrypting then signing data.. >> >>> You could additionally sign the encrypted XML blob and ensure it was >>> properly signed prior to use. >> >> Such an apparently simple couple of operations are actually quite nuanced and if not concocted properly can result in essentially no security against moderately talented attackers. See for example.. >> >> Donald T. Davis, "Defective Sign & Encrypt in S/MIME, PKCS#7, MOSS, PEM, >> PGP, and XML.", Proc. Usenix Tech. Conf. 2001 (Boston, Mass., June 25-30, >> 2001), pp. 65-78.(180 Kbytes) (PDF, 200 Kbytes) (HTML, 80 Kbytes) Also, a >> shortened version of this paper appeared in Dr. Dobb's: >> Don Davis, "Defective Sign-and-Encrypt," Dr. Dobb's Journal #330, v.26(11) >> (Nov. 2001), pp. 30-36. >> http://world.std.com/~dtd/#sign_encrypt >> http://world.std.com/~dtd/sign_encrypt/sign_encrypt7.html >> http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.28.7379&rep=rep1&type=pdf >> >> >> HTH, >> >> =JeffH >> > > > _______________________________________________ > The Web Security Mailing List > > WebSecurity RSS Feed > http://www.webappsec.org/rss/websecurity.rss > > Join WASC on LinkedIn http://www.linkedin.com/e/gis/83336/4B20E4374DBA > > WASC on Twitter > http://twitter.com/wascupdates > > websecurity@lists.webappsec.org > http://lists.webappsec.org/mailman/listinfo/websecurity_lists.webappsec.org