I would like your feedback on the following :
For my AppServices I set Authorization with AzureAD. I get authentication page and redirection to my Appservice is fine.
Then I setup an Azure Front Door which redirect to my AppServices as backend
In browser when I go to https://myfrontdoortest.azurefd.net then i get the AzureAD authentication page and redirection to my AppService is a success(in browser address bar it reads https://myappservicestest.azurewebsites.net).
Now i want to secure my AppServices with FrontDoor as explained MS here https://learn.microsoft.com/en-us/azure/frontdoor/front-door-faq. At this stage I only apply IP restrictions (not yet the X-FrontDoor-ID)
test #1: when i go directly to my AppService like
https://myappservicestest.azurewebsites.net then i get a 403
forbidden access as expected.
test #2: when I go to https://myfrontdoortest.azurefd.net then i get
the AzureAD authentication page. I provide valid credentials and I
noticed that i am redirect to
https://myappservicestest.azurewebsites.net with a 403 Forbidden.
I'm still struggling to fix it.
Is it something i should change in the reply URL to manage IP restrictions ?
Is it something i should change in FrontDoor configuration ?
Your help is very welcome
Because the front door does not have a fixed IP, it is not feasible to set the IP settings in the webapp.
So it is recommended that you still use the official recommendation to add rewrite rules in the xml file.
The article you are looking for is very useful. It is recommended to read it carefully. If you have any questions, you can also raise a support ticket, MS will give you good answer.
I also find this issue, you can refer it.
How do I lock down the access to my backend to only specified instance(s) of Azure Front Door? #36141
Related
I wasn't exactly sure how to best describe the title of the question for the issue I am having, anyways this is the problem I am encountering, I have searched for a couple of hours and could not find an answer.
I am building and app which is passing through the Azure AD sign in and redirecting back after a successful handshake. All works fine when using https://localhost:port as my RedirectURI in Azure, for example:
Under Web Redirect URIs this following works just fine:
https://localhost:7280/signin-oidc
I login with my AD credentials and I am redirected back to my app's landing page, so all good there.
The problem is however, when I use the following in the hosts file, I am just redirected back to the Azure AD sign in page, even though when I check the azure sign in logs, it states the login was successful.
Question: Is it possible to use a custom URI using the hosts file in a local development environment, when developing an app passing through an Azure sign in? Or am I restricted to using https://localhost:portNumber for my web redirectURIs? Thanks in advance.
Here is the hosts file and the web RedirectURIs in Azure. As mentioned earlier, https://localhost:port works fine. Note: I already have an SSL Certificate for the local development environment which is fine.
My hosts file:
127.0.0.1 dev.operations.co.uk
My web redirectUri(s) in Azure which I have tested:
https://dev.operations.co.uk/signin-oidc
https://dev.operations.co.uk/
I have a domain that is protected through Azure b2c. The way I set it up is that a domain linked through Azure front-door is the login domain.
login.contoso.com
The app domain is
my.contoso.com
What is happening is that when I go to login.contoso.com (without any routing or path redirect uri's) directly it will default to a 404 error and land on this page
The resource you are looking for has been removed, had its name changed, or is temporarily unavailable.
To note, the correct path works. i.e. login.contoso.com/<token>azureb2c...
The issue is how to I handle the 404 error?
I'd like to default direct that to my main domain site i.e. contoso.com or someotherpage.
The odd part for me is that because the domain, sub-domain, is login.contoso.com I don't think there is actually a page from Azure emitting that. I think, correctly, that is just my domain's way of handling 404's or wrong page.
I already handle the redirect if the person goes to my.contoso.com and isn't logged in they go directly to login.contoso.com However, I don't think i'm handling the 404 errors correctly because anything outside of that emits the previously described error screen.
So I think the question is, how can I direct a subdomain's 404 to a url of my choosing of a domain that is setup through Azure front-door?
Is that just in the same permissions of my webconfig for the main app service domain ie., contoso.com? Or, is it the webconfig of the app service specifically for the subdomain my.contoso.com?
• You can surely configure the redirection for your different subdomains from a particular subdomain URL while logging in or any other kind of activity like session auto-logout after token expiration by configuring the correct routing rules for redirection in the Azure front door classic version.
Kindly check the snapshot below as demonstrated according to your requirement: -
Thus, according to the above snapshots, you can configure the redirection for the ‘login.contoso.com’ URL to the desired domain URL of your choice, i.e., ‘contoso.com’ or ‘someotherpage.com’ for in Azure AD B2C too.
• Also, in the above snapshot, I have selected ‘Temporary Redirect (307)’ for HTTPS protocol as according to the below documentation link, the target resource is temporarily under a different URI. The user agent MUST NOT change the request method if it does an automatic redirection to that URI. Since the redirection can change over time, the client ought to continue using the original effective request URI for future requests.
https://learn.microsoft.com/en-us/azure/frontdoor/front-door-url-redirect?pivots=front-door-standard-premium#redirection-types
As you want the redirection to happen for the ‘login.contoso.com’ URL when you redirect to that page, it will surely happen when you configure it accordingly as above since this redirection is temporary according to the situations stated above.
I have a use case for a project where I need to automate the creation of Application Registration on Azure programmatically.
I have been using this sample.
error screenshot
We seem to be facing an issue with Authentication for this App Registration code. We have checked the ReplyURLs with the urls in our App Settings. They are the same. What may be another reason for this occuring?
We also found another link on microsoft documentation where this thread seems to be open but have not found a solution there either. https://learn.microsoft.com/en-us/answers/questions/54102/the-reply-url-specified-in-the-request-does-not-ma.html
To deal with this kind of problem, you can try a general solution:
When you visit the application url , you will be redirected to the login page. Decode the authorization request url, you will find redirect_url, copy the value of redirect_url and paste it into the azure portal, and try again.
For the redirect URL, it should start with https, if you need to start with http, you must configure it as http://localhost.
We have an application that is reachable through a specific URL when connected from our office public IP, and that is reachable through another specific URL when outside the office with a VPN.
We managed to set up the oAuth2 SSO for the first usecase and I was wondering if there was any way to add the second URL, so that our users working through the VPN could also log in with the SSO.
Couldn't find a way to do it so far, if you have any clue.
Thanks !
As juunas said, when you set Redirect URIs in Azure App registration, you could add multiple redirect urls.
And when you use OAuth2 SSO, here such as using OpenID Connect flow, you could specify different redirect_uri when you authenticate the user.
Thanks for your answer, the second redirect URI configured in the Azure App was redirecting us to the first one specified, after hitting the SSO connection button. I guess we found something in the app that was forcing this redirection, we'll try to remove this setting on Monday.
Thanks for you help,
Steven
I am trying to authenticate my Azure Web App. Follow this doc
In my Azure Portal, I've selected "Authenticate / Authorization" for my Web App.
After I configure my Microsoft Account Authentication Settings with Client ID/Key from the App Registration page, I save the settings page and I'll see an error:
The errors says:
Failed to save Auth Settings for WebApp App:
{"Code":"Conflict","Message":"Cannot update the site 'WebApp' because
Authentication / Authorization was configured with an invalid issuer
URL ''. The URL must be well-formed, absolute, and use the HTTPS
scheme.","Target":null,"Details":[{"Message":"Cannot update the site
'WebApp' because Authentication / Authorization was configured with an
invalid issuer URL ''. The URL must be well-formed, absolute, and use
the HTTPS
scheme."},{"Code":"Conflict"},{"ErrorEntity":{"ExtendedCode":"04530","MessageTemplate":"Cannot
update the site '{0}' because Authentication / Authorization was
configured with an invalid issuer URL '{1}'. The URL must be
well-formed, absolute, and use the HTTPS
scheme.","Parameters":["WebApp",""],"Code":"Conflict","Message":"Cannot
update the site 'WebApp' because Authentication / Authorization was
configured with an invalid issuer URL ''. The URL must be well-formed,
absolute, and use the HTTPS scheme."}}],"Innererror":null}
I'm not sure what's the "invalid issuer URL" the issue is referring to.
This issue is not a general issue. This article is absolutely correct.
So I suggest you try to use another location to deploy your Web App and configure the Applicaiton again.
Also, this issue should be temporary, I have reported this.
Hope this helps!
I'm on the App Service team. This is a known issue which we are working to address - the behavior should be temporary. Our apologies for any issues this has caused.
I do not recommend the solution of moving to another region, as this is not guaranteed to work, and sites that do see resolution in this way may break again.
Please find our recommended workaround instructions in my response to this forum post.
For me it worked to add AAD as an auth provider with the default setting even though I'm not using it. I was then able to save my Facebook auth settings. This is a temporary workaround.
This answer from this discussion. Edit field "issuer" not working for me.