I have a web forms application which I developed for testing Authentication/Authorization scenarios. While creating the test project, I selected "No Authentication" which created my project to have no authentication mechanism code. I published the web site to my azure tenant and enabled the Azure Active Directory Authentication from the "Authentication / Authorization" under features. I created an Azure AD app pointing to my web application. After hitting the default page, the app now authenticates and everything seems to work fine.
However, when I run the app locally from within Visual Studio, I am not able to get the user information as there are no appropriate headers available, eg X-MS-CLIENT-PRINCIPAL-NAME. My next step was to call the graph API to get the detailed user information.
NOTE: I am able to include the OWIN code in my web project to authenticate users, but I want minimal code change to my existing on-prem windows authentication application.
Any help / guidance
However, when I run the app locally from within Visual Studio, I am not able to get the user information as there are no appropriate headers available, eg X-MS-CLIENT-PRINCIPAL-NAME. My next step was to call the graph API to get the detailed user information.
This is expected. The X-MS-CLIENT-PRINCIPAL-NAME header (and related headers) is added by the Authentication / Authorization module which runs in app service. when you run locally from Visual Studio, you won't have this module and thus won't have this request header.
If you want to use the same code both locally and in App Service, instead of looking at the request headers, I suggest using .NET APIs which surface up user information, such as ClaimsPrincipal.Current.Identity.Name. This should be populated correctly whether you're using Windows Authentication locally or Authentication / Authorization in Azure App Service.
You can find more information about the underlying mechanics of Authentication / Authorization here: https://cgillum.tech/2016/02/01/architecture-of-azure-app-service-authentication-authorization/.
Related
I have a dotnet core api in an app service on Azure.
When I run this locally, with authentication switched on, I can generate a bearer token and use that to successfully access the end points.
On azure, when authentication is switched off I can access the end points, but when I switch authentication on in azure, I can't access any end points with a token. Postman is just returning the standard response "The page cannot be displayed because an internal server error has occurred".
I can't see anything in application insights so I'm really in the dark.
Hoping someone will know of any common issues that could be behind this.
Thanks in advance
You cannot access your web app authenticated with Azure AD using B2C token.
On local, created web app using Visual Studio only have three authentication choices:
As we can see, using Individual User Account is connecting to an Azure AD B2C account.
On portal, you could configure your app service with choices below:
If you are using Log in with Azure Active Directory, you should concern it is not same as B2C. Follow this page to configure Azure AD authentication with web app.
Get the AAD bear token:
Navigate to the app registrations page in your Azure Active Directory, choose the one you created in configuring authentication step. You would see the information like this:
Go to Certificates & secrets page to create a secret, and copy that value, cause you would not see it after leave this page.
Open Postman to get the access token, here is the required parameters:
Use the bear token you got from last step to access your web app:
I have a Web API project I created using this tutorial that I'm trying to secure using Azure AD.
According to the tutorial, when I create the project, I can select "Change Authentication" and enter my AAD information and the authentication supposed to just "work" as long as I have <Authorize> on the controller I want to secure:
According to the tutorial, I need to add the API as an app in the Azure portal but its steps and screenshots are confusing because they're old and the Azure portal has been reorganized. It says:
Next step is to add the "WebAPIServerSingleTenant" as an app you can access in your native app. Navigate to the "WebAPIClientSingleTenant" app and add "WebAPIServerSingleTenant" to your approved list (tick the checkbox too)
But adding the tenant info from Visual Studio when I created the project creates an app registration in AAD automatically, so I'm not sure what it's asking me to do.
Furthermore, when I try to call the API from Postman, for example, I just get "Authorization has been denied for this request" despite generating and passing an access token in the header of the request that looks right to me.
What steps do I need to follow to secure my web API using Azure AD?
The 'Next step is to add the ..." instruction you quote above is about adding a reference to your API app to the AAD registration of your native app. To register the native app, go to the Azure portal and use App Registration. The instructions for how to do that linked in your article are obsolete - AAD UI is totally different now. Rather use one of the official samples, in particular the one for native client accessing an API.
I'm using Xamarin Forms and Windows Azure for SQL Database. In the last version of windows azure they give you an application key to avoid unauthorized access to the web services but now they remove the application key and now they are using authentication through Facebook, google, etc.
The question is I want to protect my web services but I don't want to use facebook or google authorization because I'm using my own login and password.
I want my web services unprotect
I want to protect my tables but I receive and error while reading the data
According to your screenshot, I assumed that you are using Easy tables with access permission. As I known, when you add a new table under Easy tables, it would automatically create the related Node.js back-end, you could go to App Service Editor (Preview) in the Development Tools section of your mobile app as follows:
For Node.js back-end custom authentication, you need to set auth congiguration for your server side, and build your custom login endpoint to validate the client and generate the JWT token for your client. Here is a similar issue, you could refer to here.
Additionally, you could build the C# back-end by yourself and deploy to the mobile app. For custom authentication, you could refer to adrian hall's book about Mobile Apps Custom authentication. For data access, you need to build table controller for each of your SQL table, you could refer to Implementing Table Controllers.
Note:
You must turn on Authentication / Authorization in your App Service. Set the Action to take when request is not authenticated to Allow Request (no action) and do not configure any of the supported authentication providers.
For client app, you could leverage Azure Mobile Client SDK for connecting with your azure mobile app backend. For more details, you could refer to this tutorial about working with managed client for Azure Mobile Apps.
Is it possible to set up a single "Native app" which can be used by users on different Azure accounts/directories so they can get data from their Office 365 Sharepoint Online?
We can get this working using a "Web app" because in the Azure portal where you set this up it has the "Multi-tenanted" option which can be set to Yes - the notes for this support this:
Designates whether users in external organizations are allowed to
grant your app access to data in their organization's directory. This
control affects only the ability to grant access. It does not affect
any access that has already been granted.
And some early testing suggests this does indeed work. However this implies using an Oauth secret which must be embedded in the app and the notes here:
https://learn.microsoft.com/en-us/azure/active-directory/develop/active-directory-protocols-oauth-code
State (in relation to the app secret):
....It should not be used in a native app, because client_secrets
cannot be reliably stored on devices. It is required for web apps and
web APIs, which have the ability to store the client_secret securely
on the server side.
For native apps, the docs here:
https://learn.microsoft.com/en-us/azure/active-directory/develop/active-directory-devhowto-multi-tenant-overview
State:
Native client registrations are multi-tenant by default. You don’t
need to take any action to make a native client application
registration multi-tenant.
Which suggests they should work in the way we desire - however when we test this with OAuth flow from an account not in the same Azure AD where the native app was setup we get the following after authenticating:
AADSTS70001: Application with identifier 'XXXXXXXXXXXXXXXXXXXXXX' was not found in the directory YYYYYYYYYYYYYYYYYYYY
So it appears this does not work. At present the only way it seems to make this work is to create a Web app and embed the client ID and secret in the native application.
Has anybody had success with multi-tenant native apps or any ideas/feedback on what I am doing wrong or could try?
UPDATE I realised there were two things wrong here:
* You can actually click on the "Manifest" button in Azure and edit the raw JSON, updating the 'availableToOtherTenants' value to make it multi-tenant.
* I didn't have the scope=user_impersonation in the OAuth flow.
Now it seems we can create a native app which users in other orgs/tenants can authenticate with.
UPDATE 2 OK so it turns out our app now works for some users but at least one is getting:
AADSTS65005: Invalid resource. The client has requested access to a resource which is not listed in the requested permissions in the client's application registration. Client app ID: AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA. Resource value from request: https://XXX.YYYYYY.com. Resource app ID: ZZZZZZZZZZZ. List of valid resources from app registration: 00000002-0000-0000-c000-000000000000, 00000003-0000-0ff1-ce00-000000000000.\r\nTrace ID: KKKKKKKKKKKKKKKKK\r\nCorrelation ID: CCCCCCCCCCCCCCCCCCC
I can't see why it would work for one user but not another if both are in different tenant/Azure ADs to where the app is created.
If you were developing an native app which access the multi-tenant web API which also developed by you, you can set the add the clientId of native app to the manifest of web app's manifest with knownClientApplications property. So that when other tenant's users access the multi-tenant web API, it will also register the native app to their tenant.
Refer the code sample below which demonstrates a Windows Store application calling a multi-tenant web API that is secured using Azure AD:
active-directory-dotnet-webapi-multitenant-windows-store
I am trying to add Azure Active Directory authentication to my ASP.NET WebAPI.
I followed this tutorial and have configured my tenant and applications in Azure correctly.
Now if I test this locally with a sample desktop client, the authentication works and I can see the authenticated user's claims.
User.Identity.IsAuthenticated = true
However, if I publish my API to Azure (as a Web app), the authentication does not seem to be working anymore, even with the exact same code used to test the API locally... The only this I have to change is the endpoint to my API:
<add key="ApiBaseAddress" value="http://localhost:20105/" />
vs
<add key="ApiBaseAddress" value="https://***.azurewebsites.net/" />
Note that the JWT token passed to the API is exactly the same when testing my API locally and published, as they are authenticating to the same Azure AD and the same user accound.
What could be the source of this problem?
Could it be that azure uses https and I am running on http locally? If so, what could I try to fix this issue?
It seems that when publishing to Azure, some of my Azure AD specific config values in my web.config were replaced...
If you Enable Organizational Authentication, you are able to choose an existing AD, but the deployment just added the config values in a different way than I did.
Unchecking this option and taking care of it myself solved the issue
This might be due to the process you follow for publishing your API. If you are publishing from Visual Studio and you are using the "organizational" settings, the publishing logic will create a NEW app in Azure AD for your cloud hosted web API instance and change the audience settings accordingly. As such, you need to match those changes in the logic requesting a token as well - you need to request a token for your API using the same audience as resource identifier or you'll end up getting a token for your localhost based deployment and send it to your cloud instance, which will reject it.
You can avoid this by opting out of using the organizational settings when publishing your app to the website - that will keep the audience unchanged and allow you to use tokens against local and cloud instances indifferently.