The Salesforce platform offers system as well as application level security capabilities for building robust and secure applications. Join us as we introduce the system-level security features of Salesforce, like authentication and authorization mechanisms that include various Single Sign-On and OAuth flows. We'll also cover declarative application-level security features, like user profiles, roles and permissions, and how an Organization Wide Security and record-sharing model enforces a finer level of access control over the data.
Unsubscribed: Combat Subscription Fatigue With a Membership Mentality by Head...
Introduction to the Salesforce Security Model
1. Introduction to the Salesforce
Security Model
Sridhar Palakurthy, Salesforce.com, Senior Technical Solution Architect
Vydianath Iyer, Salesforce.com, Senior 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 any
litigation, risks associated with completed and any 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-K for the most recent fiscal year and in our quarterly report on Form 10-Q for the most recent
fiscal quarter. These 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.
5. Agenda
Systems Level Security
▪ Authentication
• Single Sign-ON
▪ Authorization
• OAuth
Application Level Security
▪ Profile
▪ Permission Set
▪ Role
▪ Sharing
• Owner
▪ Social Sign-On
Q&A
• Role Hierarchy
• Org Wide Defaults
• Sharing Rules
6. Single Sign-On: Federated Authentication
SAML is The standard for Federated Single Sign-On
Identity Store is the master of ‘User’ identity.
Identity Provider (IdP) is the Identity Assertion Provider
Service Provider (SP) is the provider of enterprise services
Typical setup consists of One IdP and several SPs. Summer 13 supports multiple IdPs
Identity
Provider
1. Generate SAML and
send to salesforce.com
2. Validate SAML and
generate session
7. SSO Basics: IdP Initiated SAML
2
Identity
Provider
1
3
4
•
User authenticates at Customer IDP
•
User is directed to Salesforce (SP) using a link or button
•
When a link or button is pressed, IDP posts SAML to Salesforce
•
Salesforce validates SAML and a user session is generated
8. SSO Basics: SP Initiated SAML
Identity Provider
MyDomain: A sub-domain used
to access a specific Salesforce
Organization.
Example: https://sp-developer.my.
salesforce.com
• Request Resource.
• Redirect to IDP
• User accesses IDP and
sends SAML Request
• IDP Authenticates. Send
SAML Response
• Salesforce validates
SAML and generates
session
1
3
4
2
5
9. Demo - How to setup Federated Authentication
Axiom (Identity
Provider)
•
•
•
•
Configure Service Provider
Configure Identity Provider
Test Login
Examine SAML Token/Assertion
Service Provider
10. What is Delegated Authentication?
ProvidesSalesforce.
com WSDL
•
•
•
Download WSDL from Salesforce.com
Implement and Host WSDL
Test Login
Client Hosts
Salesforce.com
WSDL
11. One Time Passwords / 2 Factor Authentication
Identity Provider
+ 2 Factor
2
3
1
4
12. What is OAuth?
An open protocol to authorize secure API access for
desktop/mobile client applications
Integrates with previous authentication mechanisms
•
OAuth
Authorization
4
2
1Server 3
OAuth
Client
OAuth client makes a authorization request
•
The Authorization Server authenticates the user
•
The user authorizes the application
•
The application is issued an OAuth token.
13. When Do I Use What?
Userid/Password
▪ When you just want the basics
SAML
▪ Single Sign-On for the web applications with 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
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
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
▪ Salesforce: B2B
http://www.janrain.com/salesforce
17. Application Security
▪ Organization Wide Defaults – Record Visibility
▪ Role Herirarchy – Record Visibility by hierarchy
▪ Profiles & Permission Sets – What objects can I access ?
▪ Team Sharing
• Account Teams
• Sales Teams
▪ Sharing Rules
• Manual Sharing
• Criteria Based Sharing
• Apex Managed Sharing
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
1
Name
Industry
Cyber Inc. Federal
2
Universal
3
BizPhone
Airline
Wireless
FEDER
AL
GROU
P
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 ?
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 Layout Assignments
PERMISSION SETS
▪Login IP ranges
▪Login hours
▪Desktop client access
Page Layouts
IP Ranges
Login Hours
Desktop
Client Access
App Permissions
Record Types
Tab Settings
Assigned Apps
Object Permissions
Field Level Security
Apex Classes
VisualForce Pages
34. 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
35. Roles and Profiles
Role controls Data (Record) Visibility
What records can John Sales see ?
Profile
Profile controls Object/Field permissions
What CRUD permissions does John have on objects and fields ?
Can I access the
Account Object (Table)
?
Account Id
City
State
001U000000B..
John Sales
Name
ABC Corp
Spokane
WA
001U000000V..
Acme
Atlanta
GA
001U000000X..
X Net
San Francisco
CA
001U000000Y..
Universal Air
Dallas
TX
Profile
Role
Can I access the City Field
in the Account Object
Can I see the
ACME record
?
36. 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
37. 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