You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@wicket.apache.org by jensiator <je...@gmail.com> on 2012/05/09 16:00:47 UTC
Single sign on (SSO) for two WicketApplication
Anyone got some experience on this?
1. Maybe using the tomcat built in SSO for two applications?
2. Could one add a filter/Servlet that handles it for the two Wicket
Applications?
3. Some products that anyone have good experience with?
I have google on this but have not found any good 'how to' or tutorial. Any
good links?
Jens
--
View this message in context: http://apache-wicket.1842946.n4.nabble.com/Single-sign-on-SSO-for-two-WicketApplication-tp4620516.html
Sent from the Users forum mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Single sign on (SSO) for two WicketApplication
Posted by jensiator <je...@gmail.com>.
Thanks you everyone. A thank you Arjun for you detailed thoughts. I will see
what CAS can do together with our restservices. The wicket applications is
two 'clients' that talks with the same server through rest.
--
View this message in context: http://apache-wicket.1842946.n4.nabble.com/Single-sign-on-SSO-for-two-WicketApplication-tp4620516p4625265.html
Sent from the Users forum mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Single sign on (SSO) for two WicketApplication
Posted by Dan Alvizu <da...@pingidentity.com>.
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 <dh...@yahoo.com> 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: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
Re: Single sign on (SSO) for two WicketApplication
Posted by Arjun Dhar <dh...@yahoo.com>.
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-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Single sign on (SSO) for two WicketApplication
Posted by Igor Vaynberg <ig...@gmail.com>.
look at sso solutions such as CAS[1]. see how they work, and either
use it directly, or implement your own variant if that suits you
better.
[1] http://www.jasig.org/cas
-igor
On Thu, May 10, 2012 at 4:02 AM, jensiator <je...@gmail.com> wrote:
> What about if I say that its only wicket applications? Can we narrow it down
> even more then?
> In both apps have a link to each other so the end user can toggle between
> them. If these link's are external links. How could you send/share the
> username password between den in a secure way? Https of course but I don't
> have a clue when it comes to coding. Never worked with this.
>
> --
> View this message in context: http://apache-wicket.1842946.n4.nabble.com/Single-sign-on-SSO-for-two-WicketApplication-tp4620516p4623142.html
> Sent from the Users forum mailing list archive at Nabble.com.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Single sign on (SSO) for two WicketApplication
Posted by Dan Retzlaff <dr...@gmail.com>.
Jens, I describe some details of our homegrown "application handoff"
solution here:
http://mail-archives.apache.org/mod_mbox/wicket-users/201202.mbox/%3CCAC-L2fYM4txQ7733AeuvfdNUstLTe_nBsix2ZOjVYtqKoGapaQ@mail.gmail.com%3E
On Thu, May 10, 2012 at 4:02 AM, jensiator <je...@gmail.com> wrote:
> What about if I say that its only wicket applications? Can we narrow it
> down
> even more then?
> In both apps have a link to each other so the end user can toggle between
> them. If these link's are external links. How could you send/share the
> username password between den in a secure way? Https of course but I don't
> have a clue when it comes to coding. Never worked with this.
>
> --
> View this message in context:
> http://apache-wicket.1842946.n4.nabble.com/Single-sign-on-SSO-for-two-WicketApplication-tp4620516p4623142.html
> Sent from the Users forum mailing list archive at Nabble.com.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
Re: Single sign on (SSO) for two WicketApplication
Posted by jensiator <je...@gmail.com>.
What about if I say that its only wicket applications? Can we narrow it down
even more then?
In both apps have a link to each other so the end user can toggle between
them. If these link's are external links. How could you send/share the
username password between den in a secure way? Https of course but I don't
have a clue when it comes to coding. Never worked with this.
--
View this message in context: http://apache-wicket.1842946.n4.nabble.com/Single-sign-on-SSO-for-two-WicketApplication-tp4620516p4623142.html
Sent from the Users forum mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org