Overview
As our connectivity framework has matured to include direct SaaS-to-SaaS communications (aka SaaS 2.0), there is a meaningful opportunity to transition our VA-based implementations over to the new connectivity framework whenever it is in the customer’s best interests. This document attempts to lay out some guiding principles for deciding when one connectivity method should be preferred over another, provide a rubric against which a given decision should be measured, as well as address some likely questions that may arise from the customer and the implementation team.
Guiding Principles
-
With all else being equal, the chosen connectivity pathway should aim to minimize the cost to the customer.
-
When considering Web Services-type connectivity, both VA-based Web Services and SaaS 2.0 connectors require large degrees of customization. Thus, the implementation should strive to be as flexible and portable as possible to maximize reuse, no matter which connector is chosen. There is also a SaaS 2.0 version of the Web Services connector that is configured similar to the VA-based connector, and also supports custom before/after logic via Connectivity Customizers (these are SaaS 2.0 versions of Web Services Before Operation and After Operation rules).
-
VA-based connectors utilize Beanshell/Java for custom code, whereas SaaS 2.0 connectors use TypeScript. The languages are similar, but execution is very different. The implementer should understand the implications of this difference and leverage the provided enablement material:
-
There is a wide breadth of skills available to the SailPoint community and established pathways to get implementation help, either directly from SailPoint Professional Services, from SailPoint implementation partners, or even from the SailPoint Developer Relations community via that team’s community forum. Thus, the implementer’s own skillsets should not be a hindrance in deciding which connector to use - lack of Java or TypeScript knowledge should not factor into the decision.
-
We are only considering “net new” implementations for this guide. Refactoring existing connections which are well-working is not needed, but connections which have been made using one technology can be ported to the other if the in situ configuration is not meeting the business use case.
Understanding Connector Operations: Is the Application IGA Compliant?
Before a new connector is built, it would be wise to conduct a feasibility analysis against the application’s API operations to see if an IGA-ready integration is even possible. The below table highlights some of the operations SailPoint’s Identity Security Cloud expects to be able to call, and the details around those operations:
|
Operation |
Details |
|
Test Connection (Must) |
|
|
Full Account Aggregation (Must) |
|
|
Delta Account Aggregation (Could) |
|
|
Single Account Aggregation (Must) |
|
|
Entitlement Aggregation (Must) |
|
|
Create Account (Must) |
|
|
Add/Remove Entitlement (Must) |
|
|
Enable/Disable/Delete (Should) |
|
|
Update Account – Attribute Sync (Could) |
|
VA-Based versus SaaS 2.0 Decision-Making Rubric
The below chart highlights some aspects of the overall customer use case, or nuances of the target system, which might sway an implementer’s opinion about the most appropriate connectivity pathway. This is not an exhaustive list, and it may evolve over time as the IdentityNow connectivity platform changes, but the items below should provide sufficient weight behind one connector versus the other.
|
Consideration |
Connector Preference |
Comments |
|
| 1 |
The target application does not allow inbound connections from outside of the customer’s environment. |
|
For SaaS-to-SaaS connectivity to work, the target application must accept inbound connections from our SaaS platform. If not, then the only direct connectivity route would be via the Virtual Appliance (VA). |
| 2 |
The customer requires whitelisted access to the target application, either through pre-defined IP ranges or through Fully Qualified Domain Names. |
|
Because the SaaS 2.0 framework is strictly cloud-to-cloud, there is no guarantee as to which points of origin any connection would initiate from on the SailPoint side. If the customer absolutely must whitelist via IP address/range, then a VA-based connection is preferable since the connectivity would route through the VA cluster, and the customer would know the IPs of those appliances. Note that there is a process by which customers can whitelist the specific IP addresses of their IdentityNow tenant /
IP Address Allow List | SailPoint Developer Community to allow tightly-controlled inbound connections. This process requires ongoing action on the part of the customer, so may not always be possible, but the capability should be highlighted and offered as an option. There is also an option to accommodate SaaS 2.0 connectivity by setting up a reverse proxy in front of the target application so that inbound requests can be accepted from any origin and re-routed from the proxy server’s IP. Again, this is additional network and infrastructure configuration that the customer would need to undertake, so while it may not always be an option, it is worth discussing with the customer. |
| 3 |
Complex provisioning operations are in scope for this application (i.e., we will need to do more than simply read from the target system or need more than out-of-the-box provisioning capabilities). |
|
In read-only use cases, it is often far easier to simply leverage the VA-based Web Services connector. But if very complex Before/After Operation rules are needed (e.g., for resource object customization), then a SaaS 2.0 connector might be worth exploring - either a SaaS Web Services connection or a brand new “custom” connector based on the SaaS 2.0 framework. |
| 4 |
The target system’s API structure requires multiple lookup calls to get human-friendly names or descriptions for account/entitlement attributes |
|
Sometimes, an API response for an account object will only return GUIDs or IDs for things like job locations, departments, etc. If the actual names are needed instead, a second API call is necessary to increase the number of sequential connector operations that must be executed. In these situations, a SaaS 2.0 connector has an innate advantage because all calls are triggered asynchronously. Thus, more API calls can be executed over a given period of time. |
| 5 |
The target system has tens of thousands of records which need to be aggregated. |
|
When very large populations must be managed within the target system, a slight preference is given to the SaaS 2.0 connector framework thanks to its default multi-threaded behavior. The VA-based Web Services connector can support a form of multi-threading through its partitioned aggregation configuration, so this is not necessarily a reason on its own to use SaaS 2.0. |
| 6 |
The target system is a major SaaS vendor or commonly appears as “in scope” for our customer base. |
|
If we see a system often enough, and especially if the prevalent use cases involve custom logic/provisioning, it is best to stand up this source via SaaS 2.0 connectivity. This way, re-deploy of that same connector can be done without having to involve repetitive rule reviews, re-configuration of schema attributes and mappings, etc. |
| 7 |
Complex operations which require extended authentication values. |
|
Even with the most complex out-of-the-box authentication scheme selected, the VA-based Web Services connector only supports a handful of secure strings as inputs into the configuration. If special authentication headers or additional authentication attributes are needed, the implementer can accommodate them with the custom SaaS 2.0 connectors. The source configuration flexibility afforded by these custom connectors makes working with these use cases easier than with a VA-based connector. |
| 8 |
The connector operations require callouts into other applications. |
|
In certain complex configurations, one must either call back into IdentityNow or call out to a third-party application to obtain additional information or take further action outside the target application. Before/After Operation rules could potentially solve this requirement from a VA-based Web Services connector configuration, but it would likely require authentication information (that doesn’t fit within the Web Services configuration) to be hard-coded within connector rules. That coding practice is undesirable, so leveraging a SaaS 2.0 connector’s flexible source configuration framework is the preferred architecture to solve these kinds of use cases. |
| 9 |
The target system leverages complex or non-RESTful API paradigms. |
|
Occasionally, we run into web applications where the method for requesting information is an asynchronous process or involves mixed payload types. For example, some systems require aggregation to be a two-step process: First, request a data report and receive a report ID. Then, after a period, come back to request the generated report via the provided ID. With VA-based Web Services, this is hard to orchestrate while conforming to IdentityNow rule best practices. With a SaaS 2.0 connector, however, intentional delays, loops, etc., are perfectly allowable as the SaaS 2.0 runtime is constrained to the individual tenant. Poorly written connectors that result in out-of-memory errors, infinite loops, etc., will only impact the tenant in which they’re deployed. |
| 10 |
The target system leverages a non-standard method for rate-limiting. |
|
The VA-based Web Services connector does support automatic rate limiting via an exponential back-off algorithm which is invoked by a 429 response header from the target system. However, other methods of rate limiting (e.g., non-429 responses, retry-after notifications, etc.) are not supported through the standard Web Services connector. A SaaS 2.0 connector, though, can be written to accommodate these use cases quite easily. |
Frequently Asked Questions
From a Services perspective, the pivot to SaaS 2.0 connectors likely will raise some questions for implementers. Some of the ones we’ve heard most frequently are:
-
The standard Web Services connector resides on the VA and therefore benefits from the asymmetric keypair encryption scheme encapsulated with that technology. Are the credentials for the SaaS 2.0 connectors considered to be as safe?
-
Yes, the asymmetric keypair scheme is still leveraged for SaaS 2.0 connectors - the keystore simply resides in the cloud instead of on the VA. This keystore is not accessible by any API or source code. Our DevOps-owned processes also regularly rotate those keypairs to ensure that security is maintained to SailPoint standards.
-
-
Do you have a flowchart or decision tree which I can share with my customer to help them understand the decision to go with Web Services versus SaaS?
-
Absolutely:
-
Additional Resources
