According to the Azure Graph API team's blog, they've changed the way permissions are handled in Azure AD-authenticating apps.
This error has been driving me nuts for the past month while I've been able to get into an app we're writing in Azure using AD, but my team hasn't.
Here's how we fixed our issue:
1) I could get into our app (because I setup the permissions with my account in the management portal), but my team couldn't.
2) Had to go talk to one of our DevOps guys who's a Global Administrator in our Azure tenant, got him to remove the permission in the Azure AD Application, then re-add it.
Now my team could get in.
Hope this helps anybody stuck on this
Showing posts with label impersonation. Show all posts
Showing posts with label impersonation. Show all posts
Saturday, October 17, 2015
Monday, May 18, 2015
Creating an Intranet MVC 5 application using Windows Authentication that connects to a separate Intranet Web API 2 application also using Windows Authentication
Recently I wanted to create an Intranet MVC application using Windows Authentication that connects to a separate, pre-existing Intranet Web API 2 web service that also uses Windows Authentication. In order to get the Windows Authentication of the MVC application propagated to authenticate with the Web API 2 web service, I had to do the following:
1) Place the following in both applications' <system.web> sections in their respective configuration files.
4) Use the following to connect to Web API 2:
As a side note, apparently there's also a way to change the settings so that you don't have to modify the global aspnet.config file, you can do it on a per-AppPool basis. The technique is described here, though I've never tried it myself.
1) Place the following in both applications' <system.web> sections in their respective configuration files.
2) Update the .NET aspnet.config file located at "C:\Windows\Microsoft.NET\Framework\v4.0.30319\Aspnet.config" to change the following settings to the following values:<authentication mode="Windows" /><authorization><deny users="?" /></authorization>
3) In the code for the MVC app that wants to call the Web API 2 app, do the following:<legacyImpersonationPolicy enabled="false"/><alwaysFlowImpersonationPolicy enabled="true"/>
This last bit is necessary to ensure that the currently authenticated user in the MVC app gets correctly propagated to the Web API 2 app. In the service that's mentioned in the code above, you'll also need to do the following for interacting with Web API 2:WindowsIdentity identity = (WindowsIdentity) this.HttpContext.User.Identity;using (identity.Impersonate()){searchModel.SearchResults = this.webApiService.FindWebApiItems(searchModel.SearchCriteria);}
4) Use the following to connect to Web API 2:
HttpClientHandler handler = new HttpClientHandler
{
PreAuthenticate = true,
UseDefaultCredentials = true,
Credentials = CredentialCache.DefaultNetworkCredentials
};
using (HttpClient client = new HttpClient(handler))
{
string result = client.GetStringAsync(uriBuilder.Uri).GetAwaiter().GetResult();
IList<MyWebApiModel> webApiModels = JsonConvert.DeserializeObject<MyWebApiModel[]>(result);
return webApiModels;
}
You should now have working code to propagate Windows Authentication via services.
As a side note, apparently there's also a way to change the settings so that you don't have to modify the global aspnet.config file, you can do it on a per-AppPool basis. The technique is described here, though I've never tried it myself.
Labels:
API,
asp.net,
authentication,
impersonation,
mvc,
web,
webapi,
webapi2,
windows
Subscribe to:
Posts (Atom)