[portal-commits] JBoss Portal SVN: r6986 - docs/trunk/referenceGuide/en/modules.

Author: julien(a)jboss.com Date: 2007-04-17 09:32:25 -0400 (Tue, 17 Apr 2007) New Revision: 6986 Modified: docs/trunk/referenceGuide/en/modules/authentication.xml docs/trunk/referenceGuide/en/modules/identity.xml docs/trunk/referenceGuide/en/modules/ldap.xml docs/trunk/referenceGuide/en/modules/sso.xml Log: JBPORTAL-1295 : before tagging docs for beta1 check the identity part Modified: docs/trunk/referenceGuide/en/modules/authentication.xml =================================================================== --- docs/trunk/referenceGuide/en/modules/authentication.xml 2007-04-17 13:20:32 UTC (rev 6985) +++ docs/trunk/referenceGuide/en/modules/authentication.xml 2007-04-17 13:32:25 UTC (rev 6986) @@ -7,12 +7,12 @@ </author> </chapterinfo> <title>Authentication and Authorization</title> - <para>This chapter describes authentication mechanisms in JBoss Portal</para> + <para>This chapter describes the authentication mechanisms in JBoss Portal</para> <sect1 id="authentication_in_portal"> <title>Authentication in JBoss Portal</title> <para>JBoss Portal is heavily standard based so it leverages <emphasis>Java Authentication and Authorization Service (JAAS)</emphasis> - in JBoss Application Server. Because of this it can be very flexibly configured, and other - authentication solutions can be plugged in really easily. + in JBoss Application Server. Because of this it can be configured in a very flexible manner and other + authentication solutions can be plugged in easily. To better understand authentication mechanisms in JBoss Portal please refer to <link linkend="security.security_authentication">Security</link> chapter. To learn more about JAAS look for proper documentation on @@ -22,25 +22,25 @@ </para> <sect2 id="configuration"> <title>Configuration</title> - <para>You can configure JAAS authentication stack in <emphasis>jboss-portal.sar/conf/login-config.xml</emphasis>. - What is very important to remember is that authorisation in portal starts in JAAS level - + <para>You can configure the JAAS authentication stack in <emphasis>jboss-portal.sar/conf/login-config.xml</emphasis>. + It is important to remember that authorisation in portal starts at the JAAS level - configured <emphasis>LoginModule</emphasis>s apply proper <emphasis>Principal</emphasis> objects representing - roles to authenticated user. Like you can see in <emphasis>jboss-portal.sar/portal-server.war/WEB-INF/web.xml</emphasis> portal - servlet is secured with specified role ("<emphasis>Authenticated</emphasis>"). In default portal configuration - this role is dynamically added by <emphasis>IdentityLoginModule</emphasis>. If you reconfigure default JAAS authentication - chain with other <emphasis>LoginModule</emphasis> implementations, please remember you must fit in this - security constraints to be able to access portal. For example if you place only one <emphasis>LoginModule</emphasis> + the roles of authenticated user. As you can see in <emphasis>jboss-portal.sar/portal-server.war/WEB-INF/web.xml</emphasis> portal + servlet is secured with specified role ("<emphasis>Authenticated</emphasis>"). In the default portal configuration + this role is dynamically added by <emphasis>IdentityLoginModule</emphasis>. If you reconfigure the default JAAS authentication + chain with other <emphasis>LoginModule</emphasis> implementations, you should remember that you must deal with that + security constraints in order to be able to access portal. For example if you place only one <emphasis>LoginModule</emphasis> that will authenticate users against LDAP server you may consider adding all users in your LDAP tree to such role. </para> </sect2> </sect1> <sect1 id="portal_login_modules"> <title>JAAS Login Modules</title> - <para>JBoss Portal comes with few implementations of JAAS <emphasis>LoginModule</emphasis> interface</para> + <para>JBoss Portal comes with a few implementations of JAAS <emphasis>LoginModule</emphasis> interface</para> <sect2> <title>org.jboss.portal.identity.auth.IdentityLoginModule</title> - <para>This is standard portal LoginModule implementation, that use portal identity modules to search for users and roles. By default it's the only - configured LoginModule in the portal authentication stack. Its behaviour can be altered with following options: + <para>This is the standard portal LoginModule implementation that uses portal identity modules in order to search users and roles. + By default it is the only configured LoginModule in the portal authentication stack. Its behaviour can be altered with the following options: <itemizedlist> <listitem> <emphasis role="bold">userModuleJNDIName</emphasis> - JNDI name of portal UserModule. @@ -120,13 +120,12 @@ <sect2> <title>org.jboss.portal.identity.auth.SynchronizingLdapLoginModule</title> <para> - Use can use this module instead of IdentityLoginModule to bind to LDAP. + This module can be used instead of the IdentityLoginModule to bind to LDAP. <emphasis>org.jboss.portal.identity.auth.SynchronizingLDAPLoginModule</emphasis> class is a wrapper around - <ulink url="http://wiki.jboss.org/wiki/Wiki.jsp?page=LdapLoginModule"&... from JBossSX. - It simply extends it so - all configuration that can be applied to <emphasis>LdapExtLoginModule</emphasis> also can be applied here. For user that - was authenticated successfully it will try to call identity modules from portal, check if such user - is present, and if not it will try to create it. Then for all roles assigned to this authenticated principal it will + <ulink url="http://wiki.jboss.org/wiki/Wiki.jsp?page=LdapLoginModule"&... from JBossSX. + It extends it so all configuration that can be applied to <emphasis>LdapExtLoginModule</emphasis> remains valid here. For a user that + was authenticated successfully it will try to call the identity modules from portal, then check if such user + exists or not, and if does not exist it will try to create it. Then for all roles assigned to this authenticated principal it will try to check and create them using identity modules. This behaviour can be altered using following options: <itemizedlist> <listitem> @@ -171,32 +170,30 @@ made around <ulink url="http://wiki.jboss.org/wiki/Wiki.jsp?page=LdapExtLoginModule&quo... from JBossSX. Sample configuration can look like this:</para> <programlisting><![CDATA[ - - <login-module code="org.jboss.portal.identity.auth.SynchronizingLDAPExtLoginModule" flag="required"> - <module-option name="synchronizeIdentity">true</module-option> - <module-option name="synchronizeRoles">true</module-option> - <module-option name="additionalRole">Authenticated</module-option> - <module-option name="defaultAssignedRole">User</module-option> - <module-option name="userModuleJNDIName">java:/portal/UserModule</module-option> - <module-option name="roleModuleJNDIName">java:/portal/RoleModule</module-option> - <module-option name="membershipModuleJNDIName">java:/portal/MembershipModule</module-option> - <module-option name="userProfileModuleJNDIName">java:/portal/UserProfileModule</module-option> - <module-option name="java.naming.factory.initial">com.sun.jndi.ldap.LdapCtxFactory</module-option> - <module-option name="java.naming.provider.url">ldap://example.com:10389/</module-option> - <module-option name="java.naming.security.authentication">simple</module-option> - <module-option name="bindDN">cn=Directory Manager</module-option> - <module-option name="bindCredential">secret</module-option> - <module-option name="baseCtxDN">ou=People,dc=example,dc=com</module-option> - <module-option name="baseFilter">(uid={0})</module-option> - <module-option name="rolesCtxDN">ou=Roles,dc=example,dc=com</module-option> - <module-option name="roleFilter">(member={1})</module-option> - <module-option name="roleAttributeID">cn</module-option> - <module-option name="roleRecursion">-1</module-option> - <module-option name="searchTimeLimit">10000</module-option> - <module-option name="searchScope">SUBTREE_SCOPE</module-option> - <module-option name="allowEmptyPasswords">false</module-option> - </login-module> - </mbean>]]> + <login-module code="org.jboss.portal.identity.auth.SynchronizingLDAPExtLoginModule" flag="required"> + <module-option name="synchronizeIdentity">true</module-option> + <module-option name="synchronizeRoles">true</module-option> + <module-option name="additionalRole">Authenticated</module-option> + <module-option name="defaultAssignedRole">User</module-option> + <module-option name="userModuleJNDIName">java:/portal/UserModule</module-option> + <module-option name="roleModuleJNDIName">java:/portal/RoleModule</module-option> + <module-option name="membershipModuleJNDIName">java:/portal/MembershipModule</module-option> + <module-option name="userProfileModuleJNDIName">java:/portal/UserProfileModule</module-option> + <module-option name="java.naming.factory.initial">com.sun.jndi.ldap.LdapCtxFactory</module-option> + <module-option name="java.naming.provider.url">ldap://example.com:10389/</module-option> + <module-option name="java.naming.security.authentication">simple</module-option> + <module-option name="bindDN">cn=Directory Manager</module-option> + <module-option name="bindCredential">secret</module-option> + <module-option name="baseCtxDN">ou=People,dc=example,dc=com</module-option> + <module-option name="baseFilter">(uid={0})</module-option> + <module-option name="rolesCtxDN">ou=Roles,dc=example,dc=com</module-option> + <module-option name="roleFilter">(member={1})</module-option> + <module-option name="roleAttributeID">cn</module-option> + <module-option name="roleRecursion">-1</module-option> + <module-option name="searchTimeLimit">10000</module-option> + <module-option name="searchScope">SUBTREE_SCOPE</module-option> + <module-option name="allowEmptyPasswords">false</module-option> +</login-module>]]> </programlisting> </sect2> <sect2 id="authentication.synchronizing_login_module"> @@ -205,8 +202,8 @@ This module is designed to provide synchronization support for any other LoginModule placed in the authentication stack. It leverages the fact that in JAAS authentication process occurs in two phases. In first phase when login() method is invoked it always returns "true". Because of this behaviour <emphasis>SynchronizingLoginModule</emphasis> should be always used with - "optional" flag.. - Morover it should be placed after module we want to leverage as a source for synchronization and this module should have "required" flag set. + "optional" flag. + More over it should be placed after the module we want to leverage as a source for synchronization and that module should have "required" flag set. During the second phase when commit() method is invoked it gets user <emphasis>Subject</emphasis> and its <emphasis>Principal</emphasis>s and tries to synchronize them into storage configured for portal identity modules. For this purposes such options are supported: <itemizedlist> Modified: docs/trunk/referenceGuide/en/modules/identity.xml =================================================================== --- docs/trunk/referenceGuide/en/modules/identity.xml 2007-04-17 13:20:32 UTC (rev 6985) +++ docs/trunk/referenceGuide/en/modules/identity.xml 2007-04-17 13:32:25 UTC (rev 6986) @@ -256,9 +256,9 @@ </itemizedlist> <sect2> - <title>Ways to access identity modules</title> + <title>How to obtain identity modules services ?</title> <para> - The best way to access identity modules is by using JNDI: + The advocated way to get a reference to the identity modules is by using JNDI: </para> <programlisting> import org.jboss.portal.identity.UserModule; @@ -273,7 +273,7 @@ (MembershipModule)new InitialContext().lookup("java:portal/MembershipModule"); (UserProfileModule)new InitialContext().lookup("java:portal/UserProfileModule");</programlisting> <para> - Another way to do this is, if you are fimiliar with JBoss Mikrokernel architecture is to + Another way to do this is, if you are fimiliar with JBoss Microkernel architecture is to get the <emphasis role="bold">IdentityServiceController</emphasis> mbean. You may want to inject it into your services like this: </para> @@ -371,30 +371,29 @@ </sect1> <sect1> <title>Identity configuration</title> - <para>At the beginning to understand identity configuration you need to understand how it is designed to work in portal. + <para>In order to understand identity configuration you need to understand its architecture. Different identity services like UserModule, RoleModule and etc are just plain java classes that are instantiated and exposed - by portal. So *example* UserModule service could be plain java bean object that will be: + by the portal. So an *example* of UserModule service could be a plain java bean object that would be: <itemizedlist> <listitem><emphasis role="bold">Instantiated</emphasis> using reflection</listitem> <listitem><emphasis role="bold">Initialized/Started</emphasis> by invoking some methods</listitem> <listitem><emphasis role="bold">Registered/Exposed</emphasis> using JNDI and/or mbeans (JBoss Microkernel) services, so - other citizens of the portal can use it</listitem> + other services of the portal can use it</listitem> <listitem><emphasis role="bold">Managed</emphasis> in the matter of lifecycle - so it'll be stopped and unregistered during portal shutdown</listitem> </itemizedlist> - As you see from this standpoint configuration just specifies which java class and how should be used by portal as a service. - <note>We use JBoss Microcontainer to manage state of those components so if you are interested in implementation of - custom ones - look on the methods that are leveraged by this framework.</note> + As you see from this point of view, configuration just specifies what java class will be used and how it should be used by portal as a service. + <note>We use JBoss Microcontainer internally to manage the sub system made of those components so if you are interested in implementing + custom services - look on the methods that are used by this framework.</note> </para> <para> - In JBoss Portal we provide very flexible configuration. It's very easy to rearrange and customize services, - provide and plug in own implementations, extend current ones or extend identity model with own solutions using - provided configuration service. + In JBoss Portal we provide a very flexible configuration. It is very easy to rearrange and customize services, + provide alternative implementations, extend the existing ones or provide a custom identity model. </para> - <para>To have the complete picture of the configuration of identity services lets start from it's root - component. Whole configuration and setup of identity components is made by - <emphasis role="bold">IdentityServiceController</emphasis>. It brings to life and registers all other components - like UserModule, RoleModule, MembershipModule and UserProfileModule. + <para>To grasp the full picture of the configuration of identity services let's start from its root + component. Whole configuration and setup of identity components is done by the + <emphasis role="bold">IdentityServiceController</emphasis> service. It brings to life and registers all other services + such as UserModule, RoleModule, MembershipModule and UserProfileModule. <emphasis role="bold">IdentityServiceController</emphasis> is defined in <emphasis>jboss-portal.sar/META-INF/jboss-service.xml</emphasis> </para> @@ -414,7 +413,7 @@ <attribute name="DefaultConfigFile">conf/identity/standardidentity-config.xml</attribute> </mbean>]]></programlisting> <para> - We can specify few options here: + We can specify a few options here: <itemizedlist> <listitem> <para> @@ -424,17 +423,17 @@ </listitem> <listitem> <para> - <emphasis role="bold">ConfigFile</emphasis> - defines location of main identity services configuration + <emphasis role="bold">ConfigFile</emphasis> - defines the location of the main identity services configuration file. It describes and configures all the components like UserModule, RoleModule... that need to be instantiated </para> </listitem> <listitem> <para> - <emphasis role="bold">DefaultConfigFile</emphasis> - defines location of configuration file containing - default values. For each component defined in <emphasis role="bold">ConfigFile</emphasis> IdentityServiceController - will look into this location to grab set of default options. This simply makes the main configuration file - simpler and shorter while still enabling more powerful customization. + <emphasis role="bold">DefaultConfigFile</emphasis> - defines the location of the configuration file containing + the default values. For each component defined in <emphasis role="bold">ConfigFile</emphasis>, the IdentityServiceController + will obtain a set of default options from this file. That helps to keep the main main configuration file + simple, short and easy to read. Potentially it provides more powerful customizations. </para> </listitem> </itemizedlist> @@ -471,7 +470,7 @@ <para>This section defines datasource components. They will be processed and instantiated before components in <emphasis role="bold">Module</emphasis> section, so they will be ready to serve them.</para> <note>This section isn't used with Database configuration as in JBoss Portal services exposing Hibernate - are defined separately. It's used by LDAP configuration and we'll use it as an example</note> + are defined separately. It is used by LDAP configuration and we will use it as an example</note> <programlisting><![CDATA[ <datasource> <name>LDAP</name> @@ -501,8 +500,8 @@ </datasource>]]></programlisting> <note>If you look into JBoss Portal configuration files you will find that <![CDATA[<service-name/> and <class/>]]> are specified in <emphasis role="bold">DefaultConfigFile</emphasis> and not in <emphasis role="bold">ConfigFile</emphasis>. - So this is how it works. Those two will be picked up from default configuration. The same rule takes place - for options - additional will be picked up from default configuration. What is linking configuration in those two files + So here is how it works: those two will be picked up from default configuration. The same rule is effective + for the options - additional options will be picked up from default configuration. What is linking configuration in those two files is the <emphasis role="bold"><![CDATA[<name>]]></emphasis> tag.</note> </sect3> <sect3> @@ -534,22 +533,22 @@ <listitem> <para> <emphasis role="bold">implementation</emphasis> - defines the scope under which - configuration for different implementations of modules <emphasis role="bold">type</emphasis>s are kept. - It enables to keep configurations of different implementations of same module types in one configuration file - with default options. + the configuration for different implementations of modules <emphasis role="bold">type</emphasis>s resides. + It enables to define the default options of the configuration of the different implementations of + same module types in one configuration file. </para> </listitem> <listitem> <para> <emphasis role="bold">type</emphasis> - must be unique name across all modules defined in the main configuration file. This is important as module will be stored with such name within IdentityContext - registry on runtime. Standard names are used (User, Role, Membership, UserProfile). Together with + registry at runtime. Standard names are used (User, Role, Membership, UserProfile). Together with <emphasis role="bold">implementation</emphasis> will create unique pair within file with default configuration values. </para> </listitem> <listitem> <para> - <emphasis role="bold">service-name</emphasis> - will be used for registration as an MBean. + <emphasis role="bold">service-name</emphasis> - will be used for the name when registered as an MBean. </para> </listitem> <listitem> @@ -574,16 +573,16 @@ <implementation>DB</implementation> <config/> </module>]]></programlisting> - As you see we specify only type and implementation - all the other values (service-name, class and set of options) - will be taken from default configuration. But remember that still you can overwrite any of those values in the - main config simply by specifying them. + As you can see we specify only the type and the implementation - all the other values (service-name, class and set of options) + are read from default configuration. But remember that you can still overwrite any of those values in the + main config simply by overriding them. </note> </sect3> <sect3> <title>Options</title> - <para>This section provides common options that are accessible by identity modules. We put here options - that may need to be shared. They are grouped, and can have many values:</para> + <para>This section provides common options that are accessible by identity modules. We set options + here that may need to be shared. They are grouped, and can have many values:</para> <programlisting><![CDATA[ <options> <!--Common options section--> @@ -641,9 +640,9 @@ <value>none</value> </option> </option-group>]]></programlisting> - <note>In this section we use the same inheritance mechanism. When option is not set, it's value will be taken - from the default config file. But this also means that you need to overwrite some values that - are specific for your LDAP architecture. All the options will be described along with module implementations + <note>In this section we use the same inheritance mechanism. When an option is not set, its value will be read + from the default config file. But this also means that you may need to overwrite some values that + are specific to your LDAP architecture. All the options will be described along with module implementations that use them.</note> </sect3> </sect2> @@ -730,12 +729,13 @@ </properties> ]]> </programlisting> - Configuration file contains properties definition that can be retrieved using <emphasis role="bold">PropertyInfo</emphasis> interface. - Every property that will be used in portal need to be registered here. - <note>Some information provided for property have big influence on the behaviour of UserProfileModule. For example - <emphasis>access-mode</emphasis> can made property read-only, and value provided in <emphasis>type</emphasis> will be checked + Configuration file contains properties definition that can be retrieved using the <emphasis role="bold">PropertyInfo</emphasis> interface. + Each property used in portal has to be defined here. + <note>Some information provided here can have a large impact on the behaviour of the UserProfileModule. For instance + <emphasis>access-mode</emphasis> can be made read-only and the value provided in <emphasis>type</emphasis> will be checked during <emphasis>setProperty()/getProperty()</emphasis> operations. On the other hand tags like <emphasis>usage</emphasis>, - <emphasis>description</emphasis> or <emphasis>display-name</emphasis> have mostly informational meaning at the moment</note> + <emphasis>description</emphasis> or <emphasis>display-name</emphasis> have mostly informational meaning at the moment and + are used by the management tools at runtime.</note> <itemizedlist> <listitem> <emphasis role="bold">name</emphasis> - property name. This value will be used to refer to the property in <emphasis>UserProfileModule</emphasis> @@ -783,7 +783,7 @@ <para>JBoss portal comes with a set of database related identity modules implementations done using Hibernate - those are configured by default. Those are not very configurable in <emphasis>identity-config.xml</emphasis> file. The reason is that to keep backwards compatibility of database schema with previous - portal version, we reused most of hibernate implementation. If you want to trigger hibernate mappings you should look into files in + portal version, we reused most of hibernate implementation. If you want to tweak the hibernate mappings you should look into files in <emphasis role="bold">jboss-portal.sar/conf/hibernate</emphasis>. Also those modules rely on hibernate <emphasis>SessionFactory</emphasis> components that are created in <emphasis>SessionFactoryBinder</emphasis> mbeans defined in <emphasis>jboss-portal.sar/META-INF/jboss-service.xml</emphasis></para> <para>Classes implementing identity modules: @@ -816,8 +816,9 @@ <sect2 id="identity.management_api"> <title>Delegating UserProfile module</title> <para>Delegating UserProfileModule implementation has very specific role. When we use storage mechanism like LDAP we may not be able to map all - user properties into LDAP attributes because of schema limitations. To solve this problem we use database to store such not mapped properties. - Delegating user profile module will recognize if property is mapped as <emphasis role="bold">ldap</emphasis> or <emphasis role="bold">database</emphasis> + user properties into LDAP attributes because of schema limitations. To solve this problem we still can use the database to store user properties + that do not exist in the LDAP schema. + Delegating user profile module will recognize if a property is mapped as <emphasis role="bold">ldap</emphasis> or <emphasis role="bold">database</emphasis> and delegate <emphasis>setProperty()/getProperty()</emphasis> method invocation to proper module implementation. This is implemented in <emphasis role="bold">org.jboss.portal.identity.DelegatingUserProfileModuleImpl</emphasis>. If property is mapped either as <emphasis role="bold">ldap</emphasis> and <emphasis role="bold">database</emphasis> the <emphasis role="bold">ldap</emphasis> mapping will @@ -825,31 +826,30 @@ </para> <programlisting> <![CDATA[ - <module> - <!--type used to correctly map in IdentityContext registry--> - <type>UserProfile</type> - <implementation>DELEGATING</implementation> +<module> + <!--type used to correctly map in IdentityContext registry--> + <type>UserProfile</type> + <implementation>DELEGATING</implementation> - <!--name of service and class for creating mbean--> - <service-name>portal:service=Module,type=UserProfile</service-name> - <class>org.jboss.portal.identity.DelegatingUserProfileModuleImpl</class> - <!--set of options that are set in instantiated object--> - <config> - <option> - <name>jNDIName</name> - <value>java:/portal/UserProfileModule</value> - </option> - <option> - <name>dbModuleJNDIName</name> - <value>java:/portal/DBUserProfileModule</value> - </option> - <option> - <name>profileConfigFile</name> - <value>conf/identity/profile-config.xml</value> - </option> - </config> - </module> - ]]> + <!--name of service and class for creating mbean--> + <service-name>portal:service=Module,type=UserProfile</service-name> + <class>org.jboss.portal.identity.DelegatingUserProfileModuleImpl</class> + <!--set of options that are set in instantiated object--> + <config> + <option> + <name>jNDIName</name> + <value>java:/portal/UserProfileModule</value> + </option> + <option> + <name>dbModuleJNDIName</name> + <value>java:/portal/DBUserProfileModule</value> + </option> + <option> + <name>profileConfigFile</name> + <value>conf/identity/profile-config.xml</value> + </option> + </config> +</module>]]> </programlisting> <para> Module options are: @@ -868,27 +868,27 @@ </sect2> <sect2> <title>Database UserProfile module implementation</title> - <para>Because of behaviour described in previous section database UserProfileModule needs some special capabilities. If user is present in - LDAP server but property we want to store isn't mapped as LDAP attribute such property need to be stored in database. But to store - the property user need to be synchronized from ldap into database first</para> + <para>Because of the behaviour described in the previous section, database UserProfileModule requires some special features. If a user is present in + LDAP server but a writable property isn't mapped as an LDAP attribute, such property requires to be stored in the database. In order to achieve + such result the user need to be synchronized from ldap into the database first.</para> <para>Class <emphasis>org.jboss.portal.identity.db.HibernateUserProfileModuleImpl</emphasis> has additional synchronization features. Here are the options: <itemizedlist> <listitem> - <emphasis role="bold">synchronizeNonExistingUsers</emphasis> - when set to "true" if user on which we want to perform operation doesn't exist it will - create it in database. Default is "true". + <emphasis role="bold">synchronizeNonExistingUsers</emphasis> - when set to "true" if the user subject to the operation does not exist, then it will + created it in database. By default it is "true". </listitem> <listitem> <emphasis role="bold">acceptOtherImplementations</emphasis> - if set to "true" module will accept user objects other than <emphasis>org.jboss.portal.identity.db.HibernateUserImpl</emphasis>. This is needed to enable cooperation with UserModule implementations other - than <emphasis>org.jboss.portal.identity.db.HibernateUserModuleImpl</emphasis>. Default is "true". + than <emphasis>org.jboss.portal.identity.db.HibernateUserModuleImpl</emphasis>. The default value is set "true". </listitem> <listitem> <emphasis role="bold">defaultSynchronizePassword</emphasis> - if this option is set, the value will be used as a password for synchronized user. </listitem> <listitem> <emphasis role="bold">randomSynchronizePassword</emphasis> - if this option is set to "true" synchronized user will have random generated password. - This is mostly used for the security reasons. Default is "false". + This is mostly used for the security reasons. Default value is "false". </listitem> <listitem> <emphasis role="bold">sessionFactoryJNDIName</emphasis> - JNDI name under which this user will be registered. @@ -899,7 +899,6 @@ </listitem> </itemizedlist> </para> - </sect2> </sect1> </chapter> Modified: docs/trunk/referenceGuide/en/modules/ldap.xml =================================================================== --- docs/trunk/referenceGuide/en/modules/ldap.xml 2007-04-17 13:20:32 UTC (rev 6985) +++ docs/trunk/referenceGuide/en/modules/ldap.xml 2007-04-17 13:32:25 UTC (rev 6986) @@ -8,12 +8,12 @@ </chapterinfo> <title>LDAP</title> <para>This chapter describes how to setup LDAP support in JBoss Portal</para> - <note>To be able to fully understand this chapter you should study <link linkend="identity">JBoss Portal Identity management</link> and + <note>To be able to fully understand this chapter you should also read <link linkend="identity">JBoss Portal Identity management</link> and <link linkend="authentication">Authentication</link> chapters before</note> <sect1> <title>How to enable LDAP usage in JBoss Portal</title> - <para>We'll describe here the simple steps that you'll need to perform to enable LDAP support in JBoss Portal. - For additional information you need to study more about configuration of identity and specific implementations of identity modules</para> + <para>We'll describe here the simple steps that you will need to perform to enable LDAP support in JBoss Portal. + For additional information you need to read more about configuration of identity and specific implementations of identity modules</para> <para>There are two ways to achieve this:</para> <itemizedlist> <listitem> @@ -52,7 +52,7 @@ </listitem> </itemizedlist> <para> - After doing one of above changes you need to edit configuration file that you choose to + After doing one of the above changes you need to edit configuration file that you choose to use (identity-config.xml or ldap_identity-config.xml) and configure LDAP connection options in section: </para> <programlisting><![CDATA[ @@ -211,16 +211,13 @@ <para>This is the base implementation of LDAP <emphasis>UserModule</emphasis>. It supports user creation, but will retreive users and create them in strictly specified place in LDAP tree.</para> <para>To enable it in your configuration you should have: - <programlisting> - <![CDATA[ - <module> - <!--type used to correctly map in IdentityContext registry--> - <type>User</type> - <implementation>LDAP</implementation> - <config/> - </module> - ]]> - </programlisting> + <programlisting><![CDATA[ +<module> + <!--type used to correctly map in IdentityContext registry--> + <type>User</type> + <implementation>LDAP</implementation> + <config/> +</module>]]></programlisting> </para> <para>org.jboss.portal.identity.ldap.LDAPUserModuleImpl configuration option-groups options: <itemizedlist> @@ -252,42 +249,40 @@ Example configuration: <programlisting> <![CDATA[ - <option-group> - <group-name>common</group-name> - <option> - <name>userCtxDN</name> - <value>ou=People,o=portal,dc=my-domain,dc=com</value> - </option> - <option> - <name>uidAttributeID</name> - <value>uid</value> - </option> - <option> - <name>passwordAttributeID</name> - <value>userPassword</value> - </option> - </option-group> - <option-group> - <group-name>userCreateAttibutes</group-name> - <option> - <name>objectClass</name> - <!--This objectclasses should work with Red Hat Directory--> - <value>top</value> - <value>person</value> - <value>inetOrgPerson</value> - </option> - <!--Schema requires those to have initial value--> - <option> - <name>cn</name> - <value>none</value> - </option> - <option> - <name>sn</name> - <value>none</value> - </option> - </option-group> - ]]> - </programlisting> +<option-group> + <group-name>common</group-name> + <option> + <name>userCtxDN</name> + <value>ou=People,o=portal,dc=my-domain,dc=com</value> + </option> + <option> + <name>uidAttributeID</name> + <value>uid</value> + </option> + <option> + <name>passwordAttributeID</name> + <value>userPassword</value> + </option> +</option-group> +<option-group> + <group-name>userCreateAttibutes</group-name> + <option> + <name>objectClass</name> + <!--This objectclasses should work with Red Hat Directory--> + <value>top</value> + <value>person</value> + <value>inetOrgPerson</value> + </option> + <!--Schema requires those to have initial value--> + <option> + <name>cn</name> + <value>none</value> + </option> + <option> + <name>sn</name> + <value>none</value> + </option> +</option-group>]]></programlisting> </para> </sect3> @@ -296,16 +291,14 @@ <para>Aim of this implementation is to give more flexibility for users retreival. You can specify LDAP filter that will be used for searches. This module doesn't support user creation and removal</para> <para>To enable it in your configuration you should have: - <programlisting> - <![CDATA[ - <module> - <!--type used to correctly map in IdentityContext registry--> - <type>User</type> - <implementation>LDAP</implementation> - <class>org.jboss.portal.identity.ldap.LDAPExtUserModuleImpl</class> - <config/> - </module> - ]]> + <programlisting><![CDATA[ +<module> + <!--type used to correctly map in IdentityContext registry--> + <type>User</type> + <implementation>LDAP</implementation> + <class>org.jboss.portal.identity.ldap.LDAPExtUserModuleImpl</class> + <config/> +</module]]> </programlisting> </para> <para>org.jboss.portal.identity.ldap.LDAPExtUserModuleImpl configuration option-groups options: @@ -392,15 +385,13 @@ <para>This is the base implementation of LDAP <emphasis>RoleModule</emphasis>. It supports user creation, but will retreive roles and create them in strictly specified place in LDAP tree.</para> <para>To enable it in your configuration you should have: - <programlisting> - <![CDATA[ - <module> - <!--type used to correctly map in IdentityContext registry--> - <type>Role</type> - <implementation>LDAP</implementation> - <config/> - </module> - ]]> + <programlisting><![CDATA[ +<module> + <!--type used to correctly map in IdentityContext registry--> + <type>Role</type> + <implementation>LDAP</implementation> + <config/> +</module>]]> </programlisting> </para> <para>org.jboss.portal.identity.ldap.LDAPRoleModuleImpl configuration option-groups options: @@ -431,16 +422,14 @@ that will be used for searches. This module doesn't support role creation and removal</para> <para>This module doesn't support role creation and removal</para> <para>To enable it in your configuration you should have: - <programlisting> - <![CDATA[ - <module> - <!--type used to correctly map in IdentityContext registry--> - <type>Role</type> - <implementation>LDAP</implementation> - <class>org.jboss.portal.identity.ldap.LDAPExtRoleModuleImpl</class> - <config/> - </module> - ]]> + <programlisting><![CDATA[ +<module> + <!--type used to correctly map in IdentityContext registry--> + <type>Role</type> + <implementation>LDAP</implementation> + <class>org.jboss.portal.identity.ldap.LDAPExtRoleModuleImpl</class> + <config/> +</module>]]> </programlisting> </para> <para>org.jboss.portal.identity.ldap.LDAPExtRoleModuleImpl configuration option-groups options: @@ -544,15 +533,13 @@ <title>LDAPStaticGroupMembershipModuleImpl</title> <para>This module support tree shape where role entries keep information about users that are their members.</para> <para>To enable it in your configuration you should have: - <programlisting> - <![CDATA[ - <module> - <!--type used to correctly map in IdentityContext registry--> - <type>Membership</type> - <implementation>LDAP</implementation> - <config/> - </module> - ]]> + <programlisting><![CDATA[ +<module> + <!--type used to correctly map in IdentityContext registry--> + <type>Membership</type> + <implementation>LDAP</implementation> + <config/> +</module>]]> </programlisting> </para> <para>org.jboss.portal.identity.ldap.LDAPStaticGroupMembershipModuleImpl configuration option-groups options: @@ -577,16 +564,14 @@ <title>LDAPStaticRoleMembershipModuleImpl</title> <para>This module support tree shape where user entries keep information about roles that they belong to.</para> <para>To enable it in your configuration you should have: - <programlisting> - <![CDATA[ - <module> - <!--type used to correctly map in IdentityContext registry--> - <type>Membership</type> - <implementation>LDAP</implementation> - <class>org.jboss.portal.identity.ldap.LDAPStaticRoleMembershipModuleImpl</class> - <config/> - </module> - ]]> + <programlisting><![CDATA[ +<module> + <!--type used to correctly map in IdentityContext registry--> + <type>Membership</type> + <implementation>LDAP</implementation> + <class>org.jboss.portal.identity.ldap.LDAPStaticRoleMembershipModuleImpl</class> + <config/> +</module>]]> </programlisting> </para> <para>org.jboss.portal.identity.ldap.LDAPStaticRoleMembershipModuleImpl configuration option-groups options: @@ -614,34 +599,32 @@ <title>LDAPUserProfileModuleImpl</title> <para>This is standard implementation that enables to retreive user properties from atributes in LDAP entries.</para> <para>To enable it in your configuration you should have: - <programlisting> - <![CDATA[ - <module> - <type>UserProfile</type> - <implementation>DELEGATING</implementation> - <config> - <option> - <name>ldapModuleJNDIName</name> - <value>java:/portal/LDAPUserProfileModule</value> - </option> - </config> - </module> - <module> - <type>DBDelegateUserProfile</type> - <implementation>DB</implementation> - <config> - <option> - <name>randomSynchronizePassword</name> - <value>true</value> - </option> - </config> - </module> - <module> - <type>LDAPDelegateUserProfile</type> - <implementation>LDAP</implementation> - <config/> - </module> - ]]> + <programlisting><![CDATA[ +<module> + <type>UserProfile</type> + <implementation>DELEGATING</implementation> + <config> + <option> + <name>ldapModuleJNDIName</name> + <value>java:/portal/LDAPUserProfileModule</value> + </option> + </config> +</module> +<module> + <type>DBDelegateUserProfile</type> + <implementation>DB</implementation> + <config> + <option> + <name>randomSynchronizePassword</name> + <value>true</value> + </option> + </config> +</module> +<module> + <type>LDAPDelegateUserProfile</type> + <implementation>LDAP</implementation> + <config/> +</module>]]> </programlisting> <note>Using such configuration you will have LDAP MembershipModule along with DB MembershipModule and Delegating MembershipModule. Please read <link linkend="identity.management_api">Identity</link> chapter to see why this is important. @@ -698,8 +681,7 @@ <sect3> <title>Example LDIF</title> <para> - <programlisting> - <![CDATA[ + <programlisting><![CDATA[ dn: dc=example,dc=com objectclass: top objectclass: dcObject @@ -749,109 +731,103 @@ objectClass: groupOfNames cn: Echo description: the JBoss Portal admin group -member: uid=admin,ou=People,dc=example,dc=com - ]]> - </programlisting> +member: uid=admin,ou=People,dc=example,dc=com]]></programlisting> </para> </sect3> <sect3> <title>Example identity configuration</title> <para> - <programlisting> - <![CDATA[ - <modules> - <module> - <!--type used to correctly map in IdentityContext registry--> - <type>User</type> - <implementation>LDAP</implementation> - <config/> - </module> - <module> - <type>Role</type> - <implementation>LDAP</implementation> - <config/> - </module> - <module> - <type>Membership</type> - <implementation>LDAP</implementation> - <config/> - </module> - <module> - <type>UserProfile</type> - <implementation>DELEGATING</implementation> - <config> - <option> - <name>ldapModuleJNDIName</name> - <value>java:/portal/LDAPUserProfileModule</value> - </option> - </config> - </module> - <module> - <type>DBDelegateUserProfile</type> - <implementation>DB</implementation> - <config> - <option> - <name>randomSynchronizePassword</name> - <value>true</value> - </option> - </config> - </module> - <module> - <type>LDAPDelegateUserProfile</type> - <implementation>LDAP</implementation> - <config/> - </module> - </modules> - - <options> - <option-group> - <group-name>common</group-name> + <programlisting><![CDATA[ + <modules> + <module> + <!--type used to correctly map in IdentityContext registry--> + <type>User</type> + <implementation>LDAP</implementation> + <config/> + </module> + <module> + <type>Role</type> + <implementation>LDAP</implementation> + <config/> + </module> + <module> + <type>Membership</type> + <implementation>LDAP</implementation> + <config/> + </module> + <module> + <type>UserProfile</type> + <implementation>DELEGATING</implementation> + <config> <option> - <name>userCtxDN</name> - <value>ou=People,dc=example,dc=com</value> + <name>ldapModuleJNDIName</name> + <value>java:/portal/LDAPUserProfileModule</value> </option> + </config> + </module> + <module> + <type>DBDelegateUserProfile</type> + <implementation>DB</implementation> + <config> <option> - <name>roleCtxDN</name> - <value>ou=Roles,dc=example,dc=com</value> + <name>randomSynchronizePassword</name> + <value>true</value> </option> - </option-group> - <option-group> - <group-name>userCreateAttibutes</group-name> - <option> - <name>objectClass</name> - <!--This objectclasses should work with Red Hat Directory--> - <value>top</value> - <value>person</value> - <value>inetOrgPerson</value> - </option> - <!--Schema requires those to have initial value--> - <option> - <name>cn</name> - <value>none</value> - </option> - <option> - <name>sn</name> - <value>none</value> - </option> - </option-group> - <option-group> - <group-name>roleCreateAttibutes</group-name> - <!--Schema requires those to have initial value--> - <option> - <name>cn</name> - <value>none</value> - </option> - <!--Some directory servers require this attribute to be valid DN--> - <!--For safety reasons point to the admin user here--> - <option> - <name>member</name> - <value>uid=admin,ou=People,dc=example,dc=com</value> - </option> - </option-group> - </options> + </config> + </module> + <module> + <type>LDAPDelegateUserProfile</type> + <implementation>LDAP</implementation> + <config/> + </module> +</modules> - ]]> - </programlisting> +<options> + <option-group> + <group-name>common</group-name> + <option> + <name>userCtxDN</name> + <value>ou=People,dc=example,dc=com</value> + </option> + <option> + <name>roleCtxDN</name> + <value>ou=Roles,dc=example,dc=com</value> + </option> + </option-group> + <option-group> + <group-name>userCreateAttibutes</group-name> + <option> + <name>objectClass</name> + <!--This objectclasses should work with Red Hat Directory--> + <value>top</value> + <value>person</value> + <value>inetOrgPerson</value> + </option> + <!--Schema requires those to have initial value--> + <option> + <name>cn</name> + <value>none</value> + </option> + <option> + <name>sn</name> + <value>none</value> + </option> + </option-group> + <option-group> + <group-name>roleCreateAttibutes</group-name> + <!--Schema requires those to have initial value--> + <option> + <name>cn</name> + <value>none</value> + </option> + <!--Some directory servers require this attribute to be valid DN--> + <!--For safety reasons point to the admin user here--> + <option> + <name>member</name> + <value>uid=admin,ou=People,dc=example,dc=com</value> + </option> + </option-group> +</options>]]></programlisting> </para> </sect3> @@ -877,8 +853,7 @@ <sect3> <title>Example LDIF</title> <para> - <programlisting> - <![CDATA[ + <programlisting><![CDATA[ dn: dc=example,dc=com objectclass: top objectclass: dcObject @@ -933,113 +908,108 @@ objectClass: top objectClass: organizationalRole cn: Echo -description: the JBoss Portal admin group - ]]> - </programlisting> +description: the JBoss Portal admin group]]></programlisting> </para> </sect3> <sect3> <title>Example identity configuration</title> <para> - <programlisting> - <![CDATA[ - <modules> - <module> - <!--type used to correctly map in IdentityContext registry--> - <type>User</type> - <implementation>LDAP</implementation> - <config/> - </module> - <module> - <type>Role</type> - <implementation>LDAP</implementation> - <config/> - </module> - <module> - <type>Membership</type> - <implementation>LDAP</implementation> - <class>org.jboss.portal.identity.ldap.LDAPStaticRoleMembershipModuleImpl</class> - <config/> - </module> - <module> - <type>UserProfile</type> - <implementation>DELEGATING</implementation> - <config> - <option> - <name>ldapModuleJNDIName</name> - <value>java:/portal/LDAPUserProfileModule</value> - </option> - </config> - </module> - <module> - <type>DBDelegateUserProfile</type> - <implementation>DB</implementation> - <config> - <option> - <name>randomSynchronizePassword</name> - <value>true</value> - </option> - </config> - </module> - <module> - <type>LDAPDelegateUserProfile</type> - <implementation>LDAP</implementation> - <config/> - </module> - </modules> - - <options> - <option-group> - <group-name>common</group-name> + <programlisting><![CDATA[ + <modules> + <module> + <!--type used to correctly map in IdentityContext registry--> + <type>User</type> + <implementation>LDAP</implementation> + <config/> + </module> + <module> + <type>Role</type> + <implementation>LDAP</implementation> + <config/> + </module> + <module> + <type>Membership</type> + <implementation>LDAP</implementation> + <class>org.jboss.portal.identity.ldap.LDAPStaticRoleMembershipModuleImpl</class> + <config/> + </module> + <module> + <type>UserProfile</type> + <implementation>DELEGATING</implementation> + <config> <option> - <name>userCtxDN</name> - <value>ou=People,dc=example,dc=com</value> + <name>ldapModuleJNDIName</name> + <value>java:/portal/LDAPUserProfileModule</value> </option> + </config> + </module> + <module> + <type>DBDelegateUserProfile</type> + <implementation>DB</implementation> + <config> <option> - <name>roleCtxDN</name> - <value>ou=Roles,dc=example,dc=com</value> + <name>randomSynchronizePassword</name> + <value>true</value> </option> - <option> - <name>membershipAttributeID</name> - <value>memberOf</value> - </option> - </option-group> - <option-group> - <group-name>userCreateAttibutes</group-name> - <option> - <name>objectClass</name> - <!--This objectclasses should work with Red Hat Directory--> - <value>top</value> - <value>person</value> - <value>inetOrgPerson</value> - </option> - <!--Schema requires those to have initial value--> - <option> - <name>cn</name> - <value>none</value> - </option> - <option> - <name>sn</name> - <value>none</value> - </option> - </option-group> - <option-group> - <group-name>roleCreateAttibutes</group-name> - <!--Schema requires those to have initial value--> - <option> - <name>cn</name> - <value>none</value> - </option> - <!--Some directory servers require this attribute to be valid DN--> - <!--For safety reasons point to the admin user here--> - <option> - <name>member</name> - <value>uid=admin,ou=People,dc=example,dc=com</value> - </option> - </option-group> - </options> - ]]> - </programlisting> + </config> + </module> + <module> + <type>LDAPDelegateUserProfile</type> + <implementation>LDAP</implementation> + <config/> + </module> +</modules> + +<options> + <option-group> + <group-name>common</group-name> + <option> + <name>userCtxDN</name> + <value>ou=People,dc=example,dc=com</value> + </option> + <option> + <name>roleCtxDN</name> + <value>ou=Roles,dc=example,dc=com</value> + </option> + <option> + <name>membershipAttributeID</name> + <value>memberOf</value> + </option> + </option-group> + <option-group> + <group-name>userCreateAttibutes</group-name> + <option> + <name>objectClass</name> + <!--This objectclasses should work with Red Hat Directory--> + <value>top</value> + <value>person</value> + <value>inetOrgPerson</value> + </option> + <!--Schema requires those to have initial value--> + <option> + <name>cn</name> + <value>none</value> + </option> + <option> + <name>sn</name> + <value>none</value> + </option> + </option-group> + <option-group> + <group-name>roleCreateAttibutes</group-name> + <!--Schema requires those to have initial value--> + <option> + <name>cn</name> + <value>none</value> + </option> + <!--Some directory servers require this attribute to be valid DN--> + <!--For safety reasons point to the admin user here--> + <option> + <name>member</name> + <value>uid=admin,ou=People,dc=example,dc=com</value> + </option> + </option-group> +</options>]]></programlisting> </para> </sect3> </sect2> @@ -1060,8 +1030,7 @@ This is important as we will leverage them, and we want to synchronize users identity into default portal storage mechanism. So lets look at simple configuration that should take place in <emphasis>jboss-portal.sar/conf/login-config.xml</emphasis> - <programlisting> - <![CDATA[ + <programlisting><![CDATA[ <policy> <!-- For the JCR CMS --> <application-policy name="cms"> @@ -1103,9 +1072,7 @@ </authentication> </application-policy> -</policy> - ]]> - </programlisting> +</policy>]]></programlisting> </para> <para> Few things are important in this configuration: Modified: docs/trunk/referenceGuide/en/modules/sso.xml =================================================================== --- docs/trunk/referenceGuide/en/modules/sso.xml 2007-04-17 13:20:32 UTC (rev 6985) +++ docs/trunk/referenceGuide/en/modules/sso.xml 2007-04-17 13:32:25 UTC (rev 6986) @@ -11,15 +11,15 @@ <sect1> <title>Overview of SSO in portal</title> <para>Portal as an integration and aggregation platform provides some form of SSO by itself. When you log into - portal you gain access to many systems accessed with portlets using single identity. Still in many cases you - need to integrate portal infrastructure with other SSO enabled systems. There are many different Identity Management - solutions on the market. In most cases each SSO framework provides its own way to plug into JEE application. For custom configurations - you need to have good understanding of <link linkend="identity">JBoss Portal Identity management</link> and <link linkend="authentication">authentication</link> + the portal you gain access to many systems through portlets using a single identity. Still in many cases you + need to integrate the portal infrastructure with other SSO enabled systems. There are many different Identity Management + solutions on the market. In most cases each SSO framework provides its own way to plug into Java EE application. For custom configurations + you need to have a good understanding of <link linkend="identity">JBoss Portal Identity management</link> and <link linkend="authentication">authentication</link> mechanisms.</para> </sect1> <sect1> <title>Using Tomcat Valve</title> - <para>JBoss Application Server embeds Apache Tomcat as default servlet container. Tomcat provides builtin SSO support + <para>JBoss Application Server embeds Apache Tomcat as the default servlet container. Tomcat provides a builtin SSO support using a valve. The Single Sign On Valve caches credentials on the server side, and then invisibly authenticate users when they reach different web applications. Credentials are stored in a host-wide session which means that SSO will be effective throughout the session. </para> @@ -31,13 +31,12 @@ following line: <programlisting> <![CDATA[ - <Valve className=’org.apache.catalina.authenticator.SingleSignOn’/> - ]]> +<Valve className=’org.apache.catalina.authenticator.SingleSignOn’/>]]> </programlisting> </para> </sect2> <sect2> - <title>Example usage</title> + <title>Example of usage</title> <para> Lets look a little bit closer and configure SSO between portal and other web application. As an example we'll use <emphasis>jmx-console</emphasis> web-app that comes with every JBoss Application Server installation. @@ -51,39 +50,38 @@ <para>Edit <emphasis>$JBOSS_HOME/server/default/deploy/jmx-console.war/WEB-INF/web.xml</emphasis> file and make sure it contains following content:</para> <programlisting> <![CDATA[ - <security-constraint> - <web-resource-collection> - <web-resource-name>HtmlAdaptor</web-resource-name> - <description>An example security config that only allows users with the - role JBossAdmin to access the HTML JMX console web application - </description> - <url-pattern>/*</url-pattern> - <http-method>GET</http-method> - <http-method>POST</http-method> - </web-resource-collection> - <auth-constraint> - <role-name>Admin</role-name> - </auth-constraint> - </security-constraint> - <security-constraint> - <web-resource-collection> - <web-resource-name>Public</web-resource-name> - <url-pattern>/public/*</url-pattern> - <http-method>GET</http-method> - <http-method>POST</http-method> - </web-resource-collection> - </security-constraint> +<security-constraint> + <web-resource-collection> + <web-resource-name>HtmlAdaptor</web-resource-name> + <description>An example security config that only allows users with the + role JBossAdmin to access the HTML JMX console web application + </description> + <url-pattern>/*</url-pattern> + <http-method>GET</http-method> + <http-method>POST</http-method> + </web-resource-collection> + <auth-constraint> + <role-name>Admin</role-name> + </auth-constraint> +</security-constraint> - <login-config> - <auth-method>BASIC</auth-method> - <realm-name>jmx-console</realm-name> - </login-config> +<security-constraint> + <web-resource-collection> + <web-resource-name>Public</web-resource-name> + <url-pattern>/public/*</url-pattern> + <http-method>GET</http-method> + <http-method>POST</http-method> + </web-resource-collection> +</security-constraint> +<login-config> + <auth-method>BASIC</auth-method> + <realm-name>jmx-console</realm-name> +</login-config> - <security-role> - <role-name>Admin</role-name> - </security-role> - ]]> +<security-role> + <role-name>Admin</role-name> +</security-role>]]> </programlisting> <para>This will secure <emphasis>jmx-console</emphasis> web application using BASIC browser authentication and restrict access for users with <emphasis>Admin</emphasis> role only.</para> @@ -94,8 +92,7 @@ </para> <programlisting> <![CDATA[ - admin=JBossAdmin,HttpInvoker,Admin - ]]> +admin=JBossAdmin,HttpInvoker,Admin]]> </programlisting> <para> This file is a simple identity store for this web application authentication. It will make user <emphasis>admin</emphasis> belongs to <emphasis>Admin</emphasis> role. @@ -129,8 +126,7 @@ following line: <programlisting> <![CDATA[ - <Valve className=’org.apache.catalina.authenticator.SingleSignOn’/> - ]]> +<Valve className=’org.apache.catalina.authenticator.SingleSignOn’/>]]> </programlisting> </para> <para>