Thanks for your help. I am able to determine the calling
applications.
Harri, if you are curious this is what I did:
1. Activity binds to my service and makes a call to my remote service
requesting a token.
2. In the remote binder interface, the service uses
Binder.getCallingUid to get uid, then package then signatures
3. Service generates a UID (token) and associates the signature in a
cache with that token. Token is returned to activity
4. Activity unbinds from token binder and binds again to my actual
service binder. Passes the token in the intent. Service validates
the signature.
Thanks again all!
On Dec 17, 7:43 am, Harri Smått <har...@gmail.com> wrote:
> Oh,
>
> Forgot to add. Bear in mind that Facebook SSO uses Activity.startActivityForResult(..) which gives them access to Activity.getCallingActivity() once authentication Activity is spawned.
>
> --
> H
>
> On Dec 17, 2011, at 5:22 PM, Harri Smått wrote:
>
>
>
>
>
>
>
> > Hi,
>
> > AFAIK there is no way to determine calling application from yourServiceautomatically (as many have stated already). As for Facebook SSO, it's a bit different situation since it handles logging in directly into their web services via assigned access token. In your situation you ought to do something similar though, especially give your clients a client library for making it easier to authenticate with your AndroidService.
>
> > Now, if you have a webservice, which clarifies your situation a lot, the whole authentication procedure could go roughly as follows.
>
> > 1. Your clients have to register their package signature vie web interface to server side.
> > 2. Client calls, e.g, identify(signature) IPC method after binding.
> > 3.Serviceforwards it to webservice, which determines is it ok to continue.
> > 4.Serviceassigns client a session id on positive answer.
>
> > It would be totally up to you do you want to do whole identifying procedure as a separate thread, which returns session id viaServicecallback mechanism, or as a blocking method which returns it instantly. When it comes to safely dealing with client signature, and package signatures in general, goes beyondmyknowledge though.
>
> > --
> > H
>
> > On Dec 17, 2011, at 1:14 AM, Bsweet wrote:
>
> >> Ultimately what I would like to do is check the signature of thebound
> >> application.
>
> >> I want to have a mechanism where developers can register their
> >> signatures withmyservice, then I will check to see if their package/
> >> signature combination matches what I have inmywebservice.
>
> >> This is exactly what the Facebook Android application does for Single
> >> Sign On.
>
> >> I just can't find a clean way to get the calling application.
>
> >> On Dec 16, 8:46 am, Harri Smått <har...@gmail.com> wrote:
> >>> Hi,
>
> >>> I would go for a simple handshaking mechanism quite likely. You can let anyone bind to yourservicebut disallow usage of IPC methods for unidentified clients. E.g.
>
> >>> 1. Client connects toservice.
> >>> 2. After connection is established, client is required to call, say, identify() IPC method which returns a String, Integer, what so ever.
> >>> 3. After receiving this challenge, client has to call identify(result) method which gives client a session id.
> >>> 4. For all of the later calls client has to use this session id among with the call.
>
> >>> Quite obviously all this depends totally on how much security you're required to have within your client-serviceinteraction but some very simple handshaking protocol might work surprisingly well if it's kept secret.
>
> >>> --
> >>> H
>
> >>> On Dec 16, 2011, at 6:26 PM, Bsweet wrote:
>
> >>>> It is the spoof part that concerns me.
>
> >>>> Anyone else out there have any creative ideas?
>
> >>>> Right now I'm considering just checking who is on the top of the
> >>>> activity stack, but that is hokey and not reliable.
>
> >>>> On Dec 16, 4:30 am, Mark Murphy <mmur...@commonsware.com> wrote:
> >>>>> On Thu, Dec 15, 2011 at 9:54 PM, Kristopher Micinski
>
> >>>>> <krismicin...@gmail.com> wrote:
> >>>>>> When you get a bind in yourservice(your onBind) can you just take
> >>>>>> the intent and get component associated with it?
>
> >>>>>> From Intent:
> >>>>>> ComponentName getComponent()
> >>>>>> Retrieve the concrete component associated with the intent.
>
> >>>>> That should be the recipient, not the sender.
>
> >>>>> The only way I know to find out whoboundto you is if you require
> >>>>> that information in an extra, and that can always be spoofed. The
> >>>>> expectation is that you should not care *who*boundto you, merely
> >>>>> whether they had sufficient permissions to do so.
>
> >>>>> --
> >>>>> Mark Murphy (a Commons Guy)http://commonsware.com|http://github.com/commonsguyhttp://commonsware.com/blog|http://twitter.com/commonsguy
>
> >>>>> _Android Programming Tutorials_ Version 4.1 Available!
>
> >>>> --
> >>>> You received this message because you are subscribed to the Google
> >>>> Groups "Android Developers" group.
> >>>> To post to this group, send email to android-developers@googlegroups.com
> >>>> To unsubscribe from this group, send email to
> >>>> android-developers+unsubscribe@googlegroups.com
> >>>> For more options, visit this group at
> >>>>http://groups.google.com/group/android-developers?hl=en
>
> >> --
> >> You received this message because you are subscribed to the Google
> >> Groups "Android Developers" group.
> >> To post to this group, send email to android-developers@googlegroups.com
> >> To unsubscribe from this group, send email to
> >> android-developers+unsubscribe@googlegroups.com
> >> For more options, visit this group at
> >>http://groups.google.com/group/android-developers?hl=en
--
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
No comments:
Post a Comment