I am using ASP.NET membership to control access to my application. Several pages in my application require read access to files on a network share (set up as an IIS Virtual Directory). Without membership, I just use impersonation to access the network share using a single predefined account. However, when using membership, how do I gain access to the network share with all of my "members"?
covered for a custom provider here, probably easy enough to do for yours as well.
Inherit built-in provider and implement impersonation inside
Related
I am aware of ASP.NET Authentication using Identity. So, if my application already has Authentication enabled, why would I want to enable IIS authentication on top of that?
Also, if I have both enabled, will that require a user to type in his or her credentials twice (once for the application login and then for the IIS login)?
Both are different things altogether.
ASP.NET Authentication using Identity in your web application is used for authentication & authorization of End-User in your application.
IIS authentication is for security and access management for hosted application.
If we explore a little further why this is needed. End-user just need to rights for viewing data & doing operations using User Interface Screen.
IIS user(used for IIS autehntication) might need right for creating schema, modifying schema as in Continuous Integration (CI) when you deploy code, new schema is created or existing schema can be modified.
Also in multi-tiered application, we can choose to run service(web services, web API, WCF
etc) under end-user authentication if needed OR user with more rights is required.
All decisions depends on your architecture, needs & security requirements. No choice is good for all architecture needs. We need to choose what suits our requirement best in given scenario and we design in such way application is further extensible/scalable for higher loads and easier for maintaining code too in long support.
We have used ASP.NET Identity Management in a website. It is used to authenticate users as well as manage their Roles to access specific functionality of website.
My question, Is Cognito something that meant for similar purpose? Can it replace ASP.NET Identity Management? Does it hold functionality for creating, managing and assigning Roles to users to access specific features/pages of my website?
Thanks for any help.
Overall, the functionality is very similar although there might be some subtle differences. Cognito allows you to add authentication to your application. And with the new groups feature, it allows particular users to have access to specific resources.
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.
I have a Webpage made with ASP.Net and another set of tools like a WPF, Windows Forms applications. Is mandatory that the ASP.Net webpage and all the set of applications be authenticated against the same ASP.Net membership provider database.
What I want to know is the best way to authenticate using a WCF service that uses ASP.NET membership provider for the authentication. Is anything made out of the box for authenticate a ASP.NET webpage against a WCF authentication service? I have to implement a Custom Provider? Because the Membership in ASP.NET Webpage fill the IPrinciple User property with user information and I want the same behaviour with a WCF service authentication.
a custom membership provider is how i have done this before. it worked pretty well. my group made the mistake of making the wcf service match the interface of the membership provider, which was unnecessary and messy. if you choose to go this route, i'd recommend making your service contract on your own as you want it and implementing your provider to consume that.
if i was doing it again, though, i wouldn't use wcf at all, but rather just use a membership provider (existing or a custom one, depending on your needs) for the asp.net application that talks directly to the database rather than a wcf layer and have a shared assembly the other tools could use that talks directly to the database. even having common code in a wcf service tier. i don't think using a service really provides a whole lot that you couldn't get by just using a common assembly. the asp.net membership provider is going to be something separate anyway.
this is assuming you are within an environment where you can just have the desktop tools connect to the database. if this is an internet deployed scenario, you probably do need to do this through some kind of service, and wcf is a great candidate for that. it's probably a shorter path, though, to use an existing membership provider and build your wcf service on top of the database that goes with that than to build a membership provider that consumes the wcf service. i don't think it would be a bad choice to do the latter, but you'd probably be better off with the former. this, of course, depends on a lot of factors, though.
We're planning to use standard ASP.NET user authentication for our application. However, by default this requires us to have our user database on our web server in the App_Data folder.
This is usually a big no-no for us - our databases are all behind the firewall and all access is done via a WCF Service layer.
If the database was on a different server, but directly accessible from the web server then this still vioates our usual architecture rules.
Should we worry about our user database living on our web server? Does ASP.NET offer an out-of-the-box alternative?
NOTE: We're using .NET 3.5 and SQL Server 2005
You can install the neccessary db tables etc. in any SQL Server database.
Use the aspnet_regsql.exe Wizard found in C:\WINDOWS\Microsoft.NET\Framework....... to set up the target database.
Then simply update the connection strings in the provider configurations in the web.config.
Yes and Yes.
If you ever need to move to multiple web servers you shouldn't have the user data on one of those servers.
There are multiple was to do this, but check out this link for details on one MSDN How To: Use Forms Authentication with SQL Server in ASP.NET 2.0
you can create your own Custom membership provider by overriding the methods and properties of the following abstract class: public abstract class MembershipProvider. Once you override them, then you can use any valid datasource to authenticate the user. For example, you can use MYSQL, SQL server or even XML file to authticate your users. These provider models are really really cool.
Yes, you should worry. No, there is no out-of-the-box solution. ASP.NET only ships with a SQL Membership Provider and an Active Directory membership provider (reference). You will have to use a custom membership provider to provide your functionality.