Main configuration file is idm-configuration :

<configuration xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

               xsi:schemaLocation="http://www.exoplaform.org/xml/ns/kernel_1_0.xsd http://www.exoplaform.org/xml/ns/kernel_1_0.xsd"

               xmlns="http://www.exoplaform.org/xml/ns/kernel_1_0.xsd">



   <component>

      <key>org.exoplatform.services.organization.jbidm.JBossIDMService</key>

      <type>org.exoplatform.services.organization.jbidm.JBossIDMServiceImpl</type>

      <init-params>

         <value-param>

            <name>config</name>

            <value>war:/conf/organization/idm-config.xml</value>

         </value-param>

         <values-param>

            <name>hibernate.annotations</name>

            <value>org.jboss.identity.idm.impl.model.hibernate.HibernateIdentityObject</value>

            <value>org.jboss.identity.idm.impl.model.hibernate.HibernateIdentityObjectAttribute</value>

            <value>org.jboss.identity.idm.impl.model.hibernate.HibernateIdentityObjectBinaryAttribute</value>

            <value>org.jboss.identity.idm.impl.model.hibernate.HibernateIdentityObjectBinaryAttributeValue</value>

            <value>org.jboss.identity.idm.impl.model.hibernate.HibernateIdentityObjectCredential</value>

            <value>org.jboss.identity.idm.impl.model.hibernate.HibernateIdentityObjectCredentialType</value>

            <value>org.jboss.identity.idm.impl.model.hibernate.HibernateIdentityObjectRelationship</value>

            <value>org.jboss.identity.idm.impl.model.hibernate.HibernateIdentityObjectRelationshipName</value>

            <value>org.jboss.identity.idm.impl.model.hibernate.HibernateIdentityObjectRelationshipType</value>

            <value>org.jboss.identity.idm.impl.model.hibernate.HibernateIdentityObjectTextAttribute</value>

            <value>org.jboss.identity.idm.impl.model.hibernate.HibernateIdentityObjectType</value>

            <value>org.jboss.identity.idm.impl.model.hibernate.HibernateRealm</value>

         </values-param>

         <properties-param>

            <name>hibernate.properties</name>

            <property name="hibernate.hbm2ddl.auto" value="update"/>

            <property name="hibernate.current_session_context_class" value="thread"/>

            <property name="hibernate.show_sql" value="false"/>

            <property name="hibernate.cglib.use_reflection_optimizer" value="true"/>

            <property name="hibernate.connection.url" value="jdbc:hsqldb:file:../temp/data/exodb${container.name.suffix}"/>

            <property name="hibernate.connection.driver_class" value="org.hsqldb.jdbcDriver"/>

            <property name="hibernate.connection.autocommit" value="true"/>

            <property name="hibernate.connection.username" value="sa"/>

            <property name="hibernate.connection.password" value=""/>

            <property name="hibernate.dialect" value="org.hibernate.dialect.HSQLDialect"/>

            <property name="hibernate.c3p0.min_size" value="5"/>

            <property name="hibernate.c3p0.max_size" value="20"/>

            <property name="hibernate.c3p0.timeout" value="1800"/>

            <property name="hibernate.c3p0.max_statements" value="50"/>

            <property name="hibernate.connection.provider_class" value="org.hibernate.connection.C3P0ConnectionProvider" />

         </properties-param>



      </init-params>

   </component>



   <component>

      <key>org.exoplatform.services.organization.OrganizationService</key>

      <type>org.exoplatform.services.organization.jbidm.JBossIDMOrganizationServiceImpl</type>

   </component>



</configuration>

org.exoplatform.services.organization.jbidm.JBossIDMOrganizationServiceImpl is a main entrypoint implementing org.exoplatform.services.organization.OrganizationService and is dependant on org.exoplatform.services.organization.jbidm.JBossIDMService

org.exoplatform.services.organization.jbidm.JBossIDMServiceImpl service has following options:

org.exoplatform.services.organization.jbidm.JBossIDMOrganizationServiceImpl service has following options:

Additionally JBossIDMOrganizationServiceImpl uses those defaults to perform identity management operations

Sample JBoss Identity IDM configuration file is shown below. To understand all options present in it please refer to the JBoss Identity IDM Reference Guide

<jboss-identity xmlns="urn:jboss:identity:idm:config:v1_0_beta"
                xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
                xsi:schemaLocation="urn:jboss:identity:idm:config:v1_0_alpha identity-config.xsd">
    <realms>
        <realm>
            <id>PortalRealm</id>
            <repository-id-ref>PortalRepository</repository-id-ref>
            <identity-type-mappings>
                <user-mapping>USER</user-mapping>
            </identity-type-mappings>
        </realm>
    </realms>
    <repositories>
        <repository>
            <id>PortalRepository</id>
            <class>org.jboss.identity.idm.impl.repository.WrapperIdentityStoreRepository</class>
            <external-config/>
            <default-identity-store-id>HibernateStore</default-identity-store-id>
            <default-attribute-store-id>HibernateStore</default-attribute-store-id>
        </repository>
    </repositories>
    <stores>
        <attribute-stores/>
        <identity-stores>
            <identity-store>
                <id>HibernateStore</id>
                <class>org.jboss.identity.idm.impl.store.hibernate.HibernateIdentityStoreImpl</class>
                <external-config/>
                <supported-relationship-types>
                    <relationship-type>JBOSS_IDENTITY_MEMBERSHIP</relationship-type>
                    <relationship-type>JBOSS_IDENTITY_ROLE</relationship-type>
                </supported-relationship-types>
                <supported-identity-object-types>
                    <identity-object-type>
                        <name>USER</name>
                        <relationships/>
                        <credentials>
                            <credential-type>PASSWORD</credential-type>
                        </credentials>
                        <attributes/>
                        <options/>
                    </identity-object-type>
                </supported-identity-object-types>
                <options>
                    <option>
                        <name>hibernateSessionFactoryRegistryName</name>
                        <value>hibernateSessionFactory</value>
                    </option>
                    <option>
                        <name>allowNotDefinedIdentityObjectTypes</name>
                        <value>true</value>
                    </option>
                    <option>
                        <name>populateRelationshipTypes</name>
                        <value>true</value>
                    </option>
                    <option>
                        <name>populateIdentityObjectTypes</name>
                        <value>true</value>
                    </option>
                    <option>
                        <name>allowNotDefinedAttributes</name>
                        <value>true</value>
                    </option>
                    <option>
                        <name>isRealmAware</name>
                        <value>true</value>
                    </option>
                </options>
            </identity-store>
        </identity-stores>
    </stores>
</jboss-identity>

default portal will be accessed when the user doesn't specify the portal. For example: http://hostname:port/portal/. And the default portal be used for checking at starting of tomcat to determine whether database is empty or not, too.

Configuration file path : "02portal.war:/WEB-INF/conf/portal/portal-configuration.xml"

<component>

    <key>org.exoplatform.portal.config.UserPortalConfigService</key>

    <type>org.exoplatform.portal.config.UserPortalConfigService</type>

    <component-plugins>           

     <component-plugin>

       <name>new.portal.config.user.listener</name>

       <set-method>initListener</set-method>

       <type>org.exoplatform.portal.config.NewPortalConfigListener</type>

       <description>this listener init the portal configuration</description>

       <init-params>

         <value-param>

           <name>default.portal</name>

           <description>The default portal for checking db is empty or not</description>

           <value>classic</value>

         </value-param> 

         ..........

       </init-params>

     </component-plugin>

    </component-plugins> 

  </component>

You can see in the configuration above, we defined the classic as a default portal. Notes that the definition should be as a initial parameter of the NewPortalConfigListener component-plugin

When a user logs in he sees three types of navigation tree:

they all are configured thanks to the usual XML configuration syntax in a file: "02portal.war:/WEB-INF/conf/portal/portal-configuration.xml"

<component>

  <key>org.exoplatform.portal.config.UserPortalConfigService</key>

  <type>org.exoplatform.portal.config.UserPortalConfigService</type>

  <component-plugins>           

   <component-plugin>

     <name>new.portal.config.user.listener</name>

     <set-method>initListener</set-method>

     <type>org.exoplatform.portal.config.NewPortalConfigListener</type>

     <description>this listener init the portal configuration</description>

     <init-params>

       <value-param>

         <name>default.portal</name>

         <description>The default portal for checking db is empty or not</description>

         <value>classic</value>

       </value-param> 

       <object-param>

         <name>portal.configuration</name>

         <description>description</description>

         <object type="org.exoplatform.portal.config.NewPortalConfig">

           <field  name="predefinedOwner">

             <collection type="java.util.HashSet">                

               <value><string>classic</string></value>

               <value><string>webos</string></value>

             </collection>

           </field>

           <field  name="ownerType"><string>portal</string></field>

           <field  name="templateLocation"><string>war:/conf/portal</string></field> 

         </object>

       </object-param> 

       <object-param>

         <name>group.configuration</name>

         <description>description</description>

         <object type="org.exoplatform.portal.config.NewPortalConfig">

           <field  name="predefinedOwner">

             <collection type="java.util.HashSet">            

              <value><string>platform/administrators</string></value>    

              <value><string>platform/users</string></value>

              <value><string>platform/guests</string></value>

              <value><string>organization/management/executive-board</string></value>               

             </collection>

           </field>

           <field  name="ownerType"><string>group</string></field>

           <field  name="templateLocation"><string>war:/conf/portal</string></field> 

         </object>

       </object-param>       

       <object-param>

         <name>user.configuration</name>

         <description>description</description>

         <object type="org.exoplatform.portal.config.NewPortalConfig">

           <field  name="predefinedOwner">

             <collection type="java.util.HashSet">                

               <value><string>root</string></value>

               <value><string>john</string></value>

               <value><string>mary</string></value>

               <value><string>demo</string></value>

             </collection>

           </field>

           <field  name="ownerType"><string>user</string></field>

           <field  name="templateLocation"><string>war:/conf/portal</string></field> 

         </object>

       </object-param>

     </init-params>

   </component-plugin>

</component-plugins>

In the previous XML file we define, for the 3 navigation types, some sets of predefined portal, groups or users that will have some XML files inside the war. Those files will be used to create an initial navigation the first time the portal is launched. That information will then be stored in the JCR and hence only modifiable from the portal UI.

The portal navigation incorporates the pages that can be accessed even when the user is not logged in (if the permission allow a public access). Several portal navigations are used for example when a company has several trademarks and each trade would have its own website.

The configuration of a portal called "classic" is made by providing 4 XML files under the directory portal/WEBINF/conf/portal/portal/classic:

That file describes the layout and portlets that will be shown for all pages. Usually the layout contains the banner, footer, menu, breadcrumbs portlets. Indeed, in GateIn, every area is a portlet even the banner and footer which makes the platform extremely configurable.

<?xml version="1.0" encoding="ISO-8859-1"?>

<portal-config>

  <portal-name>classic</portal-name>

  <locale>en</locale>

  <factory-id>office</factory-id>

  <access-permissions>Everyone</access-permissions>

  <edit-permission>*:/platform/administrators</edit-permission>

  <creator>root</creator>    

    

  <portal-layout>   

  <application>

     <instance-id>portal#classic:/web/BannerPortlet/banner</instance-id>

     <show-info-bar>false</show-info-bar>

   </application>

   <application>

    <instance-id>portal#classic:/web/NavigationPortlet/toolbar</instance-id>

     <show-info-bar>false</show-info-bar>

   </application>

  

   <application>

     <instance-id>portal#classic:/web/BreadcumbsPortlet/breadcumbs</instance-id>

     <show-info-bar>false</show-info-bar>

   </application>

   

 

   <page-body> </page-body>

   

   <application>

     <instance-id>portal#classic:/web/FooterPortlet/footer</instance-id>

     <show-info-bar>false</show-info-bar>

   </application>

  </portal-layout>

  

</portal-config>

Even if not shown in the previous XML file, it is also possible to apply a nested container that can also contain portlets. Containers are then responsible of the layout of their children (row, column or tabs containers exist).

Each application references a portlet using the id portal#{portalName}:/{portletWarName}/{portletName}/{uniqueId}

In order to define at which location GateIn Portal shall render the current page use the page-body tag.

The defined classic portal is accessible to "Everyone" (that means it can be accessed through the URL /portal/public/classic) but only members of the group /platform/administrators can edit it.

This file defines all the navigation nodes the portal will have. The syntax is simple as we get nested node tags. Each node references a page that is defined in the next XML file.

If the label #{} is used then it means the i18n mechanism is activated and that the real label to render is taken from an associated properties file for the current locale.

<?xml version="1.0" encoding="UTF-8"?>

<node-navigation>

  <owner-type>portal</owner-type>

  <owner-id>classic</owner-id>

  <priority>1</priority>

  <page-nodes>

   <node>

     <uri>home</uri>

     <name>home</name>

     <label>#{portal.classic.home}</label>

     <page-reference>portal::classic::homepage</page-reference>     

   </node>    

   <node>

     <uri>webexplorer</uri>

     <name>webexplorer</name>

     <label>#{portal.classic.webexplorer}</label>

     <page-reference>portal::classic::webexplorer</page-reference>     

   </node>

  </page-nodes>

</node-navigation>

This navigation tree can have multiple views inside portlets such as the breadcrumbs that render the current view node, the site map or the menu portlets.

This XML file structure is very similar to portal.xml and it can also contain container tags. Each application can decide if it wishes to render the portlet border, the window state icons or the mode.

<?xml version="1.0" encoding="ISO-8859-1"?>

<page-set>  

  <page>

    <page-id>portal::classic::homepage</page-id>

    <owner-type>portal</owner-type>

    <owner-id>classic</owner-id>

    <name>homepage</name>

    <title>Home Page</title>

    <access-permissions>Everyone</access-permissions>

    <edit-permission>*:/platform/administrators</edit-permission>

    <application>

      <instance-id>portal#classic:/web/HomePagePortlet/homepageportlet</instance-id>

      <title>Home Page portlet</title>

      <show-info-bar>false</show-info-bar>

      <show-application-state>false</show-application-state>

      <show-application-mode>false</show-application-mode>

    </application>

  </page>    

    

  <page>

    <page-id>portal::classic::webexplorer</page-id>

    <owner-type>portal</owner-type>

    <owner-id>classic</owner-id>

    <name>webexplorer</name>

    <title>Web Explorer</title>

    <access-permissions>*:/platform/users</access-permissions>

    <edit-permission>*:/platform/administrators</edit-permission>    

    <application>

      <instance-id>group#platform/users:/web/BrowserPortlet/WebExplorer</instance-id>

      <title>Web Explorer</title>

      <show-info-bar>false</show-info-bar>

    </application>  

  </page>  

</page-set>

Porlet instances can be associated with portlet-preferences that override the one defined in the usual portlet.xml file of the portlet application WAR.

<?xml version="1.0" encoding="ISO-8859-1"?>

<portlet-preferences-set>

  <portlet-preferences>

    <owner-type>portal</owner-type>

    <owner-id>classic</owner-id>

    <window-id>portal#classic:/web/BannerPortlet/banner</window-id>

    <preference>

      <name>template</name>

      <value>par:/groovy/groovy/webui/component/UIBannerPortlet.gtmpl</value>

      <read-only>false</read-only>

    </preference>

  </portlet-preferences>

  <portlet-preferences>

    <owner-type>portal</owner-type>

    <owner-id>classic</owner-id>

    <window-id>portal#classic:/web/NavigationPortlet/toolbar</window-id>

    <preference>

      <name>useAJAX</name>

      <value>true</value>

      <read-only>false</read-only>

    </preference>

  </portlet-preferences>

  <portlet-preferences>

    <owner-type>portal</owner-type>

    <owner-id>classic</owner-id>

    <window-id>portal#classic:/web/FooterPortlet/footer</window-id>

    <preference>

      <name>template</name>

      <value>par:/groovy/groovy/webui/component/UIFooterPortlet.gtmpl</value>

      <read-only>false</read-only>

    </preference>

  </portlet-preferences>

  

  

  <portlet-preferences>

    <owner-type>portal</owner-type>

    <owner-id>classic</owner-id>

    <window-id>portal#classic:/web/GroovyPortlet/groovyportlet</window-id>

    <preference>

      <name>template</name>

      <value>par:/groovy/groovy/webui/component/UIGroovyPortlet.gtmpl</value>

      <read-only>false</read-only>

    </preference>

  </portlet-preferences>

</portlet-preferences-set>

Group navigations are dynamically added (mounted) to the user navigation when he logs in. This means that a user sees in his menu also all the pages that are assigned to the groups to which he belongs to.

Here only 3 XML files are necessary: navigation.xml, pages.xml and portlet-preferences.xml. The syntax is the same as for portal navigations.

The 3 files are located in the directory: "portal/WEB-INF/conf/portal/group/group-name-path/" like for example "portal/WEB-INF/conf/portal/group/platform/administrators/"

The user navigation is the set of nodes and pages that is owned by a user. You can see that part as the user dashboard. The files needed are navigation.xml, pages.xml, portlet-preferences.xml. You will also find gadgets.xml (formerly called widgets.xml) which defines the gadgets (widgets) that will be located in the user workspace. The user workspace is located at the left hand side, the access is restricted to some privileged users, see Section 2.4, “Predefined User Configuration”

Those files are located in the directory "portal/WEB-INF/conf/portal/users/{userName}"

<?xml version="1.0" encoding="ISO-8859-1"?>

<widgets>

  <owner-type>user</owner-type>

  <owner-id>root</owner-id>

 

  <container id="Information">

    <name>Information</name>

    <description>Information's Description</description>

    <application>

      <instance-id>user#root:/GateInWidgetWeb/WelcomeWidget/WelcomeWidget1</instance-id>

      <application-type>GateInWidget</application-type>

    </application>

      

    <application>

      <instance-id>user#root:/GateInWidgetWeb/StickerWidget/StickerWidget</instance-id>

      <application-type>GateInWidget</application-type> 

    </application>

    

    <application>

      <instance-id>user#root:/GateInWidgetWeb/InfoWidget/InfoWidget1</instance-id>

      <application-type>GateInWidget</application-type>

    </application>

  </container>

  

  <container id="Calendar">

    <name>Calendar</name>

    <description>Calendar's Description</description>

    <application>

      <instance-id>user#root:/GateInWidgetWeb/CalendarWidget/CalendarWidget</instance-id>

      <application-type>GateInWidget</application-type> 

    </application>

  </container> 

 

</widgets>

Note that when you develop a portal, we advise you to use the XML instead of the User Interface as XML will allow you to provide a preconfigured package to your customer. But as each time you start the server the first time, the XML files are stored in the JCR, it will be necessary to remove the database (the jcr leverages a database). During the development phase using tomcat it simply means to delete the directory: exo-tomcat/temp

To specify the initial Organization configuration, the content of 02portal.war:/WEB-INF/conf/organization/organization-configuration.xml should be edited. This file complies with the XML GateIn configuration schema. It lists several configuration plugins.

The plugin of type org.exoplatform.services.organization.OrganizationDatabaseInitializer specifies the list of users, groups and membership types to be created. The initialization parameter named "checkDatabaseAlgorithm" determines how the creation is triggered. Thus, the value "entry" means that each user, group and membership listed in the configuration is checked each time GateIn is started. If not existing, it is created. The value "empty" means that the whole list of preconfigured users, groups and memberships is processed only if the database is empty.

The predefined membership types are specified in the "membershipType" field of the "OrganizationConfig" plugin parameter.

<field name="membershipType">

  <collection type="java.util.ArrayList">

    <value>

      <object type="org.exoplatform.services.organization.OrganizationConfig$MembershipType">

        <field name="type">

          <string>member</string>

        </field>

        <field name="description">

          <string>member membership type</string>

        </field>

      </object>

    </value>

    <value>

      <object type="org.exoplatform.services.organization.OrganizationConfig$MembershipType">

        <field name="type">

          <string>owner</string>

        </field>

        <field name="description">

          <string>owner membership type</string>

        </field>

      </object>

     </value>

     <value>

       <object type="org.exoplatform.services.organization.OrganizationConfig$MembershipType">

         <field name="type">

           <string>validator</string>

         </field>

         <field name="description">

           <string>validator membership type</string>

         </field>

       </object>

     </value>

   </collection>

</field>

The predefined groups are specified in the "group" field of the "OrganizationConfig" plugin parameter.

<field name="group">

  <collection type="java.util.ArrayList">

    <value>

      <object type="org.exoplatform.services.organization.OrganizationConfig$Group">

        <field name="name">

          <string>portal</string>

        </field>

        <field name="parentId">

          <string></string>

        </field>

        <field name="type">

          <string>hierachy</string>

        </field>

        <field name="description">

          <string>the /portal group</string>

        </field>

      </object>

    </value>

    <value>

      <object type="org.exoplatform.services.organization.OrganizationConfig$Group">

        <field name="name">

          <string>community</string>

        </field>

        <field name="parentId">

          <string>/portal</string>

        </field>

        <field name="type">

          <string>hierachy</string>

        </field>

        <field name="description">

          <string>the /portal/community group</string>

        </field>

      </object>

    </value>

    ...

  </collection>

</field>

The predefined users are specified in the "membershipType" field of the "OrganizationConfig" plugin parameter.

<field name="user">

  <collection type="java.util.ArrayList">

    <value>

      <object type="org.exoplatform.services.organization.OrganizationConfig$User">

        <field name="userName"><string>root</string></field>

        <field name="password"><string>exo</string></field>

        <field name="firstName"><string>root</string></field>

        <field name="lastName"><string>root</string></field>

        <field name="email"><string>exoadmin@localhost</string></field>

        <field name="groups"><string>member:/admin,member:/user,owner:/portal/admin</string></field>

      </object>

    </value>

    <value>

      <object type="org.exoplatform.services.organization.OrganizationConfig$User">

        <field name="userName"><string>exo</string></field>

        <field name="password"><string>exo</string></field>

        <field name="firstName"><string>site</string></field>

        <field name="lastName"><string>site</string></field>

        <field name="email"><string>exo@localhost</string></field>

        <field name="groups"><string>member:/user</string></field>

      </object>

    </value>

    ...

  </collection>

</field>

The plugin of type org.exoplatform.services.organization.impl.NewUserEventListener specifies which groups should join all newly created users. It notably specifies the groups and memberships to be used. It also specifies a list of users that should be excepted.

<component-plugin>

  <name>new.user.event.listener</name>

  <set-method>addListenerPlugin</set-method>

  <type>org.exoplatform.services.organization.impl.NewUserEventListener</type>

  <description>this listener assign group and membership to a new created user</description>

  <init-params>

    <object-param>

      <name>configuration</name>

      <description>description</description>

      <object type="org.exoplatform.services.organization.impl.NewUserConfig">

        <field  name="group">

          <collection type="java.util.ArrayList">

            <value>

              <object type="org.exoplatform.services.organization.impl.NewUserConfig$JoinGroup">

                <field name="groupId"><string>/user</string></field>

                <field name="membership"><string>member</string></field>

              </object>

            </value>               

          </collection>

        </field>

        <field  name="ignoredUser">

          <collection type="java.util.HashSet">

            <value><string>exo</string></value>

            <value><string>root</string></value>

            <value><string>company</string></value>

            <value><string>community</string></value>

          </collection>

        </field>

      </object>

    </object-param>

  </init-params>

</component-plugin>

The permission configuration for the portal is defined in the file 02portal.war:/WEB-INF/conf/portal/portal-configuration.xml . The component UserACL is described there along with other portal component configurations.

It defines 5 permissions types:

<component>

  <key>org.exoplatform.portal.config.UserACL</key>

  <type>org.exoplatform.portal.config.UserACL</type>   

  <init-params>      

    <value-param>

      <name>super.user</name>

      <description>administrator</description>

      <value>root</value>     

    </value-param>

      

    <value-param>

      <name>portal.creator.groups</name>

      <description>groups with membership type have permission to manage portal</description>

      <value>*:/platform/administrators,*:/organization/management/executive-board</value>     

    </value-param>

      

    <value-param>

      <name>navigation.creator.membership.type</name>

      <description>specific membership type have full permission with group navigation</description>

      <value>manager</value>     

    </value-param>

    <value-param>

      <name>guests.group</name>

      <description>guests group</description>

      <value>/platform/guests</value>     

    </value-param>     

    <value-param>

      <name>access.control.workspace</name>

      <description>groups with memberships that have the right to access the User Control Workspace</description>

      <value>*:/platform/administrators,*:/organization/management/executive-board</value>     

    </value-param>           

  </init-params>   

</component>

<external-component-plugins>

    <target-component>org.exoplatform.portal.config.UserACL</target-component>

    <component-plugin>

      <name>addPortalACLPlugin</name>

      <set-method>addPortalACLPlugin</set-method>

      <type>org.exoplatform.portal.config.PortalACLPlugin</type>

      <description>setting some permission for portal</description>

      <init-params>     

        <values-param>

          <name>access.control.workspace.roles</name>

          <value>*:/platform/administrators</value>

          <value>*:/organization/management/executive-board</value>       

        </values-param>

        <values-param>

          <name>portal.creation.roles</name>

          <value>*:/platform/administrators</value>

          <value>*:/organization/management/executive-board</value>      

        </values-param>

      </init-params>

    </component-plugin>

  </external-component-plugins>

GateIn Portal has two different database dependencies. One is the Hibernate service configuration, which depends on the the Hibernate and c3p0 projects. The other database dependency is Java content repository (JCR) service, which depends on the native JDBC API and it can integrate with any existing datasource implementation.

When you change the database configuration for the first time, GateIn will automatically generate the proper schema (assuming that the database user has the appropriate permissions).

GateIn assumes the default encoding for your database is latin1 . You will need to change this parameter for your database in order to work properly.

You can find the database configuration in the portal/WEB-INF/conf/database/database-configuration.xml file (located in your application server's web application directory).

<?xml version="1.0" encoding="ISO-8859-1"?>

<configuration>

  [...]

  <component>

    <key>org.exoplatform.services.database.HibernateService</key>

    <jmx-name>database:type=HibernateService</jmx-name>

    <type>org.exoplatform.services.database.impl.HibernateServiceImpl</type>

    <init-params>

      <properties-param>

        <name>hibernate.properties</name>

        <description>Default Hibernate Service</description>

        <property name="hibernate.show_sql" value="false"/>

        <property name="hibernate.cglib.use_reflection_optimizer" value="true"/>

        <property name="hibernate.connection.url" value="jdbc:hsqldb:file:../temp/data/exodb"/>

        <property name="hibernate.connection.driver_class" value="org.hsqldb.jdbcDriver"/>

        <property name="hibernate.connection.autocommit" value="true"/>

        <property name="hibernate.connection.username" value="sa"/>

        <property name="hibernate.connection.password" value=""/>

        <property name="hibernate.dialect" value="org.hibernate.dialect.HSQLDialect"/>

        <property name="hibernate.c3p0.min_size" value="5"/>

        <property name="hibernate.c3p0.max_size" value="20"/>

        <property name="hibernate.c3p0.timeout" value="1800"/>

        <property name="hibernate.c3p0.max_statements" value="50"/>

      </properties-param>

    </init-params>

  </component>

  <external-component-plugins>

    <target-component>org.exoplatform.services.naming.InitialContextInitializer</target-component>

    <component-plugin>

      <name>bind.datasource</name>

      <set-method>addPlugin</set-method>

      <type>org.exoplatform.services.naming.BindReferencePlugin</type>

      <init-params>

        <value-param>

          <name>bind-name</name>

          <value>jdbcexo</value>

        </value-param>

        <value-param>

          <name>class-name</name>

          <value>javax.sql.DataSource</value>

        </value-param>

        <value-param>

          <name>factory</name>

          <value>org.apache.commons.dbcp.BasicDataSourceFactory</value>

        </value-param>

        <properties-param>

          <name>ref-addresses</name>

          <description>ref-addresses</description>

          <property name="driverClassName" value="org.hsqldb.jdbcDriver"/>

          <property name="url" value="jdbc:hsqldb:file:../temp/data/exodb"/>

          <property name="username" value="sa"/>

          <property name="password" value=""/>

        </properties-param>

      </init-params>

    </component-plugin>

  </external-component-plugins>

  [...]

</configuration>

The first component configuration is for the Hibernate service. You can enter any additional properties in a hibernate.properties file, but GateIn will override hibernate.properties with values read in from this configuration file.

The second component configuration is for the JCR datasource. The InitialContextInitializer component will load the factory class, use the factory object to create a datasource, and bind that datasource in the JNDI tree with the value of the "bind-name" parameter. If you want to change the bind-name, for example "jdbcexo" to "myjdbc", you also need to change JCR repository configuration in order that the service picks up the right datasource.

Make sure you update the database connection properties and dialect for both of these component configurations.

There are two JCR configuration files that must be changed to support a different database. In both files, edit the dialect (and the data source name if necessary) .

The first file is 02portal.war:/WEB-INF/conf/jcr/jcr-configuration.xml :

[...]
 <component>
   <key>org.exoplatform.services.jcr.config.RepositoryServiceConfiguration</key>
   <type>org.exoplatform.services.jcr.impl.config.RepositoryServiceConfigurationImpl</type>
   <init-params>
     <value-param>
       <name>conf-path</name>
       <description>JCR configuration file</description>
       <value>war:/conf/jcr/repository-configuration.xml</value>
     </value-param>
     <properties-param>
       <name>working-conf</name>
       <description>working-conf</description>
       <property name="persisterClassName" value="org.exoplatform.services.jcr.impl.config.JDBCConfigurationPersister"/>
       <property name="sourceName" value="jdbcexo"/>
       <property name="dialect" value="hsqldb"/>
     </properties-param>
   </init-params>
 </component>
[...]

The second file is 02portal.war:/WEB-INF/conf/jcr/repository-configuration.xml :

 ...]     

     <workspaces>

       <workspace name="system" auto-init-root-nodetype="nt:unstructured" 

                  auto-init-permissions="*:/platform/administrators read;*:/platform/administrators add_node;*:/platform/administrators set_property;*:/platform/administrators remove" >

          <!-- for system storage -->

          <container class="org.exoplatform.services.jcr.impl.storage.jdbc.JDBCWorkspaceDataContainer">

            <properties>

              <property name="sourceName" value="jdbcexo"/>

              <property name="dialect" value="hsql"/>

              <!-- property name="db-type" value="mysql"/ -->

              <property name="multi-db" value="false"/>

              <property name="update-storage" value="true"/>

              <property name="max-buffer-size" value="204800"/>

              <property name="swap-directory" value="../temp/swap/system"/>

            </properties>

[...]

       </workspace>

       <workspace name="collaboration" auto-init-root-nodetype="nt:unstructured" 

                  auto-init-permissions="any read;*:/platform/administrators read;*:/platform/administrators add_node;*:/platform/administrators set_property;*:/platform/administrators remove" >

          <!-- for system storage -->

          <container class="org.exoplatform.services.jcr.impl.storage.jdbc.JDBCWorkspaceDataContainer">

            <properties>

              <property name="sourceName" value="jdbcexo"/>

              <property name="dialect" value="hsqldb"/>

              <property name="multi-db" value="false"/>

              <property name="update-storage" value="true"/>

              <property name="max-buffer-size" value="204800"/>

              <property name="swap-directory" value="../temp/swap/collaboration"/>

            </properties>

[...]

       </workspace>

       <workspace name="backup" auto-init-root-nodetype="nt:unstructured" 

                  auto-init-permissions="any read;*:/platform/administrators read;*:/platform/administrators add_node;*:/platform/administrators set_property;*:/platform/administrators remove" >

          <!-- for system storage -->

          <container class="org.exoplatform.services.jcr.impl.storage.jdbc.JDBCWorkspaceDataContainer">

            <properties>

              <property name="sourceName" value="jdbcexo"/>

              <property name="dialect" value="mysql"/>

              <!-- property name="db-type" value="mysql"/ -->

              <property name="multi-db" value="false"/>

              <property name="update-storage" value="true"/>

              <property name="max-buffer-size" value="204800"/>

              <property name="swap-directory" value="../temp/swap/backup"/>

            </properties>

       </workspace>

[...]

      </workspaces>

[...]

Data-injector is an utility to initialize enterprise data for Portal. It is packed as a .jar.

OrganizationInitializer is the service that allows creating a large organization with many groups and users. It also creates portal navigation and page(s) for each group, each user.

<configuration>

  <component>

  <key>org.exoplatform.portal.initializer.organization.OrganizationInitializer</key>

  <type>org.exoplatform.portal.initializer.organization.OrganizationInitializer</type>

    <init-params>

      <value-param>

        <name>auto.create.group.page.navigation</name>

        <description>true or false</description>

        <value>true</value>

      </value-param>

       

      <value-param>

        <name>auto.create.user.page.navigation</name>

        <description>number of pages per user</description>

        <value>10</value>

      </value-param>

      

      <object-param>

        <name>organization</name>

        <description>description</description>

        <object type="org.exoplatform.portal.initializer.organization.OrganizationConfig">

          <field name="groups">

            <collection type="java.util.ArrayList">

              <value>

                <object type="org.exoplatform.portal.initializer.organization.OrganizationConfig$GroupsConfig">

                  <field name="group">

                    <object type="org.exoplatform.services.organization.OrganizationConfig$Group">

                      <field name="name"><string>province</string></field>

                      <field name="parentId"><string>/africa/tanzania</string></field>

                      <field name="description"><string>Tanzania's province</string></field>

                      <field name="label"><string>Province</string></field>

                    </object>                

                  </field> 

                  <field name="from"><string>1</string></field>

                  <field name="to"><string>10</string></field>

                </object>

              </value>

            </collection>

          </field>

          <field name="users">

            <collection type="java.util.ArrayList"> 

              <value>

                <object type="org.exoplatform.portal.initializer.organization.OrganizationConfig$UsersConfig">

                  <field name="user">

                    <object type="org.exoplatform.services.organization.OrganizationConfig$User">

                      <field name="userName"><string>user</string></field>

                      <field name="password"><string>GateInPlatform</string></field>

                      <field name="firstName"><string>First-Name</string></field>

                      <field name="lastName"><string>Last-Name</string></field>

                      <field name="email"><string>exo@localhost</string></field>

                      <field name="groups"><string>member:/africa</string></field>

                    </object>

                  </field>

                  <field name="from"><string>0</string></field>

                  <field name="to"><string>9</string></field>

                </object>

              </value>

            </collection>

          </field>

        </object>

      </object-param>

    </init-params>

  </component>  

</configuration>

The " auto.create.group.page.navigation " Parameter Value is true or false. If TRUE it automatically create portal navigation and page for each group. If FALSE it does not create portal navigation and page for each group.

The " auto.create.user.page.navigation " Parameter Value is number of pages that automatically created for each user.

GateIn provides support for skinning the entire portal User Interface (UI) including your own portlets. Skins are designed to help you pack and reuse common graphic resources.

Skins can be switched dynamically at runtime.

When you switch, the whole portal will be repainted and new styles will be applied to the UI.

An GateIn skin contains css styles for GateIn portal's components but also shares components that may be reused in portlets. When GateIn generates a portal page markup, it inserts stylesheet links in the page's head tag.

<head>
...   
<link id="CoreSkin" rel="stylesheet" type="text/css" href="/eXoResources/skin/Stylesheet.css" />
<link id="web_FooterPortlet" rel="stylesheet" type="text/css" href= "/web/skin/portal/webui/component/UIFooterPortlet/DefaultStylesheet.css" />
<link id="web_NavigationPortlet" rel="stylesheet" type="text/css" href= "/web/skin/portal/webui/component/UINavigationPortlet/DefaultStylesheet.css" />
<link id="web_HomePagePortlet" rel="stylesheet" type="text/css" href= "/portal/templates/skin/webui/component/UIHomePagePortlet/DefaultStylesheet.css" />
<link id="web_BannerPortlet" rel="stylesheet" type="text/css" href= "/web/skin/portal/webui/component/UIBannerPortlet/DefaultStylesheet.css" />
...
</head>

In the snipped code above, you can see two types of links :

This is revealed easily by the main portal skin stylesheets. For example /eXoVistaSkin/skin/Stylesheet.css

@import url(/eXoResources/skin/PortletThemes/Stylesheet.css) ;
@import url(VistaSkin/portal/webui/component/UIPortalApplicationSkin.css) ;
@import url(VistaSkin/webui/component/Stylesheet.css) ;

Portlets often require additionnal styles that may not be defined by the portal skin. GateIn allows portlets to define additional stylesheets for each portlet and will append the corresponding link tags to the head.

The link ID will be of the form {portletAppName}{}$$PortletName. For example: ContentPortlet in content.war, will give id="contentContentPortlet"

TODO: give some rules to follow in order to avoid overriding portal styles

New skin can be created by the configuration. Firstly, you have to definy the new skin in WEB-INF/conf/script/groovy/SkinConfigScript.groovy in your Ressource (for example, in the project MyPortal, you can put it in GateInResourcesMyPortal).

SkinService.addPortalSkin("MyPortalSkin","MyPortal","/GateInResourcesMyPortal/skin/Stylesheet.css",ServletContext);

Secondly, you put all your new skin into folder skinyourSkin and create new file Stylesheet.css here. In this file, you will import all links to your CSS. For example in MyPortal project.

@import url(MyPortalSkin/portal/webui/component/UIPortalApplicationSkin.css) ;
@import url(MyPortalSkin/webui/component/Stylesheet.css) ;

Finally, you have to definy the name of new skin and the image preview for the Skin Settings action in "User Workspace" .

By default, if you don not set new name for skin, its name is label>. Looking in the file and add yout new name here.

#############################################################################
#                              Change Skin                                  #
#############################################################################
  
UIChangeSkin.action.save=Appliquer
UIChangeSkin.action.close=Fermer
UIChangeSkin.title.SkinSetting=Configuration des styles
UIChangeSkin.MyPortal.label=Style MyPortal
UIChangeSkin.Default.label=Style par d?faut
UIChangeSkin.Mac.label=Style Mac
UIChangeSkin.Vista.label=Style Vista
Skin.title=Liste des styles
Skin.left.title=Voir et s?lectionner un style

The image peeview can be set in file ressource/skin/DefaultSkin/portal/webui/component/customization/UIChangeSkinForm/Stylesheet.css of Portal.

.UIChangeSkinForm .UIItemSelector .TemplateContainer .MyPortalImage {
	margin: auto;
	width: 329px; height:204px;
	background: url('background/MyPortal.jpg') no-repeat top;
	cursor: pointer ;
}

And now, you copy your image MyPortal.jpg (that you defined above) to the folder ressource/skin/DefaultSkin/portal/webui/component/customization/UIChangeSkinForm/background and test your new skin.

Firstly, you have to definy the new theme in WEB-INF/conf/script/groovy/SkinConfigScript.groovy in your Ressource (for example, in the project MyPortal, you can put it in GateInResourcesCp060508).

SkinService.addTheme("MyPortal-MacTheme", ["MacGray","MacBlue","MacBlack"]);

Secondly, you put all your new theme into folder skinyourSkin and create new file Stylesheet.css here. In this file, you will import all links to your CSS. For example in MyPortal project.

@import url(MyPortalSkin/PortletThemes/Stylesheet.css) ;

You can see here, in the GateInResourcesCp060508/skin/MyPortalSkin/PortletThemes/Stylesheet.css, you put all your CSS of new theme.

/*---- MyPortalTheme ----*/
.MyPortalTheme .WindowBarCenter .WindowPortletInfo {
	margin-right: 80px; /* orientation=lt */
	margin-left: 80px; /* orientation=rt */
}
.MyPortalTheme .WindowBarCenter .ControlIcon {
	float: right;/* orientation=lt */
	float: left;/* orientation=rt */
	width: 24px; 
	height: 17px;
	cursor: pointer;
	background-image: url('background/MyPortalTheme.png');
}
.MyPortalTheme .ArrowDownIcon {
	background-position: center 20px;
}
.MyPortalTheme .OverArrowDownIcon {
	background-position: center 116px;
}
.MyPortalTheme .MinimizedIcon {
	background-position: center 44px;
}
.MyPortalTheme .OverMinimizedIcon {
	background-position: center 140px;
}
.MyPortalTheme .MaximizedIcon {
	background-position: center 68px;
}
.MyPortalTheme .OverMaximizedIcon {
	background-position: center 164px;
}
.MyPortalTheme .RestoreIcon {
	background-position: center 92px;
}
.MyPortalTheme .OverRestoreIcon {
	background-position: center 188px;
}
.MyPortalTheme .NormalIcon {
	background-position: center 92px;
}
.MyPortalTheme .OverNormalIcon {
	background-position: center 188px;
}
.UIPageDesktop .MyPortalTheme .ResizeArea {
	float: right;/* orientation=lt */
	float: left;/* orientation=rt */
	width: 18px; height: 18px;
	cursor: nw-resize;
	background: url('background/ResizeArea18x18.gif') no-repeat left top; /* orientation=lt */
	background: url('background/ResizeArea18x18-rt.gif') no-repeat right top; /* orientation=rt */
}
.MyPortalTheme .Information {
	height: 18px; line-height: 18px;
	vertical-align: middle; font-size: 10px;
	padding-left: 5px;/* orientation=lt */
	padding-right: 5px;/* orientation=rt */
	margin-right: 18px;/* orientation=lt */
	margin-left: 18px;/* orientation=rt */
}
.MyPortalTheme .WindowBarCenter .WindowPortletIcon {
  background-position: left top; /* orientation=lt */
  background-position: right top; /* orientation=rt */
	padding-left: 20px; /* orientation=lt */
	padding-right: 20px; /* orientation=rt */
	height: 16px;
	line-height: 16px;
}
.MyPortalTheme .WindowBarCenter .PortletName {
	font-weight: bold;
	color: #333333;
	overflow: hidden;
	white-space: nowrap;
	width: 100%;
}
.MyPortalTheme .WindowBarLeft {
	padding-left: 12px;
	background-image: url('background/MyPortalTheme.png');
	background-repeat: no-repeat;
	background-position: left -148px;
}
.MyPortalTheme .WindowBarRight {
	padding-right: 11px;
	background-image: url('background/MyPortalTheme.png');
	background-repeat: no-repeat;
	background-position: right -119px;
}
.MyPortalTheme .WindowBarCenter {
	background-image: url('background/MyPortalTheme.png');
	background-repeat: repeat-x;
	background-position: left -90px;
}
.MyPortalTheme .WindowBarCenter .FixHeight {
	height: 21px;
	padding-top: 8px;
}
.MyPortalTheme .MiddleDecoratorLeft {
	padding-left: 12px;
	background: url('background/MMyPortalTheme.png') repeat-y left;
}
.MyPortalTheme .MiddleDecoratorRight {
	padding-right: 11px;
	background: url('background/MMyPortalTheme.png') repeat-y right;
}
.MyPortalTheme .MiddleDecoratorCenter {
	background: #ffffff;
}
.MyPortalTheme .BottomDecoratorLeft {
	padding-left: 12px;
	background-image: url('background/MyPortalTheme.png');
	background-repeat: no-repeat;
	background-position: left -60px;
}
.MyPortalTheme .BottomDecoratorRight {
	padding-right: 11px;
	background-image: url('background/MyPortalTheme.png');
	background-repeat: no-repeat;
	background-position: right -30px;
}
.MyPortalTheme .BottomDecoratorCenter {
	background-image: url('background/MyPortalTheme.png');
	background-repeat: repeat-x;
	background-position: left top;
}
.MyPortalTheme .BottomDecoratorCenter .FixHeight {
	height: 30px;
}

In this article, you will learn:

Token service is used in authentication.

Using token helps preventing information such as user name, password into user request so the system will become more secure.

Token service provides the way to manipulate tokens such as create, delete, retrieve, clean ... Token service also defines the life-time of token. After the life-time, token has no more effect. The life-time definition must be configured.

All token services used in GateIn portal's authentication must be a subclass of an abstract class AbstractTokenService . So they must have these following methods:

        public Token getToken(String id) throws PathNotFoundException, RepositoryException;

        public Token deleteToken(String id) throws PathNotFoundException, RepositoryException;

        public String[] getAllTokens();

        public long getNumberTokens() throws Exception;

        public String createToken(Credentials credentials) throws IllegalArgumentException,NullPointerException;

        public Credentials validateToken(String tokenKey, boolean remove) throws NullPointerException;

These methods show how the token-service manipulates its tokens.

Token services configuration is also known as specifying the life-time of token in the configuration file. The token service is configured as a portal component.

Examples:

<component>

  <key>org.exoplatform.web.security.security.CookieTokenService</key>

  <type>org.exoplatform.web.security.security.CookieTokenService</type>

  <init-params>

    <values-param>

      <name>tokenTimeout</name>          

      <value>jcr-token</value>

      <value>7</value>

      <value>DAY</value>

    </values-param>     

  </init-params>

</component>

In this example, CookieTokenService is a subclass of AbstractTokenService so it has a property which specifies how long token can live .

Service will initiate this property by looking for an init-param named as " service.configuration ". This property must have 3 values (service's name, amount of time, unit of time). In this case, we can see the service's name is "jcr-token", the token's expiration time is a week.

At this time, GateIn Portal supports four timing units: SECOND , MINUTE , HOUR and DAY .