I need to allow authentication using my ASP.Net Identity from the MVC app (merged into the Mobile App service project) and from the mobile client (Android). Furthermore, I need to allow social authentication providers (Facebook and Google, to be exactly) to be used from the mobile client.
Adrian Hall's book says that for custom auth to work we should not configure the other authentication providers. So, how can I enable both forms of authentication?
I don't remember saying that. I'll have to check. You need to be careful though.
In your MVC app, you need to decide on ASP.NET identity or App Service Identity. If you choose ASP.NET identity, then you have to decide how your mobile application is going to authenticate - you are in completely custom area. If you are using App Service Identity, you need to decide how your application is going to authenticate (since the redirect can only go to one place).
I'd probably do App Service Identity. Configure Facebook and Google first. Then create a custom mobile auth endpoint. For your MVC side, configure a redirect page that displays the "choose your auth provider" page and then directs the user to the appropriate page - Google (/.auth/login/google) or
Facebook (/.auth/login/facebook) or custom (which you will create).
All the redirects will then point back to the callback page so the tokens get stored properly.
Related
I have two Azure Web Apps, one is a website and acting as the front-end, the other one is an API and acting as the backend. I would like to add authentication to this solution so only the front-end can access the backend. To do this, I've configured AAD authentication on the backend Web App with the express option that creates a new Azure AD application configured with the correct reply URL, API permissions (User.Read), etc. When I then navigate to the backend Web App URL, I need to sign-in with my Azure AD credentials.
Which steps do I need to take to restrict that so I as an user cannot login and only the front-end Web App can authenticate to the backend API?
For example, I can set the "Authorized client applications" on the Azure AD application of the backend API. However, I need to have an application ID to add an authorized client and I would like to use the Managed Identity of the front-end Web App for this, not a new and additional Azure AD application.
Any idea how to do this?
This is weird, if the login screen still appears, there is a problem with your code configuration, because the client credential flow does not involve user interaction.
I found a useful sample for your reference, this sample application shows how to use the Microsoft identity platform to access the data from a protected Web API, in a non-interactive process. It uses the OAuth 2 client credentials grant to acquire an access token, which is then used to call the Web API.
I have been doing some research on the best way to perform the AuthN & AuthZ for a new project but haven't found anything that seems to work for this project's requirements.
I have a .net core API project which needs to be accessed initially only by my Razor Pages web application (separate project).
In the near future, I will need to make the API accessible to 3rd party applications as well (so if a user logs in to this 3rd party app, he automatically can access my API without having to enter UN/PW again - this will likely require some development from the 3rd party team).
I would like to have different roles as well for the users in my Razor Pages Web app & users in the 3rd-party app (for authorization purposes).
The API and Razor Pages app will be running in Azure.
I would like to know if there is one solution that can be used in the API side that will handle both a request from my Razor Pages (preferentially using the token retrieved from the B2C authentication process) and the requests from other 3rd party applications.
I have thought of generating unique JWTs sending that to the 3rd party applications as well as my Razor Pages web app and using the .net core jwtBearer authentication setting in the API side to allow the authentication/authorization (would likely have user role information sent as a claim).
This doesn't seem to be a good solution though since those JWT values would be hard-coded and wouldn't be updated.
Please, let me know what you think would be a good solution.
Thank you.
You may need to consider Azure AD which provide out of box authentication. Azure AD can be used for end to end protection. You just need to secure your Web API by Azure AD and any client which require to access your API will have to get authenticated by Azure AD and will be issued a token to access your WebAPI. https://learn.microsoft.com/en-us/azure/app-service/app-service-web-tutorial-auth-aad . To manage Authorization you can consider roles https://github.com/Azure-Samples/active-directory-dotnet-webapp-roleclaims
The graphic pretty much tells the story. This is all single tenant, fwiw.
I have my Web API, which is being accessed by a "swagger" UI (which is really a kind of spa) served up from the same location, as well as an MVC app, which has some traditional MVC controllers interacting with the Web API, as well as some SPA experiences that interact directly with the web api.
From what I've read, in addition to my Web API having an app registration in my AD tenant (which has the roles declared in it's manifest in order to support RBAC), I also need to have a separate app registration for the swagger UI, which is granted permissions to access the Web API.
I'm unsure if my MVC app needs 1 AD Tenant registration, or 2 registrations (1 for MVC, 1 for the SPA served up from MVC)
Main questions..
Should my MVC/SPA share the same AD registration, or, they should be separated?
Does my Web API registration's manifest need to have "oauth2AllowImplicitFlow": true, or only the swagger and SPA app registrations' manifest need that?
My MVC, based on this github sample for SPAs, currently uses this middleware: app.UseWindowsAzureActiveDirectoryBearerAuthentication .. but if my MVC is going to do selective things in it's razor or with it's contoller logic, should I also be using these add'l middlewares UseCookieAuthentication and UseOpenIdConnectAuthentication as shown in this non-SPA web app sample
You can probably make it work with the same application (getting the access token server-side and supplying it with the rendered page), but you might run into a few things where you can't use that token to get a token to go to the next app (the WebAPI one). It does mean a potential extra trip to Azure AD, but I'd have the SPA be it's own app.
Only the Swagger and SPA registrations need "oauth2AllowImplicitFlow": true.
Your MVC app should not use the bearer auth middleware - it should use the normal OpenIdConnect one. The only app in this setup that should be using bearer auth is your WebAPI one.
A couple of additional notes re: the SPA served from the MVC app. When you're making a call to the WebAPI app, you'll need to make sure a bearer auth token is included on the call, which you get using something like ADAL-JS. If/when you're making a call to the MVC app, no bearer token will be used, you'll be usually the cookie+openid authentication.
I have a need to move an older style Azure Mobile Service to a new Azure Subscription. In the new subscription, you are no longer allowed to create an older style Mobile Service and are required to create one of the newer Azure Mobile Apps. I have already moved the database (fixed changes with the column names, etc.), and have the easy tables and easy API migrated and working based on a NodeJS back-end. The only thing that is left is to add authentication to the mobile app to secure the back-end. The way the app was originally developed is that the mobile client SDK passed a secret key along with the endpoint URL in the MobileServiceClient constructor and a custom username/password form passed the user entered credentials to a mobile API method that would validate the user contained in the database. The updated client SDK now only accepts the endpoint URL.
Everything that I see online for the new Mobile Apps wants to authenticate with AAD, Facebook, Twitter, Microsoft Account, or Google. We do not want to change our authentication. How can I easily add the same type of authentication to the new Mobile App without having to use Facebook, Google, Twitter, etc?
The easiest method is to implement some sort of custom authentication, just like you did in your Azure Mobile Service. The same principals apply - you submit the username / password to the backend. The backend generates a JWT and then the client submits that information for the rest of the session.
I covered Custom Auth in node early on in my blog series: https://shellmonger.com/2016/04/08/30-days-of-zumo-v2-azure-mobile-apps-day-5-custom-authentication/ - that one uses Auth0 to handle the actual user database, but the same principals apply.
I've got an existing mobile app that is integrated with Azure's mobile services. The mobile services are currently connected to Azure Active Directory with MFA enabled. I'm attempting to build a separate PHP-based web application that uses this existing mobile service and authentication.
Authentication
The only active directory of users is the cloud-based AAD. There is no local version and no office 365. After doing a lot of research, it appears PHP can integrate using SAML. However, there are either no PHP samples Azure Active Directory Code Samples or they're tied to Office 365 azure-sdk-for-php-samples.
How can I authenticate my users against AAD via the web-app?
Authorization
Once a user has been authenticated, how can I ensure that user has the same access levels as the user via the mobile service?
One option would be to have your PHP app serve a page using the Mobile Services JavaScript SDK and have it perform the login.
You'll get the same token that you would in your mobile app. To your question on authorization, as long as you're making subsequent backend calls through the Mobile Service, you will get the exact same authorization rules as you have defined on that service.
The token will be client-bound, and you'll likely want to get it back to your server for making calls. The actual Mobile Services token is located in client.currentUser.authenticationToken, and you can set this as a cookie in the javascript code and then retrieve it on your PHP backend in a subsequent call.
Calls to the Mobile Service (via the REST API) from your PHP backend just need this token set in the X-ZUMO-AUTH header.
This approach should work for all providers, including AAD. MFA should not be a problem in this case.