I'm not sure if it fits your use-case, but my company offers single sign on as a service:
https://www.pingone.com/ -Dan On Thu, May 10, 2012 at 11:52 AM, Arjun Dhar <[email protected]> wrote: > 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: [email protected] > For additional commands, e-mail: [email protected] > >
