I'm exploring WSO2 API Manager platform to use in Open API project. The idea is that we forbid registration in Store and creating users by ourselves. But we also want to give them only Sandbox API as a starting point and then, explicitly allow particular users to consume Production API. Haven't find any information. Is it possible? If yes - where to look?
You can restrict the token generation for the Production endpoints by using Workflows. Follow the documentation[1].
You could configure ProductionApplicationGeneration to use ApplicationRegistrationWSWorkflowExecutor and SandbobApplicationGeneration to use ApplicationRegistrationSimpleWorkflowExecutor.
With this approach if the subscriber tried to generate a token for production endpoints, it will trigger a human task, which needs to be approved from the Admin Portal.
For your requirement, you could write a custom workflow extension which allows restriction by role or user name. For more information on Writing custom workglow extension please follow [2]
[1] https://docs.wso2.com/display/AM210/Adding+an+Application+Registration+Workflow
[2] https://docs.wso2.com/display/AM210/Customizing+a+Workflow+Extension
Thanks and Regards
Related
How to add Azure custom Policy for Azure Data Factory to only use Azure Key Vault during the Linked Service Creation for fetching the Data Store Credentials instead of credentials being put up directly in ADF Linked Service. Please suggest ARM or PowerShell methods for the policy implementation.
As of yesterday, the Data Factory Azure Policy integration is available which means you can now find some built-in policies that can be assigned to ADF.
One of those is exactly what you're asking for as you can see in the image below. You can find more information here
Edit: Based on your comment, I'm editing this answer with the info you want. When it comes to custom policies, it's pretty much up to you to come up with them and create what fits your needs. In your particular case, I've created one policy that does what you want, please see here.
This policy will audit your data factory linked services and check if they're using a self-hosted integration runtime. Currently, that check is only done for a few types of integration runtimes (if you look at the policy, you can see 5 of them) which means that if you want to check more types of linked services, you'll need to add them to the list of allowed values and select them when assigning the policy definition.
Bear in mind that for some linked services types, such as Key Vault, that check won't make sense since that service can't use a self-hosted IR
Currently, I'm working with 2 apps where user can generate a payment token associated with their account. 1 uses the Secure Acceptance Hosted Checkout and the other uses Flex Microform. 1 possible case involves the user's card being captured via the Microform and then later updated via the Hosted Checkout.
The docs mention being able to replace the billing info associated with the Flex token, but it's unclear the mechanism available. I'm aware that the Hosted Checkout supports updating this info, but it's preferred to make the update without prompting the user via the Hosted Checkout so the user never needs to see the default address or require putting in their address twice. Is there an endpoint that can be uses to achieve this?
I don't know if it's the intended way of doing things for cybersource, But there is a soap service named "paySubscriptionUpdateService" in the simple order (soap) api that allowed me update the name & address on a token generated via the flex api.
You can take a look at the simple order API documentation on cybersource website - chapter 7 "Updating a subscription"
https://developer.cybersource.com/library/documentation/dev_guides/Recurring_Billing/SO_API/Recurring_Billing_SO_API.pdf
I'm sure there is a way through rest API too, I'm not sure how to do it yet. I'll circle back if I see something
Ex: Lets assume I have a 'Calculator' API and it has below operations/definitions.
1.addition
2.multiplication
I want restrict user with addition operation and remaining operations should not be visible/access in store console.
Is there any way to achieve this?
You can restrict the access for each resource by configuring scopes for each resources. If the user has access token binding to the particular scopes only can invoke the resources restricted with the scopes. Documentation has detailed useful information regarding this - https://wso2.com/library/articles/2017/01/article-an-overview-of-scope-management-with-wso2-api-manager/
I have successfully deployed a Google Cloud Endpoints Developer Portal for my API running on Endpoints. I would like to provide access to testing to people outside my organisation that are not using GCP in their projects.
Login to the portal works correctly if I enable the Service Consumer role for these people (on per-email basis). However, when they open it for the first time, they are being asked to grant some extra permissions to the portal:
This form can create totally unnecessary security concerns. Does anyone know, why is it needed?
I only would like my clients to be able to test my API using a GUI, before they could start connecting their projects (not necessary on GCP) to mine. This seems to be a valid use case for me, however I might be misunderstanding some basic concepts.
Or should I submit a feature request to Google about a new role that only enables the access to the portal, and nothing else, so no such forms are shown?
Since Endpoints APIs must be explicitly shared with customers, the portal needs to verify that the logged-in user has permission to view that Endpoints API. So the short answer is that these scopes are being requested primarily so the portal can check the user's access to this API.
Longer answer is that we (the Endpoints team) are looking into if it's possible to build narrower OAuth scopes that would correspond to the access checks we perform. We agree that it's unnecessarily broad of an access request and are hoping to improve this in the future. Thanks for your comment!
The Conduit API in Phabricator does not support setting of authorPHID parameter while calling maniphest.createtask. I can imagine this is because of security or some logical reason.
But I am developping my own frontend for Maniphest where the users (logged through Phabricator, so they are phab users and have phid) will add and edit tasks. What I need is that if a user creates task, he is also the author of the task.
But the problem is, that I can't connect to Conduit as any other user than "apibot" because I don't have others certificates in my front-end to do it. But if I log in as "apibot", then "apibot" is set as an author of the task.
Three possible solutions came to my mind:
1. retrieve certificate directly from phab's database
2. keep a list of certificates in some file in my front-end and update it manually everytime somebody will register
I guess none of them are really smart...
The third solution would be nice, but I didn't find a way, how to do it:
3. log in as "apibot", get certificate of userXY and then log in as the userXY
What would you suggest?