Salesforce.com Identity Management

Prepared by

Keith Howling Platform Specialist salesforce.com

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 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, 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 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 quarterly report on Form 10-Q for the fiscal year ended October 31, 2009 and our other filings. These documents 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 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.

Content

  Overview of Authentication in salesforce.com   Salesforce.com Authentication options

•  Delegated Authentication •  Federation

  My Domain role in SSO   Oauth for client API access   Provisioning   Other Features

Where is authentication needed with Salesforce.com?

Browser Access

User navigates to standard Salesforce.com login page, enters Salesforce Username and password.

Mobile/Desktop Clients (SAML Support) Chatter Mobile / salesforce for Outlook (Summer’11) / Chatter desktop

Client opens browser to Salesforce.com ‘device’ specific login page (or idp page for SAML orgs), enters Salesforce Username and password, approve the request for the application to access you salesforce.com data

Mobile Client (non-SAML support)

Users asked for salesforce.com username and password, this is collected in the mobile client for activation, then a secret passcode is established for locking the UI.

How does OOTB Salesforce.com authentication work?

1.  Setup your password policy data

2.  Your Salesforce.com administrator creates a user –  Email is sent to new user –  with a URL to access for first time

3.  User Logs into Salesforce.com with a User ID and Password –  User ID must be globally unique. –  User sets a current password

4.  What happens when I forget my password? –  Your administrator can reset the

password. New one time use password is sent via email

Benefits of Single Sign-On   “After a one time authentication, identities can access any application

for which they are authorized without having to re-authenticate”

  Don’t want salesforce to manage passwords and password policies

  Login with your existing enterprise credentials

–  Don't want users to learn new credentials for salesforce.com

–  Re-use out of existing investments either : •  Directory Server technologies (AD) •  SSO Federation Technologies (Active Site Minder , Confederate)

–  Maintain control of existing security policies •  Userids / passwords / security tokens

–  User Experience / Adoption •  moving between applications / devices, without challenges for username/password.

Salesforce.com Authentication options

  (1) Delegated Authentication –  Primarily used to allow users to enter their existing windows password

into salesforce .com

–  Salesforce.com proprietary technology based on a webservice

–  Other user-cases •  2 Factor implementations

•  SSO with token base process

  (2) Federation –  Standards based SSO solution, salesforce.com strategic direction for

SSO with browser/desktop and mobile devices.

–  Requires a SAML Identity provider to manage authentication

–  Supports IDP Initiated and SP Initiated authentication (with myDomain).

Salesforce.com Authentication options

  (1) Delegated Authentication (enabled profile by profile)

  (2) Federation (Org-wide)

Open a case to enable this feature in your org

Delegated Authentication with Salesforce.com

1.  User logs in to Salesforce.com either online or via the API

2.  Salesforce checks the user’s profile and if delegated authentication is enabled, makes a web service request to the customer’s authentication service.

3.  The delegated authentication web service listens for requests and queries the authentication provider (e.g. LDAP directory) and returns a response either denying or allowing access.

4.  Based on the results, the user is granted or denied access.

NOTE: Username/password credentials are passed through Salesforce.com

Delegated Authentication with Salesforce.com

Browser Access

User navigates to standard Salesforce.com login page, enters Salesforce Username and password (password verified by DA).

Mobile/Desktop Clients (SAML Support)

Client opens browser to Salesforce.com ‘device’ login page, enters Salesforce Username and password (password verified by DA), approve the request for the application to access you salesforce.com data

Mobile Client

Users asked for salesforce.com username and AD password, this is collected in the mobile client for activation, then a secret passcode is established for locking the UI.

Token Delegated Authentication with Salesforce.com Single Sign-On Implemented on-top of Delegated Authentication

a)  User starts on a custom intranet SSO page that authenticates the user and then generates some sort of cryptographic token

b)  The token is auto-posted into salesforce.com login page as the password

c)  The Delegated Authentication service verifies the token

Token Generator

Authentication check

a

b

c

API Requires Other

Solution

Token Delegated Authentication with Salesforce.com

Browser Access

User logs onto windows, User navigates to customers Salesforce.com access page, and is taken to salesforce home page (or access denied page)

•  deep links / bookmarks do not work

Mobile/Desktop Clients (SAML Support)

Delegated Authentication Listener needs to be developed with a non-token based solution for clients. (or leverage part-SAML configuration to redirect to token generator)

Mobile Client

Delegated Authentication Listener needs to be developed with a non-token based solution for clients.

Federation

  Security Assertion Markup Language

  It’s a standard! –  Service Providers (SP) –  IDentity Providers (IDP) –  Salesforce supports 1.1 & 2.0

  Flexible –  Federation Id or username –  Identity Provider can access multiple user stores (AD/LDAP etc)

  Features –  No direct communication between IDP and salesforce.com –  Salesforce doesn’t see a password, just a signed SAML Assertion. –  Your IPD provides the login page (branding)

SAML flow (SP-initiated with myDomains)

1.  User requests a resource in their org, for example: https://customer.my.salesforce.com/001/o

2.  user does not have a session for that org, sends a SAML Authentication Request to the org’s Identity Provider. (including a parameter called “RelayState” - the URL requested “/001/o” )

6.  The Identity Provider logs the user in, and sends them back to Salesforce with a SAML Response and the RelayState

7.  Salesforce processes the SAML message, creates a session, and then redirects the user to the value of the RelayState parameter

(Request URLmydomain)

Federation with Salesforce.com

Browser Access

(idp-initiated) User Initiates access clinking a link to the IDP with parameters to access the salesforce.com service provider

(sp-initiated) User accesses salesforce.com (deeplink, bookmark), if not already authenticated, is redirected to the IDP login page, then back to requested salesforce (works best with mydomains)

. Mobile/Desktop Clients (SAML Support)

Specify the My Domain URL in the client configuration, and it will use the SAML process to authenticate the user instead of logging in directly to salesforce.

Client opens browser to Salesforce.com IDP specific login page, enters IDP username and password, approve the request for the application to access you salesforce.com data.

Mobile Client

Delegated Authentication needs to be developed with a non-token based solution for clients.

My Domain

•  The login URL for a company called Universal Containers would be: https://universalcontainers.my.salesforce.com/.

•  SSO benefits

•  Allows browser SP Initialed sign-on

•  Allows clients to leverage SAML SSO Configuration

Oauth2.0 – Authentication for API User can authorize applications to access Force.com resources (REST / SOAP Web Service) on their behalf without revealing their passwords to those applications.

•  Oauth2 common flows

•  Web Server - users can authorize your web application to access their data

•  User-Agent - users can authorize your desktop or mobile application to access their data, leveraging an external or embedded browser (or user-agent) for authentication (JavaScript running in the browser or native mobile or desktop apps)

•  SAML Assertion - your application can authenticate by presenting a SAML 2.0 assertion to Force.com, the OAuth 2.0 assertion access grant type.

Oauth2.0 – WebServer flow

1.  The webapp initiates the flow by redirecting the end-user's browser to the salesforce.com authorization endpoint

2.  salesforce.com authenticates the end-user and establishes whether the end-user grants or denies the client's access request.

3.  salesforce redirects the browser back to the webapp with an authorization code.

4.  webapp requests an access token from the authorization server by authenticating and including the authorization code received in the previous step as described.

Oauth clients (with SAML Support)

  Chatter Desktop

  Salesforce for Outlook (targeted Summer’11)

  Chatter Mobile

–  Delegated Auth •  Standard logon page, password as AD/LDAP

–  SAML without myDomain •  SAML for browser’s, DA for clients.

–  SAML with myDomains •  SAML for all.

Implementation options   Delegated Authentication

–  Buy it •  WebService middleware with Directory capability,

•  Products with commercial support for Delegated Authentication / AD integration etc.

–  Build it •  Many Java/.net samples on developer.force.com from implementing a delegated

authentication listener

  SAML –  Buy it

•  ADFS2,

•  Ping Federate (adapter for provisioning from AD)

•  Multiple Oracle IPD’s

–  Build it •  Open source SAML2,

–  OpenAM (formally opensso)

–  Others..

User Provisioning and de-provisioning

  JIT SAML provisioning –  You can use SAML to create users on the fly the first time they try to log in. This

eliminates the need to create user accounts in advance

  Salesforce.com exposes user/profile object through webservices API –  Create users / profiles / roles

–  Update users / profiles / roles (including de-activate user)

  Non-SAML auto-provisioning / de-provisioning of users requires a adapter from the IDP to salesforce.com to manage user details –  Ping has an adapter for AD

•  Intercepts the Assertion flow creates the user in salesforce before initiating the SSO

–  Use Java/.NET etc to develop an adapter

Other Features – Multi-Org Federation

  Salesforce.com SSO configuration now allow ‘Entity Id’ Service Provider value to be based on myDomain setting. –  Allows setup of multiple SP’s federated to the IDP, each SP

representing an Org with unique EntityId (myDomain) •  Each Org must implement MyDomains.

•  Setup users in each org with the same Federation ID.

  Users can now move between orgs without being challenged.

Other Features – API Federation (roadmap)

  A client application on a logged on windows machine can access the salesforce.com API without challenged for credentials –  Normal OAuth2 end-user flow

•  Open browser and have the user request a token against the server - salesforce.com

•  Browser based authentication and authorise the client application

  API Federation – (no challenges if logged into windows) –  Start client, requests access to salesforce.com API

–  Get the SAML token from claims translation (Kerberos).

–  Post SAML to a Oauth endpoint,

–  receive the token to use for API

Other Features – salesforce as a Identity provider

  Having established a salesforce.com session, we can generate SAML Assertion to 3rd party applications –  user-case

•  For talking to other clouds (directly to google apps – for mail)

•  Multi-org sign in & customised login page –  Attempt to access an org

»  companyaaa.my.salesforce.com/home/home.js

–  Its configured with SAML federation to another salesforce.com org

»  siteaaa.secure.force.com/dreamforce (salesforce.com idp with sites)

–  Salesforce site (sitting on a Salesforce portal) – acting as a registration application

»  Login as a portal use, to federate as a full user in the chatter org.

Portals and Sites

  Portals and Sites support –  DA

•  Works with portal profile users

•  For Token based, need to post login credentials to the portal login page

–  SAML •  Need portalId in the SAML Assertion

•  Idp-init only