Single Sign-on contains objects named applications. The applications can be service applications or identity provider applications. The service applications contain all of the required artifacts to create a trusted, two-way connection to external services. A service is an application, service, or resource that you want to provide a single sign-on experience for your users. The applications contain certificates, metadata, appmarks, connectors, and any additional information required for the trusted, two-way connection. The trusted, two-way connection is a federated connection. A federated connection establishes a trust between Single Sign-on and a service to create a single sign-on experience for the users. You configure both Single Sign-on and the service to create the federated connection.
Each service that you want to provide a single sign-on experience for is different and has different requirements for single sign-on. The standardized authentication protocols like SAML and OAuth give all developers a structure to use but it is not a template. The resulting services have differences.
To create a single sign-on experience you take information from Single Sign-on and add it to the service and you take information from the service and add it to Single Sign-on. After you complete this configuration the two services trust each other to allow the user to have a single sign-on experience. The configuration for the trust is different for each protocol.
The fields can be different for each service with the same protocol because they are developed by different people. For example, when creating an OAuth connection, you must share the client ID and client secret to create a secure connection. The field names for these items in Single Sign-on are Client ID and Client Secret, however, the field names for these same items in Salesforce are Consumer Key and Consumer Secret.
You must gather the required items to create an application that contains the required information for a federated connection. You must gather or know the following information:
Single Sign-on enabled service: The service that you want to create a single sign-on experience for your users must be enabled for single sign-on.
An administrative account in the service: You must have an account with administrative privileges in the service to be able to configure a single sign-on connection.
An administrative account in Single Sign-on: You must have an account with administrative privileges in Single Sign-on to be able to configure a single sign-on connection.
Protocol of the service: You must know which protocol (such as SAML or OAuth) the service uses to be able to know how to properly configure the single sign-on trusted connection. Each protocol requires different information to create a trusted connection. The required items for each protocol are documented in the section that describes that protocol.
User accounts: You must have the accounts for the users in the Advanced Authentication repository to provide a single sign-on experience. The external service might require that the user accounts exist in their system as well. Each service has different requirements.
Single Sign-on provides applications for frequently used external services. Each application for the service contains federation instructions that are unique for the service. Single Sign-on also allows you to create a custom application for an external service that we do not provide in the administration console.