Have you ever had to sign in on a website multiple times? It gets frustrating, doesn’t it? There’s a good reason for it. The website uses third-party applications to give you the features you need to complete tasks on the website. Each application has its own security so it can protect your information. Thus, multiple logins.
But that’s not the smooth user experience you want to deliver to your members. So many associations choose to have those third-party applications integrated with iMIS. When they are integrated, you can provide single sign-on and a more seamless experience to your members.
Let’s look at some of the different ways those applications can be integrated.
Integration technologies
Typically, you’ll hear about the following technologies:
• API
• SOA and Web Services
• XML
• Token Authentication
• SAML
Application Programming Interface (API)
Application programming interfaces, or APIs, are created to make it easy for software developers to connect applications together – to share data back and forth, and for one software application to take advantage of the capabilities of another. When an application offers an API, they are trying to make it easy for other organizations to extend their app. Companies release their APIs in a software development kit (SDK) or post it on the internet as an open API.
For example, an association uses a web-based email marketing tool to create and manage email campaigns. They want to integrate it with iMIS, so they can run reports about email campaigns and their users. They want to combine the information that’s in iMIS with the email marketing tool to create reports.
The email marketing company isn’t going to provide access to their database to anyone, and they don’t want other developers modifying their code. Instead, they make an API available, and provide documentation about how to use it. That keeps them in control of how the other applications can access theirs. When association’s developers need information from an API, they call the API using service-oriented architecture (SOA).
Service-oriented Architecture (SOA) and Web Services
Service-oriented architecture (SOA) is an architectural concept in which a group of apps or datasets that work together through a defined method. An example of this is Amazon. Everything on Amazon uses a single login: Prime, website, video, music, and ebooks. All of these are separate services.
When a user signs in Amazon, the SOA calls the security app to verify the credentials and responds back with a confirmation. All of these services run independently, but they rely on each other.
In calling the security app and getting a response, the SOA relies on a web service. A web service is a platform-independent program. It runs a program over the web using hypertext transfer protocol, or HTTP to tell another program what to do. IMIS SOA and iMIS web services work similarly. They provide a standard way for many third-party applications to communicate with iMIS, regardless of platform or technology.
XML
XML, extensible markup language, is a data format. Like HTML, XML data can’t do anything by itself. HTML displays data and XML carries data. It needs an API that uses web services to process it.
SOAP uses XML as the messenger to make requests and receive responses. XML stores and transports data. SOAP provides the envelope to send messages using XML that includes header information and a body with the call and response information.
Although REST can use XML, it’s a lighter alternative to SOAP. It can use XML, URL, CSV, JSON, and RSS for sending requests and getting responses.
Token Authentication
A token-based authentication system lets users enter their username and password into a website or application. The application verifies the credentials and provides a signed token to the user’s client. The client stores the token and sends it with every HTTP request to the website or application. The site uses a form of authentication — such as a header, GET or POST request, or cookie — to determine what level of access to provide.
The advantage of token-based authentication is that it’s stateless. The server does not store any information about the user. This lowers the server load, streamlines permission management, and allows an application to scale without worrying about where the user is logged in.
SAML
Security assertion markup language (SAML) is an XML-based standard used for single sign-on through a web browser. It uses tokens to exchange identity information between the identity provider and the application. The identity provider authenticates users and lets the application know it has authenticated a user.
When using SAML, users do not need to enter credentials or remember passwords. They log in once and the identity provider takes over the authentication. SAML is like Bluetooth. You simply turn on Bluetooth and it connects two devices. Plug-and-play. Instead of connecting two devices like Bluetooth does, SAML connects two applications to provide secure access.
How Third-Party Integration Improves the User Experience
Remember the multiple login problem? You can solve that problem by integrating third-party applications without any programming. Third-party developers use APIs, web services, and data to extend other apps. Together, these technologies communicate with each other to send and receive information regardless of platform, protocol, or language.
For example, a user logs in iMIS to use online meeting software such as GoToMeeting. To prevent multiple logins, iMIS communicates with SAML to authenticate a member. The member won’t have to login more than once, not even to access GoToMeeting, a separate application from iMIS.
In short, third-party integrations create a seamless user experience. When users cross components or apps such as iMIS and GoToMeeting, they don’t run into barriers. These technologies make it possible for apps to communicate, send and receive responses, and interpret data.
Get a Single Login with ISG’s SAML for iMIS
ISG’s SAML for iMIS module allows iMIS to be the source of login and authentication. Associations can grant permissions in iMIS. You keep permissions updated in one place — just in iMIS — and all your applications use the same security.
Once you install SAML, you can add more applications with little effort. If you change your learning management system, for example, you don’t need to have a new integration built. You just plug it into your SAML for iMIS module, and you’re all set.
Not all apps support SAML. If yours doesn’t, some of the other integration options we just discussed can be used. Contact sales@isgsolutions.com to learn more about your integration options and see what will be most useful for your association.