I notice there are several different namespaces/classes for accessing Active Directory. What are the differences between using the following ?
System.DirectoryServices.AccountManagement
System.DirectoryServices.ActiveDirectory
System.Web.Security.ActiveDirectoryMembershipProvider
The items under AccountManagement deal with working with various LDAP type data stores. Not just Active Directory, but NDS and WinNT as well. If you know your backing store is LDAP compliant or may switch between various LDAP stores then this is probably the best to use.
The ActiveDirectory namespace is specifically for AD. Usually you only care to use this if you are going to stay strictly within an AD environment.
The ActiveDirectoryMembershipProvider has a slightly different focus. This is usually used by Web Apps as one of the membership providers. Other membership providers include the SqlMembershipProvider or even custom ones that you might create. This is used when your backing store might be AD, but could also be changed to use SQL server or some other random store in the future.
In summary, it all boils down to how your app currently functions and how it might grow in the future. If you have a desktop app, then use the System.DirectoryServices namespace. If you have a web app that might be deployed into unknown environments, use the membership providers.
Note that I have used a combination of a SqlMembershipProvider and the System.DirectoryServices space together in some apps. Specifically to authenticate into an LDAP store (AD/NDS) while authorization stays in my app.
Related
I'm working on RESTful API that implements OpenID and Oauth2. IdentityServer4 offers both and works perfectly, however nearly all examples and tutorials use in memory Test Users
I've been struggling to understand how I can implement IdentityServer4 with database while having some sort of a services that allows users accounts to be created and managed.
I'm confused whether the registration and account management services should take place on IdentityServer4 itself or somewhere else, on a different project.
I've been trying to glue together IdentityServer4 with ASP.NET Identity in a single project, however I have no idea whether this approach is correct or not.
How would architecture that implements IdentityServer4 and ASP.Net Identity look like? Should I create 2 separate projects, one for IdentityServer4 and the other for ASP.Net Identity, or should I try combining both?
It really boils down to what your requirements are. ASP.Net Identity implements a lot of boilerplate stuff and is good for getting you up and running quickly and it integrates well with IDS4. We used it in our implementation but ended up customizing it a LOT so I'd suggest if your requirements differ significantly from what it provides out of the box it may be more of a pain in the long term to have that additional dependency.
In my opinion it makes sense to treat your identity server as a self contained (micro) service that owns its own data (users, clients, persisted grants etc) and exposes any needed APIs for managing said entities from outside. IDS4 does not stipulate or particularly care how you do user authentication or how you store the data so you're free to implement that any way you like.
Do you have a preference when it comes to database? How will it be deployed?
I currently have an MVC 5 App which uses Windows authentication, from the intranet template. I would like to now expose this to internet users and utilize oauth. It seems that many of the files in oauth walkthroughs are missing from my project. Is there a nuget package I can use to refill the missing files that would have been in the "Individual Users" template, or do I really need to create a new project as OAuth and back fill Windows auth into it?
You can't really simultaneously use both Windows Auth and Forms Auth (Individual User Accounts), with or without OAuth. There's hacky ways to invalidate what I just said, but they're just that: hacky. Really, the only real approach is go Forms Auth and then connect to LDAP manually to sort of proxy authentication from the domain to Forms Auth (basically, you'd have to create a local user account that represents a domain account).
Really, if you need to use simultaneous different forms of auth, the safest and easiest bet is to use separate projects and just share as much of the code as you can, with class libraries, Razor Generator for compiling views, etc. You'd of course have to host each project separately, but you could simply use a subdomain (i.e. internal.mysite.com vs www.mysite.com), or if you got your own network DNS server, you can even map internal requests vs external requests to the two different sites using the same domain.
When creating a new Silverlight 5.0 business application, the authentication and authorization code is automatically generated. All the user info and roles are by default saved in the aspnetdb mdf file. My questions are:
Is it normal practice to keep user authorization/authentication data in separate database from your business related data, or should I copy the tables into my main database? I see that current implementation involves ApplicationId field, so it means that it can store data for different apps? Maybe there is some common database on the web server for all Web apps (just guessing)? :)
If I am to keep the user's info in a separate database, how to relate the data between these two databases? I mean, I will have UserId referenced in some tables (business rules)? My business data is using identity PKs and aspnetdb is using UniqueIdentifier, is this a problem?
When a user registers on the site, how do we assign it roles in production? There is a ASP.NET Configuration tool within Visual Studio, but what about the production environment? Should this be coded in the Web project?
What is the best practice for handling authorization / authentication of users in cases where the application always require authentication?
You shouldn't use the defaut ASP.NET authentication implementation in your production App: It uses a local database (the mdf file) because it works out of the box. However, You are not limited by this solution:
You could configure ASP.NET authentication (and role) provider to use your real database, allowing you to better integrate it into your existing data. To better understand the full process, see http://msdn.microsoft.com/en-us/library/6e9y4s5t.aspx and the linked pages. ASP.NET is able to generate all the required tables in your db by itself.
You could override the default authentication mechanism with your own. In this case you only have to edit the Services/AuthenticationService.cs in your web app project. The AuthenticationService class inherits from AuthenticationBase, and allows you to override quite a lot of membership methods with you own implementations.
I am a newbie to ASP.NET - so what is the pattern to use Isolated Storage vs. Session state for web applications?
I have a use case where when a user logs into the application, I need to create his profile information which will persist throughout his session.
Does it make sense to store this in session or should I use Isolated Storage (assuming the client is on a Windows machine)
Thanks!
ASP.NET has a profile provider that's built to store a user's profile.
You could use your own provider that's session backed if you really only want the profile to last for the duration of the session.
Your last comment makes me think you want to use isolated storage on the client machine; I don't think you can access isolated storage on the client from a browser w/o an ActiveX control or something like that.
Isolated storage is not used in asp.net applications for storing profile info - this is generally used in .net apps running on the client side.
To get profiles up and running, see any of the many posting on it.. a good one by Dino Esposito
http://msdn.microsoft.com/en-us/magazine/cc163724.aspx
and
http://msdn.microsoft.com/en-us/library/2y3fs9xs.aspx
The configuration is there by default but in visual studio you will want to bring up the admin site for your web app to make sure everything is setup.
Using web applications or web sites also gives you different access to profile properties. One will strongly type them, one will not.
Most Real world web applications have at least one dll library behind them. If we use the ASP.NET membership provider, how can we call the Roles.IsInRole method in the dll?
The possibility of referencing HttpContext is not good. Because, we have a few console application tools that use the same dll to complete a few bulk operations.
It sounds like you need to decouple your Membership mechanism from ASP.NET.
There are some good resources here on how to reference the ASP.NET Membership Provider from Windows Forms applications, which would work in the same way for console applications.
The best one is here (in VB.NET).
However, all suffer the same basic problem, which is that a malicious user could change their configuration to use their own authorisation database. (ASP.NET configuration is not available to users so we don't have the same problem there.)
So a better approach would be to either directly query the ASP.NET membership databases from your code in ADO.NET (which isn't hard: they're fairly straightforward) or to roll your own implementation of the underlying Membership Provider interfaces (detailer on MSDN here). You could then have the ASP.NET Membership Provider call your own code to establish if a user is in a role, and use this code in the same way from your console application.