Taking a Pragmatic Look at the Salesforce Security Model

1,859 views
1,566 views

Published on

0 Comments
3 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
1,859
On SlideShare
0
From Embeds
0
Number of Embeds
5
Actions
Shares
0
Downloads
154
Comments
0
Likes
3
Embeds 0
No embeds

No notes for slide

Taking a Pragmatic Look at the Salesforce Security Model

  1. 1. Taking a Pragmatic Look at theSalesforce Security ModelSridhar Palakurthy, salesforce.com, Technical Solution ArchitectVydianath Iyer, salesforce.com, Technical Solution Architect
  2. 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. 3. AgendaSystems Level Security Application Level Security  Single Sign-ON  Profile • Federated Authentication  Permission Set – Demo  Role • Delegated Authentication  Sharing – Demo • Owner  API access using OAuth • Role Hierarchy  Social Sign-On Authentication • Org Wide Defaults Providers • Sharing RulesQuiz - Q & A
  4. 4. 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 Provider1. Generate SAML and send to 2. Validate SAML and generateSalesforce session
  5. 5. SSO Basics: IDP Initiated SAML 2 3 Identity Provider 4 11. User authenticates at Customer IDP2. User is directed to Salesforce (SP) using a link or button3. When a link or button is pressed, IDP posts SAML to Salesforce4. Salesforce validates SAML and a user session is generated
  6. 6. SSO Basics: SP Initiated SAML 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 Identity Provider 3 1MyDomain: A sub-domain usedto access a specific Salesforce 4 2 Organization. 5 Example: https://sp- developer.my.salesforce.com
  7. 7. 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
  8. 8. What is Delegated Authentication? SOAP based protocol for “Single Login” Salesforce only: Minimal commercial support Salesforce hosts the authentication interface1. User sends credentials to Salesforce2. Salesforce sends credentials to Customer3. Customer authenticates user and replies “true”4. User is granted session to Salesforce
  9. 9. Demo - Delegated Authentication in Play Axiom (Identity Provider) ProvidesSalesforce.com WSDL Hosts Salesforce.com WSDL 1. Download WSDL from Salesforce.com 2. Implement and Host WSDL 3. Test Login
  10. 10. One Time Passwords / 2 Factor Identity Provider + 2 Factor 1 2 3 4
  11. 11. 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 OAuth Authorization Server 2. The Authorization Server authenticates the user 3. The user authorizes the application 1 2 3 4 4. The application is issued an OAuth token. OAuth Client
  12. 12. 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 IDPSAML Identity SAML Service Provider and 3. The user access IDP and authenticatesProvider OAuth Authorization Server 4. IDP sends a SAML response 5. SAML Service provider processes the SAML assertion 7 and logs the user in. 1 2 5 6 3 6. The user authorizes the application 4 7. The application is issued an OAuth token. OAuth Client
  13. 13. When Do I Use What?Userid/Password  When you just want the basicsSAML  Single Sign-On for the web applications  SAML provides the best commercial support  SAML provides re-use across other Cloud servicesDelegated Auth  Mobile CRM and older API clients with your own credentialsOAuth  Building an API client or mobile applicationNot mutually exclusive…you can mix and match
  14. 14. 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
  15. 15. 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 usersOut of the box support  Facebook: B2C http://www.janrain.com/salesforce  Salesforce: B2B  JanRain: Breadth & Depth support for a wide catalog of Identity Providers
  16. 16. Application Security
  17. 17. 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
  18. 18. Data Access Components Record Ownership Default Role Org-Wide Hierarchy Access Account and Sales Record Apex Access Sharing Teams Manual Territory Sharing Criteria- Based Sharing Rules
  19. 19. Record Level Security
  20. 20. Data (Record) Visibility Sharing Rules Team Sharing Role Hierarchy OWD
  21. 21. Locking Down Data (Record) AccessWhat 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
  22. 22. Opening Up Record Access - Role Hierarchy Dr. Evil Scott Evil Mini Me Fat B JURGEN RITA NO. 2 FRAU ONE ROLE PER USER Manager has automatic access* to records owned by their subordinates
  23. 23. Opening up access - Team Sharing Account Team – Team of users working together on an accountSales Team - Team of users working together on an opportunity Setting up an Account Team
  24. 24. 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
  25. 25. 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
  26. 26. Opening up Record AccessCriteria 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 FEDERAL GROUP 3 BizPhone Wireless
  27. 27. Profiles
  28. 28. What Are Profiles ?Defines a users permission to perform different functions within salesforce.com.• 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 ?
  29. 29. Permission Sets
  30. 30. What’s a Permission Set?A collection of CRUD permissions and settingsExtends user’s access without creating a new profileUser access controlled by Profile + Permission Sets
  31. 31. Some Settings are in Profiles but Not in Permission Sets (Yet) PROFILESProfile Only:  Page layouts PERMISSION SETS  Record types Page Layouts App Permissions  Login IP ranges Record types Tab Settings IP Ranges Assigned Apps  Login hours Login Hours Object Permissions Desktop Field Level Security  Desktop client access Client Access Apex Classes VisualForce Pages
  32. 32. Summary
  33. 33. Authentication and AuthorizationFederated Authentication • Uses SAML • IDP authenticates user and generates an XML “Assertion” • Identity Provider initiated • Service Provider initiatedDelegated Authentication • Custom web service which authenticates and returns a true/falseOAuth • Token based authorization for an authorized user • “Valet” key to applications • Typical use case - Mobile applications or desktop client applicationsSocial Sign-On Authentication Providers
  34. 34. Roles and Profiles Role controls Data (Record) Visibility Profile What records can John Sales see ? Can I access the Account Object (Table) ? Profile controls Object/Field permissions What CRUD permissions does John have on objects and fields ? Account Id Name City State 001U000000B.. ABC Corp Spokane WAJohn Sales 001U000000V.. Acme Atlanta GA 001U000000X.. X Net San Francisco CA 001U000000Y.. Universal Air Dallas TX Profile Role Can I access the City Field Can I see the in the Account Object ACME record ?
  35. 35. 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
  36. 36. 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
  37. 37. Sridhar Palakurthy Vydianath IyerTechnical Solution Architect Technical Solution Architect

×