Post on 19-Oct-2014
description
transcript
Taking a Pragmatic Look at the
Salesforce Security Model
Sridhar Palakurthy, salesforce.com, Technical Solution Architect
Vydianath Iyer, salesforce.com, Technical Solution Architect
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 l itigation, 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.
Agenda
Systems Level Security
Single Sign-ON
• Federated Authentication
– Demo
• Delegated Authentication
– Demo
API access using OAuth
Social Sign-On Authentication
Providers
Quiz - Q & A
Application Level Security
Profile
Permission Set
Role
Sharing
• Owner
• Role Hierarchy
• Org Wide Defaults
• Sharing Rules
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
Salesforce
2. Validate SAML and generate
session
SSO Basics: IDP Initiated SAML
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
Identity Provider 1
2
4
3
SSO Basics: SP Initiated SAML
Identity Provider
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
1 3
4 2 MyDomain: A sub-domain used
to access a specific Salesforce
Organization.
Example: https://sp-
developer.my.salesforce.com
5
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
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
Demo - Delegated Authentication in Play
Axiom (Identity Provider)
Hosts Salesforce.com WSDL
1. Download WSDL from Salesforce.com
2. Implement and Host WSDL
3. Test Login
ProvidesSalesforce.com WSDL
One Time Passwords / 2 Factor
Identity Provider
+ 2 Factor
1 2
3 4
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
2. The Authorization Server authenticates the user
3. The user authorizes the application
4. The application is issued an OAuth token.
OAuth Authorization Server
OAuth Client
2 4 3 1
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
3. The user access IDP and authenticates
4. IDP sends a SAML response
5. SAML Service provider processes the SAML assertion
and logs the user in.
6. The user authorizes the application
7. The application is issued an OAuth token.
SAML Service Provider and
OAuth Authorization Server
OAuth Client
2 7 5 1
SAML Identity
Provider
4 3
6
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
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
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
JanRain: Breadth & Depth support for a wide catalog of Identity Providers
http://www.janrain.com/salesforce
Application Security
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
Data Access Components
Record Access
Record Ownership
Role Hierarchy
Apex Sharing
Manual Sharing
Criteria- Based
Sharing Rules
Territory
Account and Sales
Teams
Default Org-Wide Access
Record Level Security
Data (Record) Visibility
Sharing Rules
Team Sharing
Role Hierarchy
OWD
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
Opening Up Record Access - Role Hierarchy
ONE ROLE PER USER
Manager has automatic access* to records owned by their subordinates
Dr. Evil
Scott Evil Mini Me Fat B
FRAU RITA NO. 2
JURGEN
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
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
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
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
3 BizPhone Wireless
FEDERAL
GROUP
Profiles
What Are Profiles ?
• 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 ?
Defines a user's permission to perform different functions within salesforce.com.
Permission Sets
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
Some Settings are in Profiles but Not in Permission
Sets (Yet)
Page Layouts
Record types
IP Ranges
Login Hours
Desktop
Client Access
App Permissions
Tab Settings
Assigned Apps
Object Permissions
Field Level Security
Apex Classes
VisualForce Pages
Profile Only:
Page layouts
Record types
Login IP ranges
Login hours
Desktop client access
PERMISSION SETS
PROFILES
Summary
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
Roles and Profiles
Account Id Name City State
001U000000B.. ABC Corp Spokane WA
001U000000V.. Acme Atlanta GA
001U000000X.. X Net San Francisco CA
001U000000Y.. Universal Air Dallas TX
Role controls Data (Record) Visibility
What records can John Sales see ?
Profile controls Object/Field permissions
What CRUD permissions does John have on objects and fields ?
Profile Can I access the
Account Object (Table) ?
Role Can I see the
ACME record ?
Profile Can I access the City Field
in the Account Object
John Sales
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
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
Sridhar Palakurthy
Technical Solution Architect
Vydianath Iyer
Technical Solution Architect