Security Provider - Salesforce¶

The Salesforce security provider enables Salesforce authentication and authorization. It is fundamentally an OAuth 2.0 security provider, supporting the following grants:

• Authorization Code
• SAML 2.0 Bearer Assertion
• JWT Bearer Token

Configuration¶

See the OAuth security provider for configuration.

Note that Salesforce refers to the client identifer (client_id) and secret (client_secret) as the "consumer key" and "consumer secret."

Defaults¶

The Salesforce security provider defaults the following endpoints:

• Authorization Endpoint: https://login.salesforce.com/services/oauth2/authorize
• Token Endpoint: https://login.salesforce.com/services/oauth2/token

SAML 2.0 Bearer Assertion¶

When using the SAML 2.0 Bearer Assertion grant, the Salesforce provider will default the following properties:

• Issuer: Defaults to the client identifier (client_id).
• Audience: https://login.salesforce.com
• Recipient: https://login.salesforce.com/services/oauth2/token

JWT Bearer Token¶

When using the JWT Bearer Token grant, the Salesforce provider will default the following properties:

• Issuer: Defaults to the client identifier (client_id).

Known Issues and Limitations¶

Refresh Token Synchronization¶

Salesforce only maintains the previous 4 refresh tokens. Practically speaking, this means a different Connected App is required for each Vinyl instance. Otherwise, each Vinyl instance will retrieve a separate refresh token, possibly invalidating a refresh token used by another instance.

Multiple Salesforce Instances¶

It is possible to configure multiple Salesforce instances. Vinyl will maintain a separate set of security tokens for each instance. However, the user will have to log into each instance at least once. If the user has already logged into one instance, the user must sign out of that instance before logging into the second. Otherwise, Salesforce will skip the sign-in process. In other words, when the user attempts to log into the second instance, Salesforce may automatically log them into the first instance.

Prior Authorization¶

When using either the SAML Bearer Assertion or JWT Bearer Token grants, Salesforce requires a prior authorization. In practice, this means that users must authenticate once using the Authorization Code grant.

SAML Assertion Source¶

The Salesforce security provider cannot source SAML assertions from a SAML Single Sign-On (SSO) provider. There are two reasons for this:

1. Salesforce requires a prior authorization (see above). Forcing users to sign on with OAuth before authenticating with SAML SSO defeats the purpose.
2. Salesforce expects the SAML assertion's Issuer to match the Connected Client's Consumer Key. Consumer Keys are opaque blobs. Though some SAML SSO Identity Providers (IdPs) can be configured to generate a SAML assertion with an arbitrary Issuer, they may describes the Issuer as urn:oasis:names:tc:SAML:2.0:nameid-format:entity. That format describes a URI. Since the Consumer Key can't be parsed as a URI, Vinyl rejects the SAML assertion.