|
security
newsgroups
|
|||||||||||||||||||||||
|
|||||||||||||||||||||||
Send custom IPrincipal object from client to WCF service - PossiblWe 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. aiKeith wrote:
> We are trying to do something that doesnt appear to be possible. Because you're using Windows Authentication.> > 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 Forgive me if I'm vague on the details - I've never done this but I > 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. 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. Show quote "aiKeith" wrote: > 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. > 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) Show quote > 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. > > "aiKeith" wrote: > >> 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. >> Dominick Baier wrote:
> Keep in mind that you shouldn't base any security decisions on That's precisely the purpose of authentication though - to verify the > information originating from the client - the client is basically > untrusted. 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... Show quote "James Crosswell" wrote: > Dominick Baier wrote: > > 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 > 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) Show quote > 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... > > "James Crosswell" wrote: > >> Dominick Baier wrote: >> >>> 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  |
|||||||||||||||||||||||
Other interesting topics