Find an Answer
The Identity Provider tab lets you configure your Identity Provider (IdP) relationship to establish Single Sign-On for your organization users. The IdP can be a service such as Active Directory Federation Services (ADFS 2.0 | ADFS 3.0); a third-party provider such as OneLogin, Okta, Azure AD, etc.; or another SAML-based IdP solution.
Back to Organization Center Contents
Once configured, your users can log in either from the Identity Provider’s website or from your GoTo product’s website using the Use my company ID link in the log-in form.
When you set up an Identity Provider, you are establishing the landing point for authentication requests, the trusted certificate that is used by the Identity Provider to encrypt authentication calls, the IdP’s formal Entity ID, and optionally, a landing page for logouts.
Set up either an Automatic or Manual configuration. You cannot do both. If you save one after the other, the last save is accepted.
The easiest and most robust way to configure SSO is to use a link to your Identity Provider's metadata file if they provide one. The metadata contains additional information that the IdP can use to make the transaction more secure. In addition, since the metadata file is generated, the method is less prone to typographical errors.
1. Log into the Organization Center.
2. In the Identity Provider tab, choose Automatic.
3. Enter the Metadata URL for your Identity Provider.
4. Click Save. The metadata file is uploaded and configures the relationships correctly.
Not all IdPs support a metadata implementation. To set up a manually configured IdP relationship, you enter key data that will get built into the SAML assertions.
SAML bindings embeds SAML messages within the underlying transport protocols. The bindings offered using the GoTo identity protocols are:
HTTP Redirect binding - enables SAML messages to be transported using HTTP redirect messages (302 status code responses). The Redirect binding contains a SAMLRequest or SAMLResponse query string parameter. Before sending, the message is deflated (sans header and checksum), base64-encoded, and URL-encoded, in that order. The process is reversed on receipt to recover the message.
HTTP POST binding - sends SAML messages in a base64-encoded XHTML form. The service provider initially responds to a request from the user agent with a document containing an XHTML form. The SSO service at the identity provider validates the request and responds with a document containing another XHTML form. Form submission can be automated.
Use the HTTP Redirect binding for short messages such as <samlp:AuthnRequest>. Longer messages such as those containing signed SAML assertions should be transmitted via the HTTP POST binding.
The service provider may use HTTP Redirect to send a request while the identity provider uses HTTP POST to transmit the response.
1. Log into the Organization Center.
2. In the Identity Provider tab, choose Manual.
3. Enter the data provided by your Identity Provider:
- Sign-in page URL - The IdP’s landing page for authentication requests.
- Sign-in binding - Choose Redirect or POST.
- Sign-out page URL – Optional: This is the URL where the user is redirected upon log-out.
- Sign-out binding - Choose Redirect or POST.
- Identity Provider Entity ID – Location of the globally unique name for your IdP as a SAML entity.
- Verification certificate – The IdP’s public certificate used to verify incoming responses from the IdP.
For the verification certificate, you can copy-and-paste the certificate contents as text into the entry form, or choose Upload certificate to import the certificate from a disk location. Both options result in the certificate being pulled into the page and displayed as shown.
4. Click Save. The configuration is stored in the GoTo account service.