• Background
• Goal
• Categories
  • Standard backend administration
    • Public engagement
    • Self-service

Background

• Afform provides a portable form system intended for use in core CiviCRM screens.
• CiviCRM includes a standard security model (involving roles, ACLs, entities, hooks, etc). This model is supported by the standard UI and by the API.
• Forms may relate to the standard security model in different ways. In many cases, a form simply abides by the standard model; in others, a form provides a targetted escalation.

Goal

The aim of this page is to collect the long-tail of use-cases for the security functionality. This can be used for (a) vetting suitability of design changes and (b) eventually informing E2E test.

Categories

A key variable in describing the security of a form is how it relates to the standard security model -- backend administration forms almost always conform to the standard/baseline security model; public engagement forms almost always require an escalation/exception from the standard model; and self-service forms are in tension (ie sometimes requiring conformance, and sometimes requiring escalation).

Note that this document generally gives more detail/consideration to the latter cases. This is not because they are more or less important - rather, their deviation from the baseline model means that they require greater attention to detail.

Standard backend administration

Description: Suppose one has developed some entity/entities and defined a standard permission model. You wish to quickly create a configuration screen with which a backend user may manage these entities.

Example: "OAuth Admin": oauth-client introduces the OAuthProvider, OAuthClient, and OAuthSysToken with a basic CRUD UI and some permissions (e.g. manage OAuth client vs manage OAuth client secrets)

Note: Minimum access/Privilege escalation: The permissions to view the form is integrally tied to the standard permissions. For example, there's no point attempting to render the "OAuth Admin" screen if the user lacks permission to the underlying data (manage OAuth client).

Public engagement

Description: Allow a new, unauthenticated person to fill out some information.

Examples:

• Newsletter signup: Provide name and email. Add email to a mailing list.
• New donation: Provide name, email, and payment information. Process payment and record contribution.
• Event registration (free): Choose an event. Provide name and email. Register for the event.
• Event registration (paid): Choose an event. Provide name, email, and payment information. Register for the event.
• New membership: Choose a membership type. Provide name, email, payment, and membership options.
• Meeting request or Inquiry: Provide name, various contact details, and a topic/request/question for meeting. Request that an agent of the organization (staffer/volunteer) contact you.
• Initiate case: Provide name, various contact details, and a topic/request/question for opening a case. Request that an agent of the organization (staffer/volunteer) facilitate the case.
• Find a member: You operate a professional society. Members of the public who wish to engage with a member may browse the public membership directory.
• Anonymous survey: You post a questionnaire for feedback on some business/organizational question.

Notes:

• Minimum access/Privilege escalation: Public forms always represent some kind of special/targeted permission. In general, members of the public cannot create/edit/read/delete Contact records; but, if using a specific form to add a new record with limited fields, then it may be allowed. This represents an escalation beyond the standard permissioning.

Self-service

Description: Make an update or request related to an existing account.

Most examples in "Public engagement" would also be sensible in a "Self-service" context, except with the added requirements of (1) providing the ability to view, update, or link with an existing record and (2) authenticating the identify of the person using the form and

Examples:

• Renew membership: For an existing membership, confirm details and provide payment information.
• My contact: Provide a form to view+edit personal contact information
• My household: Provide a form to view+edit the contact information for several related persons (either in a formal Household or in similar relationships, such as Spouse/Parent/Child)
• My organization: Provide a form to view+edit the contact information for several related persons/orgs (either in a formal Organization or in similar relationships, such as Employer/Employee)
• Find a member/colleague: You operate a professional society. Confirmed members may lookup information about other confirmed members.

Authentication: All of the self-service examples require some kind of authentication/identification for the person using the form. There are variations in how this is done, e.g.

• Username/password (i.e. log into Drupal with a username and password, authenticating as the correlated contact)
• Email with link (i.e. send an email via CiviMail, CiviEvent notification, et al with an authenticated link
• Access code (i.e. begin a multi-step pageflow; as a step in the process, send a confirmation code over email or SMS - then continue with the flow)

Minimum access/Privilege escalation: Self-service forms are less categorical than backend or public forms, e.g. they may be:

• Some may comply with the standard model (although this is probably less common than...).
• They often involve some kind of targeted escalation beyond the standard model - an admin has selected the fields, therefore it is OK to let the user work with those fields. (In this sense, they are similar to public forms.)
• Within an organization, different people/constituencies may have different self-service abilities. These could be distinguished by some characteristic of the form user:
  • Membership in a group, role, event, etc
  • A categorization in a tag, custom-field, etc
  • A CMS permission (eg edit own user)