Most of our website redesign projects entail some level of integration with an a third-party system, and usually in our projects this is an association management system (AMS). These integrations differ in scope and requirements, but always follow the same process on the development side. Our development plan for the integration follows the outlined steps.
To determine the scope and budget of the integration, we ask these questions:
- Will there be one login form to authenticate both systems (i.e. single sign on)?
- What roles will users be assigned in the CMS and AMS?
- Are there other types of groups or membership types that have special functionality?
- Will users be able to edit their profile?
- Will users be able to sign up for or renew their memberships online?
- Will there be online event registration?
- Will there be e-commerce functionality (shopping cart, payment processors, etc)?
- Will the CMS have role-oriented content?
Once the questions are answered – and we know exactly what needs to be integrated – we research our integration options.
The integration options largely depend on the APIs from the third-party system and the access options to the system:
- Does the CMS have an existing module/plugin available for the AMS integration?
- Is there a web service available?
- Are we authenticating against a remote database?
- What other options are available for single sign on?
- Is there a development installation of the AMS for testing purposes?
Based on the scope and options available for the integration, we then decide how a user will connect.
- Will the user login to the CMS (which will authenticate against the AMS and return with the necessary information to the CMS) or will the user login to the AMS (and then add login token to their user session in the CMS)?
- How do we provide the reverse authentication scenario if the login is performed in a non-standard way?
- What information is available to the CMS (from the AMS) to use for personalization?
Build and Test
Once all of the decisions have been made, we develop our user stories to cover all scenarios of user interaction between the CMS and AMS. Those user stories are used in our build phase and translated into our testing plan with test users to fit each story. Once build is done for each user story, our QA team tests each scenario and reports findings and any issues found.
Single sign on can be simple or complex, but using this plan makes it very organized to build, easy to test, and provides our clients with a functional single sign on process to fit their needs and budget.