In this series of blog entries we will describe the development of a mobile chat app using SAP NetWeaver Cloud as a backend. The last time we explained how we realized push notifications. Now we want to explain how we enabled user authentication for our app.
In the past our web service offered all information you requested – e.g. you could access all chat messages as long as you know the right chat room-id. Of course that should not be possible in our productive version – that’s why we need authentication to give the users the permission to request only their own chat room messages.
Authentication on NW Cloud
NW Cloud uses SAP Identity Management to offer programmers an authorization API. You can read the details in the documentation. Using this API gives us not only the opportunity to do a password-check but also the possibility to access the user attributes maintained – e.g. the name of the user or his mail address. Currently there are two different types for user login possible: HTTP-Basic-Authentication and SAML. We were interested in using SAML because with this technique it’s possible to use a client certificate for logging in what we can use to enable Single-Sign-On. To understand our authorization solution we have to give you a short overview about SAML. SAML differentiates between three parties: The user requesting a resource (our web service), the Service Provider (our web service) and the Identity Provider (SAP Identity Management). When the user requests a resource from the Service Provider and he is not yet authenticated the Service Provider forwards the user to the Identity Provider. Here the user can log in using several methods (HTML form, certificate as mentioned above). After successful log in the user is forwarded to the Service Provider again that now provides the requested resource. The whole process consists of a complex token exchange between user, Service Provider and Identity Provider. When you are interested in understanding the details please see other references like wikipedia e.g.. It’s important to know that the whole authentication process as described above is based on forwarding using self-sending JavaScript forms. What is on the one hand a really good idea for people using web browsers is on the other hand a little bit tricky in our mobile scenario.
Our solution for authentication for our Twaddle web service
As described above we find ourselves facing a complex user-forwarding using JavaScript. We thought it would be a good idea to not change details of this process (the token exchange, the way the information is passed between Service Provider and Identity Provider and so on). That meant we had to find a solution where the forwarding with JavaScript works – we assume the only possibility to achieve this is to use a web container within our app. During development we saw that the forwarding between the web service and the Identity Provider takes some seconds – too long for our mobile scenario. That’s why we had the idea to do the authentication only once – when the user opens the app for the first time. He then authenticates against the SAP Identity Management using his credentials (or even a client certificate as described below) and gets a token. This token is unique for every user and is randomly generated. In the future every time the user connects to the web service he provides his previously received token. The web service can check whether he knows this token and of course which user belongs to it. So we have two advantages here: The web service can deny providing information when no valid token is passed and secondary it knows which user is requesting the information. Basically this idea is not new, a lot of apps use this approach. Google has created an interesting article about this technique.
To sum up this paragraph: We implemented an extra servlet whose only function is to provide new users an authentication token. This servlet is protected using the SAML authentication. All the other functions of our web service (accessing chat messages/all users, sending messages) use neither SAML nor HTTP Basic because the authorization process would take too long. Instead to consume the general web service functions you have to maintain an authorization token, which is unique for every user. Whenever the web service needs to know which user sends the request it can reverse look-up this token.
Our implementation of our approach in iOS
Because SAML authentication is optimized for browser interaction we have to look at the special features we have to enable in our app. The app has to be able to handle self-sending JavaScript forms and react with authentication challenges, so that we can provide our certificates to authenticate, if we want to integrate SAML authentication.
We thought it would be the best way to create a NSURLConnection with the URL of the web service but we figured out that NSURLConnection is not able to handle self-sending JavaScript forms. So we thought about using a UIWebView because it’s similar to Safari. The UIWebView is able to handle those JavaScript forms but the problem is that it’s not able to react with authentication challenges (unlike NSURLConnection). Therefore we created a solution, which combines the advantages of UIWebView and the advantages of NSURLConnection. First of all we provide the URL of the web service to the UIWebView and observe which page will be opened. Then we let the NSURLConnection open the page and wait for an authentication challenge. After that we let the UIWebView open this page. If the new page is a forwarding one we wait for the new URL and then stop the UIWebView again and let the NSURLConnection open the page and so on.
Just to summarize this part: We watch the UIWebView and wait what URL it wants to load, then we let the NSURLConnection do the real loading of the website. So the UIWebView parses HTML and the NSURLConnection does the real HTTP calls and reacts with authentication challenges.
We hope our explanation about user authentication was useful for you. Unfortunately this will be our last blog post regarding Twaddle for now. We always appreciate your feedback so please feel free to suggest any ideas of improvement.
Blog series overview:
Part II - Architecture and getting started
Part III - How our web service work
- SAP Managed Tags:
4 Comments
