This chapter will show you how to integrate eXo Platform 3.5 into your information system through the specific topics below:
* [Authentication|#DEV.SystemIntegration.Authentication]
** [Single-Sign-On (SSO)|#DEV.SystemIntegration.SingleSignON]
** [Kerberos SSO on Active Directory|#DEV.SystemIntegration.KerberosSSOOnActiveDirectory]
* [Users integration|#DEV.SystemIntegration.UserIntergration]
** [Organization Service|#DEV.SystemIntegration.OrganizationService]
** [Memberships, Groups and Users|#DEV.SystemIntegration.MembershipsGroupsAndUsers]
** [Organization API|#DEV.SystemIntegration.OrganizationAPI]
* [LDAP Integration |#DEV.SystemIntegration.LDAPIntergration]
** [Connection Settings|#DEV.SystemIntegration.ConnectionSettings]
** [Active Directory sample configuration |#DEV.SystemIntegration.ActiveDirectorySampleConfiguration]
** [Active Directory sample configuration |#DEV.SystemIntegration.ActiveDirectorySampleConfiguration]
* [Email|#DEV.SystemIntegration.Email]

h1. Authentication {anchor:id=DEV.SystemIntegration.Authentication}

h2. Single-Sign-On (SSO) {anchor:id=DEV.SystemIntegration.SingleSignON}

When logging into the portal, you can gain access to many systems through portlets using a single identity. However, in many cases, the portal infrastructure must be integrated with other SSO-enabled systems. There are many different Identity Management solutions available. The GateIn documentation gives detailed configuration for different SSO implementation. For more details, see [Single Sign On|http://docs.jboss.com/gatein/portal/3.1.0-FINAL/reference-guide/en-US/html_single/index.html#chap-Reference_Guide-SSO_Single_Sign_On].

h2. Central Authentication Service (CAS) {anchor:id=DEV.SystemIntegration.CenterAuthenticationService}

Central Authentication Service (CAS) is a Web Single-Sign-On (WebSSO), developed by JA-SIG as an open source project. CAS enables you to work on different applications to log in only once and to be recognized and authenticated by all applications. Details about CAS can be found [here|http://www.ja-sig.org/products/cas/].

The CAS integration consists of two steps:

* Installing or configuring the CAS server.
* Setting up the portal to use the CAS server.

For more information on CAS configuration, refer [here|http://docs.jboss.com/gatein/portal/3.1.0-FINAL/reference-guide/en-US/html_single/index.html#sect-Reference_Guide-Single_Sign_On-CAS_Central_Authentication_Service].


h2. Kerberos SSO on Active Directory {anchor:id=DEV.SystemIntegration.KerberosSSOOnActiveDirectory}

eXo Portal 3.5 supports the Kerberos authentication on a Microsoft Active Directory. You will need to configure both your Active Directory server and the application server.

The implementation makes possible to use SPNEGO or NTLM. The client will get two authentication headers, including *Negotiate* and *NTLM* and will use whichever supported by the browser. In Firefox, it is possible to manage authentication types, but it is not in Internet Explorer; therefore, SPNEGO will be used.

To learn more about how to configure Kerberos SSO, see [here|http://wiki.exoplatform.com/xwiki/bin/view/WS/Kerberos%20SSO%20on%20Active%20Directory].


h1. Users integration {anchor:id=DEV.SystemIntegration.UserIntergration}

h2. Organization Service {anchor:id=DEV.SystemIntegration.OrganizationService}

To specify the initial Organization configuration, the content of your extension.war in _/WEB-INF/conf/organization/organization-configuration.xml_ should be edited. This file uses the portal XML configuration schema. It lists several configuration plugins.

The plugin of _org.exoplatform.services.organization.OrganizationDatabaseInitializer_ type is used to specify a list of membership types, groups, and users to be created.

h2. Memberships, Groups and Users {anchor:id=DEV.SystemIntegration.MembershipsGroupsAndUsers}

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

{code:xml}
<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>
  </collection>
</field>
{code}

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

{code:xml}
<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>
{code}

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

{code:xml}
<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>
{code}


h2. Organization API {anchor:id=DEV.SystemIntegration.OrganizationAPI}

The _exo.platform.services.organization_ package has five main components: user, user profile, group, membership type and membership. There is an additional component that serves as an entry point into Organization API - _OrganizationService_ component which provides handling functionality for the five components. For more details, take a look at the [GateIn documentation|http://docs.jboss.com/gatein/portal/3.1.0-FINAL/reference-guide/en-US/html/chap-Reference_Guide-Authentication_And_Identity.html#sect-Reference_Guide-APIs-Organization_API].

h1. LDAP Integration {anchor:id=DEV.SystemIntegration.LDAPIntergration}
If you have an existing LDAP server, the eXo predefined settings will likely not match your directory structure. eXo LDAP organization service implementation was written with flexibility in mind and can certainly be configured to meet your requirements.

The configuration is done in the _ldap-configuration.xml_ file, and this part will explain the numerous parameters which it contains.

h2. Connection Settings {anchor:id=DEV.SystemIntegration.ConnectionSettings}
First, start by connection settings which will tell eXo how to connect to your directory server. These settings are very close to the [JNDI API|http://java.sun.com/products/jndi] context parameters. This configuration is activated by the init-param _ldap.config_ of service _LDAPServiceImpl_.

{code:xml}
<component>
  <key>org.exoplatform.services.ldap.LDAPService</key>
  <type>org.exoplatform.services.ldap.impl.LDAPServiceImpl</type>
  <init-params>
    <object-param>
      <name>ldap.config</name>
      <description>Default ldap config</description>
      <object type="org.exoplatform.services.ldap.impl.LDAPConnectionConfig">
        <field name="providerURL">
          <string>ldap://127.0.0.1:389,10.0.0.1:389</string>
        </field>
        <field name="rootdn">
          <string>CN=Manager,DC=exoplatform,DC=org</string>
        </field>
        <field name="password">
          <string>secret</string>
        </field>
        <!-- field name="authenticationType"><string>simple</string></field -->
        <field name="version">
          <string>3</string>
        </field>
        <field name="referralMode">
          <string>follow</string>
        </field>
        <!-- field name="serverName"><string>active.directory</string></field -->
      </object>
    </object-param>
  </init-params>
</component>
{code}

* *providerURL*: LDAP server URL (see [PROVIDER_URL|http://java.sun.com/products/jndi/1.2/javadoc/javax/naming/Context.html#PROVIDER_URL]). For multiple LDAP servers, use comma separated list of host:port (For example, ldap://127.0.0.1:389,10.0.0.1:389).
* *rootdn*: distinguished name of user that will be used by the service to authenticate on the server (see [SECURITY_PRINCIPAL|http://java.sun.com/products/jndi/1.2/javadoc/javax/naming/Context.html#SECURITY_PRINCIPAL]).
* *password*: password for user _rootdn_ (see [SECURITY_CREDENTIALS|http://java.sun.com/products/jndi/1.2/javadoc/javax/naming/Context.html#SECURITY_CREDENTIALS]).
* *authenticationType*: type of authentication to be used (see [SECURITY_AUTHENTICATION|http://java.sun.com/products/jndi/1.2/javadoc/javax/naming/Context.html#SECURITY_AUTHENTICATION]). Use one of _none_, _simple_, _strong_. Default is _simple_.
* *version*: LDAP protocol version (see [java.naming.ldap.version|http://java.sun.com/products/jndi/tutorial/ldap/misc/version.html]). Set to 3 if your server supports LDAP V3.
* *referalMode*: one of _follow_, _ignore_, _throw_ (see [REFERRAL|http://java.sun.com/products/jndi/1.2/javadoc/javax/naming/Context.html#REFERRAL]).
* *serverName*: you will need to set this to _active.directory_ to work with Active Directory servers. Any other value will be ignored and the service will act as on a standard LDAP.

h2.  Organization Service Configuration {anchor:id=DEV.SystemIntegration.OrganizationServiceConfiguration}
Next, you need to configure the eXo *OrganizationService* to show how the directory is structured and how to interact with it.
This is managed by a couple of init-params: *ldap.userDN.key* and *ldap.attribute.mapping* in file *ldap-configuration.xml* (by default located at _portal.war/WEB-INF/conf/organization_)

{code:xml}
<component>
  <key>org.exoplatform.services.organization.OrganizationService</key>
  <type>org.exoplatform.services.organization.ldap.OrganizationServiceImpl</type>
  [...]
  <init-params>
    <value-param>
      <name>ldap.userDN.key</name>
      <description>The key used to compose user DN</description>
      <value>cn</value>
    </value-param>
    <object-param>
      <name>ldap.attribute.mapping</name>
      <description>ldap attribute mapping</description>
      <object type="org.exoplatform.services.organization.ldap.LDAPAttributeMapping"></object>
        [...]
    </object-param>
  </init-params>
  [...]
</component>
{code}

*ldap.attribute.mapping* maps your LDAP to eXo. At first, there are two main parameters to configure in it:

{code:xml}
<field name="baseURL">
  <string>dc=exoplatform,dc=org</string>
</field>
<field name="ldapDescriptionAttr">
  <string>description</string>
</field>
{code}

* *baseURL*: root dn for eXo organizational entities. This entry cannot be created by eXo and must have existed in the directory already.
* *ldapDescriptionAttr*: Name of a common attribute that will be used as description for groups and membership types.

{warning}
In Core, the ldapDesriptionAttr key is present but not consistently used everywhere in code. When using *Core*, consider that the description is always mapped to the 'description' attribute.
{warning}

Other parameters are discussed in the following sections.

h3. Users {anchor:id=DEV.SystemIntegration.Users}
h4. Main parameters {anchor:id=DEV.SystemIntegration.MainParameters}
Here are the main parameters to map eXo users to your directory:

{code:xml}
<field name="userURL">
  <string>ou=users,ou=portal,dc=exoplatform,dc=org</string>
</field>
<field name="userObjectClassFilter">
  <string>objectClass=person</string>
</field>
<field name="userLDAPClasses">
  <string>top,person,organizationalPerson,inetOrgPerson</string>
</field>
{code}

* *userURL*: base dn for users. Users are created in a flat structure under this base with a *dn* of the form: *ldap.userDN.key=username,userURL*.

For example: {code}uid=john,cn=People,o=MyCompany,c=com{code}

However, if users exist deeply under _userURL_, eXo will be able to retrieve them.

Example: {code}uid=tom,ou=France,ou=EMEA,cn=People,o=MyCompany,c=com{code}

* *userObjectClassFilter*: Filter used under _userURL_ branch to distinguish eXo user entries from others.

Example: _john_ and _tom_ will be recognized as valid eXo users but _EMEA_ and _France_ entries will be ignored in the following subtree:

{code}
uid=john,cn=People,o=MyCompany,c=com
  objectClass: person
  ...
ou=EMEA,cn=People,o=MyCompany,c=com
  objectClass: organizationalUnit
  ...
    ou=France,ou=EMEA,cn=People,o=MyCompany,c=com
      objectClass: organizationalUnit
      ...
        uid=tom,ou=EMEA,cn=People,o=MyCompany,c=com
          objectClass: person
          ...
{code}

* *userLDAPClasses*: commas are used to separate list of classes used for creating users. 
When a new user is created, an entry will be created with the given _objectClass_ attributes. 
The classes must at least define _cn_ and any attribute referenced in the user mapping.

For example, adding the user _Marry Simons_ could produce:

{code}
uid=marry,cn=users,ou=portal,dc=exoplatform,dc=org
  objectclass: top
  objectClass: person
  objectClass: organizationalPerson
  objectClass: inetOrgPerson
  ...
{code}

h4. User mapping {anchor:id=DEV.SystemIntegration.UserMapping}
The following parameters maps LDAP attributes to eXo User Java objects attributes.

{code:xml}
<field name="userUsernameAttr">
  <string>uid</string>
</field>
<field name="userPassword">
  <string>userPassword</string>
</field>
<field name="userFirstNameAttr">
  <string>givenName</string>
</field>
<field name="userLastNameAttr">
  <string>sn</string>
</field>
<field name="userDisplayNameAttr">
  <string>displayName</string>
</field>
<field name="userMailAttr">
  <string>mail</string>
</field>
{code}

* *userUsernameAttr*: username (login)
* *userPassword*: password (used when the portal authentication is done by eXo login module)
* *userFirstNameAttr*: first name
* *userLastNameAttr*: last name
* *userDisplayNameAttr*: display name
* *userMailAttr*: email address

In the example above, the user _Marry Simons_ could produce:

{code}
uid=marry,cn=users,ou=portal,dc=exoplatform,dc=org
  userPassword: XXXX
  givenName: Marry
  sn: Simons
  displayName: Marry Simons
  mail: marry.simons@example.org
  uid: marry
  ...
{code}

h3. Groups {anchor:id=DEV.SystemIntegration.Groups}
eXo Platform groups can be mapped to organizational or applicative groups defined in your directory.

{code:xml}
<field name="groupsURL">
  <string>ou=groups,ou=portal,dc=exoplatform,dc=org</string>
</field>
<field name="groupLDAPClasses">
  <string>top,organizationalUnit</string>
</field>
<field name="groupObjectClassFilter">
  <string>objectClass=organizationalUnit</string>
</field>
{code}

* *groupsURL*: base dn for eXo groups
Groups can be structured hierarchically under _groupsURL_.
            
For example, groups, including _communication_, _communication/marketing_ and _communication/press_, would map to:
            
{code}
ou=communication,ou=groups,ou=portal,dc=exoplatform,dc=org
...
  ou=marketing,ou=communication,ou=groups,ou=portal,dc=exoplatform,dc=org
  ...            
  ou=press,ou=communication,ou=groups,ou=portal,dc=exoplatform,dc=org                          
  ...
{code}        

* *groupLDAPClasses*: commas are used to separate list of classes used for group creation. 
When a new group is created, an entry will be also created with the given objectClass attributes.
The classes must define at least the required attributes: *ou*, *description* and *l*.

{info}
The *l* attribute corresponds to the *City* property in OU property editor.
{info}
                        
For example, adding the _human-resources_ group could produce: 

{code}                       
ou=human-resources,ou=groups,ou=portal,dc=exoplatform,dc=org
  objectclass: top
  objectClass: organizationalunit
  ou: human-resources
  description: The human resources department
  l: Human Resources
  ...
{code}

* *groupObjectClassFilter*: This filter is used under the _groupsURL_ branch to distinguish eXo groups from other entries. You can also use a complex filter if you need.
            
Example: groups _WebDesign_, _WebDesign/Graphists_ and _sales_ could be retrieved in:

{code}           
l=Paris,dc=sites,dc=mycompany,dc=com
  ...
  ou=WebDesign,l=Paris,dc=sites,dc=mycompany,dc=com
  ...
    ou=Graphists,WebDesign,l=Paris,dc=sites,dc=mycompany,dc=com
    ...
l=London,dc=sites,dc=mycompany,dc=com
  ...
  ou=Sales,l=London,dc=sites,dc=mycompany,dc=com
  ...
{code}

h3. Membership types {anchor:id=DEV.SystemIntegration.MembershipTypes}
Membership types are the possible roles that can be assigned to users in groups.

{code:xml}
<field name="membershipTypeURL">
  <string>ou=memberships,ou=portal,dc=exoplatform,dc=org</string>
</field>
<field name="membershipTypeLDAPClasses">
  <string>top,organizationalRole</string>
</field>
<field name="membershipTypeNameAttr">
  <string>cn</string>
</field>
{code}          

* *membershipTypeURL*: base dn for membership types storage.
eXo stores membership types in a flat structure under _membershipTypeURL_. For example, roles, including _manager_, _user_, _admin_ and _editor_ could be defined by the subtree:

{code}           
ou=roles,ou=portal,dc=exoplatform,dc=org
...
  cn=manager,ou=roles,ou=portal,dc=exoplatform,dc=org
  ...
  cn=user,ou=roles,ou=portal,dc=exoplatform,dc=org
  ...
  cn=admin,ou=roles,ou=portal,dc=exoplatform,dc=org               
  ...
  cn=editor,ou=roles,ou=portal,dc=exoplatform,dc=org
  ...
{code}             

* *membershipTypeLDAPClasses*: commas are used to separat list of classes for creating membership types. 
When a new membership type is created, an entry will be also created with the given _objectClass_ attributes.
The classes must define the required attributes: *description*, *cn*. 

For example, adding the membership type _validator_ would produce: 

{code}          
cn=validator,ou=roles,ou=portal,dc=exoplatform,dc=org
  objectclass: top
  objectClass: organizationalRole
  ...                       
{code}

* *membershipTypeNameAttr*: Attribute will be used as the name of the role.
          
For example, if _membershipTypeNameAttr_ is _cn_, the role name will be _manager_ for the following membership type entry: 


{code}cn=manager,ou=roles,ou=portal,dc=exoplatform,dc=org {code}


h3. Memberships {anchor:id=DEV.SystemIntegration.Membership}
Memberships are used to assign a role within a group. They are entries that are placed under the group entry of their scope group.
Users in this role are defined as attributes of the membership entry.
            
* For example, to designate _tom_ as the _manager_ of the group _human-resources_: 

{code}          
ou=human-resources,ou=groups,ou=portal,dc=exoplatform,dc=org
  ...
  cn=manager,ou=human-resources,ou=groups,ou=portal,dc=exoplatform,dc=org
    member: uid=tom,ou=users,ou=portal,dc=exoplatform,dc=org
    ...                
{code}

The parameters to configure memberships are:

{code:xml}
<field name="membershipLDAPClasses">
  <string>top,groupOfNames</string>
</field>
<field name="membershipTypeMemberValue">
  <string>member</string>
</field>
<field name="membershipTypeRoleNameAttr">
  <string>cn</string>
</field>
<field name="membershipTypeObjectClassFilter">
  <string>objectClass=organizationalRole</string>
</field>
{code}

* *membershipLDAPClasses*: the commas are used to separate the list of classes for creating memberships.
When a new membership is created, an entry will be also created with the given _objectClass_ attributes.
The classes must at least define the attribute designated by _membershipTypeMemberValue_.
          
Example: Adding membership _validator_ would produce:

{code}           
cn=validator,ou=human-resources,ou=groups,ou=portal,dc=exoplatform,dc=org
  objectclass: top
  objectClass: groupOfNames
  ...
{code}

* *membershipTypeMemberValue*: Multi-valued attribute is used in memberships to reference users that have the role in the group. 
Values should be a user dn.

Example: _james_ and _root_, who have _admin_ role within the group _human-resources_, would give:

{code}
cn=admin,ou=human-resources,ou=groups,ou=portal,dc=exoplatform,dc=org
  member: cn=james,ou=users,ou=portal,dc=exoplatform,dc=org
  member: cn=root,ou=users,ou=portal,dc=exoplatform,dc=org
  ...
{code}                   

* *membershipTypeRoleNameAttr*: Attribute of the membership entry whose value refers to the membership type.
            
For example, in the following membership entry:
            
{code}
cn=manager,ou=human-resources,ou=groups,ou=portal,dc=exoplatform,dc=org
{code}
          
The _cn_ attribute is used to designate the _manager_ membership type. In other words, the name of role is given by the 'cn' attribute.

* *membershipTypeObjectClassFilter*: Filter is used to distinguish membership entries under groups. You can use the more complex filters.
            
For example, the following is a filter used for a customer that needs to trigger a dynlist overlay on openldap.
           

{code}(&amp;amp;(objectClass=ExoMembership)(membershipURL=&#42;)) {code}
          

{note}
Please pay attention to the xml escaping of the '&' (and) operator.
{note}

h3. User profiles {anchor:id=DEV.SystemIntegration.UserProfiles}
eXo User profiles also have entries in the LDAP but the actual storage is still done with the hibernate service.
You will need the following parameters:

{code:xml}
<field name="profileURL">
  <string>ou=profiles,ou=portal,dc=exoplatform,dc=org</string>
</field>
<field name="profileLDAPClasses">
  <string>top,organizationalPerson</string>
</field>
{code}

* *profileURL*: base dn to store user profiles
* *profileLDAPClasses*: Classes used to when creating user profiles

h2. Active Directory sample configuration {anchor:id=DEV.SystemIntegration.ActiveDirectorySampleConfiguration}
Here is an alternative configuration for active directory that you can find in *activedirectory-configuration.xml*.

{code:xml}
[...]
<component>
  <key>org.exoplatform.services.ldap.LDAPService</key>
  [..]
  <object type="org.exoplatform.services.ldap.impl.LDAPConnectionConfig">         
  <!-- for multiple ldap servers, use comma seperated list of host:port (Ex. ldap://127.0.0.1:389,10.0.0.1:389) -->
  <!-- whether or not to enable ssl, if ssl is used ensure that the javax.net.ssl.keyStore & java.net.ssl.keyStorePassword properties are set -->
  <!-- exo portal default installed javax.net.ssl.trustStore with file is java.home/lib/security/cacerts-->
  <!-- ldap service will check protocol, if protocol is ldaps, ssl is enable (Ex. for enable ssl: ldaps://10.0.0.3:636 ;for disable ssl: ldap://10.0.0.3:389 ) -->
  <!-- when enable ssl, ensure server name is *.directory and port (Ex. active.directory) -->	  		 
    <field  name="providerURL"><string>ldaps://10.0.0.3:636</string></field>
    <field  name="rootdn"><string>CN=Administrator,CN=Users, DC=exoplatform,DC=org</string></field>
    <field  name="password"><string>site</string></field> 		
    <field  name="version"><string>3</string></field>	            
    <field  name="referralMode"><string>ignore</string></field>     	       	       
    <field  name="serverName"><string>active.directory</string></field>    	       	  
  </object>
  [..]
</component>
<component>
  <key>org.exoplatform.services.organization.OrganizationService</key>
  [...]
  <object type="org.exoplatform.services.organization.ldap.LDAPAttributeMapping">                
    [...]
    <field  name="userAuthenticationAttr"><string>mail</string></field>
    <field  name="userUsernameAttr"><string>sAMAccountName</string></field>
    <field  name="userPassword"><string>unicodePwd</string></field> 
    <field  name="userLastNameAttr"><string>sn</string></field>
    <field  name="userDisplayNameAttr"><string>displayName</string></field>
    <field  name="userMailAttr"><string>mail</string></field>
    [..]
    <field  name="membershipTypeLDAPClasses"><string>top,group</string></field>
    <field  name="membershipTypeObjectClassFilter"><string>objectClass=group</string></field>
    [..]
    <field  name="membershipLDAPClasses"><string>top,group</string></field>
    <field  name="membershipObjectClassFilter"><string>objectClass=group</string></field>
  </object>
  [...]  
</component>  
{code}

{info}
There is a Microsoft limitation: the password cannot be set in AD via unsecured connection, you have to use the LDAPs protocol.
{info}

Here is how to use the LDAPs protocol with the Active Directory:

*1.* Set up AD to use SSL:

*i.* Add the Active Directory Certificate Services role.

*ii.* Install the right certificate for the DC machine.

*2.* Enable Java VM to use the certificate from AD:

*i.* Import the root CA used in AD, to keystore, such as: keytool -importcert -file 2008.cer -keypass changeit -keystore /home/user/java/jdk1.6/jre/lib/security/cacerts.

*ii.* Set the Java options as below:

  _{noformat}JAVA_OPTS="${JAVA_OPTS} -Djavax.net.ssl.trustStorePassword=changeit -Djavax.net.ssl.trustStore=/home/user/java/jdk1.6/jre/lib/security/ca"{noformat}_

h2. Picketlink IDM {anchor:id=DEV.SystemIntegration.PicketlinkIDM}
eXo Platform uses the PicketLink IDM component to keep the necessary identity information, such as users, groups, memberships.
While the legacy interfaces are still used (org.exoplatform.services.organization) for the identity management, there is a wrapper implementation that delegates to the PicketLink IDM framework. 
For further information, visit [here|http://jboss.org/picketlink/IDM.html].

The project exo.core defines the API for Organization Service, and the eXo Platform implementation of API. For the Organization Service plugged in the eXo Platform product, you are flexible in switching between: eXo Organization Service, PicketLink and your own implementation.
The configuration to switch between various Organization Service implementations can be found in _portal.war/WEB-INF/conf/configuration.xml_:

{code:xml}
<!--PicketLink IDM integration -->
<import>war:/conf/organization/idm-configuration.xml</import>

<!--Former exo implementations -->
<!--<import>war:/conf/organization/exo/hibernate-configuration.xml</import> -->
<!-- <import>war:/conf/organization/exo/jdbc-configuration.xml</import> -->
<!--for organization service used active directory which is user lookup server -->
<!-- <import>war:/conf/organization/exoactivedirectory-configuration.xml</import> -->
<!--for organization service used ldap server which is user lookup server -->
<!-- <import>war:/conf/ldap-configuration.xml</import> -->
{code}

If you want to switch between different implementations, you just need to uncomment the corresponding <import> and leave others commented:

{code:xml}
<!--PicketLink IDM integration -->
<import>war:/conf/ldap-configuration.xml</import>
<!-- <import>war:/conf/organization/idm-configuration.xml</import> -->
<!--Former exo implementations -->
<!--<import>war:/conf/organization/exo/hibernate-configuration.xml</import> -->
<!-- <import>war:/conf/organization/exo/jdbc-configuration.xml</import> -->
<!--for organization service used active directory which is user lookup server -->
<!-- <import>war:/conf/organization/exoactivedirectory-configuration.xml</import> -->
<!--for organization service used ldap server which is user lookup server -->
{code}


h1. Email {anchor:id=DEV.SystemIntegration.Email}

The email service can use any SMTP account configured in _{noformat}$JBOSS_HOME/server/default/conf/gatein/configuration.properties{noformat}_ or _{noformat}$TOMCAT_HOME/gatein/conf/configuration.properties{noformat}_ if you are using Tomcat.

The relevant section looks like:

{code}
# EMail
gatein.email.smtp.username=
gatein.email.smtp.password=
gatein.email.smtp.host=smtp.gmail.com
gatein.email.smtp.port=465
gatein.email.smtp.starttls.enable=true
gatein.email.smtp.auth=true
gatein.email.smtp.socketFactory.port=465
gatein.email.smtp.socketFactory.class=javax.net.ssl.SSLSocketFactory
{code}

It is pre-configured for Gmail, so any Gmail account can easily be used. You simply need to use the full Gmail address as username, and fill in the password.

In corporate environments, you will want to use your corporate SMTP gateway. When using it over SSL, like in the default configuration, you may need to configure a certificate trust-store, containing your SMTP server's public certificate. Depending on the key sizes, you might also need to install Java Cryptography Extension (JCE) Unlimited Strength Jurisdiction Policy Files for your Java Runtime Environment.
