If you look at the grid as active directory and simulators and web servers then the simulators will get the request to access a resource and need to have the user authenticated and authorized and as such I would support your model. But I would suggest that most people would probably implement some kind of active directory so that they can centrally manage users and roles.
I believe OpenSim is close to this model with simulators when they log into the grid. It should be possible to force a simulator off the grid from a central point by failing its token which I don't think exist right now. To me the UGAIM is the services of the grid and even though the grid server doesn't do much the grid as a whole provides services of which one is authentication. What I seem is the more interesting challenge is how the authentication interfaces are designed so that when a request comes into a simulator it can choose to allow anonymous access to some things and require authentication for some other things. Also how the interfaces can be designed to have a default authentication model but then support hooks to use other forms of authentication. Also I see it should work in a chain so that trust can be deferred; for instance the simulator may defer authentication to a grid and then that grid may defer it to another grid or to LiveID or something like that. There other part I think can make this complicated is how the layers are defined. Using the OSI model there are many layers where authorization can be implemented, like in the TCP/IP socket itself can control access to the computer like how NT will not let you have access to a resource on the box, but if it lets you have access it creates a principle and identity object that layers above it can use. In the case of a web site that may be an anonymous users so it will them force an authentication by requesting a forms authentication which will then change the principle object and identity to give it additional authorization. What I don't see 100% clearly is how when a request goes into a region and then that region request to do changes against my inventory that we can make sure that region really has authority to do that and limit either accidental or intentional changes in the UGAIM that a region does not have authority to do. I think it needs to work something like how integrated security works in that my tokens are pass a long with the request to the UGAIM servers. Not sure how to prevent a simulator from abusing that it has my tokens and do thing I didn't request to do other than making the tokens expire or only allow one time use. The main thing I see architecturally is that there needs to be kind of a grid layer that the simulator sits on that does certain services like how an application sit on the operating system and as such the authentication stuff should be pulled out into a layer that is performed before anything else happens in a process. I think Microsoft's Membership API is a good model to look at if you haven't. It supports a default authentication or you can override it with your own custom authentication. There are probably others. Kevin Tweedy IRC: Mystical -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Diva Canto Sent: Thursday, April 16, 2009 11:45 AM To: [email protected] Subject: Re: [Opensim-dev] The essence of "grid" Right. This whole issue can be formulated in one very simple question: If the client is to delegate authority to the server-side, should it do it to the specific simulator or to this other server that speaks for a collection of simulators, aka "grid"? Under the Apache model, the answer is "to the specific simulator" which then can get its response from some other server, if it wishes to do so. But in a lot of discussions related to webs of VWs, there is an implicit assumption that there needs to be this other controller with which the clients have to interact. As I said, this is not philosophy. As I'm doing Grider, I need to decide with which server it interacts for purposes of authority delegation. I think it should interact with specific simulators. But I just wanted to shake things a bit and see what's out there in people's minds, specifically for this concept of what a "grid" is. Michael Cortez wrote: > Michael Cortez wrote: >> My thoughts: >> >> To me, a Grid is a virtual space that can be of any given size, and to >> date, currently consists of one or more discrete Regions that are laid >> out in a two dimensional grid pattern. A Grid allows for these >> discrete individual spaces to be joined together to provide a seamless >> virtual space that viewers can traverse as if they were a single large >> simulation. >> >> A Grid can consist of just a single Region, or many Regions. >> >> Within a Grid, it may be desirable to assign ownership of virtual >> space to specific agents for administration. Those agents, through >> their viewers (or other means) should be able to determine who may >> enter their space, what those visitors can do once there, including >> what communications are available and what objects they may simulate. >> Currently we determine areas of administration in 256m^2 regions of >> space, that are then sub-divided by parcels. > Oh, and I forgot to mention, I fully expect to see Grids of Grids -- in > fact, OSGrid could be seen as a grid of grids. It consists of many > individual Regions of space, that can on their own be considered a grid. > > I'll state it again here, for those that don't care to read my other > longer rambling message -- each instance of OpenSim is to a certain > extent a self contained grid. In standalone mode it has nearly all the > same services as what is currently called a "Grid" -- and those services > that are missing could be added. In fact, "Grid Mode" is simply the > delegation of specific subsets of responsibility to another entity. > > -- > Michael Cortez > _______________________________________________ > Opensim-dev mailing list > [email protected] > https://lists.berlios.de/mailman/listinfo/opensim-dev > _______________________________________________ Opensim-dev mailing list [email protected] https://lists.berlios.de/mailman/listinfo/opensim-dev _______________________________________________ Opensim-dev mailing list [email protected] https://lists.berlios.de/mailman/listinfo/opensim-dev
