Hi, AFAIK there is no way to determine calling application from your Service automatically (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 Android Service.
Now, if you have a web service, 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. Service forwards it to web service, which determines is it ok to continue. 4. Service assigns 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 via Service callback 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 beyond my knowledge though. -- H On Dec 17, 2011, at 1:14 AM, Bsweet wrote: > Ultimately what I would like to do is check the signature of the bound > application. > > I want to have a mechanism where developers can register their > signatures with my service, then I will check to see if their package/ > signature combination matches what I have in my web service. > > 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 <[email protected]> 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 <[email protected]> wrote: >>>> On Thu, Dec 15, 2011 at 9:54 PM, Kristopher Micinski >> >>>> <[email protected]> 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 [email protected] >>> To unsubscribe from this group, send email to >>> [email protected] >>> 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 [email protected] > To unsubscribe from this group, send email to > [email protected] > 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 [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
