Hi,
building on top of the new configuration GSIP, here is the "per layer
security GSIP", aka "data level security":
http://geoserver.org/display/GEOS/GSIP+19+-+Per+layer+security
Questions/comments/feedback welcome. It would be nice to be able to vote
on this in next week IRC meeting.
Cheers
Andrea
Andrea Aime wrote:
Questions/comments/feedback welcome. It would be nice to be able to vote
on this in next week IRC meeting.
Very well done: pretty simple and clear.
I haven't seen layer creation/erasing: is it supposed to be done by admin only ?
Another nitpick: does this proposal lend itself well to the RESTful Admin API ? What about writing down a draft for this portion of the API ?
Moreover, what about extending it to cover processing as well ?
I mean, if I have read-only access to two raster datasets and I want to generate a third one based on map algebra, I should be able to create a new raster dataset, right ? How can the ACL express that ?
Hmmm... this last requirement may complicate matters considerably though, just look at the XML Schema for Access Control List by OASIS:
http://docs.oasis-open.org/xacml/2.0/access_control-xacml-2.0-rbac-profile1-spec-os.pdf
Regards,
--------------------
Luca Morandini
www.lucamorandini.it
--------------------
Luca Morandini ha scritto:
Andrea Aime wrote:
Questions/comments/feedback welcome. It would be nice to be able to vote
on this in next week IRC meeting.Very well done: pretty simple and clear.
I haven't seen layer creation/erasing: is it supposed to be done by admin only ?
Good question. Layer creation and erasing as GeoServer stands today
are more like layer registering and un-registering, that is, you
don't really create the underlying feature type, you just find it
and make it available.
The current UI does not operate against the actual catalog, but against
a set of xxxConfig objects representing the current state of the
"unsaved" configuration. Applying security there too, also considering
that they are going the way of the Dodo after GeoServer 1.7.0,
seems like a waste of time...
Another nitpick: does this proposal lend itself well to the RESTful Admin API ? What about writing down a draft for this portion of the API ?
RESTFul admin will probably have its own way to identify resources
and security will be probably integrated into it by adding
a "security" sub-resources to each restful element. If you want to
think about it in terms of the current security property files, it
will be something like
/path/to/resource.operation=role1,role2,...
where operation is POST/PUT/DELETE and so on...
Moreover, what about extending it to cover processing as well ?
Good question, but I don't have an answer. Processing will be affected
by service and data security levels, but if you're thinking of securing
certain algorithms or securing ways to persistently store results
of computations back in GeoServer, then yes, we'll need ways to handle
that. How exactly I don't know, there is nothing in the current
GeoServer catalog API that allows for real creation of a new feature
type, and I believe there won't be for quite some time.
Even the WPS spec is setup so that the results can be stored, but
only to make the process request asynch. From the WPS spec, page 42:
"If storeExecuteResponse is --true? (see Table 50), then the execute response document shall be stored at a web accessible URL."
This is just like WCS GetCoverage, you can ask the coverage to be
stored, but that only means the server will give you an URL to
retrieve it later, not that the resulting coverage will be registered
into the server as a new layer.
I definitely see the interest in being able to actually register
the results as new layer that can be then used by the other OGC
services, but that's beyond the WPS spec.
I mean, if I have read-only access to two raster datasets and I want to generate a third one based on map algebra, I should be able to create a new raster dataset, right ? How can the ACL express that ?
Hmmm... this last requirement may complicate matters considerably though, just look at the XML Schema for Access Control List by OASIS:
http://docs.oasis-open.org/xacml/2.0/access_control-xacml-2.0-rbac-profile1-spec-os.pdf
Yeah, it's out of scope for this iteration. This improvement is funded,
but we have funding only to cover only vector data and only OGC services. I've included coverages in the proposal because that will
not require much extra effort, what you're proposing is definitely out
of the resources I can allocate.
Cheers
Andrea
Questions:
- we are making our own file format for capturing permissions and roles; can we not find one off the shelf?
- can we use an off the shelf ACL (ie something that has the possibility of growing to support attribute level restrictions) and only go as far as layer security right now?
Comments:
- http://www.acegisecurity.org/
- I understand that we are doing our own roll based access control list; here is a massive website of best practices for that Role Based Access Control | CSRC also lists patents etc...
- the layer.properties reminded me of the svn permissions (almost exactly)
Feedback:
- you are getting good at writing these up 
Jody
Andrea Aime wrote:
Hi,
building on top of the new configuration GSIP, here is the "per layer
security GSIP", aka "data level security":
http://geoserver.org/display/GEOS/GSIP+19+-+Per+layer+securityQuestions/comments/feedback welcome. It would be nice to be able to vote
on this in next week IRC meeting.Cheers
Andrea-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
Okay I am stupid; just made it to the end of your page and found the nice happy links... I still would like to place nice if Spring has a security module we can hook into...
Jody
Looks pretty cool Andrea, I like it. The only question I really have is about the conversation we had about workspace and namespace. I think we more or less came to the conclusion that what we think of as a "namespace" at the configuration level now will become a "workspace". And the idea of namespace will be something related to wfs, and more of an attribute on a layer rather then a container. So for transition purposes for now it makes sense to have namespaces and workspaces "mirror" each other.
So I guess my question is do we want to start referring to workspace now rather than workspace? Instead of having to change terminology later?
Andrea Aime wrote:
Hi,
building on top of the new configuration GSIP, here is the "per layer
security GSIP", aka "data level security":
http://geoserver.org/display/GEOS/GSIP+19+-+Per+layer+securityQuestions/comments/feedback welcome. It would be nice to be able to vote
on this in next week IRC meeting.Cheers
Andrea-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel!DSPAM:4007,48367a9d36662143011171!
--
Justin Deoliveira
The Open Planning Project
jdeolive@anonymised.com
Justin Deoliveira ha scritto:
Looks pretty cool Andrea, I like it. The only question I really have is about the conversation we had about workspace and namespace. I think we more or less came to the conclusion that what we think of as a "namespace" at the configuration level now will become a "workspace". And the idea of namespace will be something related to wfs, and more of an attribute on a layer rather then a container. So for transition purposes for now it makes sense to have namespaces and workspaces "mirror" each other.
So I guess my question is do we want to start referring to workspace now rather than workspace? Instead of having to change terminology later?
Hmmm... interesting one. If we do use workspace directly, I fear
user would start asking "what is a workspace and how do
I create one" and we'd have to answer talking about something which
is still not fully defined not implemented. So for the moment I
would stay with namespace, at least it's something familiar to the
current users.
Just my 2 cents
Cheers
Andrea
Hmmm... interesting one. If we do use workspace directly, I fear
user would start asking "what is a workspace and how do
I create one" and we'd have to answer talking about something which
is still not fully defined not implemented. So for the moment I
would stay with namespace, at least it's something familiar to the
current users.
That is true... however for 1.7.x the answer would be easy: "Its the same thing as namespace". How about this idea: Once the idea of a workspace does materialize we support security configuration based on both?
Just my 2 cents
Cheers
Andrea-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel!DSPAM:4007,483abed67115219720167!
--
Justin Deoliveira
The Open Planning Project
jdeolive@anonymised.com
Justin Deoliveira ha scritto:
Hmmm... interesting one. If we do use workspace directly, I fear
user would start asking "what is a workspace and how do
I create one" and we'd have to answer talking about something which
is still not fully defined not implemented. So for the moment I
would stay with namespace, at least it's something familiar to the
current users.That is true... however for 1.7.x the answer would be easy: "Its the same thing as namespace".
Right... do provide people with the workspace concept, is it
something they can see, "touch" by creating them thru the config UI, and so on? That's was more my concern. As a user I would not be very satisfied as "same thing as namespace" because it would introduce more
names to learn without any goodness for me, where's the advantage in having to learn yet another name until there's something more I can
do with it?
How about this idea: Once the idea of a workspace does materialize we support security configuration based on both?
Sure thing... we had this idea of having a namespace -> workspace relation anyways no? The moment you define a namespace, it becomes
a workspaces as well. But you can still create new ones that are
namespace unrelated.
Cheers
Andrea
Sure thing... we had this idea of having a namespace -> workspace relation anyways no? The moment you define a namespace, it becomes
a workspaces as well. But you can still create new ones that are
namespace unrelated.
Well my understanding was not to actually model a relationship between them, but simply for the time being ensure that whenever a namespace is created a workspace is also created to mirror it. In the final model I see workspace taking the place of namespace today (a grouping of datastores), and namespace simply becoming an attribute of a feature type or layer.
Cheers
Andrea!DSPAM:4007,483ad34c46061804284693!
--
Justin Deoliveira
The Open Planning Project
jdeolive@anonymised.com
Workspace sounds pretty similar to a mapserver "mapfile" 
I was not part of your conversation but it would help me if you considered namespace to be a "folder" in which you can group data; we can turn it into something more real over time. I assume a workspace would contain several namespaces; and be used to manage other non wfs content such as SLDs etc..
Cheers,
Jody
Justin Deoliveira wrote:
Looks pretty cool Andrea, I like it. The only question I really have is about the conversation we had about workspace and namespace. I think we more or less came to the conclusion that what we think of as a "namespace" at the configuration level now will become a "workspace". And the idea of namespace will be something related to wfs, and more of an attribute on a layer rather then a container. So for transition purposes for now it makes sense to have namespaces and workspaces "mirror" each other.
So I guess my question is do we want to start referring to workspace now rather than workspace? Instead of having to change terminology later?
Andrea Aime wrote:
Hi,
building on top of the new configuration GSIP, here is the "per layer
security GSIP", aka "data level security":
http://geoserver.org/display/GEOS/GSIP+19+-+Per+layer+securityQuestions/comments/feedback welcome. It would be nice to be able to vote
on this in next week IRC meeting.Cheers
Andrea-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel!DSPAM:4007,48367a9d36662143011171!
Justin Deoliveira ha scritto:
Sure thing... we had this idea of having a namespace -> workspace relation anyways no? The moment you define a namespace, it becomes
a workspaces as well. But you can still create new ones that are
namespace unrelated.Well my understanding was not to actually model a relationship between them, but simply for the time being ensure that whenever a namespace is created a workspace is also created to mirror it.
Hum... not sure this transition is going to be good. What about the
following:
- for the moment we stay with namespace, they are the only "real"
thing in GeoServer, workspace is not there, just a name in between
the clouds
- the day we introduce workspaces for good (as something that you
can define, use, configure), namespace cease to exist as a
grouping mechanism (no transition phase)
- that same day, for backwards compatibility, when we open an older
data dir, we ensure we create the relevant workspaces with the
same layers. But from there on, the two are separated.
It seems to me it's better to avoid introducing an automation
that we're going to remove afterwards.
A clarification. If I understand it properly, workspace may become a
class in 1.7.0, but nothing will really use it, no? If the code makes
sure that the workspace concept is temporarily attached to namespaces
I can write the security code to work directly against workspaces,
but once we get past the old model wrapper, workspaces are simply not
there... not in the UI, not in the storage format, not in the services.
That's why it seems to me from a user point of view they are kind of something we try to inflict without any apparent reason (we know
they will be the next real thing, but as long as 1.7.x is concerned,
they are not there...)
Opinions?
Cheers
Andrea
Hum... not sure this transition is going to be good. What about the
following:
- for the moment we stay with namespace, they are the only "real"
thing in GeoServer, workspace is not there, just a name in between
the clouds
- the day we introduce workspaces for good (as something that you
can define, use, configure), namespace cease to exist as a
grouping mechanism (no transition phase)
- that same day, for backwards compatibility, when we open an older
data dir, we ensure we create the relevant workspaces with the
same layers. But from there on, the two are separated.
I could go for this... but to me it seems meaner to simply remove the idea of namespace and replace it, rather then gradually transition to it. However workspace taking over wont wont apply until 2.x where we will be breaking backwards compatibility anyways...
It seems to me it's better to avoid introducing an automation
that we're going to remove afterwards.A clarification. If I understand it properly, workspace may become a
class in 1.7.0, but nothing will really use it, no? If the code makes
sure that the workspace concept is temporarily attached to namespaces
I can write the security code to work directly against workspaces,
but once we get past the old model wrapper, workspaces are simply not
there... not in the UI, not in the storage format, not in the services.
That's why it seems to me from a user point of view they are kind of something we try to inflict without any apparent reason (we know
they will be the next real thing, but as long as 1.7.x is concerned,
they are not there...)
Well my plan for 1.7.0 was to introduce workspace as the grouping for datastores instead of namespace, and use the technique of mirroring a workspace for every namespace. Then the old catalog code when asked to do lookups based on namespace would turn around and do a lookup on the new catalog based on workspace. Does that make sense?
Opinions?
Cheers
Andrea!DSPAM:4007,483ae31e75422092453641!
--
Justin Deoliveira
The Open Planning Project
jdeolive@anonymised.com
This was my initial thought as well, to retain just namespace as a grouping and then have the idea of a workspace map to it, and simply be a rest concept. However on more thought I figured it was useful to explicitly model the idea of a workspace. The main reason being that using namespace to group datastores rather than feature types has always seemed a bit off to me.
As for worksapce == mapfile... not sure, they are similar. But i think we came up with the idea of a "map" to be more of a mapfile like thing. I see workspace as more of a way to group data, as a mapfile more of way to group related layers and published information into... well a map :).
Jody Garnett wrote:
Workspace sounds pretty similar to a mapserver "mapfile"
I was not part of your conversation but it would help me if you considered namespace to be a "folder" in which you can group data; we can turn it into something more real over time. I assume a workspace would contain several namespaces; and be used to manage other non wfs content such as SLDs etc..
Cheers,
JodyJustin Deoliveira wrote:
Looks pretty cool Andrea, I like it. The only question I really have is about the conversation we had about workspace and namespace. I think we more or less came to the conclusion that what we think of as a "namespace" at the configuration level now will become a "workspace". And the idea of namespace will be something related to wfs, and more of an attribute on a layer rather then a container. So for transition purposes for now it makes sense to have namespaces and workspaces "mirror" each other.
So I guess my question is do we want to start referring to workspace now rather than workspace? Instead of having to change terminology later?
Andrea Aime wrote:
Hi,
building on top of the new configuration GSIP, here is the "per layer
security GSIP", aka "data level security":
http://geoserver.org/display/GEOS/GSIP+19+-+Per+layer+securityQuestions/comments/feedback welcome. It would be nice to be able to vote
on this in next week IRC meeting.Cheers
Andrea-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel!DSPAM:4007,483ae02270175332866982!
--
Justin Deoliveira
The Open Planning Project
jdeolive@anonymised.com
Justin Deoliveira ha scritto:
...
Well my plan for 1.7.0 was to introduce workspace as the grouping for datastores instead of namespace, and use the technique of mirroring a workspace for every namespace. Then the old catalog code when asked to do lookups based on namespace would turn around and do a lookup on the new catalog based on workspace. Does that make sense?
Say I request xyz:states, there is no namespace called xyz, and there
is a workspace called xyz, the response should still be that the
layer is not there, no? What I mean is that we do lookup names using
the namespace prefix, but the workspaces are not going to be associated
automatically with a namespace in the long run, so they won't participate in name lookup anyways?
Cheers
Andrea
Justin Deoliveira ha scritto:
Hum... not sure this transition is going to be good. What about the
following:
- for the moment we stay with namespace, they are the only "real"
thing in GeoServer, workspace is not there, just a name in between
the clouds
- the day we introduce workspaces for good (as something that you
can define, use, configure), namespace cease to exist as a
grouping mechanism (no transition phase)
- that same day, for backwards compatibility, when we open an older
data dir, we ensure we create the relevant workspaces with the
same layers. But from there on, the two are separated.I could go for this... but to me it seems meaner to simply remove the idea of namespace and replace it, rather then gradually transition to it. However workspace taking over wont wont apply until 2.x where we will be breaking backwards compatibility anyways...
And we'll have a tool to import old data directories into whatever
is the new format, which would keep things working as before, so
if you had namespace based security, the importer would turn
the namespaces into workspaces, and gs would start interpreting
the first part of a security rule as a workspace.
In the end, for the user GS would keep working the same until
they start changing the configuration. But at that point, they
will have to familiarize with workspaces anyways.
Cheers
Andrea
Say I request xyz:states, there is no namespace called xyz, and there
is a workspace called xyz, the response should still be that the
layer is not there, no? What I mean is that we do lookup names using
the namespace prefix, but the workspaces are not going to be associated
automatically with a namespace in the long run, so they won't participate in name lookup anyways?
Well in 1.7.x there will always be a namespace called xyz. Are you talking about in the long run? I think in the long run which is used to lookup the layer depends on the service. For instance in am OGC WFS call definitely there should be no layer reported in this case. However in a restful WFS call i could see the workspace grouping being acceptable. We could also use both namespace and workspace for layers in a WMS request.
Cheers
Andrea-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel!DSPAM:4007,483aeb9492022143011171!
--
Justin Deoliveira
The Open Planning Project
jdeolive@anonymised.com
And we'll have a tool to import old data directories into whatever
is the new format, which would keep things working as before, so
if you had namespace based security, the importer would turn
the namespaces into workspaces, and gs would start interpreting
the first part of a security rule as a workspace.In the end, for the user GS would keep working the same until
they start changing the configuration. But at that point, they
will have to familiarize with workspaces anyways.
Cool, this works for me then.
Cheers
Andrea!DSPAM:4007,483aec2f93195219720167!
--
Justin Deoliveira
The Open Planning Project
jdeolive@anonymised.com
Justin Deoliveira ha scritto:
Say I request xyz:states, there is no namespace called xyz, and there
is a workspace called xyz, the response should still be that the
layer is not there, no? What I mean is that we do lookup names using
the namespace prefix, but the workspaces are not going to be associated
automatically with a namespace in the long run, so they won't participate in name lookup anyways?Well in 1.7.x there will always be a namespace called xyz. Are you talking about in the long run? I think in the long run which is used to lookup the layer depends on the service. For instance in am OGC WFS call definitely there should be no layer reported in this case. However in a restful WFS call i could see the workspace grouping being acceptable. We could also use both namespace and workspace for layers in a WMS request.
Yeah, makes sense, thanks for the clarification 
Cheers
Andrea
Justin Deoliveira wrote:
This was my initial thought as well, to retain just namespace as a grouping and then have the idea of a workspace map to it, and simply be a rest concept. However on more thought I figured it was useful to explicitly model the idea of a workspace. The main reason being that using namespace to group datastores rather than feature types has always seemed a bit off to me.
Well said; and it is something to look into over the course of the GeoServer 2.0. I have more ideas on this subject then I can stand to see discused in email right now; lets get our configuration and user interface system sorted out so we can go on to these ideas.
As for worksapce == mapfile... not sure, they are similar. But i think we came up with the idea of a "map" to be more of a mapfile like thing. I see workspace as more of a way to group data, as a mapfile more of way to group related layers and published information into... well a map :).
Okay; workspace as more of a "workspace" kind of thing then ... I always viewed mapserver "mapfiles" as being this kind of "here is an entire configuration" option - but yeah with their focus on maps a mapfile is all they have to work with.
I am concerned here about growing scope ...
- can we ignore the idea for now?
- do we need to define this so the user interface designer can work on it? Or help us clarify our thinking
- can workspace be equated to a data directory?
- can we have multiple workspaces ...
If the idea of a workspace is going to be a first class object; in the users face; and front and center in the new ui we should wrap some scope on it now rather than later...
Jody