Single Sign-On Best Practices
9 likes11,189 views
The document discusses single sign-on best practices. It recommends developing troubleshooting practices for SSO failures, such as having a process to gather information and check login errors. It also suggests preventing failures by ensuring high availability of IDP servers, being proactive about certificate expirations, and testing implementations. Reliable and scalable SSO can be achieved using federation IDs instead of Salesforce usernames and disabling direct login to Salesforce when SSO is enabled.
Single Sign-On Best Practices
- 1. Single Sign-On Best Practices Developer Track Suchin Rengan Shesh Kondi Director, Technical Solutions Architect Cloud Solutions Architect @sacrengan @sheshzilla
- 2. 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 litigation, 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.
- 3. Why are we here? • To discuss • Different Mechanisms for Authentication • When to choose what protocol • Best practice for implementations • To help you understand • Single Sign-On Using SAML 2.0 • API access using OAuth • Authentication Providers • To demonstrate • The amazing things that can be built using our Authentication services
- 4. What is Single Sign On? Per wikipedia.. Single sign-on (SSO) is a property of access control of multiple related, but independent software systems. With this property a user logs in once and gains access to all systems without being prompted to log in again at each of them In simple terms.. Ability for systems to establish Authentication using a mutually agreed upon an identity mechanism
- 6. Username / Password Authentication • The out-of-the-box experience • Salesforce hosts the authentication interface • Flexible policies • Mobile ready ① User sends credentials to Salesforce ② Salesforce authenticates user in our database and user is granted session to Salesforce
- 7. What is SAML? • The Standard for Federated Single Sign-On • OASIS Standard: Commercial & Open Source support • Authentication interface is hosted by customer ① User requests a secure resource ② Salesforce.com redirects to Customer IDP ③ Customer authenticates user ④ User returns to Salesforce.com with SAML and is granted session * If you’re logged into the Dreamforce org, you’ve used SAML!
- 8. What is Delegated Authentication? • SOAP based protocol for “Single Login” • Salesforce only: Minimal commercial support • Salesforce hosts the authentication interface ① User sends credentials to Salesforce ② Salesforce sends credentials to Customer ③ Customer authenticates user and replies “true” ④ User is granted session to Salesforce
- 9. What is OAuth? • An open protocol to allow secure API access in a simple, standard method from desktop/web applications • Standard track in IETF • Integrates with previous authentication mechanisms ① App redirects user to Salesforce ② Salesforce authenticates user ③ Saleforce redirects user back to app with code ④ App sends code to Salesforce ⑤ Salesforce issues session ⑥ App accesses API
- 10. When do I use what? • UserId/Password • When you just want the basics • SAML • Single Sign-On for the web and applications • SAML provides the best commercial support • SAML provides re-use across other Cloud services • OAuth • Building an API client or connected application (including Mobile) • Delegated Auth • SF Mobile CRM and older API clients with your own credentials * Not mutually exclusive…you can mix and match
- 11. Customer Poll/ Question If you want to use your Active Directory credentials to use Salesforce for Outlook what mechanism would you use? A. Username / Password B. SAML C. OAuth D. Delegated Authentication
- 12. SSO in Action Shesh Kondi Suchin Rengan
- 13. How about using a Corporate Identity for Employees? Identity Provider (IDP) Service Provider (SP) MyDomain: A sub-domain used to access a specific SF Organization. Example: https://acme- 1. Generate SAML token and send 2. Validate SAML and generate developer.my.salesforce.com response to Salesforce session
- 14. Provisioning Users So, how we get the users in Salesforce?? Manually…. But that doesn’t cut for large organizations API… But that takes code and maintenance Just In Time Provisioning (SAML JIT)
- 15. What about Multiple Salesforce Orgs? Identity Provider (IDP) Service Provider (SP) Service Provider (SP)
- 16. …and an org can even be an IDP… Identity Provider (IDP) Service Provider (SP) Service Provider (SP)
- 17. How about bookmarks? 1. Request Resource. Redirect to IDP 2. Send SAML Request 3. Authenticate. Send SAML Response 4. Validate SAML. Generate session Identity Provider (IDP) Service Provider (SP) 4 2 3 1
- 18. How about Employees use Mobile? 1. User Posts Credentials 2. User get’s session
- 19. Salesforce as an IDP for a Third Party SP Identity Provider (IDP) Service Provider (SP) Service Provider (SP)
- 20. What about Single Sign-On for Partners? Identity Provider (IDP) Partner Portal 1. Generate SAML and send to 2. Validate SAML and generate Salesforce session Same as IDP Initiated SAML, but with 2 additional attributes Send these in attribute statement: organization_id & portal_id
- 21. What about the Consumers? Social Sign On Login using ‘Social’ Credentials Facebook and Janrain Authentication Providers Link Accounts Dyanamic Provisioning
- 22. How about using Social credentials for Salesforce access? 1. Authenticate and Link accounts 2. Allow Salesforce access
- 23. SSO Best Practices Suchin Rengan
- 24. Best Practices Develop troubleshooting practices for SSO failures SSO is in critical path since no login means no access to users Citi SSO SAML Issues Troubleshooting Process SAML SSO Issue is Reported Gather Information: - User Id - Error Message Check the Login Type “SAML Idp Initiated SSO” Any Login Error NO Is User Profile Make appropriate Message in User’s Configured with changes to User Login History? Proper Federation Id? Profile Error Messages like: - Failed: Issuer Mismatched - Failed: Certificate Mismathed YES YES NO Talk to Citi STS NO team and get SAML Setting Is SAML Token their help in Related Issue? (1) Valid? (2) resolution of the issue YES YES Make appropriate changes to SAML Settings If necessary open support ticket with SFDC Error Messages like: - Failed: Audience Mismatched - Failed: Recipient Mismatched - Failed: Certificate Mismatched Verify if it resolves the issue ADDITIONAL NOTES 1) For Certificate related issues, verify Certificate that is uploaded under SAML settings 2) A SAML Token can be validated using the SAML Token Debugger tool that is accessible on the SAML Settings Screen 3) Replay related issue is a temporary issue and happens if multiple SAML requests for the same user is made
- 25. SAML Best Practices – Prevent Failures • Make sure the IDP server is on a high available environment • Be proactive with regards to certificate (Salesforce and client) expirations • Check for any time skews that may lead to inconsistent timeout/ session creation issues • Implement custom logout, error pages to present custom messages instead of defaults • TEST and TEST and TEST
- 26. SAML Best Practices – Reliable & Scalable • Use Federation Id instead of SF username as subject Id • Identity based on login and no mapping required to know SF username • Login post is org specific and hence no time needed by SF to resolve org instance • Disabling users from directly logging into SF if SAML is enabled • Enable DA and implement a service that always return false • Use the “My Domains” feature and redirect the user when attempting to login directly. Also, disable flag that allows users to log into Salesforce.com directly Administrators should be excluded from SSO
- 27. Where do we go from here? Learn more on developer force: • http://wiki.developerforce.com/index.php/Single_Sign- On_for_Desktop_and_Mobile_Applications_using_SAML_and_OAuth • http://wiki.developerforce.com/index.php/CRC:SSO Attend these sessions: • Hands-on Training: Enable Single Sign-on with SAML Thursday, September 20th: 3:00 PM - 4:00 PM • Authentication with OAuth and Connected Apps Thursday, September 20th: 10:30 AM - 11:30 AM
- 28. Suchin Rengan Shesh Kondi @sacrengan @sheshzilla