Sir, I rant philosophy let me stop you @ "How could you send/share the username password between den in a secure way" ! .. Let me Fast Forward you thought what you will face on your own implementation:
...so heres the deal. Sharing passwords will not achieve anything. Because the idea of SSO is to pass the understanding that the user is VALID (not the process of authentication itself). There is no good in the second system knowing the password, .... for the idea of SSO would be not to have the user use the password at all to enter the 2nd system :) THE MEAT STUFF BEGINS ------------------------- Hope we agree on what that means. ... it boils down to basically creating a TOKEN. A Token that is recognized across a set of servers that respect the TOKEN. This TOKEN is in the form a secure Cookie. Now, you may think "Ok lets Create a Secure Cookie and we should be good". Ah! But there are more concerns. A Secure TOKEN by definition is what is accessed via HTTPS, but it does not make it IMMUNE to Hacking attacks like "SESSION HIJACKING" (basically I use JavaScript via XSS attack to steal you cookies and JSESSIONID). A script on a Browser can access Cookies. There are HTTP specifications to address this also, but they are server wide configurations in Tomcat (Not Request level or Page level imo -- for those who disagree. Refer: useHttpOnly @ http://tomcat.apache.org/tomcat-5.5-doc/config/context.html). You also have to then deal with the Validity of the TOKEN! how long is the TOKEN valid for? What algorithm do you use to ensure the validity of the Token? If i login and Copy the token. And come back later, and use the token without login, ... will your custom Algo fail? AH ! PHILOSOPHY ----------------- ...I think now you are realizing, that beyond communicating PASSWORDS or TOKENS there is a bottomless pit. ..and that is why you would choose something like CAS. If you are already thinking SSO, then you 'may' also want to think about the following: * Handing RESTful services via the SSO, not just some crude form of authenticated session management across machines. As yoou move to Mobile services, this will become very apparent. There home cook book solutions may not fair well * Integrate with 3rd party IDM (Identity management System) -- Like say LDAP * SAML integration .. ie. you may need your Applications to talk to apps on the cloud. And may want to provide seamless access across not just your servers but a Cloud like Sales Force * Also, today its 2 systems .. well they could easily be 3 or more? SUMMARY ------------ ...Bottom line, your cost for thinking only about the immediate need of 2 Wicket Systems may be the same or less than using a standard product like CAS. Which is free I'd also support the notion that you should evaluate CAS. Its configurations are in Spring, and furthermore they have a lot of adapters that are injected via Spring configs. We have overridden the existing plugins for our own custom use. Customizing Plugins on a Standard SSO is way fruitful than writing a SSO custom solution from scratch. ..I did that many years ago and its not worth it sir! ----- Software documentation is like sex: when it is good, it is very, very good; and when it is bad, it is still better than nothing! -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Single-sign-on-SSO-for-two-WicketApplication-tp4620516p4624131.html Sent from the Users forum mailing list archive at Nabble.com. --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
