Mobile apps have grown in popularity thanks to the huge success of Apple’s app store. Every other mobile platform including Apple is providing sdk’s for developers to build mobile apps for respective platforms. These include the likes of Blackberry, Windows Mobile, Symbian, palm and the latest kid on the block Android. While some of the apps are an extension and similar to what one would experience accessing on a PC/ laptop using internet browser others could be a hybrid version. A hybrid application are one’s that uses best of both the worlds; it has accesses resources over the internet by calling web-services and use native api’s of the platform to perform some form of client side processing.
Developing a hybrid app for different platforms or different versions of the same platform can be a challenging. It is interesting to note how different platforms have been selective in exposing native api’s for developers to use and build mobile apps. There could be quite a few reason for such limitations, speed to get a sdk out in the market, possible hardware limitations, third and probably the most important security. Like in the PC world, mobile these days carry huge amount of user specific data that needs to be secured, it could be your mobiles phonebook, emails, text messages or even location where you are at any given point of time as your mobile is sending signals to the nearest mobile towers.
Security is key when a mobile app is being used to access enterprise applications such as email servers, ERP applications, salesforce application etc. One way to ensure high-level of security is using two-way authentication. In two-way authentication it’s important for a client device to share its certificate that’s authenticated at the server before establishing a secure connection to exchange data. Two-way authentication is a 2 step process – certificate enrolment and authentication. Certificate enrolment is a 4 step process, client (which is the mobile app) request for a root certificate from the host. A root certificate needs to be a trusted certificate, typically signed by 3rd party certificate authority (CA) such as Verisign. Once the Root certificate is received, the application generates a CSR (Certificate signing request) that is sent to the host. A CSR typically contains device level information (such as UUID, MAC address, MCEI code etc) and user specific information (user name & password) and passcode identifier. The information exchanged through CSR is the enrolment information that helps identify the user. The CA server extracts the passcode from the CSR to cross-check with the back-office. Once the passcode is confirmed, the CA issues a client certificate that is delivered back to the device. The user specific information is stored in the back-office for future verification.
Once certificate is enrolled the authentication process kicks-in, the mobile app shares the client certificate with the host server, prior to exchange of sensitive data. The host extracts the user specific information from the client certificate to verify the identity if the user information exists in the back office database. Once verified, client and the servers have confirmed their identities and are now ready to initiate exchange of sensitive data over a secured connection.
Ajay Vijh
No comments:
Post a Comment