http://www.phparch.com \ May 2019 \ 27Access Control and Authorization
Security Corner
RBAC separates the concepts
of Users, Roles and Permissions.
Roles are defined in a system, then
Permissions defined separately.
Then the security administrator
decides what role should be permit-
ted to do what action, by assigning
that role to the permission. Finally
users are assigned to roles. The
system does the rest.As a trivial example, triggering a
system update might require users to be
in the UPDATE_MANAGER or ADMINISTRATOR
roles. Users might be granted other
roles within the system, but the update
operation always checks for the pres-
ence of at least one of these required
roles.
Role-based systems can be very
powerful, can scale to manage users
and permissions for large applications,
and are relatively easy to administer.
In addition to ready-built tools like
PHP-RBAC, the Symfony project
published a Security module^3 which
supports role-based access control
with minimal configuration. The point
of both projects is to empower strong
security for PHP developers without
requiring engineering teams to reinvent
the wheel.
Attribute-Based Systems
A slightly different system uses
custom attributes of users, objects, and
even the environment to manage access
control. Users can (and likely will) still
possess one or more roles within the
system, but these roles are augmented
by other user properties and the nature
of the systems with which they interact
to determine relative levels of access.
As a trivial example, a user in the
EDITOR role is allowed to edit a publi-
cation of a news website, only if the
status of the publication is draft. Once
the publication is pushed to produc-
tion (and its status toggles from draft
to published), the user is blocked from
making changes.
Attribute-based control is far more
granular than role-based control and
3 Security module:
https://phpa.me/symfony-access-roles
allows for finer control over the oper-
ations in your system. Open source
projects like php-abac^4 help to abstract
away the detailed implementation while
still leveraging the smooth configura-
tion elements provided by libraries like
Sy m fony.Risk-Based Systems
The final access control system we’ll
discuss is one that factors in risk. Risk of
the operation being performed. Risk of
the way the user authenticated. Risk in
general. It’s based on an attribute-based
system above, but rather than merely
taking attributes into account, rates
specific attributes based on the riskiness
inherent to them.
Consider two operations being
executed: is the user attempting to view
their profile, or is the user attempting
to drop a database table. One operation
is riskier than the other—we’d want to
ensure we perform additional checks
before carrying out a drop table opera-
tion. Since this is a risky operation, we
might only want to allow it if the user is
browsing from a certain IP address (i.e.,
the company’s office) or only if they
authenticated via LDAP to the system
(versus leveraging OpenID via a social
media account).
These additional rules combine
with specific attributes of the user, the
environment, and the operation being
performed (or object being acted upon)
to determine if we proceed. While not
written in PHP, the Golang project
Ladon^5 presents an efficient means of
enumerating these rules, very similar
to the way AWS’ Identity and Access
Management^6 system works.
4 like php-abac:
https://phpa.me/craftcamp-php-abac
5 Ladon: https://github.com/ory/ladon
6 AWS’ Identity and Access Management:
https://aws.amazon.com/iam/Other Systems
One of the other, more interesting
ways systems can prevent abuse, and
invalid access is through a set of rules.
These rules can gauge which users are
allowed to perform an action (similar to
a role-based or attribute-based system).
However, they can also integrate other
logic in evaluating whether or not to
permit access.
Is this an application that should
only ever be accessed from a trusted
corporate network? Filter based on the
requester’s IP address regardless of their
identity.
Is this an application that should
only be used during work hours? Block
access to users on evenings and week-
ends regardless of their identity.In Conclusion
The system you ultimately choose
for your application depends highly on
what the application intends to do and
the nature of the users for which you
wrote it. A social application or in-house
tool for managing content might benefit
from a more straightforward system and
faster deployment times. An application
targeting government use, protecting
private information, or interacting with
a system considered sensitive might
necessitate stronger protections and a
more advanced access control system.
The critical thing to remember is that
merely authenticating your users is not
enough for any application, particu-
larly if you need to separate users into
groups based on behavior or expected
utilization of the tool. Every application
can benefit from proper access control.
Implementing a simple role-based
system is an easy way to get started and
paves the way for more sophisticated
systems to come online as your project
grows and matures.Eric is a seasoned web developer experienced with multiple
languages and platforms. He’s been working with PHP for
more than a decade and focuses his time on helping developers
get started and learn new skills with their tech of choice. You
can reach out to him directly via Twitter: @EricMann