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.
Related
I need some help with implementing authorization infrastructure for my application.
I have a Angular SPA application that works with a Web API. This Web API in turns uses another Web API to serve its request. So, I have totally 2 Web APIs and a Angular SPA application.
I want the users of the Angular SPA application to be authenticated by our Azure AD account, and then share this token with other two Web APIs to authenticate the requests.
Please advise how to go about it, any thoughts are much appreciated.
So the flow looks like:
1.Sign-in the user in the SPA application.
2.Acquire a token to A Web API and call it.
3.A Web API then calls B Web API.
Take a look at this sample. It uses the On-Befalf-Of flow which applies to your scenario.
I have an ASP.NET MVC Web Application running as a web app in Azure App Service. This web app calls an Azure Function via HttpClient from a Controller. Authentication/Authorization is configured in the web app with Azure Active Directory. I need the user to also be authenticated when a call to the Azure Function is made so that I can access the user Claims.
I tried to also configure Authentication in the Azure Function itself but this resulted in an "Unauthorized response" whenever I called the function from my web app.
Is there a way to make both the web app and the Azure function use the same Active Directory Authentication. So that when a user is authenticated to the web app, he does not need to authenticate again in the Azure function and all the User Claims would be available in the function itself?
I can think of three different approaches that would work.
Using Bearer token.
Create two separate application registrations, one for the web application and one for the function application. Setup the Authentication/Authorization feature for the respective applications, with both configured to require AAD access. Give the web application's AAD app registration permission to access the function application's AAD app registration.
To make sure that the access token of your web application is a JWT that can be used to contact your function application, you need to add additional login parameters to your web application. To do this, follow the instructions here, but instead set additionalLoginParams to resource=<your-function-app-registration-client-id>.
When a user makes an authenticated request to the web app, a header should be populated called X-MS-TOKEN-AAD-ACCESS-TOKEN which should be an access token with an audience of your Function application's app registration. This can then be used as a bearer token to the Function application API calls, which should satisfy the authentication/authorization requirements of the function application.
Using on-behalf-of flow
Create two separate application registrations, one for the web application and one for the function application. Setup the Authentication/Authorization feature for the respective applications, with both configured to require AAD access. Give the web application's AAD app registration permission to access the function application's AAD app registration.
Then, follow the on-behalf-of flow so that the web application can get an access token for an authenticated user user for the function application. There are several libraries that help with this flow. See ADAL if your app registrations are AAD V1 apps, or MSAL if your app registrations are AAD V2 apps.
Use Client-Directed-Flow (X-ZUMO-AUTH)
Create two separate application registrations, one for the web application and one for the function application. Setup the Authentication/Authorization feature for the respective applications, with both configured to require AAD access. Give the web application's AAD app registration permission to access the function application's AAD app registration.
To make sure that the access token of your web application can be used to authenticate against your function application, you need to add additional login parameters to your web application. To do this, follow the instructions here, but instead set additionalLoginParams to resource=<your-function-app-registration-client-id>.
When a user makes an authenticated request to the web app, a header should be populated called X-MS-TOKEN-AAD-ACCESS-TOKEN which should be an access token with an audience of your Function application's app registration, along with an id token in the header X-MS-TOKEN-AAD-ID-TOKEN. Make a POST request to https://.azurewebsites.net/.auth/login/aad with the payload
{"id_token": <id-token>, "access_token": <access-token>}. This will return a session token, that you can attach as an X-ZUMO-AUTH header to authenticate requests.
NOTE: The claims in this option will be the claims of the authentication token, which are not the claims of the identity provider like in the first two options. To get the same claims as the other options, set the application setting WEBSITE_AUTH_ZUMO_USE_TOKEN_STORE_CLAIMS to true.
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
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.
Scenario: I already have a registered multi-tenant web application that is compatible with Azure SSO. I'm now in the process of developing an iOS application that will support SSO authentication for the app as well.
Based on the example provided in https://azure.microsoft.com/en-us/resources/samples/active-directory-ios/ I created a Native application for the iOS app with delegated permissions from my WebApp (ref: https://stackoverflow.com/a/29810124).
This works for any user that exists within the AAD that the app was created. However, as soon as I want to SSO from a different domain that has previously authorized the WebApp I get an error:
Application with identifier 'CLIENT_ID_HERE' not found in directory DOMAIN_HERE.onmicrosoft.com
This implies that the native application is not multi-tenant? This seems a bit bizarre considering it should be possible for users outside of the domain to SSO to an application.
Right now, for my browser based SPA I'm simply able to manually call the common Azure login page to consent and get an authorization code for a user. I then send this code to a backend (the WebApp) that performs the OAuth handshake and gets a valid token. This does not require a client_secret from the application because the SPA isn't actually performing token retrieval.
So when I attempted to use the WebApp's client_id instead (similar to what https://stackoverflow.com/a/27033816 is suggesting) I was met with an error with the Azure AD iOS SDK requiring that I provided a client secret as well. It seems that the SDK is abstracting a fair amount of this and grabbing a token for you rather than performing a step when I can simply get an authorization code and send it to my WebApp.
TLDR: My requirements are very similar to the ones outlined in multiple-tenant, multiple-platform, multiple-services single sign-on using Azure Active directory where I have multiple clients (browser, iOS, Android) that all need to be able to use Azure SSO. I'm assuming the mobile apps should be able to use my existing WebApp to authenticate the users.
The question posed in the answer of the previous SO post somewhat explains my issue:
How can my mobile app access my multi-tenant web api on behalf of the user?
References
https://learn.microsoft.com/en-us/azure/active-directory/active-directory-authentication-scenarios#native-application-to-web-api
https://github.com/Azure-Samples/active-directory-dotnet-webapi-multitenant-windows-store
At present the native app which register on the Azure portal doesn't support multi-tenant. You may consider using the V2.0 endpoint which also support the Microsoft accounts.
TLDR: My requirements are very similar to the ones outlined in multiple-tenant, multiple-platform, multiple-services single sign-on using Azure Active directory where I have multiple clients (browser, iOS, Android) that all need to be able to use Azure SSO. I'm assuming the mobile apps should be able to use my existing WebApp to authenticate the users.
Did you mean that have different font-end and the Multi-Tenant Web Application is the back-end? In this scenario, there is no need to register another native client application on the portal, you can refer here about add authentication for the iOS app.
So the majority of Microsoft's tutorials use their AAD SDK to generate OAuth access tokens whereas I needed to simply get an authorization_code to send up to a backend that's registered as an existing multi-tenant web application so it could properly generate a token using its own client_id.
This was done using the correct redirect_uri in the AD OAuth code documentation:
For native & mobile apps, you should use the default value of urn:ietf:wg:oauth:2.0:oob
Note that sending up urn:ietf:wg:oauth:2.0:oob will actually result in a schema error for the multi-tenant OAuth login page (https://login.windows.net/common/oauth2/authorize) so you must use https://login.microsoftonline.com/common/oauth2/nativeclient instead.