Author: ppenicka Date: 2013-02-18 10:42:04 -0500 (Mon, 18 Feb 2013) New Revision: 9166 Modified: epp/docs/branches/6.0/Reference_Guide/en-US/Revision_History.xml epp/docs/branches/6.0/Reference_Guide/en-US/modules/AuthenticationAndIdentity/SSO.xml Log: BZ#856450 - Incorporated comments 10 and 11 in the bug - edits of the JOSSO, CAS and clustered SSO sections. Modified: epp/docs/branches/6.0/Reference_Guide/en-US/Revision_History.xml =================================================================== --- epp/docs/branches/6.0/Reference_Guide/en-US/Revision_History.xml 2013-02-18 04:22:30 UTC (rev 9165) +++ epp/docs/branches/6.0/Reference_Guide/en-US/Revision_History.xml 2013-02-18 15:42:04 UTC (rev 9166) @@ -8,6 +8,20 @@ <simpara> <revhistory> <revision> + <revnumber>6.0.0-49</revnumber> + <date>Mon Feb 18 2013</date> + <author> + <firstname>Petr</firstname> + <surname>Penicka</surname> + <email/> + </author> + <revdescription> + <simplelist> + <member>BZ#856450 - Incorporated comments 10 and 11 in the bug - edits of the JOSSO, CAS and clustered SSO sections.</member> + </simplelist> + </revdescription> + </revision> + <revision> <revnumber>6.0.0-48</revnumber> <date>Fri Feb 15 2013</date> <author> Modified: epp/docs/branches/6.0/Reference_Guide/en-US/modules/AuthenticationAndIdentity/SSO.xml =================================================================== --- epp/docs/branches/6.0/Reference_Guide/en-US/modules/AuthenticationAndIdentity/SSO.xml 2013-02-18 04:22:30 UTC (rev 9165) +++ epp/docs/branches/6.0/Reference_Guide/en-US/modules/AuthenticationAndIdentity/SSO.xml 2013-02-18 15:42:04 UTC (rev 9166) @@ -152,7 +152,7 @@ </listitem> <listitem> <para> - CAS redirects the user back to the portal using the logout redirection configured in <xref linkend="sect-CAS_Logout_Redirection"/> . + CAS redirects the user back to the portal using the logout redirection configured in <xref linkend="sect-CAS_Logout_Redirection"/>. </para> <para> If the <emphasis role="italics">CASLogoutFilter</emphasis> is enabled, the user is logged out from both the portal and CAS server. @@ -445,7 +445,7 @@ <term>gatein.sso.login.module.enabled</term> <listitem> <para> - Specifies whether a pre-defined SSO login module declared in <filename> JPP_HOME/standalone/configuration/standalone.xml</filename> is used for authentication. When the property is set to &quot;true&quot;, the SSODelegateLoginModule delegates work to another login module, as specified using the <property>gatein.sso.login.module.class</property> property. SSODelegateLoginModule will also resend all its options to its delegate. + Specifies whether a pre-defined SSO login module declared in <filename> JPP_HOME/standalone/configuration/standalone.xml</filename> is used for authentication. When the property is set to <literal>true</literal>, the <systemitem>SSODelegateLoginModule</systemitem> delegates work to another login module, as specified using the <systemitem>gatein.sso.login.module.class</systemitem> property. <systemitem>SSODelegateLoginModule</systemitem> will also resend all its options to its delegate. </para> <para> This parameter removes the need to manually change any login module configuration in the <filename>standalone.xml</filename> file, which simplifies platform configuration. @@ -456,7 +456,7 @@ <term>gatein.sso.login.module.class</term> <listitem> <para> - Specifies the classname of the login module SSODelegateLoginModule will delegate to. This parameter will work only if <property>gatein.sso.login.module.enabled</property> is specified. + Specifies the classname of the login module <systemitem>SSODelegateLoginModule</systemitem> will delegate to. This parameter will work only if <property>gatein.sso.login.module.enabled</property> is specified. </para> </listitem> </varlistentry> @@ -480,7 +480,7 @@ <term>gatein.sso.filter.logout.class</term> <listitem> <para> - Specifies the class of the logout filter. In the example above <code>org.gatein.sso.agent.filter.CASLogoutFilter</code> is the correct choice because this filter is able to redirect to the CAS server and perform logout on the CAS side. + Specifies the class of the logout filter. In the example above <systemitem>org.gatein.sso.agent.filter.CASLogoutFilter</systemitem> is the correct choice because this filter is able to redirect to the CAS server and perform logout on the CAS side. </para> </listitem> </varlistentry> @@ -495,7 +495,7 @@ <term>gatein.sso.filter.logout.enabled</term> <listitem> <para> - Optional parameter, which specifies whether the logout interceptor is enabled. To disable logout on CAS side, set the parameter value to &quot;false&quot;. This causes both options <code>gatein.sso.filter.logout.class</code> and <code>gatein.sso.filter.logout.url</code> to be ignored. </para> + Optional parameter, which specifies whether the logout interceptor is enabled. To disable logout on CAS side, set the parameter value to <literal>false</literal>. This causes both options <systemitem>gatein.sso.filter.logout.class</systemitem> and <systemitem>gatein.sso.filter.logout.url</systemitem> to be ignored. </para> <para> When a user logs out of the portal, the CAS authentication ticket is still valid for other CAS authenticated sites. </para> @@ -613,12 +613,7 @@ <procedure> <step> <para> - <emphasis role="bold">Optional:</emphasis> To use the SSO authentication plug-in with JOSSO (not mandatory but recommended, see <xref linkend="sect-Reference_Guide-SSO_Single_Sign_On_-Java_Open_Single_Sign_On_Project-Auth_Process"/> for details): - </para> - <substeps> - <step> - <para> - Copy the contents of the <filename>JPP_DIST/gatein-sso/josso/josso-<replaceable>&lt;version&gt;</replaceable>/plugin/</filename> directory into the <replaceable>JOSSO_HOME</replaceable> directory. Among the files that will be copied, the following ones are the most important: + <emphasis role="bold">Optional:</emphasis> To use the SSO authentication plug-in with JOSSO (not mandatory but recommended, see <xref linkend="sect-Reference_Guide-SSO_Single_Sign_On_-Java_Open_Single_Sign_On_Project-Auth_Process"/> for details), copy the contents of the <filename>JPP_DIST/gatein-sso/josso/josso-<replaceable>&lt;version&gt;</replaceable>/plugin/</filename> directory into the <replaceable>JOSSO_HOME</replaceable> directory. Among the files that will be copied, the following ones are the most important: </para> <itemizedlist> <listitem> @@ -646,12 +641,10 @@ </para> </listitem> </itemizedlist> - </step> - </substeps> </step> <step> <para> - Edit <filename>TOMCAT_HOME/conf/server.xml</filename> and replace the <literal>8080</literal> port to <literal>8888</literal> to change the default Tomcat port and avoid a conflict with the default JBoss Portal Platform port (for testing purposes). + Edit <filename>JOSSO_HOME/conf/server.xml</filename> and replace the <literal>8080</literal> port to <literal>8888</literal> to change the default Tomcat port and avoid a conflict with the default JBoss Portal Platform port (for testing purposes). </para> <note> <title>Port Conflicts</title> @@ -1855,7 +1848,7 @@ <section id="sect-SSO_Single_Sign_On_-Enabling_SSO_using_JBoss_SSO_Valve-Default_Config"> <title>Default Configuration</title> <para> - The JBoss SSO valve is enabled by default. The enablement is ensured by the following JBoss Web subsystem configuration entry in the <filename>JPP_HOME/standalone/configuration/standalon-ha.xml</filename> file: + The JBoss SSO valve is enabled by default. The enablement is ensured by the following JBoss Web subsystem configuration entry in the <filename>JPP_HOME/standalone/configuration/standalone-ha.xml</filename> file: </para> <programlisting language="XML"><![CDATA[ <sso cache-container="web" cache-name="sso" reauthenticate="false" /> @@ -1865,7 +1858,7 @@ </para> </section> <section> - <title>Clustered Single-Sign On in a Shared DNS Domain</title> + <title>Clustered Single Sign-On in a Shared DNS Domain</title> <remark>Sourced from: https://docs.jboss.org/author/display/GTNPORTAL35/Clustered+SSO+setup. Updated to page version: 9</remark> <para> If multiple JBoss Portal Platform servers are accessed through different URLs in the same DNS domain, single sign-on can be configured by adding the <parameter>domain</parameter> parameter to the <parameter>sso</parameter> configuration entry. @@ -1876,33 +1869,38 @@ <para> The parameter must be added to the entry on all servers in the cluster and the name of the shared DNS domain must be specified as its value. This configuration ensures that the <parameter>JSESSIONIDSSO</parameter> cookie will be scoped to the specified domain, which is otherwise scoped only to the host where the initial authentication was performed. </para> - <para> - The following procedure demonstrates how to configure and test single sign-on for two JBoss Portal Platform servers running in a shared domain on the same physical Linux machine. - </para> <procedure id="proc-Reference_Guide-Enabling_SSO_using_JBoss_SSO_Valve-Testing_the_SSO_Valve"> <title>Configuring and Testing Single-Sign On in a Shared DNS Domain</title> + <para> + This procedure demonstrates the configuration and testing of single sign-on for two JBoss Portal Platform server instances running in a shared domain on a single physical Linux machine.</para> + <para>It is expected that each instance is installed in a separate directory in the machine's file system, and that the <literal>192.168.210.101</literal> and <literal>192.168.210.102</literal> virtual IP addresses are available on the machine. + </para> <step> <para> - Add the following lines to the <emphasis role="bold">/etc/hosts</emphasis> file. Modify the IP addresses in accordance with the IP addresses of the two JBoss Portal Platform servers. + Map the IP addresses to domain names within the same domain by adding the following lines to the <emphasis role="bold">/etc/hosts</emphasis> file: </para> <programlisting> -127.0.1.1 machine1.yourdomain.com -127.0.1.2 machine2.yourdomain.com +192.168.210.101 machine1.yourdomain.com +192.168.210.102 machine2.yourdomain.com </programlisting> </step> <step> <para> - On both servers, open the <filename><replaceable>JPP_HOME</replaceable>/standalone/configuration/standalone-ha.xml</filename> file. Add the <parameter>domain</parameter> parameter to the <parameter>sso</parameter> entry and specify the name of the shared DNS domain in its value. + Open the <filename><replaceable>JPP_HOME</replaceable>/standalone/configuration/standalone-ha.xml</filename> file on both instances, add the <parameter>domain</parameter> parameter to the <parameter>sso</parameter> entry and specify the name of the shared DNS domain in its value: </para> <programlisting language="XML"><![CDATA[ <sso cache-container="web" cache-name="sso" reauthenticate="false" domain="yourdomain.com"/> ]]></programlisting> - <remark>Source: https://docs.jboss.org/author/display/GTNPORTAL35/Clustered+SSO+setup. Updated to version 9.</remark> - <note><para>By default, <filename>standalone-ha.xml</filename> is configured to use a shared H2 database, which is intended to be used only for testing purposes.</para></note> </step> <step> + <para>By default, the <filename>standalone-ha.xml</filename> file is configured to use a shared H2 database, which is intended to be used only for testing purposes. Start the database by issuing the following command in the <replaceable>JPP_HOME</replaceable> directory of the first instance:</para> +<programlisting> +java -cp modules/com/h2database/h2/main/h2-<replaceable>&lt;VERSION&gt;</replaceable>.jar org.h2.tools.Server +</programlisting> + </step> + <step> <para> - Start the first server using the following command: + Start the first instance by issuing the following command in its <filename>JPP_HOME/bin/</filename> directory: </para> <programlisting> ./standalone.sh -b machine1.yourdomain.com -c standalone-ha.xml -Djboss.node.name=node1 @@ -1910,7 +1908,7 @@ </step> <step> <para> - Start the second server using the following command: + Start the second instance by issuing the following command in its <filename>JPP_HOME/bin/</filename> directory: </para> <programlisting> ./standalone.sh -b machine2.yourdomain.com -c standalone-ha.xml -Djboss.node.name=node2 @@ -1918,17 +1916,17 @@ </step> <step> <para> - Access the first server at <ulink url="http://machine1.yourdomain.com:8080/portal">http://machine1.yourdomain.com:8080/portal</ulink> and log in as a user. + Access the first instance at <ulink url="http://machine1.yourdomain.com:8080/portal">http://machine1.yourdomain.com:8080/portal</ulink> and log in as a user. </para> </step> <step> <para> - Access the second server at <ulink url="http://machine2.yourdomain.com:8080/portal">http://machine2.yourdomain.com:8080/portal</ulink>. When the page loads, you will be automatically logged in with the same user account that you used on the first server. + Access the second instance at <ulink url="http://machine2.yourdomain.com:8080/portal">http://machine2.yourdomain.com:8080/portal</ulink>. When the page loads, you will be automatically logged in with the same user account that you used on the first server. </para> </step> <step> <para> - Log out on any of the two servers. Then switch to the other server and verify that you have been logged out of this server as well. + Log out on any of the two instances. Then switch to the other instance and verify that you have been logged out of it as well. </para> </step> </procedure>