With the information gathered in the previous stage, we can narrow down our integration options to determine if we need to make code changes to support the integration. The next sections will detail the specifics for integrating the different application formats, however the following general steps should be considered for all application formats before opening up the code in the application:
- Leverage SSO support provided by infrastructure or framework - The goal is to leverage an open standard to provide maximum security and interoperability between partners, vendors and customers. Once the application can speak an open standard, then managing connections can be made via configuration rather than code. For example, if a web application can accept a SAML assertion to sign a user in, then using PingOne or PingFederate multiple partners (i.e. enterprises via SAML, social networks via OpenID Connect etc) can be connected and presented to the application through that SAML connection.
- Leverage an access gateway (i.e. PingAccess) to handle the authentication - PingAccess can be used to protect web applications and APIs by handling the protocol work and presenting the user attributes to the application or API via HTTP headers or cookies. If the application or API can be protected behind an access gateway like PingAccess the work of integrating an application can be greatly simplified and the benefits of administration of authentication and authorization policies can be easily implemented.
- Leverage the federation engine (i.e. PingFederate) to handle token translation - PingFederate is highly skilled at exchanging tokens in a standard and interoperable manner. Scenarios such as protocol transition (i.e. providing SAML SSO to an application that is configured to use the WS-Federation protocol) can easily be achieved. Rather than re-writing the authentication logic, the PingFederate protocol engine can perform all the work. The same is true for applications that have API requirements. Although a cleaner solution maybe be to use OpenID Connect and OAuth 2.0 for a web application that calls OAuth protected API's, a simpler and quicker solution may be to retain a SAML authentication model and provide an OAuth access token as an attribute of the assertion or exchange the assertion for an OAuth access token.
- Finally, integration via code. Either implementing open standards support in the application directly or using an integration kit to simplify the integration of standards into the application.