locked
ServiceForwarder with dynamic Authentication RRS feed

  • Question

  •  

    HI there

     

    consider following szenario:

     

    a node runs an application that consists of several services, maybe a simulation, on one michine

    another node runs on another machine, connected to the network..both machines are fully equepped and configured windows xp and have their seperate user definitions. the second node btw. runs simply a dashboard that trys to connect to the first node and its services, to control the entitys... now the users on both machines dont match, logically,

     

    i'd like to have my dashboard modified in a way that it can acces a remote dssnode by letting him specify

    a username and a password in textfields to use on the remote node (which grants access to that user according to its userlist).

    as far as i know the node uses NTLM to singlesign on..

     

    Defining an ServiceForward(Uri...)) I cant specify the credentials to use for authentication. well, to addmitt, for sure i dont fully understand NTLM and the sign in process. thus the question:

     

    Is there simple way to let the remote node know which user is trying to get a connection to it..

     

    id really love to simplify the connect proccess on that in my dashboard. i think this is a general issue connected to distributed nodes..how can services get in contact if thei are on different nodes? i have been trying to understand the UserGuide Section, but it does not provide enough examples..

     

    thank you guys

    Thursday, March 6, 2008 3:46 PM

Answers

  • thank you for the suggestion, as you will see in the upcoming 2.0 CTP1 release we have avery neat security model, building on the 1.5 model, that take sinto a account a variety of subjects (in the security sense) to determine permissions. We are basically going towards role based authentication, using the DSSP verbs, service uris, contracts, users as subjects.

     

    However we will still have a simpler model in terms of th enode still being the boundary for these decisions. Already we allow you to get the user id for inbound requests (both DSSP and HTTP). But we dont allow you to impersonate when you create a forwarder, since there is always a single principal that started the node

     

     

    Thursday, March 13, 2008 7:44 PM