Hi,
I have a VB.Net Windows form based user authentication system. The form authenticates the user info against a server through Remoting that is hosted by IIS. The authentication process runs well all the time. Once the authentication is done, I set up my customized identity and principal and set the principal to the current thread on the server before returning the call back to the client.
The thing that suprises me is that, when my client gets back to the server the next time (client gets back through a remoting reference to the same server object that did the authentication), the security principal of the current thread on the server has changed! It went back to Windows principal again, instead of my own principal I just set.
What is going on here I am new to the .Net role-based security in generial and the identiy/principal in perticular. Does this problem has anything to do with the fact that the remoting server is hosted by IIS Can someone tell me what I am doing wrong and how to correct this
Thanks a million!
Role based security: IIS based remoting server doesn't hold my principal
Yoramkr
MrZap
Thanks Lucian for the link. It is a very helpfull artical!
As I am working through my options at hand, I am still a little un-sure about what is the right way for me. Besides my ignorance of .Net role-based security, I think the architecture of our application, which in my eyes is a little different than most of the .Net apps, must also contribute to the confusion. So please allow me to reiterate my problem and how I understand the options I have.
1. My application:
I have a .Net Windows form application that connects to a .Net server application via Remoting. The Remoting server is hosted by IIS. The part of the app I am working on now is user authentication/authorization. My goal is to use .Net role-based suecurity.
2. My issue:
After the user authentication is done, I want to establish a costum pricipal and assign it to the current user's session ON THE SERVER. In other words, I want the server to REMEMBER the user's authentication/authorization status accross multiple requests. In order to acheave this what I had tried was that I create the costum principal and attache it to Thread.CurrentPrincipal. Of course that didn't work because of the reason I just got to understand after reading the article and other documents. Now it seems that what I should do is to assign the principal to HttpContext.User, instead of the thread. But that doesn't seem to solve my problem either because, like I said, my app is a windows form app, not an ASP.Net one. I don't have any ASP pages. According to the doc, HttpContext.User only holds the principal for the current request. For any following requests, it is the responsibility of the ASP pages to maintain the principal state in cookie through users' browsers.
In my case, however, I don't have an ASP.Net app. The only reason that the IIS gets involved is for hosting the Remoting server. So I am not sure how this HttpContext.User is going to help me here.
One other small detail: It seems all the docs suggest that I should assign the principal to "HttpContext.User". But when I try HttpContext.User = oMyPrincipal in my code, the compiler doesn't allow me to do that because the User property is static (shared, in VB). How should I try this
3. Options:
One option that I can see now is that I can let my client carry an identity object on every requests it makes to the server. The server then checks the permission based on the user identity whenever needed (that means making more trips to the database). Another option would be to let the client carry the entire principal object arround.
Either way, it will mean that I have to give up on trying to have the server to remember the principal through the user's session. That's simplly won't work, in our app, and, as I understand it.
If anyone see that I am completly mis-understand the concepts, or missing terribly on something, please let me know!
Thanks in advance!
Feng
Dan L