Specifications

49
With trust playing such a significant part of remote access, the Barracuda SSL VPN solution has been
designed to allow for either ‘coarsely grained’ or ‘finely grained’ access control. This approach allows
the product to mirror more closely the actual trust relationships present in the real world. In
conjunction with multi-tiered authentication schemes, our security model is much more advanced than
those offered by conventional VPN solutions.
Levels of Trust
Trust is administered in measures - the more trust a user has the more privileges they are granted.
Again the opposite is said for someone who has a lesser degree of trust and consequently is given a
lesser level of ownership and access.
The Barracuda SSL VPN appliance follows this tried and tested pattern. With the access control
framework, ‘administrators’ are seen as the most trusted users, seeing as they control the appliance.
‘Power users’ are given a lesser measure of control. Finally the standard user has a lesser degree of
trust and therefore potentially the least level of access and responsibility.
Access Control Architecture
The access control framework has been designed to tackle the following main issues.
• Users and Groups: Each organizations view on users and groups is almost always different.
They do though share common behavior, e.g. ‘Add User/Group’ or ‘Delete User/Group’. It is
also likely that the organization’s user/group directory already existed prior to the
introduction of this appliance, for example an existing Active Directory domain or LDAP
directory. The variety offered by such choice invariably gives rise to a number of different
approaches and implementations.
• Resource Access: The intended outcome when implementing an SSL VPN solution is to
allow remote access to network-based resources. The number of types of network resource is
relatively varied and new methods are likely to appear. Each resource deployed can have very
different access requirements, such as read or write permissions.
• Resource Distribution: A resource created within the system must be easily made accessible
to those users that require it. Assigning resources on a per-user basis should be avoided
wherever possible.
• Resource Permissions: Resources can have a range of permissions to limit how they may be
assigned. When a resource is assigned to a user the user must be restricted to the set
permissions. For example, a super user may create a resource to administer creation and
assignment of application shortcuts only. This is assigned to a user who attempts to delete an
existing application shortcut, this operation will be declined.
In order to resolve the aforementioned issues the access control architecture relies on three key
entities:
• Principal: The intended ‘consumer’ of the resources, i.e. a user or a group.
• Resource: The networked resource, internal function or property item that the principal
wishes to utilize, e.g. a Web-forward or the right to manage accounts.
• Policy: This is the relationship defined between the principal and resource. It is the
component that ensures that only the right people can perform the right action.