So, I thought I had this all working until I deployed to a new set of environments. I have a webapp that's authenticating just fine with multi-tenant WAAD users. But when I try to hit the webapp from an HttpClient after authenticating via AcquireTokenAsync I always get the login page as the result.
The only concrete thing I have to go in is the fact that the on-boarding process never seems to complete. The login prompt always asks me to give the WebApp and Native Client permissions.
I've triple checked client ids, tenants, app id urls, etc. Is there anything else to investigate? I hit this snag once before only for it to just start working :(
Edit #1: Webapp + api works just fine via the normal cookies, just seems to completely ignore the Bearer token I'm setting?
So it turns out I had set the Audience on the WindowsAzureActiveDirectoryBearer object incorrectly so the token was never valid...
Related
Our SPA app and Web API were working well with the standard SignUpSignIn user flow. When we switched to using a custom policy while keeping the same App Registrations, Sign In always displays “Invalid username or password” [1]. (Sign Up and Sign Out work).
To remedy the issue, we created new App Registrations as per Microsoft Custom Policy Tutorial
As stated, we used “Allow public client flows.”
Now the signin/signup page displays “The provided application with ID xxx is not valid against this service.” (error AADB2C90068). This happens whenever we use account type “Accounts in this organizational directory only”
If we use “Accounts in any identity provider”, we go back to getting “Invalid username or password”
Switching the front-end to “SPA” instead of “Public client/native (mobile & desktop)” doesn’t help.
Strangely, we did find a configuration that works: Following the tutorial exactly (Allow public client flows + Accounts in this org directory only + Public client/native platform) but leaving the front-end SPA app pointing to the old app registrations. Obviously we can’t leave it like that.
How do we properly solve the “Invalid username or password” issue with an SPA app using a custom policy?
[1] The corresponding sign-in log says error 7000218.
Also, TrustFrameworkExtensions.xml does have the correct IDs in it.
You could just use the tool I’ve made: https://aka.ms/iefsetup.
But your issue is definitely due to the way you’ve registered the two app registrations, or inserting the IDs into the XML.
This issue was resolved by creating two new App Registrations IEF and ProxyIEF that are for use exclusively by the custom policy XML. Our SPA application and it's Web Api back-end each use one additional App Registration as was the case when we were using a User Flow.
Thanks to Jas Suri, especially for this comment: "Do not change anything that the tool created. The fact that the test app works means it’s something you created in addition to what the tool created that’s not configured correctly."
I have been testing a Blazor Server app (ASP.NET Core 6.0) locally for a while with no issues. It authenticates against Azure AD, and everything works fine.
I deployed it to an IIS 10 server on Windows Server 2019 (after installing Websockets, ASP.NET hosting runtime, etc.) and now I can't get past authentication, either locally on the server or remotely.
When I hit the URL, it immediately redirects to the Microsoft Login page, where I enter my username (email), then password, then 2FA challenge, then the yes/no stay logged in page, and then it appears to hang for a short while (although in the tab it is constantly switching between "Working" and "https://login.microsoft.com...") and then it either comes up with Bad Request - Request Too Long, or just "We can't sign you in".
If it's the Bad Request error, then the cookie store will be full of .AspNetCore.Correlation.xxx and .AspNetCore.OpenIdConnectNonce.xxx cookies, which is what makes the headers too long, and creates the bad request. If it's the "we can't sign you in" error, then clicking the three dots, and saying sign out and forget, resets things which will next time result in the Bad Request error.
Just to check that I hadn't done anything stupid, I created a new blank app, using the Blazor Server template, and deployed that in place of my app. Exactly the same thing happened. I could run it locally in VS, but after publishing to IIS, exactly the same Authentication errors.
Does anyone have any ideas or pointers?
OK, for anyone who finds this in the future... it was a simple fix - but there are no error messages which point to it until you look very deeply.
When I set up both my app, and the Blazor template app, I let the scaffolder set them up, and get a secret from the Azure API, which it placed into my local secret store.
When I published the app to IIS, the ClientSecret was not copied.
The quick fix was to simply put the client secret into the appsettings.json file at which point everything came good immediately. The longer fix is to use the server-based secret store.
Apparently the looping was caused by the client secret not being present. :(
We are testing the use of Docusign, within the approval flow of a business application.
We are using the OAuth solution for Service integrations, the JWT (JSON Web Token) flow.
When I call the apiClient.ConfigureJwtAuthorizationFlow method in the aplication hosted in IIS Localhost, I obtain the OAuthToken and can send envelopes.
But when I deploy the solution on the Test server, with the same userId, integratorKey and privateKey, the call to apiClient.ConfigureJwtAuthorizationFlow method return null.
I did:
https://account-d.docusign.com/oauth/auth?response_type=code&scope=signature%20impersonation&client_id=XXXXXXXXXXXX&redirect_uri=https://www.docusign.com
Do you have any idea how to fix this? What's the matter?
Have you tried using the C# .Net Core or C# .Net Framework examples? See if one of those examples work on your Test server. If they do, the problem is in your code. If they don't then they are the first issue to be solved.
As you say, there should be no difference in where you run your application.
The usual issues to be checked for a test server: Firewall rules, DNS configuration, SSL root certificate store, etc.
Also, the url you gave is used for manually granting consent. It is only needed once per user (on demo). You only use that URL once to grant consent. After that, the JWT token can be used to get an access token which impersonates the user.
I have one Node Bluemix application configured with the SSO Service & connected with a Cloud Directory. I can successfully authenticate the user but I'm having problems to accomplish a successful logout. I have tried req.session.destroy, req.logout, and express-passport-logout module to end the session. But none of them worked. I also tried to remove cookies from my application but it didn't work as well. The only way it is working is by restarting the browser or clearing cookies from browser. Does anybody know how to achieve a SSO logout from the application?
The last time I used the service this was not possible. The problem is: what you are doing with the listed commands is to close your application session, not the one on SSO service. So when the user comes back (with the same cookie) your application will ask SSO service to check and it will accept the user (since the session there is still open). Currently there is no API available to close the session on the SSO service instance.
Actually, this becomes more complex when you use external IdP: even if you close the session at the SSO server, the browser will still have a session with the real IdP the user logged in from, which depending on the configuration of your service instance could be one or more of IBM, Facebook, Google, Linkedin. Some of these IdP's provide long-lived sessions via persistent cookies and your application can't force the termination on their side. That means that on next click of the "login" button, particularly in the case where the SSO service instance is configured to use only one IdP, SSO will happen seamlessly with no further interaction.
Take a look here to get more information.
As Umberto says, maybe it was not possible before, but now it seems to be:
Check this. You can redirect your user to this:
/idaas/mtfim/sps/idaas/logout
At least this seems to work if you only use Cloud Directory.
I have 2 webapi2 projects that use the same database. If I'm on localhost I get a bearer token from one I can pass it to the other and the other will properly decrypt it and load the user. However when I publish them to separate urls on azure, I get the one token fine from one but when I pass it to the other I can't get the ticket to load and it gives me the unauthorized response.
I'm testing this by watching the owin AuthenticationTokenProvider.OnRecieve method. When context.DeserializeTicket is called the ticket remains null and the user never gets loaded.
Your first response will likely be about how the machine keys need to be the same between the 2 so they will work. The problem there is
All my online research says that azure machine keys are synced between apps in the same role (ones a web app and the other is a web api app) so this shouldn't be an issue
I can't specify a machine key because the first app has been in production for a while and changing it's machine key would mess up stored passwords etc...
using the machine key used by the production app on the new api nay work but there is no way to get the machine key of an azure web app.
I'm pretty sure this isn't a machine key issue though but I have no idea how to figure this out. Heeeeelllp!