1. Taking a Pragmatic Look at the
Salesforce Security Model
Sridhar Palakurthy, salesforce.com, Technical Solution Architect
Vydianath Iyer, salesforce.com, Technical Solution Architect

2. Safe Harbor
Safe harbor statement under the Private Securities Litigation Reform Act of 1995:
This presentation may contain forward-looking statements that involve risks, uncertainties, and assumptions. If any such uncertainties materialize or if
any of the assumptions proves incorrect, the results of salesforce.com, inc. could differ materially from the results expressed or implied by the forward-
looking statements we make. All statements other than statements of historical fact could be deemed forward-looking, including any projections of
product or service availability, subscriber growth, earnings, revenues, or other financial items and any statements regarding strategies or plans of
management for future operations, statements of belief, any statements concerning new, planned, or upgraded services or technology developments
and customer contracts or use of our services.
The risks and uncertainties referred to above include – but are not limited to – risks associated with developing and delivering new functionality for our
service, new products and services, our new business model, our past operating losses, possible fluctuations in our operating results and rate of growth,
interruptions or delays in our Web hosting, breach of our security measures, the outcome of intellectual property and other litigation, risks associated
with possible mergers and acquisitions, the immature market in which we operate, our relatively limited operating history, our ability to expand, retain,
and motivate our employees and manage our growth, new releases of our service and successful customer deployment, our limited history reselling
non-salesforce.com products, and utilization and selling to larger enterprise customers. Further information on potential factors that could affect the
financial results of salesforce.com, inc. is included in our annual report on Form 10-Q for the most recent fiscal quarter ended July 31, 2012. This
documents and others containing important disclosures are available on the SEC Filings section of the Investor Information section of our Web site.
Any unreleased services or features referenced in this or other presentations, press releases or public statements are not currently available and may
not be delivered on time or at all. Customers who purchase our services should make the purchase decisions based upon features that are currently
available. Salesforce.com, inc. assumes no obligation and does not intend to update these forward-looking statements.

3. Agenda
Systems Level Security Application Level Security
 Single Sign-ON  Profile
• Federated Authentication  Permission Set
– Demo  Role
• Delegated Authentication
 Sharing
– Demo
• Owner
 API access using OAuth • Role Hierarchy
 Social Sign-On Authentication • Org Wide Defaults
Providers • Sharing Rules
Quiz - Q & A

4. Single Sign-On: Federated Authentication
SAML is The standard for Federated Single Sign-On
Identity Provider (IDP) is the master of User data
Service Provider (SP) is the provider of enterprise services
Typical setup consists of One IDP and several SPs.
Identity Provider
1. Generate SAML and send to 2. Validate SAML and generate
Salesforce session

5. SSO Basics: IDP Initiated SAML
2 3
Identity Provider
4
1
1. User authenticates at Customer IDP
2. User is directed to Salesforce (SP) using a link or button
3. When a link or button is pressed, IDP posts SAML to Salesforce
4. Salesforce validates SAML and a user session is generated

6. SSO Basics: SP Initiated SAML
1. Request Resource.
2. Redirect to IDP
3. User accesses IDP and sends SAML
Request
4. IDP Authenticates. Send SAML
Response
5. Salesforce validates SAML and
generates session
Identity Provider
3 1
MyDomain: A sub-domain used
to access a specific Salesforce 4 2
Organization. 5
Example: https://sp-
developer.my.salesforce.com

7. Demo - How to setup Federated Authentication
Axiom (Identity Provider) Service Provider
1. Configure Service Provider
2. Configure Identity Provider
3. Test Login
4. Examine SAML Token/Assertion

8. What is Delegated Authentication?
SOAP based protocol for “Single Login”
Salesforce only: Minimal commercial support
Salesforce hosts the authentication interface
1. User sends credentials to Salesforce
2. Salesforce sends credentials to Customer
3. Customer authenticates user and replies “true”
4. User is granted session to Salesforce

9. Demo - Delegated Authentication in Play
Axiom (Identity Provider)
ProvidesSalesforce.com WSDL Hosts Salesforce.com WSDL
1. Download WSDL from Salesforce.com
2. Implement and Host WSDL
3. Test Login

10. One Time Passwords / 2 Factor
Identity Provider
+ 2 Factor
1
2
3 4

11. What is OAuth?
An open protocol to authorize secure API access for
desktop/client applications
Integrates with previous authentication mechanisms
1. OAuth client makes a authorization request
OAuth Authorization Server 2. The Authorization Server authenticates the user
3. The user authorizes the application
1 2 3 4
4. The application is issued an OAuth token.
OAuth Client

12. Combining SAML and OAuth
You can combine SAML based Single Sign-on for OAuth enabled
desktop and mobile applications
1. OAuth client makes a authorization request
2. The Authorization Server redirects the user to SAML
IDP
SAML Identity SAML Service Provider and 3. The user access IDP and authenticates
Provider OAuth Authorization Server 4. IDP sends a SAML response
5. SAML Service provider processes the SAML assertion
7
and logs the user in.
1 2 5 6
3 6. The user authorizes the application
4
7. The application is issued an OAuth token.
OAuth Client

13. When Do I Use What?
Userid/Password
 When you just want the basics
SAML
 Single Sign-On for the web applications
 SAML provides the best commercial support
 SAML provides re-use across other Cloud services
Delegated Auth
 Mobile CRM and older API clients with your own credentials
OAuth
 Building an API client or mobile application
Not mutually exclusive…you can mix and match

14. Social Sign-On
 Automatically create and update users and contacts
 Single Sign-On makes it easy and keeps them coming back
 Deliver applications and services to deepen your relationship
 Active engagement automatically updates your customer data

15. So what’s under the covers?
The Auth Providers Framework
 Pre-integrated Single Sign-On from branded Identity Services
 Automatically create and update Contacts and Users
 Full control post authentication data processing
 Works for both internal and external users
Out of the box support
 Facebook: B2C http://www.janrain.com/salesforce
 Salesforce: B2B
 JanRain: Breadth & Depth support for a wide catalog of Identity Providers

16. Application Security

17. Application Security
o Organization Wide Defaults – Record Visibility
o Role Herirarchy – Record Visibility by hierarchy
o Profiles – What objects can I access ?
o Permission sets
o Team Sharing
 Account Teams
 Sales Teams
o Sharing Rules
 Manual Sharing
 Criteria Based Sharing

18. Data Access Components
Record
Ownership
Default
Role
Org-Wide
Hierarchy
Access
Account
and Sales
Record Apex
Access Sharing
Teams
Manual
Territory
Sharing
Criteria-
Based
Sharing
Rules

19. Record Level Security

20. Data (Record) Visibility
Sharing Rules
Team Sharing
Role Hierarchy
OWD

21. Locking Down Data (Record) Access
What are your Organization Wide Defaults ?
 Baseline level access that all users have for each other’s data
 Feature to restrict access (visibility) to records of data
Private implies
only record
owner and roles
higher can see
the record

22. Opening Up Record Access - Role Hierarchy
Dr. Evil
Scott Evil Mini Me Fat B
JURGEN
RITA NO. 2 FRAU
ONE ROLE PER USER
Manager has automatic access* to records owned by their subordinates

23. Opening up access - Team Sharing
Account Team – Team of users working together on an account
Sales Team - Team of users working together on an opportunity
Setting up an
Account Team

24. Opening Up Record Access − Sharing Rules
Extends access beyond
baseline level
Share records owned by a
role/group with another
roles or groups
Applied in real time when a
record is created or
ownership is transferred

25. Opening Up Record Access - Manual Sharing
• A user with owner-like access to a
record (the owner, his managers, and
administrators have owner-like access)
can share it with another user, group,
role or role and all subordinate roles
• In the case of manual account sharing,
access to child opportunities and cases
can be granted, too

26. Opening up Record Access
Criteria Based Sharing Rules
• Criteria Based Sharing rules open up access to sets of users, groups,
roles based on the field values in the data record
ID Name Industry
1 Cyber Inc. Federal
2 Universal Airline
FEDERAL
GROUP
3 BizPhone Wireless

27. Profiles

28. What Are Profiles ?
Defines a user's permission to perform different functions within salesforce.com.
• What objects (accounts, leads, contacts etc.) can I access ?
• What page layouts can I see ?
• What fields can I access ?
• Which tabs can I view ?
• Which record types can I see ?
• Which Apex Classes are accessible for me ?
• Which Visualforce Pages can I access ?

29. Permission Sets

30. What’s a Permission Set?
A collection of CRUD permissions and settings
Extends user’s access without creating a new profile
User access controlled by Profile + Permission Sets

31. Some Settings are in Profiles but Not in Permission
Sets (Yet)
PROFILES
Profile Only:
 Page layouts PERMISSION SETS
 Record types
Page Layouts App Permissions
 Login IP ranges Record types Tab Settings
IP Ranges Assigned Apps
 Login hours Login Hours Object Permissions
Desktop Field Level Security
 Desktop client access Client Access Apex Classes
VisualForce Pages

32. Summary

33. Authentication and Authorization
Federated Authentication
• Uses SAML
• IDP authenticates user and generates an XML “Assertion”
• Identity Provider initiated
• Service Provider initiated
Delegated Authentication
• Custom web service which authenticates and returns a true/false
OAuth
• Token based authorization for an authorized user
• “Valet” key to applications
• Typical use case - Mobile applications or desktop client applications
Social Sign-On Authentication Providers

34. Roles and Profiles
Role controls Data (Record) Visibility
Profile
What records can John Sales see ?
Can I access the
Account Object (Table) ?
Profile controls Object/Field permissions
What CRUD permissions does John have on objects and fields ?
Account Id Name City State
001U000000B.. ABC Corp Spokane WA
John Sales
001U000000V.. Acme Atlanta GA
001U000000X.. X Net San Francisco CA
001U000000Y.. Universal Air Dallas TX
Profile Role
Can I access the City Field Can I see the
in the Account Object ACME record ?

35. Quiz
Q: A company wants to restrict access to opportunities by owner but open up access to his/her
management hierarchy
A. Set the organization wide default for opportunities to private
Q: John is a chatter only user and needs read access to a custom object , a visual force page
and an apex class
A. Create a permission set to provide access to the visual force page and apex class
and assign John to the permission set
Q. Can federated authentication in Salesforce co-exist with delegated authentication?
A. Yes
Q. Does user need to authenticate during OAuth handshake between a client application and
Salesforce?
A. Yes

36. Links & References
 Salesforce.com Security Guide
• http://www.salesforce.com/us/developer/docs/securityImplGuide/index.htm
 Axiom SSO Play Area
• https://axiomsso.herokuapp.com/Home.action
 JanRain Social Sign-On Providers
• http://www.janrain.com/salesforce

37. Sridhar Palakurthy Vydianath Iyer
Technical Solution Architect Technical Solution Architect