we want to develop a Phonegap driven web app for our end users so that they can access and modify their personal data on our library management system (LIS) via it’s REST API endpoints. Since the only two layers of security provided by the LIS are API keys and a generic Access Management on the API Level we feel that we need to improve the security a lot.
Below you’ll find our work-in-progress definition of what a secure access to our LIS API means for us. It would be great if you could skim it and give us your opinion on whether this would be doable with the Dreamfactory Service Platform (DSP) and if our ideas can be called “secure” at all.
An ideal secure(?) request from our app via DSP
Initial Request from the mobile app (client) to DSP with an API Key provided by DSP during definition of custom service endpoint. This will be stored somewhere in the source code of the client. Furthermore a username and password provided by the users through a normal web form are send along with the request.
The DSP evaluates the incoming API Key. If it’s valid it performs step 3. Otherwise it sends back an error message to the client.
The DSP issues a request to an external authentication server (in our case CAS) with the username and password provided by the request in step 1.
If the DSP receives a positive response from the authentication server it proceeds with step 5. Otherwise it sends back an error message to the client.
The DSP creates an access token and sends it back to the client.
The client now makes the necessary request(s) using the access token.
The DSP checks if an access token is present and if it is valid (regarding it’s syntax and expiration date). If the access token is valid the DSP routes the request to our LIS API with the necessary API key for the LIS API that will be pulled in from a lookup key stored on the DSP. If the access token is not valid (e.g. has expired) the DSP sends back an error message to the client.
Skimming the DSP documentation it seems that we’ll have to recur to Server Side Scripting (especially for step 3 and step 4) and implementing oAuth (step 5).
Hey - thanks for reaching out. I want to ask you a couple of questions in order to try and understanding more of what you’re trying to accomplish.
Are the users in this scenario stored in CAS or the DSP?
Do you want users who are on the DSP to make service calls against CAS system? Or is it the other way around?
In the OAuth blogs that Jerry’s written - the actual Oauth token is generated by Facebook, not the DSP. In this case, it would be CAS generating the token, or is it your expectation that the DSP will generate the access token?
thank you for your response and sorry for my late reply but I was away on holidays.
Regarding your questions:
All users are stored in CAS. I basically want to handle the interaction with the CAS Server via it’s REST API using DSP server side scripts (here a short description of the CAS REST API http://jasig.github.io/cas/4.0.0/protocol/REST-Protocol.html).
All the App should do is issuing an initial HTTPS request to the DSP with the username and password to start the DSP <-> CAS interactions. If successful the DSP gets a service ticket from the CAS. This service ticket is saved locally in a DB on DSP level and passed back to the App.
This services ticket is then used by the App to issue all necessary requests to the final API-Endpoint through the DSP. where a service ticket validation is performed and the API Key of the final API-Endpoint is appended to the request.
No worries on the late response, hope that you had a good vacation. I’ve looked into this issue and believe that phpCAS is the answer to your question. If you don’t mind taking a look at that link, integration instructions are seemingly straight forward, though if you do have an issue please let me know.
thank you for your response. That is exactly the workflow. But instead of performing it on the App level would it be possible to implement it on the DSP level through server side scripting?
thanks very much for your answer. Right now I’m still in the planning process. As soon as I will start to develop something and hit some road bumps I will come back to the forum.