We're setting up SAML2 SSO using Azure AD, and we set the Reply URL incorrectly the first time. Now, I am unable to login with the original credentials we tested with as they are being redirected to the incorrect Reply URL. Any new user accounts work fine.
I'm unable to find any documentation saying how long this type of caching may take place, but I've cleared all client-side caches and am at a loss for what we could do without recreating the app (which we'd like to try to avoid).
Related
I currently have an Azure Blob Storage Account setup with Azure CDN to host a Static Site. This Static Site is connected to an App Service backend and uses frontend-based authentication using Active Directory baked into the application code with MSAL.
When it was initially deployed and running off of the Static Site's URL alone, I was able to authenticate without fail. The auth popup would present itself, I would provide credentials, and the Active Directory sent back a token that I then confirmed with the backend and successfully redirected to the post-auth landing page.
The Problem I'm having now is that when I proceed to the URL provided by the Azure CDN (rather than the Storage Site's URL), the popup for authentication opens and allows me to provide credentials, but instead of closing and redirecting upon token reception, the popup simply hangs there. It's also interesting to note that the popup's URL is listed as the Static Site URL and not the CDN URL. The token comes back and is present in later portions of the URL, so it must be a mis-match between the URLs that's causing the issue.
I've Tried changing out the Static Site's configured Reply URLs to match the CDN, and it didn't make a difference. I've also added the CDN URLs (both the custom one and the endpoint .azureedge.net one) to the Active Directory list of Reply URLs.
The CDN is providing a certificate for the custom URLs to use, so we need that in order for the custom URLs to work properly. To be clear as well, the authentication works when using the Static Site URL, but not the CDN URL.
Has anyone else run into an issue of this nature? If so, have you solved it?
For anyone who may come across this, the solution was much more simple than I had anticipated. The MSAL configs for the frontend needed to be using the new CDN URL (which I figured), but the CDN itself needed to be purged and the changes picked up from the Blob storage.
No idea where else to turn at this point. We're in the final stages of developing our app, which is hosted in a Linux-based NodeJS v12 Azure Web App.
Our app hooks up to Azure AD B2C to store and manage user accounts. AD B2C is configured entirely with Custom Policies.
When we try to change our account's password via B2C, we proceed with the password change successfully, but then B2C tries to redirect us back to our website, and it fails with a 431.
The Referer is ridiculously long, and looks something like this: https://%ADTenant%.b2clogin.com/%ADTenant%.onmicrosoft.com/%CustomPolicyName%/api/SelfAsserted/confirmed?csrf_token=%Token%&tk=StateProperties=%Token%&p=%CustomPolicyName%?diags=%ListOfEncodedClaimsAndControlInformation%
Encoded, the entire thing is roughly ~1,800-1,900 characters long. We also have about ~1,000-1,100 characters in our cookies, and the destination URL is ~1,300 characters long, for a total of ~4.1-4.3k characters.
If we reload the page the referer becomes empty so the call works fine.
Strangely enough, when in Incognito, the issue does not arise; the Referer becomes empty and it works fine.
At first we thought it was the NodeJS 8KB request header size maximum, but our request header is under that. And it works locally; it only breaks when the app is in an Azure Web App, making it harder to troubleshoot.
We even added WEBSITE_AUTH_DISABLE_IDENTITY_FLOW=true to our Web App: no luck
If anyone out there has an idea, that would be amazing, as we're running thin on ideas here :(
Thanks!
I guess you can try use –max-http-header-size arg for node.
I have an IIS website on a server internal to my domain that is also published via azure application proxy, which is secured using windows authentication. Our AD structure is hosted locally and published to Azure AD via AD connect.
Users visiting from outside the domain are authenticated first via the login.microsoftonline.com page.
My problem is that users external to the domain are on shared devices and need to change users occasionally, and I can't figure out how to do that.
I have read that navigating to an url like https://login.microsoftonline.com/{tenant id}/oauth2/logout?client_id={client id}&post_logout_redirect_uri={???} is supposed to achieve this, but after arriving at the login page and logging in as a different user, when we return to the site the user turns out not to be the user that authenticated, but remains the same user as before the attempt to change the user.
I have also read that deleting the cookies named like AzureAppProxyUserSessionCookie, AzureAppProxyAnalyticCookie and AzureAppProxyAccessCookie can help, but doing so does not seem to make any difference.
I thought that perhaps the browser was auto-authenticating or pre filling in forms etc, but turning those features off does not affect anything.
My questions are:
Are any log-off / log-on via Azure AD event logs kept that I can view, and if so, where?
How are you meant to log-off for my scenario?
We are developing an UWP app using ADAL authentication in Azure. We have configured our client in Azure Portal with the Redirect URI taken from the result of this method:
Windows.Security.Authentication.Web.WebAuthenticationBroker.GetCurrentApplicationCallbackUri()
It was working at the beginning, but now we've noticed that the URI generated by that method has changed. Therefore our login with ADAL does not worked anymore, stating that
The reply address 'ms-app://s-1-15-2-104.......' does not match the reply addresses configured for the application.
Of course, we added the new value of the URI to the client configuration, and it worked, but after a day or two it has changed again. I think this is not the right way to update the Azure configuration every couple of days.
How can we ensure that the result of GetCurrentApplicationCallbackUri stays unchanged?
The GetCurrentApplicationCallbackUri uses your app's SID to construct the URL. I'm not sure of the exact mechanics of it, but if you are still developed the app, especially in a team, the SID can change.
One way to ensure that it remains fixed, is to create the Application in the Windows Dashboard and associate the app with the Store:
From Visual Studio - right click on the Project and select Store->Associate app with the store.
You don't have to submit, but associating the app will update the package.appxmanifest with the real values from the Dashboard and they will persist across developers.
From documentation:
To support SSO, the online provider must allow you to register a redirect URI in the form ms-app://appSID, where appSID is the SID for your app. You can find your app's SID from the app developer page for your app, or by calling the GetCurrentApplicationCallbackUri method.
Found this official ACS demo http://www.fabrikamshipping.com/ while researching on ACS.
In the app itself, when logging in with one of the providers ( I chose Google ), I can see in the browser history the URL that contains the claims returned from ACS. It's the URL that starts with :
https://fabrikamshipping.accesscontrol.windows.net/v2/openid?context=pr%3dwsfederation%26rm%3dhttp%253a%252f%252ffabrikamshipping%252fcons...
Going to this URL logs me in the app, even after clearing all browser cache and cookies.
So if I log in to the app from some public computer, and then log out, my account is exposed by going to this URL in the browser history.
I know this is the standart way that ACS Identity handling works.
What am I missing here ?
You are not missing. This URL will log you in, even all cookies are cleared. However, when going on public computer you have to be more careful about your credentials. Clearing history will wipe this URL from browsers history.
Also, I don't actually see the claims URL in my history.
Another way of protecting your personal data is using "In Private Browsing session" for the browser of your choice. Note that it is very hard for someone to see, not to mention remembering that URL. You got it, because you copied from the browser at the moment of redirecting.
I opened the same thread in Azure official forums :
http://social.msdn.microsoft.com/Forums/en-US/windowsazuresecurity/thread/8f35d6d7-fe0d-4589-9502-54c85714979a
It seems like a known issue. I will update the answer here as soon as a solution will be provided.