[aerogear-dev] Security Thoughts (was: Re: SPEC: AeroGear Unified Push Server)

[Matthias Wessendorf]

BTW...


Have in mind, that regarding the "*Mobile Variant Instances*" thing, some
new comments were made in this thread:
http://aerogear-dev.1069024.n5.nabble.com/aerogear-dev-Security-for-quot-Device-Registration-quot-td2505.html


-Matthias




On Wed, May 8, 2013 at 5:30 PM, Matthias Wessendorf <matzew at apache.org>wrote:

> Hi,
>
> Bruno, Kris and I met, to talk a bit about the *security* related items
> here.
>  <https://gist.github.com/matzew/cd8c8de1e2f00b837bb5#oauth2>OAuth2
>
> Using OAuth2 for (initial) authentication of the following items:
>
>    - *Mobile Variant Instances:* The installation on a device (Mobile
>    Variant Instances) needs to authenticate itself in order to register
>    its data (e.g. deviceToken, alias etc, as discussed in the spec)
>    - *Applications:* Backend applications that are using the *HTTP
>    endpoints* to submit "Push Message requests" (e.g.send XZY to all
>    mobile-variant-instances of PushApplication X)
>    - *Developers:* OAuth2 is not enought. See below...
>
> <https://gist.github.com/matzew/cd8c8de1e2f00b837bb5#mobile-variant-instances-based-on-android--ios>Mobile
> Variant Instances based on Android / iOS
>
> There are OAuth2 clients, that will be reused. e.g. *AFNetworking* has
> support for it...
>  <https://gist.github.com/matzew/cd8c8de1e2f00b837bb5#java-application>(Java)
> Application
>
> Our Java lib will also use one of the existing client libs (e.g. Apache
> Oltu) to authenticate itself against the *AeroGear Unified Push Server*.
>  <https://gist.github.com/matzew/cd8c8de1e2f00b837bb5#javascript>
> JavaScript
>
> We will create something minimal for now, instead of making this part of
> AeroGear.Auth.
>  <https://gist.github.com/matzew/cd8c8de1e2f00b837bb5#security-framework>Security
> Framework
>
> For Developers (with different roles/groups etc) simply OAuth is not
> enough. We need a *Security Framework* for the*right management*, e.g. to
> authorize that Developer X is really allowed to do step y.
>
> The *AeroGear Unified Push Server* must be decoupled from any concrete
> "Security Provider", so that it is plugable and not tied to *one* "Security
> Framework". A common interface could be provided by AeroGear-Security.
> The *AeroGear Unified Push Server* is now only tied to this flexible
> dependency. Different plugable implementations would/cloud be provided by
> AeroGear-Security.
> <https://gist.github.com/matzew/cd8c8de1e2f00b837bb5#management-of-developers-and-push-applications>Management
> of *Developers* and Push Applications
>
> The Secuirty Framework abstration (e.g. via AG-Security), would model the
> concept of a Developer (and its groups/roles etc).
>
> The actual model of the *AeroGear Unified Push Server* (e.g.Push
> Applications,Mobile VariantsandMobile Variant Instances`) would be
> independent from that "security layer".
>
> However, since a Developer creates the model objects (e.g. a Mobile
> Variant for a Push Application), there is a relationship between them. To
> some degree (and also inspired by Picketlink), these are (logical)
> extensions of aDeveloper. They *belong* to a Developer.
>
> *TL;DR:* The "model objects" would be stored as "properties" /
> "attributes" of such a "Developer", abstracted by the (future) offerings of
> the AeroGear-Sec layer, instead of using a *concrete* "user class" of
> one, specific Security Framework
> <https://gist.github.com/matzew/cd8c8de1e2f00b837bb5#authentication-of-mobile-variant-instance>Authentication
> of Mobile Variant Instance
>
> For the first iteration, we are going to use OAuth here. *However*, that
> may have a problem: When aMobile Variant Instance is performing
> authentication againt the server, some Credentials (e.g.
> "kris:IloveJavaScript") are being used. For *ALL* the installed
> applications (e.g. via Play / Apple App-Store), or in EACH browser (
> SimplePush)!!
>
> That means the kris:IloveJavaScript couple will be used by 1.000.000
> phones. And opens room for *reverse engineering interests*.
>
> *Future:* we will evaluate "Digital signatures" or on the fly (self
> signed) client SSL certifactes. This also will remove the requirement (see
> Spec) to send a Mobile-Variant-ID to the *AeroGear Unified Push Server*
> ....
>
> *But for now, we start with OAuth...*
>  <https://gist.github.com/matzew/cd8c8de1e2f00b837bb5#javascriptsimplepush>
> JavaScript/SimplePush
>
> User Agent ID and Channel IDs being stored in localStorage...
>
> We *could* investigate JS encryption... but for now the plan is
> expire/renew those IDs after some amount of (specified?) time. Crypto.js
> will come at a later iteration!
>
> Thoughts? If not, content will be baked into the "spec"...
>
> With ♥
>
> Greetings
> Bruno, Kris and Matthias
>
>
>
>
>
>
>
> On Wed, May 8, 2013 at 6:54 AM, Matthias Wessendorf <matzew at apache.org>wrote:
>
>>
>>
>>
>> On Wed, May 8, 2013 at 5:24 AM, Deepali Khushraj <dkhushra at redhat.com>wrote:
>>
>>> Matthias,
>>>
>>> A couple of comments:
>>>
>>> * You mention disable notifications feature for "mobile variant
>>> instances". I was wondering if you considered the same for "mobile
>>> variants" and "push applications"? Could help admins disable misbehaving
>>> apps, and developers manage older app versions.
>>>
>>
>> yeah, removing(or perhaps disabling) mobile variants, or even the lager
>> "push application" concept would be possible.
>> I think I mentioned the "instances" to make clear I can easily remove a
>> guy, which has been fired (but he didn't return the company phone).
>>
>>
>>>
>>> * API access: during "app registration", developer login seems like a
>>> good idea.
>>>
>>
>> Otherwise everyone could register new apps :)
>>
>>
>>>  I am not so sure about "sending" messages though, as this will likely
>>> be initiated by a server-side component with no developer in the loop.
>>>
>>
>> I feel that we should protect our "sending http endpoint". That does
>> not necessarily mean a user:password combination.
>>
>> The "Send" is triggered by a server-side component (e.g. some backend
>> app, written in some language/framework).
>> We should make sure that only "valid" server-side components can send
>> messages to a PushApplication/MobileVariant(s).
>>
>> Not covered in the spec (but the UI Mockups indicate it already)
>> When these PushApplication/MobileVariant(s) are registered we will have a
>> button to generate "access keys".
>>
>> curl -v -H "Accept: application/json" -H "Content-type: application/json"
>> -H "ag-pa-access-key: 329804327981237984317927098247980432179843217813267834687213842"
>> -X POST
>>    -d '{message: {"key":"blah", "alert":"HELLO!"}}'http://SERVER/sender/broadcast/PushApplicationID
>>
>>
>> Not sure if that is really enough, but here the "server side comp." needs
>> to know the ID of the logical "Push Application" constract, plus it
>> "push-app-access-key";
>>
>> So... if someone knows these two, he could start spamming the users,
>> hence I feel that on-top of these keys we may want to have the
>> server-side-component somehow perform some sort of auth against our
>> HTTP-SEND endpoint
>>
>>
>>
>>
>>
>>>
>>> Thanks for the spec! The clear definitions made it very easy to read.
>>>
>>
>> Thanks!
>>
>>
>>>
>>> D.
>>>
>>>
>>> On May 6, 2013, at 3:33 AM, Matthias Wessendorf <matzew at apache.org>
>>> wrote:
>>>
>>> Moved the current draft to the homepage, see
>>> https://github.com/aerogear/aerogear.org/pull/57
>>>
>>> -M
>>>
>>>
>>> On Tue, Apr 30, 2013 at 1:57 PM, Bruno Oliveira <bruno at abstractj.org>wrote:
>>>
>>>> Really helpful Matthias. Thanks!
>>>>
>>>>
>>>> --
>>>> "The measure of a man is what he does with power" - Plato
>>>> -
>>>> @abstractj
>>>> -
>>>> Volenti Nihil Difficile
>>>>
>>>>
>>>>
>>>> On Tuesday, April 30, 2013 at 8:54 AM, Matthias Wessendorf wrote:
>>>>
>>>> > On IRC, Bruno raised a valid concern: The earlier version had "use
>>>> cases"
>>>> >
>>>> >
>>>> > I updated the GIST (
>>>> https://gist.github.com/matzew/b918eb45d3f17de09b8f) and added:
>>>> > * more definitions
>>>> > * usage scenarios
>>>> > * use cases
>>>> >
>>>> >
>>>> > -Matthias
>>>> >
>>>> >
>>>> >
>>>> >
>>>> >
>>>> >
>>>> >
>>>> > On Mon, Apr 29, 2013 at 3:27 PM, Matthias Wessendorf <
>>>> matzew at apache.org (mailto:matzew at apache.org)> wrote:
>>>> > > Hi,
>>>> > >
>>>> > > I started a GIST to convert the different gists and readme's into a
>>>> server-side spec
>>>> > > (https://gist.github.com/matzew/b918eb45d3f17de09b8f)
>>>> > >
>>>> > >
>>>> > > * Regarding the "mobile variant instance":
>>>> > > We need to decide, what a SimplePush client may need on-top of the
>>>> data, described below (and in the gist). (since they have clientIDs +
>>>> channels)
>>>> > >
>>>> > > * Similar... we need to reflect the "" on a "selected" (and
>>>> broadcast) send as well.
>>>> > >
>>>> > > * Sec: there is a different meeting, on the sec - content will be
>>>> integrated (or linked from this spec)
>>>> > >
>>>> > >
>>>> > > If this doc, looks good, I will submit it as a PR so that we get it
>>>> on the homepage
>>>> > >
>>>> > >
>>>> > > Next:
>>>> > > CLIENT SPEC is coming later today (or tomorrow)
>>>> > >
>>>> > > Thoughts ?
>>>> > > Matthias
>>>> > >
>>>> > >
>>>> > >
>>>> > >
>>>> > >
>>>> > > AeroGear Unified Push Server (Draft 0.0.3)
>>>> > >
>>>> > > The AeroGear Unified Push Server is a server that allows sending
>>>> native push messages to different mobile operation systems. The initial
>>>> version of the server supports Apple's APNs (
>>>> http://developer.apple.com/library/mac/#documentation/NetworkingInternet/Conceptual/RemoteNotificationsPG/Chapters/ApplePushService.html%23//apple_ref/doc/uid/TP40008194-CH100-SW9),
>>>> Google Cloud Messaging (
>>>> http://developer.android.com/google/gcm/index.html) and Mozilla's
>>>> Simple Push (https://wiki.mozilla.org/WebAPI/SimplePush).
>>>> > >
>>>> > > Motivation / Purpose
>>>> > >
>>>> > > Goal: Any (JBoss/AeroGear powered) mobile application, that is
>>>> backed by JBoss technology (e.g. admin console, Errai, drools, etc.), is
>>>> able to easily work with mobile push messages. For a JBoss "backend
>>>> application" it should be as simple as possible, to send messages to its
>>>> different mobile clients.
>>>> > >
>>>> > > Definitions
>>>> > >
>>>> > > Before we get into details, it's important that we have a good
>>>> lexicon.
>>>> > >
>>>> > > Push Application
>>>> > >
>>>> > > A logical construct that represents an overall mobile application
>>>> (e.g. Mobile HR).
>>>> > >
>>>> > > Mobile Variant
>>>> > >
>>>> > > A mobile variant of the Push Application. There can be multiple
>>>> variants for a Push Application (e.g. HR Android,HR iPad, HR iPhone free,
>>>> HR iPhone premium or HR Mobile Web).
>>>> > >
>>>> > > Mobile Variant Instance
>>>> > >
>>>> > > Represents an actual installation on a mobile device (e.g. User1
>>>> connected via MobileWeb or User2 runs HR iPhone premium on his phone)
>>>> > >
>>>> > > Overview
>>>> > >
>>>> > > The AeroGear Unified Push Server contains three different
>>>> components:
>>>> > >
>>>> > > Registration: Registry for Push Applications, Mobile Variants and
>>>> Mobile Variant Instances
>>>> > > Storage: A database, storing the registered applications and
>>>> instances
>>>> > > Sender: Receives messages and sends them to different Mobile
>>>> Variant Instances
>>>> > >
>>>> > >
>>>> > > The graphic below gives a little overview:
>>>> > >
>>>> > > Functionality
>>>> > > Registration
>>>> > >
>>>> > > Three different registration types are provided by the AeroGear
>>>> Unified Push Server.
>>>> > >
>>>> > > Push Application Registration
>>>> > >
>>>> > > Adds a logical construct, that represents an overall mobile
>>>> application (e.g. Mobile HR). The Push Application contains the following
>>>> properties:
>>>> > >
>>>> > > Name
>>>> > > Description
>>>> > > A collection of Mobile Variants
>>>> > >
>>>> > >
>>>> > > The server offers an HTTP interfaces to apply a Push Application
>>>> registration:
>>>> > >
>>>> > > curl -v -H "Accept: application/json" -H "Content-type:
>>>> application/json" -X POST -d '{"name" : "MyApp", "description" : "awesome
>>>> app" }' http://SERVER/applications <http://server/applications>
>>>> > >
>>>> > > The response returns an ID for the Push Application.
>>>> > >
>>>> > > Mobile Variant Registration
>>>> > >
>>>> > > Adds a mobile variant for an existing Push Application. There can
>>>> be multiple variants for a Push Application (e.g. HR Android, HR iPad, HR
>>>> iPhone free, HR iPhone premium or HR Mobile Web).
>>>> > >
>>>> > >
>>>> > > The server supports the following variant types:
>>>> > >
>>>> > > iOS
>>>> > > Android
>>>> > > SimplePush
>>>> > >
>>>> > > iOS Variant
>>>> > >
>>>> > > An iOS variant represents a logical construct for one iOS
>>>> application (e.g. HR for iPhone or HR for iPad ). The iOS variant requires
>>>> some APNs specific values:
>>>> > >
>>>> > > APNs Push Certificate file
>>>> > > Passphrase
>>>> > >
>>>> > >
>>>> > > The server offers an HTTP interfaces to register an iOS varian:
>>>> > >
>>>> > > curl -i -H "Accept: application/json" -H "Content-type:
>>>> multipart/form-data" -F "certificate=@/Users/matzew/Desktop/MyCert.p12" -F
>>>> "passphrase=TopSecret" -X POST http://SERVER/applications/{PUSH_ID}/iOS<http://server/applications/%7BPUSH_ID%7D/iOS>(
>>>> http://SERVER/applications/%7BPUSH_ID%7D/iOS<http://server/applications/%7BPUSH_ID%7D/iOS>
>>>> )
>>>> > >
>>>> > > NOTE: The above is a multipart/form-data, since it is required to
>>>> upload the "Apple Push certificate"!
>>>> > >
>>>> > >
>>>> > > The response returns an ID for the iOS variant.
>>>> > >
>>>> > > Android Variant
>>>> > >
>>>> > > An Android variant represents a logical construct for one Android
>>>> application (e.g. HR for Android). The Android variant requires some Google
>>>> specific values:
>>>> > >
>>>> > > Google API Key
>>>> > >
>>>> > >
>>>> > > The server offers an HTTP interfaces to register an Android variant:
>>>> > >
>>>> > > curl -v -H "Accept: application/json" -H "Content-type:
>>>> application/json" -X POST -d '{"googleKey" : "IDDASDASDSA"}'
>>>> http://SERVER/applications/{PUSH_ID}/android<http://server/applications/%7BPUSH_ID%7D/android>(
>>>> http://SERVER/applications/%7BPUSH_ID%7D/android<http://server/applications/%7BPUSH_ID%7D/android>
>>>> )
>>>> > >
>>>> > > _The response returns an ID for the Android variant.
>>>> > >
>>>> > > SimplePush Variant
>>>> > >
>>>> > > An SimplePush variant represents a logical construct for one
>>>> SimplePush application (e.g. HR mobile Web). The SimplePush variant
>>>> requires some Simple Push Network specific values:
>>>> > >
>>>> > > URL of the PushNetwork server
>>>> > >
>>>> > >
>>>> > > The server offers an HTTP interfaces to register an SimplePush
>>>> variant:
>>>> > >
>>>> > > curl -v -H "Accept: application/json" -H "Content-type:
>>>> application/json" -X POST -d '{"pushNetworkURL" : "
>>>> http://localhost:7777/endpoint/"}'
>>>> http://SERVER/applications/{PUSH_ID}/simplePush<http://server/applications/%7BPUSH_ID%7D/simplePush>(
>>>> http://SERVER/applications/%7BPUSH_ID%7D/simplePush<http://server/applications/%7BPUSH_ID%7D/simplePush>
>>>> )
>>>> > >
>>>> > > The response returns an ID for the SimplePush variant.
>>>> > >
>>>> > > Mobile Variant Instance Registration
>>>> > >
>>>> > > Adds an mobile variant instance to an existing mobile variant (e.g.
>>>> User1 runs HR-iPad on his device). It is possible that one user can have
>>>> multiple devices. A mobile variant instance contains the following
>>>> properties:
>>>> > >
>>>> > > Required Data
>>>> > > deviceToken
>>>> > >
>>>> > >
>>>> > > The platform specific device token, that identifies the device with
>>>> the used push network, in order to deliver messages
>>>> > >
>>>> > > operatingSystem
>>>> > >
>>>> > >
>>>> > > It is required for the device to submit it's exact name of the
>>>> underlying OS.
>>>> > >
>>>> > > osVersion
>>>> > >
>>>> > >
>>>> > > It is required for the device to submit it's exact version of the
>>>> underlying OS.
>>>> > >
>>>> > > Mobile Variation ID
>>>> > >
>>>> > >
>>>> > > ID received when registering a Mobile Variant. This ID needs to be
>>>> submitted as a request header (ag-mobile-variant). NOTE: It is possible
>>>> that this ID goes away, in favor for a digital signature in a future release
>>>> > >
>>>> > > Optional Data
>>>> > > deviceType
>>>> > >
>>>> > >
>>>> > > It is recommended to store the (exact) device type (e.g. phone vs
>>>> tablet).
>>>> > >
>>>> > > alias
>>>> > >
>>>> > >
>>>> > > If the business application requires the conecpt of a user, the
>>>> registration must submit an unique identifier (like a username), to
>>>> identify the user. It is possible that one user has multiple devices.
>>>> > >
>>>> > > Business Data
>>>> > >
>>>> > > The above are technical information bits that are required to get a
>>>> message to the device. This the app wants to send notification based on a
>>>> criteria, the relevant data has to be stored in the business backend. This
>>>> way the backend app is very flexible on the criterias (e.g. max salary,
>>>> geolocation, number of children, etc). All this data is NOT directly
>>>> related to the technical functionality of sending data. The usage of the
>>>> AeroGear Pipe is highly recommended to store business data on the business
>>>> backend.
>>>> > >
>>>> > >
>>>> > > The server offers an HTTP interfaces to register an mobile variant
>>>> instance:
>>>> > >
>>>> > > curl -v -H "Accept: application/json" -H "Content-type:
>>>> application/json" -H "ag-push-app: {id}" -H "ag-mobile-app: {id}" -X POST
>>>> -d '{ "alias" : "user at company.com (mailto:user at company.com)",
>>>> "deviceToken" : "someTokenString", "deviceType" : "ANDROID",
>>>> "mobileOperatingSystem" : "android", "osVersion" : "4.0.1" }'
>>>> http://SERVER/registry/device <http://server/registry/device>
>>>> > >
>>>> > > NOTE: Platform specific Client SDKs will be provided to submit the
>>>> require data to the AeroGear Unified Push Server.
>>>> > >
>>>> > > Storage
>>>> > >
>>>> > > A (configurable) database that stores all registered applications
>>>> and instances.
>>>> > >
>>>> > > Sender
>>>> > >
>>>> > > HTTP interface that receives messages for a delivery to different
>>>> Mobile Push Networks. A few different Sender Types are supported by the
>>>> push server.
>>>> > >
>>>> > > Global Broadcast Sender
>>>> > >
>>>> > > Sends a push message to all mobile variants (and all of its mobile
>>>> variant intances), of a given Push Application:
>>>> > >
>>>> > > curl -v -H "Accept: application/json" -H "Content-type:
>>>> application/json" -X POST -d '{"key":"blah", "alert":"HELLO!"}'
>>>> http://SERVER/sender/broadcast/{PushApplicationID}<http://server/sender/broadcast/%7BPushApplicationID%7D>(
>>>> http://SERVER/sender/broadcast/%7BPushApplicationID%7D<http://server/sender/broadcast/%7BPushApplicationID%7D>
>>>> )
>>>> > >
>>>> > > Sends a JSON map to the server. If platform specific key words
>>>> (e.g. alert for APNs) are used, they are honored for the specific platform.
>>>> This transformation is done by the AeroGear Unified Push Server.
>>>> > >
>>>> > > Variant specific Broadcast
>>>> > >
>>>> > > Sends a push message to only one mobile variants (and all of its
>>>> mobile variant intances).:
>>>> > >
>>>> > > curl -v -H "Accept: application/json" -H "Content-type:
>>>> application/json" -X POST -d '{"key":"blah", "alert":"HELLO!"}'
>>>> http://SERVER/sender/broadcast/variant/{MobileVariantID}<http://server/sender/broadcast/variant/%7BMobileVariantID%7D>(
>>>> http://SERVER/sender/broadcast/variant/%7BMobileVariantID%7D<http://server/sender/broadcast/variant/%7BMobileVariantID%7D>
>>>> )
>>>> > >
>>>> > > Sends a JSON map to the server. If platform specific key words
>>>> (e.g. alert for APNs) are used, they are honored for the specific platform.
>>>> This transformation is done by the AeroGear Unified Push Server.
>>>> > >
>>>> > > Selected Sender
>>>> > >
>>>> > > Sends a push message to a selected list of identified users
>>>> (regardless of their variant):
>>>> > >
>>>> > > curl -v -H "Accept: application/json" -H "Content-type:
>>>> application/json" -X POST -d '{ alias: ["user at foo.com (mailto:
>>>> user at foo.com)", "bar at moz.org (mailto:bar at moz.org)", ....], message:
>>>> {"key":"blah", "alert":"HELLO!"} }' http://SERVER/sender/selected<http://server/sender/selected>
>>>> > >
>>>> > > The alias value is used to identied the desired users. The payload
>>>> (messages) is a standard JSON map. If platform specific key words (e.g.
>>>> alert for APNs) are used, they are honored for the specific platform. This
>>>> transformation is done by the AeroGear Unified Push Server.
>>>> >
>>>> >
>>>> >
>>>> >
>>>> >
>>>> > --
>>>> > Matthias Wessendorf
>>>> >
>>>> > blog: http://matthiaswessendorf.wordpress.com/
>>>> > sessions: http://www.slideshare.net/mwessendorf
>>>> > twitter: http://twitter.com/mwessendorf
>>>> > _______________________________________________
>>>> > aerogear-dev mailing list
>>>> > aerogear-dev at lists.jboss.org (mailto:aerogear-dev at lists.jboss.org)
>>>> > https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> aerogear-dev mailing list
>>>> aerogear-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>>
>>>
>>>
>>>
>>> --
>>> Matthias Wessendorf
>>>
>>> blog: http://matthiaswessendorf.wordpress.com/
>>> sessions: http://www.slideshare.net/mwessendorf
>>> twitter: http://twitter.com/mwessendorf
>>> _______________________________________________
>>> aerogear-dev mailing list
>>> aerogear-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>
>>>
>>>
>>> _______________________________________________
>>> aerogear-dev mailing list
>>> aerogear-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>
>>
>>
>>
>> --
>> Matthias Wessendorf
>>
>> blog: http://matthiaswessendorf.wordpress.com/
>> sessions: http://www.slideshare.net/mwessendorf
>> twitter: http://twitter.com/mwessendorf
>>
>
>
>
> --
> Matthias Wessendorf
>
> blog: http://matthiaswessendorf.wordpress.com/
> sessions: http://www.slideshare.net/mwessendorf
> twitter: http://twitter.com/mwessendorf
>



-- 
Matthias Wessendorf

blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20130520/8a564989/attachment-0001.html