Application Access Control

Moving from the web to the cloud with

robust security
 Introduction
• Process hosted applications have become
the norm
– Hosting processes run as a secured user for the
process, not the user
– Impersonation can be used, but it’s expensive
and requires user accounts
– Each user account on the OS is another attack
vector
• Distributed systems, cloud computing and
peer-to-peer are growing in popularity
– All of these system types imply a hosted
environment
 A Framework Based Model
• An enterprise application framework can be
developed to centralize user authentication
and authorization
• Transcends all forms of authentication
– Provider based model for “pluggable” credentials
– Multiple types of authenticators may be used
• Separation of authorization into an orthogonal
implementation
– Permissions are extensible
– User mapping to permissions are modularized
 Framework Integration
• Each system
component is isolated
• Security is itself an
isolated component
• Component integration
is dynamic in the core
framework
• Security is extended to
code access security
as well
 Deployment Capabilities
• Architecture of
isolated
components and
registries allows for
flexible
deployments
• Coop is simply a
form of deployment
accommodated by
the architecture
 Application Design
• Core framework provides all
“cross-cutting” functionality
including security
• Access model is based
upon component-level
security, each module
declares a distinct
permission set
• Application is based upon a
required set of components
that are deployed across a
cluster of registered nodes
 Module Structure
• A module is conceptually a
public API that is accessed
by the application
• Each request passes
linearly through dynamically
injected providers
• Providers are loaded via
reflection and use a
dynamic binding protocol to
ensure they only respond
when called appropriately
 Security Design
• Dynamic loading is key
– Engine performs all loading and
binding (fail-safe defaults applied)
– Module loads and binds all providers
directly based upon registry (open
design)
– Access to all is secured and directly
checked per call (complete mediation)
– Each “part” of security is isolated from
the others
• Extensibility is built-in
• All enhancements are made by
changing providers
 Overarching Implementation
• A single framework instance can tie
together multiple applications across
multiple nodes
• Security can be deployed in isolated
chunks to separate information stores
• Constructs like single-sign on are “free”
– Black-listing / auditing of users can transcend
applications
• The unified security mechanism is the
SecurityContext entity
 SecurityContext Entity
• Any execution of code must be on behalf of some
user
– At the system (OS) level, this is the hosting process
user
– For a user request, the code is constrained virtually
by framework code access
– A request must pass the user along for authorization
• A SecurityContext entity encapsulates the user or
“process” requesting the action
– Engine (the hosting engine entity itself)
– Module (the originating module that is brokering the
operation request)
– Application (the application the request is made from)
– User (the actual user account token the request is for)
 Passing a Context
• All modules are provided a single SecurityContext
object at initialization time
• Only the Engine (Singleton) can create an original
SecurityContext
– The engine embeds itself into the initial
SecurityContext object
– All module SecurityContexts are derived from the
engine context
– Each module can compare a received context engine
to it’s own to ensure a common engine instance is
there
• User Interface elements interact with users and
generate a SecurityContext object with an
associated user
 Users
• A user is a token representing an
authorized “account” within the system
• Users can represent a person or an
external system (application)
– All users must be granted permissions to be
useful
– System users (applications) are used to
exchange data between systems with equal
security mechanisms to a person user
account
 Permissions
• A permission is a named token, owned by a code
module that represents an action
– Permission “names” are broken into 3 areas
• Verb (e.g. create, execute)
• Scope (e.g. application, global, system)
• Access Type (e.g. class, object, field, spatial, time, cell)
– Permissions are registered and unregistered as part of the
installation of a module
• Permissions are used by the owning module
– The owning module’s current security provider “asks” the
framework if the requesting user “has” the permission and
executes any additional code for verification of
authorization
– Changing the module security provider changes the
currently implemented authorization enforcement
• Each node may be configured differently (by enclave)
 Roles
• A role is an application scoped, named entity for
relating users to permissions
– Users cannot be directly assigned permissions
(cleaner model)
– Roles may be nested
– Resolution of roles is performed by the role provider
• Each applications roles are isolated
– Users are at the system level and therefore transcend
all applications (SSO is free)
• Role provider can be replaced to accommodate
any resolution model
– Grant model is default (no-deny)
– Grant/Deny model is a simple provider change
 Authentication
• Authentication is the process of verifying the
requesting party knows a shared secret to resolve
the requesting party to a user account
– Authentication can be done in many ways
• Authentication module supports pluggable
providers for any type of authentication
– Username / password (default)
– X.509 certificate (or similar)
– Biometric (any type of factors can be applied)
• Credential storage is centralized to a single model
– Minimized development of a new provider to the
credential classes and a comparator
 Module Security Provider
• Each executable module of code has one or more
providers, each of which have a single registered
security provider
– Security providers evaluate security rules to perform
authorization
– May be simple user look-up or permission resolution
– May include ANY form of validation as designed by
the implementor of the security provider
• Unlimited flexibility in design
– Change is extremely cheap
– Multiple deployments can each use a common
module base with custom security providers
– Minimizes deployment costs
 Conclusions
• The implementation of an enterprise
application framework with integrated security
will:
– Enhance security capabilities
– Reduce complexity of implementation (fewer
“moving parts”
– Maintains separation of concerns
– Incredible flexibility
• Pluggable provider construct permits
integration into existing technologies
– Cost is minimized when changing underlying
technologies used