A Deep Dive into Salesforce Security: Authentication and Authorization Explained
Welcome to the start of a comprehensive exploration of Salesforce security, beginning with the foundational elements of authentication and authorization. This article is the first in a series that aims to unravel the web of Salesforce's security mechanisms.
The Basics: Authentication & Authorization
Authentication is the process of validating that an entity—whether it's a user in a browser or a machine accessing the system—truly is what it claims to be. Meanwhile, authorization determines what actions the authenticated entity is allowed to perform within Salesforce. Both are paramount to ensure that your Salesforce data remains secure and that only authorized users and entities can access it.
From Browsers to APIs: Understanding the Entry Points
For all incoming traffic, Salesforce ensures that all incoming traffic utilizes SSL and TLS for secure data transport. (We'll touch on these terms in detail in a future article.)
When visualizing how data enters Salesforce, envision two main pathways:
Directly via a browser by a user
Through an API client application, like a mobile app or another server
Both routes initiate their journey by communicating with the Salesforce Authentication Server.
Let's break these down further:
Browser-Based Access
For humans interacting with Salesforce through a browser:
Authentication additional layers of security: Multi-Factor Authentication (MFA), IP Ranges, and client-side certificates.
Identity Providers: Salesforce can act as the Identity Provider (IDP) to verify user authenticity. Once authenticated, Salesforce's server provides a session token to the respective client's ORG instance.
Third-party IDP: Instead of Salesforce, a third-party IDP, set up in an SSO relationship with Salesforce, can handle authentication. In this case, the IDP sends a SAML assertion to Salesforce, which then issues the session token once validated.
Following this, authorization mechanisms control access to pages and resources.
API Client Access
For machines trying to access Salesforce:
OAuth Flows: Machines can employ one of multiple OAuth flows to gain access, from the web server flow suited for external web servers to client credentials flow and many in between. Each has its unique sequence and purpose.
Session Establishment: Post-authentication, the Salesforce authentication server hands over a session token, granting the API client access to Salesforce's resources.
Authorization rules then come into play.
In Summary: How It All Fits Together
No matter the access point, either a browser or an API client, the process encompasses:
Transport-Level Security: Using TLS and potentially adding layers like IP whitelisting and client-side certificates for enhanced security.
Authentication: This step identifies the user or system. It's where elements like MFA or third-party IDPs come in.
Session Token Issuance: Once authenticated, the entity receives a session token, acting as a passport to Salesforce's resources.
Authorization: The final barrier. Even with a valid session token, this determines what resources the entity can access.
With this foundational knowledge, we're set to delve deeper into the nuances of Salesforce security in our upcoming articles. Stay tuned for an even more detailed examination of each component mentioned above.
Thank you for reading, and I hope you found this informative. Catch our next installment for more insights into Salesforce security.
Stay Tuned
Embark on your Salesforce Identity journey with confidence! For more insights and tips, stay tuned here on www.SteveTechArc.com and to the @SteveTechArc YouTube channel. Subscribe and enhance your understanding of Salesforce Identity.
Helping change the world by sharing integration info with fellow Architects and those on their Architect Journey!
STA 3.1