[Geoserver-devel] Needs some tips/hints (on the correct mailing list this time)

Hi all, during the GSOC 2011 I am working on this issue..
http://jira.codehaus.org/browse/GEOS-4554

I plan to split the architecture into two components, a user/group
management and a role authority. As an example, it should be possible
to get user/group info form the OS or a Database and storing roles in
property files. Many combinations are possible.

At the moment, we have a file
GEOSERVER_DATA_DIR/security/users.properties
with the following syntax

user=password,role1,....rolen,[enabled | disabled ]

This gives me headaches because password and enabled status belong to
user/group management while the roles belong to the role authority.

For a clean architecture I need 6 files
users.properties // user attributes without roles
groups.properties // group attributes without roles
roles.properties // roles
user_group.properties // "belongs to" relationship
user_roles.properties // "user has roles" relationship
group_roles.properties // "group has roles" relationship

An idea is to put these file in its own subdir
GEOSERVER_DATA_DIR/security/propertybased/*

The migration would be the following:
On first start, read the file
GEOSERVER_DATA_DIR/security/users.properties , create the directoy
hierarchy and new files, migrate, write a migration message in the log
and inform the admin that he can remove the old user.properties.

On the following starts, if
GEOSERVER_DATA_DIR/security/users.properties exists, I will write a
warning in the log to remove that file, since it is no longer used,
but contains passwords.

Opinions ?

----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.

Hi Christian,

Any reason why a specific subdir is needed? Is it planned that other different security configurations would store files under the “security” base directory? If so maybe a name like “basic” or “default” might be a little better than “propertybased”.

An alternative would be to continue to use that directory but instead look for the existence of one of the new files… like groups.properties and if it does’t exist then do the upgrade of the config file. This is what we do when we update the data directory.

2c.

-Justin

On Wed, May 25, 2011 at 2:52 AM, <christian.mueller@anonymised.com> wrote:

Hi all, during the GSOC 2011 I am working on this issue…
http://jira.codehaus.org/browse/GEOS-4554

I plan to split the architecture into two components, a user/group
management and a role authority. As an example, it should be possible
to get user/group info form the OS or a Database and storing roles in
property files. Many combinations are possible.

At the moment, we have a file
GEOSERVER_DATA_DIR/security/users.properties
with the following syntax

user=password,role1,…rolen,[enabled | disabled ]

This gives me headaches because password and enabled status belong to
user/group management while the roles belong to the role authority.

For a clean architecture I need 6 files
users.properties // user attributes without roles
groups.properties // group attributes without roles
roles.properties // roles
user_group.properties // “belongs to” relationship
user_roles.properties // “user has roles” relationship
group_roles.properties // “group has roles” relationship

An idea is to put these file in its own subdir
GEOSERVER_DATA_DIR/security/propertybased/*

The migration would be the following:
On first start, read the file
GEOSERVER_DATA_DIR/security/users.properties , create the directoy
hierarchy and new files, migrate, write a migration message in the log
and inform the admin that he can remove the old user.properties.

On the following starts, if
GEOSERVER_DATA_DIR/security/users.properties exists, I will write a
warning in the log to remove that file, since it is no longer used,
but contains passwords.

Opinions ?


This message was sent using IMP, the Internet Messaging Program.


vRanger cuts backup time in half-while increasing security.
With the market-leading solution for virtual backup and recovery,
you get blazing-fast, flexible, and affordable data protection.
Download your free trial now.
http://p.sf.net/sfu/quest-d2dcopy1


Geoserver-devel mailing list
Geoserver-devel@anonymised.comsts.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel


Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.

Quoting Justin Deoliveira <jdeolive@anonymised.com>:

Hi Christian,

Any reason why a specific subdir is needed? Is it planned that
other different security configurations would store files under the
"security" base directory?

Yep, configuration files for connecting to other background stores like ldap, jdbc,.....

If so maybe a name like "basic" or "default"

might be a little better than "propertybased".

"default" is nice, this is the out of the box solution.

An alternative would be to continue to use that directory but instead look
for the existence of one of the new files... like groups.properties and if
it does't exist then do the upgrade of the config file. This is what we do
when we update the data directory.

Looking for the existence of new files is what I want to do. I am unsure if I
should migrate users.properties directly or make a backup for the admin for later manual removal.

Christian

2c.

-Justin

On Wed, May 25, 2011 at 2:52 AM, <christian.mueller@anonymised.com> wrote:

Hi all, during the GSOC 2011 I am working on this issue..
http://jira.codehaus.org/browse/GEOS-4554

I plan to split the architecture into two components, a user/group
management and a role authority. As an example, it should be possible
to get user/group info form the OS or a Database and storing roles in
property files. Many combinations are possible.

At the moment, we have a file
GEOSERVER_DATA_DIR/security/users.properties
with the following syntax

user=password,role1,....rolen,[enabled | disabled ]

This gives me headaches because password and enabled status belong to
user/group management while the roles belong to the role authority.

For a clean architecture I need 6 files
users.properties // user attributes without roles
groups.properties // group attributes without roles
roles.properties // roles
user_group.properties // "belongs to" relationship
user_roles.properties // "user has roles" relationship
group_roles.properties // "group has roles" relationship

An idea is to put these file in its own subdir
GEOSERVER_DATA_DIR/security/propertybased/*

The migration would be the following:
On first start, read the file
GEOSERVER_DATA_DIR/security/users.properties , create the directoy
hierarchy and new files, migrate, write a migration message in the log
and inform the admin that he can remove the old user.properties.

On the following starts, if
GEOSERVER_DATA_DIR/security/users.properties exists, I will write a
warning in the log to remove that file, since it is no longer used,
but contains passwords.

Opinions ?

----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.

------------------------------------------------------------------------------
vRanger cuts backup time in half-while increasing security.
With the market-leading solution for virtual backup and recovery,
you get blazing-fast, flexible, and affordable data protection.
Download your free trial now.
http://p.sf.net/sfu/quest-d2dcopy1
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.

----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.

On Wed, May 25, 2011 at 9:11 AM, <christian.mueller@anonymised.com> wrote:

Quoting Justin Deoliveira <jdeolive@anonymised.com>:

Hi Christian,

Any reason why a specific subdir is needed? Is it planned that
other different security configurations would store files under the
“security” base directory?

Yep, configuration files for connecting to other background stores like ldap, jdbc,…

If so maybe a name like “basic” or “default”

might be a little better than “propertybased”.

“default” is nice, this is the out of the box solution.

An alternative would be to continue to use that directory but instead look
for the existence of one of the new files… like groups.properties and if
it does’t exist then do the upgrade of the config file. This is what we do
when we update the data directory.

Looking for the existence of new files is what I want to do. I am unsure if I
should migrate users.properties directly or make a backup for the admin for later manual removal.

Not sure what makes more sense… but again in the data dir upgrade case we take the old catalog.xml and services.xml and move them to catalog.xml.old, etc… so that to leave them in place in case the admin wants to revert… but put the new ones in place as per the upgrade.

Christian

2c.

-Justin

On Wed, May 25, 2011 at 2:52 AM, <christian.mueller@anonymised.com> wrote:

Hi all, during the GSOC 2011 I am working on this issue…
http://jira.codehaus.org/browse/GEOS-4554

I plan to split the architecture into two components, a user/group
management and a role authority. As an example, it should be possible
to get user/group info form the OS or a Database and storing roles in
property files. Many combinations are possible.

At the moment, we have a file
GEOSERVER_DATA_DIR/security/users.properties
with the following syntax

user=password,role1,…rolen,[enabled | disabled ]

This gives me headaches because password and enabled status belong to
user/group management while the roles belong to the role authority.

For a clean architecture I need 6 files
users.properties // user attributes without roles
groups.properties // group attributes without roles
roles.properties // roles
user_group.properties // “belongs to” relationship
user_roles.properties // “user has roles” relationship
group_roles.properties // “group has roles” relationship

An idea is to put these file in its own subdir
GEOSERVER_DATA_DIR/security/propertybased/*

The migration would be the following:
On first start, read the file
GEOSERVER_DATA_DIR/security/users.properties , create the directoy
hierarchy and new files, migrate, write a migration message in the log
and inform the admin that he can remove the old user.properties.

On the following starts, if
GEOSERVER_DATA_DIR/security/users.properties exists, I will write a
warning in the log to remove that file, since it is no longer used,
but contains passwords.

Opinions ?


This message was sent using IMP, the Internet Messaging Program.


vRanger cuts backup time in half-while increasing security.
With the market-leading solution for virtual backup and recovery,
you get blazing-fast, flexible, and affordable data protection.
Download your free trial now.
http://p.sf.net/sfu/quest-d2dcopy1


Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel


Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.


This message was sent using IMP, the Internet Messaging Program.


Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.

On Wed, May 25, 2011 at 10:52 AM, <christian.mueller@anonymised.com> wrote:

Hi all, during the GSOC 2011 I am working on this issue..
http://jira.codehaus.org/browse/GEOS-4554

I plan to split the architecture into two components, a user/group
management and a role authority. As an example, it should be possible
to get user/group info form the OS or a Database and storing roles in
property files. Many combinations are possible.

At the moment, we have a file
GEOSERVER_DATA_DIR/security/users.properties
with the following syntax

user=password,role1,....rolen,[enabled | disabled ]

This gives me headaches because password and enabled status belong to
user/group management while the roles belong to the role authority.

For a clean architecture I need 6 files
users.properties // user attributes without roles
groups.properties // group attributes without roles
roles.properties // roles
user_group.properties // "belongs to" relationship
user_roles.properties // "user has roles" relationship
group_roles.properties // "group has roles" relationship

Hmmm... too much rendundancy, too many files, hard to manage,
easy to screw up.
What about:
- removing the roles files (the list of roles is already in the sum of
users and groups files)
- merge back users and roles in a single file
- merge back group and roles in a single file
This would leaves us with 4 files, which is much closed to what I'd
expect a normal
human being to manage without too many errors.

Alternatively, go for a single xml/yaml file with the simplest
possible structure (reducing
redundancy to the minimum possible)?

As a rule of thumb, I consider anything that could be done with less
moving parts
broken, and the minimal version of it the only acceptable solution.
Kind of mixing togheter Antoine De Saint Exupery view (perfection is reached
not when there is nothing to add, but when there is nothing else to remove)
with good old Djistra common sense (a programmer should always be fully aware
of the strictly limited size of his own skull... and I'd add, the
users skull as well).
Ok, enough philosophy :-p

Cheers
Andrea

--
-------------------------------------------------------
Ing. Andrea Aime
GeoSolutions S.A.S.
Tech lead

Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy

phone: +39 0584 962313
fax: +39 0584 962313

http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.youtube.com/user/GeoSolutionsIT
http://www.linkedin.com/in/andreaaime
http://twitter.com/geowolf

-------------------------------------------------------

XML would be the best. I added some samples to
http://jira.codehaus.org/browse/GEOS-4554
for further discussion.

@Justin, perhaps you should watch this issue.

I would strongly vote for 2 xml files, one for role management and one for
user/group management.

I created 2 xml schemes and 2 demo files and tried to keep it simple.
Using an XML schema has a lot of advantages. The user can edit with a tool and validate, I can use JAXB for serializing/deserializing (if this is ok). Further I can save much code for validation.

I would implement the access logic using XPath. I looked at the possibilities of DB2 and you can store even large xml files, access them via XPath, create indices on nodes and so on. I think this is possible with other products too.

The roles can be hierarchical if something is wondering about the "parent" attribute in roles.xml.

I am further thinking about role attributes, which must be filled at runtime, but for now, I want to delay this.

Thanks for your hints
Christian

Quoting Andrea Aime <andrea.aime@anonymised.com>:

On Wed, May 25, 2011 at 10:52 AM, <christian.mueller@anonymised.com> wrote:

Hi all, during the GSOC 2011 I am working on this issue..
http://jira.codehaus.org/browse/GEOS-4554

I plan to split the architecture into two components, a user/group
management and a role authority. As an example, it should be possible
to get user/group info form the OS or a Database and storing roles in
property files. Many combinations are possible.

At the moment, we have a file
GEOSERVER_DATA_DIR/security/users.properties
with the following syntax

user=password,role1,....rolen,[enabled | disabled ]

This gives me headaches because password and enabled status belong to
user/group management while the roles belong to the role authority.

For a clean architecture I need 6 files
users.properties // user attributes without roles
groups.properties // group attributes without roles
roles.properties // roles
user_group.properties // "belongs to" relationship
user_roles.properties // "user has roles" relationship
group_roles.properties // "group has roles" relationship

Hmmm... too much rendundancy, too many files, hard to manage,
easy to screw up.
What about:
- removing the roles files (the list of roles is already in the sum of
users and groups files)
- merge back users and roles in a single file
- merge back group and roles in a single file
This would leaves us with 4 files, which is much closed to what I'd
expect a normal
human being to manage without too many errors.

Alternatively, go for a single xml/yaml file with the simplest
possible structure (reducing
redundancy to the minimum possible)?

As a rule of thumb, I consider anything that could be done with less
moving parts
broken, and the minimal version of it the only acceptable solution.
Kind of mixing togheter Antoine De Saint Exupery view (perfection is reached
not when there is nothing to add, but when there is nothing else to remove)
with good old Djistra common sense (a programmer should always be fully aware
of the strictly limited size of his own skull... and I'd add, the
users skull as well).
Ok, enough philosophy :-p

Cheers
Andrea

--
-------------------------------------------------------
Ing. Andrea Aime
GeoSolutions S.A.S.
Tech lead

Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy

phone: +39 0584 962313
fax: +39 0584 962313

http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.youtube.com/user/GeoSolutionsIT
http://www.linkedin.com/in/andreaaime
http://twitter.com/geowolf

-------------------------------------------------------

----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.

On Thu, May 26, 2011 at 8:00 AM, <christian.mueller@anonymised.com> wrote:

XML would be the best. I added some samples to
http://jira.codehaus.org/browse/GEOS-4554
for further discussion.

@Justin, perhaps you should watch this issue.

I would strongly vote for 2 xml files, one for role management and one for
user/group management.

I created 2 xml schemes and 2 demo files and tried to keep it simple.
Using an XML schema has a lot of advantages. The user can edit with a tool
and validate, I can use JAXB for serializing/deserializing (if this is ok).

Time ago we noticed that adding jaxb jars in the path would break GML
handling due to some Eclipse XSD incompatibilities (as far as I
remember, Justin,
any help there?).
If you design your in memory classes carefully I believe you can just
use XStream, that is known to work.

I would implement the access logic using XPath. I looked at the
possibilities of DB2 and you can store even large xml files, access them via
XPath, create indices on nodes and so on. I think this is possible with
other products too.

Ok, good for alternative implementations, though we're mainly interested
in having a file system based solution now (and possibly a hibernate
based solution later if we go dbconfig).

The roles can be hierarchical if something is wondering about the "parent"
attribute in roles.xml.

Do we really need hierarchy? Can't the same be obtained by composition
of roles in a user group?

Anyways, better than 6 files already, but I would go down to one if
possible, less cross referencing among the files and everything
just one one place that's easier to look up for the writer.
Adding a space for roles and groups in a user definition should
be easy

Ah, I appreciated the usage of attributes when possible to reduce
the xml boilerplate.

I was wondering whether to use a gml:ordinates like approach
for lists such as the roles ones:

<gsv:userroles username="user1">ROLE_WFS ROLE_WMS</gsv:userroles>

Though I guess I might be pushing the "simplify thy xml" thing a little
too far now

Cheers
Andrea

--
-------------------------------------------------------
Ing. Andrea Aime
GeoSolutions S.A.S.
Tech lead

Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy

phone: +39 0584 962313
fax: +39 0584 962313

http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.youtube.com/user/GeoSolutionsIT
http://www.linkedin.com/in/andreaaime
http://twitter.com/geowolf

-------------------------------------------------------

First, I truncated the message, otherwise we produce some confusion (who said what)

1) no JAXB, XStream will do the job

2) hierarchy is a very "cheap" feature. No geoserver code beyond the one I produce now will be concerned. I will flatten the hierarchy before you see it :slight_smile:

3) Two or one file. I see user/group management as a global enterprise issue (active directory as an example), roles and role associations are application specific. Its a common situation to fetch user/groups from a third party backend store, but having role associations in a local file. These two stores are loosely coupled, not every user/group in the enterprise needs roles for geoserver. I still like the idea of two files, but I can make make a third xml schema which is an aggregate of roles.xsd and users.xsd and store user/group/roles in one xml file. As a consequence, changing the user/group store gets more complicated.

Proposal: I will continue with two files till we can see the code in action. If the community dislikes the two file approach, I will merge. This is easier than splitting.

4)
<gsv:userroles username="user1">ROLE_WFS ROLE_WMS</gsv:userroles>
This is semantically not the same because no check is made by the validator if the roles exist. We could use an attribute of type ID_REFS having

<gsv:userroles username="user1" roles="ROLE_WFS ROLE_WMS"/>. This would work for
user/roles, group/roles and group/user relationships. I only fear , that for long lists, esp. group/users, the config file becomes difficult to read. Better a document with many lines as a document with long lines.

A also think we should not exaggerate the simplification.

Cheers
Christian

----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.

On Thu, May 26, 2011 at 12:43 AM, Andrea Aime <andrea.aime@anonymised.com> wrote:

On Thu, May 26, 2011 at 8:00 AM, <christian.mueller@anonymised.com> wrote:

XML would be the best. I added some samples to
http://jira.codehaus.org/browse/GEOS-4554
for further discussion.

@Justin, perhaps you should watch this issue.

I would strongly vote for 2 xml files, one for role management and one for
user/group management.

I created 2 xml schemes and 2 demo files and tried to keep it simple.
Using an XML schema has a lot of advantages. The user can edit with a tool
and validate, I can use JAXB for serializing/deserializing (if this is ok).

Time ago we noticed that adding jaxb jars in the path would break GML
handling due to some Eclipse XSD incompatibilities (as far as I
remember, Justin,
any help there?).
If you design your in memory classes carefully I believe you can just
use XStream, that is known to work.

Yeah afaik there were some issues with multiple versions of xerces required. Sounds like we are going xstream though.

I would implement the access logic using XPath. I looked at the
possibilities of DB2 and you can store even large xml files, access them via
XPath, create indices on nodes and so on. I think this is possible with
other products too.

Ok, good for alternative implementations, though we’re mainly interested
in having a file system based solution now (and possibly a hibernate
based solution later if we go dbconfig).

The roles can be hierarchical if something is wondering about the “parent”
attribute in roles.xml.

Do we really need hierarchy? Can’t the same be obtained by composition
of roles in a user group?

Anyways, better than 6 files already, but I would go down to one if
possible, less cross referencing among the files and everything
just one one place that’s easier to look up for the writer.
Adding a space for roles and groups in a user definition should
be easy

Ah, I appreciated the usage of attributes when possible to reduce
the xml boilerplate.

I was wondering whether to use a gml:ordinates like approach
for lists such as the roles ones:

<gsv:userroles username=“user1”>ROLE_WFS ROLE_WMS</gsv:userroles>

Though I guess I might be pushing the “simplify thy xml” thing a little
too far now

Cheers
Andrea

Ing. Andrea Aime
GeoSolutions S.A.S.
Tech lead

Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy

phone: +39 0584 962313
fax: +39 0584 962313

http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.youtube.com/user/GeoSolutionsIT
http://www.linkedin.com/in/andreaaime
http://twitter.com/geowolf



vRanger cuts backup time in half-while increasing security.
With the market-leading solution for virtual backup and recovery,
you get blazing-fast, flexible, and affordable data protection.
Download your free trial now.
http://p.sf.net/sfu/quest-d2dcopy1


Geoserver-devel mailing list
Geoserver-devel@anonymised.comsts.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel


Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.