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