sso presentation

Upload: dashboardj

Post on 10-Jul-2015

153 views

Category:

Documents


0 download

TRANSCRIPT

Salesforce.comIdentity Management

Prepared by

Keith Howling Platform Specialist salesforce.com

Safe HarborSafe harbor statement under the Private Securities Litigation Reform Act of 1995: This presentation may contain forwardlooking 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 (Summer11) / 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 Dont 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)

Open a case to enable this feature in your org

(2) Federation (Org-wide)

Delegated Authentication with Salesforce.com1. User logs in to Salesforce.com either online or via the API 2. Salesforce checks the users profile and if delegated authentication is enabled, makes a web service request to the customers 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.comBrowser 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.comSingle Sign-On Implemented on-top of Delegated Authentication

b

Authentication check Token Generator a

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

b) The token is auto-posted into salesforce.com login page as the password c) The Delegated Authentication service verifies the token

c

Token Delegated Authentication with Salesforce.comBrowser 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 Its 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 doesnt 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

(Request URLmydomain)

2. user does not have a session for that org, sends a SAML Authentication Request to the orgs 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

Federation with Salesforce.comBrowser 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 nontoken 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 APIUser 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 useragent) 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 flow1. 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 Summer11) Chatter Mobile Delegated Auth Standard logon page, password as AD/LDAP

SAML without myDomain SAML for browsers, 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 IPDs

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 SPs 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