4 votesunder review · 2 comments · API Management » API management experience · Flag idea as inappropriate… · Admin →
13 votesunder review · 0 comments · API Management » Developer portal · Flag idea as inappropriate… · Admin →
To get integration stated, we’ve added links to Aqua and Twistlock from overview within a configured registry.
Over time, we’ll provide a more integrated experience, where ACR has vulnerability scanning integrated into the image listing.
We’ve started the design, and would welcome any additional feedback.
Based on all the great feedback, we’re adding token based authentication to the repo-based permissions capability. Customers can configure time based tokens, for access to specific repos, with RBAC.
We don’t have an ETA yet, but we expect to be in preview by this summer.
We’ve started the Auto-Purge work, with this current design: https://github.com/AzureCR/specs/tree/master/auto-purge
Please provide feedback here: https://github.com/AzureCR/specs/issues/1
This is not planned for the next 6 months, but is on the roadmap.
Just to provide an update, we are close to launching a private preview. We are in the final testing stages for this feature. We will have another update in the next few weeks with instructions on how to join the private preview.
Thank you. We will examine the experience of duplicate sign ups across Identity providers. Would performing this check by using the email address be sufficient?
BTW, Linking multiple provider accounts to one user is in our roadmap and we’ve already achieved it in preview…
We look forward to your feedback
Due to various technical limitations, the first iteration of the customer-owned domains functionality will not be available for a few more months. We will provide an update as soon as we can get a more specific ETA.
We have released the public preview for this feature! Learn more about how to use it here: https://docs.microsoft.com/azure/active-directory-b2c/active-directory-b2c-setup-oidc-azure-active-directory
We continue evaluating several alternatives to provide full email customization. We are actively working on an alternative.
Unfortunately we do no yet have an ETA.
Thanks for the feedback. Please clarify the request by providing an example.
If custom sections could be added based on a critiera (group membership or product of subscription) then the following could be helpful to the developer.
The primary use case I have would be around stating the rate limit thresholds for either a particular product or group of users, e.g. Production has X rate limit, Staging has Y rate limit, or group A has X rate limit, group B has Y rate limit.
This capability would keep more documentation about the API and its uses in the APIM portal and accessible to the developer instead as tribal knowledge and prevent it from being global knowledge.
As a secondary note, I'm not sure this capability exists today, but the ability to use Properties within the docs would be nice as the rate limit is most likely a Property and could be imported into the docs so that when the Property value is updated then the docs would also be updated. Maybe not with replacement but with custom markdown support for pulling the property value
Thanks for the feedback – be great to get continued input on this. Keep the votes coming!
I'd also agree, if we could deploy an Azure Public IP as a reservation and then bind the service to that then we'd have further assurance that just redeploying or changing the networking wouldn't change the public IP.
I think this is less of an issue for internal vnets as I typically scope the entire subnet range for network ACLs.
Yes. We are moving from an APIM instance per environment to a developer instance and a production instance. We are using products to manage the environment relationship and policies in the product scope to change the backend systems. This is fairly cumbersome with multiple products, e.g. consumers and then needing 1 to N versions of that product, one for each environment.
The con of this approach is that we don't really have a good test bed for trying changes outside of the developers unless we let the other developer teams use the developer instance, which is not what we want as it impacts their stability during their development efforts.
What this model does help us do is be much better about the changes since the changes could impact production. Things like understanding the impact on changes to APIs and the need for versioning as well as better test plans for the dev instance are necessary for success instead of nice to haves.
318 votesunder review · 13 comments · API Management » Developer portal · Flag idea as inappropriate… · Admin →
Having the ability to scope an operation to a group would be helpful. Use case would be a Support API that has commands that Level1 support teams can use and Level2 support teams can use other operations but they are all the same API. Today I would have to have a Level1 Support API and a Level2 Support API and use products to control which one sees which API.
This feature would let me have one Support API and visibility to the operation would be managed based on the group, defaulting to "Developers" of course. This could also be handy in providing "Developer" API operations and "Guests" API operations, e.g. a heartbeat / service status API could be available to "Guests" so anyone good see that visibility, but deeper interaction on the monitoring API could be provided to those with the Developers group.