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>