>-----Original Message----- >From: [email protected] [mailto:qt-mobility- >[email protected]] On Behalf Of ext Srikanth
>I am working on a project that uses services framework introduced in qt >mobility. I have a requirement wherein only few service clients with a >specific "permission" or "capability" can access my service. I see two >classes namely QServiceContext and QAbstractSecuritySession that are >passed in >QServicePluginInterface::createInstance(). I think i need to use the >mentioned classes to filter which clients my service should serve. One >possible solution I thought is using QServiceContext as follows (It may >be a dumb approach, plz correct me) >- Service and Clients share a unique identification key and clients fill >it in QServiceContext::setClientId() ans Service verifies it in >createInstance and serves if the key matches with the shared key. In principle your approach can work. However the security aspect is not very great since such a shared key would have to be encoded in the service binary. A hex editor will always reveal such strings. Therefore the question is how secure your identification should be. A partial alternative might be to use a cryptographic hashing mechanism. Rather than sharing the ident key you could put the passed key through the hashing algorithm in sinde the createInstance function and compare the result. It would be similar to the passwd mechanism on *nix platforms. Of course you client would still have to know the clear ident. The assumption is that at least your service plug-in is somewhat secure from hex editor attacks. >Another way is to mention <capabilities> in service description xml and >use QAbstractSecuritySession. But none of the examples provided with >QtMobility 1.0 or sdk docs describes how to use QAbstarctSecuritySession. >It will be really useful if a complete description of >QAbstractSecuritySession usage with a example. The abstract security manager is used by some Nokia applications (CWRT) for the same purpose as your question indicates. Those applications provide their own implementation for QAbstractSecuritySession. The passing context ensures that session object can be trusted upon. The actual service's client is some sort of html script which must execute in a trusted environment and requests a service. Based on the script signature the trusted client process creates the sec session which the service can rely upon. Since I don't know what security parameters you have this may or may not work for you. In any case you'd have to implement it. In general you can attach any meaning to the mentioned two classes. Simply consider them as some form of information carrier (or generic/low-level enabler) between service and client. In what you make use of it is up to you. The context object is probably more geared towards simple information transfer whereas the sec session has the additional option of carrying implementation details to the service plug-in (the virtual function isAllowed() is called by the QServiceManager before the service plug-in is even loaded - as part of loadInterface() call). -- Alex _______________________________________________ Qt-mobility-feedback mailing list [email protected] http://lists.trolltech.com/mailman/listinfo/qt-mobility-feedback
