Authentication (Re: Feature polls...)

[Jos é Luis Campanello]

I see your points and i agree. I must appologize for the fact that i used the OS example, it was handy and (too) simple.

I was really thinking about integration with other systems (corporate and/or legacy). In these situations, security will most likely be provided in a way dependent on the system and some of the information to display will be very dependent on who is looking at it, and (possibly) change very often.

Think of a cable operator technician accesing the system to find out the customer complains of the day or some live or semi-live monitoring tool (like a sensor network).

In some of these situations, it may not be possible (or reasonable) to have an RDBMS to query. It may even be necesary to use a web service (or something more "obscure").

It is true that in some (perhaps most) of these situations security will be solved by the supporting system. Yet, this requires that (somehow generated) security tokens be received-by and passed-thru mapserver to be used when needed (independent of the security framework being used, whether it is standard or not).

In some of these scenarios, performance may be a secondary issue when compared to security.

                jluis

----- Mensaje original -----
From: Attila Csipa <plists at PROMETHEUS.ORG.YU>
Date: Viernes, Enero 20, 2006 12:46 pm
Subject: Re: [UMN_MAPSERVER-DEV] Authentication (Re: Feature polls...)

> ... oops, clicked on send by mistake.
> 
> On Friday 20 January 2006 16:04, José Luis Campanello wrote:
> > As an example, i was thinking of a (single) layer that contains 
> some public
> > and some private information. I really see no simple method to 
> implement> that kind of access control using an external security 
> tool. While it is
> 
> It should make no difference HOW an authuser(credentials) function 
> is 
> performed. Of course some methods have limitations but then again, 
> you should 
> take this into account when designing the system and not forcing a 
> technically unfeasible security policy. In this spirit it would be 
> suboptimal 
> to set a combined security layer - it means you would be doing 
> access 
> checking in the most computation-expensive level, the features. Of 
> course you 
> could always put in a hook into mapserver for feature level 
> authentication, 
> but it would most likely mean a huge performance hit, especially 
> if that 
> overhead cannot be offloaded to a RDBMS, which is more often the 
> case than it 
> is not (shapefile data, for example). 
> 
> Another point of consideration that is perhaps not that apparent - 
> it's not 
> the same to think about security realms that have data assigned to 
> them, as 
> opposed to data sets that have security realms assigned to them. 
> Generally I 
> think in mapserver applications data sets change qualitatively far 
> less often 
> than security realms - this means you should build your security 
> around your 
> data, and not the other way around.
> 
> > I think that security should be built into the product in a way that
> > ensures the same set of functionality in every platform (keep in 
> mind that
> > even user ids vary in size and type from OS to OS).
> 
> I strongly disagree. With this approach you get the smallest 
> compatible subset 
> of possible functionality, while you actually want the largest 
> possible 
> subset for the given platform. Imagine MapServer is ported to, 
> say, 
> Windows95. With a compatible subset, it would mean that Mapserver 
> should not 
> have any user-authentication, since Win95 makes no (practical) 
> difference 
> among its users.
>