I try to use composer to develop a block-chain web app.
I write the ".acl" file to implement access control, and I also issued different IDs to different participant, then I start the REST server.
The next thing I want to ask is, how can the REST server identify my identity?
Just like, one kind of participant is named "trader", I specify "trader" cannot access function "A" in chaincode, but REST server generate the API of "A", then I write a simple html file and send a POST request to localhost:3000, I can invoke this function directly. I even don't know I access this interface by what kind of identity.
I am confused about this, can some one help me?
Remember how you started the REST server? You had to specify a business network card, and likely it was the card for the admin with all reading and writing rights. Also most likely, you disabled authentication with passport.
With these two elements, of course you can always do anything just by calling any available API function.
You can refer to the passport authentication instructions for composer-rest-server to implement your authentication scheme.
You should code the rules for what is allowed for certain groups (such as "patients", "doctors", "payers") in the ACL permission files. Refer to the section "Granting Network Access Control" in https://hyperledger.github.io/composer/latest/reference/acl_language, which contains some pretty similar examples.
Illicit API calls would then simply fail if attempted by the wrong entity.
Related
I have API backend and it will be consumed by different consumers like our own company website and even other website can use our API with certain quota/limitation and for this scope management we will be using express-gateway(eg), however this is not the only reason I am using express-gateway(eg). Now coming to my problem/miss-understanding, for our own website we can create api-key and user credentials using eg command. But for the other user who wishes to use our api, I don’t want them to contact me for this integration, rather they should be able to create a user credentials and API key themselves using some facility (let us call it key management) provided by us. Here I am stuck how to give a web platform or any other mechanism where a user can create account and then create api-key for their own website. I was thinking to extend the express-gateway app itself and create page where a website owner can fill the form with various input field that will serve as parameter for eg command and I can trigger eg command in node console and create credentials and save it in redis database and then fetch those information to show it to user as their use rid and api-key. But I want to know the best way how others are doing, like how google, twitter and many more are allowing to create api-key, delete key and regenerate the api-key on compromise. Some suggestion would be to use third party tool to manage user-credentials, I will have little inertia to accept that, even if I do so how will I hook those third-party solution to my express-gateway.
In general, API gateways and authentication servers are independent, or at least loosely-coupled. The typical workflow is:
A user browses to the Create Account page for a service.
The user creates an account with the authentication server
The user makes a request through the API gateway
The API gateway checks with the authentication server whether the operation is allowed, discarding it if the user is not authorized to perform the requested action
The API gateway dispatches the request to the appropriate server
The receiving server checks whether the user is permitted to perform the action (in case the API gateway has been compromised)
Express Gateway includes its own authentication server for convenience, but the steps are basically the same. The difference is that one uses the Express Gateway Admin API to create the user and credentials rather than going to a different server.
Note that Express Gateway and its default account database (reddis) are not persistent out of the box.
I'm using Password Grant flow in my Laravel api but i find that the tokens generated to the user may be abused.
I have the api running in a domain and a web app in another domain consuming it. I want to make sure that even if someone copy the token from the Localstorage inside my app, it will be useless outside of my consuming domain.
The only solution i find to this problem is by checking the domain with a middleware or inside the Api methods. Is there any secure way to do this? Should i use middlewares as i just mentioned?
To be honest, I don't think there is a way that you can prevent this.
I assume that the web app is using clientside code to get your API, and so the IP address will always be the clients, and so you cannot limit your API to specific IPs.
Additionally, the calling domain is useless as you could fake this in postman or any other API sending tool.
This is a fight you won't easily win.
I'd ask the question of what ways can a user really abuse my API. If they want to use their token to perform actions on their account inside your application, then what does it matter if this happens within your application or outside of it?
How can they abuse your platform if they have the token? If there are ways to abuse it then you are better treating the root cause that allows the abuse to take place, rather than trying to limit how the token can be used.
I Guys, i have to create a mobile app that need to make a request to a laravel endpoint, app no require registration or login, which is the best way to protect my api? To make sure the only my application can call it?
Thanks!
There's no full proof method of securing your api, because with the right tools and following some tutorials on the web, anyone could view your whole api request, headers, tokens, etc.
Anything you do or store on the app is already compromised, so signatures,ssl, encryption,tokens, etc are not that helpful if malicious users have access to the app. It can make it more troublesome for malicious users, but a dedicated one could overcome it.
Using authentication atleast forces users to register before they can use your api and you can block the user when needed. Along with requiring email verification, users who wish to misuse your api would then need valid email addresses atleast. But since you mention securing without authentication, this goes out of scope.
You can secure your api somewhat by using rate limiting. laravel has an inbuilt rate limiting with the throttle middleware. You can use this to restrict the number of times an api can be called in a particular time interval by an ip address.
Next would be Ip blocking. If any malicious activity is found, you could block the ip address. But this can be overcome with a vpn, and a malicious user could also block someone elses ip in this manner.
Captcha can help against bots, but would also annoy regular users.
Another method would be restriction with cors, those who have faced cors issues know exactly how annoying it can be, but it wont work on native apps (or you could try pwa).
And in a worse case scenario you could go with some terms and conditions and some legal action
A simple solution You can create a table for devices with api key which will be generated for each device app, and always use it to send requests to the api end point, then used it to fetch data from the rest api. The same process like if you are loging in, but you will use the api key unstead and the key will be fixe not refreshed evrey time.
I'm faced with a difficult scenario regarding OAuth 2 authentication and Google's Calendar API.
I am attempting to write a PHP script which processes my personal calendar data after being triggered by a POST call from an external source. However, I am having trouble granting the script access to my account. Since the script runs entirely in the background, there is never an opportunity for me to enter the authorization code which is required for PHP command line tools making Google API requests.
I have looked into Service Accounts, which grant access to personal data without individual approval, but unfortunately this is only available to G Suite users, which I am not.
I have also attempted to run my script manually, enter the code to authenticate, then run it from my external source. This doesn't work either, because the authorization codes are apparently only good for the same mode of access where it was entered, and the response to the external source still shows as asking for the code.
Lastly, please note that responding with the authorization code from the external source is not an option. Which I can activate the trigger, I cannot change how it works or the data it passes.
TL;DR: How do I grant a PHP script (which runs only in the background) access to my personal Google Calendar data?
Thanks in advance!
Articulating this question actually helped me better formulate my Google searches, and I found the answer!
I'll leave this question/answer here so somebody can hopefully benefit from it -
Turns out that the Service Account is the way to go, but instead of trying to access your account's data via the service account, you need to share the calendars in question with the generated service account email address. Essentially, this makes the service account a "co-owner" of the calendar. Then, you simply make the request to the service account's own information.
Hope this helps!
I've got a project made of two websites:
The front : A Laravel website without database and logic (just showing static pages and my javascript)
The API : A project using Lumen/Dingo API with my endpoints, my database, my logic and my models
I want to allow my front to ask data to my API depending the user.
Ex. I want to log the user, retrieve his friends, add some post to his
account, etc. (from the Javascript)
What is the best solution?
Using an identification per user (using o-auth or JWT)
Allow my front project to ask to my API then each javascript call needs to use my front without knowing my API) (In this solution I need to create routes similars to my API's routes)
Identification per user is always a better solution as the claims can be decided per user, also in future when it is required to provide permissions to access API based on claims or roles, it becomes easy to give information using the claims and amount of access you can give to a specific user.
So the way it will work is:
There will be identity server which will be containing the list of users in the system, and also the clams and scopes per user.
The API project will trust the identity server, that means any token provided by the identity server can get verified.
Based on the token per user your API app can decide how much information you want to give to the user.
That way in future you can have methods based on roles, claims and users will be provided with only the information that they have access to.