Just An Application

June 2, 2009

What’s New In MIDP 3.0 ? Part 2: Application Level Access Authorization

Filed under: Java, JME, MIDlets, MIDP, MIDP3 — Tags: , , , — Simon Lewis @ 10:09 pm

Probably not the most obvious place to begin, but since the Event API, the Inter-MIDlet communication API, and RMS all support access control in terms of authorized MIDlets, I am going to start by covering Application Level Access Authorization, before going on to the APIs that use it.

The Authorization Model

For a MIDlet to enforce access control in terms of authorized MIDlets, the MIDlet suite containing the enforcing MIDlet must explicitly specify the authorization criteria to be met by an accessing MIDlet. The criteria that must be specified are the protection domain, the vendor, and the signer of the MIDlet suite containing the accessing MIDlet.

The protection domain requirement can only specify that the protection domain of the MIDlet suite containing the accessing MIDlet be the same as that of the MIDlet suite containing the enforcing MIDlet, or that it is not significant.

The vendor requirement can explicitly specify the vendor of the MIDlet suite containing the accessing MIDlet, or that it is not significant.

The signer requirement can explicitly specify the signer of the MIDlet suite containing the accessing MIDlet, or that it is not significant.

An accessing MIDlet is authorized if all the specified criteria are met, that is, if the protection domain AND the vendor AND the signer of the MIDlet suite containing the accessing MIDlet all match those specified.

Multiple protection domain/vendor/signer triplets may be specified in which case the accessing MIDlet is authorized if all the specified criteria for at least one of the specified protection domain/vendor/signer triplets are met.

MIDlets in the same MIDlet suite as the MIDlet enforcing access control are automatically allowed access.

If no authorization criteria are specified by a MIDlet suite then access control will not be enforced, that is, by default, there is no access control.

Specifying Authorization Criteria

The MIDlet-Access-Auth-Type-<n> Attribute

Authorization criteria are specified by defining one or more MIDlet-Access-Auth-Type-<n> attributes in the manifest of the MIDlet suite JAR. The first ordinal n must be 1 and consecutive ordinals should be used. If there is a gap or gaps than all attributes following the first gap are ignored.

The value of each attribute is a semi-colon separated triplet of the form

    domain=<domain-value>;vendor=<vendor-value>;signer=<signer-value>

All three value pairs must be present and legal. If they are not then the MIDlet suite installation will fail.

The <domain-value> can be either of the literals SELF, meaning the same protection domain as the declaring MIDlet suite, or ANY, meaning that the protection domain is not significant.

The <vendor-value> can be either a quoted string which may contain whitespace identifying a given vendor, or the literal ANY, meaning that the vendor is not significant.

The <signer-value> can be either a string specifying a certificate alias, or the literal ANY, meaning that the signer is not significant.

The MIDlet-Access-Auth-Cert<n>

A certificate alias is specified by defining a MIDlet-Access-Auth-Cert-<n> attribute in the manifest of the MIDlet suite JAR.

The value of the attribute is a whitespace separated pair of the form

    <alias> <certificate>

where <alias> is an unquoted string, and <certificate> is a Base-64 encoded certificate.

Examples

The following is legal but effectively useless, since it allows access by any MIDlet whatsoever,

    MIDlet-Access-Auth-Type-1: domain=ANY;vendor=ANY;signer=ANY

Slightly more useful, the following specifies that the accessing MIDlet must be contained in a MIDlet suite in the same protection domain as the MIDlet suite containing the enforcing MIDlet.

    MIDlet-Access-Auth-Type-1: domain=SELF;vendor=ANY;signer=ANY

It is also possible to specify that that the accessing MIDlet must be contained in a MIDlet suite from a given vendor.

    MIDlet-Access-Auth-Type-1: domain=ANY;vendor="MIDlets R Us";signer=ANY

Note that an unsigned MIDlet suite can use any vendor name it chooses so this may not be a particularly useful access control policy.

It is also possible to specify that that the accessing MIDlet must be contained in a MIDlet suite signed by a given certificate.

    MIDlet-Access-Auth-Type-1: domain=ANY;vendor=ANY;signer=TrustedCertificate
    MIDlet-Access-Auth-Cert-1: TrustedCertificate <Base-64 encoded cerificate>

The following specifies that the MIDlet suite containing the accessing MIDlet must be in the same protection domain as the MIDlet suite containing the enforcing MIDlet, AND that it be provided by the given vendor AND that it be signed by the given certificate.

    MIDlet-Access-Auth-Type-1: domain=SELF;vendor="MIDlets R Us";signer=TrustedCertificate
    MIDlet-Access-Auth-Cert-1: TrustedCertificate <Base-64 encoded cerificate>

The following specifies that the MIDlet suite containing the accessing MIDlet must be in the same protection domain as the MIDlet suite containing the enforcing MIDlet, OR that it must be provided by the given vendor AND that it must be signed by the given certificate.

    MIDlet-Access-Auth-Type-1: domain=SELF;vendor=ANY;signer=ANY
    MIDlet-Access-Auth-Type-2: domain=ANY;vendor="MIDlets R Us";signer=TrustedCertificate
    MIDlet-Access-Auth-Cert-1: TrustedCertificate <Base-64 encoded cerificate>

Copyright (c) 2009 By Simon Lewis. All Rights Reserved.

Advertisements

2 Comments »

  1. […] server may specify that only an authorized MIDlet can be a […]

    Pingback by What’s New In MIDP 3.0 ? Part 4: Inter-MIDlet Communication « Just An Application — June 5, 2009 @ 11:56 pm

  2. […] Access to RecordStores can now be controlled using Application Level Access Authorization. […]

    Pingback by What’s New In MIDP 3.0 ? Part 6: RMS « Just An Application — June 11, 2009 @ 9:38 am


RSS feed for comments on this post. TrackBack URI

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Blog at WordPress.com.

%d bloggers like this: