I have been quite for a while on this blog. Thanks to one of the most fascinating projects I have been working since January. One of my major focus area has been integrating SharePoint 2013 On-Premises environment with SAAS applications like Yammer and Office 365 through federation providers like On-Premises ADFS.
As most of organizations moving towards cloud, SAAS integrations with On-Premises SharePoint will become more common for few years. As part of initial discussions and discovery sessions with SAAS provider’s technical team, there has been typical list of questions any SharePoint 2013 architect should tackle while integrating SAAS applications with SharePoint. Here are the high level questions I have been asking and I felt like it would be really useful to post on this blog.
- # of Environments and Free accounts in each environments – How many SAAS environments can be provisioned for your organizations to support typical software development lifecycle e.g. DEV, TEST, PROD?
- Identity Management, User Provisioning, User Deprovisioning, & Single Sign on Requirements – identity management, user profiles, & single sing on are key for multiple platforms integration. Some of the common approaches are manual export of user data, lazy-load during API calls, Directory Sync (like ADSync in Yammer and DirSync in Office 365), or manually creating local accounts in the SAAS systems. Key here is to have federated identities able to map on-premises identities for single sign on and platform integration. In addition to seeding users in the SAAS systems, additional questions like what would happen if UPN (if Email is UserID) changes for the user or what options available to sync and deprovisioning users.
- Infrastructure, Firewall, and Network requirements
- Since SAAS provider needs to communicate with SharePoint On-Premises farm in hybrid implementation, many of SAAS providers supports data communication over SSL – 443 web proxy port. As long as both servers and user desktops are open to web proxy 443 port for outside communication, user and custom code should be able to communicate with external provider.
- What are the logon requirement for federation identity provider? Do you support email or any user id?
- Any other infrastructure requirements? e.g. reverse proxy, firewalls, IP addresses, proxy servers in DMZ etc.
- Platform Release Cycle – This is key. Since SAAS providers can update their software independent of your release cycle (e.g. every two or three months), it is nice to understand backward compatibility of your integration.
Please provide feedback and let me know if I have been missing anything for others.