[Pipet Devel] Re: Security model

jarl van katwijk jarl at casema.net
Thu Apr 6 16:15:40 EDT 2000

> > 1c- Other DL's (local and remote) can connect via
> > CORBA after
> >        the root DL has granted them access.
> 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.
But these are only techinical implementation problems, they hardly count
compared to this security model :-)

> > 1e- BL nodes (or: VSH subnets) can communicate
> > with other BL nodes
> >        only if both nodes have the same parent
> > DL.
> Makes sense for bl security. This will be something that'll need to go
> into the bl code.

They do. But the point is that the brokering layer will get inter local
transport system: local subnet-> remote subnet. It's no big deal,
but everybody should know that this going on.
(note: the transported data will be encrypted with the DL password as key.)

> > 2a- a DL authenticates other DL's for access to
> > its nodes\subnets.
> Right, this is what I mentioned in 1c, and is something I'll have to
> do.

OK, so this means will will have a system that is like the unix user\group
only groups have passwords too in VSH!

group    ~~ BL level (DL id  & DL password give access to whole set of subnets
and nodes that are childs of that DL)
user       ~~ DL level (??? id & ??? password give access to subset of the
subnets and nodes that are childs of that DL)

This is just to illustrate the system, dont take it too strict.

> > 2c- No DL can connect to the root DL, so no
> > non-root DL has ability 2a.
> This makes a lot of sense for security reasons. This way, no one can
> remotely get access to a root DL. So before the local DL starts
> allowing  remote DLs access, the local root DL will have to create a
> new DL to allow this access. Am I reading you right on this one?

The root DL will only be there to grant others access and do some very-very-very
basic subnet processing.
The most work will spawn out of other DL's.

>     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' (?)  2.
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..

>     If we want to restrict access to only certain nodes for local DLs,
> then we will need a more complicated authorization scheme. I'm not
> sure if we really need this kind of fine scale authorization, and
> would rather leave it out, but it is up to you :-)

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?

More information about the Pipet-Devel mailing list