• 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.

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

• 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.

• 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
  

• 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)
  

• 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

• 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
  

• 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)
  

• 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
  

• 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

• 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
  

• 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

• 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.

• 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
  

• 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
  

    # 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)

• 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

• 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

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

• It's just that simple ;o)

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