I have a following architecture:
1) client logins to ASP.NET web site (www.site.com) where the session expired in 3000 minutes and cookieless set to false.
2) After some time client opens Activex in browser. Activex connects to Session Enabled Web Service (www.site.com/Service.asmx) through .NET managed classes.
What I need to do is send cookies which browser recieved while authenticated through Web site. and if such cookie does not exist then the user is not authenticated and connection to Web service will be prohibited.
I understand that I need to use System.Net.CookieContainer class, but How do I set this broser cookie to this class?
localhost.WebService1 web = new localhost.WebService1();
System.Net.CookieContainer cookie = new System.Net.CookieContainer();
web.CookieContainer = cookie;
Brings me into totally new session.
Please help.
Best regards,
Danny.
The ActiveX control is a completely separate process and will create its own session every time. Even though it uses the same browser as its container, it basically like running a separate application to connect to the webservice. To get around this, an idea would be to pass some kind of time-sensitive key/Guid to the ActviceX control (sent to the ActiveX control via javascript) This key (saved in database, created by the page) could be passed into the WebService and validated?
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 very good understanding on asp.net session management.
But i have few questions around that.
when session id is get created. when client login to application with user name and password. or when client try to access default.aspx page.
how server serve client session request.
can we access session id in js?
is there any difference between ASP.NET web form and ASP.NET MVC in terms of client server session creation?
Any links/book which gives me very depth idea about session will helpful for me.
Thanks in Advance !!!
Prashant
I have very good understanding on asp.net session management.
I think that you are misusing the terms here. ASP.NET Session is one thing, Forms Authentication is an entirely different thing. I suppose that you are talking about Forms Authentication here.
1) when session id is get created. when client login to application
with user name and password. or when client try to access default.aspx
page.
When someone calls the FormsAuthentication.SetAuthCookie method which usually happens once the username and password credentials are validated by the LogOn action.
2) how server serve client session request.
A forms authentication cookie is emitted to the client when the FormsAuthentication.SetAuthCookie method is called and this cookie gets sent to the server on each subsequent request. The cookie contains an encrypted value of the username that allows the server to populate the IPrincipal.
3) can we access session id in js?
No, the forms authentication cookie is emitted with the httponly flag meaning that it is not accessible to client scripting.
4) is there any difference between ASP.NET web form and ASP.NET MVC in terms of client server session creation?
They are absolutely the same. Actually there's no such notion as ASP.NET MVC client server session creation. All this mechanism is coming from ASP.NET.
Now let's suppose that you actually talked about ASP.NET Session in your question. I will try to answer your questions in that context:
1) when session id is get created. when client login to application
with user name and password. or when client try to access default.aspx
page.
Whenever some server side code attempts to read or write to the session using the HttpContext.Session property.
2) how server serve client session request.
A session cookie is emitted to the client when the some server side script attempts to read or write to the HttpContext.Session object. This cookie gets sent to the server on each subsequent request. The cookie is just an id that allows to access the session data which is stored on the server. By default session data is stored in memory. But you could also configure ASP.NET to store it out-of-proc or in SQLServer. For more information about the various session state modes please refer to MSDN.
3) can we access session id in js?
No, the ASP.NET session cookie is emitted with the httponly flag meaning that it is not accessible to client scripting.
4) is there any difference between ASP.NET web form and ASP.NET MVC in terms of client server session creation?
They are absolutely the same. Actually there's no such notion as ASP.NET MVC client server session creation. All this mechanism is coming from ASP.NET.
I'm building web portal in ASP.NET MVC 3 that uses distant web service as only way to communicate with database. Web service has requirement to always have Username/Password passed in request header, otherwise it rejects the call.
I have overridden ASP.NET Membership so that my ValidateUser method sends Username/Password to web service Login method, and returns true/false if authentication is successful. It works quite nice with AcountController provided with MVC 3 Empty internet template. Since I have to pass Username/Password on every web service call, I'm saving them in Session.
My problem is:
If I close browser and reopen it... I remain logged to website, but my Session variables are expired, so none of my requests to web service are being accepted, even though I'm still logged with credentials.
I'm looking for nice suggestion how to sync user logged in state with session state. Either to keep them both persistent until log off is used or to have them both dispose on browser being closed.
Thanks for all suggestions :)
When the user signs in using your AccountController, try setting the auth cookie like this:
FormsAuthentication.SetAuthCookie(model.UserName, false);
This should tell ASP.NET to delete the cookie when the browser window is closed. Then, when user opens up a new browser, both the session and the auth cookie should both be destroyed.
Sessions are cookies on the client side. Forms Authentication (which uses your membership provider) also uses cookies.
They are different.
Is your auth ticket or cookie persistent? This MS KB will explain things and scenarios in more detail than I would here...
Hth.
I'm writing an ASP.net application that uses Windows Identity Foundation. My ASP.net application uses claims-based authentication with passive redirection to a security token service. This means that when a user accesses the application, they are automatically redirected to the Security Token Service where they receive a security token which identifies them to the application.
In ASP.net, security tokens are stored as cookies.
I want to have something the user can click on in my application that will delete the cookie and redirect them to the Security Token Service to get a new token. In short, make it easy to log out and log in as another user. I try to delete the token-containing cookie in code, but it persists somehow.
How do I remove the token so that the user can log in again and get a new token?
I found the solution. To put it succinctly:
Dim smartWsFederationAuthenticationModule As _
Microsoft.IdentityModel.Web.WSFederationAuthenticationModule = _
HttpContext.Current.ApplicationInstance.Modules("WSFederationAuthenticationModule")
smartWsFederationAuthenticationModule.SignOut(True)
See here for more information: http://garrettvlieger.com/blog/2010/03/refreshing-claims-in-a-wif-claims-aware-application/
I also see that I can get handles to some other parts of the WIF framework this was, as well. It's definitely worth the read.
Cookies are a bit strange. They are managed by the browser and there is no "Method" to delete them. Just deleting them from the Request or Response objects on the server side does not remove them from the browser on the client side.
To "Delete" a cookie you have to set it's expiration date to the past.
See: http://msdn.microsoft.com/en-us/library/ms178195.aspx
The first time I log onto my webservice I want to use FormsAuthentication e.g.
myService.ClientCredentials.UserName.UserName = "name";
myService.ClientCredentials.UserName.Password = "password";
but once a user has logged onto my web app I dont want to have to know about his password so I would like to be able to connect to the webservice as this user without knowing his password. Is this possible?
I would save the password on whatever front end is accessing the web service and then pass it behind the scenes whenever the user called the web service.
So essentially, design your web service take a password always, but have the front end cache the password so once the user enters the password, the front end doesn't ask again.
Be forewarned, there may be a security concern with keeping the password cached, as I believe that would be part of the session. I'm not familiar with how .net handles this, but you may want to look into hashing.
You should be able to do this, but there are several issues to consider. Forms-based Authentication (FBA) normally uses a cookie to track authentication.
Security - Configure the web application
and web service to use the same FBA database.
Domain - As long as the web service
is on the same domain as the web
application, the web service can use
the same authentication cookie. If the
client has cookies disabled, then this
may not work.
Cookie expiration - You need to configure
the duration of the authentication to an
acceptable time limit (30 minutes, 1 hour,
1 day, or more) in the web.config file. This
will allow the user to access the web service
within a proper time frame after he or she
has logged in.
you can enable sessions in your webservice. There is a simple token that you add in at the begining of the service declaration.
<WebMethod(True)> Method Name