Single Sign-On (SSO) systems are very common in large enterprises. In particular, some legislation such as Sarbanes-Oxley or HIPAA is difficult to achieve compliance with, without SSO.
Examples of SSO software providers include Ping, ADFS, and Okta. These systems typically consist of a federation server that provides integration with third-party applications such as Salesforce.
Many customers integrate SSO or Reduced Sign-On (RSO) throughout their enterprises. In most cases, Skedulo can support these systems if they can be integrated with the Salesforce log in process.
For customers on the Windows platform, it is very common for SSO to be implemented with Integrated Windows Authentication (IWA). This technology utilizes the user's login credentials to log into applications without requiring the password to be re-entered; This is well supported on Internet Explorer/Edge on Windows, and some integration is available on other platforms. The fallback mechanism uses NTLM authentication which prompts the user for their Windows Domain login and password.
OpenID is a web-based protocol for authenticating users to an application using a third-party identity provider. Authentication typically happens by the application using redirects to send the user to a login page on the third party. After obtaining consent from the user to access the application, they are redirected back to the application with authentication credentials. The Skedulo Phoenix application uses OpenID as its core authentication mechanism.
Security Assertion Markup Language (SAML) is a standard for exchanging authentication mechanism between providers using XML. It also provides a standard protocol for exchanging this data via web directs similar to OpenID. It can be thought of as an alternative technology which provides a similar function. SAML is used exclusively by Ping.
Salesforce has excellent integration with both OpenID and SAML identity providers. To use SSO, customers are typically required to create a custom domain in Salesforce (e.g., customer.my.salesforce.com) and configure either an OpenID or SAML identity provider. Customers will then either enter this URL directly into the browser or enter it by selecting the "Use Custom Domain" option from the Salesforce login menu.
The customer will then be redirected to the Federation Server login. If using Integrated Windows Authentication on a supported browser, the user will be authenticated without a password being prompted and then redirected to the Salesforce application. Otherwise, a form will be shown requiring them to enter their username and password. If this is the first time they have logged into Salesforce, a "consent" dialog will be shown asking whether the user account should be allowed to access Salesforce data.
Whether you are using Skedulo classic or the new web app, the experience is the same. When logging into Skedulo, you will be presented with the Salesforce login dialog above.
To log in using SSO, you must select the "Use Custom Domain" option and enter the custom domain. The login flow is then identical to the Salesforce experience. If using a supported browser/environment then the Integrated Windows Authentication login will work as per normal.
The same approach to logging in to the web app also applies to the mobile app. Users are prompted to log in and must enter their custom domain.
As of the v1.10.3 release of Skedulo, this also supports the IWA technique. However, this will require the user to enter their Windows domain user and password as the mobile device does not have access to these credentials.
When logging into the sandbox there will be a different custom domain to the production domain. You must ensure when logging in to either the web app or the mobile app you select the sandbox login before entering the custom domain.
If you don't do this it will fail the login with the following error:
invalid_grant: authentication failure
If you experience this issue, Log out and select the appropriate Salesforce or sandbox login for your custom domain.