Paddy Architecture and Security Proposal
From MemberWiki
Contents |
Architecture and security proposal
JON: This wiki page contains a submission by Paddy Byers about Mobile Device APIs security. We have merge this document into Mobile_Device_APIs_Security. The original document is preserved in its original form, except with some color-coded comments about how to merge into the other document.
Introduction
The notes below describe a proposed architecture for the definition and implementation of device APIs and the associated security framework. It is intended to be agnostic to the specific implementation method, but is based substantially on the WebVM architecture and certain implementation dependencies might remain at this stage - if so, they are unintentional.
This document first outlines the key principles of the architecture and their main implications, before outlining the architecture in more detail.
Terminology
JON: I suggest merging the contents of this section into the "Terminology" section of Mobile_Device_APIs_Security.
Platform API
An API exposed by the native platform of the device.
Scriptable API
An API that exposes device functionality to scripts within web applications.
Security framework
The set of security capabilities responsible for ensuring actions are performed in a controlled manner.
Trusted subsystem
An implementation of a scriptable API, making use either of platform or other scriptable APIs, that can be relied upon to expose only the functionality defined in its own API, and no additional functinality as may be available in any of the underlying APIs.
Key principles and implications
JON: I suggest moving this whole section into Mobile_Device_APIs_Security just after the "Terminology" section, installing older sections 'Access control belongs in the "system"' and 'JavaScript logic simply calls the APIs' within this section.
API extensibility
The framework supports the creation of APIs by any party, and does not depend on any specific central definition or standardisation process for the APIs themselves.
The implications of this are given below.
APIs, including both interfaces and implementations of those interfaces, are identified by URI Usual URI namespacing conventions can therefore be used to manage the namespace of API identifiers. Any centrally defined APIs can be defined within a URI belonging to the defining organisation, such as openajax.org, or omtp.org. JON: I understand why we need to put a URI on an interface definition so that we can be sure which spec we are working with, and I understand why we need to put a URI on an implementation so implementations can be uniquely defined (we have a similar requirement with Hub 1.0). But we need to avoid putting unnecessary bookkeeping requirements and too much bureaucracy on ourselves and on the world. Therefore, I'm not sure about requiring a URI for a particular implementation of a particular interface.
Any web application (whether a web page or installed widget) must explicitly declare the APIs it intends to use. This declaration can take the form of a static declaration (eg in a manifest for a widget package), or can be a programmatic declaration (eg openajax.loadAPI('http://api.openajax.org/mobile/contacts'); ). This declaration allows for:
- a check that the runtime supports the API in question;
- dynamic provisioning of the API, in implementations that support this;
- a permission check that the page in question is permitted to bind to that API. This delivers flexibility and usability benefits to the security framework as compared with simply enforcing access control at the point that APIs are called, or APIs attempt to perform security-relevant platform operations.
- the ability of a runtime to resolve, based on local circumstances or other specified parameters, which particular implementation or configuration of an API to load or bind to. (This also mirrors the approach increasingly followed by the toolkits and web API frameworks, wherein APIs are programmatically loaded rather than being explcitly and directly referenced by a SCRIPT tag.)
- (In the case of statically declared dependencies), the ability for a local widget manager to determine prior to installation whether or not a widget is capable of running on the target device.
- dealing with trusted subsystems (in implementations that support this). It is possible to define separate APIs, offering differing levels of access to the same resource, and selectively grant access at the API level.
Support for all Application Deployment models
The framework supports all of the application deployment models listed. Concretely, this means that:
- within the security framework, policies can be configured that depend both on URI identities and Signer identities;
- within an implementation, the mechanism for binding a page to an API (and applying any configured policy to the bind action) must be able to deal with both statically and dynamically declared dependencies.
JON: We need to discuss how this section relates to the Application Deployment model discussions we have had relative to the Use Cases and Requirements documents.
Authentication of content separated from assignment of rights
Many mobile application security frameworks assign each application to a trust domain based on a classification of the installed root certificates on the device. An application would, for example, be assigned to an "operator" trust domain if it is signed, and the validation chain for its signature ends with a certificate that is classified as an "operator" certificate.
The trust domain in turn determines the rights given to the application.
In the proposed architecture, this specific dependency between establishing the authenticity of a web application and determining its rights is avoided. Instead, the rights assigned to any web application are determined based on a configured policy that depends on the application identity as well as the root certificate by which that identity was verified. JON: I recommend minor wording changes here to talk about these things as potential ways forward rather than the way forward. We aren't yet at the stage where we can be sure we fully know the way forward.
Support for trusted subsystems
The security framework, responsible for enforcement of a configured security policy, by default performs a check on every attempt to call a scriptable API, and on every attempt by the implementation of that API to call an underlying platform API.
However, when the implementation of a scriptable API is known to be a trusted subsystem, an attempted call to a platform API is permitted provided that that trusted subsystem is authorised to access that API, even if the invoking web application is not. Using this, scriptable APIs and trusted implementations can be created that selectively grant access to the resources exposed by a platform API in circumstances where full access to the platform API is not allowable. JON: I was somewhat confused about the intended meaning here. I assume that trusted subsystems should be able to make calls to platform APIs, but the implication is that somehow or other the trusted subsystem won't allow an application to bypass security by invoking the trusted subsystem's APIs which then indirectly invoke the platform APIs.
Framework definitions
Agent
A web application, either remotely hosted on a web server or locally installed as a widget, is considered to be an agent.
Security context
An Agent has a number of properties that are relevant to security, collectively referred to as its Security Context. These include:
- the site domain, if the web page is remotely hosted at that domain. The site domain might additionally be verified if a server certificate has been verified by SSL, or if the underlying network connection has some other reliable means of domain resolution.
- a signer's distinguished name, if the web page is read from a signed container (such as the JAR package for a locally installed widget).
JON: The above section needs to be merged into an overlapping section already found in Mobile_Device_APIs_Security.
Action
Multiple types of action are addressed and mediated by the framework. Actions are named by defining a number of action namespaces and using the generic naming scheme :. JON: Did some text get deleted accidentally?
The following actions are understood by the framework.JON: Did some text get deleted accidentally?
Platform API
JON: I made earlier comments above questioning the need to define URIs for each implementation of each interface. My feeling is that it is fine for some implementations such as WebVM to assign URIs for each platform API, but not a requirement that all implementations do this.
All low-level security-relevant platform operations, according to some naming scheme. In WebVM, these are named according to the Java package/class/API namespace, since these are the low-level platform operations that are mediated by the system.
The scheme identifier is midp. JON: My guess is that statement is true for WebVM, but isn't true for OpenAjax.
An example of a fully qualified action identifier is midp:javax.microedition.location.read.
Other platforms may define their own platform API namespace and API names.
A standardised set of platform API names, using the openajax namespace id, could be defined, which simply become aliases for platform-specific names within given implementations.
Bind
JON: I don't think we should require a binding process via a binding action. I would expect that in most situations the platform takes care of linking an implementation to a scriptable API under the hood, and from the perspective of an application, all that it knows is that the given scriptable API is supported.
This is the action of binding an agent to a scriptable API.
The fully qualified identifier is system:bind.
Scriptable API
This is the action of calling a function declared in a specific scriptable API.
The scheme identifier is script.
The general form of the action identifier is script:<scriptable API URI>!<function name>
Query
A security Query represents a specific attempt to perform an Action, and encapsulates the information on which the corresponding security decision is made. A Query refers to the (identifier of the) attempted Action.
Certain Queries, in addition to the Action, contain information relating to the context of the specific attempt. In the case of an attempt to open a file, for example, this context information might include the path and name of the file. The definition of each specific Action also defines whether or not there is any expected context information associated with that Action.
Ruleset
A Ruleset loosely corresponds to the idea of a security domain; that is, it can be used to model a collection of sites across which a particular set of permissions apply.
Each Ruleset includes at least one Rule and at least one Identity. A Ruleset exists to associate the Rules with their Identities.
Rule
A Rule indicates whether or not permission for a particular Action (such as binding to a library or sending an SMS) should be granted or denied. The Rule can given three outcomes:
- permission is Granted;
- permission is Denied;
- the check should be referred to the User. In this case, a security prompt should appear, allowing the user to make the decision.
In each Ruleset, a Rule can be created for any or all of the Actions. (The Rules will only apply to Agents whose URI/DN matches one of the Identities.)
In addition to referring to an Action, a Rule can also optionally include a Constraint, which is an additional qualifier that specifiers whether or not a given Query matches the Rule based on the context information. For example, a Rule governing the File Open action can specify a constraint limiting permission to files in a given directory.
Security configuration
A Security Configuration comprises a number of Rulesets.
Permission check procedure
JON: I recommend just copying this section as is into Mobile_Device_APIs_Security.
Each Security Context (loosely corresponding to a particular scope within the execution of an application) is associated with a Security Configuration - that is, a collection of Rulesets.
Any attempted Action that arises in that context, giving rise to a corresponding Query, is checked against that Security Configuration, and allowed or declined, on the basis of the following procedure:
- each Ruleset is checked to determine whether or not the Security Context's Identity belongs to that Ruleset. If it does, the Rules in that Ruleset are added to the set of Applicable Rules. If not, no Rules in that Ruleset are considered further.
- each Rule in the set of Applicable Rules is checked to determine whether or not the Rule matches the Query. A Rule is considered to match if the Rule's Action matches the Query's Action, and if any context information in the Query matches any Constraint in the Rule. If the Rule matches the Query, the Rule's outcome is added to the set of applicable outcomes. If not, the Rule is not considered further. If there are no matching Rules, the Query is denied.
- the most restrictive outcome of all of the applicable outcomes is determined.
- If that outcome is Granted, the Action is allowed to proceed. If the outcode is Denied, the Action is not allowed to proceed and an error is returned.
- If the outcome is that the check should be referred to the user, an interactive prompt is presented that shows relevant details relating to the Security Context and Query, to which the user can Grant or Deny permission. The Action is allowed to proceed or not depending on the user's response.
