Académique Documents
Professionnel Documents
Culture Documents
com
Identity Management
Prepared by
Safe Harbor
Safe 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
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.
(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).
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.
a) User starts on a custom intranet SSO page that authenticates the user and then generates some sort of cryptographic token
API 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
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)
(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
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 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.
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..
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
SAML
Need portalId in the SAML Assertion Idp-init only