With the recent release of .NET Core 1.0, we're in the process of migrating our RC1 applications to the final release. The only piece we can't seem to figure out is how to integrate Active Directory authentication.
Previously in the RC1 applications, we had used the System.DirectoryServices.AccountManagement library to handle the LDAP authorization queries. However, we can no longer mix this library with .NET Core v1.
Generally, what is the best way to integrate Active Directory authentication into our applications using the libraries available for use in the .NET Core framework? IdentityServer, some other third party service like Auth0 or something else?
The Novell.LDAP library has been ported to .NET Core you can find it in NuGet. There are numerous samples available, including a verify password sample.
Best is subjective, really there's only one way right now, given the missing DirectoryServices namespace (which is planning for 1.1) - federation.
You'd have to install ADFS, and expose it to the internet. Then you configure it to act as an OAuth2 endpoint, and use the generic OAuth middleware to redirect logins to your ADFS server. You could also install the latest ADFS beta, which needs the latest Windows Server beta, and use OpenID Connect, but that's a lot of beta risks you may not find acceptable.
Or, if you just want the latest MVC pieces, run it on .NET Desktop, where you have full access to the directory services namespace.
The System.DirectoryServices namespace is currently being implemented in .NET Core, work is ongoing.
https://github.com/dotnet/corefx/issues/2089
Just want to say that they just issued a pre-release of the Microsoft.Windows.Compatibility which contains the System.DirectoryServices components needed to integrating with Active Directory
https://www.nuget.org/packages/Microsoft.Windows.Compatibility/2.0.0-preview1-25914-04
Related
Is there a "best" way of achieving this?
Basically I want to leverage my company's Azure AD tenant to build a fully featured internal application. Using Microsoft Graph, I can retrieve users via their identifier guids, and use the identifiers as foreign keys for various tables in our on premises database, instead of having a dedicated User table, which would need to be populated and synced up with the AD. There are many other prospective uses for Graph, but leveraging users is the priority right now.
A large chunk of my application is built already. I am able to lock down my client app using the package react-aad-msal, requiring users to authenticate through single-sign-on. I have also successfully been able to pass that token back to the protected .NET Core API, accessing various endpoints as the authenticated user.
From here, I am not sure how I can develop the calls to Microsoft Graph. At which point should I make the connection? Should the client application connect to both the on-prem API, as well as Graph? Or should it only connect to the on-prem, which would then connect to Graph? Curious to know the pros and cons of either method.
I've also heard tell that Microsoft is working on their own package: #azure/msal-react, and that react-aad-msal should no longer be used (as it only supports msal 1.0 and not 2.0. I have no idea which version is better for my needs). While msal-react is still in development, apparently I should be using #azure/msal-browser. But I cannot find a good example of a react app using msal-browser to authenticate.
Here is a Sample on how to use MSAL with React to call Microsoft Graph.
The only different in your case will be that instead of calling Microsoft Graph, you will call your own API.
Bottomline is - there is no direct integration package yet for react. Which can also be read from the official statement on the msal-js repo:
After our current libraries are up to standards, we will begin
balancing new feature requests, with new platforms such as react and
node.js.
You can also use .net core instead. Please go through the sample here which can help.
I want to develop a Java Web App to consume some Microsoft Graph Services. According to Azure Portal's "Quick Start" tab, they recommend MSAL to authenticate and call the services (com.microsoft.aad.msal4j.*).
On the other hand, I've found https://github.com/microsoftgraph/msgraph-sdk-java-auth, which offers a nice API to use the services, but the last uptade is from more than a year.
Which should I use? I'm a bit afraid the SDK gets deprecated.
Thanks.
If you have a look at the dotnet version of this library, you'll see it uses MSAL. Whenever the Java msgraph auth library was started, MSAL Java wasn't ready. There's work that needs to be done to align the Java auth library with the dotnet one so it uses MSAL as well. I'd say go ahead and use the Java auth library keeping in mind a few things:
It will change as the required work gets done
Auth libraries for msgraph SDKs are all in preview and might change in the future
There's currently a limitation addressed by this pull request and that you can workaround as documented here
I have a .NET Core 3.1 WPF app that I'm working on. In order to work with our older application it needs to validate credentials that are entered into a dialog for a local account. How can this be done?
It appears that all of the necessary classes have not been included in .NET Core yet, because the System.DirectoryServices package does not yet have the AccountManagement.PrincipalContext class that used to be used for this purpose.
Clarification
I have to validate creds for an arbitrary user account that may or may not be the account executing the app.
I hate to tell you, but the simple answer is that you can not. Interaction with active directory. There are limits on how integrated DNC 3.1 is - and you stumbled upon one. Supposedly dotnet 5.0 will better integrate.
For now, you can either use win32 / native syntax for this, or use a server side proxy that handles the authentication.
To my knowledge, you re requirements are simple not implemnented in the scope of the platform chosen.
Anyone please feel free to correct me.
Update: This is doable in .NET not core - so you can put up a smple website for this as service in .NET. So from the wpf side this turns into "make a http request".
I developed a test .NET Core Web App to which I added the .doc to .pdf conversion tool GemBox.
Their documentation for Azure deployment combined with .NET Core is limited to non-existing and their support guys could not help me with a clear solution either.
The error I get:
HTTP Error 500.31 - ANCM Failed to Find Native Dependencies Common
solutions to this issue: The specified version of
Microsoft.NetCore.App or Microsoft.AspNetCore.App was not found.
I tracked down the problem to the following issue:
GemBox.Document for .NET Core 3.0 uses WPF.
Is it possible that App Service added a limited support for WPF?
Thanks,
Lorena
The latest released version of GemBox.Document have cross-platform support for saving to PDF which doesn't have a WPF dependency, see the release post or the ASP.NET Core example.
So, you can now use GemBox.Document on Azure services, such as App Service, Azure Functions, etc. without any issue.
I built an Azure WebAPI. I did not create the project with Authentication at the time it was first created. I added Active directory Authentication based on a code sample from Microsoft. It utilizes Microsoft.IdentityModel.Clients.ActiveDirectory which I got from NuGet. It works just fine.
I then created a WebAPI from VS 2017 and selected Authentication (using AD) at the time of project creation. It included Microsoft.AspNetCore.Authentication.AzureAD.UI.
I am not sure of the difference between these two NuGet modules nor which is better suited for my Azure WebAPI.
Then comes the modules to use in a .NET WPF client. There is no AuthorizationContext class (and others) in Microsoft.AspNetCore.Authentication.AzureAD.UI. Should I stick with Microsoft.IdentityModel.Clients.ActiveDirectory in the .NET WPF client or are there equivalents in Microsoft.AspNetCore.Authentication.AzureAD.UI?
For your web api project, answer is it depends on what you're trying to do from within the web api. For most simple scenarios where you just need to read/validate tokens, you should be good with the added Microsoft.AspNetCore.Aurthentication.JwtBearer nuget pacakges. More detailed question/answer available in this SO post
In case of your WPF client application although, you won't have much choice. You will need to work with ADAL or MSAL based on which AD version/endpoints you want to use. Also, in case of WPF client more probably than not you will need to acquire a token from Azure AD so internal operations (which library will take care of under the hood e.g. authenticationContext.AcquireTokenAsync) will be a little more involved than just reading the provided token from a header and hence the package.