force.com application security
Post on 24-Dec-2014
60 Views
Preview:
DESCRIPTION
TRANSCRIPT
Force.com Application Security
Making sense of Profiles, Permission Sets, Org-Wide Defaults, Roles, Role Hierarchy,
Groups, and Sharing Rules
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 Hierarch
y
Groups
Sharing
?
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
Different Goals
1. Secure Functions
What is my job role?Owner – Create, Read, Edit, Delete
Need to know only – ReadEveryone else – None
2. Secure Data
Can I share this record?
Confidential objects– PrivateInformational – Public ReadCollaborative – Public Write
Override through sharing rules
Mine Yours
Different Tools
1. Secure Functions
Secure with:
1. Secure Data
Secure with:
Profiles
Permission Sets
Org-Wide Defaults
Roles Role Hierarch
y
Groups
Sharing
Mine Yours
What can I do in the App for the data that I can see?
Job #1 - Secure Functions
Create Read & Edit
Delete
“CRED”
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
Recruiter, Hiring Manager, Interviewer, Everyone else
Make a plan for each Job Role
Permissions for Interviewers
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
Only one Profile per User Set at Org level If a Profile matches your app’s Job Role, use
it!
Secure Functions with Profiles
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
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
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
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.
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
Groups are any collection of: Other groups Roles Roles and subordinates Users
When Job Roles ≠ SF Roles
Groups
Manual sharing Create a sharing
rule for the specific record
When nothing fits…
Sharing
Need to View or Modify all data Set this up in the Profile or Permission Set
Data Administrators
Profiles
Permission Sets
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 Hierarch
y
Groups
Sharing
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
Appendix: Job Aids
Design1. Get Data Model (Objects and Fields) for App2. Determine Job Roles3. Go through Data Model for each Job Role
1. App and Tab visibility2. Create, Read, Edit, Delete, View All, Modify All
for each Custom Object3. Read/Write, Read only, Hidden for each field4. Record sharing requirements
4. Get info on org Profiles, Roles, and Role Hierarchy
Cookbook to Secure an App
Implementation1. Secure Functions
1. If Profile matches Job Role, set up security on Profile2. Else create Permission Set for each Job Role
1. App access, tab visibility, object CREDVaMa, field HRW
2. Secure Data1. Setup View All / Modify All for admins on Profile or
Permission Set2. Set Org-Wide Default to Private/Read/Read-Write, Hierarchy3. For each Job Role, create needed Sharing Rules
(see Common Use Cases for examples)1. Create Groups as needed2. Split existing Roles as needed
4. Train on manual sharing as needed
Cookbook to Secure an App
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
Object Name
Who creates?
Who else needs to see?
Object 1 Job role Role/Role and subordinates/Group/User
Object 2
…
Sharing
top related