Looking for a bit of advice on where to take a current webapp which supports logins based on active directory and makes use of the built in asp login component.
The problem is that we want to have the option to use the active directory login or a "normal" login using data stored in our local database.
Just to make it clear. On each installed system it would be one or the other so I'm not asking how to check both each login atempt.
Basic flow:
Determine which login mode is set
if active directory
load active directory login form
validate login info against active directory
login to system
else if normal login
load default login form
validate login info against database
login to system
My lack of knowledge on the asp login component may be the problem here but I'm unsure of how to make the login component know which login mode to run the validation on? The login form seems just like a black box, which makes me a little uneasy when using it on such an important task.
Can this be done?
Or..
Should I just write a custom login for the system and be done with it?
The login control will be your friend in this situation, as it simply utilizes the ASP.Net membership provider model. You will not need to change the application at all!
All you need to do is specify in the web.config file which authentication mode you'll be using. This can of course be set up on a machine by machine basis. So, for your active directory machines:
<connectionStrings>
<add name="ADConnectionString" connectionString="LDAP://testdomain.test.com/CN=Users,DC=testdomain,DC=test,DC=com" />
</connectionStrings>
<membership defaultProvider="MyADMembershipProvider">
<providers>
<add
name="MyADMembershipProvider"
type="System.Web.Security.ActiveDirectoryMembershipProvider, System.Web, Version=2.0.0.0,
Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a"
connectionStringName="ADConnectionString"
connectionUsername="testdomain\administrator"
connectionPassword="password"/>
</providers>
</membership>
You can read more on implementing login with membership providers and active directory from http://msdn.microsoft.com/en-us/library/ms998360.aspx.
And then for your machines that will be authenticating against a database, you simply write a custom membership provider that will authenticate against your database. It's really simple, you really only need to implement one method. You can start here: http://msdn.microsoft.com/en-us/library/f1kyba5e.aspx.
Here is a great example also, with a bare minimum of code and an easy walkthrough for setting it up: http://www.15seconds.com/issue/050216.htm
If you use Forms authentication, you could check the user against active directory and against the database and if either returns a positive set the forms authentication to true.
yes and no.
the LOGIN components utilize the Membership provider classes. What you need is to code yourself up a Active Directory version, and tell ASP.Net to look towards it for AD, or to look toward the SQLMembershipProvider if using the database
Related
I work for a company that uses active directory for all computers. Everyone also has a AD user account but this does not mean that they use it all the time. Some users only use them for certain applications. For the most part, all general users just use a generic login out in the work areas.
I am new to MVC and I am trying to learn to do everything the proper way. I currently have an application that was written in JAVA that I need to convert to asp.net mvc. I want to make it so that users who are logged in under the shared username are required to login using their own AD credentials to authenticate and impose as themselves from then on in the application.
From what I can make sense of on google, I will need to make a custom authentication method. If so, maybe someone can graciously point me in the right direction.
Any help is greatly appreciated. Thank you all.
Assuming you are on IIS7, a former IIS team member wrote a very useful blog on combining windows and forms authentication.
I have and am currently using this in a production intranet system and the following are my comments on how to setup
Unlock the and configuration sections before you can use them in web.config:
%windir%\system32\inetsrv\appcmd unlock config /section:anonymousAuthentication
%windir%\system32\inetsrv\appcmd unlock config /section:windowsAuthentication
Register the forms authentication wrapper configuration section in your web.config:
section name="formsAuthenticationWrapper" type="Mvolo.Modules.FormsAuthConfigurationSection"
Replace the built-in Forms Authentication module with the wrapper:
<remove name="FormsAuthentication" />
<add name="FormsAuthentication" type="Mvolo.Modules.FormsAuthModule" />
Set the required settings for the gateway page:
<security>
<!-- Enable IIS Windows authentication for the login page -->
<authentication>
<windowsAuthentication enabled="true" />
<anonymousAuthentication enabled="false" />
</authentication>
</security>
That should do it.
I'm trying to implement Asp.Net Identity 2.0 (OWIN) in an existing application and I'm having all sorts of trouble when it comes to roles. I created a sample project from the project template and (as far as I can tell) I've copied everything from there into my application. I modified the connection information so the authentication tables come from my own Sql database instead of the default local DB.
Everything seems to work great. The tables are initialized (created) upon start-up and I can create a new user, assign a role to that user, and log in as that user. But when I attempt to check if the user is in a particular role I get an exception indicating a problem locating the local database. Well that would be because I'm not using the local DB. So why would my application be looking for roles in the (non-existent) local DB?
To rule out weirdness in my Sql instance, I changed the connection data of the sample app so that it points my DB and ran it. I can log in using the user I created in my application and can even poll the user for the role in question successfully. I confirmed this by examining the tables directly and verified the user, role, and user-role association were all there.
Here's what I did notice though. When I run the sample app the user is an instance of System.Security.Claims.ClaimsPrincipal. But when I run my app the user is an instance of System.Web.Security.RolePrincipal.
So, what did I miss? Why is my app returning a RolePrincipal instead of ClaimsPrincipal? Where could I look for clues?
I'm pulling my hair out on this and I don't have much left! Any help would be greatly appreciated.
What is happening is your old application is still hooking up to the old membership code. A few checklist items should bring you back...
Make sure FormsAuthenticationModule is removed (Since MVC5 no longer uses it)
<modules>
<remove name="FormsAuthenticationModule" />
</modules>
Make sure SimpleMembership is turned off (or alternatively just delete it)
<add key="enableSimpleMembership" value="false"/>
And the most important part is to delete references to WebMatrix (no longer used in MVC 5). WebMatrix will automatically register pre-application startup methods that will "attempt" to provide membership services to your project. See here for details
I had to remove RoleManager as well:
<modules>
<remove name="FormsAuthentication" />
<remove name="RoleManager" />
</modules>
I've got multiple membership providers in my web.config and in my login control,
I am going to use the provider based on a drop down list with the name of the provider.
Web.config:
<system.web>
<membership>
<providers>
<remove clear />
<add name="MyOwnProvider1" .... />
<add name="MyOwnProvider2" .... />
</providers>
</membership>
</system.web>
In Login.ascx.cs:
I am selecting the provider based on a drop down list like so:
MembershipProvider provider = Membership.Providers[dropDownList.SelectedItem.Text];
Problem is whenever I hit this line, it always tries to connect to MyOwnProvider1 when in fact MyOwnProvider2 was selected!
Any ideas?
The cause of the problem you are having is that when the app is spun up, either the provider flagged as defaultProvider in the membership element OR the first provider encountered, starting with your web.config and moving upstream to the root web.config in the .net framework/config directory, is initialized, making it the membership provider.
Couple this behavior with the fact that all of the baked in plumbing and controls are expecting to work with a single provider and you are uscwap.
In order to make something like this work, you are going to have to implement a single custom membership provider that acts as a facade or aggregator for your multiple authentication sources and add that as the single provider in web.config.
Cheers
Is it possible to dynamically select a provider that way? I've always assumed not (though I've never tried it), in this instance I'd guess that when it loads Membership.Providers it stops at the first one it comes to, MyOwnProvider1 in your case.
We use ELMAH error exception logging in our application. I'd like to keep ELMAH secure from regular users while still making it available to administrators/developers of the application.
When you set security with forms authentication in the web.config you then lose the ability to access the RSS feed. I'd like to be able to secure ELMAH but yet still pass through authentication to the axd to be able to access the RSS feed (i.e. /elmah.axd/rss) from a RSS reader.
Thinking that http authentication would be proper as then I can probably get to the rss feed with the following url syntax http://username:password#somedomain.com/elmah.axd/rss I assume you would need to set authentication mode="windows" on that specific path in the web.config. One issue pops up though is how do you set credentials on a virtual file?
Looking at Google brings back this article on CodeProject on how to set up authentication passthrough with cookies. Is this a good solution to my problem?
Is there another way that is better to be able to access the RSS feed while still being secure?
Thanks.
Supporting HTTP Authentication and Forms Authentication in a Single ASP.NET Web Site
Basically you add a dll called MADAM to your project adjust your web.config and configure which file(s) you want to authenticate as Basic instead of Forms:
<configuration>
<configSections>
<sectionGroup name="madam">
<section name="userSecurityAuthority" type="System.Configuration.SingleTagSectionHandler, System, Version=1.0.5000.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" />
<section name="formsAuthenticationDisposition" type="Madam.FormsAuthenticationDispositionSectionHandler, Madam" />
</sectionGroup>
</configSections>
...
<madam>
<userSecurityAuthority ... />
<formsAuthenticationDisposition>
<discriminators all="[true|false]">
...
</discriminators>
</formsAuthenticationDisposition>
</madam>
...
<system.web>
<httpModules>
<add name="FormsAuthenticationDisposition" type="Madam.FormsAuthenticationDispositionModule, Madam" />
<add name="AuthenticationModule" type="MADAM Authentication Module Type" />
</system.web>
</configuration>
This was easy to set up and solved my problem of being able to authenticate elmah.axd and still be able to subscribe to the RSS feed with Basic authentication credentials.
Side note MADAM is written by the same guy that wrote ELMAH, coincidence?
Depends on the client I guess - I know some desktop readers (sure others do, as well) support feeds that require authentication, and provide a login box when first requesting it - not sure what they are doing behind the scenes to make it work though.
Sorry for the poor title here :)
I have my WSS configured for Forms Authentication. I'd like my users to land on the WSS login page, log in, and then provide them links to other ASP.NET apps which also are configured for forms authentication. I'd like to achieve a single-signon-ish solution (the reason I say "ish" is I'm not looking to implement SSO per-se, as in SAML, but rather achieve the similar effect of not forcing the user to re-enter their credentials). You can assume the forms auth credentials that WSS uses are the SAME as those in the subsequent forms auth apps I want to provide the links to.
Does this require code on the WSS side, or can I make this happen non-programmatically on the ASP.NET/IIS configuration side?
Thanks
What is your Forms Authentication Provider?
On Active Directory (for instance) your browser will remember what your authentication was on the first entry site and carry it for you.
Having this on the web.config file of both ASP.NET and SharePoint sites:
<connectionStrings>
<add name="ADConnectionString"
connectionString=
"LDAP://testdomain.test.com/CN=Users,DC=testdomain,DC=test,DC=com" />
</connectionStrings>
<membership defaultProvider="MyADMembershipProvider">
<providers>
<add
name="MyADMembershipProvider"
type="System.Web.Security.ActiveDirectoryMembershipProvider,
System.Web, Version=2.0.0.0,
Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a"
connectionStringName="ADConnectionString"
connectionUsername="testdomain\administrator"
connectionPassword="password"/>
</providers>
</membership>
Will ensure they will both use the same authentication providers and therefore once the browser has the information about their identity, it will recycle it accordingly throughout.
Other wise, try a Federation Service.
Here is a tutorial on how to use ADFS
Hi Ric thanks for the response. I think I found my answer. Forms authentication is all about the cookie, so if I configure both the ASP.NET web app and the Sharepoint virtual directory to use the same authentication cookie, I should get single-sign on between them. I'm going to try.
UPDATE: This works nicely.