Azure offers a simple webapi proxying service that consumes authenticated requests and relays responses to clients.
We created the “rapmlsqa” portal for api management VIA THE AZURE CLOUD; where we see a default api – provided as an element of the ‘starter product’
We learn to invoke this api using the developer console. We also learned, first, to obtain from the management console “users” panel the subscription key for the “starter product”.
we see that the invocation requires a subscription key, even though no (proxy) security requirement is set.
The first use we make of AAD – and its oauth2/openid-connect handshake is for the purpose of user login to the management/developer portal site:
This gives us a signin experience setup for local account and AAD (rapmlsqa federated) login:
After the usual azure cloud login experience, we land on the site which has auto-created a (federated-local) account
back on the management site, we can exploit our admin privileges to modify the subscriptions to which the new user has access
we see that this new (federated user) – with its distinct subscription ids now – can invoke the API:
Of course, this is not an oauth2 handshake (to access the API). in realty terms, we have a portal that enables us to assign vendorids (to MLS federated users) and grant said user subscription power to certain APIs (eg RETS).
In the next effort, we WILL APPLY oauth2 handshakes between API CLIENT and API SERVER/PROXY