From portal-commits at lists.jboss.org Sat Mar 3 16:34:34 2007 Content-Type: multipart/mixed; boundary="===============2597329985467139266==" MIME-Version: 1.0 From: portal-commits at lists.jboss.org To: portal-commits at lists.jboss.org Subject: [portal-commits] JBoss Portal SVN: r6510 - docs/trunk/referenceGuide/en/modules. Date: Sat, 03 Mar 2007 16:34:34 -0500 Message-ID: --===============2597329985467139266== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Author: bdaw Date: 2007-03-03 16:34:34 -0500 (Sat, 03 Mar 2007) New Revision: 6510 Modified: docs/trunk/referenceGuide/en/modules/identity.xml Log: update Modified: docs/trunk/referenceGuide/en/modules/identity.xml =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- docs/trunk/referenceGuide/en/modules/identity.xml 2007-03-03 21:03:18 U= TC (rev 6509) +++ docs/trunk/referenceGuide/en/modules/identity.xml 2007-03-03 21:34:34 U= TC (rev 6510) @@ -815,6 +815,90 @@ Delegating UserProfile module + Delegating UserProfile module implementation has very speci= fic role. When we use storage mechanism like LDAP we may not be able to map= all + user properties into LDAP attributes because of schema limitation= s. To solve this problem we use database to store such not mapped propertie= s. + Delegating user profile module will recognize if property is mapp= ed as ldap or da= tabase + end delegate setProperty()/getProperty() met= hod invocation to proper module implementation. This is implemented in + org.jboss.portal.identity.DelegatingUserP= rofileModuleImpl. If property is mapped either as + ldap and database the ldap mapping = will + have higher priority. + + + + + UserProfile + DELEGATING + + + portal:service=3DModule,type=3DUserProfile + org.jboss.portal.identity.DelegatingUserProfileModuleImpl<= /class> + + + + + + + + ]]> + + + Module options are: + + + dbModuleJNDIName - JN= DI name under which database implementation of UserProfileModule is registe= red. + + + ldapModuleJNDIName - = JNDI name under which ldap implementation of UserProfileModule is registere= d. + + + profileConfigFile - c= onfiguration file for user properties. + + + + + Database UserProfile module implementation + Because of behaviour described in previous section database= UserProfile module needs some special capabilities. If user is present in + LDAP server but property we want to store isn't mapped as LDAP at= tribute such property need to be stored in database. But to store + the property user need to be synchronized from ldap into database= first + Class org.jboss.portal.identity.db.HibernateUserP= rofileModuleImpl has additional synchronization features. + Here are the options: + + + synchronizeNonExistingUsers - when set to "true" if user on which we want to perform operation does= n't exist it will + create it in database + + + acceptOtherImplementations - if set to "true" module will accept user objects other than + org.jboss.portal.identity.db.HibernateUserImpl. This is needed to enable cooperation with UserModule implementati= ons other + than org.jboss.portal.identity.db.HibernateUserMo= duleImpl + + + defaultSynchronizePassword - if this option is set the value will be used as password for synchroni= zed user. + + + randomSynchronizePassword - if this option is set to "true" synchronized user will have random gene= rated password. + This is mostly for the security reasons. + + + sessionFactoryJNDIName -= JNDI name under which this user will be registered. + + + profileConfigFile - file= with user profile configuration + + + + = + --===============2597329985467139266==--