January 2013 - gatein-commits - Jboss List Archives

gatein SVN: r9078 - in epp/docs/branches/6.0/Reference_Guide/en-US: modules and 7 other directories.

by do-not-reply＠jboss.org

Author: jaredmorgs Date: 2013-01-24 22:37:08 -0500 (Thu, 24 Jan 2013) New Revision: 9078 Modified: epp/docs/branches/6.0/Reference_Guide/en-US/Revision_History.xml epp/docs/branches/6.0/Reference_Guide/en-US/modules/Advanced/Foundations/Config_Retrieval.xml epp/docs/branches/6.0/Reference_Guide/en-US/modules/AuthenticationAndIdentity/AuthenticationAuthorizationOverview.xml epp/docs/branches/6.0/Reference_Guide/en-US/modules/AuthenticationAndIdentity/PasswordEncryption.xml epp/docs/branches/6.0/Reference_Guide/en-US/modules/PortalDevelopment/RTLFramework.xml epp/docs/branches/6.0/Reference_Guide/en-US/modules/PortalDevelopment/Skinning.xml epp/docs/branches/6.0/Reference_Guide/en-US/modules/PortletDevelopment/Standard.xml epp/docs/branches/6.0/Reference_Guide/en-US/modules/WSRP.xml epp/docs/branches/6.0/Reference_Guide/en-US/modules/eXoJCR/jcr-with-gtn/managed-datasources-under-jboss-as.xml epp/docs/branches/6.0/Reference_Guide/en-US/modules/eXoJCR/jcr/cluster-config.xml epp/docs/branches/6.0/Reference_Guide/en-US/modules/eXoJCR/jcr/configuration/jdbc-data-container-config.xml Log: Sanitized all old file paths, and set NEEDINFO on areas that I need more advice on. 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-01-25 02:15:12 UTC (rev 9077) +++ epp/docs/branches/6.0/Reference_Guide/en-US/Revision_History.xml 2013-01-25 03:37:08 UTC (rev 9078) @@ -8,6 +8,20 @@ <simpara> <revhistory> <revision> + <revnumber>6.0.0-36</revnumber> + <date>Fri Jan 25 2013</date> + <author> + <firstname>Jared</firstname> + <surname>Morgan</surname> + <email/> + </author> + <revdescription> + <simplelist> + <member>Sanitized all old file paths. NEEDINFO - FILE PATH used in remarks to flag areas where I need assistance with info.</member> + </simplelist> + </revdescription> + </revision> + <revision> <revnumber>6.0.0-35</revnumber> <date>Fri Jan 25 2013</date> <author> Modified: epp/docs/branches/6.0/Reference_Guide/en-US/modules/Advanced/Foundations/Config_Retrieval.xml =================================================================== --- epp/docs/branches/6.0/Reference_Guide/en-US/modules/Advanced/Foundations/Config_Retrieval.xml 2013-01-25 02:15:12 UTC (rev 9077) +++ epp/docs/branches/6.0/Reference_Guide/en-US/modules/Advanced/Foundations/Config_Retrieval.xml 2013-01-25 03:37:08 UTC (rev 9078) @@ -11,20 +11,21 @@ <para> The container is initialized by looking into different locations. This container is used by portal applications. Configurations are overloaded in the following lookup sequence: </para> + <remark>NEEDINFO - FILE PATHS - the file before was configuration.xml, but I'm pretty sure all this is defined in standalone.xml now, correct?</remark> <procedure> <step> <para> - Services default <envar>RootContainer</envar> configurations from JAR files <filename><replaceable>JPP_DIST/jboss-as/</replaceable>/conf/gatein/configuration.xml</filename>. + Services default <envar>RootContainer</envar> configurations from JAR files <filename><replaceable>JPP_HOME/</replaceable>/standalone/configuration/standalone.xml</filename>. </para> </step> <step> <para> - External <envar>RootContainer</envar> configuration can be found at <filename><replaceable>JPP_DIST/jboss-as/</replaceable>/conf/gatein/configuration.xml</filename>. + External <envar>RootContainer</envar> configuration can be found at <filename><replaceable>JPP_HOME/</replaceable>/standalone/configuration/standalone.xml</filename>. </para> </step> <step> <para> - Services default <envar>PortalContainer</envar> configurations from JAR files <filename><replaceable>JPP_DIST</replaceable>/jboss-as/conf/portal/configuration.xml</filename>. + Services default <envar>PortalContainer</envar> configurations from JAR files <filename><replaceable>JPP_HOME/</replaceable>/standalone/configuration/standalone.xml</filename>. </para> </step> <step> @@ -34,7 +35,7 @@ </step> <step> <para> - External configuration for services of named portal can be found at <filename><replaceable>JPP_DIST</replaceable>/jboss-as/conf/gatein/configuration.xml</filename>. + External configuration for services of named portal can be found at <filename><replaceable>JPP_HOME</replaceable>/standalone/configuration/standalone.xml</filename>. </para> </step> </procedure> @@ -43,6 +44,7 @@ The search looks for a configuration file in each JAR/WAR available from the classpath using the current thread context classloader. During the search these configurations are added to a set. If the service was configured previously and the current JAR contains a new configuration of that service the latest (from the current JAR/WAR) will replace the previous one. The last one will be applied to the service during the services start phase. </para> </note> + <remark>NEEDINFO - FILE PATHS - the file before was configuration.xml, but I'm pretty sure all this is defined in standalone.xml now, correct?</remark> <warning> <para> Take care to have no dependencies between configurations from JAR files (<filename>/conf/portal/configuration.xml</filename> and <filename>/conf/configuration.xml</filename>) since we have no way to know in advance the loading order of those configurations. In other words, if you want to overload some configuration located in the file <filename>/conf/portal/configuration.xml</filename> of a given JAR file, you must not do it from the file <filename>/conf/portal/configuration.xml</filename> of another JAR file but from another configuration file loaded after configurations from JAR files <filename>/conf/portal/configuration.xml.</filename> Modified: epp/docs/branches/6.0/Reference_Guide/en-US/modules/AuthenticationAndIdentity/AuthenticationAuthorizationOverview.xml =================================================================== --- epp/docs/branches/6.0/Reference_Guide/en-US/modules/AuthenticationAndIdentity/AuthenticationAuthorizationOverview.xml 2013-01-25 02:15:12 UTC (rev 9077) +++ epp/docs/branches/6.0/Reference_Guide/en-US/modules/AuthenticationAndIdentity/AuthenticationAuthorizationOverview.xml 2013-01-25 03:37:08 UTC (rev 9078) @@ -52,8 +52,9 @@ <para> Authentication workflow consists of HTTP requests and redirects which include handshakes. Currently only Servlet 3.0 containers are supported, so authentication is triggered programmatically from Servlet API. </para> + <remark>NEEDINFO - FILE PATHS - in this file, the /dologin blocks seem to be in <servlet-mapping> directives. Is it OK for me to update to this format in this respect?</remark> <para> - First you can see in <filename><replaceable>JPP_DIST</replaceable>/jboss-as/server/<replaceable>PROFILE</replaceable>/deploy/gatein.ear/portal.war/WEB-INF/web.xml</filename> that authentication is triggered by accessing a secured URL <systemitem>_/dologin_</systemitem>: + First you can see in <filename><replaceable>JPP_DIST</replaceable>/gatein/gatein.ear/portal.war/WEB-INF/web.xml</filename> that authentication is triggered by accessing a secured URL <systemitem>_/dologin_</systemitem>: </para> <programlisting language="XML" role="XML"> <![CDATA[ @@ -96,7 +97,7 @@ ]]> </programlisting> <para> - <literal>LoginServlet</literal> redirects the user to the login page placed in <filename><replaceable>JPP_DIST</replaceable>/jboss-as/server/<replaceable>PROFILE</replaceable>/deploy/gatein.ear/portal.war/login/jsp/login.jsp</filename>. + <literal>LoginServlet</literal> redirects the user to the login page placed in <filename><replaceable>JPP_DIST</replaceable>/gatein/gatein.ear/portal.war/login/jsp/login.jsp</filename>. <mediaobject> <imageobject role="html"> <imagedata align="center" fileref="images/AuthenticationAndIdentity/Overview/loginScreen.png" format="PNG"/> @@ -107,7 +108,7 @@ </mediaobject> </para> <para> - Changes to the appearance of this login page can be made in this JSP file. Alternatively you can create an extension and override this page via extension if you don't want to edit it directly. You can also change images or CSS placed in <filename><replaceable>JPP_DIST</replaceable>/jboss-as/server/<replaceable>PROFILE</replaceable>/deploy/gatein.ear/login/skin</filename> . + Changes to the appearance of this login page can be made in this JSP file. Alternatively you can create an extension and override this page via extension if you don't want to edit it directly. You can also change images or CSS placed in <filename><replaceable>JPP_DIST</replaceable>/gatein/gatein.ear/login/skin</filename> . </para> <para> After a user submits the login form, they are redirected to the login URL: <ulink url="http://localhost:8080/portal/login?username=root&password=gtn&ini..." type="http">http://localhost:8080/portal/login?username=root&password=gtn&ini...</ulink>. @@ -119,7 +120,7 @@ <section id="sect-Authentication_Authorization_Intro-Login_Modules"> <title>Login modules</title> <para> -From the WCI servlet API login, the user is redirected to JAAS authentication. JBoss Portal Platform uses its own security domain (<emphasis role="bold">gatein-domain</emphasis>) with a set of predefined login modules. Login module configuration for <emphasis>gatein-domain</emphasis> is contained in the <filename><replaceable>JPP_DIST</replaceable>/jboss-as/server/<replaceable>PROFILE</replaceable>/deploy/gatein.ear/META-INF/gatein-jboss-beans.xml</filename> file. +From the WCI servlet API login, the user is redirected to JAAS authentication. JBoss Portal Platform uses its own security domain (<emphasis role="bold">gatein-domain</emphasis>) with a set of predefined login modules. Login module configuration for <emphasis>gatein-domain</emphasis> is contained in the <filename><replaceable>JPP_DIST</replaceable>/gatein/gatein.ear/META-INF/gatein-jboss-beans.xml</filename> file. </para> <para> Below is the default login modules stack: Modified: epp/docs/branches/6.0/Reference_Guide/en-US/modules/AuthenticationAndIdentity/PasswordEncryption.xml =================================================================== --- epp/docs/branches/6.0/Reference_Guide/en-US/modules/AuthenticationAndIdentity/PasswordEncryption.xml 2013-01-25 02:15:12 UTC (rev 9077) +++ epp/docs/branches/6.0/Reference_Guide/en-US/modules/AuthenticationAndIdentity/PasswordEncryption.xml 2013-01-25 03:37:08 UTC (rev 9078) @@ -167,12 +167,12 @@ </step> <step> <para> - Deploy the <filename>codec-example.jar</filename> into your <filename><replaceable>JPP_DIST</replaceable>/jboss-as/server/<replaceable>PROFILE</replaceable>/deploy/gatein.ear/lib/</filename> directory. + Deploy the <filename>codec-example.jar</filename> into the <filename><replaceable>JPP_DIST</replaceable>/gatein/gatein.ear/lib/</filename> directory. </para> </step> <step> <para> - Start (or restart) your JBoss Portal Platform. + Start (or restart) JBoss Portal Platform. </para> <para> Any passwords written to the JCR will now be encoded and not plain text. Modified: epp/docs/branches/6.0/Reference_Guide/en-US/modules/PortalDevelopment/RTLFramework.xml =================================================================== --- epp/docs/branches/6.0/Reference_Guide/en-US/modules/PortalDevelopment/RTLFramework.xml 2013-01-25 02:15:12 UTC (rev 9077) +++ epp/docs/branches/6.0/Reference_Guide/en-US/modules/PortalDevelopment/RTLFramework.xml 2013-01-25 03:37:08 UTC (rev 9078) @@ -67,7 +67,7 @@ It works by appending -lt or -rt to the stylesheet name. </para> <para> - For instance: <filename><replaceable>JPP_DIST</replaceable>/jboss-as/server/<replaceable>PROFILE</replaceable>/deploy/gatein.ear/web.war/skin/portal/webui/component/UIFooterPortlet/DefaultStylesheet-rt.css</filename> will return the same stylesheet as <filename><replaceable>JPP_DIST</replaceable>/jboss-as/server/<replaceable>PROFILE</replaceable>/deploy/gatein.ear/web.war/skin/portal/webui/component/UIFooterPortlet/DefaultStylesheet.css</filename> but processed for the RT orientation. The <parameter>-lt</parameter> suffix is optional. + For instance: <filename><replaceable>JPP_HOME</replaceable>/gatein/gatein.ear/portal.war/templates/skin/portal/webui/component/UIFooterPortlet/DefaultStylesheet-rt.css</filename> will return the same stylesheet as <filename><replaceable>JPP_HOME</replaceable>/gatein/gatein.ear/portal.war/templates/skin/portal/webui/component/UIFooterPortlet/DefaultStylesheet.css</filename> but processed for the RT orientation. The <parameter>-lt</parameter> suffix is optional. </para> <para> Stylesheet authors can annotate their stylesheet to create content that depends on the orientation. @@ -112,7 +112,7 @@ The web resource filter uses the same naming pattern as the skin service. When an image ends with the -rt suffix the portal will attempt to locate the original image and create a mirror of it. </para> <para> - For instance: requesting the image <filename><replaceable>JPP_DIST</replaceable>/jboss-as/server/<replaceable>PROFILE</replaceable>/deploy/gatein.ear/01eXoResources.war/skin/DefaultSkin/webui/component/UITabSystem/UITabs/background/NormalTabStyle-rt.gif</filename> returns a mirror of the image <filename><replaceable>JPP_DIST</replaceable>/jboss-as/server/<replaceable>PROFILE</replaceable>/deploy/gatein.ear/01eXoResources.war/skin/DefaultSkin/webui/component/UITabSystem/UITabs/background/NormalTabStyle.gif</filename>. + For instance: requesting the image <filename><replaceable>JPP_HOME</replaceable>/gatein/gatein.ear/eXoResources.war/skin/DefaultSkin/webui/component/UITabSystem/UITabs/background/NormalTabStyle-rt.gif</filename> returns a mirror of the image <filename><replaceable>JPP_HOME</replaceable>/gatein/gatein.ear/eXoResources.war/skin/DefaultSkin/webui/component/UITabSystem/UITabs/background/NormalTabStyle.gif</filename>. </para> <note> <para> Modified: epp/docs/branches/6.0/Reference_Guide/en-US/modules/PortalDevelopment/Skinning.xml =================================================================== --- epp/docs/branches/6.0/Reference_Guide/en-US/modules/PortalDevelopment/Skinning.xml 2013-01-25 02:15:12 UTC (rev 9077) +++ epp/docs/branches/6.0/Reference_Guide/en-US/modules/PortalDevelopment/Skinning.xml 2013-01-25 03:37:08 UTC (rev 9078) @@ -534,7 +534,7 @@ <para> For example, the property can be passed as a JVM parameter with <literal>-D</literal> option when running JBoss Portal Platform. </para> - <programlisting><command>sh jboss-as/bin/run.sh -Dexo.product.developing=true</command></programlisting> + <programlisting><command>./bin/standalone.sh -Dexo.product.developing=true</command></programlisting>  <warning> <para> This option may cause display bugs in some browsers. Modified: epp/docs/branches/6.0/Reference_Guide/en-US/modules/PortletDevelopment/Standard.xml =================================================================== --- epp/docs/branches/6.0/Reference_Guide/en-US/modules/PortletDevelopment/Standard.xml 2013-01-25 02:15:12 UTC (rev 9077) +++ epp/docs/branches/6.0/Reference_Guide/en-US/modules/PortletDevelopment/Standard.xml 2013-01-25 03:37:08 UTC (rev 9078) @@ -142,12 +142,12 @@ </step> <step> <para> - Copy the package file into <literal><replaceable>JPP_DIST</replaceable>/jboss-as/server/default/deploy</literal>. + Copy the package file into <literal><replaceable>JPP_HOME</replaceable>/standalone/deployments</literal>. </para> </step> <step> <para> - Start JBoss Application Server (if it is not already running). + Start the portal (if it is not already running). </para> </step> <step> @@ -159,14 +159,6 @@ <para> Create a new portal page and add the portlet to it. </para> - <mediaobject> - <imageobject role="html"> - <imagedata width="444" align="center" scale="100" fileref="images/PortletDevelopment/Standard/first_portlet/deployed.png" format="PNG"/> - </imageobject> - <imageobject role="fo"> - <imagedata width="444" contentwidth="120mm" align="center" fileref="images/PortletDevelopment/Standard/first_portlet/deployed.png" format="PNG"/> - </imageobject> - </mediaobject> </step> </procedure> </section> Modified: epp/docs/branches/6.0/Reference_Guide/en-US/modules/WSRP.xml =================================================================== --- epp/docs/branches/6.0/Reference_Guide/en-US/modules/WSRP.xml 2013-01-25 02:15:12 UTC (rev 9077) +++ epp/docs/branches/6.0/Reference_Guide/en-US/modules/WSRP.xml 2013-01-25 03:37:08 UTC (rev 9078) @@ -75,13 +75,15 @@ JBoss Portal Platform provides complete support for WSRP 1.0 and 2.0 standard interfaces, and offers both consumer and producer services. Starting with version 2.1.0-GA of the component, WSRP is packaged as a JBoss Portal Platform extension, and is self-contained in a package named - <filename><replaceable>JPP_DIST</replaceable>/jboss-as/server/<replaceable>PROFILE</replaceable>/deploy/gatein-wsrp-integration.ear</filename> + <filename><replaceable>JPP_DIST</replaceable>/gatein/extensions/gatein-wsrp-integration.ear</filename> . </para> + <remark>NEEDINFO - FILE PATHS - there don't seem to be any config files that I can see in the directory below.</remark> <para>The only files of interest from a user perspective are located in the - <filename><replaceable>JPP_DIST</replaceable>/jboss-as/server/<replaceable>PROFILE</replaceable>/conf/gatein/</filename> + <filename><replaceable>JPP_DIST</replaceable>/standalone/configuration/gatein/wsrp</filename> directory.</para> + <remark>NEEDINFO - FILE PATHS - the wsse files are not present in the directory structure. Where do these live now?</remark> <itemizedlist> <listitem> <para><filename>gatein-wsse-consumer.xml</filename>, which allows you to configure WS-Security support for the consumer.</para> @@ -1038,13 +1040,14 @@ <para>While it is recommended you use the WSRP Configuration portlet to configure Consumers, the component provides an alternative way to configure consumers by adding an XML file called <filename>wsrp-consumers-config.xml</filename> in the - <filename><replaceable>JPP_DIST</replaceable>/jboss-as/server/<replaceable>PROFILE</replaceable>/conf/gatein/</filename> directory. + <filename><replaceable>JPP_DIST</replaceable>/standalone/configuration/gatein/wsrp/</filename> directory. </para> <note> <title>Note</title> + <remark>NEEDINFO - FILE PATH - while this path is valid, there is no XSD here any more. Should I just remove the note? Where is the XSD contained now?</remark> <para>An XML Schema defining which elements are available to configure Consumers via XML can be found in - <filename><replaceable>JPP_DIST</replaceable>/jboss-as/server/<replaceable>PROFILE</replaceable>/deploy/gatein-wsrp-integration.ear/lib/wsrp-integration-api-&WSRP_VERSION;.jar/xsd/gatein_wsrp_consumer_1_0.xsd </filename> + <filename><replaceable>JPP_DIST</replaceable>/gatein/extensions/gatein-wsrp-integration.ear/lib/jboss7integration.jar/ </filename> </para> </note> <important> @@ -1152,13 +1155,14 @@ </section> <section> <title>Examples</title> + <remark>NEEDINFO - FILE PATHS - this file was not present at the location specified. Where is this file now?</remark> <para> Here is the configuration of the <literal>selfv1</literal> and <literal>selfv2</literal> consumers as found in - <filename><replaceable>JPP_DIST</replaceable>/jboss-as/server/<replaceable>PROFILE</replaceable>/deploy/gatein-wsrp-integration.ear/lib/extension-component-&WSRP_VERSION;.jar/conf/wsrp-consumers-config.xml</filename> + <filename><replaceable>JPP_HOME</replaceable>/gatein/extensions/gatein-wsrp-integration.ear/lib/extension-component-&WSRP_VERSION;.jar/conf/wsrp-consumers-config.xml</filename> with a cache expiring every 500 seconds and with a 50 second timeout for web service operations. <note> <para> @@ -2151,8 +2155,8 @@ </section> </section> <section> -<title>Example implementation</title> - <para> + <title>Example implementation</title> + <para> We also provide a complete, end-to-end example to get you started, which you can find at <ulink url="https://github.com/gatein/gatein-wsrp/tree/master/examples/invocation-han..."/> . This example shows how @@ -2165,15 +2169,15 @@ <code>InvocationHandlerDelegate</code> , to establish a round-trip communication channel outside of the standard WSRP protocol, implementing the following scenario: </para> - <itemizedlist> - <listitem> - <para> + <itemizedlist> + <listitem> + <para> <code>ExampleConsumerInvocationHandlerDelegate</code> attaches to the consumer to add the current session id as an extension to render requests sent to the producer. </para> - </listitem> - <listitem> - <para> + </listitem> + <listitem> + <para> <code>ExampleProducerInvocationHandlerDelegate</code> provides the counterpart of <code>ExampleConsumerInvocationHandlerDelegate</code> @@ -2181,12 +2185,11 @@ <code>ExampleConsumerInvocationHandlerDelegate</code> sends and adds an extension of its own to the render response so that the consumer-side delegate can know that the information it passed was properly processed. </para> - </listitem> - </itemizedlist> - <sidebar> - <para>To activate the InvocationHandlerDelegates on both the consumer and producer, start your GateIn Portal instance as follows:</para> - </sidebar> -</section> - + </listitem> + </itemizedlist> + <sidebar> + <para>To activate the InvocationHandlerDelegates on both the consumer and producer, start your GateIn Portal instance as follows:</para> + </sidebar> + </section> </section> </chapter> Modified: epp/docs/branches/6.0/Reference_Guide/en-US/modules/eXoJCR/jcr/cluster-config.xml =================================================================== --- epp/docs/branches/6.0/Reference_Guide/en-US/modules/eXoJCR/jcr/cluster-config.xml 2013-01-25 02:15:12 UTC (rev 9077) +++ epp/docs/branches/6.0/Reference_Guide/en-US/modules/eXoJCR/jcr/cluster-config.xml 2013-01-25 03:37:08 UTC (rev 9078) @@ -12,6 +12,7 @@ <para> To deploy eXo JCR to the JBoss AS, do the following: </para> + <remark>NEEDINFO - FILE PATHS - do we need to do this for JPP 6. JCR is embedded isn't it?</remark> <procedure> <title/> <step> @@ -21,7 +22,7 @@ </step> <step> <para> - Copy the file into <filename><replaceable>JPP_DIST</replaceable>/jboss-as/server/<replaceable>PROFILE</replaceable>/deploy</filename> directory. + Copy the file into <filename><replaceable>JPP_HOME</replaceable>/standalone/deployments</filename> directory. </para> </step> <step> Modified: epp/docs/branches/6.0/Reference_Guide/en-US/modules/eXoJCR/jcr/configuration/jdbc-data-container-config.xml =================================================================== --- epp/docs/branches/6.0/Reference_Guide/en-US/modules/eXoJCR/jcr/configuration/jdbc-data-container-config.xml 2013-01-25 02:15:12 UTC (rev 9077) +++ epp/docs/branches/6.0/Reference_Guide/en-US/modules/eXoJCR/jcr/configuration/jdbc-data-container-config.xml 2013-01-25 03:37:08 UTC (rev 9078) @@ -113,7 +113,7 @@ Each database software supports ANSI SQL standards but also has its own specifics. Therefore each database has its own configuration setting in the eXo JCR as a database dialect parameter. More detailed configuration of the database can be set by editing the metadata SQL-script files. </para> <para> - You can find SQL-scripts in <filename>conf/storage/</filename> directory of the <filename><replaceable>JPP_DIST</replaceable>/jboss-as/server/<replaceable>PROFILE</replaceable>/deploy/gatein.ear/lib/exo.jcr.component.core-XXX.XXX.jar</filename> file . + You can find SQL-scripts in <filename>conf/storage/</filename> directory of the <filename><replaceable>JPP_HOME</replaceable>/modules/org/gatein/lib/main/exo.jcr.component.core-<remark>VERSION</remark>.jar</filename> file . </para> <para> The following tables show the correspondence between the scripts and databases: Modified: epp/docs/branches/6.0/Reference_Guide/en-US/modules/eXoJCR/jcr-with-gtn/managed-datasources-under-jboss-as.xml =================================================================== --- epp/docs/branches/6.0/Reference_Guide/en-US/modules/eXoJCR/jcr-with-gtn/managed-datasources-under-jboss-as.xml 2013-01-25 02:15:12 UTC (rev 9077) +++ epp/docs/branches/6.0/Reference_Guide/en-US/modules/eXoJCR/jcr-with-gtn/managed-datasources-under-jboss-as.xml 2013-01-25 03:37:08 UTC (rev 9078) @@ -9,6 +9,7 @@ <title>Configurations Steps</title> <section id="sect-Reference_Guide-Configurations_Steps-Declaring_the_datasources_in_the_AS"> <title>Declaring the datasources in the AS</title> + <remark>NEEDINFO - FILE PATHS - I know this isn't right. Where do these get deployed again?</remark> <para> To declare the datasources using a JBoss application server, deploy a <literal>ds</literal> file (<filename><replaceable>XXX</replaceable>-ds.xml</filename>) into the <emphasis>deploy</emphasis> directory of the appropriate server profile (<filename>/server/<replaceable>PROFILE</replaceable>/deploy</filename>, for example). </para> @@ -59,7 +60,9 @@ <section id="sect-Reference_Guide-Configurations_Steps-Do_not_bind_datasources_explicitly"> <title>Do not bind datasources explicitly</title> <para> - Do not let the portal explicitly bind datasources. Edit the <filename><replaceable>JPP_DIST</replaceable>/jboss-as/server/<replaceable>PROFILE</replaceable>/conf/gatein/configuration.properties</filename> and comment out the following rows in the JCR section: + Do not let the portal explicitly bind datasources. </para> + <remark>NEEDINFO - FILE PATHS - I think some of the values have changed here when I look at the new file below. New info required?</remark> + <para>Edit the <filename><replaceable>JPP_HOME</replaceable>/standalone/configuration/gatein/configuration.properties</filename> and comment out the following rows in the JCR section: </para> <programlisting>#gatein.jcr.datasource.driver=org.hsqldb.jdbcDriver #gatein.jcr.datasource.url=jdbc:hsqldb:file:${gatein.db.data.dir}/data/jdbcjcr_${name} @@ -73,7 +76,7 @@ #gatein.idm.datasource.username=sa #gatein.idm.datasource.password=</programlisting> <para> - Open the <filename>jcr-configuration.xml</filename> and <filename>idm-configuration.xml</filename> files ans comment out references to the plug-in <literal>InitialContextInitializer</literal>. + Open the <filename>jcr-configuration.xml</filename> and <filename>idm-configuration.xml</filename> files and comment out references to the plug-in <literal>InitialContextInitializer</literal>. </para> <programlisting language="XML" role="XML"> <!--

11 years, 3 months

1
0
0 / 0

gatein SVN: r9077 - in epp/docs/branches/6.0/Reference_Guide/en-US: modules/Advanced/Foundations and 7 other directories.

by do-not-reply＠jboss.org

Author: jaredmorgs Date: 2013-01-24 21:15:12 -0500 (Thu, 24 Jan 2013) New Revision: 9077 Modified: epp/docs/branches/6.0/Reference_Guide/en-US/Reference_Guide.ent epp/docs/branches/6.0/Reference_Guide/en-US/Revision_History.xml epp/docs/branches/6.0/Reference_Guide/en-US/modules/Advanced/Foundations/Configuring_Services.xml epp/docs/branches/6.0/Reference_Guide/en-US/modules/AuthenticationAndIdentity/AuthenticationAuthorizationOverview.xml epp/docs/branches/6.0/Reference_Guide/en-US/modules/AuthenticationAndIdentity/CoreOrganizationInitializer.xml epp/docs/branches/6.0/Reference_Guide/en-US/modules/AuthenticationAndIdentity/PasswordEncryption.xml epp/docs/branches/6.0/Reference_Guide/en-US/modules/AuthenticationAndIdentity/PredefinedUserConfiguration.xml epp/docs/branches/6.0/Reference_Guide/en-US/modules/AuthenticationAndIdentity/SSO.xml epp/docs/branches/6.0/Reference_Guide/en-US/modules/PortalDevelopment/DefaultPortalConfiguration.xml epp/docs/branches/6.0/Reference_Guide/en-US/modules/PortalDevelopment/DefaultPortalNavigationConfiguration.xml epp/docs/branches/6.0/Reference_Guide/en-US/modules/PortalDevelopment/LocalizationConfiguration.xml epp/docs/branches/6.0/Reference_Guide/en-US/modules/PortalDevelopment/Skinning.xml epp/docs/branches/6.0/Reference_Guide/en-US/modules/PortletDevelopment/Global_Portlet.xml epp/docs/branches/6.0/Reference_Guide/en-US/modules/PortletDevelopment/PortletBridge.xml epp/docs/branches/6.0/Reference_Guide/en-US/modules/PortletDevelopment/PortletBridge/configuration.xml epp/docs/branches/6.0/Reference_Guide/en-US/modules/PortletDevelopment/Standard.xml epp/docs/branches/6.0/Reference_Guide/en-US/modules/eXoJCR/jcr/configuration/exo-jcr-configuration.xml epp/docs/branches/6.0/Reference_Guide/en-US/modules/eXoJCR/jcr/configuration/multilanguage-support.xml epp/docs/branches/6.0/Reference_Guide/en-US/modules/eXoJCR/jcr/configuration/search-configuration.xml epp/docs/branches/6.0/Reference_Guide/en-US/modules/eXoJCR/jcr/jbosscache-configuration-templates.xml epp/docs/branches/6.0/Reference_Guide/en-US/modules/eXoJCR/jcr/searching/searching-repository-content.xml Log: Removed all instances of 02portal and changed to just portal, updated file paths to portal.xml and portlet.xml, except when they related to portlet bridge. Modified: epp/docs/branches/6.0/Reference_Guide/en-US/Reference_Guide.ent =================================================================== --- epp/docs/branches/6.0/Reference_Guide/en-US/Reference_Guide.ent 2013-01-25 01:01:20 UTC (rev 9076) +++ epp/docs/branches/6.0/Reference_Guide/en-US/Reference_Guide.ent 2013-01-25 02:15:12 UTC (rev 9077) @@ -17,4 +17,4 @@ <!ENTITY VX "6"> <!ENTITY VY "6.0"> <!ENTITY VZ "6.0.0"> -<!ENTITY WSRP_VERSION "CHANGEME"> +<!ENTITY WSRP_VERSION "2.2.2.Final"> 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-01-25 01:01:20 UTC (rev 9076) +++ epp/docs/branches/6.0/Reference_Guide/en-US/Revision_History.xml 2013-01-25 02:15:12 UTC (rev 9077) @@ -275,7 +275,7 @@ <revdescription> <simplelist> <member>BZ#856417 - Added Examples to Portlet Bridge section from content in https://docs.jboss.org/author/display/PBR/Examples, and did a final review of content before submitting JSF2 and RF4 tasks for QE validation. </member> - <member>Also removed text references to JBoss Enterprise Portal Platform, Enterprise Portal Platform, EPP_HOME, and EPP_DIST.</member> + <member>Also removed text references to JBoss Enterprise Portal Platform, Enterprise Portal Platform, JPP_HOME, and JPP_DIST.</member> </simplelist> </revdescription> </revision> @@ -415,7 +415,7 @@ </author> <revdescription> <simplelist> - <member>Bug 850746 - Remove Chapter 41. eXo JCR Backup Service and Chapter 42. HTTPBackupAgent and Backup Client from EPP Reference Guide.</member> + <member>Bug 850746 - Remove Chapter 41. eXo JCR Backup Service and Chapter 42. HTTPBackupAgent and Backup Client from JPP Reference Guide.</member> </simplelist> </revdescription> </revision> Modified: epp/docs/branches/6.0/Reference_Guide/en-US/modules/Advanced/Foundations/Configuring_Services.xml =================================================================== --- epp/docs/branches/6.0/Reference_Guide/en-US/modules/Advanced/Foundations/Configuring_Services.xml 2013-01-25 01:01:20 UTC (rev 9076) +++ epp/docs/branches/6.0/Reference_Guide/en-US/modules/Advanced/Foundations/Configuring_Services.xml 2013-01-25 02:15:12 UTC (rev 9077) @@ -21,7 +21,7 @@ All <filename>configuration.xml</filename> files located at <filename>conf/portal/configuration.xml</filename> in the classpath will have their services configured at the <literal>PortalContainer</literal> scope. </para> <para> - Additionally, <emphasis role="bold">portal extensions</emphasis> can use configuration information stored in <filename><replaceable>JPP_DIST</replaceable>/jboss-as/server/<replaceable>PROFILE</replaceable>/deploy/gatein.ear/02portal.war/WEB-INF/conf/configuration.xml</filename>, and will also have their services configured in the <literal>PortalContainer</literal> scope. + Additionally, <emphasis role="bold">portal extensions</emphasis> can use configuration information stored in <filename><replaceable>JPP_DIST</replaceable>/gatein/gatein.ear/portal.war/WEB-INF/conf/configuration.xml</filename>, and will also have their services configured in the <literal>PortalContainer</literal> scope. </para> <para> When eXo kernel reads a configuration, it loads the file from the kernel jar using the classloader and does not use an internet connection to resolve the file. Modified: epp/docs/branches/6.0/Reference_Guide/en-US/modules/AuthenticationAndIdentity/AuthenticationAuthorizationOverview.xml =================================================================== --- epp/docs/branches/6.0/Reference_Guide/en-US/modules/AuthenticationAndIdentity/AuthenticationAuthorizationOverview.xml 2013-01-25 01:01:20 UTC (rev 9076) +++ epp/docs/branches/6.0/Reference_Guide/en-US/modules/AuthenticationAndIdentity/AuthenticationAuthorizationOverview.xml 2013-01-25 02:15:12 UTC (rev 9077) @@ -5,11 +5,7 @@ ]> <chapter id="sect-Reference_Guide-Authentication_Authorization_Intro"> <title>Authentication and Authorization intro</title> - <remark> - ======================================================= - NOTE: Content updated to wiki version 4 (11 Jan 2013) - =======================================================</remark> - + <remark> ======================================================= NOTE: Content updated to wiki version 4 (11 Jan 2013) =======================================================</remark> <section id="sect-Reference_Guide-Authentication_Authorization_Intro-Authentication"> <title>Authentication Overview</title> <para> @@ -32,19 +28,19 @@ <listitem> <remark>FIXME: Correct the following link</remark> <para> - SSO server integration (CAS, JOSSO, OpenSSO). Refer to ** xref linkend="sect-Reference_Guide-SSO_Single_Sign_On"/ for more information. + SSO server integration (CAS, JOSSO, OpenSSO). Refer to ** xref linkend="sect-Reference_Guide-SSO_Single_Sign_On"/ for more information. </para> </listitem> <listitem> <remark>FIXME: Correct the following link</remark> <para> - SPNEGO authentication with a Kerberos ticket. Refer to ** xref linkend="sect-Reference_Guide-SSO_Single_Sign_On_-SPNEGO_Simple_and_Protected_GSSAPI_Negotiation_Mechanism"/ for more information. + SPNEGO authentication with a Kerberos ticket. Refer to ** xref linkend="sect-Reference_Guide-SSO_Single_Sign_On_-SPNEGO_Simple_and_Protected_GSSAPI_Negotiation_Mechanism"/ for more information. </para> </listitem> <listitem> - <para> + <para> <remark>FIXME: Fix the following link</remark> - SAML2 based authentication. Refer to ** xref linkend="sect-Reference_Guide-SSO_Single_Sign_On_-SAML2"/ for more information. + SAML2 based authentication. Refer to ** xref linkend="sect-Reference_Guide-SSO_Single_Sign_On_-SAML2"/ for more information. </para> </listitem> <listitem> @@ -111,7 +107,7 @@ </mediaobject> </para> <para> - Changes to the appearance of this login page can be made in this JSP file. Alternatively you can create an extension and override this page via extension if you don't want to edit it directly. You can also change images or CSS placed in <filename><replaceable>JPP_DIST</replaceable>/jboss-as/server/<replaceable>PROFILE</replaceable>/deploy/gatein.ear/login/skin</filename> . + Changes to the appearance of this login page can be made in this JSP file. Alternatively you can create an extension and override this page via extension if you don't want to edit it directly. You can also change images or CSS placed in <filename><replaceable>JPP_DIST</replaceable>/jboss-as/server/<replaceable>PROFILE</replaceable>/deploy/gatein.ear/login/skin</filename> . </para> <para> After a user submits the login form, they are redirected to the login URL: <ulink url="http://localhost:8080/portal/login?username=root&password=gtn&ini..." type="http">http://localhost:8080/portal/login?username=root&password=gtn&ini...</ulink>. @@ -128,9 +124,7 @@ <para> Below is the default login modules stack: </para> - <remark> - QUESTION: Does the reference below "JBossAS7LoginModule" need to be changed? - </remark> + <remark> QUESTION: Does the reference below "JBossAS7LoginModule" need to be changed? </remark> <programlisting language="XML" role="XML"><![CDATA[ <security-domain name="gatein-domain" cache-type="default"> <authentication> @@ -151,9 +145,9 @@ <para> New login modules can be added or the stack completely replaced with custom modules. </para> - <remark>QUESTION: Should the following reference be to official Red Hat documentation instead of Oracle's?</remark> + <remark>QUESTION: Should the following reference be to official Red Hat documentation instead of Oracle's?</remark> <para> - Authentication starts with the login method of each login module being invoked. After all login methods are invoked, the authentication is continued by invoking the commit method on each login module. Both login and commit methods can throw LoginException. If it happens, then the whole authentication ends unsuccessfully, which in turn invokes the abort method on each login module. By returning "false" from the login method, you can ensure that the login module is ignored. This is not specific to JBoss Portal Platform but it is generic to JAAS. Refer to <ulink type="http" url="http://docs.oracle.com/javase/6/docs/technotes/guides/security/jaas/JAASR...">http://docs.oracle.com/javase/6/docs/technotes/guides/security/jaas/JAASR...</ulink> here for more information about login modules in general. + Authentication starts with the login method of each login module being invoked. After all login methods are invoked, the authentication is continued by invoking the commit method on each login module. Both login and commit methods can throw LoginException. If it happens, then the whole authentication ends unsuccessfully, which in turn invokes the abort method on each login module. By returning "false" from the login method, you can ensure that the login module is ignored. This is not specific to JBoss Portal Platform but it is generic to JAAS. Refer to <ulink url="http://docs.oracle.com/javase/6/docs/technotes/guides/security/jaas/JAASR..." type="http">http://docs.oracle.com/javase/6/docs/technotes/guides/security/jaas/JAASR...</ulink> here for more information about login modules in general. </para> <section id="sect-Authentication_Authorization_Intro-existingLM"> <title>Existing login modules</title> @@ -167,7 +161,7 @@ <listitem> <remark>FIXME: Fix the link to the relevant CAS section</remark> <para> - It's useful only if SSO authentication is enabled (disabled by default. It can be enabled through properties in configuration.properties file and in this case it delegates the work to another real login module for SSO integration. If SSO is disabled, SSODelegateLoginModule is simply ignored. See ** xref linkend="Central Authentication Service (CAS)#Configuration"/ properties details for more details. If SSO is used and SSO authentication succeed, the special Identity object will be created and saved into shared state map (Map, which is shared between all login modules), so that this Identity object can be used by JBossAS7LoginModule or other login modules in the JAAS chain. + It's useful only if SSO authentication is enabled (disabled by default. It can be enabled through properties in configuration.properties file and in this case it delegates the work to another real login module for SSO integration. If SSO is disabled, SSODelegateLoginModule is simply ignored. See ** xref linkend="Central Authentication Service (CAS)#Configuration"/ properties details for more details. If SSO is used and SSO authentication succeed, the special Identity object will be created and saved into shared state map (Map, which is shared between all login modules), so that this Identity object can be used by JBossAS7LoginModule or other login modules in the JAAS chain. </para> </listitem> </varlistentry> @@ -180,11 +174,9 @@ </listitem> </varlistentry> </variablelist> - <para> Some other login modules are not active by default, but can be added them if you find them useful. </para> - <variablelist> <varlistentry> <term>CustomMembershipLoginModule</term> @@ -193,32 +185,31 @@ Special login module, which can be used to add a user to existing groups during a successful login of this user. The group name is configurable and by default is /platform/users group. This login module is not used because in normal environment, users are already in the /platform/users group. It is useful only for some special setups like read-only LDAP, where groups of an LDAP user are taken from the LDAP tree so that users may not be in the /platform/users group, which is needed for successful authorization. </para> <para> - Note that the CustomMembershipLoginModule can't be the first login module in the LoginModule chain because it assumes that the Identity object is already available in shared state. So there are two possible cases. For an non-SSO case, you may need to chain this LM with other login modules, which can be used to establish Identity and add it into shared state. Those LM can be InitSharedStateLoginModule and SharedStateLoginModule. For an SSO case, you can add CustomMembershipLoginModule between SSODelegateLoginModule and JBossAS7LoginModule. + Note that the CustomMembershipLoginModule can't be the first login module in the LoginModule chain because it assumes that the Identity object is already available in shared state. So there are two possible cases. For an non-SSO case, you may need to chain this LM with other login modules, which can be used to establish Identity and add it into shared state. Those LM can be InitSharedStateLoginModule and SharedStateLoginModule. For an SSO case, you can add CustomMembershipLoginModule between SSODelegateLoginModule and JBossAS7LoginModule. </para> </listitem> </varlistentry> <varlistentry> - <term>InitSharedStateLoginModule</term> - <listitem> - <para> - It can read credentials from JAAS callback and add them into shared state. It's intended to be used in JAAS chain before SharedStateLoginModule + <term>InitSharedStateLoginModule</term> + <listitem> + <para> + It can read credentials from JAAS callback and add them into shared state. It's intended to be used in JAAS chain before SharedStateLoginModule </para> - </listitem> + </listitem> </varlistentry> <varlistentry> - <term>SharedStateLoginModule</term> - <listitem> - <para> + <term>SharedStateLoginModule</term> + <listitem> + <para> It reads username and password from sharedState map from attributes javax.security.auth.login.name and javax.security.auth.login.password. Then it calls Authenticator.validateUser(Credential[] credentials), to perform authentication of username and password against OrganizationService and portal identity database. Result of successful authentication is object Identity, which is saved to sharedState map. </para> - </listitem> + </listitem> </varlistentry> </variablelist> - <para> Configuration example with CustomMembershipLoginModule and disabled SSO: </para> - <programlisting language="XML" role="XML"><![CDATA[ + <programlisting language="XML" role="XML"><![CDATA[ <login-module code="org.exoplatform.web.security.InitSharedStateLoginModule" flag="required"> <module-option name="portalContainerName" value="portal"/> <module-option name="realmName" value="gatein-domain"/> @@ -238,12 +229,10 @@ <module-option name="realmName" value="gatein-domain"/> </login-module>]]> </programlisting> - <para> And a configuration example with enabled SSO: </para> - - <programlisting language="XML" role="XML"><![CDATA[ + <programlisting language="XML" role="XML"><![CDATA[ <login-module code="org.gatein.sso.integration.SSODelegateLoginModule" flag="required"> <module-option name="enabled" value="${gatein.sso.login.module.enabled}" /> <module-option name="delegateClassName" value="${gatein.sso.login.module.class}" /> @@ -262,11 +251,8 @@ <module-option name="realmName" value="gatein-domain"/> </login-module>]]> </programlisting> - - </section> - - <section id="sect-Authentication_Authorization_Intro-createNewLM"> + <section id="sect-Authentication_Authorization_Intro-createNewLM"> <title>Creating your own login module</title> <para> Before creating your own login module, it is recommended that you study the source code of existing login modules to better understand the JAAS authentication process. You need to have good knowledge so that you can properly decide where your login module should be placed and if you need to replace some existing login modules or simply attach your own module to the existing chain. @@ -303,8 +289,7 @@ </para> </formalpara> </section> - - <section id="sect-Authentication_Authorization_Intro-authenticatorAndRolesExtractor"> + <section id="sect-Authentication_Authorization_Intro-authenticatorAndRolesExtractor"> <title>Authenticator and RolesExtractor</title> <para> Authenticator is an important component in the authentication process. The interface <emphasis>org.exoplatform.services.security.Authenticator</emphasis> looks like this: @@ -439,7 +424,7 @@ <section id="sect-Authentication_Authorization_Intro-RememberMeAuthentication-RemindPasswordTokenService"> <title>RemindPasswordTokenService</title> <para> - This is a special service used during the RememberMe authentication workflow. It is configurable in the file <filename><replaceable>JPP_DIST</replaceable>/jboss-as/server/<replaceable>PROFILE</replaceable>/deploy/gatein.ear/02portal.war/WEB-INF/conf/common/remindpwd-configuration.xml</filename> . For more info, look at section <xref linkend="sect-Reference_Guide-Authentication_Token_Configuration"/> + This is a special service used during the RememberMe authentication workflow. It is configurable in the file <filename><replaceable>JPP_DIST</replaceable>/gatein/gatein.ear/portal.war/WEB-INF/conf/common/remindpwd-configuration.xml</filename> . For more info, look at section <xref linkend="sect-Reference_Guide-Authentication_Token_Configuration"/> </para> <para> You can encrypt passwords before storing them in JCR. More info is in section <xref linkend="sect-Reference_Guide-Authentication_and_Identity-Password_Encryption"/>. @@ -447,73 +432,73 @@ </section> </section> <section id="sect-Authentication_Authorization_Intro-authorization"> - <title>Authorization overview</title> - <para> + <title>Authorization overview</title> + <para> In the previous section, you learned about JAAS authentication and about login modules. So you know the result of authentication, including: </para> - <itemizedlist> - <listitem> - <para> + <itemizedlist> + <listitem> + <para> JAAS Subject with principals for username (UserPrincipal) and for JAAS roles (RolesPrincipal). </para> - </listitem> - <listitem> - <para> + </listitem> + <listitem> + <para> Identity object, which encapsulates username, all memberships and all JAAS roles. This Identity object is bound to IdentityRegistry component. </para> - </listitem> - </itemizedlist> - <para> + </listitem> + </itemizedlist> + <para> Authorization in JBoss Portal Platform actually happens on two levels: </para> - <section id="sect-Authentication_Authorization_Intro-servletContainerAuthorization"> - <title>Servlet container authorization</title> - <para> + <section id="sect-Authentication_Authorization_Intro-servletContainerAuthorization"> + <title>Servlet container authorization</title> + <para> First round of authorization is servlet container authorization based on secured URL from <filename>web.xml</filename>. We saw above in web.xml snippet that secured URL are accessible only for users from role <emphasis>users</emphasis>: </para> - <programlisting language="XML" role="XML"><![CDATA[ + <programlisting language="XML" role="XML"><![CDATA[ <auth-constraint> <role-name>users</role-name> </auth-constraint>]]></programlisting> - <remark>FIXME: correct the link to 'Login modules'</remark> - <para> + <remark>FIXME: correct the link to 'Login modules'</remark> + <para> This actually means that our user needs to be in JBoss Portal Platform role <emphasis>/platform/users</emphasis> (For details see <xref linkend="sect-Authentication_Authorization_Intro-authenticatorAndRolesExtractor"/>). In other words, if we successfully authenticate but our user is not in group <emphasis>/platform/users</emphasis>, then it means that he is not in JAAS role <emphasis>users</emphasis>, which in turn means that they will have authorization error <emphasis role="bold">403 Forbidden</emphasis> thrown by servlet container. For example in LDAP setup, your users may not be in /platform/users by default, but you can use CustomMembershipLoginModule to fix this problem. For details see ** Login modules**. </para> - <para> + <para> You can change the behavior and possibly add some more <emphasis>auth-constraint</emphasis> elements into <filename>web.xml</filename>. However this protection of resources based on web.xml is not standard JBoss Portal Platform method and is mentioned here mainly for illustration purposes. </para> - </section> - <section id="sect-Authentication_Authorization_Intro-gateInAuthorization"> - <title>Portal level authorization</title> - <para> + </section> + <section id="sect-Authentication_Authorization_Intro-gateInAuthorization"> + <title>Portal level authorization</title> + <para> The second round of authorization is based on the component <emphasis role="bold">UserACL</emphasis> (See <xref linkend="chap-Reference_Guide-Portal_Default_Permission_Configuration"/>). You can declare access and edit permissions for portals, pages and/or portlets. UserACL is then used to check if our user has particular permissions to access or edit specified resources. An important object containing information about the roles of our user is the <emphasis>Identity</emphasis> object created during JAAS authentication. </para> - <para> + <para> Authorization on portal level looks like this: </para> - <itemizedlist> - <listitem> - <para> + <itemizedlist> + <listitem> + <para> The user sends a HTTP request to some URLs in portal; </para> - </listitem> - <listitem> - <para> - The HTTP request is processed through <literal>SetCurrentIdentityFilter</literal>, which is declared in <filename><replaceable>JPP_DIST</replaceable>/jboss-as/server/<replaceable>PROFILE</replaceable>/deploy/gatein.ear/02portal.war/WEB-INF/web.xml</filename>. + </listitem> + <listitem> + <para> + The HTTP request is processed through <literal>SetCurrentIdentityFilter</literal>, which is declared in <filename><replaceable>JPP_DIST</replaceable>/gatein/gatein.ear/portal.war/WEB-INF/web.xml</filename>. </para> - </listitem> - <listitem> - <para> + </listitem> + <listitem> + <para> SetCurrentIdentityFilter reads username of current user from <emphasis>HttpServletRequest.getRemoteUser()</emphasis>. Then it looks for Identity of this user in IdentityRegistry, where Identity has been saved during authentication. The Identity found is then encapsulated into a <emphasis role="bold">ConversationState</emphasis> object and bound into the ThreadLocal variable. </para> - </listitem> - <listitem> - <para> + </listitem> + <listitem> + <para> UserACL is able to obtain Identity of current user from method <emphasis>UserACL.getIdentity()</emphasis>, which simply calls <emphasis>ConversationState.getCurrent().getIdentity()</emphasis> to find the current Identity bound to ThreadLocal. Now the UserACL has the identity of the user and can perform any security checks. </para> - </listitem> - </itemizedlist> + </listitem> + </itemizedlist> + </section> </section> </section> - </section> </chapter> Modified: epp/docs/branches/6.0/Reference_Guide/en-US/modules/AuthenticationAndIdentity/CoreOrganizationInitializer.xml =================================================================== --- epp/docs/branches/6.0/Reference_Guide/en-US/modules/AuthenticationAndIdentity/CoreOrganizationInitializer.xml 2013-01-25 01:01:20 UTC (rev 9076) +++ epp/docs/branches/6.0/Reference_Guide/en-US/modules/AuthenticationAndIdentity/CoreOrganizationInitializer.xml 2013-01-25 02:15:12 UTC (rev 9077) @@ -8,11 +8,11 @@ <para>The plug-in is particularly useful when using the Site Publisher add-on, and directly adding users or groups to a LDAP server through LDIF files, or into a database using SQL. </para> <section> <title>Enable Initializer</title> - <para>The initializer is disabled by default. To activate it, uncomment the block containing the path to the <filename>initializer-configuration.xml</filename> file in <filename><replaceable>JPP_DIST</replaceable>/jboss-as/server/<replaceable>PROFILE</replaceable>/deploy/gatein.ear/02portal.war/conf/configuration.xml</filename>. + <para>The initializer is disabled by default. To activate it, uncomment the block containing the path to the <filename>initializer-configuration.xml</filename> file in <filename><replaceable>JPP_DIST</replaceable>/gatein/gatein.ear/portal.war/conf/configuration.xml</filename>. </para> <programlisting language="XML"> <import>war:/conf/organization/initializer-configuration.xml</import></programlisting> - <para>All configuration for the initializer occurs in <filename><replaceable>JPP_DIST</replaceable>/jboss-as/server/<replaceable>PROFILE</replaceable>/deploy/gatein.ear/02portal.war/conf/organization/initializer-configuration.xml</filename>, which is the main configuration file + <para>All configuration for the initializer occurs in <filename><replaceable>JPP_DIST</replaceable>/gatein/gatein.ear/portal.war/conf/organization/initializer-configuration.xml</filename>, which is the main configuration file for this initializer. More details about configuration options, along with alternatives to XML directive configuration, are described in subsequent sections.</para> </section> <section> @@ -79,7 +79,7 @@ </section> <section id="Triggering_Operations"> <title>Using configuration directives</title> - <para>There are a number of ways of controlling operations associated with CoreOrganizationInitializer. All parameters are configured in <value-param> directive blocks in the <filename><replaceable>JPP_DIST</replaceable>/jboss-as/server/<replaceable>PROFILE</replaceable>/deploy/gatein.ear/02portal.war/conf/organization/initializer-configuration.xml</filename> file.</para> + <para>There are a number of ways of controlling operations associated with CoreOrganizationInitializer. All parameters are configured in <value-param> directive blocks in the <filename><replaceable>JPP_DIST</replaceable>/gatein/gatein.ear/portal.war/conf/organization/initializer-configuration.xml</filename> file.</para> <example> <title><value-param> block for initializer directives</title> <programlisting language="XML"><value-param> @@ -91,7 +91,7 @@ <title>Disable launchAll at Startup</title> <para>For large implementations with many users and groups, consider disabling <parameter>launchAll</parameter> functionality during start-up for each portal container. Disabling this operation during start-up will result in a performance improvement.</para> <step> - <para>Open <filename><replaceable>JPP_DIST</replaceable>/jboss-as/server/<replaceable>PROFILE</replaceable>/deploy/gatein.ear/02portal.war/conf/organization/initializer-configuration.xml</filename></para> + <para>Open <filename><replaceable>JPP_DIST</replaceable>/gatein/gatein.ear/portal.war/conf/organization/initializer-configuration.xml</filename></para> </step> <step> <para>Locate the <parameter>executeAllListenersDuringBoot</parameter> <value-param> parameter.</para> @@ -104,7 +104,7 @@ <title>Disable launchAll Job Scheduler</title> <para>A job scheduler is configured to run by default, and executes <parameter>launchAll</parameter> periodically. For large implementations with many users and groups, consider disabling the Job scheduler <parameter>launchAll</parameter> functionality for each portal container. Disabling this operation may result in a performance improvement.</para> <step> - <para>Open <filename><replaceable>JPP_DIST</replaceable>/jboss-as/server/<replaceable>PROFILE</replaceable>/deploy/gatein.ear/02portal.war/conf/organization/initializer-configuration.xml</filename></para> + <para>Open <filename><replaceable>JPP_DIST</replaceable>/gatein/gatein.ear/portal.war/conf/organization/initializer-configuration.xml</filename></para> </step> <step> <para>Search for "scheduler" in the file.</para> @@ -117,7 +117,7 @@ <title>Alter the way JCR objects are created on-demand, at user login. </title> <para>When a user logs into the portal, the <parameter>treatUser</parameter> operation runs on-demand to create the required JCR objects. This operation (activated by default) improves overall performance of the portal, because user objects are only created when needed. To disable the operation (not recommended), follow the guidelines below.</para> <step> - <para>Open <filename><replaceable>JPP_DIST</replaceable>/jboss-as/server/<replaceable>PROFILE</replaceable>/deploy/gatein.ear/02portal.war/conf/organization/initializer-configuration.xml</filename></para> + <para>Open <filename><replaceable>JPP_DIST</replaceable>/gatein/gatein.ear/portal.war/conf/organization/initializer-configuration.xml</filename></para> </step> <step> <para>Locate the <parameter>ExtensibleFilter</parameter> directive block.</para> Modified: epp/docs/branches/6.0/Reference_Guide/en-US/modules/AuthenticationAndIdentity/PasswordEncryption.xml =================================================================== --- epp/docs/branches/6.0/Reference_Guide/en-US/modules/AuthenticationAndIdentity/PasswordEncryption.xml 2013-01-25 01:01:20 UTC (rev 9076) +++ epp/docs/branches/6.0/Reference_Guide/en-US/modules/AuthenticationAndIdentity/PasswordEncryption.xml 2013-01-25 02:15:12 UTC (rev 9077) @@ -139,7 +139,7 @@ <orderedlist> <listitem> <para> - The <emphasis>Remember Me</emphasis> feature can be disabled by removing the corresponding checkbox in: <filename><replaceable>JPP_DIST</replaceable>/jboss-as/server/<replaceable>PROFILE</replaceable>/deploy/gatein.ear/02portal.war/login/jsp/login.jsp</filename> and <filename><replaceable>JPP_DIST</replaceable>/jboss-as/server/<replaceable>PROFILE</replaceable>/deploy/gatein.ear/02portal.war/groovy/portal/webui/UILoginForm.gtmpl</filename>. + The <emphasis>Remember Me</emphasis> feature can be disabled by removing the corresponding checkbox in: <filename><replaceable>JPP_DIST</replaceable>/gatein/gatein.ear/portal.war/login/jsp/login.jsp</filename> and <filename><replaceable>JPP_DIST</replaceable>/gatein/gatein.ear/portal.war/groovy/portal/webui/UILoginForm.gtmpl</filename>. </para> </listitem> <listitem> Modified: epp/docs/branches/6.0/Reference_Guide/en-US/modules/AuthenticationAndIdentity/PredefinedUserConfiguration.xml =================================================================== --- epp/docs/branches/6.0/Reference_Guide/en-US/modules/AuthenticationAndIdentity/PredefinedUserConfiguration.xml 2013-01-25 01:01:20 UTC (rev 9076) +++ epp/docs/branches/6.0/Reference_Guide/en-US/modules/AuthenticationAndIdentity/PredefinedUserConfiguration.xml 2013-01-25 02:15:12 UTC (rev 9077) @@ -8,7 +8,7 @@ <section id="sect-Reference_Guide-Predefined_User_Configuration-Overview"> <title>Overview</title> <para> - The initial Organization configuration should be specified by editing the content of <filename><replaceable>JPP_DIST</replaceable>/jboss-as/server/<replaceable>PROFILE</replaceable>/deploy/gatein.ear/02portal.war:/WEB-INF/conf/organization/organization-configuration.xml</filename>. This file uses the portal XML configuration schema. It lists several configuration plug-ins. + The initial Organization configuration should be specified by editing the content of <filename><replaceable>JPP_DIST</replaceable>/gatein/gatein.ear/portal.war:/WEB-INF/conf/organization/organization-configuration.xml</filename>. This file uses the portal XML configuration schema. It lists several configuration plug-ins. </para> </section> <section id="sect-Reference_Guide-Predefined_User_Configuration-Plugin_for_adding_users_groups_and_membership_types"> @@ -33,7 +33,7 @@ </para> <note> <para> - See <literal>02portal.war:/WEB-INF/conf/organization/organization-configuration.xml</literal> for the full content. + See <literal><replaceable>JPP_HOME</replaceable>/gatein/gatein.ear/portal.war/WEB-INF/conf/organization/organization-configuration.xml</literal> for the full content. </para> </note> <programlisting language="XML" role="XML"><xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="../../extras/Authentication_Identity_PredefinedUserConfiguration/default98.xml" parse="text"/></programlisting> @@ -45,7 +45,7 @@ </para> <note> <para> - See <literal>02portal.war:/WEB-INF/conf/organization/organization-configuration.xml</literal> for the full content. + See <literal>JPP_HOME/gatein/gatein.ear/portal.war/WEB-INF/conf/organization/organization-configuration.xml</literal> for the full content. </para> </note> <programlisting language="XML" role="XML"><xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="../../extras/Authentication_Identity_PredefinedUserConfiguration/default99.xml" parse="text"/></programlisting> @@ -57,7 +57,7 @@ </para> <note> <para> - See <literal>02portal.war:/WEB-INF/conf/organization/organization-configuration.xml</literal> for the full content. + See <literal><replaceable>JPP_HOME</replaceable>/gatein/gatein.ear/portal.war/WEB-INF/conf/organization/organization-configuration.xml</literal> for the full content. </para> </note> <programlisting language="XML" role="XML"><xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="../../extras/Authentication_Identity_PredefinedUserConfiguration/default100.xml" parse="text"/></programlisting> 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-01-25 01:01:20 UTC (rev 9076) +++ epp/docs/branches/6.0/Reference_Guide/en-US/modules/AuthenticationAndIdentity/SSO.xml 2013-01-25 02:15:12 UTC (rev 9077) @@ -1,311 +1,250 @@ <?xml version='1.0' encoding='UTF-8'?> - -<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN" "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" [ +<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN" "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" [ <!ENTITY % BOOK_ENTITIES SYSTEM "../../Reference_Guide.ent"> %BOOK_ENTITIES; ]> - <chapter id="sect-Reference_Guide-SSO_Single_Sign_On"> - <title>Single Sign-On</title> - - <section id="sect-SSO_Single_Sign_On_-Overview"> - <title>Overview and Configuration Assumptions</title> - - <para> +<chapter id="sect-Reference_Guide-SSO_Single_Sign_On"> + <title>Single Sign-On</title> + <section id="sect-SSO_Single_Sign_On_-Overview"> + <title>Overview and Configuration Assumptions</title> + <para> JBoss Portal Platform provides an implementation of single sign-on (<literal>SSO</literal>) as an integration and aggregation platform. </para> - - <para> + <para> When logging into the portal, users can access many systems through portlets using a single identity. In many cases, however, the portal infrastructure must be integrated with other SSO enabled systems. </para> - - <para> + <para> There are many different Identity Management solutions available. In most cases each SSO framework provides a unique way to plug into a Java EE application. </para> - - <para> + <para> This section will cover the implementation of four different SSO plug-ins with JBoss Portal Platform: </para> - - <itemizedlist> - <listitem> - <para> + <itemizedlist> + <listitem> + <para> <xref linkend="sect-SSO_Single_Sign_On_-Central_Authentication_Service"/> </para> - </listitem> - - <listitem> - <para> + </listitem> + <listitem> + <para> <xref linkend="sect-Reference_Guide-SSO_Single_Sign_On_-Java_Open_Single_Sign_On_Project"/> </para> - </listitem> - - <listitem> - <para> + </listitem> + <listitem> + <para> <xref linkend="sect-Reference_Guide-SSO_Single_Sign_On_-OpenAM"/> </para> - </listitem> - - <listitem> - <para> + </listitem> + <listitem> + <para> <xref linkend="sect-Reference_Guide-SSO_Single_Sign_On_-SPNEGO_Simple_and_Protected_GSSAPI_Negotiation_Mechanism"/> </para> - </listitem> - </itemizedlist> - - <note> - <title>Prerequisites</title> - - <para> + </listitem> + </itemizedlist> + <note> + <title>Prerequisites</title> + <para> In this tutorial, the SSO server is being installed in a Tomcat environment. Tomcat can be obtained from <ulink url="http://tomcat.apache.org" type="http"> http://tomcat.apache.org </ulink> . </para> - </note> - - <para> + </note> + <para> All the packages required for SSO setup can be found in the <filename><filename>JPP_DIST</filename>/gatein-sso</filename> directory of the JBoss Portal Platform binary package. </para> - - <warning> - <para> + <warning> + <para> Users are advised to not run any portal extensions that could override the data when manipulating the <filename>gatein.ear</filename> file directly. </para>  - </warning> - </section> - - <section id="sect-SSO_Single_Sign_On_-Central_Authentication_Service"> - <title><remark>BZ#856430</remark>Central Authentication Service (CAS)</title> - - <para> + </para> --> </warning> + </section> + <section id="sect-SSO_Single_Sign_On_-Central_Authentication_Service"> + <title><remark>BZ#856430</remark>Central Authentication Service (CAS)</title> + <para> The CAS single sign-on (SSO) plug-in enables seamless integration between the platform and the CAS SSO framework. General information about CAS can be found on the <ulink url="http://www.jasig.org/cas">Jasig website</ulink>. </para> - - <section id="sect-CAS-Authentication_Process"> - <title>Authentication Process</title> - - <para> + <section id="sect-CAS-Authentication_Process"> + <title>Authentication Process</title> + <para> The authentication process with CAS integration occurs in the following order: </para> - - <orderedlist> - <listitem> - <para> + <orderedlist> + <listitem> + <para> A user visits the main portal page, and wishes to authenticate. The user clicks <emphasis role="italics">Sign in</emphasis>. </para> - </listitem> - - <listitem> - <para> + </listitem> + <listitem> + <para> Normally this action would present the portal login dialog, however with SSO integration enabled, the action redirects the user to a marker URL such as <ulink url="http://localhost:8080/portal/sso"/>. </para> - - <para> + <para> The portal handles this user action by calling the interceptor (Servlet filter) <emphasis role="strong">LoginRedirectFilter</emphasis>, which redirects the user seamlessly away from the <emphasis role="italics">/portal/sso</emphasis> URL to the CAS server page. </para> - </listitem> - - <listitem> - <para> + </listitem> + <listitem> + <para> The interceptor redirects the user to the CAS login page <ulink url="http://localhost:8888/cas/login"/> . The user enters the correct authentication information, and submits the form. </para> - - <para> + <para> The CAS server retrieves the information from the identity store. The store could be an external database, a LDAP server, or from information obtained through an authentication plug-in such as the one shipped with JBoss Portal Platform. Refer to <xref linkend="sect-CAS_Authentication_Plug-in"/> for specific details about this technology. </para> - </listitem> - - <listitem> - <para> + </listitem> + <listitem> + <para> Once CAS determines the user has the correct access privileges to access the portal server, CAS redirects the user back to the portal through another marker URL such as <ulink url="http://localhost:8080/portal/initiatelogin"/> . </para> - - <para> + <para> The <emphasis role="strong">InitiateLoginFilter</emphasis> interceptor acts on the user redirection to <emphasis role="italics">/portal/initiatelogin</emphasis> by obtaining a CAS ticket attached in the HTTP request inside the <emphasis role="italics">ticket</emphasis> parameter. The interceptor then delegates validation of this ticket to a configured <emphasis role="strong">CASAgent</emphasis> component. </para> - </listitem> - - <listitem> - <para> + </listitem> + <listitem> + <para> The <emphasis>CASAgent</emphasis> validates the ticket by sending a validation request to the CAS server through a configured back channel. The CAS server validates the request, and ensures it contains the user name of the authenticated user in step 3. </para> - </listitem> - - <listitem> - <para> + </listitem> + <listitem> + <para> After SSO validation, <emphasis role="italics">InitiateLoginFilter</emphasis> redirects the user to the portal login URL <ulink url="http://localhost:8080/portal/login"/> , which initiates JAAS authentication. </para> - - <para> + <para> The <emphasis role="strong">SSOLoginModule</emphasis> detects whether the user has been successfully validated by <emphasis role="italics">CASAgent</emphasis>. If this is the case, the login module obtains data about user (groups, memberships) from <emphasis role="italics">OrganizationService</emphasis> and encapsulates the details into an <emphasis role="strong">Identity</emphasis> object. </para> - </listitem> - - <listitem> - <para> + </listitem> + <listitem> + <para> The <emphasis role="strong">JBossAS7LoginModule</emphasis> completes the authentication request by establishing the JAAS <emphasis role="italics">Subject</emphasis>, and saves the <emphasis role="italics">Identity</emphasis> object to the <emphasis role="italics">IdentityRegistry</emphasis>. For more information about login modules, refer to <xref linkend="sect-Authentication_Authorization_Intro-Login_Modules"/>. </para> - </listitem> - - <listitem> - <para> + </listitem> + <listitem> + <para> After successful JAAS authentication, the user is redirected to the portal in an authenticated state. </para> - </listitem> - </orderedlist> - - <para> + </listitem> + </orderedlist> + <para> For more information about the available Login Modules shipped with the product, refer to the JBoss Enterprise Application Platform <citetitle>Security Guide</citetitle>. </para> - </section> - - <section id="sect-CAS-Logout_Workflow"> - <title>Logout Process</title> - - <para> + </section> + <section id="sect-CAS-Logout_Workflow"> + <title>Logout Process</title> + <para> The logout process with CAS integration occurs in the following order: </para> - - <orderedlist> - <listitem> - <para> + <orderedlist> + <listitem> + <para> The authenticated user clicks the <emphasis role="italics">Sign out</emphasis> link. </para> - </listitem> - - <listitem> - <para> + </listitem> + <listitem> + <para> The <emphasis role="strong">CASLogoutFilter</emphasis> interceptor recognizes the logout request, and redirects the user to the CAS logout page <ulink url="http://localhost:8888/cas/logout"/> . </para> - </listitem> - - <listitem> - <para> + </listitem> + <listitem> + <para> The CAS server logs out the user, and invalidate the CAS cookie <emphasis role="italics">CASTGC</emphasis> . </para> - </listitem> - - <listitem> - <para> + </listitem> + <listitem> + <para> CAS redirects the user back to the portal using the logout redirection configured in <xref linkend="sect-CAS_Logout_Redirection"/> . </para> - - <para> + <para> If the <emphasis role="italics">CASLogoutFilter</emphasis> is enabled, the user is logged out from both the portal and CAS server. </para> - </listitem> - - <listitem> - <para> + </listitem> + <listitem> + <para> The logout redirection request completes the logout process on the CAS server's side, and the user is redirected to the portal's anonymous page. </para> - </listitem> - </orderedlist> - </section> - - <section id="sect-CAS-Configuration_Overview"> - <title>CAS Configuration Overview</title> - - <para> + </listitem> + </orderedlist> + </section> + <section id="sect-CAS-Configuration_Overview"> + <title>CAS Configuration Overview</title> + <para> For scope purposes, the setup instructions assume the following configuration outcomes: </para> - - <itemizedlist> - <listitem> - <para> + <itemizedlist> + <listitem> + <para> The CAS 3.5 is downloaded, and required changes are made to authentication plug-in, logout redirection, and CASTGC cookie configuration. </para> - </listitem> - - <listitem> - <para> + </listitem> + <listitem> + <para> Once configured, Apache Maven is used to create the custom CAS web archive, suitable for deployment. </para> - </listitem> - - <listitem> - <para> + </listitem> + <listitem> + <para> The WAR is deployed to the Apache Tomcat server, which acts as the host for the CAS. </para> - </listitem> - - <listitem> - <para> + </listitem> + <listitem> + <para> Apache Tomcat is configured to listen on <emphasis role="italics">localhost:8888</emphasis>. </para> - </listitem> - - <listitem> - <para> + </listitem> + <listitem> + <para> JBoss Portal Platform is configured to listen on <emphasis role="italics">localhost:8080</emphasis>. </para> - </listitem> - </itemizedlist> - - <section id="sect-CAS-Download_CAS"> - <title><remark>BZ#856430 </remark>Download CAS</title> - - <para> + </listitem> + </itemizedlist> + <section id="sect-CAS-Download_CAS"> + <title><remark>BZ#856430 </remark>Download CAS</title> + <para> CAS can be downloaded from <ulink url="http://www.jasig.org/cas/download"/> . The supported version is <emphasis role="italics">CAS 3.5</emphasis> . More recent CAS versions may also work, however have not been officially tested as part of this specific configuration exercise. </para> - <remark>Docs Note - jmorgan - Marek, I originally incorrectly specified that an admin should extract the CAS source binary into the Tomcat server. It's my fault, because I didn't realise that you need to configure CAS first, *then* build the WAR, and finally deploy to Tomcat. The following sentence makes this much clearer now.</remark> - <para> + <remark>Docs Note - jmorgan - Marek, I originally incorrectly specified that an admin should extract the CAS source binary into the Tomcat server. It's my fault, because I didn't realise that you need to configure CAS first, *then* build the WAR, and finally deploy to Tomcat. The following sentence makes this much clearer now.</remark> + <para> Extract the downloaded file into a suitable working directory. This location will be referred to as <code>CAS_DIR</code> in subsequent configuration instructions. </para> - </section> - </section> - - <section id="sect-CAS-Modifying_CAS_Server"> - <title>Modifying the CAS server</title> - - <para> + </section> + </section> + <section id="sect-CAS-Modifying_CAS_Server"> + <title>Modifying the CAS server</title> + <para> To configure the CAS server correctly, the most effective way is to make the necessary changes directly in the CAS code base. Follow the instructions in the sections below to make the required changes to the CAS code base, before using Maven to build the CAS web archive. </para> - - <section id="sect-CAS_Authentication_Plug-in"> - <title>Authentication Plug-in</title> - - <para> + <section id="sect-CAS_Authentication_Plug-in"> + <title>Authentication Plug-in</title> + <para> While it is possible (and perfectly acceptable) for an administrator to configure CAS to retrieve user credentials from an external database, or from a LDAP server, it is also possible to use JBoss technology. </para> - - <para> + <para> CAS can be configured to make secure authentication callbacks to a RESTful service installed on the remote portal instance using the supplied CAS <literal>AuthenticationPlugin</literal>. </para> - - <para> + <para> Implementing the <literal>AuthenticationPlugin</literal> on the CAS server has the advantage of leveraging a single identity storage for portal user, group and role data. If a new user is added using the portal user management interface, the user information is instantly accessible to the CAS server through the technology implemented by the <literal>AuthenticationPlugin</literal>. </para> - - <para> + <para> The plug-in verifies user credentials by connecting to an existing portal instance using REST over the HTTP protocol. The portal serves a REST authentication callback request, and verifies the user identity against the portal's own identity storage provided by the PicketLink IDM <emphasis role="italics">OrganizationService</emphasis>. The <literal>AuthenticationPlugin</literal> receives the portal's response to the CAS server, and continues with the authentication process based on user data in the response. </para> - - <para> + <para> For the plug-in to function correctly, it must be properly configured on the CAS server to connect to this service. Set up the server to authenticate against the portal using the REST call-back. </para> - - <procedure> - <title>Configuring the Authentication plug-in</title> - - <step> - <para> + <procedure> + <title>Configuring the Authentication plug-in</title> + <step> + <para> Open <code>CAS_DIR/cas-server-webapp/src/main/webapp/WEB-INF/deployerConfigContext.xml</code>. </para> - </step> - - <step> - <para> + </step> + <step> + <para> Replace the default configuration, which declares the Jasig <classname>SimpleTestUsernamePasswordAuthenticationHandler</classname> Authentication Handler with the following supported Authentication Handler. </para> - - <note> - <para> + <note> + <para> This configuration is available in the <code><replaceable>JPP_DIST</replaceable>gatein-sso/cas/plugin/WEB-INF/deployerConfigContext.xml</code> file. If you choose to take this configuration file, ensure the default host, port and context parameters are adjusted to match the values corresponding to the remote portal instance. </para> - </note> -<programlisting> + </note> + <programlisting>  <bean class="org.gatein.sso.cas.plugin.AuthenticationPlugin"> @@ -316,189 +255,152 @@ <property name="httpMethod"><value>POST</value></property> </bean> </programlisting> - </step> - - <step> - <para> + </step> + <step> + <para> Copy all jars from <code><replaceable>JPP_DIST</replaceable>gatein-sso/cas/plugin/WEB-INF/lib/</code> to the <code>CAS_DIR/cas-server-webapp/src/main/webapp/WEB-INF/lib</code> directory. </para> - </step> - </procedure> - </section> - - <section id="sect-CAS_Logout_Redirection"> - <title>Logout redirection setup</title> - - <para> + </step> + </procedure> + </section> + <section id="sect-CAS_Logout_Redirection"> + <title>Logout redirection setup</title> + <para> The CAS server displays the CAS logout page with a link to return to the portal by default. To make the CAS server redirect to the portal page after a logout, modify <code>CAS_DIR/cas-server-webapp/src/main/webapp/</code> <code>WEB-INF/cas-servlet.xml</code> to include the <code>followServiceRedirects="true"</code> parameter: </para> -<programlisting language=""><bean id="logoutController" class="org.jasig.cas.web.LogoutController" + <programlisting language=""><bean id="logoutController" class="org.jasig.cas.web.LogoutController" p:centralAuthenticationService-ref="centralAuthenticationService" p:logoutView="casLogoutView" p:warnCookieGenerator-ref="warnCookieGenerator" p:ticketGrantingTicketCookieGenerator-ref="ticketGrantingTicketCookieGenerator" p:followServiceRedirects="true"/> </programlisting> - </section> - - <section id="sect-CAS_SSO_Cookie_Configuration"> - <title>CAS SSO cookie configuration (CASTGC)</title> - - <para> + </section> + <section id="sect-CAS_SSO_Cookie_Configuration"> + <title>CAS SSO cookie configuration (CASTGC)</title> + <para> Jasic CAS uses a cookie named - <firstterm> - CAS Ticket Granting Cookie - </firstterm> + <firstterm> CAS Ticket Granting Cookie </firstterm> (CASTGC) to control the authentication state within the browser session. The cookie contains a Ticket Granting Ticket (TGT), which preserves SSO authentication where more than one site is controlled by the same SSO profile. </para> - - <example id="exam-CASTGC_Authentication"> - <title>Basic CASTGC Portal Authentication Scenario</title> - - <para> + <example id="exam-CASTGC_Authentication"> + <title>Basic CASTGC Portal Authentication Scenario</title> + <para> Two portal servers are provisioned that use a single CAS server to manage authentication. The portals are named <literal>accounts</literal> and <literal>services</literal>. </para> - - <para> + <para> When a user initially accesses the <literal>accounts</literal> portal, they provide their SSO credentials, and CAS authenticates them as a registered user. The user then switches to the <literal>services</literal> portal, and is authenticated when she clicks the Sign in link. </para> - - <para> + <para> This behavior is correct given this example because the browser instance stores the browser authentication state using the CASTCG cookie. The CASTCG cookie in this instance creates new ticket for the <literal>services</literal> portal automatically based on the authentication state present for the accounts portal. </para> - </example> - - <para> + </example> + <para> The behavior described in <xref linkend="exam-CASTGC_Authentication"/>exists through a secured connection only (https connection). To benefit from authentication across two or more portals, one of the options below must be implemented. Choose the correct option based on the deployment environment: </para> - - <variablelist> - <varlistentry> - <term>Testing</term> - - <listitem> - <para> + <variablelist> + <varlistentry> + <term>Testing</term> + <listitem> + <para> Alter the CASTGC cookie to be non-secure. </para> - - <para> + <para> The cookie can be accessed through http (insecure) connections. </para> - - <para> + <para> To configure this test behavior, open <code>CAS_DIR/cas-server-webapp/src/main/webapp/WEB-INF/spring-configuration/ticketGrantingTicketCookieGenerator.xml</code> and switch the attribute <code>cookieSecure</code> to false. </para> -<programlisting><bean id="ticketGrantingTicketCookieGenerator" + <programlisting><bean id="ticketGrantingTicketCookieGenerator" p:cookieSecure="false" p:cookieMaxAge="-1" p:cookieName="CASTGC" p:cookiePath="/cas" /></programlisting> - </listitem> - </varlistentry> - - <varlistentry> - <term>Production</term> - - <listitem> - <para> + </listitem> + </varlistentry> + <varlistentry> + <term>Production</term> + <listitem> + <para> Correctly implement the https protocol for all production servers that rely on CAS. This configuration is the recommended method for any production server, and ensures greater security for CAS connections. Refer to the Jasig documentation about securing CAS <ulink url="https://wiki.jasig.org/display/CASUM/Securing+Your+New+CAS+Server "/> for information and resources. </para> - </listitem> - </varlistentry> - </variablelist> - </section> - </section> - - <section id="sect-CAS-Install_Tomcat_Server"> - <title>Install Apache Tomcat Server</title> - - <para> + </listitem> + </varlistentry> + </variablelist> + </section> + </section> + <section id="sect-CAS-Install_Tomcat_Server"> + <title>Install Apache Tomcat Server</title> + <para> Install and configure Apache Tomcat 7, which provides the host server for the CAS server. </para> - - <para> + <para> File name abbreviations in this section are described in <xref linkend="sect-File_Name_Conventions"/> </para> - - <procedure> - <title>Configuring Apache Tomcat for CAS</title> - - <step> - <para> + <procedure> + <title>Configuring Apache Tomcat for CAS</title> + <step> + <para> Visit <ulink url="http://tomcat.apache.org/download-70.cgi"/> and download the Tomcat 7 binary distribution. </para> - </step> - - <step> - <para> + </step> + <step> + <para> Extract and install the binary on the server that is required to host CAS. This directory is now referred to as <replaceable>TOMCAT_HOME</replaceable>. </para> - </step> - - <step> - <para> + </step> + <step> + <para> Edit <filename>TOMCAT_HOME/conf/server.xml</filename> and change port 8080 to 8888 to avoid a conflict with the default JBoss Portal Platform listen port. </para> - <remark>BZ#856430 - jmorgan - Added the new ports from the Confluence SSO Server Setup section</remark> - <important> - <para> + <remark>BZ#856430 - jmorgan - Added the new ports from the Confluence SSO Server Setup section</remark> + <important> + <para> If the Apache Tomcat server is installed on the same machine as JBoss Portal Platform, ensure other listen ports common to both servers are changed to prevent configuration issues. For example, change the Tomcat admin port from 8005 to 8805, and the Tomcat AJP port from 8009 to 8809. </para> - </important> - </step> - - <step> - <para> + </important> + </step> + <step> + <para> Ensure all Apache Tomcat ports are open in the server firewall, and the service is enabled and running so the platform can communicate with Apache Tomcat on the same server. </para> - </step> - </procedure> - </section> - - <section id="sect-CAS-Modifying_the_Portal"> - <title>Modifying the Portal</title> - - <para> + </step> + </procedure> + </section> + <section id="sect-CAS-Modifying_the_Portal"> + <title>Modifying the Portal</title> + <para> Before building and deploying the Jasig CAS sever, configuration needs to be implemented on the JBoss Portal Platform server to prepare the portal for CAS integration. </para> - - <section id="sect-CAS_Portal_SSO_Primary_Configuration_File"> - <title>Portal SSO Primary Configuration File</title> - - <para> + <section id="sect-CAS_Portal_SSO_Primary_Configuration_File"> + <title>Portal SSO Primary Configuration File</title> + <para> The main portal configuration file for SSO integration is <code>JPP_SERVER/gatein/gatein.ear/portal.war/WEB-INF/conf/sso/security-sso-configuration.xml</code> . All required SSO components such as agents and SSO interceptors (servlet filters in v5.x of the product) are configured in this file. </para> - - <para> + <para> In most cases, it will never be necessary to edit <filename>security-sso-configuration.xml</filename> directly when using JBoss Portal Platform. The portal architecture allows users to override the base configuration described in this file using name/value pairs configured in one place: <filename>JPP_SERVER/standalone/configuration/gatein/configuration.properties</filename> </para> - - <para> + <para> The exception to this rule is where configuration present in <filename>security-sso-configuration.xml</filename> is fundamentally unsuitable for the production environment the server will be deployed to, or when additional underlying functionality is required (for example, another custom interceptor). </para> - </section> - - <section id="sect-CAS_Configuring_the_Platform"> - <title>Portal configuration.properties for CAS SSO</title> - - <para> + </section> + <section id="sect-CAS_Configuring_the_Platform"> + <title>Portal configuration.properties for CAS SSO</title> + <para> To prepare the portal platform for CAS authentication, SSO filters and login modules need to be specified in global configuration files. The location of the CAS server, as configured in a locally-running Apache Tomcat server, also needs to be specified. </para> - - <procedure> - <title>Configuring SSO configuration.properties for CAS</title> - - <step> - <para> + <procedure> + <title>Configuring SSO configuration.properties for CAS</title> + <step> + <para> Open <filename>JPP_SERVER/standalone/configuration/gatein/configuration.properties</filename> and locate the SSO sections in the file. </para> - </step> - - <step> - <para> + </step> + <step> + <para> Make the following changes to the file to declare the correct login module, server and portal URLs, and the logout filter. </para> -<programlisting> + <programlisting> # SSO gatein.sso.enabled=true gatein.sso.callback.enabled=${gatein.sso.enabled} @@ -510,342 +412,281 @@ gatein.sso.filter.logout.url=${gatein.sso.server.url}/logout gatein.sso.filter.login.sso.url=${gatein.sso.server.url}/login?service=${gatein.sso.portal.url}/@@[portal.container.name]@(a)/initiatessologin </programlisting> - </step> - </procedure> - - <variablelist> - <varlistentry> - <term>gatein.sso.enabled</term> - - <listitem> - <para> + </step> + </procedure> + <variablelist> + <varlistentry> + <term>gatein.sso.enabled</term> + <listitem> + <para> Specifies whether SSO integration is enabled on the portal. With this option set to "true" when a user clicks the <emphasis role="italics">Sign in</emphasis> link, the user is redirected to the <emphasis role="italics">/portal/sso</emphasis> URL rather than a standard Sign in dialog. </para> - </listitem> - </varlistentry> - - <varlistentry> - <term>gatein.sso.callback.enabled</term> - - <listitem> - <para> + </listitem> + </varlistentry> + <varlistentry> + <term>gatein.sso.callback.enabled</term> + <listitem> + <para> Specifies whether the REST callback authentication handler is enabled. </para> - - <para> + <para> The handler is required if the CAS server must use the SSO Authentication plug-in to handle portal authentication. See <xref linkend="sect-CAS_Logout_Redirection"/> for details. The callback handler is enabled by default. Set the parameter to false if the Authentication Plugin on the CAS server side is not required. </para> - </listitem> - </varlistentry> - - <varlistentry> - <term>gatein.sso.login.module.enabled</term> - - <listitem> - <para> + </listitem> + </varlistentry> + <varlistentry> + <term>gatein.sso.login.module.enabled</term> + <listitem> + <para> Specifies whether a pre-defined SSO login module declared in <filename> JPP_SERVER/standalone/configuration/standalone.xml</filename> is used for authentication. When the property is set to "true", 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. </para> - - <para> + <para> This parameter removes the need to manually change any login module configuration in the standalone.xml file, which simplifies platform configuration. </para> - </listitem> - </varlistentry> - - <varlistentry> - <term>gatein.sso.login.module.class</term> - - <listitem> - <para> + </listitem> + </varlistentry> + <varlistentry> + <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 gatein.sso.login.module.enabled is specified. </para> - </listitem> - </varlistentry> - - <varlistentry> - <term>gatein.sso.server.url</term> - - <listitem> - <para> + </listitem> + </varlistentry> + <varlistentry> + <term>gatein.sso.server.url</term> + <listitem> + <para> Specifies the URL from which the CAS server is accessible. </para> - </listitem> - </varlistentry> - - <varlistentry> - <term>gatein.sso.portal.url</term> - - <listitem> - <para> + </listitem> + </varlistentry> + <varlistentry> + <term>gatein.sso.portal.url</term> + <listitem> + <para> Specifies the URL from which the JBoss Portal Platform is accessible. </para> - </listitem> - </varlistentry> - - <varlistentry> - <term>gatein.sso.filter.logout.class</term> - - <listitem> - <para> + </listitem> + </varlistentry> + <varlistentry> + <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 CAS side. </para> - </listitem> - </varlistentry> - - <varlistentry> - <term>gatein.sso.filter.logout.url</term> - - <listitem> - <para> + </listitem> + </varlistentry> + <varlistentry> + <term>gatein.sso.filter.logout.url</term> + <listitem> + <para> Specifies the CAS server logout URL, which is used for redirection by the logout filter </para> - </listitem> - </varlistentry> - - <varlistentry> - <term>gatein.sso.filter.logout.enabled</term> - - <listitem> - <para> + </listitem> + </varlistentry> + <varlistentry> + <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 " false" . This results in both options <code>gatein.sso.filter.logout.class</code> and <code>gatein.sso.filter.logout.url</code> are ignored </para> - - <para> + <para> When a user logs out of the portal, the CAS authentication ticket is still valid for other CAS authenticated sites. </para> - </listitem> - </varlistentry> - - <varlistentry> - <term>gatein.sso.filter.login.sso.url</term> - - <listitem> - <para> + </listitem> + </varlistentry> + <varlistentry> + <term>gatein.sso.filter.login.sso.url</term> + <listitem> + <para> Specifies the CAS server login URL, which is used by LoginRedirectFilter for redirection to the CAS server login page. </para> - <remark>Docs Note - jmorgan - added this note about the p.c.n variable, and that it *shouldn't* be substituted for a hard-coded variable name.</remark> - <note> - <para> + <remark>Docs Note - jmorgan - added this note about the p.c.n variable, and that it *shouldn't* be substituted for a hard-coded variable name.</remark> + <note> + <para> The string <literal>@@portal.container.name(a)@ </literal>is dynamically replaced when the URL is interpreted by the platform's SSO Component. It is recommended that this string is used over hard-coding the name of the portal for future maintenance and ease of configuration changes. </para> - </note> - </listitem> - </varlistentry> - </variablelist> - </section> - </section> - - <section id="sect-Deploying_CAS_on_Tomcat"> - <title><remark>BZ#856430 </remark>Build and Deploy the CAS</title> - <remark>BZ#856430 - jmorgan - This is a new sections which captures the final step an admin needs to do to bring all the cofiguration together.</remark> - <para> + </note> + </listitem> + </varlistentry> + </variablelist> + </section> + </section> + <section id="sect-Deploying_CAS_on_Tomcat"> + <title><remark>BZ#856430 </remark>Build and Deploy the CAS</title> + <remark>BZ#856430 - jmorgan - This is a new sections which captures the final step an admin needs to do to bring all the cofiguration together.</remark> + <para> Jasig CAS uses Apache Maven to build the <filename>cas.war</filename> file. Follow the instructions to produce this file, and deploy it to the Apache Tomcat server. </para> - - <procedure> - <title>Building CAS, and Deploying to Tomcat</title> - - <step> - <para> + <procedure> + <title>Building CAS, and Deploying to Tomcat</title> + <step> + <para> Install Maven by following the recommendations and links in the <ulink url="https://wiki.jasig.org/display/CASUM/Building+and+Deploying">Building and Deploying section</ulink> of the Jasig CAS user documentation. </para> - </step> - - <step> - <para> + </step> + <step> + <para> In a terminal, navigate to <filename>CAS_DIR/cas-server-webapp/</filename>, and run <command>mvn install</command>. </para> - </step> - - <step> - <para> + </step> + <step> + <para> Copy <filename>CAS_DIR/cas-server-webapp/target/cas.war</filename> to <filename>TOMCAT_HOME/webapps</filename>. </para> - </step> - - <step> - <para> + </step> + <step> + <para> Tomcat should be running by default, if the process has been followed up to this step. Start JBoss Portal Platform, and verify the server is running by opening <ulink url="http://localhost:8080/"/>. </para> - </step> - - <step> - <para> + </step> + <step> + <para> Open <ulink url="http://localhost:8888/cas"/> to verify the CAS server has correctly deployed to Tomcat. If the link does not open the CAS login page, restart Apache Tomcat and try again. </para> - </step> - </procedure> - <remark>BZ#856430 - jmorgan - Added this "wrap up" statement that should describe what customers are able to do after following the procedure.</remark> - <para> + </step> + </procedure> + <remark>BZ#856430 - jmorgan - Added this "wrap up" statement that should describe what customers are able to do after following the procedure.</remark> + <para> The CAS server is now deployed to Tomcat, and the portal will now redirect users to the CAS login page when they click on the Sign In link. </para> - </section> - </section> - - <section id="sect-Reference_Guide-SSO_Single_Sign_On_-Java_Open_Single_Sign_On_Project"> - <title><remark>BZ#856430</remark>Java Open Single Sign-On Project</title> - - <para> + </section> + </section> + <section id="sect-Reference_Guide-SSO_Single_Sign_On_-Java_Open_Single_Sign_On_Project"> + <title><remark>BZ#856430</remark>Java Open Single Sign-On Project</title> + <para> Configuring JOSSO for JBoss Enterprise Application Platform requires an Apache server instance to host JOSSO. JBoss Enterprise Application Platform communicates with the JOSSO Apache instance through the single sign-on plug-in. </para> - - <para> + <para> This single sign-on plug-in enables seamless integration between JBoss Portal Platform and the Java Open Single Sign-On (JOSSO) framework. Details about JOSSO can be found at <ulink url="http://www.josso.org"/> . </para> - - <para> + <para> The procedures in this section detail setting up the JOSSO server to authenticate against the JBoss Portal Platform login module. </para> - - <para> + <para> After completing the procedures in this section, all links redirecting to the user authentication pages will redirect to the JOSSO centralized authentication form. </para> - - <section> - <title>Authentication Process</title> - - <para> + <section> + <title>Authentication Process</title> + <para> The login workflow for JOSSO is quite similar to that used for CAS authentications (specific details can be found in <xref linkend="sect-CAS-Authentication_Process"/>). </para> - - <para> + <para> Briefly; when a user clicks to sign in to a portal they are redirected to the JOSSO login screen, where they supply the appropriate credentials. They are then redirected (with access authorization) back to the Portal. </para> - - <para> + <para> The <systemitem>JOSSOAgent</systemitem> component performs a validation of the authorization ticket with the JOSSO server via a back channel after the <systemitem>InitiateLoginFilter</systemitem> has delegated the <parameter>josso_assertion_id</parameter> request to it. The JOSSO agent and JOSSO server communicate via web services. </para> - - <para> + <para> After a successful validation, the user identity is successfully established and the user is logged into the requested Portal. </para> - - <para> + <para> On logout, <systemitem>JOSSOLogoutFilter</systemitem> performs a logout on both the Portal and the JOSSO server (similar to the process for CAS). </para> - - <para> + <para> While the authentication plugin (which is able to send REST requests to the portal, receive the response, and authenticate the user on the JOSSO side) is supported, this support is only for JOSSO 1.8 (not JOSSO 2.2 as at this release). </para> - - <para> + <para> In this section, we will assume that JBoss Portal Platform will be running on JBoss Enterprise Application Platform 6 using port <emphasis role="italics">localhost:8080</emphasis> and that the JOSSO server will be running on Tomcat, using <emphasis role="italics">localhost:8888</emphasis>. </para> - - <note> - <para> + <note> + <para> There are differences between various JOSSO minor versions (especially betweeen JOSSO versions 1.8.1 and 1.8.2) so instructions will be slightly different between various versions. This will be pointed in text in more details. </para> - </note> - </section> - - <section> - <title>JOSSO 1.8</title> - - <section id="sid-55477376_JOSSO-ObtainingJOSSO"> - <title>Obtaining JOSSO</title> - - <para> + </note> + </section> + <section> + <title>JOSSO 1.8</title> + <section id="sid-55477376_JOSSO-ObtainingJOSSO"> + <title>Obtaining JOSSO</title> + <para> JOSSO can be downloaded from <ulink url="http://sourceforge.net/projects/josso/files/"/>. Use the package that embeds Apache Tomcat. </para> - <remark>Docs Note; JOSSO versions up to 1.8.7 are available from this URL. I assume any after 1.8.2 are unsupported. Should we call this out in the docs?</remark> - <para> + <remark>Docs Note; JOSSO versions up to 1.8.7 are available from this URL. I assume any after 1.8.2 are unsupported. Should we call this out in the docs?</remark> + <para> Once downloaded, extract the package into what will be called <replaceable>JOSSO_HOME</replaceable> in this example. </para> - </section> - - <section id="sid-55477376_JOSSO-JOSSOserver"> - <title>Set up the JOSSO server</title> - - <para> + </section> + <section id="sid-55477376_JOSSO-JOSSOserver"> + <title>Set up the JOSSO server</title> + <para> This section describes how to set up the JOSSO server to authenticate against the JBoss Portal Platform using the REST authentication plugin. In this example, the JOSSO server will be installed on Tomcat. </para> - - <procedure> - <step> - <para> + <procedure> + <step> + <para> <emphasis role="bold">Optional:</emphasis> To use the SSO authentication plugin with JOSSO (not-mandatory but recommended. See <xref linkend="sect-CAS-Authentication_Process"/> for details): </para> - <substeps> - <step><para> + <substeps> + <step> + <para> Copy the files from <filename>SSO_HOME/josso/josso-<replaceable><version></replaceable>/plugin/</filename> into <replaceable>JOSSO_HOME</replaceable> directory, as shown below: </para> - <para> + <para> Keep in mind that <replaceable>SSO_HOME</replaceable> refers to the JOSSO directory within JBoss Portal Platform as mentioned in <xref linkend="sect-Reference_Guide-SSO_Single_Sign_On"/>. </para> - <itemizedlist> - <listitem> - <para> + <itemizedlist> + <listitem> + <para> Copy <filename><replaceable>SSO_HOME</replaceable>/josso/josso-<replaceable><version></replaceable>/plugin/lib/josso-gateway-config.xml</filename> to <filename><replaceable>JOSSO_HOME</replaceable>/lib/josso-gateway-config.xml</filename>. The original file is being replaced. You should consider creating a backup of it before adding the new file. </para> - </listitem> - - <listitem> - <para> + </listitem> + <listitem> + <para> Add <filename><replaceable>SSO_HOME</replaceable>/josso/josso-<replaceable><version></replaceable>/plugin/lib/josso-gateway-config.xml</filename> to <filename><replaceable>JOSSO_HOME</replaceable>/lib/</filename>. This file is not present in the original <replaceable>JOSSO_HOME</replaceable> download. </para> - </listitem> - - <listitem> - <para> + </listitem> + <listitem> + <para> Add <filename>SSO_HOME/josso/josso-<replaceable><version></replaceable>/plugin/webapps/josso/WEB-INF/classes/gatein.properties</filename> to <filename>JOSSO_HOME/webapps/josso/WEB-INF/classes/</filename>. This file is not present in the original <replaceable>JOSSO_HOME</replaceable> download. </para> - - <para> + <para> This file may need to be reconfigured according to your JBoss Portal Platform environment (you need to use the host and port of your JBoss Portal Platform instance as this will be used by the Authentication plugin to send REST requests over HTTP). </para> - </listitem> - </itemizedlist> - </step> - </substeps> - </step> - - <step> - <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). </para> - - <note> - <title>Port Conflicts</title> - - <para> + <note> + <title>Port Conflicts</title> + <para> If JBoss Portal Platform is running on the same machine as Tomcat, other ports need to be changed in addition to <literal>8080</literal> to avoid port conflicts. They can be changed to any free port. For example, you can change the admin port from <literal>8005</literal> to <literal>8805</literal>, and AJP port from <literal>8009</literal> to <literal>8809</literal>. </para> - </note> - </step> - - <step> - <para> + </note> + </step> + <step> + <para> Tomcat should now allow access to <uri>http://localhost:8888/josso/signon/login.do</uri>. However, if you are using the SSO Authentication plugin, the login will not be available as you must set up your JBoss Portal Platform instance to use it. </para> - - <figure> - <title>JOSSO Login Page</title> - <mediaobject> - <imageobject role="html"> - <imagedata align="center" fileref="images/AuthenticationAndIdentity/SSO/josso.png" format="PNG"/> - </imageobject> - </mediaobject> - </figure> - </step> - </procedure> - </section> - - <section id="sid-55477376_JOSSO-SetuptheJOSSOclient"> - <title>Set up the JOSSO client</title> - - <procedure> - <step> - <para> + <figure> + <title>JOSSO Login Page</title> + <mediaobject> + <imageobject role="html"> + <imagedata align="center" fileref="images/AuthenticationAndIdentity/SSO/josso.png" format="PNG"/> + </imageobject> + </mediaobject> + </figure> + </step> + </procedure> + </section> + <section id="sid-55477376_JOSSO-SetuptheJOSSOclient"> + <title>Set up the JOSSO client</title> + <procedure> + <step> + <para> Some of the configuration properties in <filename>JBOSS_HOME/standalone/configuration/gatein/configuration.properties</filename> need to be set on the client server. </para> - - <para> + <para> Locate the <literal>#SSO</literal> section of the file and edit it to match the sample below: </para> - - <informalexample> -<programlisting> + <informalexample> + <programlisting> #SSO gatein.sso.enabled=true gatein.sso.callback.enabled=${gatein.sso.enabled} @@ -861,284 +702,230 @@ gatein.sso.filter.logout.url=${gatein.sso.josso.base.url}/logout.do gatein.sso.filter.login.sso.url=${gatein.sso.server.url}?josso_back_to=${gatein.sso.portal.url}/@@portal.container.name@(a)/initiatessologin </programlisting> - </informalexample> - - <para> + </informalexample> + <para> Most of the properties are described in <xref linkend="sect-CAS_Configuring_the_Platform"/>. </para> - - <para> + <para> Some of the properites differ for JOSSO: </para> - - <itemizedlist> - <listitem> - <para> + <itemizedlist> + <listitem> + <para> The Logout filter is <code>org.gatein.sso.agent.filter.JOSSOLogoutFilter</code>. </para> - </listitem> - - <listitem> - <para> + </listitem> + <listitem> + <para> <code>gatein.sso.josso.host</code> points to the location of the JOSSO server. </para> - </listitem> - - <listitem> - <para> + </listitem> + <listitem> + <para> <code>gatein.sso.portal.url</code> must be changed if you intend to access JBoss Portal Platform on any URL other than <emphasis role="italics">localhost:8080</emphasis>. </para> - </listitem> - - <listitem> - <para> + </listitem> + <listitem> + <para> The <code>gatein.sso.josso.agent.config.file</code> property points to the location of the Agent configuration file, which is relative to classpath. Therefore the agent file location is actually located at <filename>JBOSS_HOME/gatein/gatein.ear/portal.war/WEB-INF/classes/sso/josso/1.8/josso-agent-config.xml</filename>. </para> - - <para> + <para> In the majority of cases, nothing in this file will need to be configured beyond the defaults. </para> - </listitem> - </itemizedlist> - </step> - - <step> - <para> + </listitem> + </itemizedlist> + </step> + <step> + <para> JOSSO has some specific dependencies, which differ between various versions. The original <code>org.gatein.sso</code> SSO module must be replaced with one appropriate for your version of JOSSO. The alternate modules are available in the JOSSO download. </para> - - <substeps> - <step> - <para> + <substeps> + <step> + <para> Delete the <filename>JBOSS_HOME/modules/org/gatein/sso</filename> directory. </para> - </step> - - <step> - <para> + </step> + <step> + <para> Copy the <filename>SSO_HOME/josso/gatein-josso-<replaceable><version></replaceable>/modules/org/gatein/sso</filename> directory into <filename>JBOSS_HOME/modules/org/gatein/</filename>. </para> - </step> - </substeps> - </step> - </procedure> - - <para> + </step> + </substeps> + </step> + </procedure> + <para> From now on, all links redirecting to the user authentication pages will redirect to the JOSSO centralized authentication form. If you set Authentication plugin for JOSSO, you can login with JBoss Portal Platform credentials (like john/gtn) on JOSSO side. </para> - </section> - </section> - - <section> - <title>JOSSO 2.2</title> - - <para> + </section> + </section> + <section> + <title>JOSSO 2.2</title> + <para> JOSSO 2.2 takes a different approach to SSO than JOSSO 1.8. It is designed to allow users to create their own SSO environment by modelling it in a flash web application called <emphasis role="strong">atricore-console</emphasis>. </para> - - <para> + <para> Unfortunately this make it more difficult to use the SSO Authentication plugin as it is not easily possible to configure an existing JOSSO 2.2 environment via Spring XML files. Using the <systemitem>AuthenticationPlugin</systemitem> with JOSSO 2.2 is not supported. </para> - - <section id="sid-55477376_JOSSO-JOSSO2.2serversetup"> - <title>JOSSO 2.2 server setup</title> - - <para> + <section id="sid-55477376_JOSSO-JOSSO2.2serversetup"> + <title>JOSSO 2.2 server setup</title> + <para> You can downloaded JOSSO 2.2.0 from <ulink url="http://www.josso.org">JOSSO site</ulink> and follow the instructions from the JOSSO 2 quickstart in <ulink url="http://www.josso.org/confluence/display/JOSSO1/JOSSO2+Quick+start"/> . </para> - - <para> + <para> After unzipping the download and running the JOSSO, you can access the <application>atricore</application> console at <uri>http://<replaceable>server.local.network</replaceable>:8081/atricore-console</uri> (<replaceable>server.local.network</replaceable> is the virtual host defined in <filename>/etc/hosts</filename>). </para> - - <procedure> - <step> - <para> + <procedure> + <step> + <para> Login to the portal with the username/password combination; <literal>admin/admin</literal>. </para> - </step> - - <step> - <para> + </step> + <step> + <para> Create a new, empty <emphasis role="italics">Identity appliance</emphasis> with the following details: </para> - <table> - <title></title> - <tgroup cols="2"> - <thead> - <row> - <entry> - Setting - </entry> - <entry> - Value - </entry> - </row> - </thead> - <tbody> - <row> - <entry> - Name - </entry> - <entry> - <parameter>MYFIRSTIA</parameter> - </entry> - </row> - <row> - <entry> - Realm name - </entry> - <entry> - <parameter>com.mycompany.myrealm</parameter> - </entry> - </row> - <row> - <entry> - Appliance location - </entry> - <entry> - <uri>http://server.local.network:8081</uri> - </entry> - </row> - </tbody> - </tgroup> - </table> - </step> - - <step> - <para> + <table> + <title/> + <tgroup cols="2"> + <thead> + <row> + <entry> Setting </entry> + <entry> Value </entry> + </row> + </thead> + <tbody> + <row> + <entry> Name </entry> + <entry> + <parameter>MYFIRSTIA</parameter> + </entry> + </row> + <row> + <entry> Realm name </entry> + <entry> + <parameter>com.mycompany.myrealm</parameter> + </entry> + </row> + <row> + <entry> Appliance location </entry> + <entry> + <uri>http://server.local.network:8081</uri> + </entry> + </row> + </tbody> + </tgroup> + </table> + </step> + <step> + <para> Create a new Identity provider named <emphasis role="italics">AcmeIDP</emphasis> (use the default settings). - </para> - </step> - - <step> - <para> + </para> + </step> + <step> + <para> Create an Identity vault <emphasis role="italics">IDPUsers</emphasis> and connect it with <emphasis role="italics">AcmeIDP</emphasis> via <emphasis role="italics">Identity lookup</emphasis> connection. </para> - </step> - - <step> - <para> + </step> + <step> + <para> Create a Service provider called <emphasis role="italics">SP1</emphasis> but let the hosts to be on <emphasis role="italics">server.local.network:8081</emphasis>. </para> - </step> - - <step> - <para> + </step> + <step> + <para> Create an Identity vault <emphasis role="italics">SP1Users</emphasis> and wire it with SP1 via <emphasis role="italics">Identity lookup</emphasis> connection. </para> - </step> - - <step> - <para> + </step> + <step> + <para> Create empty temporary directory <filename>/tmp/tomcat7</filename> and then in the <application>atricore</application> console create new Execution environment of type <emphasis role="italics">Tomcat</emphasis> with the following parameters: </para> - <table> - <title></title> - <tgroup cols="2"> - <thead> - <row> - <entry> - Setting - </entry> - <entry> - Value - </entry> - </row> - </thead> - <tbody> - <row> - <entry> - Name - </entry> - <entry> - <parameter>SP1EE</parameter> - </entry> - </row> - <row> - <entry> - Version - </entry> - <entry> - <parameter>7.0.x</parameter> - </entry> - </row> - <row> - <entry> - Target host - </entry> - <entry> - <parameter>Local</parameter> - </entry> - </row> - <row> - <entry> - Install home - </entry> - <entry> - <parameter>/tmp/tomcat7</parameter> (the <code>/tmp/tomcat7</code> directory must exist, but it can be empty). - </entry> - </row> - </tbody> - </tgroup> - </table> - </step> - - <step> - <para> + <table> + <title/> + <tgroup cols="2"> + <thead> + <row> + <entry> Setting </entry> + <entry> Value </entry> + </row> + </thead> + <tbody> + <row> + <entry> Name </entry> + <entry> + <parameter>SP1EE</parameter> + </entry> + </row> + <row> + <entry> Version </entry> + <entry> + <parameter>7.0.x</parameter> + </entry> + </row> + <row> + <entry> Target host </entry> + <entry> + <parameter>Local</parameter> + </entry> + </row> + <row> + <entry> Install home </entry> + <entry><parameter>/tmp/tomcat7</parameter> (the <code>/tmp/tomcat7</code> directory must exist, but it can be empty). </entry> + </row> + </tbody> + </tgroup> + </table> + </step> + <step> + <para> Wire <emphasis role="italics">SP1</emphasis> and <emphasis role="italics">SP1EE</emphasis> via an <emphasis role="italics">Activation</emphasis> connection. </para> - - <para> - <remark>Docs note: I don't even know what this sentence is trying to say.</remark> Left default values of parameters instead of parameter <emphasis role="italics">Partner application location</emphasis> needs to be configured to <ulink url="http://localhost:8080/portal"/> + <para> + <remark>Docs note: I don't even know what this sentence is trying to say.</remark> Left default values of parameters instead of parameter <emphasis role="italics">Partner application location</emphasis> needs to be configured to <ulink url="http://localhost:8080/portal"/> </para> - </step> - - <step> - <para> + </step> + <step> + <para> Wire <emphasis role="italics">SP1</emphasis> and <emphasis role="italics">AcmeIDP</emphasis> via <emphasis role="italics">Federated connection</emphasis>. </para> - </step> - - <step> - <para> + </step> + <step> + <para> Click <guilabel>Save</guilabel> and save this model. </para> - </step> - - <step> - <para> - Go to the <guilabel>Identity appliance lifecycle management</guilabel> tab and go through lifecycle of Identity appliance (<menuchoice><guimenuitem>Saved</guimenuitem><guimenuitem>Staged</guimenuitem><guimenuitem>Deployed</guimenuitem><guimenuitem>Started</guimenuitem></menuchoice>) as suggested in the quickstart. + </step> + <step> + <para> + Go to the <guilabel>Identity appliance lifecycle management</guilabel> tab and go through lifecycle of Identity appliance (<menuchoice> + <guimenuitem>Saved</guimenuitem> + <guimenuitem>Staged</guimenuitem> + <guimenuitem>Deployed</guimenuitem> + <guimenuitem>Started</guimenuitem> + </menuchoice>) as suggested in the quickstart. </para> - </step> - - <step> - <para> + </step> + <step> + <para> Go to the <guilabel>Account & Entitlement management</guilabel> tab and create users. Users must be created this way because REST callbacks to the Portal are not supported in this release. </para> - - <para> + <para> This example will create the following user/password accounts: <literal>john</literal>/<literal>password</literal>, <literal>root</literal>/<literal>password</literal> and <literal>demo</literal>/<literal>password</literal>. </para> - </step> - </procedure> - </section> - - <section id="sid-55477376_JOSSO-JOSSOclientsetup"> - <title>JOSSO client setup</title> - - <para> + </step> + </procedure> + </section> + <section id="sid-55477376_JOSSO-JOSSOclientsetup"> + <title>JOSSO client setup</title> + <para> This section assumes that all relevant configurations were made as described in <xref linkend="sid-55477376_JOSSO-JOSSO2.2serversetup"/>. </para> - - <procedure> - <step> - <para> + <procedure> + <step> + <para> Assuming again that you have JBoss Portal Platform running on JBoss Enterprise Platform 6, you need to change some of the properties in the SSO sections of <filename>JBOSS_HOME/standalone/configuration/gatein/configuration.properties</filename> to match those below: </para> - - <informalexample> -<programlisting> + <informalexample> + <programlisting> # SSO gatein.sso.enabled=true gatein.sso.callback.enabled=${gatein.sso.enabled} @@ -1158,192 +945,177 @@ gatein.sso.josso.partnerAppPoint=SP1EE gatein.sso.filter.login.sso.url=${gatein.sso.server.url}/IDBUS/${gatein.sso.josso.identityApplianceId}/${gatein.sso.josso.partnerAppPoint}/JOSSO/SSO/REDIR?josso_back_to=${gatein.sso.portal.url}/@@portal.container.name@(a)/josso_security_check&josso_partnerapp_id=${gatein.sso.josso.partnerAppId} </programlisting> - </informalexample> - - <para> + </informalexample> + <para> Note that <code>gatein.sso.filter.logout.url</code> is empty now as the logout URL will be obtained from the JOSSO agent configuration set in file <filename>JBOSS_HOME/gatein/gatein.ear/portal.war/WEB-INF/classes/sso/josso/2.2/josso-agent-config.xml</filename>. </para> - </step> - - <step> - <para> - Update the SSO module in EAP 6: + </step> + <step> + <para> + Update the SSO module in JBoss Enterprise Application Platform 6: </para> - - <substeps> - <step> - <para> + <substeps> + <step> + <para> Delete the <filename>JBOSS_HOME/modules/org/gatein/sso</filename> directory. </para> - </step> - - <step> - <para> + </step> + <step> + <para> Copy the <filename>SSO_HOME/josso/gatein-josso-182/modules/org/gatein/sso</filename> into <filename>JBOSS_HOME/modules/org/gatein/</filename> directory. </para> - </step> - </substeps> - </step> - - <step> - <substeps> - <step> - <para> + </step> + </substeps> + </step> + <step> + <substeps> + <step> + <para> Start the Portal. </para> - - <para> + <para> Access <uri>http://localhost:8080/portal</uri> and click <emphasis role="italics">Sign in</emphasis>. </para> - - <para> + <para> You will be redirected to the JOSSO instance, but you will need to login with the username/password account created via the JOSSO console (for example <literal>john</literal>/<literal>password</literal>) as REST callbacks are not supported. </para> - - <para> + <para> After a successful login to JOSSO, you will be redirected to the Portal as <literal>john</literal>. </para> - </step> - </substeps> - </step> - </procedure> - </section> - </section> - - <section> - <title>Setup with portal on Tomcat</title> - - <para> + </step> + </substeps> + </step> + </procedure> + </section> + </section> + <section> + <title>Setup with portal on Tomcat</title> + <para> If you have JBoss Portal Platform on Tomcat 7 and you want to configure it for SSO against JOSSO you must complete the following additional steps: </para> - - <procedure> - <title></title> - - <step> - <para> + <procedure> + <title/> + <step> + <para> Add <code>ServletAccessValve</code> into <filename>server.xml</filename> (as was done to set up CAS single sign-on). Refer to <xref linkend="sect-Deploying_CAS_on_Tomcat"/> for more details. </para> - - </step> - - <step> - <para> + </step> + <step> + <para> Copy the JAR files for the appropriate JOSSO version from <filename>GATEIN_SSO_HOME/josso/gatein-josso-<replaceable><version></replaceable>/modules/org/gatein/sso/main into JBOSS_HOME/lib/</filename>. </para> - <para> + <para> Use <replaceable>gatein-josso-181</replaceable> if you are on JOSSO 1.8.1 or older or <replaceable>gatein-josso-182</replaceable> if you are on JOSSO 1.8.2 or newer or on JOSSO 2.2. </para> - </step> - </procedure> - </section> - </section> - - <section id="sect-Reference_Guide-SSO_Single_Sign_On_-OpenAM"> - <title>OpenAM</title> - <para> - OpenAM is an open source access management, entitlements and federation server platform. It is a successor of OpenSSO, the access management and federation server platform whose integration was available in JBoss Enterprise Portal Platform 5. As the development of OpenSSO has been discontinued, the OpenSSO integration has been replaced with OpenAM integration in JBoss Portal Platform 6. - </para> - <section id="sect-Reference_Guide-SSO_Single_Sign_On_-OpenAM-Login-Workflow"> - <title>Login and Logout Workflow</title> - <para> - When the OpenAM integration is configured and a user clicks the <guibutton>Sign in</guibutton> link on a JBoss Portal Platform page, they are redirected to the OpenAM login screen, where they provide their login credentials. Authentication on the OpenAM server side is performed by the JBoss Portal Platform SSO Authentication Plugin. The plugin sends a REST request to JBoss Portal Platform, obtains a response, and authenticates the user on the OpenAM side based on the response. - </para> - <para> - After successful authentication with OpenAM, an OpenAM authentication ticket is stored in the <systemitem>iPlanetDirectoryPro</systemitem> cookie in the client browser and the user is redirected back to the portal page. When the portal page is requested, the <systemitem>InitiateLoginFilter</systemitem> iterceptor delegates validation of the OpenAM ticket to the <systemitem>OpenSSOAgent</systemitem> component. The <systemitem>OpenSSOAgent</systemitem> then uses the OpenAM REST API to perform back channel validation of the ticket with the OpenAM server. After successful validation, user identity is established and the user is logged in to JBoss Portal Platform. - </para> - <para> - When logout is requested by clicking the <guibutton>Sign out</guibutton> button on a portal page, the <emphasis role="italics">OpenSSOLogoutFilter</emphasis> interceptor performs logout on both JBoss Portal Platform and the OpenAM server. - </para> - <para> - The OpenAM login and logout workflow is similar to the workflow that users go through with CAS, so you can refer to <xref linkend="sect-CAS-Authentication_Process"/> for more detailed information. - </para> - </section> - <section id="sect-Reference_Guide-SSO_Single_Sign_On_-OpenAM-ObtainingOpenAM"> - <title>Obtaining OpenAM</title> - <para> - OpenAM must be obtained from <ulink url="http://forgerock.org/openam.html">Forgerock</ulink>. Only the 9.5 and 10.0 versions of OpenAM are fully tested and supported with JBoss Portal Platform 6. Integration with other versions—including <ulink url="http://www.oracle.com/technetwork/testcontent/opensso-091890.html">OpenSSO</ulink>, the predecessor of OpenAM—may be functional, but has not been fully tested and is therefore not supported. - </para> - <para> - The procedures in this section assume that OpenAM is obtained in the form of a ZIP distribution. Once downloaded, extract the contents of the ZIP package into a location of your choice. This location will be referred to as <code>OPENAM_HOME</code> in the following text. - </para> - </section> - <section id="sect-Reference_Guide-SSO_Single_Sign_On_-OpenAM-OpenAMserversetup"> - <title>OpenAM Server Setup</title> - <para> - This section contains procedures that need to be followed to set up an OpenAM server for authentication against JBoss Portal Platform. The authentication set up by these procedures is ensured by the JBoss Portal Platform SSO Authentication Plugin. The plugin will be installed in OpenAM and configured to perform authentication against the portal using a REST callback. - <note> - <para> - Using the REST callback as presented in this section is not mandatory. You can achieve authentication on the OpenAM side by any other means according to your preference. - </para> - </note> - </para> - <para> - To achieve the setup, perform the procedures in the following order: - <itemizedlist> - <listitem> - <para><xref linkend="sect-Reference_Guide-SSO_Single_Sign_On_-OpenAM-ModifyingtheOpenAMserver" /></para> - </listitem> - <listitem> - <para><xref linkend="sect-Reference_Guide-SSO_Single_Sign_On_-OpenAM-Authenticationpluginsetup" /></para> - </listitem> - <listitem> - <para><xref linkend="sect-Reference_Guide-SSO_Single_Sign_On_-OpenAM-ConfigurerealminOpenAMUI" /></para> - </listitem> - </itemizedlist> - </para> - <procedure id="sect-Reference_Guide-SSO_Single_Sign_On_-OpenAM-ModifyingtheOpenAMserver"> - <title>Deploying the OpenAM Server</title> - <step> - <para> - Obtain a copy of Tomcat 7 and extract it into a suitable location. This location will be referred to as <code>TOMCAT_HOME</code> further in the text. - </para> - </step> - <step> - <para> - Deploy OpenAM to Tomcat by copying the <code>OPENAM_HOME/opensso/deployable-war/opensso.war</code> archive to the <code>TOMCAT_HOME/webapps/</code> directory. - </para> - <note> - <para> - The name of the WAR file is still <filename>opensso.war</filename>, even if it contains OpenAM, which is the successor of OpenSSO. The context of the OpenAM web application has also kept the name <code>/opensso</code>. - </para> - </note> - </step> - <step> - <para> - Change the default Tomcat port to avoid conflict with the default JBoss Portal Platform port. For the purpose of this example, let's change it to <literal>8888</literal> by editing the <code>TOMCAT_HOME/conf/server.xml</code> configuration file and replacing the <literal>8080</literal> port number with <literal>8888</literal>. - </para> - </step> - <step performance="optional"> - <para> - If JBoss Portal Platform is running on the same machine as Tomcat, other Tomcat port numbers also need to be changed to avoid conflicts. These port numbers can be changed to any unassigned port numbers available on the machine. For example, you can change the admin port from <literal>8005</literal> to <literal>8805</literal> and the AJP port from <literal>8009</literal> to <literal>8809</literal> if the latter are not assigned. - </para> - </step> - </procedure> - <procedure id="sect-Reference_Guide-SSO_Single_Sign_On_-OpenAM-Authenticationpluginsetup"> - <title>Adding the Authentication Plug-in</title> - <step> - <para> - Copy the contents of the <code>JPP_DIST/gatein-sso/opensso/plugin/</code> directory to <code>TOMCAT_HOME/webapps/opensso/</code>. This will add: - </para> - <itemizedlist> - <listitem> - <para> - the <filename>AuthenticationPlugin.xml</filename> file to the <filename>TOMCAT_HOME/webapps/opensso/config/auth/default/</filename> directory. The file contains the following configuration: - </para> - <informalexample> -<programlisting language="XML"> -<?xml version='1.0' encoding="UTF-8"?> -<!DOCTYPE ModuleProperties PUBLIC "=//iPlanet//Authentication Module Properties XML Interface 1.0 DTD//EN" "jar://com/sun/identity/authentication/Auth_Module_Properties.dtd"> - -<ModuleProperties moduleName="AuthenticationPlugin" version="1.0"> - <Callbacks length="2" order="1" timeout="60" header="GateIn OpenAM Login"> + </step> + </procedure> + </section> + </section> + <section id="sect-Reference_Guide-SSO_Single_Sign_On_-OpenAM"> + <title>OpenAM</title> + <para> + OpenAM is an open source access management, entitlements and federation server platform. It is a successor of OpenSSO, the access management and federation server platform whose integration was available in JBoss Enterprise Portal Platform 5. As the development of OpenSSO has been discontinued, the OpenSSO integration has been replaced with OpenAM integration in JBoss Portal Platform 6. + </para> + <section id="sect-Reference_Guide-SSO_Single_Sign_On_-OpenAM-Login-Workflow"> + <title>Login and Logout Workflow</title> + <para> + When the OpenAM integration is configured and a user clicks the <guibutton>Sign in</guibutton> link on a JBoss Portal Platform page, they are redirected to the OpenAM login screen, where they provide their login credentials. Authentication on the OpenAM server side is performed by the JBoss Portal Platform SSO Authentication Plugin. The plugin sends a REST request to JBoss Portal Platform, obtains a response, and authenticates the user on the OpenAM side based on the response. + </para> + <para> + After successful authentication with OpenAM, an OpenAM authentication ticket is stored in the <systemitem>iPlanetDirectoryPro</systemitem> cookie in the client browser and the user is redirected back to the portal page. When the portal page is requested, the <systemitem>InitiateLoginFilter</systemitem> iterceptor delegates validation of the OpenAM ticket to the <systemitem>OpenSSOAgent</systemitem> component. The <systemitem>OpenSSOAgent</systemitem> then uses the OpenAM REST API to perform back channel validation of the ticket with the OpenAM server. After successful validation, user identity is established and the user is logged in to JBoss Portal Platform. + </para> + <para> + When logout is requested by clicking the <guibutton>Sign out</guibutton> button on a portal page, the <emphasis role="italics">OpenSSOLogoutFilter</emphasis> interceptor performs logout on both JBoss Portal Platform and the OpenAM server. + </para> + <para> + The OpenAM login and logout workflow is similar to the workflow that users go through with CAS, so you can refer to <xref linkend="sect-CAS-Authentication_Process"/> for more detailed information. + </para> + </section> + <section id="sect-Reference_Guide-SSO_Single_Sign_On_-OpenAM-ObtainingOpenAM"> + <title>Obtaining OpenAM</title> + <para> + OpenAM must be obtained from <ulink url="http://forgerock.org/openam.html">Forgerock</ulink>. Only the 9.5 and 10.0 versions of OpenAM are fully tested and supported with JBoss Portal Platform 6. Integration with other versions—including <ulink url="http://www.oracle.com/technetwork/testcontent/opensso-091890.html">OpenSSO</ulink>, the predecessor of OpenAM—may be functional, but has not been fully tested and is therefore not supported. + </para> + <para> + The procedures in this section assume that OpenAM is obtained in the form of a ZIP distribution. Once downloaded, extract the contents of the ZIP package into a location of your choice. This location will be referred to as <code>OPENAM_HOME</code> in the following text. + </para> + </section> + <section id="sect-Reference_Guide-SSO_Single_Sign_On_-OpenAM-OpenAMserversetup"> + <title>OpenAM Server Setup</title> + <para> + This section contains procedures that need to be followed to set up an OpenAM server for authentication against JBoss Portal Platform. The authentication set up by these procedures is ensured by the JBoss Portal Platform SSO Authentication Plugin. The plugin will be installed in OpenAM and configured to perform authentication against the portal using a REST callback. + <note> + <para> + Using the REST callback as presented in this section is not mandatory. You can achieve authentication on the OpenAM side by any other means according to your preference. + </para> + </note> + </para> + <para> + To achieve the setup, perform the procedures in the following order: + <itemizedlist> + <listitem> + <para><xref linkend="sect-Reference_Guide-SSO_Single_Sign_On_-OpenAM-ModifyingtheOpenAMserver"/></para> + </listitem> + <listitem> + <para><xref linkend="sect-Reference_Guide-SSO_Single_Sign_On_-OpenAM-Authenticationpluginsetup"/></para> + </listitem> + <listitem> + <para><xref linkend="sect-Reference_Guide-SSO_Single_Sign_On_-OpenAM-ConfigurerealminOpenAMUI"/></para> + </listitem> + </itemizedlist> + </para> + <procedure id="sect-Reference_Guide-SSO_Single_Sign_On_-OpenAM-ModifyingtheOpenAMserver"> + <title>Deploying the OpenAM Server</title> + <step> + <para> + Obtain a copy of Tomcat 7 and extract it into a suitable location. This location will be referred to as <code>TOMCAT_HOME</code> further in the text. + </para> + </step> + <step> + <para> + Deploy OpenAM to Tomcat by copying the <code>OPENAM_HOME/opensso/deployable-war/opensso.war</code> archive to the <code>TOMCAT_HOME/webapps/</code> directory. + </para> + <note> + <para> + The name of the WAR file is still <filename>opensso.war</filename>, even if it contains OpenAM, which is the successor of OpenSSO. The context of the OpenAM web application has also kept the name <code>/opensso</code>. + </para> + </note> + </step> + <step> + <para> + Change the default Tomcat port to avoid conflict with the default JBoss Portal Platform port. For the purpose of this example, let's change it to <literal>8888</literal> by editing the <code>TOMCAT_HOME/conf/server.xml</code> configuration file and replacing the <literal>8080</literal> port number with <literal>8888</literal>. + </para> + </step> + <step performance="optional"> + <para> + If JBoss Portal Platform is running on the same machine as Tomcat, other Tomcat port numbers also need to be changed to avoid conflicts. These port numbers can be changed to any unassigned port numbers available on the machine. For example, you can change the admin port from <literal>8005</literal> to <literal>8805</literal> and the AJP port from <literal>8009</literal> to <literal>8809</literal> if the latter are not assigned. + </para> + </step> + </procedure> + <procedure id="sect-Reference_Guide-SSO_Single_Sign_On_-OpenAM-Authenticationpluginsetup"> + <title>Adding the Authentication Plug-in</title> + <step> + <para> + Copy the contents of the <code>JPP_DIST/gatein-sso/opensso/plugin/</code> directory to <code>TOMCAT_HOME/webapps/opensso/</code>. This will add: + </para> + <itemizedlist> + <listitem> + <para> + the <filename>AuthenticationPlugin.xml</filename> file to the <filename>TOMCAT_HOME/webapps/opensso/config/auth/default/</filename> directory. The file contains the following configuration: + </para> + <informalexample> + <programlisting language="XML"> +<?xml version='1.0' encoding="UTF-8"?> +<!DOCTYPE ModuleProperties PUBLIC "=//iPlanet//Authentication Module Properties XML Interface 1.0 DTD//EN" "jar://com/sun/identity/authentication/Auth_Module_Properties.dtd"> + +<ModuleProperties moduleName="AuthenticationPlugin" version="1.0"> + <Callbacks length="2" order="1" timeout="60" header="GateIn OpenAM Login"> <NameCallback> <Prompt> Username </Prompt> </NameCallback> - <PasswordCallback echoPassword="false"> + <PasswordCallback echoPassword="false"> <Prompt> Password </Prompt> @@ -1351,94 +1123,102 @@ </Callbacks> </ModuleProperties> </programlisting> - </informalexample> - </listitem> - <listitem> - <para> - the <filename>sso-opensso-plugin-<VERSION>.jar</filename> and <filename>commons-httpclient-<VERSION>.jar</filename> archives to the <filename>TOMCAT_HOME/webapps/opensso/WEB-INF/lib</filename> directory. - </para> - </listitem> - <listitem> - <para> - the <filename>gatein.properties</filename> file to the <filename>TOMCAT_HOME/webapps/opensso/WEB-INF/classes/</filename> directory. You may need to change the values specified in this file to match the configuration of the JBoss Portal Platform instance. The values will be used by the authentication plugin to establish the REST connection to the portal. - </para> - </listitem> - </itemizedlist> - </step> - <step> - <para> - Start Tomcat and verify that you are able to access the OpenAM user interface at <ulink url="http://localhost:8888/opensso"/>. - </para> - </step> - </procedure> - <procedure id="sect-Reference_Guide-SSO_Single_Sign_On_-OpenAM-ConfigurerealminOpenAMUI"> - <title>Configuring a Realm in OpenAM User Interface</title> - <step> - <para> - Direct your browser to <ulink url="http://localhost:8888/opensso"/>. - </para> - </step> - <step> - <para>Create the default configuration.</para> - </step> - <step> - <para> - Login as <systemitem class="username">amadmin</systemitem> and navigate to <menuchoice><guimenu>Configuration</guimenu><guimenuitem>Authentication</guimenuitem></menuchoice>. - </para> - </step> - <step> - <para> - Select the <guibutton>Core</guibutton> link, add a new value containing the <literal>org.gatein.sso.opensso.plugin.AuthenticationPlugin</literal> class name and click <guibutton>Save</guibutton>. This step is important for the JBoss Portal Platform SSO Authentication Plugin to be available among other OpenAM authentication modules. - </para> - </step> - <step> - <para> - Go to the <guimenu>Access control</guimenu> tab and create a new realm called <literal>gatein</literal>. - </para> - </step> - <step> - <para> - Go to the <literal>gatein</literal> realm and click the <guimenu>Authentication</guimenu> tab. In the <guimenu>Authentication chaining</guimenu> section at the bottom of the tab, click <guibutton>ldapService</guibutton>. Here, change the selection from <literal>Datastore</literal>, which is the default module in the authentication chain, to <literal>AuthenticationPlugin</literal>. This ensures that authentication of the <literal>gatein</literal> realm will be performed using the JBoss Portal Platform REST service instead of the OpenAM LDAP server. - </para> - </step> - <step> - <para> - Still on the <guimenu>Authentication</guimenu> tab of the <literal>gatein</literal> realm, click the <guibutton>All Core Settings</guibutton> button. When the settings are displayed, change the <guilabel>UserProfile</guilabel> value from <literal>Required</literal> to <literal>Dynamic</literal>. This is needed because JBoss Portal Platform users are not initially present in the OpenAM LDAP server datastore. The <literal>Dynamic</literal> value ensures that all users are automatically added the datastore after their first successful authentication. - </para> - </step> - <step> - <para> - Go to <menuchoice><guimenu>Access control</guimenu><guimenuitem>Top level realm</guimenuitem><guimenuitem>Privileges</guimenuitem><guimenuitem>All authenticated users</guimenuitem></menuchoice> and check the following checkboxes: - </para> - <itemizedlist> - <listitem> - <para> - <guilabel>Read and write access only for policy properties</guilabel> - </para> - </listitem> - <listitem> - <para> - <guilabel>Read and write access to all realm and policy properties</guilabel> - </para> - </listitem> - </itemizedlist> - <para> - Adding these privileges allows REST access to the OpenAM server. - </para> - </step> - <step> - <para> - Repeat the previous step to increase the privileges also for the <literal>gatein</literal> realm. - </para> - </step> - </procedure> - </section> - <section id="sect-Reference_Guide-SSO_Single_Sign_On_-OpenAM-SetuptheOpenAMclient"> - <title>JBoss Portal Platform Setup as OpenAM Client</title> - <para> - On the JBoss Portal Platform server, you need to ensure proper configuration of single sign-on properties in the <code>JPP_SERVER/standalone/configuration/gatein/configuration.properties</code> file. Locate the SSO section in this file and change/add properties in the section as follows: - </para> -<programlisting># SSO + </informalexample> + </listitem> + <listitem> + <para> + the <filename>sso-opensso-plugin-<VERSION>.jar</filename> and <filename>commons-httpclient-<VERSION>.jar</filename> archives to the <filename>TOMCAT_HOME/webapps/opensso/WEB-INF/lib</filename> directory. + </para> + </listitem> + <listitem> + <para> + the <filename>gatein.properties</filename> file to the <filename>TOMCAT_HOME/webapps/opensso/WEB-INF/classes/</filename> directory. You may need to change the values specified in this file to match the configuration of the JBoss Portal Platform instance. The values will be used by the authentication plugin to establish the REST connection to the portal. + </para> + </listitem> + </itemizedlist> + </step> + <step> + <para> + Start Tomcat and verify that you are able to access the OpenAM user interface at <ulink url="http://localhost:8888/opensso"/>. + </para> + </step> + </procedure> + <procedure id="sect-Reference_Guide-SSO_Single_Sign_On_-OpenAM-ConfigurerealminOpenAMUI"> + <title>Configuring a Realm in OpenAM User Interface</title> + <step> + <para> + Direct your browser to <ulink url="http://localhost:8888/opensso"/>. + </para> + </step> + <step> + <para>Create the default configuration.</para> + </step> + <step> + <para> + Login as <systemitem class="username">amadmin</systemitem> and navigate to <menuchoice> + <guimenu>Configuration</guimenu> + <guimenuitem>Authentication</guimenuitem> + </menuchoice>. + </para> + </step> + <step> + <para> + Select the <guibutton>Core</guibutton> link, add a new value containing the <literal>org.gatein.sso.opensso.plugin.AuthenticationPlugin</literal> class name and click <guibutton>Save</guibutton>. This step is important for the JBoss Portal Platform SSO Authentication Plugin to be available among other OpenAM authentication modules. + </para> + </step> + <step> + <para> + Go to the <guimenu>Access control</guimenu> tab and create a new realm called <literal>gatein</literal>. + </para> + </step> + <step> + <para> + Go to the <literal>gatein</literal> realm and click the <guimenu>Authentication</guimenu> tab. In the <guimenu>Authentication chaining</guimenu> section at the bottom of the tab, click <guibutton>ldapService</guibutton>. Here, change the selection from <literal>Datastore</literal>, which is the default module in the authentication chain, to <literal>AuthenticationPlugin</literal>. This ensures that authentication of the <literal>gatein</literal> realm will be performed using the JBoss Portal Platform REST service instead of the OpenAM LDAP server. + </para> + </step> + <step> + <para> + Still on the <guimenu>Authentication</guimenu> tab of the <literal>gatein</literal> realm, click the <guibutton>All Core Settings</guibutton> button. When the settings are displayed, change the <guilabel>UserProfile</guilabel> value from <literal>Required</literal> to <literal>Dynamic</literal>. This is needed because JBoss Portal Platform users are not initially present in the OpenAM LDAP server datastore. The <literal>Dynamic</literal> value ensures that all users are automatically added the datastore after their first successful authentication. + </para> + </step> + <step> + <para> + Go to <menuchoice> + <guimenu>Access control</guimenu> + <guimenuitem>Top level realm</guimenuitem> + <guimenuitem>Privileges</guimenuitem> + <guimenuitem>All authenticated users</guimenuitem> + </menuchoice> and check the following checkboxes: + </para> + <itemizedlist> + <listitem> + <para> + <guilabel>Read and write access only for policy properties</guilabel> + </para> + </listitem> + <listitem> + <para> + <guilabel>Read and write access to all realm and policy properties</guilabel> + </para> + </listitem> + </itemizedlist> + <para> + Adding these privileges allows REST access to the OpenAM server. + </para> + </step> + <step> + <para> + Repeat the previous step to increase the privileges also for the <literal>gatein</literal> realm. + </para> + </step> + </procedure> + </section> + <section id="sect-Reference_Guide-SSO_Single_Sign_On_-OpenAM-SetuptheOpenAMclient"> + <title>JBoss Portal Platform Setup as OpenAM Client</title> + <para> + On the JBoss Portal Platform server, you need to ensure proper configuration of single sign-on properties in the <code>JPP_SERVER/standalone/configuration/gatein/configuration.properties</code> file. Locate the SSO section in this file and change/add properties in the section as follows: + </para> + <programlisting># SSO gatein.sso.enabled=true gatein.sso.callback.enabled=${gatein.sso.enabled} gatein.sso.login.module.enabled=${gatein.sso.enabled} @@ -1450,59 +1230,59 @@ gatein.sso.filter.logout.url=${gatein.sso.server.url}/UI/Logout gatein.sso.filter.login.sso.url=${gatein.sso.server.url}/UI/Login?realm=${gatein.sso.openam.realm}&goto=${gatein.sso.portal.url}/@@portal.container.name@(a)/initiatessologin </programlisting> - <para> - Most of the properties are already described for CAS integration in <xref linkend="sect-CAS_Configuring_the_Platform" />, so you can refer to that section for detailed information. - </para> - <para> - Values of some properties are different with OpenAM, specifically the URLs for login/logout redirection, the logout filter class and the <code>gatein.sso.server.url</code> property, which points to the location of the OpenAM server. The <code>gatein.sso.openam.realm</code> value points to the realm created on the OpenAM server in <xref linkend="sect-Reference_Guide-SSO_Single_Sign_On_-OpenAM-ConfigurerealminOpenAMUI" />. - </para> - <para> - With all the previously described configuration, all links redirecting users to authentication pages will redirect them to the OpenAM authentication form. On the OpenAM side, users will be able to log in to the <literal>gatein</literal> realm using their JBoss Portal Platform credentials. - </para> - <para> - <figure> - <title>OpenAM Login Page</title> - <mediaobject> - <imageobject> - <imagedata fileref="images/AuthenticationAndIdentity/SSO/openam.png"/> - </imageobject> - </mediaobject> - </figure> - </para> - </section> - <section id="sect-Reference_Guide-SSO_Single_Sign_On_-OpenAM-CrossdomainauthenticationwithOpenAM"> - <title>Cross-domain Authentication with OpenAM</title> - <para> - The configuration described in <xref linkend="sect-Reference_Guide-SSO_Single_Sign_On_-OpenAM-OpenAMserversetup" /> and <xref linkend="sect-Reference_Guide-SSO_Single_Sign_On_-OpenAM-SetuptheOpenAMclient" /> assumes that JBoss Portal Platform and OpenAM are deployed on the same server or in the same DNS domain. - </para> - <para> - In such an environment, OpenAM adds the <systemitem>iPlanetDirectoryPro</systemitem> cookie for the shared domain to the client browser. It stores the authentiction token in the cookie and performs redirection to the <systemitem>OpenSSOAgent</systemitem> in JBoss Portal Platform. The agent is able to read the token from the cookie and perform its validation because the portal is running in the same domain. - </para> - <para> - This is not possible when the JBoss Portal Platform server and the OpenAM server are running in different domains and cannot share cookies. OpenAM provides the <systemitem>CDCServlet</systemitem> to solve this situation. Authenticated users can send requests to this servlet and the servlet responds with an encoded SAML message containing the SSO token and other information required to authenticate. The portal agent is then able to parse and validate the message, obtain the SSO token and establish the <systemitem>iPlanetDirectoryPro</systemitem> cookie for the domain where JBoss Portal Platform is deployed. Once the OpenAM agent on the portal side has token, it can perform further validation of this token and finish authentication of the user. - </para> - <para> - Detailed information about the <systemitem>CDCServlet</systemitem> servlet can be found in <ulink url="http://docs.oracle.com/cd/E19575-01/820-3746/gipjl/index.html">Sun OpenSSO Enterprise Deployment Planning Guide</ulink>. - </para> - <procedure id="sect-Reference_Guide-SSO_Single_Sign_On_-OpenAM-Crossdomainauthenticationconfiguration"> - <title>Cross-domain Authentication Configuration</title> - <para> - For the purpose of this example, we will assume that the OpenAM server is deployed on the <literal>opensso.mydomain.com</literal> host and the JBoss Portal Platform server on the <literal>portal.yourdomain.com</literal> host. - </para> - <para> - If you want to simulate this configuration on a single machine, you can do it by configuring virtual hosts. On Linux, this can be achieved by editing the <code>/etc/hosts</code> file and adding records similar to the following, with the IP addresses changed accordingly: - </para> - <para> + <para> + Most of the properties are already described for CAS integration in <xref linkend="sect-CAS_Configuring_the_Platform"/>, so you can refer to that section for detailed information. + </para> + <para> + Values of some properties are different with OpenAM, specifically the URLs for login/logout redirection, the logout filter class and the <code>gatein.sso.server.url</code> property, which points to the location of the OpenAM server. The <code>gatein.sso.openam.realm</code> value points to the realm created on the OpenAM server in <xref linkend="sect-Reference_Guide-SSO_Single_Sign_On_-OpenAM-ConfigurerealminOpenAMUI"/>. + </para> + <para> + With all the previously described configuration, all links redirecting users to authentication pages will redirect them to the OpenAM authentication form. On the OpenAM side, users will be able to log in to the <literal>gatein</literal> realm using their JBoss Portal Platform credentials. + </para> + <para> + <figure> + <title>OpenAM Login Page</title> + <mediaobject> + <imageobject> + <imagedata fileref="images/AuthenticationAndIdentity/SSO/openam.png"/> + </imageobject> + </mediaobject> + </figure> + </para> + </section> + <section id="sect-Reference_Guide-SSO_Single_Sign_On_-OpenAM-CrossdomainauthenticationwithOpenAM"> + <title>Cross-domain Authentication with OpenAM</title> + <para> + The configuration described in <xref linkend="sect-Reference_Guide-SSO_Single_Sign_On_-OpenAM-OpenAMserversetup"/> and <xref linkend="sect-Reference_Guide-SSO_Single_Sign_On_-OpenAM-SetuptheOpenAMclient"/> assumes that JBoss Portal Platform and OpenAM are deployed on the same server or in the same DNS domain. + </para> + <para> + In such an environment, OpenAM adds the <systemitem>iPlanetDirectoryPro</systemitem> cookie for the shared domain to the client browser. It stores the authentiction token in the cookie and performs redirection to the <systemitem>OpenSSOAgent</systemitem> in JBoss Portal Platform. The agent is able to read the token from the cookie and perform its validation because the portal is running in the same domain. + </para> + <para> + This is not possible when the JBoss Portal Platform server and the OpenAM server are running in different domains and cannot share cookies. OpenAM provides the <systemitem>CDCServlet</systemitem> to solve this situation. Authenticated users can send requests to this servlet and the servlet responds with an encoded SAML message containing the SSO token and other information required to authenticate. The portal agent is then able to parse and validate the message, obtain the SSO token and establish the <systemitem>iPlanetDirectoryPro</systemitem> cookie for the domain where JBoss Portal Platform is deployed. Once the OpenAM agent on the portal side has token, it can perform further validation of this token and finish authentication of the user. + </para> + <para> + Detailed information about the <systemitem>CDCServlet</systemitem> servlet can be found in <ulink url="http://docs.oracle.com/cd/E19575-01/820-3746/gipjl/index.html">Sun OpenSSO Enterprise Deployment Planning Guide</ulink>. + </para> + <procedure id="sect-Reference_Guide-SSO_Single_Sign_On_-OpenAM-Crossdomainauthenticationconfiguration"> + <title>Cross-domain Authentication Configuration</title> + <para> + For the purpose of this example, we will assume that the OpenAM server is deployed on the <literal>opensso.mydomain.com</literal> host and the JBoss Portal Platform server on the <literal>portal.yourdomain.com</literal> host. + </para> + <para> + If you want to simulate this configuration on a single machine, you can do it by configuring virtual hosts. On Linux, this can be achieved by editing the <code>/etc/hosts</code> file and adding records similar to the following, with the IP addresses changed accordingly: + </para> + <para> <programlisting> opensso.mydomain.com 192.168.2.7 portal.yourdomain.com 10.11.12.13 </programlisting> - </para> - <step> - <para> - On the JBoss Portal Platform side, single sign-on configuration in the <code>configuration.properties</code> file needs to be specified as follows: - </para> -<programlisting> + </para> + <step> + <para> + On the JBoss Portal Platform side, single sign-on configuration in the <code>configuration.properties</code> file needs to be specified as follows: + </para> + <programlisting> # SSO gatein.sso.enabled=true gatein.sso.callback.enabled=${gatein.sso.enabled} @@ -1517,139 +1297,143 @@ gatein.sso.filter.login.openamcdc.enabled=true gatein.sso.filter.login.sso.url=${gatein.sso.server.url}/cdcservlet </programlisting> - <para> - As we need to redirect requests to the <systemitem>CDCServlet</systemitem>, the <code>gatein.sso.filter.login.sso.url</code> property points to the URL of the servlet. It is also necessary to use a modified version of the <code>LoginRedirectFilter</code> interceptor. That is why the <code>gatein.sso.filter.login.openamcdc.enabled</code> value is changed to <literal>true</literal> and the <code>gatein.sso.filter.login.enabled</code> value is now set to <literal>false</literal>. - </para> - </step> - <step> - <para> - Access the OpenAM user interface at <ulink url="http://opensso.mydomain.com:8888/opensso"/> and log in as <systemitem class="username">amadmin</systemitem>. - </para> - </step> - <step> - <para> - Navigate to <menuchoice><guimenu>Access Control</guimenu><guimenuitem>"gatein" realm</guimenuitem> <guimenuitem>Agents</guimenuitem><guimenuitem>Web</guimenuitem></menuchoice>. - </para> - </step> - <step> - <para>Create a new web agent through the wizard using the following properties:</para> - <itemizedlist> - <listitem> - <para><guilabel>Name</guilabel>: GateInAgent</para> - </listitem> - <listitem> - <para><guilabel>Password</guilabel>: A password of your choice.</para> - </listitem> - <listitem> - <para><guilabel>Configuration</guilabel>: Centralized</para> - </listitem> - <listitem> - <para> - <guilabel>Server URL</guilabel>: <ulink url="http://opensso.mydomain.com:8888/opensso"/> - </para> - </listitem> - <listitem> - <para> - <guilabel>Agent URL</guilabel>: <ulink url="http://portal.yourdomain.com:8080"/> - </para> - </listitem> - </itemizedlist> - <para> - Creating this agent is required for the <systemitem>CDCServlet</systemitem> to work properly. If you have more portal servers on different hosts, you may want to create an agent for each of them. Please refer to <ulink url="http://openam.forgerock.org/doc/admin-guide/index.html">OpenAM Administration Guide</ulink> for more details. - </para> - </step> - </procedure> - </section> - </section> - - <section id="sect-Reference_Guide-SSO_Single_Sign_On_-SPNEGO_Simple_and_Protected_GSSAPI_Negotiation_Mechanism"> - <title>Simple and Protected GSSAPI Negotiation Mechanism (SPNEGO)</title> - <para> + <para> + As we need to redirect requests to the <systemitem>CDCServlet</systemitem>, the <code>gatein.sso.filter.login.sso.url</code> property points to the URL of the servlet. It is also necessary to use a modified version of the <code>LoginRedirectFilter</code> interceptor. That is why the <code>gatein.sso.filter.login.openamcdc.enabled</code> value is changed to <literal>true</literal> and the <code>gatein.sso.filter.login.enabled</code> value is now set to <literal>false</literal>. + </para> + </step> + <step> + <para> + Access the OpenAM user interface at <ulink url="http://opensso.mydomain.com:8888/opensso"/> and log in as <systemitem class="username">amadmin</systemitem>. + </para> + </step> + <step> + <para> + Navigate to <menuchoice> + <guimenu>Access Control</guimenu> + <guimenuitem>"gatein" realm</guimenuitem> + <guimenuitem>Agents</guimenuitem> + <guimenuitem>Web</guimenuitem> + </menuchoice>. + </para> + </step> + <step> + <para>Create a new web agent through the wizard using the following properties:</para> + <itemizedlist> + <listitem> + <para><guilabel>Name</guilabel>: GateInAgent</para> + </listitem> + <listitem> + <para><guilabel>Password</guilabel>: A password of your choice.</para> + </listitem> + <listitem> + <para><guilabel>Configuration</guilabel>: Centralized</para> + </listitem> + <listitem> + <para> + <guilabel>Server URL</guilabel>: <ulink url="http://opensso.mydomain.com:8888/opensso"/> + </para> + </listitem> + <listitem> + <para> + <guilabel>Agent URL</guilabel>: <ulink url="http://portal.yourdomain.com:8080"/> + </para> + </listitem> + </itemizedlist> + <para> + Creating this agent is required for the <systemitem>CDCServlet</systemitem> to work properly. If you have more portal servers on different hosts, you may want to create an agent for each of them. Please refer to <ulink url="http://openam.forgerock.org/doc/admin-guide/index.html">OpenAM Administration Guide</ulink> for more details. + </para> + </step> + </procedure> + </section> + </section> + <section id="sect-Reference_Guide-SSO_Single_Sign_On_-SPNEGO_Simple_and_Protected_GSSAPI_Negotiation_Mechanism"> + <title>Simple and Protected GSSAPI Negotiation Mechanism (SPNEGO)</title> + <para> The Simple and Protected GSSAPI Negotiation Mechanism (SPNEGO) uses desktop credentials provided during desktop authentication to transparently authenticate a portal user through a web browser. - </para> - <para> - Let's illustrate this mechanism on a typical use case: - </para> - <procedure> - <step> - <para> + </para> + <para> + Let's illustrate this mechanism on a typical use case: + </para> + <procedure> + <step> + <para> A user logs into their desktop computer with a login that is governed by an Active Directory domain. </para> - </step> - <step> - <para> + </step> + <step> + <para> The user launches a web browser to access a web application that is hosted on JBoss Portal Platform and uses JBoss Negotiation. </para> - </step> - <step> - <para> + </step> + <step> + <para> The browser transfers the desktop credentials to the web application. </para> - </step> - <step> - <para> - JBoss Portal Platform uses background GSS messages to validate the user's Kerberos ticket with the Active Directory (or another Kerberos server). + </step> + <step> + <para> + JBoss Portal Platform uses background GSS messages to validate the user's Kerberos ticket with the Active Directory (or another Kerberos server). </para> - </step> - <step> - <para> + </step> + <step> + <para> The user experiences a seamless sign-on into the web application. </para> - </step> - </procedure> - <section id="sect-Reference_Guide-SPNEGO_Simple_and_Protected_GSSAPI_Negotiation_Mechanism-SPNEGO_Server_Configuration"> - <title>SPNEGO Server Configuration</title> - <para> + </step> + </procedure> + <section id="sect-Reference_Guide-SPNEGO_Simple_and_Protected_GSSAPI_Negotiation_Mechanism-SPNEGO_Server_Configuration"> + <title>SPNEGO Server Configuration</title> + <para> This section describes the steps to set up a Kerberos server on Linux. The server will then be used for SPNEGO authentication against JBoss Portal Platform. - </para> - <note> - <para> + </para> + <note> + <para> The procedure below only describes the basic steps to configure a SPNEGO server in a Linux environment. If you are already familiar with SPNEGO, or if you are using Windows and an Active Directory domain, you can proceed to <xref linkend="proc-Reference_Guide-JBoss_Enterprise_Portal_Platform_Configuration-Advanced_SPNEGO_Configuration"/> to see how SPNEGO can be integrated with JBoss Portal Platform. - </para> - <para> + </para> + <para> Kerberos setup is also dependent on your Linux distribution, so the steps can be slightly different in your environment. </para> - </note> - <procedure id="proc-Reference_Guide-SPNEGO_Server_Configuration-SPNEGO_Basics"> - <title>Configuring the SPNEGO Server</title> - <step> - <para> - Ensure correct hostname to IP address mapping on the machine where Kerberos and JBoss Portal Platform are running. For example, if the machine's IP address is <literal>192.168.1.88</literal> and you want it to be accessed under the <literal>server.local.network</literal> hostname, add the following line to the <emphasis role="bold">/etc/hosts</emphasis> file: + </note> + <procedure id="proc-Reference_Guide-SPNEGO_Server_Configuration-SPNEGO_Basics"> + <title>Configuring the SPNEGO Server</title> + <step> + <para> + Ensure correct hostname to IP address mapping on the machine where Kerberos and JBoss Portal Platform are running. For example, if the machine's IP address is <literal>192.168.1.88</literal> and you want it to be accessed under the <literal>server.local.network</literal> hostname, add the following line to the <emphasis role="bold">/etc/hosts</emphasis> file: </para> -<programlisting> + <programlisting> 192.168.1.88 server.local.network </programlisting> - <note> - <para> + <note> + <para> It is not recommended you use loopback addresses. </para> - </note> - </step> - <step> - <para> + </note> + </step> + <step> + <para> Install Kerberos with these packages: <package>krb5-admin-server</package>, <package>krb5-kdc</package>, <package>krb5-config</package>, <package>krb5-user</package>, <package>krb5-clients</package>, and <package>krb5-rsh-server</package>. </para> - </step> - <step> - <para> + </step> + <step> + <para> Edit the Kerberos configuration in the <emphasis role="bold">/etc/krb5.config</emphasis> file: - </para> - <itemizedlist> - <listitem> - <para> + </para> + <itemizedlist> + <listitem> + <para> Uncomment the following lines: </para> -<programlisting> + <programlisting> default_tgs_enctypes = rc4-hmac default_tkt_enctypes = rc4-hmac permitted_enctypes = rc4-hmac </programlisting> - </listitem> - <listitem> - <para> + </listitem> + <listitem> + <para> Add <emphasis role="bold">local.network</emphasis> as a default realm, add it to the list of realms, and remove the remaining realms. The resulting content of the file will be as follows: </para> -<programlisting> + <programlisting> [libdefaults] default_realm = LOCAL.NETWORK @@ -1702,19 +1486,19 @@ krb4_convert = true krb4_get_tickets = false </programlisting> - </listitem> - </itemizedlist> - </step> - <step> - <para> + </listitem> + </itemizedlist> + </step> + <step> + <para> Modify KDC configuration. - </para> - <itemizedlist> - <listitem> - <para> - Edit the <emphasis role="bold">/etc/krb5kdc/kdc.conf</emphasis> file as shown below: - </para> -<programlisting> + </para> + <itemizedlist> + <listitem> + <para> + Edit the <emphasis role="bold">/etc/krb5kdc/kdc.conf</emphasis> file as shown below: + </para> + <programlisting> [kdcdefaults] kdc_ports = 750,88 @@ -1736,327 +1520,327 @@ kdc = FILE:/tmp/kdc.log admin_server = FILE:/tmp/kadmin.log </programlisting> - </listitem> - <listitem> - <para> + </listitem> + <listitem> + <para> Create the <filename>krb5kdc</filename> and <filename>krb5logs</filename> directories according to the paths used in the KDC configuration file. </para> - </listitem> - <listitem> - <para> + </listitem> + <listitem> + <para> Create a KDC database. </para> -<programlisting> + <programlisting> sudo krb5_newrealm </programlisting> - </listitem> - <listitem> - <para> + </listitem> + <listitem> + <para> Start the KDC and Kerberos servers. </para> -<programlisting> + <programlisting> sudo /etc/init.d/krb5-kdc restart sudo /etc/init.d/krb-admin-server restart </programlisting> - </listitem> - </itemizedlist> - </step> - <step> - <para> + </listitem> + </itemizedlist> + </step> + <step> + <para> Add principals and create keys. - </para> - <itemizedlist> - <listitem> - <para> + </para> + <itemizedlist> + <listitem> + <para> Start an interactive <literal>kadmin</literal> session and create the necessary principals. </para> -<programlisting> + <programlisting> sudo kadmin.local </programlisting> - </listitem> - <listitem> - <para> + </listitem> + <listitem> + <para> Add the JBoss Portal Platform machine and keytab file. </para> -<programlisting> + <programlisting> addprinc -randkey HTTP/server.local.network(a)LOCAL.NETWORK ktadd HTTP/server.local.network(a)LOCAL.NETWORK </programlisting> - </listitem> - <listitem> - <para> + </listitem> + <listitem> + <para> Add the default JBoss Portal Platform user accounts and enter a password for each of them. </para> -<programlisting> + <programlisting> addprinc john addprinc demo addprinc root </programlisting> - </listitem> - </itemizedlist> - </step> - <step> - <para> + </listitem> + </itemizedlist> + </step> + <step> + <para> Issue the following command to test your setup: </para> -<programlisting> + <programlisting> kinit -A demo </programlisting> - <itemizedlist> - <listitem> - <para> + <itemizedlist> + <listitem> + <para> If everything is set up well, you are required to enter the password created for the <literal>demo</literal> user in the previous step. - </para> - <para> - Without the <command>-A</command> option, the Kerberos ticket validation would involve reverse DNS lookups, which can be difficult to debug with certain network DNS configurations. This is a production level security feature and it is not necessary to use it in a development environment. In production environment, it is recommended to avoid using the <command>-A</command> option. + </para> + <para> + Without the <command>-A</command> option, the Kerberos ticket validation would involve reverse DNS lookups, which can be difficult to debug with certain network DNS configurations. This is a production level security feature and it is not necessary to use it in a development environment. In production environment, it is recommended to avoid using the <command>-A</command> option. </para> - </listitem> - <listitem> - <para> + </listitem> + <listitem> + <para> After successful login to Kerberos, you can display your Kerberos ticket using the following command: </para> -<programlisting> + <programlisting> klist </programlisting> - </listitem> - <listitem> - <para> + </listitem> + <listitem> + <para> If you want to log out and destroy your Kerberos ticket, issue the following command: </para> -<programlisting> + <programlisting> kdestroy </programlisting> - </listitem> - </itemizedlist> - </step> - </procedure> - </section> - <section id="sect-Reference_Guide-SPNEGO_Simple_and_Protected_GSSAPI_Negotiation_Mechanism-SPNEGO_Server_Configuration-Clients"> - <title>Client Configuration</title> - <para> - After performing the server configuration described in <xref linkend="sect-Reference_Guide-SPNEGO_Simple_and_Protected_GSSAPI_Negotiation_Mechanism-SPNEGO_Server_Configuration" />, you need to enable negotiated authentication in web browsers on client machines from which users will authenticate. + </listitem> + </itemizedlist> + </step> + </procedure> + </section> + <section id="sect-Reference_Guide-SPNEGO_Simple_and_Protected_GSSAPI_Negotiation_Mechanism-SPNEGO_Server_Configuration-Clients"> + <title>Client Configuration</title> + <para> + After performing the server configuration described in <xref linkend="sect-Reference_Guide-SPNEGO_Simple_and_Protected_GSSAPI_Negotiation_Mechanism-SPNEGO_Server_Configuration"/>, you need to enable negotiated authentication in web browsers on client machines from which users will authenticate. </para> - <para> - <xref linkend="proc-Reference_Guide-JBoss_Enterprise_Portal_Platform_Configuration-SPNEGO_Firefox" /> describes how negotiated authentication can be enabled in Mozilla Firefox. For instructions on enabling negotiated authentication in a different browser, consult the browser's documentation. - </para> - <procedure id="proc-Reference_Guide-JBoss_Enterprise_Portal_Platform_Configuration-SPNEGO_Firefox"> - <title>Enabling Negotiated Authentication in Mozilla Firefox</title> - <step> - <para> + <para> + <xref linkend="proc-Reference_Guide-JBoss_Enterprise_Portal_Platform_Configuration-SPNEGO_Firefox"/> describes how negotiated authentication can be enabled in Mozilla Firefox. For instructions on enabling negotiated authentication in a different browser, consult the browser's documentation. + </para> + <procedure id="proc-Reference_Guide-JBoss_Enterprise_Portal_Platform_Configuration-SPNEGO_Firefox"> + <title>Enabling Negotiated Authentication in Mozilla Firefox</title> + <step> + <para> Start Mozilla Firefox and enter <literal>about:config</literal> into the address field. </para> - </step> - <step> - <para> + </step> + <step> + <para> Search for the <literal>network.negotiate-auth</literal> preference and set its value as follows: </para> -<programlisting> + <programlisting> network.negotiate-auth.allow-proxies = true network.negotiate-auth.delegation-uris = .local.network network.negotiate-auth.gsslib (no-value) network.negotiate-auth.trusted-uris = .local.network network.negotiate-auth.using-native-gsslib = true </programlisting> - </step> - </procedure> - </section> - <section id="sect-Reference_Guide-SPNEGO_Simple_and_Protected_GSSAPI_Negotiation_Mechanism-JBoss_Enterprise_Portal_Platform_Configuration"> - <title>JBoss Portal Platform Configuration</title> - <para> + </step> + </procedure> + </section> + <section id="sect-Reference_Guide-SPNEGO_Simple_and_Protected_GSSAPI_Negotiation_Mechanism-JBoss_Enterprise_Portal_Platform_Configuration"> + <title>JBoss Portal Platform Configuration</title> + <para> JBoss Portal Platform uses JBoss Negotiation to enable SPNEGO-based desktop single sign-on for the portal. The following procedure describes how to integrate SPNEGO with JBoss Portal Platform. - </para> - <procedure id="proc-Reference_Guide-JBoss_Enterprise_Portal_Platform_Configuration-Advanced_SPNEGO_Configuration"> - <title>Configuring SPNEGO Integration with JBoss Portal Platform</title> - <step> - <para> + </para> + <procedure id="proc-Reference_Guide-JBoss_Enterprise_Portal_Platform_Configuration-Advanced_SPNEGO_Configuration"> + <title>Configuring SPNEGO Integration with JBoss Portal Platform</title> + <step> + <para> Modify the <literal># SSO</literal> section of the <filename><replaceable>JPP_SERVER</replaceable>/standalone/configuration/gatein/configuration.properties</filename> file, replacing the original content with the following properties: </para> -<programlisting> + <programlisting> <xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="../../extras/Authentication_Identity_SSO/default124.xml" parse="text"/> </programlisting> - <para> + <para> The list below explains the meaning of individual properties: <variablelist> - <varlistentry> - <term>gatein.sso.enabled</term> - <listitem> - <para> - This is a general property used to inform JBoss Portal Platform that clicking the <guibutton>Sign in</guibutton> link will redirect users to a URL ending with the <literal>/portal/dologin</literal> suffix. - </para> - </listitem> - </varlistentry> - <varlistentry> - <term>gatein.sso.callback.enabled</term> - <listitem> - <para> - This property can be set to <literal>false</literal> as REST callbacks are not required for SPNEGO integration. - </para> - </listitem> - </varlistentry> - <varlistentry> - <term>gatein.sso.skip.jsp.redirection</term> - <listitem> - <para> - This property must be set to <literal>false</literal> for SPNEGO integration, especially to ensure fallback to FORM authentication. - </para> - </listitem> - </varlistentry> - <varlistentry> - <term>gatein.sso.login.module.enabled</term> - <listitem> - <para> - This property can be set to <literal>false</literal> as a different set of login modules is needed for SPNEGO integration. - </para> - </listitem> - </varlistentry> - <varlistentry> - <term>gatein.sso.filter.login.sso.url</term> - <listitem> - <para> - This value ensures that clicking the <guibutton>Sign in</guibutton> link will redirect users to the <literal>/portal/dologin</literal> URL, which is a secured URL declared in the <filename>security-constraint section of JPP_SERVER/gatein/gatein.ear/portal.war/WEB-INF/web.xml</filename> file, allowing the <systemitem>GateInNegotiationAuthenticator</systemitem> valve to intercept the HTTP request. - </para> - </listitem> - </varlistentry> - <varlistentry> - <term>gatein.sso.filter.logout.enabled</term> - <term>gatein.sso.filter.initiatelogin.enabled</term> - <listitem> - <para> - These properties can be set to <literal>false</literal> as the logout filter and the <systemitem>InitiateLoginFilter</systemitem> are not needed for SPNEGO integration. - </para> - </listitem> - </varlistentry> - <varlistentry> - <term>gatein.sso.valve.enabled</term> - <listitem> - <para> - SPNEGO integration requires a custom Tomcat valve to intercept HTTP requests for secured URLs. The <systemitem>SSODelegateValve</systemitem> is defined in the <filename>JPP_SERVER/gatein/gatein.ear/portal.war/WEB-INF/jboss-web.xml</filename> file and is used only if this option is set to <literal>true</literal>. The purpose of the valve is to delegate the real work to another valve declared in the <literal>gatein.sso.valve.class</literal> property. This eliminates the need to edit configuration in the <filename>jboss-web.xml</filename> file. - </para> - </listitem> - </varlistentry> - <varlistentry> - <term>gatein.sso.valve.class</term> - <listitem> - <para> - The delegate valve for SPNEGO is <systemitem>org.gatein.sso.spnego.GateInNegotiationAuthenticator</systemitem>. It is used to establish identity of the client by exchanging several handshakes with client browser. The valve is able to obtain and parse an SPNEGO token and resend it to the JAAS layer, where login modules (especially the <systemitem>SPNEGOLoginModule</systemitem>) are able to verify the validity of the wrapped Kerberos token and establish user identity at the JBoss Portal Platform layer. - </para> - </listitem> - </varlistentry> - </variablelist> - </para> - </step> - <step> + <varlistentry> + <term>gatein.sso.enabled</term> + <listitem> <para> + This is a general property used to inform JBoss Portal Platform that clicking the <guibutton>Sign in</guibutton> link will redirect users to a URL ending with the <literal>/portal/dologin</literal> suffix. + </para> + </listitem> + </varlistentry> + <varlistentry> + <term>gatein.sso.callback.enabled</term> + <listitem> + <para> + This property can be set to <literal>false</literal> as REST callbacks are not required for SPNEGO integration. + </para> + </listitem> + </varlistentry> + <varlistentry> + <term>gatein.sso.skip.jsp.redirection</term> + <listitem> + <para> + This property must be set to <literal>false</literal> for SPNEGO integration, especially to ensure fallback to FORM authentication. + </para> + </listitem> + </varlistentry> + <varlistentry> + <term>gatein.sso.login.module.enabled</term> + <listitem> + <para> + This property can be set to <literal>false</literal> as a different set of login modules is needed for SPNEGO integration. + </para> + </listitem> + </varlistentry> + <varlistentry> + <term>gatein.sso.filter.login.sso.url</term> + <listitem> + <para> + This value ensures that clicking the <guibutton>Sign in</guibutton> link will redirect users to the <literal>/portal/dologin</literal> URL, which is a secured URL declared in the <filename>security-constraint section of JPP_SERVER/gatein/gatein.ear/portal.war/WEB-INF/web.xml</filename> file, allowing the <systemitem>GateInNegotiationAuthenticator</systemitem> valve to intercept the HTTP request. + </para> + </listitem> + </varlistentry> + <varlistentry> + <term>gatein.sso.filter.logout.enabled</term> + <term>gatein.sso.filter.initiatelogin.enabled</term> + <listitem> + <para> + These properties can be set to <literal>false</literal> as the logout filter and the <systemitem>InitiateLoginFilter</systemitem> are not needed for SPNEGO integration. + </para> + </listitem> + </varlistentry> + <varlistentry> + <term>gatein.sso.valve.enabled</term> + <listitem> + <para> + SPNEGO integration requires a custom Tomcat valve to intercept HTTP requests for secured URLs. The <systemitem>SSODelegateValve</systemitem> is defined in the <filename>JPP_SERVER/gatein/gatein.ear/portal.war/WEB-INF/jboss-web.xml</filename> file and is used only if this option is set to <literal>true</literal>. The purpose of the valve is to delegate the real work to another valve declared in the <literal>gatein.sso.valve.class</literal> property. This eliminates the need to edit configuration in the <filename>jboss-web.xml</filename> file. + </para> + </listitem> + </varlistentry> + <varlistentry> + <term>gatein.sso.valve.class</term> + <listitem> + <para> + The delegate valve for SPNEGO is <systemitem>org.gatein.sso.spnego.GateInNegotiationAuthenticator</systemitem>. It is used to establish identity of the client by exchanging several handshakes with client browser. The valve is able to obtain and parse an SPNEGO token and resend it to the JAAS layer, where login modules (especially the <systemitem>SPNEGOLoginModule</systemitem>) are able to verify the validity of the wrapped Kerberos token and establish user identity at the JBoss Portal Platform layer. + </para> + </listitem> + </varlistentry> + </variablelist> + </para> + </step> + <step> + <para> Modify configuration of the <systemitem>security</systemitem> subsystem in the <filename><replaceable>JPP_SERVER</replaceable>/standalone/configuration/standalone.xml</filename> file: </para> - <substeps> - <step> - <para> - Rename the existing <literal>gatein-domain</literal> security domain to <literal>gatein-form-auth-domain</literal>. - </para> - </step> - <step> - <para> - Add a new definition of the <literal>gatein-domain</literal> security domain. - </para> - </step> - <step> - <para> - Add a new security domain called <literal>host</literal>. Values of the following properties need to be specified in accordance with your environment setup: - </para> - <para> - <variablelist> - <varlistentry> - <term>principal</term> - <listitem> - <para> - The HTTP server principal specified in your kerberos keytab. In <xref linkend="proc-Reference_Guide-SPNEGO_Server_Configuration-SPNEGO_Basics" />, we used the <literal>LOCAL.NETWORK</literal> Kerberos realm and the <literal>server.local.network</literal> host and subsequently added the <literal>HTTP/server.local.network(a)LOCAL.NETWORK</literal> principal to the keytab. - </para> - </listitem> - </varlistentry> - <varlistentry> - <term>keyTab</term> - <listitem> - <para> - The path to the file with your Kerberos keytab. In <xref linkend="proc-Reference_Guide-SPNEGO_Server_Configuration-SPNEGO_Basics" />, we used the <filename>/etc/krb5.keytab</filename> location. Please note that this file should be readable by the user under whose account JBoss Portal Platform is executed. Generally, Kerberos keytab files should not be readable by normal OS users as they contain encrypted keys of server principals. Consult Kerberos documentation for more details. - </para> - </listitem> - </varlistentry> - <varlistentry> - <term>debug</term> - <listitem> - <para> - Enabling this option adds more log messages into JBoss Portal Platform console and log file. It is useful to have this option enabled during configuration, but it is advised to disable it in production to avoid unnecessarily large server logs. - </para> - </listitem> - </varlistentry> - </variablelist> - </para> - </step> - </substeps> - <para> - The code extract below shows the expected result of the security domain configuraion. - </para> - <programlisting language="XML" role="XML"><xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="../../extras/Authentication_Identity_SSO/default125.xml" parse="text"/></programlisting> - </step> - <step> - <para> + <substeps> + <step> + <para> + Rename the existing <literal>gatein-domain</literal> security domain to <literal>gatein-form-auth-domain</literal>. + </para> + </step> + <step> + <para> + Add a new definition of the <literal>gatein-domain</literal> security domain. + </para> + </step> + <step> + <para> + Add a new security domain called <literal>host</literal>. Values of the following properties need to be specified in accordance with your environment setup: + </para> + <para> + <variablelist> + <varlistentry> + <term>principal</term> + <listitem> + <para> + The HTTP server principal specified in your kerberos keytab. In <xref linkend="proc-Reference_Guide-SPNEGO_Server_Configuration-SPNEGO_Basics"/>, we used the <literal>LOCAL.NETWORK</literal> Kerberos realm and the <literal>server.local.network</literal> host and subsequently added the <literal>HTTP/server.local.network(a)LOCAL.NETWORK</literal> principal to the keytab. + </para> + </listitem> + </varlistentry> + <varlistentry> + <term>keyTab</term> + <listitem> + <para> + The path to the file with your Kerberos keytab. In <xref linkend="proc-Reference_Guide-SPNEGO_Server_Configuration-SPNEGO_Basics"/>, we used the <filename>/etc/krb5.keytab</filename> location. Please note that this file should be readable by the user under whose account JBoss Portal Platform is executed. Generally, Kerberos keytab files should not be readable by normal OS users as they contain encrypted keys of server principals. Consult Kerberos documentation for more details. + </para> + </listitem> + </varlistentry> + <varlistentry> + <term>debug</term> + <listitem> + <para> + Enabling this option adds more log messages into JBoss Portal Platform console and log file. It is useful to have this option enabled during configuration, but it is advised to disable it in production to avoid unnecessarily large server logs. + </para> + </listitem> + </varlistentry> + </variablelist> + </para> + </step> + </substeps> + <para> + The code extract below shows the expected result of the security domain configuraion. + </para> + <programlisting language="XML" role="XML"><xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="../../extras/Authentication_Identity_SSO/default125.xml" parse="text"/></programlisting> + </step> + <step> + <para> While logged in as a user with read permissions for the Kerberos keytab file, start JBoss Portal Platform using the following command: </para> -<programlisting> + <programlisting> ./standalone.sh -Djava.security.krb5.realm=LOCAL.NETWORK -Djava.security.krb5.kdc=server.local.network -b server.local.network </programlisting> - </step> - </procedure> - </section> - <section> - <title>SPNEGO Configuration Testing</title> - <para> - Once you have performed the configuration above, you can follow <xref linkend="proc-Reference_Guide-JBoss_Enterprise_Portal_Platform_Configuration-SPNEGO_Testing"/> to verify that the configured authentication is functional. - </para> - <procedure id="proc-Reference_Guide-JBoss_Enterprise_Portal_Platform_Configuration-SPNEGO_Testing"> - <title>Testing the SPNEGO Configuration</title> - <step> - <para> + </step> + </procedure> + </section> + <section> + <title>SPNEGO Configuration Testing</title> + <para> + Once you have performed the configuration above, you can follow <xref linkend="proc-Reference_Guide-JBoss_Enterprise_Portal_Platform_Configuration-SPNEGO_Testing"/> to verify that the configured authentication is functional. + </para> + <procedure id="proc-Reference_Guide-JBoss_Enterprise_Portal_Platform_Configuration-SPNEGO_Testing"> + <title>Testing the SPNEGO Configuration</title> + <step> + <para> Log in to Kerberos using the following command: </para> -<programlisting> + <programlisting> kinit -A demo </programlisting> - </step> - <step> - <para> + </step> + <step> + <para> In a browser, access <ulink url="http://server.local.network:8080/portal">http://server.local.network:8080/portal</ulink> and click the <guibutton>Sign In</guibutton> link in the top menu of the portal. If the authentication is configured correctly, you will be automatically signed in as the <literal>demo</literal> user. </para> - </step> - <step> - <para> + </step> + <step> + <para> Destroy the previously obtained Kerberos ticket using the following command: <programlisting> kdestroy </programlisting> - </para> - </step> - <step> - <para> - In the browser, log out and log back in. In case of correct configuration, you will be redirected to the login screen of JBoss Portal Platform. This happens because you no longer have an active Kerberos ticket and a fallback to the standard FORM authentication occurred. - </para> - </step> - </procedure> - </section> - <section> + </para> + </step> + <step> + <para> + In the browser, log out and log back in. In case of correct configuration, you will be redirected to the login screen of JBoss Portal Platform. This happens because you no longer have an active Kerberos ticket and a fallback to the standard FORM authentication occurred. + </para> + </step> + </procedure> + </section> + <section> <title>Additional Configuration</title> - <para> - </para> - <section> - <title>Disabling Fallback to FORM Authentication</title> - <para> - As demonstrated in <xref linkend="proc-Reference_Guide-JBoss_Enterprise_Portal_Platform_Configuration-SPNEGO_Testing" />, users trying to sign in without a valid Kerberos ticket are automatically redirected to the JBoss Portal Platform logon page. There, they can perform standard FORM authentication using their user name and password. - </para> - <para> - If you want to disable FORM authentication to allow only users with a valid Kerberos ticket to sign in, you need to comment out the <parameter>usernamePasswordDomain</parameter> option in the <literal>SPNEGOLoginModule</literal> configuration in the <filename><replaceable>JPP_SERVER</replaceable>/standalone/configuration/standalone.xml</filename> file. - </para> -<programlisting language="XML"><![CDATA[<login-module + <para> + </para> + <section> + <title>Disabling Fallback to FORM Authentication</title> + <para> + As demonstrated in <xref linkend="proc-Reference_Guide-JBoss_Enterprise_Portal_Platform_Configuration-SPNEGO_Testing"/>, users trying to sign in without a valid Kerberos ticket are automatically redirected to the JBoss Portal Platform logon page. There, they can perform standard FORM authentication using their user name and password. + </para> + <para> + If you want to disable FORM authentication to allow only users with a valid Kerberos ticket to sign in, you need to comment out the <parameter>usernamePasswordDomain</parameter> option in the <literal>SPNEGOLoginModule</literal> configuration in the <filename><replaceable>JPP_SERVER</replaceable>/standalone/configuration/standalone.xml</filename> file. + </para> + <programlisting language="XML"><![CDATA[<login-module code="org.gatein.sso.spnego.SPNEGOLoginModule" flag="requisite"> <module-option name="password-stacking" value="useFirstPass"/> <module-option name="serverSecurityDomain" value="host"/> @@ -2064,30 +1848,30 @@  </login-module>]]> </programlisting> - </section> - <section> - <title>Enabling Logging</title> - <para> - To enable logging of events related to SPNEGO authentication, you can add the following entries to the <systemitem>logging</systemitem> subsystem in the <filename><replaceable>JPP_SERVER</replaceable>/standalone/configuration/standalone.xml</filename> file: - </para> -<programlisting language="XML"><![CDATA[<logger category="org.gatein.sso"> + </section> + <section> + <title>Enabling Logging</title> + <para> + To enable logging of events related to SPNEGO authentication, you can add the following entries to the <systemitem>logging</systemitem> subsystem in the <filename><replaceable>JPP_SERVER</replaceable>/standalone/configuration/standalone.xml</filename> file: + </para> + <programlisting language="XML"><![CDATA[<logger category="org.gatein.sso"> <level name="TRACE"/> </logger> <logger category="org.jboss.security.negotiation"> <level name="TRACE"/> </logger>]]> -</programlisting> - <para> - Increased logging of Kerberos events to standard output can be enabled by launching JBoss Portal Platform with the <command>-Dsun.security.krb5.debug=true</command> option. - </para> -<programlisting> +</programlisting> + <para> + Increased logging of Kerberos events to standard output can be enabled by launching JBoss Portal Platform with the <command>-Dsun.security.krb5.debug=true</command> option. + </para> + <programlisting> ./standalone.sh -Djava.security.krb5.realm=LOCAL.NETWORK -Djava.security.krb5.kdc=server.local.network -b server.local.network -Dsun.security.krb5.debug=true -</programlisting> - </section> +</programlisting> </section> - </section> - <section id="sect-SSO_Single_Sign_On_-Enabling_SSO_using_JBoss_SSO_Valve"> - <title>Single Sign-On in a Cluster</title> + </section> + </section> + <section id="sect-SSO_Single_Sign_On_-Enabling_SSO_using_JBoss_SSO_Valve"> + <title>Single Sign-On in a Cluster</title>  - <para> + --> <para> In a cluster, the JBoss SSO valve can be used to authenticate a user on one JBoss Portal Platform node and have that authentication automatically carried across to other nodes in the cluster. </para> - - <section id="sect-SSO_Single_Sign_On_-Enabling_SSO_using_JBoss_SSO_Valve-Default_Config"> - <title>Default Configuration</title> - - <para> + <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_SERVER/standalone/configuration/standalon-ha.xml</filename> file: </para> -<programlisting language="XML"><![CDATA[ + <programlisting language="XML"><![CDATA[ <sso cache-container="web" cache-name="sso" reauthenticate="false" /> ]]></programlisting> - <para> + <para> When a loadbalancer is used in a cluster, no further configuration is needed to set up single sign-on. All JBoss Portal Platform servers in the cluster are accessed through the same URL, which is the URL of the loadbalancer. Automatic single sign-on is performed when the loadbalancer redirects client requests to individual nodes in the cluster. </para> - </section> - - <section> - <title>Clustered Single-Sign On in a Shared DNS Domain</title> - - <para> + </section> + <section> + <title>Clustered Single-Sign On in a Shared DNS Domain</title> + <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. </para> -<programlisting language="XML"><![CDATA[ + <programlisting language="XML"><![CDATA[ <sso cache-container="web" cache-name="sso" reauthenticate="false" domain="yourdomain.com"/> ]]></programlisting> - <para> + <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> + <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> - - <step> - <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> + <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. </para> -<programlisting> + <programlisting> 127.0.1.1 machine1.yourdomain.com 127.0.1.2 machine2.yourdomain.com </programlisting> - </step> - - <step> - <para> + </step> + <step> + <para> On both servers, open the <filename><replaceable>JPP_SERVER</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. </para> -<programlisting language="XML"><![CDATA[ + <programlisting language="XML"><![CDATA[ <sso cache-container="web" cache-name="sso" reauthenticate="false" domain="yourdomain.com"/> ]]></programlisting> - </step> - - <step> - <para> + </step> + <step> + <para> Start the first server using the following command: </para> -<programlisting> + <programlisting> ./standalone.sh -b machine1.yourdomain.com -c standalone-ha.xml -Djboss.node.name=node1 </programlisting> - </step> - - <step> - <para> + </step> + <step> + <para> Start the second server using the following command: </para> -<programlisting> + <programlisting> ./standalone.sh -b machine2.yourdomain.com -c standalone-ha.xml -Djboss.node.name=node2 </programlisting> - </step> - - <step> - <para> + </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. </para> - </step> - - <step> - <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. </para> - </step> - - <step> - <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. </para> - </step> - </procedure> - </section> - - <section id="sect-SSO_Single_Sign_On_-Enabling_SSO_using_JBoss_SSO_Valve-Other_Web_Apps"> - <title>Reauthentication</title> - - <para> + </step> + </procedure> + </section> + <section id="sect-SSO_Single_Sign_On_-Enabling_SSO_using_JBoss_SSO_Valve-Other_Web_Apps"> + <title>Reauthentication</title> + <para> The JBoss SSO valve can also be used to authenticate with any other web application. If that application uses the same roles as the main JBoss Portal Platform instance, no further configuration is required. Because the JBoss SSO valve includes the same JAAS principal in all HTTP requests, even in requests to other web applications, matching roles ensure successful authentication with those applications. </para> - - <para> + <para> To enable single sing-on authentication with an application that uses different roles, you need to set the <parameter>reauthenticate</parameter> parameter of the <parameter>sso</parameter> JBoss Web subsystem configuration entry to <literal>true</literal>. </para> -<programlisting language="XML"><![CDATA[ + <programlisting language="XML"><![CDATA[ <sso cache-container="web" cache-name="sso" reauthenticate="true" /> ]]></programlisting> - <para> + <para> The <literal>true</literal> value ensures that reauthentication with user credentials will be performed against the web application's security domain in each HTTP request. This will enforce creation of a new principal with updated roles for the web application. As user credentials are used for authentication in this case, it is required that the same user credentials exist in both the web application and the JBoss Portal Platform instance. </para> - </section> - </section> - </chapter> + </section> + </section> +</chapter> Modified: epp/docs/branches/6.0/Reference_Guide/en-US/modules/PortalDevelopment/DefaultPortalConfiguration.xml =================================================================== --- epp/docs/branches/6.0/Reference_Guide/en-US/modules/PortalDevelopment/DefaultPortalConfiguration.xml 2013-01-25 01:01:20 UTC (rev 9076) +++ epp/docs/branches/6.0/Reference_Guide/en-US/modules/PortalDevelopment/DefaultPortalConfiguration.xml 2013-01-25 02:15:12 UTC (rev 9077) @@ -98,7 +98,7 @@ Once you have created a custom portal that suits your needs, you may wish to disable a portal that is no longer required. </para> <task> - <title>Task: Disable a portal in EPP 5</title> + <title>Task: Disable a portal in JBoss Portal Platform 5</title> <tasksummary> <para> The procedure below will show you how to disable an unused portal in a JBoss Portal Platform instance. Modified: epp/docs/branches/6.0/Reference_Guide/en-US/modules/PortalDevelopment/DefaultPortalNavigationConfiguration.xml =================================================================== --- epp/docs/branches/6.0/Reference_Guide/en-US/modules/PortalDevelopment/DefaultPortalNavigationConfiguration.xml 2013-01-25 01:01:20 UTC (rev 9076) +++ epp/docs/branches/6.0/Reference_Guide/en-US/modules/PortalDevelopment/DefaultPortalNavigationConfiguration.xml 2013-01-25 02:15:12 UTC (rev 9077) @@ -28,7 +28,7 @@ </listitem> </itemizedlist> <para> - These navigations are configured using the standard XML syntax in the file: <filename>02portal.war/WEB-INF/conf/portal/portal-configuration.xml</filename>. + These navigations are configured using the standard XML syntax in the file: <filename>portal.war/WEB-INF/conf/portal/portal-configuration.xml</filename>. </para> <programlisting language="XML" role="XML"><xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="../../extras/PortalDevelopment_DefaultPortalNavigationConfiguration/default144.xml" parse="text"/></programlisting> <para> @@ -114,7 +114,7 @@ The portal navigation incorporates the pages that can be accessed even when a user is not logged in (assuming the applicable permissions allow public access). For example; several portal navigations could be used when a company has multiple trademarks, and websites are set up for each of them. </para> <para> - The <emphasis>Classic</emphasis> portal is configured by three XML files in the <filename>02portal.war:/WEB-INF/conf/portal/portal/classic</filename> directory: + The <emphasis>Classic</emphasis> portal is configured by three XML files in the <filename><replaceable>JPP_HOME</replaceable>/gatein/gatein.ear/portal.war/WEB-INF/conf/portal/portal/classic</filename> directory: </para> <variablelist> <varlistentry> @@ -166,16 +166,15 @@ </warning> </listitem> </varlistentry> - <varlistentry> + <varlistentry> <term>pages.xml</term> <listitem> <para> - This configuration file structure is very similar to <filename>portal.xml</filename> and it can also contain container tags (some usage examples of container tags can be found in <filename>02portal.war/WEB-INF/conf/portal/portal/sharedlayout.xml</filename>). + This configuration file structure is very similar to <filename>portal.xml</filename> and it can also contain container tags (some usage examples of container tags can be found in <filename>portal.war/WEB-INF/conf/portal/portal/sharedlayout.xml</filename>). </para> <para> Each application can decide whether to render the portlet border, the window state, the icons, or the portlet mode. </para> - </listitem> </varlistentry> </variablelist> @@ -189,7 +188,7 @@ The group navigation menu is configured by two XML files (<filename>navigation.xml</filename> and <filename>pages.xml</filename>). The syntax used in these files is the same as those covered in <xref linkend="sect-Reference_Guide-Portal_Navigation_Configuration-Portal_Navigation"/>. </para> <para> - They are located in <filename>02portal.war/WEB-INF/conf/portal/group<replaceable>/group-name-path/</replaceable></filename> directory (For example; <filename>02portal.war/WEB-INF/conf/portal/group/platform/administrators/</filename>). + They are located in <filename>portal.war/WEB-INF/conf/portal/group<replaceable>/group-name-path/</replaceable></filename> directory (For example; <filename>portal.war/WEB-INF/conf/portal/group/platform/administrators/</filename>). </para> </section> <section id="sect-Reference_Guide-Portal_Navigation_Configuration-User_Navigation"> @@ -198,7 +197,7 @@ User navigation is the set of nodes and pages that are owned by a user. They are part of the user's dashboard. </para>  <para> - Two files configure the user navigation (<filename>navigation.xml</filename> and <filename>pages.xml</filename>). They are located in the directory "<filename>02portal.war/WEB-INF/conf/portal/users/{userName}</filename>". + Two files configure the user navigation (<filename>navigation.xml</filename> and <filename>pages.xml</filename>). They are located in the directory "<filename>portal.war/WEB-INF/conf/portal/users/{userName}</filename>". </para> <para> The file <filename>eXoGadgets.war/WEB-INF/gadget.xml</filename> defines the gadgets that will be available on a user dashboard. @@ -207,5 +206,5 @@ The example below shows a dashboard with all of the default gadgets included, as well as an extra currency converter gadget sourced from <ulink url="http://www.google.com/ig/directory?synd=open" type="http">Google Gadgets</ulink>. </para> <programlisting language="XML" role="XML"><xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="../../extras/PortalDevelopment_DefaultPortalNavigationConfiguration/gadgets.xml" parse="text"/></programlisting> - </section> + </section> </chapter> Modified: epp/docs/branches/6.0/Reference_Guide/en-US/modules/PortalDevelopment/LocalizationConfiguration.xml =================================================================== --- epp/docs/branches/6.0/Reference_Guide/en-US/modules/PortalDevelopment/LocalizationConfiguration.xml 2013-01-25 01:01:20 UTC (rev 9076) +++ epp/docs/branches/6.0/Reference_Guide/en-US/modules/PortalDevelopment/LocalizationConfiguration.xml 2013-01-25 02:15:12 UTC (rev 9077) @@ -57,7 +57,7 @@ The returned <literal>Locale</literal> has to be one of the locales supported by portal, otherwise it will fall back to the portal default <literal>Locale</literal>. </para> <para> - The supported locales are listed in <filename><replaceable>JPP_DIST</replaceable>/jboss-as/server/<replaceable>PROFILE</replaceable>/deploy/gatein.ear/02portal.war/WEB-INF/conf/common/locales-config.xml</filename> file as described in <xref linkend="sect-Reference_Guide-Internationalization_Configuration-Locales_Configuration"/> . + The supported locales are listed in <filename><replaceable>JPP_HOME</replaceable>/gatein/gatein.ear/portal.war/WEB-INF/conf/common/locales-config.xml</filename> file as described in <xref linkend="sect-Reference_Guide-Internationalization_Configuration-Locales_Configuration"/> . </para> <para> The <literal>determineLocale()</literal> method takes a parameter of type <literal>LocaleContextInfo</literal>, which represents a compilation of preferred locales from different sources; user’s profile, portal default, browser language settings, current session, browser cookie. @@ -204,7 +204,7 @@ <section id="sect-Reference_Guide-Pluggable_Locale_Policy-LocalePolicy_Configuration"> <title>LocalePolicy Configuration</title> <para> - The <literal>LocalePolicy</literal> framework is enabled for portlets by configuring <literal>LocalizationLifecycle</literal> class in portal's webui configuration file: <filename><replaceable>JPP_DIST</replaceable>/jboss-as/server/<replaceable>PROFILE</replaceable>/deploy/gatein.ear/02portal.war/WEB-INF/webui-configuration.xml</filename>: + The <literal>LocalePolicy</literal> framework is enabled for portlets by configuring <literal>LocalizationLifecycle</literal> class in portal's webui configuration file: <filename><replaceable>JPP_HOME</replaceable>/gatein/gatein.ear/portal.war/WEB-INF/webui-configuration.xml</filename>: </para> <programlisting language="XML" role="XML"><application-life-cycle-listeners> ... @@ -212,7 +212,7 @@ </application-life-cycle-listeners> </programlisting> <para> - The default <literal>LocalePolicy</literal> implementation is installed as an eXo Kernel portal service via <filename><replaceable>JPP_DIST</replaceable>/jboss-as/server/<replaceable>PROFILE</replaceable>/deploy/gatein.ear/02portal.war/WEB-INF/conf/portal/web-configuration.xml</filename>. + The default <literal>LocalePolicy</literal> implementation is installed as an eXo Kernel portal service via <filename><replaceable>JPP_HOME</replaceable>/gatein/gatein.ear/portal.war/WEB-INF/conf/portal/web-configuration.xml</filename>. </para> <para> The following excerpt is responsible for installing the service: @@ -244,7 +244,7 @@ That way even localization of servlets, and .jsps accessed in a non-bridged manner can stay in sync with portlet localization. </para> <para> - <literal>LocalizationFilter</literal> is installed through the portal's web.xml file: <filename><replaceable>JPP_DIST</replaceable>/jboss-as/server/<replaceable>PROFILE</replaceable>/deploy/gatein.ear/02portal.war/WEB-INF/web.xml</filename>. + <literal>LocalizationFilter</literal> is installed through the portal's web.xml file: <filename><replaceable>JPP_DIST</replaceable>/gatein/gatein.ear/portal.war/WEB-INF/web.xml</filename>. </para> <programlisting language="XML" role="XML"><filter> <filter-name>LocalizationFilter</filter-name> Modified: epp/docs/branches/6.0/Reference_Guide/en-US/modules/PortalDevelopment/Skinning.xml =================================================================== --- epp/docs/branches/6.0/Reference_Guide/en-US/modules/PortalDevelopment/Skinning.xml 2013-01-25 01:01:20 UTC (rev 9076) +++ epp/docs/branches/6.0/Reference_Guide/en-US/modules/PortalDevelopment/Skinning.xml 2013-01-25 02:15:12 UTC (rev 9077) @@ -87,7 +87,7 @@ The default skin can also be configured using the portal configuration files. This allows the portal to have the new default skin ready for use when JBoss Portal Platform is first started. </para> <para> - The default skin of the portal is called <literal>Default</literal>. To change this value add a <literal>skin</literal> tag in the <literal>02portal.war/WEB-INF/conf/portal/portal/classic/portal.xml</literal> configuration file. + The default skin of the portal is called <literal>Default</literal>. To change this value add a <literal>skin</literal> tag in the <literal>portal.war/WEB-INF/conf/portal/portal/classic/portal.xml</literal> configuration file. </para> <para> To change the skin to <literal>MySkin</literal> you would make the following changes: @@ -406,7 +406,7 @@ </listitem> <listitem> <para> - The value of the <parameter>portlet-name</parameter> element needs to match the value of the <parameter>portlet-name</parameter> element in <filename>portlet.xml</filename>. + The value of the <parameter>portlet-name</parameter> element needs to match the value of the <parameter>portlet-name</parameter> element in <filename><replaceable>JPP_HOME</replaceable>/standalone/configuration/gatein/portlet.xml</filename>. </para> </listitem> </itemizedlist> Modified: epp/docs/branches/6.0/Reference_Guide/en-US/modules/PortletDevelopment/Global_Portlet.xml =================================================================== --- epp/docs/branches/6.0/Reference_Guide/en-US/modules/PortletDevelopment/Global_Portlet.xml 2013-01-25 01:01:20 UTC (rev 9076) +++ epp/docs/branches/6.0/Reference_Guide/en-US/modules/PortletDevelopment/Global_Portlet.xml 2013-01-25 02:15:12 UTC (rev 9077) @@ -40,12 +40,12 @@ </portlet-app> </programlisting> <para> - The path to the global <filename>portlet.xml</filename> is the value of <literal>gatein.portlet.config</literal> in the <filename>configuration.properties.xml</filename> file. By default, the file path is <filename><replaceable>JPP_DIST</replaceable>/jboss-as/server/<replaceable>PROFILE</replaceable>/conf/gatein/portlet.xml</filename> + The path to the global <filename>portlet.xml</filename> is the value of <literal>gatein.portlet.config</literal> in the <filename>configuration.properties.xml</filename> file. By default, the file path is <filename><replaceable>JPP_HOME</replaceable>/standalone/configuration/gatein/portlet.xml</filename> </para> <section id="sect-Reference_Guide-Shared_portlet.xml-Global_Metadata_Elements"> <title>Global Metadata Elements</title> <para> - The global <filename>portlet.xml</filename> file conforms, with some restrictions, to the portlet deployment descriptor schema defined in the Portlet Specification. In this file, the following elements are supported: + The global <filename><replaceable>JPP_HOME</replaceable>/standalone/configuration/gatein/portlet.xml</filename> file conforms, with some restrictions, to the portlet deployment descriptor schema defined in the Portlet Specification. In this file, the following elements are supported: </para> <orderedlist> <listitem> Modified: epp/docs/branches/6.0/Reference_Guide/en-US/modules/PortletDevelopment/PortletBridge/configuration.xml =================================================================== --- epp/docs/branches/6.0/Reference_Guide/en-US/modules/PortletDevelopment/PortletBridge/configuration.xml 2013-01-25 01:01:20 UTC (rev 9076) +++ epp/docs/branches/6.0/Reference_Guide/en-US/modules/PortletDevelopment/PortletBridge/configuration.xml 2013-01-25 02:15:12 UTC (rev 9077) @@ -7,7 +7,7 @@ <title id="Portlet_Bridge_Bridge_Configuration">Bridge Configuration</title> <section id="sect-Reference_Guide-Core_Setup_and_Configuration-portlet.xml"> <title>portlet.xml</title> - <para>To have access to all portlet 2 specification features, you must declare the portlet schema definition as prescribed in the <filename>portlet.xml</filename> file. The <init-param> directives are explained in more detail if required below the portlet.xml code.</para> + <para>To have access to all portlet 2 specification features, you must declare the portlet schema definition as prescribed in the <filename><replaceable>JPP_HOME</replaceable>/standalone/configuration/gatein/portlet.xml</filename> file. The <init-param> directives are explained in more detail if required below the <filename>portlet.xml</filename> code.</para> <para>The XML below describes the basic directives required for a JSF2 portlet. Some directives are optional, and are called-out in the file. </para> <programlisting language="XML"><xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="../../../extras/PortletBridge_Configuration/default197.xml" parse="text"/></programlisting> Modified: epp/docs/branches/6.0/Reference_Guide/en-US/modules/PortletDevelopment/PortletBridge.xml =================================================================== --- epp/docs/branches/6.0/Reference_Guide/en-US/modules/PortletDevelopment/PortletBridge.xml 2013-01-25 01:01:20 UTC (rev 9076) +++ epp/docs/branches/6.0/Reference_Guide/en-US/modules/PortletDevelopment/PortletBridge.xml 2013-01-25 02:15:12 UTC (rev 9077) @@ -28,7 +28,7 @@ </section> <section id="Portlet_Bridge_File_Locations"> <title>File Locations</title> - <remark>BZ#856417 - NEEDINFO - will we be packaging the portletbridge binaries in this folder for EPP 6? </remark> + <remark>BZ#856417 - NEEDINFO - will we be packaging the portletbridge binaries in this folder for JBoss Portal Platform 6? </remark> <para>The binaries required for Portlet Bridge applications, and example applications that can be used to learn and understand JSF applications are located in in <filename>JPP_DIST/portletbridge</filename>. </para> <para>Configuration files for Portlet Bridge are located in the following locations: </para> <itemizedlist> Modified: epp/docs/branches/6.0/Reference_Guide/en-US/modules/PortletDevelopment/Standard.xml =================================================================== --- epp/docs/branches/6.0/Reference_Guide/en-US/modules/PortletDevelopment/Standard.xml 2013-01-25 01:01:20 UTC (rev 9076) +++ epp/docs/branches/6.0/Reference_Guide/en-US/modules/PortletDevelopment/Standard.xml 2013-01-25 02:15:12 UTC (rev 9077) @@ -121,7 +121,7 @@ This section describes how to deploy a portlet in JBoss Portal Platform. </para> <para> - An example portlet called <filename>SimplestHelloWorld</filename> is available in the <filename>/jboss-epp-<replaceable>VERSION</replaceable>-src/portal/examples/portlets/</filename> directory of the JBoss Portal Platform sources package. + An example portlet called <filename>SimplestHelloWorld</filename> is available in the <filename>/jboss-jpp-<replaceable>VERSION</replaceable>-src/portal/examples/portlets/</filename> directory of the JBoss Portal Platform sources package. </para> <section id="sect-Reference_Guide-Deploying_your_first_Portlet-Compiling"> <title>Compiling</title> @@ -306,7 +306,7 @@ <para>Obtain the JBoss Portal Platform sources package from the Customer Support portal.</para> </step> <step> - <para>Move to <filename>/jboss-epp-<replaceable>VERSION</replaceable>-src/portal/examples/portlets/jsphellouser</filename> </para> + <para>Move to <filename>/jboss-jpp-<replaceable>VERSION</replaceable>-src/portal/examples/portlets/jsphellouser</filename> </para> </step> <step> <para> @@ -455,7 +455,7 @@ In order to write a portlet using JSF a 'bridge' is needed. This software allows developers to write a portlet application as if it was a JSF application. The bridge then negotiates the interactions between the two layers. </para> <para> - An example using the JBoss Portlet Bridge is available in the <filename>/jboss-epp-<replaceable>VERSION</replaceable>-src/portal/examples/portlets/</filename> directory of the JBoss Portal Platform sources package. The configuration is slightly different from a JSP application. This example can be used as a base to configure instead of creating a new application. + An example using the JBoss Portlet Bridge is available in the <filename>/jboss-jpp-<replaceable>VERSION</replaceable>-src/portal/examples/portlets/</filename> directory of the JBoss Portal Platform sources package. The configuration is slightly different from a JSP application. This example can be used as a base to configure instead of creating a new application. </para> <para> As in any JSF application, the file <literal>faces-config.xml</literal> is required. It must contain the following information: Modified: epp/docs/branches/6.0/Reference_Guide/en-US/modules/eXoJCR/jcr/configuration/exo-jcr-configuration.xml =================================================================== --- epp/docs/branches/6.0/Reference_Guide/en-US/modules/eXoJCR/jcr/configuration/exo-jcr-configuration.xml 2013-01-25 01:01:20 UTC (rev 9076) +++ epp/docs/branches/6.0/Reference_Guide/en-US/modules/eXoJCR/jcr/configuration/exo-jcr-configuration.xml 2013-01-25 02:15:12 UTC (rev 9077) @@ -54,7 +54,7 @@ JCR services are registered in the Portal container. </para> <para> - Below is an example configuration from the <filename><replaceable>JPP_DIST</replaceable>/jboss-as/server/<replaceable>PROFILE</replaceable>/deploy/gatein.ear/02portal.war/WEB-INF/conf/jcr/jcr-configuration.xml</filename> file. + Below is an example configuration from the <filename><replaceable>JPP_DIST</replaceable>/gatein/gatein.ear/portal.war/WEB-INF/conf/jcr/jcr-configuration.xml</filename> file. </para> <programlisting language="XML"><xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="../../../../extras/Advanced_Development_JCR_Configuration/jcr-configuration.xml" parse="text"/></programlisting> <section id="sect-Reference_Guide-Portal_configuration-JCR_Configuration"> @@ -63,7 +63,7 @@ The JCR Service can use multiple <emphasis>Repositories</emphasis> and each repository can have multiple <emphasis>Workspaces</emphasis>. </para> <para> - Configure the workspaces by locating the workspace you need to modify in <filename><replaceable>JPP_DIST</replaceable>/jboss-as/server/<replaceable>PROFILE</replaceable>/deploy/gatein.ear/02portal.war/WEB-INF/conf/jcr/repository-configuration.xml</filename>. + Configure the workspaces by locating the workspace you need to modify in <filename><replaceable>JPP_DIST</replaceable>/gatein/gatein.ear/portal.war/WEB-INF/conf/jcr/repository-configuration.xml</filename>. </para> <para> The repository configuration supports human-readable values. They are not case-sensitive. Modified: epp/docs/branches/6.0/Reference_Guide/en-US/modules/eXoJCR/jcr/configuration/multilanguage-support.xml =================================================================== --- epp/docs/branches/6.0/Reference_Guide/en-US/modules/eXoJCR/jcr/configuration/multilanguage-support.xml 2013-01-25 01:01:20 UTC (rev 9076) +++ epp/docs/branches/6.0/Reference_Guide/en-US/modules/eXoJCR/jcr/configuration/multilanguage-support.xml 2013-01-25 02:15:12 UTC (rev 9077) @@ -37,7 +37,7 @@ <itemizedlist> <listitem> <para> - The configuration file to be modified for these changes is <filename><replaceable>JPP_DIST</replaceable>/jboss-as/server/<replaceable>PROFILE</replaceable>/deploy/gatein.ear/02portal.war/WEB-INF/conf/jcr/repository-configuration.xml</filename>. + The configuration file to be modified for these changes is <filename><replaceable>JPP_HOME</replaceable>/gatein/gatein.ear/portal.war/WEB-INF/conf/jcr/repository-configuration.xml</filename>. </para> </listitem> <listitem> Modified: epp/docs/branches/6.0/Reference_Guide/en-US/modules/eXoJCR/jcr/configuration/search-configuration.xml =================================================================== --- epp/docs/branches/6.0/Reference_Guide/en-US/modules/eXoJCR/jcr/configuration/search-configuration.xml 2013-01-25 01:01:20 UTC (rev 9076) +++ epp/docs/branches/6.0/Reference_Guide/en-US/modules/eXoJCR/jcr/configuration/search-configuration.xml 2013-01-25 02:15:12 UTC (rev 9077) @@ -12,7 +12,7 @@ Below is an example of the configuration file that governs search behaviors. Refer to <xref linkend="sect-Reference_Guide-Search_Configuration-Global_Search_Index"/> for how searching operates in JCR and information about customized searches. </para> <para> - The JCR index configuration file is located at <filename><replaceable>JPP_DIST</replaceable>/jboss-as/server/<replaceable>PROFILE</replaceable>/deploy/gatein.ear/02portal.war/WEB-INF/conf/jcr/repository-configuration.xml</filename>. + The JCR index configuration file is located at <filename><replaceable>JPP_HOME</replaceable>/gatein/gatein.ear/portal.war/WEB-INF/conf/jcr/repository-configuration.xml</filename>. </para> <para> A code example is included below with a list of the configuration parameters shown below that. @@ -516,7 +516,7 @@ </para> </example> <para> - The global search index is configured in the <filename><replaceable>JPP_DIST</replaceable>/jboss-as/server/<replaceable>VERSION</replaceable>/deploy/gatein.ear/02portal.war/WEB-INF/conf/jcr/repository-configuration.xml</filename> configuration file within the "query-handler" tag. + The global search index is configured in the <filename><replaceable>JPP_HOME</replaceable>/gatein/gatein.ear/portal.war/WEB-INF/conf/jcr/repository-configuration.xml</filename> configuration file within the "query-handler" tag. </para> <programlisting language="XML" role="XML"><query-handler class="org.exoplatform.services.jcr.impl.core.query.lucene.SearchIndex"> </programlisting> @@ -616,13 +616,13 @@ </programlisting> <para> - in <filename><replaceable>JPP_DIST</replaceable>/jboss-as/server/<replaceable>PROFILE</replaceable>/deploy/gatein.ear/02portal.war/WEB-INF/conf/jcr/repository-configuration.xml</filename> with the new class: + in <filename><replaceable>JPP_HOME</replaceable>/gatein/gatein.ear/portal.war/WEB-INF/conf/jcr/repository-configuration.xml</filename> with the new class: </para> <programlisting language="XML" role="XML"><query-handler class="mypackage.indexation.MySearchIndex> </programlisting> <para> - To configure an application to use a new analyzer, add the <parameter>analyzer</parameter> parameter to each query-handler configuration in <filename><replaceable>JPP_DIST</replaceable>/jboss-as/server/<replaceable>PROFILE</replaceable>/deploy/gatein.ear/02portal.war/WEB-INF/conf/jcr/repository-configuration.xml</filename>: + To configure an application to use a new analyzer, add the <parameter>analyzer</parameter> parameter to each query-handler configuration in <filename><replaceable>JPP_HOME</replaceable>/gatein/gatein.ear/portal.war/WEB-INF/conf/jcr/repository-configuration.xml</filename>: </para> <programlisting language="XML" role="XML"><xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="../../../../extras/Advanced_Development_JCR_search-configuration/default69.xml" parse="text"/></programlisting> <para> Modified: epp/docs/branches/6.0/Reference_Guide/en-US/modules/eXoJCR/jcr/jbosscache-configuration-templates.xml =================================================================== --- epp/docs/branches/6.0/Reference_Guide/en-US/modules/eXoJCR/jcr/jbosscache-configuration-templates.xml 2013-01-25 01:01:20 UTC (rev 9076) +++ epp/docs/branches/6.0/Reference_Guide/en-US/modules/eXoJCR/jcr/jbosscache-configuration-templates.xml 2013-01-25 02:15:12 UTC (rev 9077) @@ -70,7 +70,7 @@ <section id="sect-Reference_Guide-JBoss_Cache_configuration-Shipped_JBoss_Cache_configuration_templates"> <title>Shipped JBoss Cache configuration templates</title> <para> - The eXo JCR implementation is shipped with ready-to-use JBoss Cache configuration templates for JCR's components. They are located in <filename><replaceable>JPP_DIST</replaceable>/jboss-as/server/<replaceable>PROFILE</replaceable>/deploy/gatein.ear/02portal.war/WEB-INF/conf/jcr/jbosscache</filename> directory, inside either the <filename>cluster</filename> or <filename>local</filename> directory. + The eXo JCR implementation is shipped with ready-to-use JBoss Cache configuration templates for JCR's components. They are located in <filename><replaceable>JPP_HOME</replaceable>/gatein/gatein.ear/portal.war/WEB-INF/conf/jcr/jbosscache</filename> directory, inside either the <filename>cluster</filename> or <filename>local</filename> directory. </para> <section id="sect-Reference_Guide-Shipped_JBoss_Cache_configuration_templates-Data_container_template"> <title>Data container template</title> Modified: epp/docs/branches/6.0/Reference_Guide/en-US/modules/eXoJCR/jcr/searching/searching-repository-content.xml =================================================================== --- epp/docs/branches/6.0/Reference_Guide/en-US/modules/eXoJCR/jcr/searching/searching-repository-content.xml 2013-01-25 01:01:20 UTC (rev 9076) +++ epp/docs/branches/6.0/Reference_Guide/en-US/modules/eXoJCR/jcr/searching/searching-repository-content.xml 2013-01-25 02:15:12 UTC (rev 9077) @@ -8,7 +8,7 @@ <section id="sect-Reference_Guide-Searching_Repository_Content-Introduction"> <title>Introduction</title> <para> - You can find the JCR configuration file here: <filename><replaceable>JPP_DIST</replaceable>/jboss-as/server/<replaceable>PROFILE</replaceable>/deploy/gatein.ear/02portal.war/portal/WEB-INF/conf/jcr/repository-configuration.xml</filename>. + You can find the JCR configuration file here: <filename><replaceable>JPP_DIST</replaceable>/gatein/gatein.ear/portal.war/portal/WEB-INF/conf/jcr/repository-configuration.xml</filename>. </para> <para> Please refer to <xref linkend="chap-Reference_Guide-Search_Configuration"/> for more information about index configuration.

11 years, 3 months

1
0
0 / 0

gatein SVN: r9076 - in epp/docs/branches/6.0/Reference_Guide/en-US: modules/PortalDevelopment and 1 other directory.

by do-not-reply＠jboss.org

Author: jaredmorgs Date: 2013-01-24 20:01:20 -0500 (Thu, 24 Jan 2013) New Revision: 9076 Modified: epp/docs/branches/6.0/Reference_Guide/en-US/Revision_History.xml epp/docs/branches/6.0/Reference_Guide/en-US/modules/PortalDevelopment/DefaultPortalConfiguration.xml epp/docs/branches/6.0/Reference_Guide/en-US/modules/PortalDevelopment/DefaultPortalPermissionConfiguration.xml Log: BZ#903884 - Changes incorporated for https://docs.jboss.org/author/display/GTNPORTAL35/Default+Portal+Configur.... Ready for QE 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-01-25 00:13:45 UTC (rev 9075) +++ epp/docs/branches/6.0/Reference_Guide/en-US/Revision_History.xml 2013-01-25 01:01:20 UTC (rev 9076) @@ -8,6 +8,20 @@ <simpara> <revhistory> <revision> + <revnumber>6.0.0-35</revnumber> + <date>Fri Jan 25 2013</date> + <author> + <firstname>Jared</firstname> + <surname>Morgan</surname> + <email/> + </author> + <revdescription> + <simplelist> + <member>Changes incorporated for https://docs.jboss.org/author/display/GTNPORTAL35/Default+Portal+Configur.... Ready for QE.</member> + </simplelist> + </revdescription> + </revision> + <revision> <revnumber>6.0.0-34</revnumber> <date>Fri Jan 25 2013</date> <author> Modified: epp/docs/branches/6.0/Reference_Guide/en-US/modules/PortalDevelopment/DefaultPortalConfiguration.xml =================================================================== --- epp/docs/branches/6.0/Reference_Guide/en-US/modules/PortalDevelopment/DefaultPortalConfiguration.xml 2013-01-25 00:13:45 UTC (rev 9075) +++ epp/docs/branches/6.0/Reference_Guide/en-US/modules/PortalDevelopment/DefaultPortalConfiguration.xml 2013-01-25 01:01:20 UTC (rev 9076) @@ -5,6 +5,7 @@ ]> <chapter id="chap-Reference_Guide-Default_Portal_Configuration"> <title>Default Portal Configuration</title> + <remark>Source content: https://docs.jboss.org/author/display/GTNPORTAL35/Default+Portal+Configur...</remark> <section id="sect-Reference_Guide-Default_Portal_Configuration-Overview"> <title>Overview</title> <para> @@ -20,7 +21,7 @@ <section id="sect-Reference_Guide-Default_Portal_Configuration-Configuration"> <title>Configuration</title> <para> - The following example configuration can be found at: "<filename>02portal.war:/WEB-INF/conf/portal/portal-configuration.xml</filename>". + The following example configuration can be found at: <filename><replaceable>JPP_HOME</replaceable>/gatein/gatein.ear/portal.war/WEB-INF/conf/portal/portal-configuration.xml</filename>. </para> <programlisting language="XML" role="XML"><xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="../../extras/PortalDevelopment_DefaultPortalConfiguration/default143.xml" parse="text"/></programlisting> <para> @@ -33,40 +34,93 @@ <emphasis>Components</emphasis>, <emphasis>component-plugins</emphasis>, and <emphasis>init-params</emphasis> are explained in a later chapter of this document. </para> </section> - <section id="sect-Reference_Guide-Default_Portal_Configuration-Disabling_a_Portal"> -  - <title><remark>BZ#794416</remark>Disabling a Portal</title> - <para> + --> <title><remark>BZ#794416</remark>Disabling a Portal</title> + <para> Once you have created a custom portal that suits your needs, you may wish to disable a portal that is no longer required. </para> - - <task> - <title>Task: Disable a portal in EPP 5</title> - <tasksummary> - <para> + <task> + <title>Task: Disable a portal in EPP 5</title> + <tasksummary> + <para> The procedure below will show you how to disable an unused portal in a JBoss Portal Platform instance. </para> - </tasksummary> - <taskprerequisites> - <title>Prerequisites: </title> - <itemizedlist> - <listitem> - <para> + </tasksummary> + <taskprerequisites> + <title>Prerequisites: </title> + <itemizedlist> + <listitem> + <para> <remark>Are there any pre-reqs for this task?</remark> </para> - </listitem> - </itemizedlist> - </taskprerequisites> - <procedure> - <title></title> - <step> - <para> + </listitem> + </itemizedlist> + </taskprerequisites> + <procedure> + <title/> + <step> + <para> Add the following configuration to the <filename>configuration.xml</filename> of the custom extension in order to disable a portal: </para> -<programlisting language="XML" role="XML"><![CDATA[<?xml version="1.0" encoding="UTF-8"?> + <programlisting language="XML" role="XML"><![CDATA[<?xml version="1.0" encoding="UTF-8"?> <configuration xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.exoplaform.org/xml/ns/kernel_1_0.xsd http://www.exoplaform.org/xml/ns/kernel_1_1.xsd" xmlns="http://www.exoplaform.org/xml/ns/kernel_1_1.xsd"> @@ -97,17 +151,16 @@ </external-component-plugins> </configuration> ]]></programlisting> - </step> - </procedure> - <taskrelated> - <note> - <title></title> - <para> + </step> + </procedure> + <taskrelated> + <note> + <title/> + <para> Disabling the default <emphasis>portal</emphasis> container is possible as well, but some functions, such as WSRP, or Services Management, depend on the default portal container to be deployed, and will no longer work if this is disabled. </para> - </note> - </taskrelated> - </task> - </section> - + </note> + </taskrelated> + </task> + </section> </chapter> Modified: epp/docs/branches/6.0/Reference_Guide/en-US/modules/PortalDevelopment/DefaultPortalPermissionConfiguration.xml =================================================================== --- epp/docs/branches/6.0/Reference_Guide/en-US/modules/PortalDevelopment/DefaultPortalPermissionConfiguration.xml 2013-01-25 00:13:45 UTC (rev 9075) +++ epp/docs/branches/6.0/Reference_Guide/en-US/modules/PortalDevelopment/DefaultPortalPermissionConfiguration.xml 2013-01-25 01:01:20 UTC (rev 9076) @@ -8,7 +8,7 @@ <section id="sect-Reference_Guide-Portal_Default_Permission_Configuration-Overview"> <title>Overview</title> <para> - The default permission configuration for the portal is defined through the <literal>org.exoplatform.portal.config.UserACL</literal> component configuration in the <filename><replaceable>JPP_DIST</replaceable>/jboss-as/server/<replaceable>PROFILE</replaceable>/deploy/gatein.ear/02portal.war/WEB-INF/conf/portal/portal-configuration.xml</filename> file. + The default permission configuration for the portal is defined through the <literal>org.exoplatform.portal.config.UserACL</literal> component configuration in the <filename><replaceable>JPP_HOME</replaceable>/gatein/gatein.ear/portal.war/WEB-INF/conf/portal/portal-configuration.xml</filename> file. </para> <para> It defines eight permissions types:

11 years, 3 months

1
0
0 / 0

gatein SVN: r9075 - in epp/docs/branches/6.0/Reference_Guide/en-US: modules/AuthenticationAndIdentity and 1 other directory.

by do-not-reply＠jboss.org

Author: jaredmorgs Date: 2013-01-24 19:13:45 -0500 (Thu, 24 Jan 2013) New Revision: 9075 Modified: epp/docs/branches/6.0/Reference_Guide/en-US/Revision_History.xml epp/docs/branches/6.0/Reference_Guide/en-US/modules/AuthenticationAndIdentity/LDAP.xml Log: BZ#856453 - Incorporated all QE feedback from Tomas for LDAP. Ready for Verification. 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-01-24 22:14:24 UTC (rev 9074) +++ epp/docs/branches/6.0/Reference_Guide/en-US/Revision_History.xml 2013-01-25 00:13:45 UTC (rev 9075) @@ -7,7 +7,21 @@ <title>Revision History</title> <simpara> <revhistory> - <revision> + <revision> + <revnumber>6.0.0-34</revnumber> + <date>Fri Jan 25 2013</date> + <author> + <firstname>Jared</firstname> + <surname>Morgan</surname> + <email/> + </author> + <revdescription> + <simplelist> + <member>BZ#856453 - Incorporated all QE feedback from Tomas for LDAP. Ready for Verification.</member> + </simplelist> + </revdescription> + </revision> + <revision> <revnumber>6.0.0-33</revnumber> <date>Wed Jan 23 2013</date> <author> @@ -21,8 +35,7 @@ <member>Rebased changes for https://docs.jboss.org/author/display/GTNPORTAL35/Working+with+WSRP+exten...</member> </simplelist> </revdescription> - </revision> - + </revision> <revision> <revnumber>6.0.0-32</revnumber> <date>Wed Jan 23 2013</date> @@ -36,8 +49,8 @@ <member>BZ#886376 - Updated all Book_Info.xml files with consistent subtitle. Rebuilt for review..</member> </simplelist> </revdescription> - </revision> - <revision> + </revision> + <revision> <revnumber>6.0.0-31</revnumber> <date>Tue Jan 22 2013</date> <author> @@ -49,7 +62,7 @@ <simplelist> <member>Imported raw content for chapters for Password Encryption and PicketLink IDM integration.</member> <member>Rebased changes for https://docs.jboss.org/author/display/GTNPORTAL35/PicketLink+IDM+integration</member> - <member>Rebased changes for https://docs.jboss.org/author/display/GTNPORTAL35/Password+Encryption</member> + <member>Rebased changes for https://docs.jboss.org/author/display/GTNPORTAL35/Password+Encryption</member> </simplelist> </revdescription> </revision> Modified: epp/docs/branches/6.0/Reference_Guide/en-US/modules/AuthenticationAndIdentity/LDAP.xml =================================================================== --- epp/docs/branches/6.0/Reference_Guide/en-US/modules/AuthenticationAndIdentity/LDAP.xml 2013-01-24 22:14:24 UTC (rev 9074) +++ epp/docs/branches/6.0/Reference_Guide/en-US/modules/AuthenticationAndIdentity/LDAP.xml 2013-01-25 00:13:45 UTC (rev 9075) @@ -49,91 +49,6 @@ If you are using a third party directory server (<application>OpenDS</application>, <application>OpenLDAP</application> or <application>Microsoft Active Directory</application>), refer to the appropriate documentation for that product. </para> <para> - The following values provide an example of working configuration settings for the different Directory Servers: - </para> - <table> - <title/> - <tgroup cols="8"> - <colspec colname="1"/> - <colspec colname="2"/> - <colspec colname="3"/> - <colspec colname="4"/> - <colspec colname="5"/> - <colspec colname="6"/> - <colspec colname="7"/> - <colspec colname="8"/> - <spanspec namest="2" nameend="8" spanname="vspan"/> - <thead> - <row> - <entry> Directory Server </entry> - <entry spanname="vspan"> Value </entry> - </row> - </thead> - <tbody> - <row> - <entry/> - <entry> - <emphasis role="bold">root user Distinguished Name (DN)</emphasis> - </entry> - <entry> - <emphasis role="bold">Password</emphasis> - </entry> - <entry> - <emphasis role="bold">Port</emphasis> - </entry> - <entry> - <emphasis role="bold">Admin Port</emphasis> - </entry> - <entry> - <emphasis role="bold">Base DN</emphasis> - </entry> - <entry> - <emphasis role="bold">Database Population</emphasis> - </entry> - <entry> - <emphasis role="bold">SSO/TLS</emphasis> - </entry> - </row> - <row> - <entry> - <emphasis role="bold">RHDS and OpenDS</emphasis> - </entry> - <entry> cn=Directory Manager </entry> - <entry> password </entry> - <entry> 1389 </entry> - <entry> 4444 </entry> - <entry> dc=example,dc=com </entry> - <entry> "Only create the base entry" </entry> - <entry> no SSO, no TLS </entry> - </row> - <row> - <entry> - <emphasis role="bold">MSAD</emphasis> - </entry> - <entry> CN=Users </entry> - <entry/> - <entry/> - <entry/> - <entry/> - <entry/> - <entry/> - </row> - <row> - <entry> - <emphasis role="bold">OpenLDAP</emphasis> - </entry> - <entry> cn=Manager,dc=example,dc=com </entry> - <entry> secret </entry> - <entry> 1389 </entry> - <entry/> - <entry> dc=example,dc=com </entry> - <entry/> - <entry/> - </row> - </tbody> - </tgroup> - </table> - <para> These, and other appropriate settings, should be adjusted to suit your circumstances. </para> </step> @@ -150,8 +65,9 @@ </procedure> <section id="sect-Reference_Guide_eXo_JCR_1.14-LDAP_Integration-LDAP_in_Read-only_Mode"> <title>LDAP in Read-only Mode</title> - <para> - This section will show you how to add LDAP in read-only mode. This means that user data entries (both pre-existing, and newly added through the JBoss Portal Platform User Interface) will be consumed though the Directory Server and LDAP services, but written to the underlying database. The only exception is that passwords updated through the user interface will also be propagated into the appropriate LDAP entry. + <para>If LDAP is configured to operate in read-write mode, changes to user and group information made in the portal platform is written back to the directory server. </para> + <para>If LDAP is operating in read-only mode. existing user and group information is consumed from the directory server, and all new user data entries created using the Portal User Interface are stored in the portal database. </para> + <para>The only exception is that passwords updated through the user interface will also be propagated into the appropriate LDAP entry. </para> <procedure id="proc-LDAP-LDAP_read-only_Mode"> <title>Set up LDAP read-only Mode</title> @@ -358,7 +274,7 @@ <section id="sect-Reference_Guide_eXo_JCR_1.14-LDAP_Integration-LDAP_as_Default_Store"> <title>LDAP as Default Store</title> <para> - Follow the procedure below to set LDAP up as the default identity store for JBoss Portal Platform. All default accounts and some of groups that comes with JBoss Portal Platform will be created in the LDAP store. + Follow the procedure below to set LDAP up as the default identity store for JBoss Portal Platform. All default accounts and some of groups that come with JBoss Portal Platform will be created in the LDAP store. </para> <para> The LDAP server will be configured to store part of the JBoss Portal Platform group tree. This means that groups under specified part of the tree will be stored in directory server while all others will be stored in database. @@ -582,10 +498,10 @@ <term>providerURL</term> <listitem> <para> - The LDAP server connection URL. Formatted as "LDAP://localhost:<replaceable><PORT></replaceable>". The default setting is: <emphasis>LDAP://localhost:1389</emphasis>. + The LDAP server connection URL. Formatted as "ldap://<replaceable><HOST></replaceable>:<replaceable><PORT></replaceable>". The default setting is: <emphasis>ldap://localhost:1389</emphasis>. </para> <para> - <emphasis role="bold">MSAD</emphasis>: Should use SSL connection (LDAPs://xxx:636) for password update or creation to work. + <emphasis role="bold">MSAD</emphasis>: Should use SSL connection (ldaps://<replaceable><HOST></replaceable>:636) for password update or creation to work. </para> </listitem> </varlistentry> @@ -655,7 +571,7 @@ Comment #2: An additional option defines that nothing else (except password updates) should be written there. </para> <para> - All groups under <emphasis role="bold">/acme/roles</emphasis> will be stored in PicketLink IDM with the <emphasis role="bold">acme_roles_type</emphasis> group type name and groups under <emphasis role="bold">/acme/organization_units</emphasis> will be stored in PicketLink IDM with <emphasis role="bold">acme_ou_type group</emphasis> type name. + All groups under <emphasis role="bold">/acme/roles</emphasis> will be stored in PicketLink IDM with the <emphasis role="bold">acme_roles_type</emphasis> group type name and groups under <emphasis role="bold">/acme/organization_units</emphasis> will be stored in PicketLink IDM with <emphasis role="bold">acme_ou_type</emphasis> group type name. </para> <para> For MSAD, the <parameter>identity-object-types</parameter> values in <filename>picketlink-idm-msad-readonly-config.xml</filename> change to:

11 years, 3 months

1
0
0 / 0

gatein SVN: r9074 - in epp/docs/branches/6.0/Admin_Guide/en-US: images and 1 other directory.

by do-not-reply＠jboss.org

Author: jaredmorgs Date: 2013-01-24 17:14:24 -0500 (Thu, 24 Jan 2013) New Revision: 9074 Modified: epp/docs/branches/6.0/Admin_Guide/en-US/Revision_History.xml epp/docs/branches/6.0/Admin_Guide/en-US/chapter-5-Administration_and_Monitoring.xml epp/docs/branches/6.0/Admin_Guide/en-US/images/GateIn-RHQ-Plugin.png Log: BZ#856436 - Updated the JON plug-in graphic, and sent for QA review Modified: epp/docs/branches/6.0/Admin_Guide/en-US/Revision_History.xml =================================================================== --- epp/docs/branches/6.0/Admin_Guide/en-US/Revision_History.xml 2013-01-23 15:47:09 UTC (rev 9073) +++ epp/docs/branches/6.0/Admin_Guide/en-US/Revision_History.xml 2013-01-24 22:14:24 UTC (rev 9074) @@ -8,6 +8,20 @@ <simpara> <revhistory> <revision> + <revnumber>6.0.0-6</revnumber> + <date>Fri Jan 25 2013</date> + <author> + <firstname>Jared</firstname> + <surname>Morgan</surname> + <email/> + </author> + <revdescription> + <simplelist> + <member>BZ#856436 - Updated GateIn JON Plug-in screenshot.</member> + </simplelist> + </revdescription> + </revision> + <revision> <revnumber>6.0.0-5</revnumber> <date>Wed Jan 23 2013</date> <author> @@ -20,7 +34,7 @@ <member>BZ#886376 - Updated all Book_Info.xml files with consistent subtitle. Rebuilt for review..</member> </simplelist> </revdescription> - </revision> + </revision> <revision> <revnumber>6.0.0-4</revnumber> <date>Fri Nov 16 2012</date> Modified: epp/docs/branches/6.0/Admin_Guide/en-US/chapter-5-Administration_and_Monitoring.xml =================================================================== --- epp/docs/branches/6.0/Admin_Guide/en-US/chapter-5-Administration_and_Monitoring.xml 2013-01-23 15:47:09 UTC (rev 9073) +++ epp/docs/branches/6.0/Admin_Guide/en-US/chapter-5-Administration_and_Monitoring.xml 2013-01-24 22:14:24 UTC (rev 9074) @@ -8,6 +8,7 @@ <para>JBoss Portal Platform provides a JBoss Operations Network plug-in (<firstterm>GateIn JON Plug-in</firstterm>) to assist with monitoring the platform.</para> <para>The plug-in captures application/portlet and site statistics. A different set of statistics are collected depending on the context of each portlet. <xref linkend="fig-GateIn_JON_Plug-in_Interface"/> shows the basic JON interface.</para> <para>Follow the download and installation instructions in the <citetitle>Installation Guide</citetitle> to activate Administration and Monitoring.</para> + <remark>BZ#856436 Updated screenshot with Nick Scavelli's provided screenshot from the Confluence docs.</remark> <figure id="fig-GateIn_JON_Plug-in_Interface"> <title>GateIn JON Plug-in Interface</title> <mediaobject> @@ -15,7 +16,7 @@ <imagedata contentwidth="660px" fileref="images/GateIn-RHQ-Plugin.png"/> </imageobject> <textobject> - <para>Screenshot of the JON console view, with the Portlets and Sites views expanded.</para> + <para>Screenshot of the JON console view, with the with the GateIn AS7 Plug-in highlighted.</para> </textobject> </mediaobject> </figure> Modified: epp/docs/branches/6.0/Admin_Guide/en-US/images/GateIn-RHQ-Plugin.png =================================================================== (Binary files differ)

11 years, 3 months

1
0
0 / 0

gatein SVN: r9073 - in epp/docs/branches/6.0/Reference_Guide/en-US: modules and 1 other directories.

by do-not-reply＠jboss.org

Author: aakanksha_writer Date: 2013-01-23 10:47:09 -0500 (Wed, 23 Jan 2013) New Revision: 9073 Modified: epp/docs/branches/6.0/Reference_Guide/en-US/Revision_History.xml epp/docs/branches/6.0/Reference_Guide/en-US/modules/PortalDevelopment/DefaultPortalNavigationConfiguration.xml epp/docs/branches/6.0/Reference_Guide/en-US/modules/WSRP.xml Log: Updated chapter Portal Development and WSRP extensions 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-01-23 00:39:56 UTC (rev 9072) +++ epp/docs/branches/6.0/Reference_Guide/en-US/Revision_History.xml 2013-01-23 15:47:09 UTC (rev 9073) @@ -7,6 +7,22 @@ <title>Revision History</title> <simpara> <revhistory> + <revision> + <revnumber>6.0.0-33</revnumber> + <date>Wed Jan 23 2013</date> + <author> + <firstname>Aakanksha</firstname> + <surname>Singh</surname> + <email/> + </author> + <revdescription> + <simplelist> + <member>Rebased changes for https://docs.jboss.org/author/display/GTNPORTAL35/Portal+Navigation+Confi... </member> + <member>Rebased changes for https://docs.jboss.org/author/display/GTNPORTAL35/Working+with+WSRP+exten...</member> + </simplelist> + </revdescription> + </revision> + <revision> <revnumber>6.0.0-32</revnumber> <date>Wed Jan 23 2013</date> Modified: epp/docs/branches/6.0/Reference_Guide/en-US/modules/PortalDevelopment/DefaultPortalNavigationConfiguration.xml =================================================================== --- epp/docs/branches/6.0/Reference_Guide/en-US/modules/PortalDevelopment/DefaultPortalNavigationConfiguration.xml 2013-01-23 00:39:56 UTC (rev 9072) +++ epp/docs/branches/6.0/Reference_Guide/en-US/modules/PortalDevelopment/DefaultPortalNavigationConfiguration.xml 2013-01-23 15:47:09 UTC (rev 9073) @@ -166,16 +166,7 @@ </warning> </listitem> </varlistentry> - <varlistentry> - <term>Subnodes</term> - <listitem> - <para> - Subnodes can also be created using the following XML structure - </para> - <programlisting language="XML" role="XML"><xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="../../extras/PortalDevelopment_DefaultPortalNavigationConfiguration/subpage.xml" parse="text"/></programlisting> - </listitem> - </varlistentry> - <varlistentry> + <varlistentry> <term>pages.xml</term> <listitem> <para> @@ -184,7 +175,7 @@ <para> Each application can decide whether to render the portlet border, the window state, the icons, or the portlet mode. </para> - <programlisting language="XML" role="XML"><xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="../../extras/PortalDevelopment_DefaultPortalNavigationConfiguration/pages.xml" parse="text"/></programlisting> + </listitem> </varlistentry> </variablelist> @@ -216,5 +207,5 @@ The example below shows a dashboard with all of the default gadgets included, as well as an extra currency converter gadget sourced from <ulink url="http://www.google.com/ig/directory?synd=open" type="http">Google Gadgets</ulink>. </para> <programlisting language="XML" role="XML"><xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="../../extras/PortalDevelopment_DefaultPortalNavigationConfiguration/gadgets.xml" parse="text"/></programlisting> - </section> + </section> </chapter> Modified: epp/docs/branches/6.0/Reference_Guide/en-US/modules/WSRP.xml =================================================================== --- epp/docs/branches/6.0/Reference_Guide/en-US/modules/WSRP.xml 2013-01-23 00:39:56 UTC (rev 9072) +++ epp/docs/branches/6.0/Reference_Guide/en-US/modules/WSRP.xml 2013-01-23 15:47:09 UTC (rev 9073) @@ -1814,7 +1814,7 @@ </ulink> and <ulink url="https://github.com/gatein/gatein-wsrp/blob/master/producer/src/main/java/..."> - <classname>org.gatein.registration.policies.RegistrationPropertyValidator</classname> + <classname>org.gatein.registration.policies.RegistrationPropertyValidator</classname> </ulink> for more details on what is expected of each method. </para> @@ -1824,7 +1824,7 @@ <title>DefaultRegistrationPolicy</title> <mediaobject> <imageobject> - <imagedata fileref="images/WSRP/producer_default.png" width="666"/> + <imagedata width="666" fileref="images/WSRP/producer_default.png"/> </imageobject> </mediaobject> </figure> @@ -1877,4 +1877,316 @@ </para> </section> </section> + <section> + <title>Working with WSRP Extensions</title> + <section> + <title>Overview</title> + <para> + The WSRP specifications allows for implementations to extend the protocol using + <ulink url="http://docs.oasis-open.org/wsrp/v2/wsrp-2.0-spec-os-01.html#_Extension">Extensions</ulink> + . GateIn Portal, as of its WSRP implementation version 2.2.0, provides a way for client code (e.g. portlets) to interact with such extensions in the form of several classes and interfaces gathered within the + <ulink url="https://github.com/gatein/gatein-wsrp/tree/master/api/src/main/java/org/g..."><code>org.gatein.wsrp.api.extensions</code> package </ulink> + , the most important ones being + <code>InvocationHandlerDelegate</code> + , + <code>ConsumerExtensionAccessor</code> + and + <code>ProducerExtensionAccessor</code> + . + </para> + <para> + To be able to use this API, you will need to include the + <code>wsrp-integration-api-$WSRP_VERSION.jar</code> + file to your project, where + <code>$WSRP_VERSION</code> + is the version of the GateIn Portal WSRP implementation you wish to use, 2.2.2.Final being the current one. This can be done by adding the following dependency to your maven project: + </para> + <informalexample> + <programlisting> +<dependency> + <groupId>org.gatein.wsrp</groupId> + <artifactId>wsrp-integration-api</artifactId> + <version>$WSRP_VERSION</version> +</dependency> +</programlisting> + </informalexample> + <section> + <title>InvocationHandlerDelegate infrastructure</title> + <para> + Using the + <code>InvocationHandlerDelegate</code> + infrastructure, custom behavior can now be inserted on either consumer or producer sides to enrich WSRP applications before and/or after portlet requests and/or responses. Please refer to the Javadoc for + <ulink url="https://github.com/gatein/gatein-wsrp/blob/master/api/src/main/java/org/g..."> + <code>org.gatein.wsrp.api.extensions.InvocationHandlerDelegate</code> + </ulink> + for more details on this interface and how to implement it. + </para> + <warning> + <para> + Since + <code>InvocationHandlerDelegate</code> + is a very generic interface, it could potentially be used for more than simply working with WSRP extensions. Moreover, since it has access to internal GateIn Portal classes, it is important to be treat access to these internal classes as + <emphasis role="strong">read-only</emphasis> + to prevent any un-intentional side-effects. + </para> + </warning> + </section> + <section> + <title>Injecting InvocationHandlerDelegate implementations</title> + <para> + Implementations of + <code>InvocationHandlerDelegate</code> + <emphasis role="strong">must</emphasis> + follow the same constraints as + <code>RegistrationPolicy</code> + implementations as detailed in + <ulink url="https://docs.jboss.org/author/pages/viewpage.action?pageId=54264625_Confi...">Customization of Registration handling behavior</ulink> + section of the + <ulink url="https://docs.jboss.org/author/pages/viewpage.action?pageId=54264625">Configuring GateIn's WSRP Producer</ulink> + chapter, in essence, they + <emphasis role="strong">must</emphasis> + follow the Java + <ulink url="http://docs.oracle.com/javase/7/docs/api/java/util/ServiceLoader.html"> + <code>ServiceLoader</code> + </ulink> + architectural pattern and be deployed in the appropriate + <code>$JBOSS_HOME/gatein/extensions</code> + directory. + </para> + <para> + You can specify only one + <code>InvocationHandlerDelegate</code> + implementation per side: one implementation for the consumer and another one for the producer. This is accomplished by passing the fully classified class name to the appropriate system property when the portal is started: + </para> + <informaltable> + <tgroup cols="2"> + <thead> + <row> + <entry> + <para>WSRP side</para> + </entry> + <entry> + <para>System property</para> + </entry> + </row> + </thead> + <tbody> + <row> + <entry> + <para>consumer</para> + </entry> + <entry> + <para>org.gatein.wsrp.consumer.handlers.delegate</para> + </entry> + </row> + <row> + <entry> + <para>producer</para> + </entry> + <entry> + <para>org.gatein.wsrp.producer.handlers.delegate</para> + </entry> + </row> + </tbody> + </tgroup> + </informaltable> + <section id="sid-55477864_WorkingwithWSRPextensions-Example"> + <title>Example</title> + <informalexample> + <programlisting>./standalone.sh -Dorg.gatein.wsrp.consumer.handlers.delegate=com.example.FooInvocationHandlerDelegate</programlisting> + </informalexample> + <para> + will inject the + <code>com.example.FooInvocationHandlerDelegate</code> + class on the consumer side, assuming that class implements the + <code>org.gatein.wsrp.api.extensions.InvocationHandlerDelegate</code> + interface and is packaged and deployed appropriately as explained above. + </para> + </section> + </section> + <section id="sid-55477864_WorkingwithWSRPextensions-Accessingextensionsfromclientcode"> + <title>Accessing extensions from client code</title> + <para> + You can access extensions from client code using + <code>ConsumerExtensionAccessor</code> + and + <code>ProducerExtensionAccessor</code> + on the consumer and producer, respectively. Each interface provides several methods but you should only have to ever call two of them on each, as shown in the following table: + </para> + <informaltable> + <tgroup cols="2"> + <thead> + <row> + <entry> + <para>Interface</para> + </entry> + <entry> + <para>Relevant methods</para> + </entry> + </row> + </thead> + <tbody> + <row> + <entry> + <para> + <code>ConsumerExtensionAccessor</code> + </para> + </entry> + <entry> + <itemizedlist> + <listitem> + <para> + <code>public void addRequestExtension(Class targetClass, Object extension)</code> + </para> + </listitem> + <listitem> + <para> + <code>public List<UnmarshalledExtension> getResponseExtensionsFrom(Class responseClass)</code> + </para> + </listitem> + </itemizedlist> + </entry> + </row> + <row> + <entry> + <para> + <code>ProducerExtensionAccessor</code> + </para> + </entry> + <entry> + <itemizedlist> + <listitem> + <para> + <code>List<UnmarshalledExtension> getRequestExtensionsFor(Class targetClass)</code> + </para> + </listitem> + <listitem> + <para> + <code>void addResponseExtension(Class wsrpResponseClass, Object extension)</code> + </para> + </listitem> + </itemizedlist> + </entry> + </row> + </tbody> + </tgroup> + </informaltable> + <para>Please refer to the Javadoc for these classes for more details.</para> + <note> + <para>We currently only support adding and accessing extensions from a core subset of WSRP classes pertaining to markup, interaction, resource or event requests and responses, as follows:</para> + <informaltable> + <tgroup cols="2"> + <thead> + <row> + <entry> + <para>Request classes</para> + </entry> + <entry> + <para>Response classes</para> + </entry> + </row> + </thead> + <tbody> + <row> + <entry> + <para> + <code>org.oasis.wsrp.v2.InteractionParams</code> + </para> + </entry> + <entry> + <para> + <code>org.oasis.wsrp.v2.MarkupResponse</code> + </para> + </entry> + </row> + <row> + <entry> + <para> + <code>org.oasis.wsrp.v2.EventParams</code> + </para> + </entry> + <entry> + <para> + <code>org.oasis.wsrp.v2.BlockingInteractionResponse</code> + </para> + </entry> + </row> + <row> + <entry> + <para> + <code>org.oasis.wsrp.v2.MarkupParams</code> + </para> + </entry> + <entry> + <para> + <code>org.oasis.wsrp.v2.HandleEventsResponse</code> + </para> + </entry> + </row> + <row> + <entry> + <para> + <code>org.oasis.wsrp.v2.ResourceParams</code> + </para> + </entry> + <entry> + <para> + <code>org.oasis.wsrp.v2.ResourceResponse</code> + </para> + </entry> + </row> + </tbody> + </tgroup> + </informaltable> + </note> + <note> + <para> + We + <emphasis role="strong">strongly</emphasis> + recommend that you use + <code>org.w3c.dom.Element</code> + values as extensions for interoperability purposes. + </para> + </note> + </section> + </section> + <section> +<title>Example implementation</title> + <para> + We also provide a complete, end-to-end example to get you started, which you can find at + <ulink url="https://github.com/gatein/gatein-wsrp/tree/master/examples/invocation-han..."/> + . This example shows how + <code>ExampleConsumerInvocationHandlerDelegate</code> + , a consumer-side + <code>InvocationHandlerDelegate</code> + implementation, can add information extracted from the consumer and pass it along to the producer, working in conjunction with + <code>ExampleProducerInvocationHandlerDelegate</code> + , the associated producer-side + <code>InvocationHandlerDelegate</code> + , to establish a round-trip communication channel outside of the standard WSRP protocol, implementing the following scenario: + </para> + <itemizedlist> + <listitem> + <para> + <code>ExampleConsumerInvocationHandlerDelegate</code> + attaches to the consumer to add the current session id as an extension to render requests sent to the producer. + </para> + </listitem> + <listitem> + <para> + <code>ExampleProducerInvocationHandlerDelegate</code> + provides the counterpart of + <code>ExampleConsumerInvocationHandlerDelegate</code> + on the producer. It checks incoming render requests for potential extensions matching what + <code>ExampleConsumerInvocationHandlerDelegate</code> + sends and adds an extension of its own to the render response so that the consumer-side delegate can know that the information it passed was properly processed. + </para> + </listitem> + </itemizedlist> + <sidebar> + <para>To activate the InvocationHandlerDelegates on both the consumer and producer, start your GateIn Portal instance as follows:</para> + </sidebar> +</section> + + </section> </chapter>

11 years, 3 months

1
0
0 / 0

gatein SVN: r9072 - in epp/docs/branches/6.0: Developer_Guide/en-US and 4 other directories.

by do-not-reply＠jboss.org

Author: jaredmorgs Date: 2013-01-22 19:39:56 -0500 (Tue, 22 Jan 2013) New Revision: 9072 Modified: epp/docs/branches/6.0/Admin_Guide/en-US/Book_Info.xml epp/docs/branches/6.0/Admin_Guide/en-US/Revision_History.xml epp/docs/branches/6.0/Developer_Guide/en-US/Book_Info.xml epp/docs/branches/6.0/Developer_Guide/en-US/Revision_History.xml epp/docs/branches/6.0/Installation_Guide/DON'T_EDIT_THIS_SOURCE epp/docs/branches/6.0/Migration_Notes/en-US/Revision_History.xml epp/docs/branches/6.0/Reference_Guide/en-US/Book_Info.xml epp/docs/branches/6.0/Reference_Guide/en-US/Revision_History.xml epp/docs/branches/6.0/User_Guide/en-US/Book_Info.xml epp/docs/branches/6.0/User_Guide/en-US/Revision_History.xml Log: BZ#886376 - Updated all Book_Info.xml files with consistent subtitle. Rebuilt for review. Modified: epp/docs/branches/6.0/Admin_Guide/en-US/Book_Info.xml =================================================================== --- epp/docs/branches/6.0/Admin_Guide/en-US/Book_Info.xml 2013-01-22 05:18:26 UTC (rev 9071) +++ epp/docs/branches/6.0/Admin_Guide/en-US/Book_Info.xml 2013-01-23 00:39:56 UTC (rev 9072) @@ -5,7 +5,7 @@ ]> <bookinfo id="book-Admin_Guide-Admin_Guide"> <title>Administration Guide</title> - <subtitle>for use with JBoss Portal Platform 6 and it's patch releases.</subtitle> + <subtitle>for use with JBoss Portal Platform 6 and its patch releases.</subtitle> <productname>JBoss Portal Platform</productname> <productnumber>6</productnumber> <edition>6.0.0</edition> Modified: epp/docs/branches/6.0/Admin_Guide/en-US/Revision_History.xml =================================================================== --- epp/docs/branches/6.0/Admin_Guide/en-US/Revision_History.xml 2013-01-22 05:18:26 UTC (rev 9071) +++ epp/docs/branches/6.0/Admin_Guide/en-US/Revision_History.xml 2013-01-23 00:39:56 UTC (rev 9072) @@ -8,6 +8,20 @@ <simpara> <revhistory> <revision> + <revnumber>6.0.0-5</revnumber> + <date>Wed Jan 23 2013</date> + <author> + <firstname>Jared</firstname> + <surname>Morgan</surname> + <email/> + </author> + <revdescription> + <simplelist> + <member>BZ#886376 - Updated all Book_Info.xml files with consistent subtitle. Rebuilt for review..</member> + </simplelist> + </revdescription> + </revision> + <revision> <revnumber>6.0.0-4</revnumber> <date>Fri Nov 16 2012</date> <author> Modified: epp/docs/branches/6.0/Developer_Guide/en-US/Book_Info.xml =================================================================== --- epp/docs/branches/6.0/Developer_Guide/en-US/Book_Info.xml 2013-01-22 05:18:26 UTC (rev 9071) +++ epp/docs/branches/6.0/Developer_Guide/en-US/Book_Info.xml 2013-01-23 00:39:56 UTC (rev 9072) @@ -5,7 +5,7 @@ ]> <bookinfo id="book-Developer_Guide-Developer_Guide"> <title>Developer Guide</title> - <subtitle>for use with JBoss Portal Platform 6.</subtitle> + <subtitle>for use with JBoss Portal Platform 6 and its patch releases.</subtitle> <productname>JBoss Portal Platform</productname> <productnumber>6</productnumber> <edition>6.0.0</edition> Modified: epp/docs/branches/6.0/Developer_Guide/en-US/Revision_History.xml =================================================================== --- epp/docs/branches/6.0/Developer_Guide/en-US/Revision_History.xml 2013-01-22 05:18:26 UTC (rev 9071) +++ epp/docs/branches/6.0/Developer_Guide/en-US/Revision_History.xml 2013-01-23 00:39:56 UTC (rev 9072) @@ -5,6 +5,20 @@ <simpara> <revhistory> <revision> + <revnumber>6.0.0-7</revnumber> + <date>Wed Jan 23 2013</date> + <author> + <firstname>Jared</firstname> + <surname>Morgan</surname> + <email/> + </author> + <revdescription> + <simplelist> + <member>BZ#886376 - Updated all Book_Info.xml files with consistent subtitle. Rebuilt for review..</member> + </simplelist> + </revdescription> + </revision> + <revision> <revnumber>6.0.0-6</revnumber> <date>Fri Jan 18 2013</date> <author> Modified: epp/docs/branches/6.0/Installation_Guide/DON'T_EDIT_THIS_SOURCE =================================================================== --- epp/docs/branches/6.0/Installation_Guide/DON'T_EDIT_THIS_SOURCE 2013-01-22 05:18:26 UTC (rev 9071) +++ epp/docs/branches/6.0/Installation_Guide/DON'T_EDIT_THIS_SOURCE 2013-01-23 00:39:56 UTC (rev 9072) @@ -1,3 +1,7 @@ -This is not the canonical source for this documentation. +This guide is a PressGang CCMS-managed document. -The guide is a PressGang CCMS book. +The Content Spec Processor Map for this document is saved in PressGang CCMS. + +The topic ID you need to pull is: 11942 + +Refer to the CSProcessor User Guide on engineering.redhat.com/docs for more information. Modified: epp/docs/branches/6.0/Migration_Notes/en-US/Revision_History.xml =================================================================== (Binary files differ) Modified: epp/docs/branches/6.0/Reference_Guide/en-US/Book_Info.xml =================================================================== --- epp/docs/branches/6.0/Reference_Guide/en-US/Book_Info.xml 2013-01-22 05:18:26 UTC (rev 9071) +++ epp/docs/branches/6.0/Reference_Guide/en-US/Book_Info.xml 2013-01-23 00:39:56 UTC (rev 9072) @@ -5,7 +5,7 @@ ]> <bookinfo id="book-Reference_Guide-Reference_Guide"> <title>Reference Guide</title> - <subtitle>for use with JBoss Portal Platform 6.</subtitle> + <subtitle>for use with JBoss Portal Platform 6 and its patch releases.</subtitle> <productname>JBoss Portal Platform</productname> <productnumber>6</productnumber> <edition>6.0.0</edition> 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-01-22 05:18:26 UTC (rev 9071) +++ epp/docs/branches/6.0/Reference_Guide/en-US/Revision_History.xml 2013-01-23 00:39:56 UTC (rev 9072) @@ -7,9 +7,23 @@ <title>Revision History</title> <simpara> <revhistory> + <revision> + <revnumber>6.0.0-32</revnumber> + <date>Wed Jan 23 2013</date> + <author> + <firstname>Jared</firstname> + <surname>Morgan</surname> + <email/> + </author> + <revdescription> + <simplelist> + <member>BZ#886376 - Updated all Book_Info.xml files with consistent subtitle. Rebuilt for review..</member> + </simplelist> + </revdescription> + </revision> <revision> <revnumber>6.0.0-31</revnumber> - <date>Thu Jan 22 2013</date> + <date>Tue Jan 22 2013</date> <author> <firstname>Aakanksha</firstname> <surname>Singh</surname> Modified: epp/docs/branches/6.0/User_Guide/en-US/Book_Info.xml =================================================================== --- epp/docs/branches/6.0/User_Guide/en-US/Book_Info.xml 2013-01-22 05:18:26 UTC (rev 9071) +++ epp/docs/branches/6.0/User_Guide/en-US/Book_Info.xml 2013-01-23 00:39:56 UTC (rev 9072) @@ -5,7 +5,7 @@ ]> <bookinfo id="book-User_Guide-User_Guide"> <title>User Guide</title> - <subtitle>for use with JBoss Portal Platform 6 and it's patch releases.</subtitle> + <subtitle>for use with JBoss Portal Platform 6 and its patch releases.</subtitle> <productname>JBoss Portal Platform</productname> <productnumber>6</productnumber> <edition>6.0.0</edition> Modified: epp/docs/branches/6.0/User_Guide/en-US/Revision_History.xml =================================================================== --- epp/docs/branches/6.0/User_Guide/en-US/Revision_History.xml 2013-01-22 05:18:26 UTC (rev 9071) +++ epp/docs/branches/6.0/User_Guide/en-US/Revision_History.xml 2013-01-23 00:39:56 UTC (rev 9072) @@ -7,6 +7,20 @@ <title>Revision History</title> <simpara> <revhistory> + <revision> + <revnumber>6.0.0-10</revnumber> + <date>Wed Jan 23 2013</date> + <author> + <firstname>Jared</firstname> + <surname>Morgan</surname> + <email/> + </author> + <revdescription> + <simplelist> + <member>BZ#886376 - Updated all Book_Info.xml files with consistent subtitle. Rebuilt for review..</member> + </simplelist> + </revdescription> + </revision> <revision> <revnumber>6.0.0-9</revnumber> <date>Mon Dec 06 2012</date>

11 years, 3 months

1
0
0 / 0

gatein SVN: r9071 - in epp/docs/branches/6.0/Reference_Guide/en-US: modules/AuthenticationAndIdentity and 1 other directory.

by do-not-reply＠jboss.org

Author: aakanksha_writer Date: 2013-01-22 00:18:26 -0500 (Tue, 22 Jan 2013) New Revision: 9071 Modified: epp/docs/branches/6.0/Reference_Guide/en-US/Revision_History.xml epp/docs/branches/6.0/Reference_Guide/en-US/modules/AuthenticationAndIdentity/BackendConfiguration.xml epp/docs/branches/6.0/Reference_Guide/en-US/modules/AuthenticationAndIdentity/PasswordEncryption.xml Log: Updated Chapter Password Encryption and 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-01-22 05:16:43 UTC (rev 9070) +++ epp/docs/branches/6.0/Reference_Guide/en-US/Revision_History.xml 2013-01-22 05:18:26 UTC (rev 9071) @@ -7,6 +7,22 @@ <title>Revision History</title> <simpara> <revhistory> + <revision> + <revnumber>6.0.0-31</revnumber> + <date>Thu Jan 22 2013</date> + <author> + <firstname>Aakanksha</firstname> + <surname>Singh</surname> + <email/> + </author> + <revdescription> + <simplelist> + <member>Imported raw content for chapters for Password Encryption and PicketLink IDM integration.</member> + <member>Rebased changes for https://docs.jboss.org/author/display/GTNPORTAL35/PicketLink+IDM+integration</member> + <member>Rebased changes for https://docs.jboss.org/author/display/GTNPORTAL35/Password+Encryption</member> + </simplelist> + </revdescription> + </revision> <revision> <revnumber>6.0.0-30</revnumber> <date>Thu Jan 17 2013</date> Modified: epp/docs/branches/6.0/Reference_Guide/en-US/modules/AuthenticationAndIdentity/BackendConfiguration.xml =================================================================== --- epp/docs/branches/6.0/Reference_Guide/en-US/modules/AuthenticationAndIdentity/BackendConfiguration.xml 2013-01-22 05:16:43 UTC (rev 9070) +++ epp/docs/branches/6.0/Reference_Guide/en-US/modules/AuthenticationAndIdentity/BackendConfiguration.xml 2013-01-22 05:18:26 UTC (rev 9071) @@ -1,4 +1,5 @@ <?xml version='1.0' encoding='UTF-8'?> + <!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN" "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" [ <!ENTITY % BOOK_ENTITIES SYSTEM "../../Reference_Guide.ent"> %BOOK_ENTITIES; @@ -389,4 +390,357 @@ <programlisting language="XML" role="XML"><xi:include href="../../extras/Authentication_Identity_BackendConfiguration/default97.xml" parse="text" xmlns:xi="http://www.w3.org/2001/XInclude" /></programlisting> - </section> --></chapter> + </section> --> + +<section id="sid-54264613_PicketLinkIDMintegration-Configurationfiles"> + + <title>Configuration files</title> + <para> + The main configuration file is + <code>JBOSS_HOME/gatein/gatein.ear/portal.war/WEB-INF/conf/organization/idm-configuration.xml</code> + : + </para> + <informalexample> + <programlisting><configuration xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" + xsi:schemaLocation="http://www.exoplaform.org/xml/ns/kernel_1_2.xsd http://www.exoplaform.org/xml/ns/kernel_1_2.xsd" + xmlns="http://www.exoplaform.org/xml/ns/kernel_1_2.xsd"> + + <component> + <key>org.exoplatform.services.organization.idm.PicketLinkIDMService</key> + <type>org.exoplatform.services.organization.idm.PicketLinkIDMServiceImpl</type> + <init-params> + <value-param> + <name>config</name> + <value>war:/conf/organization/idm-config.xml</value> + </value-param> + <value-param> + <name>portalRealm</name> + <value>realm${container.name.suffix}</value> + </value-param> + </init-params> + </component> + + + <component> + <key>org.exoplatform.services.organization.OrganizationService</key> + <type>org.exoplatform.services.organization.idm.PicketLinkIDMOrganizationServiceImpl</type> + <init-params> + <object-param> + <name>configuration</name> + <object type="org.exoplatform.services.organization.idm.Config"> + <field name="useParentIdAsGroupType"> + <boolean>true</boolean> + </field> + + <field name="forceMembershipOfMappedTypes"> + <boolean>true</boolean> + </field> + + <field name="pathSeparator"> + <string>.</string> + </field> + + <field name="rootGroupName"> + <string>GTN_ROOT_GROUP</string> + </field> + + <field name="groupTypeMappings"> + <map type="java.util.HashMap"> + <entry> + <key><string>/</string></key> + <value><string>root_type</string></value> + </entry> + +  +  + + </map> + </field> + + <field name="associationMembershipType"> + <string>member</string> + </field> + + <field name="ignoreMappedMembershipType"> + <boolean>false</boolean> + </field> + </object> + </object-param> + </init-params> + + + </component> + +</configuration> +</programlisting> + </informalexample> + <section id="sid-54264613_PicketLinkIDMintegration-PicketlinkIDMServiceImpl"> + + <title>PicketlinkIDMServiceImpl</title> + <para> + The + <code>org.exoplatform.services.organization.idm.PicketLinkIDMServiceImpl</code> + service has the following options: + </para> + <itemizedlist> + <listitem> + <para> + <code>config</code> + (value-param) The PicketLink IDM configuration file. + </para> + </listitem> + <listitem> + <para> + <code>hibernate.properties</code> + (properties-param) A list of hibernate properties used to create SessionFactory that will be injected to JBoss Identity IDM configuration registry. + </para> + </listitem> + <listitem> + <para> + <code>hibernate.annotations</code> + A list of annotated classes that will be added to Hibernate configuration. + </para> + </listitem> + <listitem> + <para> + <code>hibernate.mappings</code> + A list of + <code>.xml</code> + files that will be added to hibernate configuration as mapping files. + </para> + </listitem> + <listitem> + <para> + <code>jndiName</code> + (value-param) If the 'config' parameter is not provided, this parameter will be used to perform JNDI lookup for + <code>IdentitySessionFactory</code> + . + </para> + </listitem> + <listitem> + <para> + <code>portalRealm</code> + (value-param) The realm name that should be used to obtain proper + <code>IdentitySession</code> + . The default is + <code>'PortalRealm'</code> + . + </para> + </listitem> + <listitem> + <para> + <code>apiCacheConfig</code> + (value-param) The infinispan configuration file with cache configuration for Picketlink IDM API. It's different for cluster and non-cluster because infinispan needs to be replicated in cluster environment. + </para> + </listitem> + <listitem> + <para> + <code>storeCacheConfig</code> + (value-param) + + The infinispan configuration file with cache configuration for Picketlink IDM IdentityStore. Actually it's used only for LDAP store (not used with default DB configuration). It's different for cluster and non-cluster because infinispan needs to be replicated in cluster environment. + </para> + </listitem> + </itemizedlist> + </section> + <section id="sid-54264613_PicketLinkIDMintegration-PicketlinkIDMOrganizationServiceImpl"> + + <title>PicketlinkIDMOrganizationServiceImpl</title> + <para> + The + <code>org.exoplatform.services.organization.idm.PicketLinkIDMOrganizationServiceImpl</code> + key is a main entrypoint implementing + <code>org.exoplatform.services.organization.OrganizationService</code> + and is dependent on + <code>org.exoplatform.services.organization.idm.PicketLinkIDMService</code> + . + </para> + <para> + The + <code>org.exoplatform.services.organization.idm.PicketLinkIDMOrganizationServiceImpl</code> + service has the following options defined as fields of object-param of the + <code>org.exoplatform.services.organization.idm.Config</code> + type: + </para> + <itemizedlist> + <listitem> + <para> + <code>defaultGroupType</code> + The name of the PicketLink IDM GroupType that will be used to store groups. The default is + <code>'GTN_GROUP_TYPE'</code> + . + </para> + </listitem> + <listitem> + <para> + <code>rootGroupName</code> + The name of the PicketLink IDM Group that will be used as a root parent. The default is + <code>'GTN_ROOT_GROUP'</code> + . + </para> + </listitem> + <listitem> + <para> + <code>passwordAsAttribute</code> + This parameter specifies if a password should be stored using PicketLink IDM Credential object or as a plain attribute. The default is + <code>false</code> + . + </para> + </listitem> + <listitem> + <para> + <code>useParentIdAsGroupType</code> + This parameter stores the parent ID path as a group type in PicketLink IDM for any IDs not mapped with a specific type in 'groupTypeMappings'. If this option is set to + <code>false</code> + , and no mappings are provided under 'groupTypeMappings', then only one group with the given name can exist in the portal group tree. + </para> + </listitem> + <listitem> + <para> + <code>pathSeparator</code> + When 'userParentIdAsGroupType is set to + <code>true</code> + , this value will be used to replace all "/" characters in IDs. The "/" character is not allowed to be used in group type name in PicketLink IDM. + </para> + </listitem> + <listitem> + <para> + <code>associationMembershipType</code> + If this option is used, then each Membership, created with MembrshipType that is equal to the value specified here, will be stored in PicketLink IDM as simple Group-User association. + </para> + </listitem> + <listitem> + <para> + <code>groupTypeMappings</code> + This parameter maps groups added with portal API as children of a given group ID, and stores them with a given group type name in PicketLink IDM. + + If the parent ID ends with "/*", then all child groups will have the mapped group type. Otherwise, only direct (first level) children will use this type. + + This can be leveraged by LDAP if LDAP DN is configured in PicketLink IDM to only store a specific group type. This will then store the given branch in portal group tree, while all other groups will remain in the database. + </para> + </listitem> + <listitem> + <para> + <code>forceMembershipOfMappedTypes</code> + Groups stored in PicketLink IDM with a type mapped in 'groupTypeMappings' will automatically be members under the mapped parent. Group relationships linked by PicketLink IDM group association will not be necessary. + + This parameter can be set to false if all groups are added via portal APIs. This may be useful with LDAP configuration as, when set to true, it will make every entry added to LDAP appear in portal. This, however, is not true for entries added via GateIn Portal management UI. + </para> + </listitem> + <listitem> + <para> + <code>ignoreMappedMembershipType</code> + If "associationMembershipType" option is used, and this option is set to true, then Membership with MembershipType configured to be stored as PicketLink IDM association will not be stored as PicketLink IDM Role. + </para> + </listitem> + </itemizedlist> + <para> + Additionally, + <emphasis role="italics">PicketlinkIDMOrganizationServiceImpl</emphasis> + uses those defaults to perform identity management operations. + </para> + <itemizedlist> + <listitem> + <para>GateIn Portal User interface properties fields are persisted in Picketlink IDM using those attributes names: firstName, lastName, email, createdDate, lastLoginTime, organizationId, password (if password is configured to be stored as attribute).</para> + </listitem> + <listitem> + <para>GateIn Portal Group interface properties fields are persisted in Picketlink IDM using those attributes names: label, description.</para> + </listitem> + <listitem> + <para> + GateIn Portal MembershipType interface properties fields are persisted in JBoss Identity IDM using those RoleType properties: description, owner, create_date, modified_date. + + A sample + <emphasis role="italics">PicketLink IDM</emphasis> + configuration file is shown below. To understand all the options it contains, please refer to the PicketLink IDM Reference Guide. + </para> + </listitem> + </itemizedlist> + <informalexample> + <programlisting><jboss-identity xmlns="urn:jboss:identity:idm:config:v1_0_beta" + xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" + xsi:schemaLocation="urn:jboss:identity:idm:config:v1_0_alpha identity-config.xsd"> + <realms> + <realm> + <id>PortalRealm</id> + <repository-id-ref>PortalRepository</repository-id-ref> + <identity-type-mappings> + <user-mapping>USER</user-mapping> + </identity-type-mappings> + </realm> + </realms> + <repositories> + <repository> + <id>PortalRepository</id> + <class>org.jboss.identity.idm.impl.repository.WrapperIdentityStoreRepository</class> + <external-config/> + <default-identity-store-id>HibernateStore</default-identity-store-id> + <default-attribute-store-id>HibernateStore</default-attribute-store-id> + </repository> + </repositories> + <stores> + <attribute-stores/> + <identity-stores> + <identity-store> + <id>HibernateStore</id> + <class>org.jboss.identity.idm.impl.store.hibernate.HibernateIdentityStoreImpl</class> + <external-config/> + <supported-relationship-types> + <relationship-type>JBOSS_IDENTITY_MEMBERSHIP</relationship-type> + <relationship-type>JBOSS_IDENTITY_ROLE</relationship-type> + </supported-relationship-types> + <supported-identity-object-types> + <identity-object-type> + <name>USER</name> + <relationships/> + <credentials> + <credential-type>PASSWORD</credential-type> + </credentials> + <attributes/> + <options/> + </identity-object-type> + </supported-identity-object-types> + <options> + <option> + <name>hibernateSessionFactoryRegistryName</name> + <value>hibernateSessionFactory</value> + </option> + <option> + <name>allowNotDefinedIdentityObjectTypes</name> + <value>true</value> + </option> + <option> + <name>populateRelationshipTypes</name> + <value>true</value> + </option> + <option> + <name>populateIdentityObjectTypes</name> + <value>true</value> + </option> + <option> + <name>allowNotDefinedAttributes</name> + <value>true</value> + </option> + <option> + <name>isRealmAware</name> + <value>true</value> + </option> + </options> + </identity-store> + </identity-stores> + </stores> +</jboss-identity> +</programlisting> + </informalexample> + </section> + </section> +</chapter> Modified: epp/docs/branches/6.0/Reference_Guide/en-US/modules/AuthenticationAndIdentity/PasswordEncryption.xml =================================================================== --- epp/docs/branches/6.0/Reference_Guide/en-US/modules/AuthenticationAndIdentity/PasswordEncryption.xml 2013-01-22 05:16:43 UTC (rev 9070) +++ epp/docs/branches/6.0/Reference_Guide/en-US/modules/AuthenticationAndIdentity/PasswordEncryption.xml 2013-01-22 05:18:26 UTC (rev 9071) @@ -1,62 +1,185 @@ <?xml version='1.0' encoding='UTF-8'?> -<!DOCTYPE section PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN" "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" [ +<!DOCTYPE section PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN" "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" [ <!ENTITY % BOOK_ENTITIES SYSTEM "../../Reference_Guide.ent"> %BOOK_ENTITIES; ]> <chapter id="sect-Reference_Guide-Authentication_and_Identity-Password_Encryption"> <title>Password Encryption</title> - <warning> - <title>Username and passwords stored in clear text</title> + <section id="sid-54264610_PasswordEncryption-HashingandsaltingofpasswordsinPicketlinkIDM"> + <title>Hashing and salting of passwords in Picketlink IDM</title> <para> + GateIn Portal is using + <ulink url="http://www.jboss.org/picketlink/IDM">Picketlink IDM</ulink> + framework to store information about identity objects (users/groups/memberships) and more info about this is in + <ulink url="https://docs.jboss.org/author/pages/viewpage.action?pageId=54264613">PicketLink IDM integration</ulink> + . For better security, Picketlink IDM does not save user passwords into database in plain-text, but it uses + <code>CredentialEncoder</code> + , which encode password and save the encoded form into Picketlink IDM database. + + Later when user want to authenticate, he needs to provide his password in plain-text via web login form. Provided password is then encoded and compared with encoded password from Picketlink IDM database. GateIn Portal is then able to authenticate user based on this comparison. + </para> + <para> + Default implementation of + <code>CredentialEncoder</code> + is using password hashing with MD5 algorithm and storing those MD5 hashes in database. It does not use any salting of passwords. This is not safest solution, but it's backward compatible with previous releases of GateIn Portal before version 3.5, where MD5 password hashing was only possible encoding form. So if you migrate from older release of GateIn Portal, your users will be still able to authenticate. + </para> + <para>However if you are starting from fresh database (no migration from previous GateIn Portal release), you may increase security by using better hashing algorithm and especially by enable password salting. See below for details.</para> + <section id="sid-54264610_PasswordEncryption-ChoosingCredentialEncoderimplementation"> + <title>Choosing CredentialEncoder implementation</title> + <para> + The implementation of CredentialEncoder is configured in file + <code>GATEIN_HOME/gatein/gatein.ear/portal.war/WEB-INF/conf/organization/picketlink-idm/picketlink-idm-config.xml</code> + . Usually the most important are options of realm + <code>idm_portal</code> + starting with prefix + <code>credentialEncoder.</code> + . Possible implementations are: + </para> + <section id="sid-54264610_PasswordEncryption-HashingEncoder"> + <title>HashingEncoder</title> + <para>This is the default choice. It uses only hashing of passwords with MD5 algorithm without salting. As mentioned previously, it's not safest solution but it's backward compatible with previous GateIn Portal releases, so there are no issues with database migration from previous release. Configuration looks like this:</para> + <informalexample> + <programlisting> +<option> + <name>credentialEncoder.class</name> + <value>org.picketlink.idm.impl.credential.HashingEncoder</value> +</option> +<option> + <name>credentialEncoder.hashAlgorithm</name> + <value>MD5</value> +</option> +</programlisting> + </informalexample> + </section> + <section id="sid-54264610_PasswordEncryption-DatabaseReadingSaltEncoder"> + <title>DatabaseReadingSaltEncoder</title> + <para>This implementation provides salting of password in addition to hashing. The salt is unique for each user, so it's much more complicated to decrypt password via brute force, if some attacker steal encoded passwords from your database. The salt is generated randomly for each user and stored in Picketlink IDM database as attribute. Random generation of salt ensure that all users have different salts, so even if two users have same password, the encoded password in database will be different for them. Here is configuration example, which is using SHA-256 algorithm for hashing (more secure than MD5) and algorithm SHA1PRNG for generation of random salts.</para> + <informalexample> + <programlisting> +<option> + <name>credentialEncoder.class</name> + <value>org.picketlink.idm.impl.credential.DatabaseReadingSaltEncoder</value> +</option> +<option> + <name>credentialEncoder.hashAlgorithm</name> + <value>SHA-256</value> +</option> +<option> + <name>credentialEncoder.secureRandomAlgorithm</name> + <value>SHA1PRNG</value> +</option> +</programlisting> + </informalexample> + </section> + <section id="sid-54264610_PasswordEncryption-FileReadingSaltEncoder"> + <title>FileReadingSaltEncoder</title> + <para> + It also uses hashing and salting, so it's similar like previous encoder. But it's theoretically even more secure, because salts are not stored in Picketlink IDM database together with passwords. Salt of each user is generated from + <emphasis role="italics">saltPrefix</emphasis> + and user's username. And + <emphasis role="italics">saltPrefix</emphasis> + is read from some file in your filesystem. Configuration can look like this: + </para> + <informalexample> + <programlisting> +<option> + <name>credentialEncoder.class</name> + <value>org.picketlink.idm.impl.credential.FileReadingSaltEncoder</value> +</option> +<option> + <name>credentialEncoder.hashAlgorithm</name> + <value>SHA-256</value> +</option> +<option> + <name>credentialEncoder.fileLocation</name> + <value>/salt/mysalt.txt</value> +</option> +</programlisting> + </informalexample> + <para> + Please note that specified file + <code>/salt/mysalt.txt</code> + must exist and must be readable by user, which executed GateIn Portal. But file should be properly secured to not be readable by every user of your OS. The file can have some random content phrase, for example + <emphasis role="italics">a4564dac2aasddsklklkajdgnioiow</emphasis> + . + </para> + <para> + So the + <code>FileReadingSaltEncoder</code> + is probably most secure of all options, but in addition to + <code>DatabaseReadingSaltEncoder</code> + you need to set the file with salt. + </para> + <important> + <title>Important</title> + <para> + The + <code>CredentialEncoder</code> + from above is actually used only for encoding of passwords in Picketlink IDM database. It's not used for LDAP. Picketlink IDM LDAP implementation ( + <code>LDAPIdentityStore</code> + ) is sending passwords to LDAP server in plain form, because password encoding is usually provided by LDAP server itself. For example OpenDS 2 is using SHA1 based hashing of passwords with random generation of user salt (so actually something similar to our + <code>DatabaseReadingSaltEncoder</code> + implementation). + </para> + </important> + </section> + </section> + </section> + <section> + <title>Password Encryption of Rememberme Passwords</title> + <warning> + <title>Username and passwords stored in clear text</title> + <para> The <emphasis>Remember Me</emphasis> feature of JBoss Portal Platform uses a token mechanism to be able to authenticate returning users without requiring an explicit login. However, to be able to authenticate these users, the token needs to store the username and password in clear text in the JCR. </para> - </warning> - <para> + </warning> + <para> Administrators have two options available to ameliorate this risk: </para> - <orderedlist> - <listitem> - <para> + <orderedlist> + <listitem> + <para> The <emphasis>Remember Me</emphasis> feature can be disabled by removing the corresponding checkbox in: <filename><replaceable>JPP_DIST</replaceable>/jboss-as/server/<replaceable>PROFILE</replaceable>/deploy/gatein.ear/02portal.war/login/jsp/login.jsp</filename> and <filename><replaceable>JPP_DIST</replaceable>/jboss-as/server/<replaceable>PROFILE</replaceable>/deploy/gatein.ear/02portal.war/groovy/portal/webui/UILoginForm.gtmpl</filename>. </para> - </listitem> - <listitem> - <para> + </listitem> + <listitem> + <para> Passwords can be encoded prior to being saved to the JCR. This option requires administrators to provide a custom subclass of <parameter>org.exoplatform.web.security.security.AbstractCodec</parameter> and set up a codec implementation with <parameter>CookieTokenService</parameter>: </para> - <procedure id="proc-Reference_Guide-Password_Encryption-Encrypt_Password_in_JCR"> - <title>Encrypt Password in JCR</title> - <step> - <para> + <procedure id="proc-Reference_Guide-Password_Encryption-Encrypt_Password_in_JCR"> + <title>Encrypt Password in JCR</title> + <step> + <para> Create a javaclass similar to: </para> - <programlisting language="Java" role="Java"><xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="../../extras/Authentication_Identity/ExampleCodec.java" parse="text"/></programlisting> - </step> - <step> - <para> + <programlisting language="Java" role="Java"><xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="../../extras/Authentication_Identity/ExampleCodec.java" parse="text"/></programlisting> + </step> + <step> + <para> Compile the class and package it into a jar file. For this example we will call the jar file <filename>codec-example.jar</filename>. </para> - </step> - <step> - <para> + </step> + <step> + <para> Create a <filename>conf/portal/configuration.xml</filename> file within the <filename>codec-example.jar</filename> similar to the example below. This allows the portal kernel to find and use the new codec implementation. </para> - <programlisting language="XML" role="XML"><xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="../../extras/Authentication_Identity/configuration.xml" parse="text"/></programlisting> - </step> - <step> - <para> + <programlisting language="XML" role="XML"><xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="../../extras/Authentication_Identity/configuration.xml" parse="text"/></programlisting> + </step> + <step> + <para> Deploy the <filename>codec-example.jar</filename> into your <filename><replaceable>JPP_DIST</replaceable>/jboss-as/server/<replaceable>PROFILE</replaceable>/deploy/gatein.ear/lib/</filename> directory. </para> - </step> - <step> - <para> + </step> + <step> + <para> Start (or restart) your JBoss Portal Platform. </para> - <para> + <para> Any passwords written to the JCR will now be encoded and not plain text. </para> - </step> - </procedure> - </listitem> - </orderedlist> + </step> + </procedure> + </listitem> + </orderedlist> + </section> </chapter>

11 years, 3 months

1
0
0 / 0

gatein SVN: r9070 - in epp/docs/branches/6.0: Reference_Guide/en-US/modules/AuthenticationAndIdentity and 1 other directory.

by do-not-reply＠jboss.org

Author: smumford Date: 2013-01-22 00:16:43 -0500 (Tue, 22 Jan 2013) New Revision: 9070 Removed: epp/docs/branches/6.0/Draft_CSP_Maps/Installation_Guide/tmp/ Modified: epp/docs/branches/6.0/Reference_Guide/en-US/modules/AuthenticationAndIdentity/SAML2.xml Log: Removed unnecessary tmp directory Modified: epp/docs/branches/6.0/Reference_Guide/en-US/modules/AuthenticationAndIdentity/SAML2.xml =================================================================== (Binary files differ)

11 years, 3 months

1
0
0 / 0

gatein SVN: r9069 - epp/docs/branches/6.0/Installation_Guide/en-US.

by do-not-reply＠jboss.org

Author: smumford Date: 2013-01-22 00:12:14 -0500 (Tue, 22 Jan 2013) New Revision: 9069 Modified: epp/docs/branches/6.0/Installation_Guide/en-US/HTTPSConfiguration.xml Log: https://docs.jboss.org/author/display/GTNPORTAL35/HTTPS+Configuration Changes incorporated into enterprise doc Modified: epp/docs/branches/6.0/Installation_Guide/en-US/HTTPSConfiguration.xml =================================================================== --- epp/docs/branches/6.0/Installation_Guide/en-US/HTTPSConfiguration.xml 2013-01-21 05:12:50 UTC (rev 9068) +++ epp/docs/branches/6.0/Installation_Guide/en-US/HTTPSConfiguration.xml 2013-01-22 05:12:14 UTC (rev 9069) @@ -5,8 +5,9 @@ ]> <section id="HTTPS_Configuration"> <title>HTTPS Configuration</title> + <remark>Source: https://docs.jboss.org/author/display/GTNPORTAL35/HTTPS+Configuration</remark> <remark>https://bugzilla.redhat.com/show_bug.cgi?id=794440 - 20120221 - Reworked the entire section to cover keystore and truststore configuration specific to EPP. </remark> - <para>JBoss Enterprise Portal Platform runs by default in HTTP mode. For security purposes, configure your production platform to run in HTTPS mode. </para> + <para>JBoss Enterprise Portal Platform runs by default in HTTP mode. For security purposes, configure your production platform to run in HTTPS mode. </para> <important> <para>Understanding the fundamentals of keystore and truststore configuration is critical to the tasks in this section. </para> <para>Refer to the JBoss Enterprise Application Platform <citetitle>Security Guide</citetitle> <citetitle>"SSL Encryption Overview"</citetitle> chapter for detailed encryption theory and procedures relevant to all JBoss Middleware platforms. </para> @@ -78,7 +79,7 @@ <programlisting language="XML"><Connector protocol="HTTP/1.1" SSLEnabled="true" port="8443" address="${jboss.bind.address}" scheme="https" secure="true" clientAuth="false" sslProtocol = "TLS" - keystoreFile="${jboss.server.home.dir}/conf/<replaceable>server.keystore</replaceable>" + keystoreFile="$JAVA_HOME/jre/lib/security/cacerts" keystorePass="123456" truststoreFile="/usr/java/<replaceable>JDK_VERSION/</replaceable>jre/lib/security/cacerts" truststorePass="<replaceable>changeit</replaceable>"

11 years, 3 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

gatein-commits January 2013