📄 authorization.html
字号:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"><HTML> <HEAD> <META HTTP-EQUIV="CONTENT-TYPE" CONTENT="text/html; charset=iso-8859-1"> <TITLE>MIDlet Suite Security</TITLE> <LINK REL ="stylesheet" TYPE="text/css" HREF="../../../../stylesheet.css" TITLE="Style"> <!-- @(#)Authorization.html 1.29 02/07/11 --> <!-- Changed by: Roger Riggs - Sun Microsystems Inc, 22-Mar-2002 --> <!-- Changed by: Gary Adams - SMI Software Development, 11-Mar-2002 --> <!-- Changed by: Roger Riggs - Sun Microsystems Inc, 11-Jul-2002 --> <!-- Changed by: Gary Adams - SMI Software Development, 07-Aug-2002 --> <!-- Changed by: Roger Riggs - Sun Microsystems Inc, 03-Sep-2002 --> </HEAD> <BODY> <H1>Security for MIDP Applications</H1> <P>The MIDP 1.0 specification constrained each MIDlet suite to operate in a sandbox wherein all of the APIs available to the MIDlets would prevent access to sensitive APIs or functions of the device. That sandbox concept is used in this specification and all untrusted MIDlet suites are subject to its limitations. Every implementation of this specification MUST support running untrusted MIDlet suites. </P> <P>MIDP 2.0 introduces the concept of trusted applications that may be permitted to use APIs that are considered sensitive and are restricted. If and when a device determines that a MIDlet suite can be trusted then access is allowed as indicated by the domain policy. The Trusted MIDlet Suite Security section below describes the concepts. Any MIDlet suite that is not trusted by the device MUST be run as untrusted. If errors occur in the process of verifying that a MIDlet suite is trusted then the MIDlet suite MUST be rejected. </P> <H2><A name="untrusted">Untrusted MIDlet Suites</A></H2> <P>An untrusted MIDlet suite is a MIDlet suite for which the origin and the integrity of the JAR file can NOT be trusted by the device. Untrusted MIDlet suites MUST execute in the untrusted domain using a restricted environment where access to protected APIs or functions either is not allowed or is allowed with explicit user permission. Any MIDP 1.0 compliant MIDlet suite MUST be able to run in an implementation of this specification as untrusted. Any APIs or functions of this specification which are not security sensitive, having no permissions defined for them, are implicitly accessible by both trusted and untrusted MIDlet suites. Untrusted MIDlet suites do not request permissions explicitly in the JAR manifest or application descriptor. </P> <P>The untrusted domain for untrusted MIDlet suites MUST allow, without explicit confirmation by the user, access to:</P> <TABLE BORDER="1" CELLSPACING="1" CELLPADDING="5"> <THEAD> <TR> <TH WIDTH="60%">API</TD> <TH WIDTH="40%">Description</TD> </TR> </THEAD> <TR> <TD><CODE>javax.microedition.rms</CODE></TD> <TD>RMS APIs </TD> </TR> <TR> <TD><CODE>javax.microedition.midlet</CODE></TD> <TD>MIDlet Lifecycle APIs </TD> </TR> <TR> <TD><CODE>javax.microedition.lcdui</CODE></TD> <TD>User Interface APIs </TD> </TR> <TR> <TD><CODE>javax.microedition.lcdui.game</CODE></TD> <TD>The Game APIs </TD> </TR> <TR> <TD><CODE>javax.microedition.media</CODE><BR> <CODE>javax.microedition.media.control</CODE></TD> <TD>The multi-media APIs for playback of sound </TD> </TR> </TABLE> <P>The untrusted domain for untrusted MIDlet suites MUST allow, with explicit confirmation by the user, access to protected APIs or functions:</P> <TABLE BORDER="1" CELLSPACING="1" CELLPADDING="5"> <THEAD> <TR> <TH WIDTH="60%">API</TD> <TH WIDTH="40%">Protocol</TD> </TR> </THEAD> <TBODY> <TR> <TD><CODE>javax.microedition.io.HttpConnection</CODE> </TD><TD><CODE>http</CODE></TD> </TR> <TR> <TD><CODE>javax.microedition.io.HttpsConnection</CODE> </TD> <TD><CODE>https</CODE></TD> </TR> </TBODY> </TABLE> <H2><A name="trusted">Trusted MIDlet Suite Security</A></H2> <P>Security for Trusted MIDlet suites is based on protection domains. Each protection domain defines the permissions that may be granted to a MIDlet suite in that domain. The protection domain owner specifies how the device identifies and verifies that it can trust a MIDlet suite and bind it to a protection domain with the permissions that authorize access to protected APIs or functions. The mechanisms the device uses to identify and trust MIDlet suites are defined separately to allow them to be selected appropriately to the device, network, and business case.</P> <P>The <A HREF="PKITrust.html"> Trusted MIDlet Suites Using X.509 PKI</A> describes a mechanism for identifying trusted MIDlet suites though signing and verification. If an implementation of this specification will recognize MIDlet suites signed using PKI as trusted MIDlet suites they must be signed and verified according to the formats and processes specified in Trusted MIDlet Using X.509 PKI.</P> <H3><A NAME="definitions">Definition of Terms</A></H3> <TABLE BORDER="1" CELLSPACING="1" CELLPADDING="7"> <THEAD> <TR> <TH VALIGN="TOP">Term</TD> <TH VALIGN="TOP">Definition</TD> </TR> </THEAD> <TR> <TD>Protection Domain</TD> <TD>A set of <em>Allowed</em> and <em>User</em> permissions that may be granted to a MIDlet suite</TD> </TR> <TR> <TD>Permission</TD> <TD>A named permission defined by an API or function to prevent it from being used without authorization</TD> </TR> <TR> <TD>Trusted MIDlet Suite </TD> <TD>A MIDlet suite for which the authentication and the integrity of JAR file can be trusted by the device and bound to a protection domain</TD> </TR> </TABLE> <H2><A NAME="base">Authorization Model</A></H2> <P>The basic authorization of a MIDlet suite is established by the relationships between the following elements: </P> <UL> <LI>A protection domain consisting of a set of <em>Allowed</em> and <em>User</em> permissions </LI> <LI>A set of permissions requested by the MIDlet suite in <code>MIDlet-Permissions</code> and <code>MIDlet-Permissions-Opt</code> attributes </LI> <LI>A set of permissions for each protected API or function on the device which is a union of all permissions defined by every API on the device for protected functions </LI> <LI>The user who may be asked to grant permissions </LI> </UL> <H3>Assumptions</H3> <UL> <LI>MIDlets do not need to be aware of the security policy except for security exceptions that may occur when using APIs. </LI> <LI>A MIDlet suite is subject to a single protection domain and its permissible actions. </LI> <LI>The internal representation of protection domains and permissions is implementation specific. </LI> <LI> The details of how authentication results and configuration settings are presented to the user in the user interface are implementation dependent and are outside the scope of this specification. </LI> <LI>The device must protect the security policy and protection domain information stored in the device from viewing or modification except by authorized parties. </LI> <LI>If the security policy for a device is static and disallows use of some functions of the security framework then the implementation of unused and inaccessible security functions may be removed. </LI> <LI>Security policy allows an implementation to restrict access but MUST NOT be used to avoid implementing functionality. For example, unimplemented protocols under the Generic Connection framework MUST throw <CODE>ConnectionNotFoundException</CODE>. </LI> </UL> <H3><A NAME=perm>Permissions</A></H3> <P>Permissions are the means to protect access to APIs or functions which require explicit authorization before being invoked. Permissions described in this section only refer to those APIs and functions which need security protection and do not refer to other APIs which can be accessed by both trusted and untrusted MIDlet suites and do not need explicit permission. Permissions are checked by the implementation prior to the invocation of the protected function. </P> <P>The names of permissions have a hierarchical organization similar to Java package names. The names of permissions are case sensitive. All of the permissions for an API MUST use the prefix that is the same as the package name of the API. If the permission is for a function of a specific class in the package then the permission MUST include the package and classname. The set of valid characters for permissions is the same as that for package and class names. The conventions for use of capitalization in package names SHOULD be used for permission names. For example, <CODE>javax.microedition.io</CODE>. Following the permission name, whether by package or class, additional modifiers may be appended with a separator of "." (Unicode U+002E). </P> <P> Each API in this specification that provides access to a protected function will define the permissions. For APIs defined outside of MIDP 2.0 there must be a single document that specifies any necessary permissions and the behavior of the API when it is implemented on MIDP 2.0. </P> <H3>Permissions for Protected Functions</H3> <P>Each function (or entire API) which was identified as protected must have its permission name defined in the class or package documentation for the API.</P> <P>Refer to the documentation of the <CODE>javax.microedition.io</CODE> package for permissions on all Generic Connection schemes defined in this specification. All APIs and functions within this specification that do not explicitly define permissions MUST be made available to all trusted and untrusted MIDlet suites.</P> <H3>Requesting Permissions for a MIDlet Suite</H3> <P>A MIDlet suite that requires access to protected APIs or functions must request the corresponding permissions. Permissions requested can be required by listing the permissions⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -