Accessing OData endpoint of the Project Online 2013/Project Server 2013 in any custom mobile app requires some authentication mechanism. For accessing Project Online/Project Server 2013, you need to implement one of the below described authentication modes/method and also enable special permissions for the user who accesses OData endpoints via apps.
Authentication Providers
There are a variety of Security Support Provider Interfaces (SSPI) by Microsoft that are available for the authentication purpose. SharePoint users are most familiar with – Microsoft NTLM and Microsoft Kerberos. NTLM and Kerberos are the types of Windows Claims-based Authentication using Active Directory Services (AD DS) as the authentication store and user credentials validation.
Kerberos as a security support provider has been a part of Windows since Windows Server 2000 and was proposed as a replacement for NTLM. The two often work together or in a mixture across Windows environments.
Authentication methods for Android and iOS
Project Online 2013 and Project Server 2013 support multiple authentication methods and authentication modes. When you plan for mobile app access, you must consider the available authentication methods for the mobile OS.
1.Claims-based authentication with mobile apps
2.NTLM authentication with mobile apps
1. Claim based authentication with mobile apps
What is Claim?
A claim is a simple piece of information that describes a given identity on some aspect. A claim can be held in the authentication token like an envelope that may contain other identifying information and a signature that can be used to verify that the token is not tampered on its way from remote machine to your system.
Claim based authentication
Claims-based authentication is now a more general way of authentication, which allows users to authenticate on an external system. It is the process of establishing users’ identity and ensuring that the information is not tampered.
Courtesy TechNet library
Flow for Claim based authentication with app
1.Request to Project Online 2013 via web view
2.System redirects user to the authentication page of Office 365
3.After successful authentication to Office 365, it will return cookie and tokens
4.App validates the cookie and tokens
5.Once the token and the cookie is received, the app is able to access ODATA
2. NTLM authentication with mobile apps
What is NTLM authentication
It is the windows challenge/response (NT-LAN manager) authentication protocol used on networks that include systems running the Windows operating system and on stand-alone systems. In terms of the mobile app, an Interactive NTLM authentication over a network typically involves two systems: a mobile app, where the user is requesting authentication, and a domain controller, where information related to the user’s password is kept.
Un-interactive authentication, which may be required to permit an already logged-on user to access a resource such as a server application, typically involves three systems: a mobile app, a server, and a domain controller that does the authentication calculations on behalf of the server.
Flow for NTLM Authentication with app
1.A user accesses a mobile app and provides a domain name, user name, and password. The mobile app computes a cryptographic hash of the password and discards the actual password.
2.The app sends the user name to the server (in plaintext).
3.The server generates a 16-byte random number, called a challenge and sends it to the mobile app.
4.The app encrypts this challenge with the hash of the user’s password and returns the result to the server. This is called the response.
5.The server sends the following three items to the domain controller:
      1.User name
      2.Challenge sent to the app
      3.Response received from app
6.The domain controller uses the user name to get the hash of the password from the Security Account Manager database. This password hash is used to encrypt the challenge.
7.It then compares the encrypted challenge computed in step 6 to the response computed in step 4. If they are identical, authentication is successful.
Working with Project Online 2013
Accessing Project Online 2013 via mobile apps require some more efforts. You need to develop the header to access project server online otherwise it will return an unauthorized access error. To create a valid header, first you need to verify two cookies FedAuth and rtFa. If they exist, then create a new header named Cookie and add to your request, then after the GET request can be made to the server.
1.Write a code to read data from server
2.Set HTTP method as ‘GET’
3.Add another header Cookie and add both cookies ‘FedAuth’ and ‘rtFa’, which are required to access Project online
Working with Project Server 2013
To access Project Server 2013, app required to implement NTLM authentication. For iOS, there is already a library which provides NTLM authentication, for android either you can write a code manually or can use third party libraries like https://github.com/masconsult/android-ntlm
Accessing Project server OData endpoints with mobile apps
Now that you have finished with the complicated part, all you need to do is, write a code to access web service end points (OData endpoints).
OData API URL
To access OData, you also need the URL of Project Online 2013 or Project Server 2013 OData API. In most of the cases it will be:
/ _api/projectdata/
Try this URL with your browser to list the end points. Then use endpoints according your need.
Permissions required
To access OData services, you need to enable reporting permissions which can be found in global permissions.
Using $filter, $select and other oData query
oData queries can be used with a mobile app by ensuring that the URL you develop for query contains valid characters.
Conclusion
Using the above described method, a user can authenticate mobile apps (Android or iOS) to access Project Online 2013 or Project Server 2013. Users can also call GET web requests in the app to access Project Online 2013 or Project Server 2013 data like current project, resources, timesheet, tasks and assignment information. For additional HTTP verbs like PUT and POST, one needs to add some additional headers in the web requests.
