Is it possible to use Principal Propagation to call Workflow REST APIs using type-safe client? The way provided is via client credentials. Is there any plan to support principal propagation in the future?
https://sap.github.io/cloud-sdk/docs/java/features/rest/clients/scp-workflow-rest-api
Yes, it is possible to use the Principal Propagation Authentication flow to call the Workflow service while using the type-safe workflow client.
However, you cannot use the ScpCfServiceDestinationLoader to create the destination programmatically in this case. Currently, we only support client credentials flow with the loader.
Instead, you should create a destination in BTP(CF) with OAuth2UserTokenExchange authentication type and then subsequently use DestinationAccessor to fetch this destination.
We are evaluating options to extend the ScpCfServiceDestinationLoader API to support other authentication types but have not planned this feature yet.
Update: This has changed with Cloud SDK version 4.7.0. You can now use AuthenticationType.OAUTH2_USER_TOKEN_EXCHANGE with ScpCfServiceDestinationLoader.
Related
I have one use case to call on-premise REST API via Cloud Connector. It is a custom API in SAP R/3 system. I checked with API developer and unfortunately they have no OpenAPI specification for it. Thus, I could not use OpenAPI generator to generate library.
Is there any other way to call on-premise REST API in such scenario like native call with connectivity service? We might have some more use cases with the same situation in future.
Is it possible to provide a generic REST client similar to OData?
For your use-case you could leverage our HttpClientAccessor to instantiate a HttpClient.
HttpDestination destination = DestinationAccessor.getDestination("my-destination").asHttp();
HttpClient client = HttpClientAccessor.getHttpClient(destination);
HttpResponse response = client.execute(your-http-request-here);
You can read more details here
I am new to Azure API Management and will be happy to receive suggestion and advise on my implementation.
I am developing a B2B Api Channel for 3rd parties to call my services via the API Management (APIM) Gateway. On the APIM developers portal I can onboard new clients and generate API key. My struggle is how best to figure out at the underlying services who is calling?
I have considered add the API Key generated in the APIM to a database which the underlying service will call to authenticate, however, the implementation will be manual and will not be in sync when the 3rd party client goes to APIM and regenerate a new API key.
What I want is a solution that auto syncs authorization and authentication between APIM and the underlying services.
Since API keys can be replaced, you better rely on IDs to identify clients.
You can pass a client ID to a backend in a header: https://stackoverflow.com/a/42277313/2579733
Now how do you correlate APIM's client IDs with your backend's client IDs?
If there are only a few clients, you can probably update that association in your backend's database manually. If you can use the clients's email to connect the APIM client and your backend client, that's even easier (you're done).
If you will need to register many clients and the manual approach is not feasible... One way to do it is with Delegated Authentication:
Delegation allows you to use your existing website for handling developer sign in/sign up and subscription to products, as opposed to using the built-in functionality in the developer portal. It enables your website to own the user data and perform the validation of these steps in a custom way.
I never used it but it seems you can transfer the responsibility of creating new clients to a backend service (developed by you).
This way you have access to client emails, you generate IDs and can store the ID relationship in the backend as necessary.
So, I have an API in Azure-API-Management, which is attached to a function. I want to expose one the method in API as Web-hook for another application CRM. It will be an inbound web-hook.
Is it possible ?
A webhook endpoint is like any other HTTP endpoint that usually expects a POST request from an external system. So, yes.
Depending on the CRM Application, you could leverage APIMs built-in security features to authenticate the webhook call without having to validate credentials in your function as a bonus for using APIM.
I have configured Azure Application Insight for monitoring our systems and was trying to enable the alerting. I'm using app insight availability test which provides a functionality to call a webhook URL.
I wrote a webhook using HTTP triggered Azure function, but the problem is it exposes a public URL which if called will raise an alarm on our internal alerting system. So I plan to authenticate the call to webhook.
Is there any way I can authenticate the call possibly using OAUTH.I don't want to provide the token in URL, looking for something secure. Another problem with manually using token in URL is that token rotation will require manual work.
Any suggestions on I can automate this task which will take care of secret rotation will be appreciated.
I believe token based authentication is the only possible route as of today as documented here.
But I think you should still be able to use a Function App without worrying about key rotation since the function keys can be read through the Functions API if the AzureWebJobsSecretStorageType app setting is set to files as documented here.
I'm making an iOS/Android app using Xamarin (not Xamarin.Forms, just regular Xamarin). I'm using the shared library set up rather than PCL. I want my app to call an Azure function but I'm unsure of the safest/best way to handle this. I have it set to "Function" for the "Authorization level". The test URL includes the "?code=..." portion in it. I was under the impression that if I put that in my C# code with the "code" value exposed that it was considered a bad idea from a security perspective.
I'm lost as to the safest/best way to deal with this. I've read that setting it in app.config is also a bad idea. I found some references for a web app that suggest using the connection strings that are available in the azure portal, but since this isn't a web app, I'm unsure of how I'd actually retrieve those values in my code (or if that's even possible).
So how would you suggest I handle setting the value for "code" so that I can call my function and avoid a security problem?
UPDATE: Providing more info as per request:
I'm using MSAL to authenticate my users with a B2C active directory. I already have that part working and have received a token authenticating the user.
I also just now enabled authentication in my functions.
I was under the impression that to call my function from my mobile client I had to make a new HttpRequestMessage. I'm unsure of then what I'd place in it to pass my token along.
Just to make sure I understand, your concern is about embedding secrets (the ?code=XXX value) in your iOS/Android app, correct? If so, yes, this is generally considered bad security practice. It's best to assume that anyone who can download your app will have the ability to discover these secrets and use them any way they want.
The recommended way to authenticate with a backend service, such as Azure Functions, from a mobile device is to use interactive authentication - i.e. some kind of OAuth flow. You can build it yourself, or you can use the built-in functionality of Azure Functions and Azure App Service to help you (Azure Functions is built on top of App Service). Here is a resource which might be useful:
https://learn.microsoft.com/en-us/azure/app-service/app-service-authentication-overview
https://contos.io/working-with-identity-in-an-azure-function-1a981e10b900#.vcjit3ntw
The API Key (code) is indeed not meant to be used by clients you distribute externally, so it shouldn't be used by your mobile app.
The most straight forward option here would be to use the built in App Service Authentication features with Azure Functions and implement an authentication flow in your app, which would allow you to securely authenticate the user.
Sharing more information about your scenario may help identify alternatives.