Authentication (Re: Feature polls...)
Philip Mark Donaghy
philip.donaghy at GMAIL.COM
Thu Jan 19 17:49:24 EST 2006
On 1/19/06, Sean Gillies <sgillies at frii.com> wrote:
> Instead of building authentication (and realms) into MapServer, why
> don't we instead work to open MapServer up to Tomcat (or .NET,
> whatever floats your boat), and take advantage of the authentication
> frameworks that already exist? We can keep bolting ever more, and
> redundant, code onto MapServer, but I think it makes more sense to
> make MapServer work better within already existing frameworks.
>
> Sean
Authorization is the process of permitting access to specific content
based on the user who has been authenticated. MapScript is a super way
to do custom stuff with MapServer and it is ideal for integrating with
Tomcat or another "framework". The question that is more important is
what type of "specific content" needs authorization. Are there real
use cases for hiding a layer from certain users. I think so, yet
Tomcat couldn't help me do that. It's true that you could write one
map file for one type of user and another map file for another type
and a web server could redirect them accordingly. I think this needs
more thought and some good use cases.
Another way to do authorization is directly with the data. Some
databases allow you to view only data that fits a specific
characteristic. This is also defined by the users role. Of course the
connection has to be opened by the user who has requested the
information. All these are complex ways of setting up distributed data
systems. Sometimes it is easier to implement authorization in the
software.
>
> On Jan 19, 2006, at 2:30 PM, Philip Mark Donaghy wrote:
>
> > Oops, I sent this only to Steve the first time.
> >
> > Yes, I am interested in putting this in writing. I'll help any way
> > I can.
> >
> > I can say now that I would like to have one or more REALM definition
> > in the map file.
> >
> > A realm processor would have an isUserInRole function. Realms types
> > could be ldap, database, or file. Different realm processors would be
> > invoked according to the realm TYPE.
> >
> > MapServer users could configure any layer with one or more ROLES.
> >
> > There is the notion of the Principal. That is the current user making
> > the request. Getting the principal from the request will be possible
> > using Basic authentication since the username and password is sent
> > with every request following authentication. In the Tomcat/AppServer
> > world this can be done otherways, one of which is by using a session
> > to store the user credentials. But correct me if I am wrong MapServer
> > does not maintain a session accross requests.
> >
> > I can't really think of anyway to do this without using https or
> > sessions. Any ideas?
> >
> > On 1/19/06, Steve Lime <steve.lime at dnr.state.mn.us> wrote:
> >> We'll hold you to Monday- only 4 days left. ;-)
> >>
> >> Are you or someone else willing to do a bit of research on the
> >> subject an=
> > d possibly author an RFC?
> >>
> >> Steve
> >>
> >>>>> Philip Mark Donaghy <philip.donaghy at GMAIL.COM> 01/17/06 6:55 PM
> >>>>> >>>
> >> This is a very interesting topic. I have some experience working with
> >> application servers and web application frameworks at Apache
> >> Jakarta(yes this is java but the theory is the same for any
> >> language).
> >> Application servers define realms that are configured and made
> >> available to the applications running in it. The realm is an
> >> abstraction of the user, group, and role authentication mechanism
> >> backed by any number of storage mechanisms (db, ldap, xml file). The
> >> realm must define at least one critical function, isUserInRole(user,
> >> roles). Applications are then configured to accept or deny resources
> >> based on the current users roles.
> >>
> >> What is important here is the authorization mechanism is simply
> >> delegated to a third party tool. MapServer needs the ability to
> >> configure different kinds of realms and apply authorization model to
> >> any type of layer or feature. MapServer users can then configure
> >> roles
> >> for layers or features(or rules applied to attributes of features).
> >>
> >> So all this has to be used in conjunction with authentication so that
> >> map server knows who is the current user making the request.
> >>
> >> I'll have this done by monday :)
> >>
> >> On 1/16/06, Mark MacLennan <maclenna at visi.com> wrote:
> >>> At 10:39 PM 1/15/2006 -0500, Kralidis,Tom [Burlington] wrote:
> >>>> Has anyone checked out DACS (http://dacs.sourceforge.net/)?
> >>>> They have=
> > a
> >>> C/C++ toolkit/API in which one can build modules to stuff like do
> >>> per l=
> > ayer
> >>> authorization, etc.
> >>>> I've seen this successfully integrated with CubeWerx WMS/WFS.
> >>>> Would b=
> > e
> >>> neat to see as a pluggable Apache module for use w/ MapServer.
> >>>
> >>> Very interesting! I had not come across DACS and it is exactly the
> >>> functionality I had in mind :-)
> >>>
> >>> A related project I was aware of, although I am not sure how it
> >>> might a=
> > pply
> >>> to MapServer per se, is GeoXACML (http://www.geoxacml.org/). A
> >>> demonstr=
> > aton
> >>> has been implemented for a OGC Web Map Service. An OGC discussion
> >>> paper=
> > for
> >>> GeoXACML also exists
> >>> (https://portal.opengeospatial.org/files/index.php?
> >>> artifact_id=3D10471)
> >>> related to the topic of authorization for digital rights
> >>> management in =
> > the
> >>> geospatial domain.
> >>>
> >>> thanks!
> >>> Mark
> >>>
> >>
> >>
> >> --
> >> Philip Donaghy
> >> donaghy.blogspot.com del.icio.us/donaghy/philip
> >> Skype: philipmarkdonaghy
> >> Office: +33 5 56 60 88 02
> >> Mobile: +33 6 20 83 22 62
> >>
> >>
> >
> >
> > --
> > Philip Donaghy
> > donaghy.blogspot.com del.icio.us/donaghy/philip
> > Skype: philipmarkdonaghy
> > Office: +33 5 56 60 88 02
> > Mobile: +33 6 20 83 22 62
>
> ---
> Sean Gillies
> sgillies at frii dot com
> http://zcologia.com/news
>
>
>
>
--
Philip Donaghy
donaghy.blogspot.com del.icio.us/donaghy/philip
Skype: philipmarkdonaghy
Office: +33 5 56 60 88 02
Mobile: +33 6 20 83 22 62
More information about the mapserver-dev
mailing list