>> This "connection" will be mediated by the local DL, right? So a remote >> DL will never directly communicate with a local BL. The local DL will >> accept some XML to be processed from the remote DL, and then submit >> this to the local BL under its own dlId and uri instanceID. So this >> DL authentication (to gain access to nodes) will need to mediated >> through a dl->dl connection that I'll need to do. > > No, I'm saying the BL wont notice the differance between a local or a remote > DL. > > The only problem with remote DL's is that the (local) root DL must know about > that remote one in order to authoritized it. Okay, I think we are saying the same thing--that a local dl has to accept a connection from a remote dl and get it authorized to use the local bl. This will be occuring in a (not yet defined) dl->dl corba connection. > (note: the transported data will be encrypted with the DL password as key.) Man, Jarl, you are awesome! This just helped me figure out a problem I was having with secure password storage in the dl. Thanks! > OK, so this means will will have a system that is like the unix user\group > system, > only groups have passwords too in VSH! This sounds like a good plan to me. Jeff, does this jive with your security ideas? >> How will the permissions for node access by assigned? All >> authorized DLs (by tha authorize function) have access to the same >> nodes as their parent (the DL that created them)? > > No, they have access to the nodes created with THEIR DLid. > And yes, this makes it possible to have multiple logins on the same DLid. > To get access to another DL's nodes, use login 'level' (?) Okay, I think I understand your point, although I'm not sure what you mean by login level... > We should therefor deside if it can be possible for a DL to login to another > DL and to a BL at the same time. I didn't though about the consequences yet.. This makes my head hurt :-) I think we should keep it simple for the time being. I think the only idea about of one dl being able to log into another was so one dl could control the other (ie. you could control the gnome gui display using the (not yet developed) speech recognition user interface. Am I right on this Jeff, or did you have bigger ideas of two dls connecting? > Maybe this new field of the uriS will make this possible? > so it will be like this (simplyfied): > struct uriS { > long instaceID; > long groupID; //aint the same as the unix 'group' !! > long subnetID; > long nodeID; > }; > > Giving any lead? Okay, so a group is "smaller" than a instanceID, and groups subnets and nodes and not users. Am I following you correctly? Brad