We have several web applications. When we run anyone of them we enter username and password and some cookies (user id) have been sent to client computer. When we run some another application, we should be able to check if we already logged on in some of our applications and if so, we automatically logged on to other applications without entering username and password.
It seems we should search for cookies in other applications to check if they exist. As I know cookies exist in context of particular web application and I'm not sure if we can check their existence in other applications.
How to resolve this?
If your web applications are being hosted in sub-domains of the same domain (e.g. exchange.contoso.com and mail.contoso.com), then you can easily exchange cookies between sub-domains by setting the "Domain" property of the HttpCookie object to .contoso.com:
Response.Cookies["auth"].Domain = ".contoso.com";
Hope this helps.
Related
After we have moved to Azure farm, I have implied Azure Session State Provider (redis) to my asp.net mvc application, But some Authorized pages redirect me to login page !!
Is that because I use User.Identity.Name or User.Identity.IsAuthenticated in some actions!!
Do I have to replace the User.Identity.Name with :
// instead of below line
//Boolean usern = User.Identity.IsAuthenticated;
// is below lines :
Boolean usern = "";
object objValue = Session["usersession"];
if (objValue != null)
{ usern = true;}
else {usern = false;}
Is that right, if not why users redirect to login again sometimes !!!
This is probably not a session issue but rather an authentication cookie/ticket issue. Azure most likely has their servers load balanced, even if you are only using a single instance/role(this gives them reliability %). Meaning that your application actually exists on more than one server at a time.
The MachineKey in a .NET app is what is responsible for encrypting and decrypting your authentication cookie. In your web.config, if you are not properly defining the <machineKey> attribute, then IIS makes up a machine key for you. Each server running the application will make their own machine key if it is not defined by you. As a result, one server is able to decrypt and read your authentication ticket, while the next request goes to another server which cannot decrypt the authentication ticket because it was encrypted with a different key and this server thinks that you are not logged in.
To address this issue, open your web.config file and define your <machineKey> attribute and redeploy. Once you login with the newly deployed application, you should see this issue disappear.
Forms authentication and Machine Key information on MSDN
Machine Key Generator
I don't think the session management would do this, regardless of Azure Redis or otherwise. If you are using asp.net authentication cookies you need to make changes to support multiple roles.
I know this is an old article but if you look through Moving Applications to Microsoft Azure Cloud Services you will see this:
There is one further change to the application that potentially
affects the authentication process. If you were to run the aExpense
application on more than one web role instance in Azure, the default
cookie encryption mechanism (which uses DPAPI) is not appropriate
because each instance has a different key. This would mean that a
cookie created by one web role instance would not be readable by
another web role instance. To solve this problem you should use a
cookie encryption mechanism that uses a key shared by all the web role
instances. The following code from the Global.asax file shows how to
replace the default SessionSecurityHandler object and configure it to
use the RsaEncryptionCookieTransform class.
essentially if this is happening the redirects to the login page are because you are bouncing to a different instance and it could not read the asp.net auth cookie and just assumed the user was not authenticated as a result.
I have a parent application in IIS7 which uses Forms authentication. Within that app, I have another application (not virtual directory) which I would like to inherit the parents forms authentication settings.
The authentication in the child app is not working, when i call System.Web.Security.Membership.GetUser() it returns null.
Both the web.configs have the same authentication sections, both are set to have the same machine key and both are using the same app pool. Does anyone else have any more ideas?
Thanks
Without a proper look at the applications its difficult to see what could be happening, however, I do have a suggestion. Previously, I've written a class the encrypts the username in a cookie using something like a session id as a hash.
The next app can then check for the cookie, decrypt the username and authenticate the user.
The only issue with this is the cookie access. It only works for apps with the same parent domain. E.g. A cookie of domain.com would be accessible to www.domain.com, app1.domain.com and app2.domain.com.
Another solution, that would get around the domain issue, would be a Shibboleth implementation.
I have an ASP.NET application that uses Forms Authentication.
I need to call the Sharepoint search.asmx web service to retrieve a list of files from the network satisfying the search criteria (there's a good reason for me doing this outside of Sharepoint)
I'm not sure of the security information I need to pass the search.asmx. I've tried:
queryService.ClientCredentials.Windows.ClientCredential = System.Net.CredentialCache.DefaultNetworkCredentials
queryService.ClientCredentials.Windows.AllowedImpersonationLevel = Security.Principal.TokenImpersonationLevel.Impersonation
-which works in my development environment as my user has access to the File Shares Sharepoint is accessing. What I can't understand, and can't infer from debugging or event viewers, etc. is what credentials are passed in the above code once I deploy this code on a server.
Will it pass the windows credentials of the user who opened the IE window prior to using forms authentication. Will it pass the credentials of the account that is running the asp.net components i.e. the account of the AppPool I'm running in, or will it pass something else?
I can't seem to get Sharepoint to return any files and I guess it's because the credentials being passed don't have access to the File Share.
Thanks
Andy
To get this working quickly you can access the SharePoint webservices with your username & password. This isn't the best solution long term obviously.
Set the Credentials property on the SharePoint webservice proxy to your username & password:
spProxy.Credentials = new NetworkCredential("username", "password", "domain");
You'll need to make sure the credentials property is set before you call the webservice.
I'm not a SharePoint expert (I've only used it as a developer), but I believe it only uses Windows authentication to secure the webservices. So forms authentication isn't going to help you out here if you want to access the webservices as the logged in user (unless you're validating the username & password manually with LDAP). ASP.NET Impersonation & Delegation only makes sense if you are using Windows authentication.
As stated by pseudocoder you might want to setup a special account to access SharePoint from the web server.
I'm wanting to secure ELMAH in an internet facing application. The system uses Forms Authentication, but doesn't currently have any non-user accounts (e.g. Admins). The user accounts are set up in an automated fashion.
I don't really want to shoehorn any admin accounts into the system (the current DB schema for the users would be quite inappropriate for storing an admin user in), so I was thinking of corrupting the Forms authentication by checking for an SSL client certificate. If I pick all the right options in IIS, I believe I can ensure that only certificates issued by our internal CA (currently used for non-production sites needing SSL certs) will get passed through to ASP.Net.
I can then use the presence of a Valid ClientCertificate (checking IsPresent and IsValid properties of Request.ClientCertificate) to know that this is a connection from an internal user, and set the Forms Authentication cookie as "Diagnostic" or "Admin" (Or any other special username), and then secure elmah.axd using any of the usual methods suggested for doing it via Forms Authentication.
So my question is - am I overcomplicating things, missing something obvious, opening a massive security hole, etc?
Why don't you just store an admin user account credentials within Web.Config and lock down the URL using Forms Authentication anyway?
Edit
Ok, if the application is entirely internal anyway, why not secure a subdirectory of your site (e.g. myapplication.domain.com/exceptions/elmah.axd or even just myapplication.domain.com/elmah.axd) using Active Directory and set authorisation through IIS?
I want to be able to authenticate an NT username/password combination through an ASP.NET site, completely separate from the username that's recognized through Request.ServerVariables("LOGON_USER") and the like. There are accounts that will have the rights to completely override others, but the users will still have to enter the correct password to do so.
I tried using the LoginUser function from advapi32.dll, but that only tries the login for the local machine (which would be the application server). Is there something that will work for checking the network in general?
You could authenticate against Active Directory.
An ASP.NET application can use Forms
authentication to permit users to
authenticate against Active Directory
using the Lightweight Directory Access
Protocol (LDAP). After the user is
authenticated and redirected, you can
use the
Application_AuthenticateRequest method
of the Global.asax file to store a
GenericPrincipal object in the
HttpContext.User property that flows
throughout the request.
http://msdn.microsoft.com/en-us/library/ms180890
Have you thought of using LDAP and ADAM (Active Directory in Application Mode)?
That would allow you to authenticate users in the manner you're seeking. I found a few articles for you:
http://www.c-sharpcorner.com/UploadFile/wojtekpiaseczny/AdamAuthentication10262006124310PM/AdamAuthentication.aspx
http://www.15seconds.com/Issue/060525.htm\
http://msdn.microsoft.com/en-us/library/aa302397.aspx