Author: ppenicka Date: 2013-01-30 11:15:12 -0500 (Wed, 30 Jan 2013) New Revision: 9099 Modified: epp/docs/branches/6.0/Reference_Guide/en-US/Revision_History.xml epp/docs/branches/6.0/Reference_Guide/en-US/modules/AuthenticationAndIdentity/AccessingUserProfile.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/BackendConfiguration.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/LDAP.xml epp/docs/branches/6.0/Reference_Guide/en-US/modules/AuthenticationAndIdentity/OrganizationAPI.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/SAML2.xml epp/docs/branches/6.0/Reference_Guide/en-US/modules/AuthenticationAndIdentity/SAML2_Salesforce_and_Google_Integration.xml epp/docs/branches/6.0/Reference_Guide/en-US/modules/AuthenticationAndIdentity/SSO.xml Log: Chapter III. Authentication and Authorization - further code cleanup, spell-check, unified capitals in titles, removed links to docs.jboss.org (where applicable), removed some technical jargon, etc. 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-30 06:22:19 UTC (rev 9098) +++ epp/docs/branches/6.0/Reference_Guide/en-US/Revision_History.xml 2013-01-30 16:15:12 UTC (rev 9099) @@ -8,6 +8,21 @@ <simpara> <revhistory> <revision> + <revnumber>6.0.0-43</revnumber> + <date>Wed Jan 30 2013</date> + <author> + <firstname>Petr</firstname> + <surname>Penicka</surname> + <email/> + </author> + <revdescription> + <simplelist> + <member>Cleaned up imported content in Chapter III. - Authentication and Authorization.</member> + <member>Cleared out TODO, FIXME and some other remarks, further code cleanup, spell-check, unified capitals in titles, removed links to docs.jboss.org (where applicable), removed some technical jargon, etc.</member> + </simplelist> + </revdescription> + </revision> + <revision> <revnumber>6.0.0-42</revnumber> <date>Tue Jan 27 2013</date> <author> Modified: epp/docs/branches/6.0/Reference_Guide/en-US/modules/AuthenticationAndIdentity/AccessingUserProfile.xml =================================================================== --- epp/docs/branches/6.0/Reference_Guide/en-US/modules/AuthenticationAndIdentity/AccessingUserProfile.xml 2013-01-30 06:22:19 UTC (rev 9098) +++ epp/docs/branches/6.0/Reference_Guide/en-US/modules/AuthenticationAndIdentity/AccessingUserProfile.xml 2013-01-30 16:15:12 UTC (rev 9099) @@ -22,6 +22,6 @@ </listitem> </orderedlist> <para> - Both alternatives are probably better then {{OrganizationService orgService = getApplicationComponent(OrganizationService.class)}} because you can use them from your own portlets or servlet/portlet filters. Variant with {{getApplicationComponent}} works only from WebUI. + Both alternatives are probably better then {{OrganizationService orgService = getApplicationComponent(OrganizationService.class)}} because you can use them from your own portlets or servlet/portlet filters. The variant with {{getApplicationComponent}} works only from WebUI. </para> </chapter> 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-30 06:22:19 UTC (rev 9098) +++ epp/docs/branches/6.0/Reference_Guide/en-US/modules/AuthenticationAndIdentity/AuthenticationAuthorizationOverview.xml 2013-01-30 16:15:12 UTC (rev 9099) @@ -22,7 +22,7 @@ </listitem> <listitem> <para> - The <literal>RememberMe</literal> authentication method (wherein the user checks the <guilabel>Remember my login</guilabel> checkbox on the log in form). + The <literal>RememberMe</literal> authentication method (wherein the user checks the <guilabel>Remember my login</guilabel> check box on the log in form). </para> </listitem> <listitem> @@ -85,17 +85,20 @@ &lt;/login-config&gt; </programlisting> <para> <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"/> - </imageobject> - <imageobject role="fo"> - <imagedata align="center" scalefit="1" fileref="images/AuthenticationAndIdentity/Overview/loginScreen.png" format="PNG"/> - </imageobject> - </mediaobject> + <figure> + <title>Default Login Form on the login.jsp Page</title> + <mediaobject> + <imageobject role="html"> + <imagedata align="center" fileref="images/AuthenticationAndIdentity/Overview/loginScreen.png" format="PNG"/> + </imageobject> + <imageobject role="fo"> + <imagedata align="center" scalefit="1" fileref="images/AuthenticationAndIdentity/Overview/loginScreen.png" format="PNG"/> + </imageobject> + </mediaobject> + </figure> </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&apos;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> . + 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&apos;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&amp;password=gtn&amp;initialURI=/portal/classic" type="http">http://localhost:8080/portal/login?username=root&amp;password=gtn&amp;initialURI=/portal/private/classic</ulink>. @@ -105,7 +108,7 @@ </para> </section> <section id="sect-Authentication_Authorization_Intro-Login_Modules"> - <title>Login modules</title> + <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>JPP_HOME/gatein/gatein.ear/META-INF/gatein-jboss-beans.xml</filename> file. </para> @@ -136,7 +139,7 @@ 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 &quot;false&quot; 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/... type="http">http://docs.oracle.com/javase/6/docs/technotes/g... here for more information about login modules in general. </para> <section id="sect-Authentication_Authorization_Intro-existingLM"> - <title>Existing login modules</title> + <title>Existing Login Modules</title> <para> Here is a brief description of existing login modules: </para> @@ -146,7 +149,7 @@ <term>SSODelegateLoginModule</term> <listitem> <para> - It&apos;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="sect-SSO_Single_Sign_On_-Central_Authentication_Service"/> 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 JBoss Enterprise Application Platform 6 LoginModule or other login modules in the JAAS chain. + It is 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="sect-SSO_Single_Sign_On_-Central_Authentication_Service"/> 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 JBoss Enterprise Application Platform 6 LoginModule or other login modules in the JAAS chain. </para> </listitem> </varlistentry> @@ -154,7 +157,7 @@ <term>JBoss Enterprise Application Platform 6 LoginModule</term> <listitem> <para> - Most important login module, which is normally used to perform whole authentication by itself. First it checks if Identity object has been already created and saved into sharedState map by previous login modules (like SSODelegateLoginModule, CustomMembershipLoginModule or SharedStateLoginModule). If not, it triggers real authentication of user with usage of Authenticator interface and it will use Authentication.validateUser(Credential[] credentials) which performs real authentication of username and password against OrganizationService and portal identity database. See <xref linkend="sect-Authentication_Authorization_Intro-authenticatorAndRolesExtractor"/> for details about Authenticator and about Identity objects. In the Jboss Enterprise Application Platform 6LoginModule.commit method, the Identity object is registered to IdentityRegistry, which will be used later for authorization. Also some JAAS principals (UserPrincipal and RolesPrincipal) and assigned to! our authenticated Subject. This is needed for JBoss Enterprise Application server, so that it can properly recognize the name of the logged user and its roles on an JBoss Enterprise Application level. + Most important login module, which is normally used to perform whole authentication by itself. First it checks if Identity object has been already created and saved into sharedState map by previous login modules (like SSODelegateLoginModule, CustomMembershipLoginModule or SharedStateLoginModule). If not, it triggers real authentication of user with usage of Authenticator interface and it will use Authentication.validateUser(Credential[] credentials) which performs real authentication of username and password against OrganizationService and portal identity database. See <xref linkend="sect-Authentication_Authorization_Intro-authenticatorAndRolesExtractor"/> for details about Authenticator and about Identity objects. In the Jboss Enterprise Application Platform 6 LoginModule.commit method, the Identity object is registered to IdentityRegistry, which will be used later for authorization. Also some JAAS principals (UserPrincipal and RolesPrincipal) and assigned t! o our authenticated Subject. This is needed for JBoss Enterprise Application server, so that it can properly recognize the name of the logged user and its roles on an JBoss Enterprise Application level. </para> </listitem> </varlistentry> @@ -238,7 +241,7 @@ </programlisting> </section> <!-- Ending section with existing login modules --> <section id="sect-Authentication_Authorization_Intro-createNewLM"> - <title>Creating your own login module</title> + <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. </para> @@ -258,7 +261,7 @@ </listitem> </itemizedlist> <formalpara id="form-Authentication_Authorization_Intro-authenticationAppServerLevel"> - <title>Authentication on application server level</title> + <title>Authentication on Application Server Level</title> <para> <remark>QUESTION: Should the following reference to Tomcat be removed?</remark> Application server needs to properly recognize that user is successfully logged and it has assigned his JAAS roles. Unfortunately this part is not standardized and is specific for each AS. For example in JBoss Enterprise Application, you need to ensure that JAAS Subject has assigned principal with username (UserPrincipal) and also RolesPrincipal, which has name &quot;Roles&quot; and it contains list of JAAS roles. This part is actually done in <code>JbossLoginModule.commit()</code>. In Tomcat, this flow is little different, which means Tomcat has it is own <literal>TomcatLoginModule</literal>. @@ -268,7 +271,7 @@ After successful authentication, user needs to be at least in JAAS role &quot;users&quot; because this role is declared in <filename>web.xml</filename> as you saw above. JAAS roles are extracted by special algorithm from JBoss Portal Platform memberships. See below in section with RolesExtractor. </para> <formalpara id="form-Authentication_Authorization_Intro-authenticationGateInServerLevel"> - <title>Authentication on JBoss Portal Platform level</title> + <title>Authentication on JBoss Portal Platform Level</title> <para> The login process needs to create a special object <literal>org.exoplatform.services.security.Identity</literal> and register this object into JBoss Portal Platform component <literal>IdentityRegistry</literal>. The Identity object should encapsulate the username of the authenticated user, memberships of this user and JAAS roles. The Identity object can be easily created with interface <literal>Authenticator</literal> as shown below. </para> @@ -359,14 +362,14 @@ </section> <!-- Ending section Authenticator and RolesExtractor --> </section> <!-- Ending section with login modules --> <section id="sect-Authentication_Authorization_Intro-differentAuthWorkflows"> - <title>Different authentication workflows</title> + <title>Different Authentication Workflows</title> <section id="sect-Authentication_Authorization_Intro-RememberMeAuthentication"> - <title>RememberMe authentication</title> + <title>RememberMe Authentication</title> <para> In default login dialog, you can notice that there is &quot;Remember my login&quot; checkbox, which users can use to persist their login on his workstation. Default validity period of RememberMe cookie is one day (it is configurable), and so user can be logged for whole day before he need to re-authenticate again with his credentials. </para> <section id="sect-Authentication_Authorization_Intro-RememberMeAuthentication-howDoesItWork"> - <title>How does it work</title> + <title>How Does It Work</title> <itemizedlist> <listitem> <para> @@ -416,7 +419,7 @@ </section> </section> <section id="sect-Authentication_Authorization_Intro-authorization"> - <title>Authorization overview</title> + <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> @@ -436,7 +439,7 @@ Authorization in JBoss Portal Platform actually happens on two levels: </para> <section id="sect-Authentication_Authorization_Intro-servletContainerAuthorization"> - <title>Servlet container authorization</title> + <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> 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-30 06:22:19 UTC (rev 9098) +++ epp/docs/branches/6.0/Reference_Guide/en-US/modules/AuthenticationAndIdentity/BackendConfiguration.xml 2013-01-30 16:15:12 UTC (rev 9099) @@ -391,7 +391,7 @@ <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> --> <section id="sid-54264613_PicketLinkIDMintegration-Configurationfiles"> - <title>Configuration files</title> + <title>Configuration Files</title> <para> The main configuration file is <code>JPP_HOME/gatein/gatein.ear/portal.war/WEB-INF/conf/organization/idm-configuration.xml</code> @@ -535,7 +535,7 @@ <listitem> <para> <code>apiCacheConfig</code> - (value-param) The infinispan configuration file with cache configuration for Picketlink IDM API. It&apos;s different for cluster and non-cluster because infinispan needs to be replicated in cluster environment. + (value-param) The Infinispan configuration file with cache configuration for PicketLink IDM API. It&apos;s different for cluster and non-cluster because Infinispan needs to be replicated in cluster environment. </para> </listitem> <listitem> @@ -543,7 +543,7 @@ <code>storeCacheConfig</code> (value-param) - The infinispan configuration file with cache configuration for Picketlink IDM IdentityStore. Actually it&apos;s used only for LDAP store (not used with default DB configuration). It&apos;s different for cluster and non-cluster because infinispan needs to be replicated in cluster environment. + The Infinispan configuration file with cache configuration for PicketLink IDM IdentityStore. Actually it&apos;s used only for LDAP store (not used with default DB configuration). It&apos;s different for cluster and non-cluster because Infinispan needs to be replicated in cluster environment. </para> </listitem> </itemizedlist> @@ -553,7 +553,7 @@ <para> The <code>org.exoplatform.services.organization.idm.PicketLinkIDMOrganizationServiceImpl</code> - key is a main entrypoint implementing + key is a main entry point implementing <code>org.exoplatform.services.organization.OrganizationService</code> and is dependent on <code>org.exoplatform.services.organization.idm.PicketLinkIDMService</code> @@ -628,7 +628,7 @@ <code>forceMembershipOfMappedTypes</code> Groups stored in PicketLink IDM with a type mapped in &apos;groupTypeMappings&apos; 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 JBoss Portal Platform management UI. + 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 JBoss Portal Platform management user interface. </para> </listitem> <listitem> @@ -645,10 +645,10 @@ </para> <itemizedlist> <listitem> - <para>JBoss Portal Platform 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> + <para>JBoss Portal Platform 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>JBoss Portal Platform Group interface properties fields are persisted in Picketlink IDM using those attributes names: label, description.</para> + <para>JBoss Portal Platform Group interface properties fields are persisted in PicketLink IDM using those attributes names: label, description.</para> </listitem> <listitem> <para> 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-30 06:22:19 UTC (rev 9098) +++ epp/docs/branches/6.0/Reference_Guide/en-US/modules/AuthenticationAndIdentity/CoreOrganizationInitializer.xml 2013-01-30 16:15:12 UTC (rev 9099) @@ -81,7 +81,7 @@ <title>Using configuration directives</title> <para>There are a number of ways of controlling operations associated with CoreOrganizationInitializer. All parameters are configured in &lt;value-param&gt; directive blocks in the <filename><replaceable>JPP_DIST</replaceable>/gatein/gatein.ear/portal.war/conf/organization/initializer-configuration.xml</filename> file.</para> <example> - <title>&lt;value-param&gt; block for initializer directives</title> + <title>&lt;value-param&gt; Block for Initializer Directives</title> <programlisting language="XML">&lt;value-param&gt; &lt;name&gt;directiveName&lt;/name&gt; &lt;value&gt;[true | false]&lt;/value&gt; @@ -114,7 +114,7 @@ </step> </procedure> <procedure> - <title>Alter the way JCR objects are created on-demand, at user login. </title> + <title>Altering On-demand JCR Object Creation 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>/gatein/gatein.ear/portal.war/conf/organization/initializer-configuration.xml</filename></para> @@ -134,7 +134,7 @@ <title>Using JMX Console</title> <para>The JMX Console is available for all CoreOrganizationInitializer operations.</para> <procedure> - <title>Trigger operations through the JMX console . </title> + <title>Triggering Operations through the JMX Console</title> <step> <para>Open <uri>http://localhost:8080/jmx-console</uri></para> </step> @@ -157,7 +157,7 @@ </section> <section> <title>Using REST Interface</title> - <para>OrganizationInitializerService can be accessed using a REST interface. Some examples of commands are provided, as a practical way of demonstrating the REST syntax required. Pay particular attention to how forward slash symbols are escaped in directory paths featured in some REST syntax examples.</para> + <para>OrganizationInitializerService can be accessed using a REST interface. Some examples of commands are provided, as a practical way of demonstrating the REST syntax required. Pay particular attention to how forward slash symbols are escaped in directory paths featured in some REST syntax examples.</para> <variablelist> <varlistentry> <term> 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-30 06:22:19 UTC (rev 9098) +++ epp/docs/branches/6.0/Reference_Guide/en-US/modules/AuthenticationAndIdentity/LDAP.xml 2013-01-30 16:15:12 UTC (rev 9099) @@ -37,7 +37,7 @@ </para> </note> <procedure id="proc-Reference_Guide-LDAP_Integration-LDAP_Set_Up"> - <title>LDAP Set Up</title> + <title>LDAP Setup</title> <step> <para> Install your <application>LDAP</application> server by following the installation instructions provided for the product you are using. @@ -67,7 +67,7 @@ <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> + <title>Set up LDAP Read-only Mode</title> <step> <para> Open the <filename><replaceable>ID_HOME</replaceable>/idm-configuration.xml</filename> file. @@ -78,7 +78,7 @@ </step> <step> <para> - Comment out the default Picketlink <literal>config</literal> value: + Comment out the default PicketLink <literal>config</literal> value: </para> <programlisting language="XML" role="XML"><![CDATA[<value>war:/conf/organization/picketlink-idm/picketlink-idm-config.xml</value> ]]></programlisting> @@ -288,7 +288,7 @@ Open the <filename><replaceable>ID_HOME</replaceable>/idm-configuration.xml</filename> file. </para> <para> -JBoss Portal Platform uses the PicketLink IDM framework as the underlying identity storage system, hence all the configurations use dedicated Picketlink settings. +JBoss Portal Platform uses the PicketLink IDM framework as the underlying identity storage system, hence all the configurations use dedicated PicketLink settings. </para> </step> <step> @@ -337,7 +337,7 @@ &lt;/value&gt;</programlisting></para> <important> <para>If this configuration is not uncommented, memberships will be used as both relationships and roles, which may cause duplicated records in the GUI.</para> - <para>Normally, the same roles being used for LDAP mapping need to be uncommented. User memberships under the specified groups will be created in Picketlink IDM only as relationships, and not as roles. </para> + <para>Normally, the same roles being used for LDAP mapping need to be uncommented. User memberships under the specified groups will be created in PicketLink IDM only as relationships, and not as roles. </para> </important> </step> <step> @@ -350,7 +350,7 @@ </step> <step> <title>Result</title> - <para>All portal groups under <filename>/platform</filename> and under <filename>/organization</filename> groups (for example <filename>/platform/users</filename>, <filename>/platform/administrators</filename>, <filename>/organization/management/executive-board</filename>) are mapped to the LDAP tree. The location of groups in the LDAP tree are configurable through the parameter <parameter>ctxDNs</parameter> in the Picketlink IDM configuration file. See <xref linkend="sect-LDAP_Integration-Examples"/> for more information about configuration parameters. + <para>All portal groups under <filename>/platform</filename> and under <filename>/organization</filename> groups (for example <filename>/platform/users</filename>, <filename>/platform/administrators</filename>, <filename>/organization/management/executive-board</filename>) are mapped to the LDAP tree. The location of groups in the LDAP tree are configurable through the parameter <parameter>ctxDNs</parameter> in the PicketLink IDM configuration file. See <xref linkend="sect-LDAP_Integration-Examples"/> for more information about configuration parameters. </para> </step> @@ -434,9 +434,9 @@ <section id="sect-LDAP_Integration-Examples"> <title>Examples</title> <example id="exam-Reference_Guide-LDAP_Integration-Examples-LDAP_configuration_options"> - <title>LDAP configuration</title> + <title>LDAP Configuration</title> <para> - The following settings are stored in the Picketlink configuration file that is nominated in the <filename>idm-configuration.xml</filename> file of your deployment (under the <parameter>config</parameter> parameter of the <parameter>PicketLinkIDMService</parameter> component): + The following settings are stored in the PicketLink configuration file that is nominated in the <filename>idm-configuration.xml</filename> file of your deployment (under the <parameter>config</parameter> parameter of the <parameter>PicketLinkIDMService</parameter> component): </para> <para> This file could be: @@ -470,7 +470,7 @@ </listitem> </itemizedlist> <variablelist> - <title>Configuration options</title> + <title>Configuration Options</title> <varlistentry> <term>ctxDNs</term> <listitem> @@ -566,7 +566,7 @@ Author [w/email]: Bolesław Dawidowicz (bdawidow(a)redhat.com), Jeff Yu License: ?? --> <example id="exam-Reference_Guide-LDAP_Integration-Examples-Read_Only_groupTypeMappings"> - <title>Read Only groupTypeMappings</title> + <title>Read-only groupTypeMappings</title> <para> The <parameter>groupTypeMappings</parameter> exposed in the <filename>idm-configuration.xml</filename> file correspond to <parameter>identity-object-type</parameter> values defined in the DS-specific configuration file (referenced in <emphasis>Sub-step 3a</emphasis> of the DS-specific procedure above). </para> Modified: epp/docs/branches/6.0/Reference_Guide/en-US/modules/AuthenticationAndIdentity/OrganizationAPI.xml =================================================================== --- epp/docs/branches/6.0/Reference_Guide/en-US/modules/AuthenticationAndIdentity/OrganizationAPI.xml 2013-01-30 06:22:19 UTC (rev 9098) +++ epp/docs/branches/6.0/Reference_Guide/en-US/modules/AuthenticationAndIdentity/OrganizationAPI.xml 2013-01-30 16:15:12 UTC (rev 9099) @@ -57,15 +57,17 @@ The <literal>OrganizationService</literal> component is an additional component that serves as an entry point into the Organization API. It provides handling functionality for the five components. </para> <para> - <mediaobject> - <imageobject role="html"> - <imagedata align="center" fileref="images/AuthenticationAndIdentity/OrganizationServiceClassDiagram.png" format="PNG"/> - </imageobject> - <imageobject role="fo"> - <imagedata align="center" scalefit="1" fileref="images/AuthenticationAndIdentity/OrganizationServiceClassDiagram.png" format="PNG"/> - </imageobject> - </mediaobject> - + <figure> + <title>Handler Objects Accessible by the OrganizationService Component</title> + <mediaobject> + <imageobject role="html"> + <imagedata align="center" fileref="images/AuthenticationAndIdentity/OrganizationServiceClassDiagram.png" format="PNG"/> + </imageobject> + <imageobject role="fo"> + <imagedata align="center" scalefit="1" fileref="images/AuthenticationAndIdentity/OrganizationServiceClassDiagram.png" format="PNG"/> + </imageobject> + </mediaobject> + </figure> </para> <para> By exposing the Organization API, the <literal>OrganizationService</literal> component provides developers with access to handler objects for managing each of the five components: 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-30 06:22:19 UTC (rev 9098) +++ epp/docs/branches/6.0/Reference_Guide/en-US/modules/AuthenticationAndIdentity/PasswordEncryption.xml 2013-01-30 16:15:12 UTC (rev 9099) @@ -6,18 +6,12 @@ <chapter id="sect-Reference_Guide-Authentication_and_Identity-Password_Encryption"> <title>Password Encryption</title> <section id="sid-54264610_PasswordEncryption-HashingandsaltingofpasswordsinPicketlinkIDM"> - <title>Hashing and salting of passwords in Picketlink IDM</title> + <title>Hashing and Salting of Passwords in PicketLink IDM</title> <remark>Source: https://docs.jboss.org/author/display/GTNPORTAL35/Password+Encryption<... <para> -JBoss Portal Platform 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=5426... 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. JBoss Portal Platform is then able to authenticate user based on this comparison. +JBoss Portal Platform is using the + <ulink url="http://www.jboss.org/picketlink/IDM">PicketLink IDM</ulink> + framework to store information about identity objects (users/groups/memberships). 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, they need to provide their password in plain-text via a web login form. The provided password is then encoded and compared to an encoded password in the PicketLink IDM database. JBoss Portal Platform is then able to authenticate user based on this comparison. More information can be found in <xref linkend="sect-Reference_Guide-PicketLink_IDM_integration"/>. </para> <para> Default implementation of @@ -26,7 +20,7 @@ </para> <para>However if you are starting from fresh database (no migration from previous JBoss Portal Platform 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> + <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> @@ -54,7 +48,7 @@ </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&apos;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> + <para>This implementation provides salting of password in addition to hashing. The salt is unique for each user, so it&apos;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> &lt;option&gt; @@ -75,11 +69,11 @@ <section id="sid-54264610_PasswordEncryption-FileReadingSaltEncoder"> <title>FileReadingSaltEncoder</title> <para> - It also uses hashing and salting, so it&apos;s similar like previous encoder. But it&apos;s theoretically even more secure, because salts are not stored in Picketlink IDM database together with passwords. Salt of each user is generated from + It also uses hashing and salting, so it&apos;s similar like previous encoder. But it&apos;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&apos;s username. And <emphasis role="italics">saltPrefix</emphasis> - is read from some file in your filesystem. Configuration can look like this: + is read from some file in your file system. Configuration can look like this: </para> <informalexample> <programlisting> @@ -116,7 +110,7 @@ <para> The <code>CredentialEncoder</code> - from above is actually used only for encoding of passwords in Picketlink IDM database. It&apos;s not used for LDAP. Picketlink IDM LDAP implementation ( + from above is actually used only for encoding of passwords in PicketLink IDM database. It&apos;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> @@ -151,7 +145,7 @@ <title>Encrypt Password in JCR</title> <step> <para> - Create a javaclass similar to: + Create a Java class 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> 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-30 06:22:19 UTC (rev 9098) +++ epp/docs/branches/6.0/Reference_Guide/en-US/modules/AuthenticationAndIdentity/PredefinedUserConfiguration.xml 2013-01-30 16:15:12 UTC (rev 9099) @@ -11,7 +11,7 @@ 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 id="sect-Reference_Guide-Predefined_User_Configuration-Plugin_for_adding_users_groups_and_membership_types"> - <title>Plug-in for adding users, groups and membership types</title> + <title>Plug-in for Adding Users, Groups and Membership Types</title> <para> The plug-in type <literal>org.exoplatform.services.organization.OrganizationDatabaseInitializer</literal> is used to specify a list of membership types, a list of groups and a list of users to be created. </para> @@ -26,7 +26,7 @@ </para> </section> <section id="sect-Reference_Guide-Predefined_User_Configuration-Membership_types"> - <title>Membership types</title> + <title>Membership Types</title> <para> The predefined membership types are specified in the <emphasis role="bold">membershipType</emphasis> field of the <emphasis role="bold">OrganizationConfig</emphasis> plug-in parameter. </para> @@ -52,7 +52,7 @@ <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> </section> <section id="sect-Reference_Guide-Predefined_User_Configuration-Plugin_for_managing_user_creation"> - <title>Plug-in for monitoring user creation</title> + <title>Plug-in for Monitoring User Creation</title> <para> The plug-in type <literal>org.exoplatform.services.organization.impl.NewUserEventListener</literal> specifies which groups all newly created users should become members of. </para> Modified: epp/docs/branches/6.0/Reference_Guide/en-US/modules/AuthenticationAndIdentity/SAML2.xml =================================================================== (Binary files differ) Modified: epp/docs/branches/6.0/Reference_Guide/en-US/modules/AuthenticationAndIdentity/SAML2_Salesforce_and_Google_Integration.xml =================================================================== (Binary files differ) 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-30 06:22:19 UTC (rev 9098) +++ epp/docs/branches/6.0/Reference_Guide/en-US/modules/AuthenticationAndIdentity/SSO.xml 2013-01-30 16:15:12 UTC (rev 9099) @@ -269,7 +269,7 @@ </procedure> </section> <section id="sect-CAS_Logout_Redirection"> - <title>Logout redirection setup</title> + <title>Logout Redirection Setup</title> <remark>Source: https://docs.jboss.org/author/display/GTNPORTAL35/Central+Authentication+... <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=&quot;true&quot;</code> parameter: @@ -283,7 +283,7 @@ </programlisting> </section> <section id="sect-CAS_SSO_Cookie_Configuration"> - <title>CAS SSO cookie configuration (CASTGC)</title> + <title>CAS SSO Cookie Configuration (CASTGC)</title> <remark>Source: https://docs.jboss.org/author/display/GTNPORTAL35/Central+Authentication+... <para> Jasic CAS uses a cookie named @@ -299,7 +299,7 @@ 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> - 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. + This behavior is correct given this example because the browser instance stores the browser authentication state using the CASTGC cookie. The CASTGC 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> @@ -441,7 +441,7 @@ Specifies whether the REST callback authentication handler is enabled. </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. + 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 plug-in on the CAS server side is not required. </para> </listitem> </varlistentry> @@ -596,14 +596,14 @@ On logout, <systemitem>JOSSOLogoutFilter</systemitem> performs a logout on both the Portal and the JOSSO server (similar to the process for CAS). </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). + While the authentication plug-in (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> 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> - 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. + There are differences between various JOSSO minor versions (especially between 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> @@ -620,14 +620,14 @@ </para> </section> <section id="sid-55477376_JOSSO-JOSSOserver"> - <title>Set up the JOSSO server</title> + <title>Setting 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. + This section describes how to set up the JOSSO server to authenticate against the JBoss Portal Platform using the REST authentication plug-in. In this example, the JOSSO server will be installed on Tomcat. </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): + <emphasis role="bold">Optional:</emphasis> To use the SSO authentication plug-in with JOSSO (not-mandatory but recommended. See <xref linkend="sect-CAS-Authentication_Process"/> for details): </para> <substeps> <step> @@ -653,7 +653,7 @@ Add <filename>SSO_HOME/josso/josso-<replaceable>&lt;version&gt;</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> - 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). + 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 plug-in to send REST requests over HTTP). </para> </listitem> </itemizedlist> @@ -673,7 +673,7 @@ </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. + Tomcat should now allow access to <uri>http://localhost:8888/josso/signon/login.do</uri>. However, if you are using the SSO Authentication plug-in, 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> @@ -687,7 +687,7 @@ </procedure> </section> <section id="sid-55477376_JOSSO-SetuptheJOSSOclient"> - <title>Set up the JOSSO client</title> + <title>Setting up the JOSSO Client</title> <procedure> <step> <para> @@ -718,7 +718,7 @@ Most of the properties are described in <xref linkend="sect-CAS_Configuring_the_Platform"/>. </para> <para> - Some of the properites differ for JOSSO: + Some of the properties differ for JOSSO: </para> <itemizedlist> <listitem> @@ -765,7 +765,7 @@ </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. + From now on, all links redirecting to the user authentication pages will redirect to the JOSSO centralized authentication form. If you set Authentication plug-in for JOSSO, you can login with JBoss Portal Platform credentials (like john/gtn) on JOSSO side. </para> </section> </section> @@ -775,10 +775,10 @@ 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> - 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. + Unfortunately this make it more difficult to use the SSO Authentication plug-in 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> + <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+sta... . </para> @@ -907,7 +907,7 @@ </step> <step> <para> - Go to the <guilabel>Identity appliance lifecycle management</guilabel> tab and go through lifecycle of Identity appliance (<menuchoice> + Go to the <guilabel>Identity appliance life cycle management</guilabel> tab and go through life cycle of Identity appliance (<menuchoice> <guimenuitem>Saved</guimenuitem> <guimenuitem>Staged</guimenuitem> <guimenuitem>Deployed</guimenuitem> @@ -926,7 +926,7 @@ </procedure> </section> <section id="sid-55477376_JOSSO-JOSSOclientsetup"> - <title>JOSSO client setup</title> + <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> @@ -999,28 +999,6 @@ </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/> - <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> - Copy the JAR files for the appropriate JOSSO version from <filename>GATEIN_SSO_HOME/josso/gatein-josso-<replaceable>&lt;version&gt;</replaceable>/modules/org/gatein/sso/main into JPP_HOME/lib/</filename>. - </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> @@ -1030,7 +1008,7 @@ <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. + 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 plug-in 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. @@ -1054,7 +1032,7 @@ <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. + 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 plug-in 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. @@ -1199,7 +1177,7 @@ <guimenuitem>Top level realm</guimenuitem> <guimenuitem>Privileges</guimenuitem> <guimenuitem>All authenticated users</guimenuitem> - </menuchoice> and check the following checkboxes: + </menuchoice> and check the following check boxes: </para> <itemizedlist> <listitem> @@ -1409,7 +1387,7 @@ <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&apos;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: + Ensure correct host name to IP address mapping on the machine where Kerberos and JBoss Portal Platform are running. For example, if the machine&apos;s IP address is <literal>192.168.1.88</literal> and you want it to be accessed under the <literal>server.local.network</literal> host name, add the following line to the <emphasis role="bold">/etc/hosts</emphasis> file: </para> <programlisting> 192.168.1.88 server.local.network @@ -1760,7 +1738,7 @@ <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&gt;HTTP/server.local.network(a)LOCAL.NETWORK&lt;/literal&gt; principal to the keytab. + 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&gt;HTTP/server.local.network(a)LOCAL.NETWORK&lt;/literal&gt; principal to the keytab. </para> </listitem> </varlistentry> @@ -1785,7 +1763,7 @@ </step> </substeps> <para> - The code extract below shows the expected result of the security domain configuraion. + The code extract below shows the expected result of the security domain configuration. </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>