Message-ID: <870903309.301377.1369122488598.JavaMail.firstname.lastname@example.org> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_301376_2051450042.1369122488597" ------=_Part_301376_2051450042.1369122488597 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html
There are very many single sign on technologies available, but on this p= age we discuss a very simple implementation provided in the standard distro= , the HashSSOR= ealm.
The HashSSORealm permits a user to authenticate with one web application= , and then have that authentication and authorization shared by other web a= pplications deployed in the same instance.
The key is to configure a single instance of the HashSSORealm for all we= b applications that wish to share authentication and authorization informat= ion, and then plug that instance into each UserRealm configured for each we= b application.
Here's the definition of a HashSSORealm instance:
Now, if we have web applications A and B, we would plug the instance we = defined above into the configurations for both:
You probably need to set up your Session cookie configuration to allow a= session id established by one web app to be shared by another. By default,= the Session cookie path is that of the context path of the related page. S= o, if you have web app A at /A and web app B at /B, a session id establishe= d by /A would not be able to be used by /B, making single sign-on impossibl= e.
So, you need to configure a path that is valid for all the webapps that = wish to share the session. In the example above, the only common path is &q= uot;/". However, if you have 2 webapps, one at "/one" and th= e other at "/one/two", you could configure the common path as &qu= ot;/one".
Check the wiki page Session Config= uration for information on how to configure Session cookies.