I have a requirement to add trailing slash to the APIs hosted in APIM. However, APIM gateway seems to be removing the trailing slash when forward the call to backend service.
Example 1:
APIM Gateway URL: https://api.domain.com/getdata/
Backend service URL: https://mybackendservice.domain.com/getdata
Example 2:
APIM Gateway URL: https://api.domain.com/getdata/?q=1&r=2
Backend service URL: https://mybackendservice.domain.com/getdata?q=1&r=2
Can someone please suggest any URL rewrite policies we can add to retain the trailing slash, so that the backend service urls would be:
https://mybackendservice.domain.com/getdata/
https://mybackendservice.domain.com/getdata/?q=1&r=2
Thank you Vitaliy Kurokhtin ,Posting your suggestion as an answer to help other community members.
"Let's say you have APIM service with hostname my-service.azure-api.net. An API in APIM service with URL suffix my-api, and a backend URI of https://my-backend.com. And an operation in this API with URI template of my/uri/template.
So for an incoming call to
https://my-service.azure-api.net/my-api/my/uri/template
without any additional configuration APIM service will make a call to
https://my-backend.com/my/uri/template
Because by default APIM service replaces in source URI scheme+hostname+api suffix with backend URI defined for an API in question.
In most simple case when your API has only one operation you could set API suffix to api/v1/storenumber/ordernumber and operation template to /. That would result in public facing URI of https://api.example.com/api/v1/storenumber/ordernumber
and backend URI for this operation of
https://back-end.service.com/
Of course this is approach is harder to use when you have multiple operations in API. In that case you'll need to use policies: Rewrite URL |MS DOC . For that you can set your API suffix and operation URI template to anything, but add this policy into operation's inbound section:
<rewrite-uri template="/" />
what rewrite-uri policy does is overrides operation URI template for backend request"
Reference:
Azure APIM "rewrite-uri" policy - How to remove the URL suffix?
Related
By correlate requests in Azure APIM and Application Insight with W3C distributed tracing Azure, if the client dose not send the traceparent header, seems APIM would checks the incoming request and if no traceparent, the APIM would generate and set from the request goes to backend.
In this case, we would like to return the traceparent information from the frontend response header so the consumer who inoke the API would get it, they could report API issue with this traceparent id so we can better trace/diagnose it with service log.
The question is how to get the APIM generated traceparent from inbound/outbound policy, please suggest a approach, thanks !
The traceparent HTTP header field identifies the incoming request in a tracing system. The traceparent describes the position of the incoming request in its trace graph in a portable, fixed-length format.
If the traceparent HTTP header is not available then, you can set it by using the set-header policy of API Management policies. The set-header policy is used to assigns a value to an existing response and/or request header or adds a new response and/or request header.
When placed in an inbound pipeline, this policy sets the HTTP headers for the request being passed to the target service. When placed in an outbound pipeline, this policy sets the HTTP headers for the response being sent to the gateway’s client.
The below snippet shows how you can set a new correlation context header if none is available.
<set-header name="traceparent" exists-action="skip">
<value>#($"00-{context.RequestId.ToString("N")}-0000000000000000-01")</value>
</set-header>
With the context.RequestId.ToString("N") you get the internally correlated id of the request and format it without dashes. But don't forget to set the correlation format in the Settings tab to W3C.
And with this you will get the traceparent in the header section of your request.
I would suggest you to read this W3C document on traceparent headers and Correlation headers using W3C TraceContext for more information.
I have already a code to retrieve the objects in the bucket using oci-java-sdk and this is working as expected. I would like to retrieve the URL of the file which was uploaded to the bucket in object storage and when I use this URL, this should redirect to the actual location without asking any credentials.
I saw preauthenticated requests but again i need to create one more request. I dont want to send one more request and want to get URL in the existing GetObjectResponse.
Any suggestions>
Thanks,
js
The URL of an object is not returned from the API but can be built using information you know (See Update Below!). The pattern is:
https://{api_endpoint}/n/{namespace_name}/b/{bucket_name}/o/{object_name}
Accessing that URL will (generally, see below) require authentication. Our authentication mechanism is described at:
https://docs.cloud.oracle.com/en-us/iaas/Content/API/Concepts/signingrequests.htm
Authentication is NOT required if you configure the bucket as a Public Bucket.
https://docs.cloud.oracle.com/en-us/iaas/Content/Object/Tasks/managingbuckets.htm?TocPath=Services%7CObject%20Storage%7C_____2#publicbuckets
As you mentioned, Pre-authenticated Requests (PARs) are an option. They are generally used in this situation, and they work well.
https://docs.cloud.oracle.com/en-us/iaas/Content/Object/Tasks/usingpreauthenticatedrequests.htm
Strictly speaking, it is also possible to use our Amazon S3 Compatible API...
https://docs.cloud.oracle.com/en-us/iaas/Content/Object/Tasks/s3compatibleapi.htm
...and S3's presigned URLs to generate (without involving the API) a URL that will work without additional authentication.
https://docs.aws.amazon.com/AmazonS3/latest/dev/ShareObjectPreSignedURL.html
Update: A teammate pointed out that the OCI SDK for Java now includes a getEndpoint method that can be used to get the hostname needed when querying the Object Storage API. https://docs.cloud.oracle.com/en-us/iaas/tools/java/1.25.3/com/oracle/bmc/objectstorage/ObjectStorage.html#getEndpoint--
I have a requirement where I have the Azure APIM public facing URL - https://api.example.com/api/v1/storenumber/ordernumber
And
Back-end service URL (Notice - There is no URL path suffix here) - https://back-end.service.com
So I need to remove "/api/v1/storenumber/ordernumber" in APIM.
How to achieve this in Azure APIM policies?
Thanks,
Aneesh.
Let's say you have APIM service with hostname my-service.azure-api.net. An API in APIM service with URL suffix my-api, and a backend URI of https://my-backend.com. And an operation in this API with URI template of my/uri/template.
So for an incoming call to
https://my-service.azure-api.net/my-api/my/uri/template
without any additional configuration APIM service will make a call to
https://my-backend.com/my/uri/template
Because by default APIM service replaces in source URI scheme+hostname+api suffix with backend URI defined for an API in question.
In most simple case when your API has only one operation you could set API suffix to api/v1/storenumber/ordernumber and operation template to /. That would result in public facing URI of
https://api.example.com/api/v1/storenumber/ordernumber
and backend URI for this operation of
https://back-end.service.com/
Of course this is approach is harder to use when you have multiple operations in API. In that case you'll need to use policies: https://learn.microsoft.com/en-us/azure/api-management/api-management-transformation-policies#RewriteURL. For that you can set your API suffix and operation URI template to anything, but add this policy into operation's inbound section:
<rewrite-uri template="/" />
what rewrite-uri policy does is overrides operation URI template for backend request.
I am doing post request to API via Azure ApiManagement.
If Origin header is present and its not one of specified in Cors policy even postman will return empty response.
As soon as I disable Origin header I can get response.
So problem is following for web based application we must enable cors,
<cors allow-credentials="true">
<allowed-origins>
${env:CorsOrigin}
</allowed-origins>
<allowed-methods>
<method>*</method>
</allowed-methods>
<allowed-headers>
<header>*</header>
</allowed-headers>
</cors>
But our cordova app is also calling same api, and by default cordova will append Origin: file:// Then Api management is doing strange things it will cut body. So response will be empty. If i do same request directly to azure function, I will get proper response back, and since cordova does not care (To a degree in our case is ok) about CORS I would expect api management not to cut response.
Also Api management will not allow me to enter *, because of allow-credentials="true" and also I can't set it to allow file://
APIM does not support origin with file scheme, only http and https. I'll see if we can fix it. But there the workaround for allow-origins=* and allow-credentials=true is to use expressions:
<allowed-origins>
<origin>#(context.Request.Headers.GetValueOrDefault("Origin", "*"))</origin>
</allowed-origins>
This way response will contain sent Origin header value in Access-Control-Allow-Origin and not just * which is not allowed.
I've set up a MediaWiki server on an Azure website with the PluggableAuth and OpenID Connect extensions. The latter uses the PHP OpenID Connect Basic Client library. I am an administrator in the Azure AD domain example.com, wherein I've created an application with App ID URI, sign-on URL and reply URL all set to https://wiki.azurewebsites.net/. When I navigate to the wiki, I observe the following behavior (cookie values omitted for now):
Client Request
GET https://wiki.azurewebsites.net/ HTTP/1.1
RP Request
GET https://login.windows.net/example.com/.well-known/openid-configuration
IP Response
(some response)
RP Response
HTTP/1.1 302 Moved Temporarily
Location: https://login.windows.net/{tenant_id}/oauth2/authorize?response_type=code&redirect_uri=https%3A%2F%2Fwiki.azurewebsites.net%2F&client_id={client_id}&nonce={nonce}&state={state}
Client Request
(follows redirect)
IP Response
HTTP/1.1 302 Found
Location: https://wiki.azurewebsites.net/?code={code}&state={state}&session_state={session_state}
Client Request
(follows redirect)
RP Request (also repeats #2 & #3)
POST https://login.windows.net/{tenant_id}/oauth2/token
grant_type=authorization_code&code={code}&redirect_uri=https%3A%2F%2Fwiki.azurewebsites.net%2F&client_id={client_id}&client_secret={client_secret}
IP Response
(As interpreted by MediaWiki; I don't have the full response logged at this time)
AADSTS50001: Resource identifier is not provided.
Note that if I change the OpenID PHP client to provide the 'resource' parameter in step 8, I get the following error response from AAD instead:
RP Request
POST https://login.windows.net/{tenant_id}/oauth2/token
grant_type=authorization_code&code={code}&redirect_uri=https%3A%2F%2Fwiki.azurewebsites.net%2F&resource=https%3A%2F%2Fwiki.azurewebsites.net%2F&client_id={client_id}&client_secret={client_secret}
IP Response
AADSTS90027: The client '{client_id}' and resource 'https://wiki.azurewebsites.net/' identify the same application.
(This has come up before.)
Update
I've made some progress based on #jricher's suggestions, but after working through several more errors I've hit one that I can't figure out. Once this is all done I'll submit pull requests to the affected libraries.
Here's what I've done:
I've added a second application to the example.com Azure AD domain, with the App ID URI set to mediawiki://wiki.azurewebsites.net/, as a dummy "resource". I also granted the https://wiki.azurewebsites.net/ application delegated access to this new application.
Passing in the dummy application's URI as the resource parameter in step #8, I'm now getting back the access, refresh, and ID tokens in #9!
The OpenID Connect library requires that the ID token be signed, but while Azure AD signs the access token it doesn't sign the ID token. It comes with the following properties: {"typ":"JWT","alg":"none"}. So I had to modify the library to allow the caller to specify that unsigned ID tokens are considered "verified". Grrr.
Okay, next it turns out that the claims can't be verified because the OpenID Provider URL I specified and the issuer URL returned in the token are different. (Seriously?!) So, the provider has to be specified as https://sts.windows.net/{tenant_id}/, and then that works.
Next, I found that I hadn't run the MediaWiki DB upgrade script for the OpenID Connect extension yet. Thankfully that was a quick fix.
After that, I am now left with (what I hope is) the final problem of trying to get the user info from AAD's OpenID Connect UserInfo endpoint. I'll give that its own section.
Can't get the user info [Updated]
This is where I am stuck now. After step #9, following one or two intermediate requests to get metadata and keys for verifying the token, the following occurs:
RP Request:
(Updated to use GET with Authorization: Bearer header, per MSDN and the spec.)
GET https://login.windows.net/{tenant_id}/openid/userinfo
Authorization: Bearer {access_token}
IP Response:
400 Bad Request
AADSTS50063: Credential parsing failed. AADSTS90010: JWT tokens cannot be used with the UserInfo endpoint.
(If I change #10 to be either a POST request, with access_token in the body, or a GET request with access_token in the query string, AAD returns the error: AADSTS70000: Authentication failed. UserInfo token is not valid. The same occurs if I use the value of the id_token in place of the access_token value that I received.)
Help?
Update
I'm still hoping someone can shed light on the final issue (the UserInfo endpoint not accepting the bearer token), but I may split that out into a separate question. In the meantime, I'm adding some workarounds to the libraries (PRs coming soon) so that the claims which are already being returned in the bearer token can be used instead of making the call to the UserInfo endpoint. Many thanks to everyone who's helped out with this.
There's also a nagging part of me that wonders if the whole thing would not have been simpler with the OpenID Connect Basic Profile. I assume there's a reason why that was not implemented by the MediaWiki extension.
Update 2
I just came across a new post from Vittorio Bertocci that includes this helpful hint:
...in this request the application is asking for a token for itself! In Azure AD this is possible only if the requested token is an id_token...
This suggests that just changing the token request type in step 8 from authorization_code to id_token could remove the need for the non-standard resource parameter and also make the ugly second AAD application unnecessary. Still a hack, but it feels like much less of one.
Justin is right. For authorization code grant flow, your must specify the resource parameter in either the authorization request or the token request.
Use &resource=https%3A%2F%2Fgraph.windows.net%2F to get an access token for the Azure AD Graph API.
Use &resource=https%3A%2F%2Fmanagement.core.windows.net%2F to get a token for the Azure Service Management APIs.
...
Hope this helps
Microsoft's implementation of OpenID Connect (and OAuth2) has a known bug where it requires the resource parameter to be sent by the client. This is an MS-specific parameter and requiring it unfortunately breaks compatibility with pretty much every major OAuth2 and OpenID Connect library out there. I know that MS is aware of the issue (I've been attempting to do interoperability testing with their team for quite a while now), but I don't know of any plans to fix the problem.
So in the mean time, your only real path is to hack your client software so that it sends a resource parameter that the AS will accept. It looks like you managed to make it send the parameter, but didn't send a value that it liked.
I had issues getting this running on Azure, even though I got something working locally. Since I was trying to setup a private wiki anyway, I ended up enabling Azure AD protection for the whole site by turning on:
All Settings -> Features -> Authentication / Authorization
From within the website in https://portal.azure.com
This made it so you had to authenticate to Azure-AD before you saw any page of the site. Once you were authenticated a bunch of HTTP Headers are set for the application with your username, including REMOTE_USER. As a result I used the following plugin to automatically log the already authenticated user into Azure:
https://www.mediawiki.org/wiki/Extension:Auth_remoteuser