I want to publish my API, but I want to limit so users can only execute in sandbox environment (I want to limit production to specific user/customers with specific agreement).
This is a basic functionality in other API managers, but I don't find how to do in WSO2.
I have found this article in Medium, and also noticed that when I create an aplication, a couple of new roles are created (Application/user_application_SANDBOX and Application/user_application_PRODUCTION), but I don't find how to use them.
Deep dive in doc doesn't helped me.
Option 1:
You can use application registration workflow to control key generation for production and sandbox, by sending it through an approval process.
If you want to automate it based on a property or something, you can write a custom workflow extension.
However, this is applied to applications but not to APIs. That means if you allow generating prod keys for an application, all APIs, that the application has subscribed to, are accessible with prod keys.
Option2:
If you want to do this in API level, you can write a custom mediation sequence. Within the custom sequence, you can read the key type (i.e. production or sandbox), subscriber, enduser (if required) etc. and decide whether you want to allow the request or not.
Related
I have an ASP, vb.net, forms-based system. I want to allow people to use PDF documents created within that system to send them to DocuSign and out to others for signature. I have used the DocuSign SDK to build a system that works; however, I am concerned that I may not have the best setup for that.
The problem relates to the "open" nature of this system. Our users are allowed to see and modify all parts of the underlying system, including forms, coding, etc. As a result, a clientID and secret would be seeable to users. And that is concerning.
The system will need to be set to be easily used by our users. So, having users set up a developer account, setting up API settings, etc., will not be something we can reasonably expect.
It would be better if the system did all the interaction and they just had to log on to DocuSign to send the document out for signing. DocuSign has suggested becoming a partner in their referral system. I worry that will still require all the pieces (clientID and secret) that people will be able to see. But, I am not sure that is true.
Will being a partner mean we can avoid having those items saved in an open system where users can see them? Or does being a partner mean some of that is removed or not necessary?
Is there a better way of setting this up so that we can avoid all that mess?
There's no reason that all your customers wouldn't be able to use the same clientID (also know as Integration Key or IK) and secret key (clientSecret).
You will be the only one that can see/set them as the ISV. They will all use their own DocuSign accounts, using your IK. That is abosltuly fine and does not have any limitations.
We recommend ISVs use a single IK per app if it's the same code for the app even if they have multiple customers using the app.
I'm building a full-stack application with Next-JS. I'm building an API that works with Firebase. I was wondering if there is a way to make this API secure.
Let me elaborate. There is an option to your account called Premium. This variable is stored in the Firestore and will determine if you have purchased a Premium membership. This will determine whether or not you have access to certain features. I will use an API to change this variable.
I had the following in mind:
Have a button on the page to upgrade account.
Button pressed? Call to the API with the following params: email, upgrade to. This is because the same function can also be used to downgrade an account, for example when the user doesn't pay for the upgrade.
That API function changes the variable in the Firestore. It returns a status and a message.
I want to make option 2 more secure because otherwise, it would allow anyone to change the premium variable. That is obviously not what I want. Is there anything I can do about that? For example, a token system, the thing with that is that I have been thinking about that and I don't really know how to implement that and how it would work exactly.
For anyone wondering why I am using an API: I will also be creating an app, probably with react-native. The user will also be able to change their account status and interact with the API to do other stuff in that app.
Thanks for reading and responding! I hope this is at least a bit clear. If you have any questions, please comment them.
I do similar things in my app. I use Cloud Functions (which operate in a secure environment) to both save settings in Security-Rules -protected tables, as well as setting Custom Claims in the users Auth profile. All authorizations are then verified in the Cloud Functions before any changes are made - You may need to "seed" some values in a protected collection/document from the Console to get the process started.
Is it possible to build and deploy an agent available only for some users , like for example a company, or limiting access ?
It depends on exactly what your needs are.
While not exactly what you are looking for, you can deploy an Action to Alpha test status. This lets you make it available to up to 20 users without going through the review process.
Additionally, you can deploy it to up to 200 users if you deploy to Beta. However, this still will require a review by the Action review team.
If you need more than this (and probably a wise idea even in other use cases), you'll need to use Google Sign in for Assistant or other identity methods to get the identity of the user and then determine if this is an authorized user as part of your Action. This will require review by the Action review team.
I am trying to write an app that, upon receiving the credentials of an Azure user, will be able to show him various pieces of information using the Azure billing apis.
However, the following git sample that shows how to use one of those apis, lists a series of steps that should be done in the Azure cloud platform in order for things to work, and these steps need to be done by the user himself. Specifically, step 1 talks about registering an app and configuring it so that it has access and permissions to use the apis.
Only after those steps, will I be able to access the billing apis and retrieve his information.
Seeing as how I don't want the user to have to do anything after he gives me his username and password, is there an API or some other automated way with which I can register my app to view his account?
https://github.com/Azure-Samples/billing-dotnet-usage-api
Ideally, I would want some sort of imaginary code that maybe looks like:
someObj obj = someAPI.loginToAzureWithCredentials("123456", "someUserName")
obj.registerApplication();
Obviously the "code" is very lacking in details, but it's just for emphasizing what I'm searching for.
I want to make an option such that I can issue 3rd part developers access to my data and to do so, similar to the following: https://docs.sharedcount.com/, I want to create a system wherein those developers are provided an API key for which the consumption count can be monitored
Came through Waterlock but does not look like it has this feature: http://waterlock.ninja/
Curious, what would be the best approach to implement API keywords for a Sail.js app?
Sails makes this incredibly easy by use of policies. When a user signs up, assign them an API key, and then create a policy that checks the params for a valid API key -- i.e. req.param('APIKey') -- and deny access if one is not found.