Force.com application security
•Download as PPTX, PDF•
0 likes•226 views
Making sense of Profiles, Permission Sets, Org-Wide Defaults, Roles, Role Hierarchy, Groups, and Sharing Rules for the Force.com platform
Recommended
Recommended
More Related Content
Recently uploaded
Recently uploaded (20)
Featured
Featured (20)
Force.com application security
- 1. Force.com Application Security Making sense of Profiles, Permission Sets, Org-Wide Defaults, Roles, Role Hierarchy, Groups, and Sharing Rules
- 2. Force.com Platform Fundamentals walks through all the security options Lots of options leads to lots of confusion! How do I secure my App? Profiles Permission Sets Org-Wide Defaults Roles Role Hierarchy Groups Sharing ?
- 3. Security Simplified – 2 Jobs 1. Secure Functions Objects/fields What can I do in the app for data I can see? Create, Read, Edit, Delete 2. Secure Data Records Which data can I see? All, mine, my group, etc. Mine Yours
- 4. Different Goals 1. Secure Functions What is my job role? Owner – Create, Read, Edit, Delete Need to know only – Read Everyone else – None 2. Secure Data Can I share this record? Confidential objects– Private Informational – Public Read Collaborative – Public Write Override through sharing rules Mine Yours
- 5. Different Tools 1. Secure Functions Secure with: 1. Secure Data Secure with: Profiles Permission Sets Org-Wide Defaults Roles Role Hierarchy Groups Sharing Mine Yours
- 6. What can I do in the App for the data that I can see? Job #1 - Secure Functions Create Read & Edit Delete “CRED”
- 7. What objects and fields should a user (by job role) be able to Create, Read, Edit, and Delete ? What’s your App CRED? Profiles Permission Sets
- 8. Recruiter, Hiring Manager, Interviewer, Everyone else Make a plan for each Job Role Permissions for Interviewers
- 9. Default On = on my tab bar by default Default Off = I can add to my tab bar Tab Hidden = I can’t get to records directly Won’t prevent access. Only CRED will. Can access records indirectly through links, chatter, related records Tab Settings Users can change defaults
- 10. Only one Profile per User Set at Org level If a Profile matches your app’s Job Role, use it! Secure Functions with Profiles
- 11. If you don’t have a matching Profile, create a Permission Set (as many as you want) Screens layout slightly different, but same settings Assign Permission Sets to Users Secure with Permission Sets Permission Sets
- 12. 3 models for securing records: Public Read/Write Public Read Only Private Go into Org-Wide Defaults and set objects to the most restrictive setting needed Job #2 – Secure Data Org-Wide Defaults Mine Yours
- 13. Each record has an Owner Person who created the record Can be reassigned Grant Access Using Hierarchies option Give access to Owner and up in Role Hierarchy… …but also need App CRED in a Profile or Permission Set What Your Boss Sees Org-Wide Defaults
- 14. Sharing Rules Roles Roles and Subordinates Public Groups Overriding the Org-Wide Defaults Sharing Either Read Only or Read/Write. Cannot take away access in a rule, only add access.
- 15. Role Hierarchy Looks like an org chart… …but doesn’t have to be You’re going to have lots of apps. Make this match the org chart! Think about how you’re going to maintain… Roles
- 16. Groups are any collection of: Other groups Roles Roles and subordinates Users When Job Roles ≠ SF Roles Groups
- 17. Manual sharing Create a sharing rule for the specific record When nothing fits… Sharing
- 18. Need to View or Modify all data Set this up in the Profile or Permission Set Data Administrators Profiles Permission Sets
- 19. Security needed Method used All users the same Public Read/Write or Public Read Only org-wide default Me & my boss Private + Grant Access Using Hierarchies org-wide default Me & my co-workers Private + share with role sharing rule Me & my peers Private + share with group sharing rule Ad hoc Private + manual sharing Data Administrator Profile or Permission set with View All or Modify All Common Use Cases Profiles Permission Sets Org-Wide Defaults RolesRole Hierarchy Groups Sharing
- 20. No user should own more than 10,000 records if using role hierarchy Changing owner removes manual sharing, can cause sharing rules to no longer apply Changing a user’s role can change who can access records Changing Role Hierarchy causes sharing to be recalculated and can take a while… do off-peak Change hierarchy from bottom up Keep it simple! Can you explain sharing for your app? Best Practices and Warnings
- 22. Design 1. Get Data Model (Objects and Fields) for App 2. Determine Job Roles 3. Go through Data Model for each Job Role 1. App and Tab visibility 2. Create, Read, Edit, Delete, View All, Modify All for each Custom Object 3. Read/Write, Read only, Hidden for each field 4. Record sharing requirements 4. Get info on org Profiles, Roles, and Role Hierarchy Cookbook to Secure an App
- 23. Implementation 1. Secure Functions 1. If Profile matches Job Role, set up security on Profile 2. Else create Permission Set for each Job Role 1. App access, tab visibility, object CREDVaMa, field HRW 2. Secure Data 1. Setup View All / Modify All for admins on Profile or Permission Set 2. Set Org-Wide Default to Private/Read/Read-Write, Hierarchy 3. For each Job Role, create needed Sharing Rules (see Common Use Cases for examples) 1. Create Groups as needed 2. Split existing Roles as needed 4. Train on manual sharing as needed Cookbook to Secure an App
- 24. Object Name Tab Settings CREDVaMa Fields (HRW) Object 1 On/Off/ Hidden Create/Read/Edit/ Delete/View All/ Modify All Hide/Read/ Write by field Object 2 … Access needed for Job Role
- 25. Object Name Who creates? Who else needs to see? Object 1 Job role Role/Role and subordinates/Group/User Object 2 … Sharing
Editor's Notes
- http://www.salesforce.com/us/developer/docs/fundamentals/index.htm
- Create access is like having a bunch of blank forms. Not everyone gets the blank forms. Read & Edit – picture this as a pane of glass that will go over the top of the form. Blue paint is going to block the fields you don’t have access to. Clear glass is like having read access. For edit, we have a hole in the glass and a pencil. Delete access is being given the key to remove the glass, take out the paper form, and throw it away. In securing functions, we have only defined the rules of what data I can create, read, edit, and delete. Do I have a pad of forms, what does my pane of glass look like, and do I get a garbage can? Just because I have these things doesn’t mean I get to look at all completed forms. But when I do get a hold of a record, my “CRED” will dictate what I can do with that record.
- This picture is a Data Model of a simple app. You can see your Data Model by going to Setup > Build > Schema Builder, and then selecting all of your objects. Each box is an object, each row in the box is a field. You will secure each object using CRED. In this example, I want Interviewers to be able to read Positions, Job Applications, Candidates; edit Reviews; and not see anything else. You can also override field level security, for example, to hide sensitive data such as social security numbers, and min and max pay.
- http://www.salesforce.com/us/developer/docs/fundamentals/Content/adg_securing_permset_interview_try_it.htmYou need to figure out your job roles, then ask what access to objects and fields should each job role will require.
- Don’t try to use “Tab Hidden” for security. Only CRED will keep someone out. Tab Hidden just changes how to access, not ability to access.
- Setup > Manager Users > ProfilesThis page shows the settings you will need to set for each job role that has a matching Profile.Best practice: limit the number of profiles. Should be big groups of users, not so many you can’t understand them, less than the number of boxes on an org chart, combine where possible. Rule of thumb: if there is a reorg or a new group using the app, you can create new profiles, otherwise if you don’t have a matching profile, use a permission set instead.
- Setup > Manager Users > Permission SetsWhen creating a Permission Set, use the Description field to remind yourself why. You may not remember later once you have many apps!To assign a Permission Set to a user, go to Setup > Manage Users > Users. Click User then Edit Assignments
- Setup > Security Controls > Sharing SettingsIf one person can’t read it, have to use Private. For most data, you will need to use Private.Public Read/Write – Idea generation, collaborationPublic Read Only – Job postingsPrivate – Reviews
- Role hierarchy – gives access to record. CRED ability is based on profile/permission set.If Role Hierarchy doesn’t need access to your object, turn this off! Drives significant overhead (when doing maintenance on Users and Roles) if you have lots of users or records. For more details, see: http://www.salesforce.com/docs/en/cce/record_access_uth/salesforce_record_access_under_the_hood.pdfhttp://www.salesforce.com/docs/en/cce/draes/draes.pdf - Designing Record Access for Enterprise Scale
- Setup > Security Controls > Sharing SettingsSet up Org-Wide Default as Private or Public Read Only, and then override through sharing rules. If you set up as Public Read Write, you cannot take away access through a sharing rule. That’s why they are called “sharing rules” not “access rules”. You can only share more, not take away access. You have lots of choices on how to pick people to share with. Try to get the job done with the least number of rules to reduce overhead.(Will show typical UseCases in a few slides)
- Setup > Security Controls > Sharing SettingsNo user should own more than 10,000 records if using role hierarchy in Org-Wide Defaults. Will cause problems when that person changes jobs or roles.
- When you don’t have a Salesforce Role in the Role Hierarchy to match your Job Role, and you have an easy way to identify the users, create a group. A group also makes sense when you need to share with multiple roles so you only need to maintain one sharing rule.
- Groups like “interviewers” may change constantly. You don’t want to get daily emails to add and remove people from a group. Let people assign access as needed with the Sharing button.Note:Changing your sharing model (for example, by changing the record owner)deletes any manual shares
- This is the only way sharing is done through Profiles and Permission Sets. Outside of data admins, Profiles and Permission Sets just give you CRED abilities.
- If a user owns 10,000+ records:• Turn off hierarchies for that object if not needed• Place user in a separate role at the top of the hierarchy if possible• Not move them out of that top-level role• Keep them out of public groups that could be used as the source for sharing rules
- Please provide feedback on use of these Job Aids!
- Meet separately with each Job Role and fill out this worksheet (one sheet per role)
- After access for all Job Roles is determined, meet with all Job Roles and confirm CRED abilities as a group. Then fill in this worksheet with sharing rules for each Object. Keep in mind Public Read-Write and Public Read Only are options.