Plone Security is like an Onion

• How? It can make you cry
  
• Why? Security is hard
• We will cover lots of stuff here. Ask questions as we go.
• Don't expect to get it all at once. This stuff can be tricky.
• Let's peel the onion and try not to cry.

Basic Security Concepts

• The CIA - Confidentiality, Integrity, Availability
• The PTA - Physical, Technical, Administative
  
• The AAA- Authentication, Authorization, Accounting

Layers

• User - A person
• Group - A collection of Users
• Permission - Grant ability to perform an action on an object
• Role - A group of permissions

• Workflow - Modify Permission settings on an object. Binds the layers together, like duct tape, or the Force.

Zope Management Interface

• Security Tab - lots of permissions and roles.
• Don't change things here in a Plone site until you know what you are doing. Use a test site if possible first.
• Workflow can and will override security changes on content objects
  

Users

• Stored in the ZODB by default.
• Plone 2.5 with newer Zope uses more complex acl_users folder than before
• Authentication happens with username and password
• By default, both username and password are sent for every request in the clear (unencrypted)
• See SessionCrumbler and use SSL for initial login. See httpslogin, which ues SessionCrumbler.
• Default Users: admin (created during install)
  

Groups

• You can add a role to a group to give that role to all the group members site wide
• Generally you give groups Local Roles, not global site wide roles
  

• Default Groups: Members, Administrators

Permissions

• Most common permissions

• View - See the content
  
• Modify portal content - Edit the content
  
• Access contents information - Access properties and attributes
  
• List folder contents - See what is in a folderish content object

• Aquire permission settings - Acquisition for permissions. Be careful to pay attention to this setting, especially in workflow permission settings. ArchGenXML turns this off in it's generated workflows
  

Roles

• Manager - do anything you want and don't worry about permissions
  
• Owner - do what you want to objects you own
  
• Reviewer - edit, approve/publish content
  
• Member - Create content in your own folder
• Authenticated - Logged in but not a member (not used much to giver permissions)
  
• Anonymous - Mostly just view content, maybe comment on it (watch out for comment spam)
  

Workflow

• A workflow needs to have the permissions that it may effect defined on the Permissions tab

• Each state has a Permissions tab to define what the permissions should be set to

• Workflow will clear or set each permission, even if you set it manually in the ZMI

• Use the Update security settings button on the portal_workflow tool in the ZMI when you change workflow to update the permissions
  

Local Roles

• Give a user or group 'extra' roles in a certain part of your site
• Can disable inheritance of roles from parent objects (greyed out in the
  
• Use the sharing tab
• Add /sharing to the end of a URL
• Add /folder_localrole_form to the end of a URL

Proxy Roles

• Sometimes a script you write needs to do stuff that requires permissions that the user running the script doesn't have
  
• Proxy Roles allow a script be run with a specific role
• Is this safe? Only if you know exactly what the script is doing
• Example: A user sending an email, which requires access to the MailHost object
  

Other Stuff

• Modify the Add portal members permission at the root of the Plone site in the ZMI Security tab. This will keep Anonymous users from joining the site. Can also change security on the join_form.
• Restricted vs. unrestricted code
• Turn on Unauthorized in Event Log

Restricted vs. unrestricted code

• public - always accessible
• private - not accessible by restricted code or by calling the method via the URL (URL traversal)
• protected - the method is protected by a specific permission.

Turn on Unauthorized in Event Log

• To see the unauthorized messages (access denied) in the event_log
• Site Setup -> Error Log
• Remove Unauthorized from Ignored exception type
• Don't leave this on for a publicly accessable site or you could flood the logfile
  

VerboseSecurity Product:

• When access is denied it shows what roles you had and what roles you needed
• Plone 2.1 and before: Add on Product: VerboseSecurity
  
• Plone 2.5: Builtin. Enable in the zope.conf file's verbose-security section and restart Zope
  

Security in the code

    # set a method to be publically accessible - all TTW code can
    # call this directly
    security.declarePublic('publicMethod')
    def publicMethod(self):
      # ... (docstring and method body)

    # set a method to be private - no TTW code can call this directly
    security.declarePrivate('privateMethod')
    def privateMethod(self):
      # ... (docstring and method body)

    # set a method to be protected by a given permission.
    # Only users with this permission in the context can call
    security.declareProtecte(CMFCorePermissions.View, 'protectedMethod')
    def protectedMethod(self):
      # ... (docstring and method body)

Reference: General guides

• SuperGuide Zope Security: http://www.zopemag.com/Guides/SuperGuide_ZopeSecurity.html
• Understanding permissions and security: http://plone.org/documentation/tutorial/understanding-permissions/tutorial-all-pages

Reference: Python Code

• Security Model: http://plone.org/documentation/tutorial/manipulating-plone-objects-programmatically/security-model

• Manipulating permissions: http://plone.org/documentation/tutorial/manipulating-plone-objects-programmatically/security-and-permission
• Workflows: http://plone.org/documentation/tutorial/manipulating-plone-objects-programmatically/workflows

Reference: Zope Specific

• Users and Security: Very Zope-centric http://www.zope.org/Documentation/Books/ZopeBook/2_6Edition/Security.stx

The End

• It's just that simple ;o)

• My infrequently updated site: http://castlemurphy.com
• Email: skeeter at castlemurphy dot com