...

Within the community bonding period learning was focused on how to do things "The apache way". This required getting used to communication over the mailing list, becoming equated with our developing a relationship with my mentor, learning to use git, adding documentation to the project and finally creating a patch that was submitted to the review board.

...

Along with this I exploded the testing framework developed for Cloudstack. Within the Coding stage this became very important.

Midterm review

During the code stage I began to investigate the current LDAP implementation. This includes:

• The user authenticator (plugins/user-authentication/ldap) This allowed the cloudstack login to allow LDAP based enables LDAP users to login once they exist to Cloudstack once the user exists within the cloudstack internal Cloudstack database.
• LDAPConfig (api/src/org/apache/cloudstack/api/command/admin/ldap/LDAPConfigCmd.java) This exposed a functionality allows for adding an LDAP configuration. This is detailed over here: https://cloudstack.apache.org/docs/api/apidocs-4.1/root_admin/LDAPConfigldapConfig.html^{Image Modified} This did not allow multiple configurations.
• LDAPRemove (api/src/org/apache/cloudstack/api/command/admin/LDAP/LDAPRemoveCmd.java) this allowed This allows for removing the LDAP configuration
• UI features. Global settings -> LDAP configuration allowed for the addition of a single LDAP server using the LDAPConfig command and the removal of an LDAP server using the LDAPRemove command.

After reviewing this code and implementation for some time I realised that it wasn't the most maintainable code. I realised I could existed extend it if required but . But it would involve creating more unmaintainable code and it would be messy, which . This goes against my own principles of developing quality. This made me make the steep but justified decision to completely redo the LDAP implementation within Cloudstack. By doing this I did chance expanded the scope of the project but it was justified for ease of expansion.

I began to research the most appropriate way of structuring this. I started of by redoing the implementation. This meant creating the following classes(Excluding DAOs):

• LdapManager

...

• : Manages all LDAP connections.
• LdapConfiguration

...

• : Supplies all configuration from within the Cloudstack database or defaults where required.
• LdapUserManager

...

• : Handles any interaction with LDAP user information.
• LdapUtils

...

• : Supplies static helpers, e.g. escape search queries, get attributes from search queries.
• LdapContextFactory

...

• : Manages the creation of contexts.
• LdapAuthenticator

...

• : Supplies an authenticator to Cloudstack using the LdapManager.

From this I had a solid foundation for creating API commands to allow the user to interact with an LDAP server. I went on to create the following commands:

...