It is fun to reflect upon how software development has changed over the years. I remember a time when websites and internal business applications were all custom built by a team of developers. If changes to the software were required the task was assigned to a developer. Fortunately, those days are long gone.

The industry quickly moved from custom built websites to CMS systems and from custom built applications to CRM’s. It is now taken for granted that the business staff have the ability to manage their own website content and orchestrate their own business process workflows using packaged software and SaaS services such as iMIS.

Packed/SaaS Software

Packaged Software and SaaS services have many advantages. Custom software development is expensive. If a service can be developed and the cost shared between many customers then the software development effort becomes much more economical. In addition, most services are focused on one specific problem domain and therefore are able to invest all of their resources on a single problem domain. As time passes, the software evolves and improves, surpassing in quality and depth, any custom software that would have been built with a limited budget.

Custom Software

Still, there are those that argue that custom solutions are preferable. They argue that the cookie cutter nature of packaged software and services offer a general solution to a company’s specific and unique problem. That the products may be hard to customize and modify. Or that the software update process, being dependent on the cadence of the development firm, impedes business by changes not being available when the business may need them.

Software Integration

Both positions have valid points, but ideally there should be a middle ground where we can find a balance between the two extremes. The middle ground in this case is software integration, which, if implemented properly can be used to achieve “best of breed” results.

An organization has many business processes. A specific packaged software solution may satisfy the majority of an organization’s requirements in a satisfactory way. However, there will usually remain a certain percentage of business processes which are not ideally suited by the packaged software. In such cases, an organization can choose to live with the mismatch. They may choose to integrate with another software system that is better fit for their use case. Or, perhaps, they may opt to build a custom solution for that specific process. By mixing and matching, an organization can strive to achieve the best solution possible for their processes.

Benefits of Software Integration

Software integration today, does require effort as it is not yet fully streamlined. I do envision a day when software integration between services will be automated and at our fingertips much like the cloud hardware infrastructure is today. But until that time arrives, it will take effort and there will be a cost. That cost, however, is significantly less than building everything from scratch and there are many benefits to having a proper integration framework in place that will provide an ROI.

1. Increasing operating efficiency.
2. Improve member engagement by offering best of breed solutions.
3. Remain agile and be capable of quickly responding to changing conditions and requirements.
4. The ability to swap 3rd party services with minimal friction.
5. The ability to expose your data and business logic to external partners.

If the integration is implemented correctly, it can provide a solid platform for continual business growth. The tools and technologies at our disposal have evolved significantly over the years. How are you leveraging these new technologies to benefit and grow your organization?

Software Integration Considerations

If you find yourself considering a software integration solution then there are a few things that you should understand and consider. Integration solutions today boil down to two fundamental concerns:

Single Sign On (SSO)

Each system is independent. However, that fact must be transparent to end users. There have been many approaches employed in the past to achieve SSO. However, the two main recommended approaches are based on industry standards.

SAML2

The SAML2 protocol is an older but still common technology used to achieve SSO.

OpenID Connect

The latest, more modern approach is OpenID Connect. OpenID Connect is more web and mobile friendly.

When performing an integration, it is important to follow these standards and avoid inventing a custom, proprietary solution to achieve SSO. SSO is a solved problem. It is not recommended to home grow your own SSO solution.

API’s

An API, or Application Programming Interface, is a way for two or more systems to communicate information between each other. In order to communicate, each system must expose an API. The API’s are used to expose business logic and data to external systems. There are standards such as REST and GraphQL that formalize how this communication takes place. In addition, there are security standards such as OAuth 2 the govern how to properly secure access to these API’s. It is important to have a well designed and secure API so that it can be easily and securely consumed by external systems.

Additional Concern

Loose Coupling

Loose coupling means that the two systems can be modified independently of one another without causing adverse effects on one other. This can be achieved by properly implementing the standards specified above and by employing proper coding patterns. It is important that the integrated systems remain loosely coupled so each can be changed and upgraded independently of one another.

When engaging in any software integration project it is imperative to keep these considerations in mind as they are the key factors that differentiate a successful integration that fosters future growth vs. one that does not.

Mobile apps and "external javascript apps" are not currently supported by iMIS. You would need to implement a server side component on your end.

Integration Concerns

To provide some perspective, there are two main concerns when integrating with iMIS using an external application:

1. User Identity

   We need a way for our application to establish the users identity. That application may be a native app (mobile or desktop), a javascript app, or a server side app.

2. Access Tokens (OAuth 2)

   We need to obtain an access token in order to call the iMIS API. An access token can represent either a. the logged in user b. the client application

OAuth 2 Flows

APIs are usually secured by OAuth 2 using access tokens. Oauth 2 supports 4 types of flows for obtaining an access token. I will simply list them here and not describe them. There are many resources that already describe them.

1. Resource Owner
2. Client Credential
3. Authorization Code
4. Implicit

iMIS & OAuth 2

The iMIS Token endpoint supports the Resource Owner flow for two different use cases.

Use Case 1 - Remote Service

a. Create an "application user" in iMIS with a username and password. 
b. Assign the RemoteService role to that "application user".  
c. Aapplication(s) can now use this username and password to obtain an access token.

grant_type=password
username=###
password=###

* This approach supports service side apps only because you need to be able to keep the username and password secure.
* The access token does not represent the logged in user.  Instead it represents the fictitious "application user" that was defined for this purpose.
* Permissions are restricted based on how you defined the permissions in iMIS for the "application user".

Use Case 2 - SSO iPart

a. Using the SSO iPart, iMIS implements the Resource Owner flow and ultimately passes back the refresh token to the application.
b. The application can then use the refresh token to obtain an access token. The token endpoint responds with not only an access token but a few other properties as well, such as a new refresh token and the user name, which we can use to "establish identity". Technically, this is a misuse of OAuth 2 as OAuth 2 is not supposed to be used for authentication.

grant_type=refresh_token
client_id=###
client_secret=###
refresh_token=###

* This approach is a server side approach because it requires a client id and client secret. 
* Additionally, a "user agent" is required to implement the flow.
* After exchanging the refresh token you get an access token in the response and the "user id".
* The access token represents the logged in user.

OpenID Connect

OpenID Connect is the preferred way to establish identity. OpenID Connect adds authentication on top of OAuth 2. When using OpenID Connect your application will receive an Identity Token and an Access Token. The Identity Token is cryptographically linked to the access token and can be used by your application to establish identity.

iMIS Identity Server

We were facing similar issues with authenticating external applications. We solved them by creating iMIS Identity Server. iMIS Identity Server adds OpenID Connect support to iMIS. With iMIS Identity Server you can support any use case that you encounter. You can learn more here http://www.organizedbits.com/imis-identity-server.html

The Benefits

The benefits of iMIS Identity Server are that

1. It allows you to secure all type of applications (native/mobile apps, js apps, and server side web apps)
2. It supports Single Sign On and Single Sign Off between iMIS and 3rd party applications.
3. Additionally, it allows you to build and secure your own APIs if desired.

If you'd like more information please reach out to us.