Azure AD B2C Single Sign Out - azure-ad-b2c

I have two web apps, one a .Net Framework app and the other a .Net Core app. Both are registered with the same B2C environment.
They interact with one another such that when I sign in on one application, when I click on sign in on the other, this takes me past the input screen and logs me in with the credentials already entered on the other application.
The issue I have is that I have set up a Logout Url for both applications, but it is only working one way round and not the other.
If I am logged in on both applications, then sign out of the Framework application, then when pressing F5 on the Core application, the user is logged out as expected.
However, if I try this the other way round. So I sign out of the Core application, then press F5 on the Framework application, then this does not log the user out.
As it is working one way but not the other, I assume this must be an issue with how the Framework application is setup and not with how the Custom Policy files linked to each application are setup, as if it was, then neither would work?
In the B2C application setting for the Framework application, the Logout URL is:
https://xxxx.azurewebsites.net/Account/SignOut
Which points to:
public void SignOut()
{
if (Request.IsAuthenticated)
{
IEnumerable<AuthenticationDescription> authTypes = HttpContext.GetOwinContext().Authentication.GetAuthenticationTypes();
HttpContext.GetOwinContext().Authentication.SignOut(authTypes.Select(t => t.AuthenticationType).ToArray());
Request.GetOwinContext().Authentication.GetAuthenticationTypes();
}
}
I've also tried an endpoint which is the same as the above but doesn't check if the user is currently authenticated, and just runs the three lines without the if check, but that doesn't work either.
While, the B2C application settings for the Core application, the Logout URL is:
https://yyyy.azurewebsites.net/AzureADB2C/Account/SignOut
Any ideas?

Related

Azure B2C SPA app with custom policy gives Sign In error "Invalid username or password”

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."

Azure Mobile App MSA Authentication Difficulties

So I'm working on a project to redeploy an application that was previously hosted as an Azure Mobile Service as an Azure Mobile App. Said application has a frontend (hosted as a Web App in Azure) and backend API (this is the Mobile App) that is called directly from the frontend's javascript. The upgrade had been going well up until I started working on the Microsoft Account Authentication piece. Following the instructions at...
https://learn.microsoft.com/en-us/azure/app-service-mobile/app-service-mobile-net-upgrading-from-mobile-services
https://learn.microsoft.com/en-us/azure/app-service-mobile/app-service-mobile-how-to-configure-microsoft-authentication
...got things mostly rolling. My application has been registered in the Microsoft Account Developer Center, I specified a Redirect URI following the 'https://{{my_backend_mobile_app_name}}.azurewebsites.net/.auth/login/microsoftaccount/callback' format, I configured the Microsoft Authentication/Authorization in the appropriate blade of my mobile app in Azure using the ClientId/Secret from the Microsoft Account Developer Center. Things go mostly well when I test it out: I can go to the frontend of my application and click on the 'Sign In' button, a new window opens with Microsoft's Login.Live site where I am prompted to login with a Microsoft account, I do so successfully and am redirected to the Redirect URL specified in the Microsoft Account Developer Center and it has Code and State values appended in the query string.
However, the page that is shown when I get redirected there is a 'You do not have permission to view this directory or page'. If I copy the URL, open a new tab, paste it in and hit enter it takes me to a 'You have successfully signed in' page. But neither way takes me back to the frontend of my application where it would log me in and continue into the site as everything is still happening in the new window that was opened for signing in. If I close that window, the authentication process sees that as a 'Cancelling' of the login and requires me to login again (which just repeats the above process). If I leave the window open and go back to the window with my frontend site, it is still waiting for a response from the login process.
So this leads me to my main question: How do I get the Microsoft Account Authentication process to actually return the login response to my frontend site rather than to the login window?
Side note, I've updated the SDK's for both the frontend and backend from the Mobile Service ones to the Mobile App's ones. In doing so I had to add in an OWIN middleware (per the instructions in link #1 above, under the 'Updating the server project' header) to my backend app. My current hypothesis is that this OWIN middleware isn't configured correctly for authentication and is getting in the way blocking the callback from working properly; thus, I am messing around with the app.UseAppServiceAuthentication(new AppServiceAuthenticationOptions()); piece.
According to your description, I assumed that you are using the JavaScript client library for Azure Mobile Apps. I checked this issue on my local side and found I could encounter the same issue as you mentioned as follows:
Then I tried to deploy it to azure web app (https://brucechen-mobile.azurewebsites.net/login.html), I found it could work as follows:
After searched the web I found a similar issue and refer to this blog about Fix the Ripple Issues. I log onto azure portal and choose my mobile app, then click "All Settings > CORS", add the URL for my local web application as follows:
Then, click "SETTINGS > Authentication / Authorization", add the ALLOWED EXTERNAL REDIRECT URLS as follows:
Based on the above settings, it could work as expected on my local side as follows:

GetCurrentApplicationCallbackUri changing over time

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.

IS there any way to get redirected to view of a mvc project from another mvc project?

We have implanted 2 utilities using mvc. And both utilities have authentication using Active directory.We are using single sign on here,means if the user authenticated in 1st application then he can access 2nd application without entering credentials in 2nd application.
Question:If user is not Authenticated in 1st application and he is trying to access the dashboard of second application then he must be redirected to login page of 1st application....IS there any way to do this?
Problem is solved :)
return Redirect("http://localhost:12350/");
It is working.

Azure web api authentication

I would like to secure my Azure WebApi with 3rd party providers (FB, G+... I basically just need a valid email). Was looking at Auth0 and seems like it will do the thing paired with Jwt middleware in web api project, but I was wondering if the same can be done using Azure only.
Azure Web App authentication confused me a bit - it does not seem to give anything to my Asp.Net web app. I still have to configure all the middleware in Startup.cs and the app still works fine if I completely turn authentication off.
I could do the same thing Auth0 does - issue my own Jwt tokens based on access tokens from FB or G+ - but would like to avoid that.
Could you please point me to the right direction?
You have a couple options:
App Service Authentication
Configure the authentication via middle ware
App Service Authentication
The App Service Authentication does not require any code inside your application because your App Service has a gateway that inspects request for authorization. Depending on the setting you can either secure the entire site or secure individual resources (by using the [Authorize] attribute on the endpoint in MVC/WebAPI).
With the latest release you can control authorization on a site by site basis including manually triggering the sign in by navigating the user to the <yoursiteurl>/.auth/login/<provider>. By defualt the token store is enabled so you can make a request to <yoursiteurl>/.auth/me and get back information from the provider.
Middleware Authentication
This is the default way authorization happens in the Single Page ASP.NET Template. The middleware authentication uses OAuth/OpenId to secure the resources. This option does it at the application layer instead of at the gateway. If you are using ASP.NET Identity (from the single page project template) the email from the persons log in will automatically be stored in the Users table. The tutorial in the link above gives lots of details on how to get it working.
Make sure you use the [Authorize] attribute to trigger the Authorization in either case.
Hope that helps you get started in the right direction.

Resources