 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
.NET Forum / .NET Framework / Security / November 2007Send custom IPrincipal object from client to WCF service - Possibl
We are trying to do something that doesnt appear to be possible. Simply this: We create a IPrincipal object on the client based on a custom class that holds info we need for auditing (ip, workstation_name, etc) What we want to do is somehow pass this IPrincipal object to WCF when we access it. This is necessary so we can get the auditing info, etc... Why is it that it only appears you can create the Principal object at the server based on a Windows Account or ClientCredeintials -- neither of which will work for us because even if we persisted the IPrincipal object in a db, we couldnt be sure of reconstructing the same object at the server - that is if the same user account was logged into 2 different machines. Any help would be extremely appreciated. > We are trying to do something that doesnt appear to be possible. > [quoted text clipped - 8 lines] > Why is it that it only appears you can create the Principal object at the > server based on a Windows Account or ClientCredeintials -- Because you're using Windows Authentication. > neither of which > will work for us because even if we persisted the IPrincipal object in a db, > we couldnt be sure of reconstructing the same object at the server - that is > if the same user account was logged into 2 different machines. Forgive me if I'm vague on the details - I've never done this but I remember reading about it. When you send a message it gets wrapped in various layers of gue depending on the endpoint that you have configured and I think there's a way to create your own custom layers that the message gets wrapped in when sending/receiving it to/from the client/server. You might then be able to extract this information in a custom IAuthorizationPolicy and store it in the SecurityContext. As I say, I'm pretty vague on the details but that might give you enough to track down a comprehensive article on this on google or whatever. Best Regards, James Crosswell Microforge.net LLC http://www.microforge.net Hello James, Thanks for your response. What we ended up doing is kinda like that. We custom serialize our IPrincipal object, stuff it in the message header, then extract and recreate our object at the server within the Evaulate method. We found now way to directly send a custom IPrincipal object created at the client, directly thru the server. Every sample we saw built the object at the server with only say a 'windows' account or user/pass pair passed in. Doing it the way we did, we were able to keep all of the information we had stuffed in the custom object when we created it on the client end. Thanks again. > We are trying to do something that doesnt appear to be possible. > [quoted text clipped - 13 lines] > > Any help would be extremely appreciated. Keep in mind that you shouldn't base any security decisions on information originating from the client - the client is basically untrusted. Can't you re-create the information you need based on the authenticated principal? ----- Dominick Baier (http://www.leastprivilege.com) Developing More Secure Microsoft ASP.NET 2.0 Applications (http://www.microsoft.com/mspress/books/9989.asp) > Hello James, > [quoted text clipped - 34 lines] >> >> Any help would be extremely appreciated. > Keep in mind that you shouldn't base any security decisions on > information originating from the client - the client is basically > untrusted. That's precisely the purpose of authentication though - to verify the client is who it says it is. Regardless of the strength of weakness of the authentication mechanism you're using, you HAVE to make access control decisions based on whoever you determine the client to be during the authentication process. Best Regards, James Crosswell Microforge.net LLC http://www.microforge.net Thanks guys for your response. Yes, you cannot trust the client, however to recreate them on the server side is the same security risk - you are getting a user/pass from the client... > > Keep in mind that you shouldn't base any security decisions on > > information originating from the client - the client is basically [quoted text clipped - 11 lines] > Microforge.net LLC > http://www.microforge.net not quite - because you do authentication first. There could be a properly authenticated user A - which sends IPrincipal data for User B. You see the issue? ----- Dominick Baier (http://www.leastprivilege.com) Developing More Secure Microsoft ASP.NET 2.0 Applications (http://www.microsoft.com/mspress/books/9989.asp) > Thanks guys for your response. > [quoted text clipped - 17 lines] >> Microforge.net LLC >> http://www.microforge.ne Free MagazinesGet these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...
|
Reply to this Message
|
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.