I agree with Andrea that i would be weary of complexity here, even if we do
try to hide it from users. We took this approach with the authentication
changes and imo it is not all that user friendly compared to other systems
that offer similar authentication options.
Unless you spend a lot of time designing the user interface up
front undoubtedly development complexity will creep through. Case in point:
currently the user needs to know what user group and role services are. For
power users this may not be an issue, they probably like the flexibility,
but for the average user it's confusing.
On Wed, Jun 12, 2013 at 3:20 AM, Christian Mueller <
[email protected]> wrote:
> The idea is to have an XACML engine for the developers, not for the users.
> The user never should configure XACML directly (I am not an enemy of my
> own).
>
> Christian
>
>
> 2013/6/12 Andrea Aime <[email protected]>
>
>> On Wed, Jun 12, 2013 at 10:21 AM, Christian Mueller <
>> [email protected]> wrote:
>>
>>> Hi Niels
>>>
>>> Beyond combining layer and services there are additional wishes &
>>> requirements. A customer of me wants to restrict access to formats, e. g.
>>> prohibit getMap requests using SVG.
>>>
>>> I would vote for a powerful access control engine like (GEO) XACML. Some
>>> years ago I did a summer of code project mentored by Andrea concerning
>>> GEOXACML integration but due to lack of time, we did not finish. (The code
>>> is still a community module).
>>>
>>> XACML is quite powerful and it is a standard. As a first step, I would
>>> prefer to switch from our property files to one XACML file without changing
>>> the current functionality. After this, we could enhance access control.
>>>
>>
>> While I'm not opposed to XACML per se, I'm rather worried about it's
>> complexity, a 3 lines property file equates to 100-200 loc of XACML, so any
>> movement in that direction should be followed by a proper GUI development
>> hiding the XACML complexity to the user, otherwise we'll end up with a
>> situation similar to app-schema, powerful but people often just end up
>> pulling hairs and looking for alternatives because they cannot get its
>> configuration right.
>>
>> Cheers
>> Andrea
>>
>> --
>> ==
>> Our support, Your Success! Visit http://opensdi.geo-solutions.it for
>> more information.
>> ==
>>
>> Ing. Andrea Aime
>> @geowolf
>> Technical Lead
>>
>> GeoSolutions S.A.S.
>> Via Poggio alle Viti 1187
>> 55054 Massarosa (LU)
>> Italy
>> phone: +39 0584 962313
>> fax: +39 0584 1660272
>> mob: +39 339 8844549
>>
>> http://www.geo-solutions.it
>> http://twitter.com/geosolutions_it
>>
>> -------------------------------------------------------
>>
>
>
>
> --
> DI Christian Mueller MSc (GIS), MSc (IT-Security)
> OSS Open Source Solutions GmbH
>
>
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by Windows:
>
> Build for Windows Store.
>
> http://p.sf.net/sfu/windows-dev2dev
> _______________________________________________
> Geoserver-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/geoserver-devel
>
>
--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.
------------------------------------------------------------------------------
This SF.net email is sponsored by Windows:
Build for Windows Store.
http://p.sf.net/sfu/windows-dev2dev
_______________________________________________
Geoserver-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
