Csci283 Presentation Spring2009

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