When data can't be open: Securing sensitive spatial data with open source software
MacAulay, Angus
When data can't be open - securing sensitive spatial data with open source software
 Yeah, so part of my talk, when data can't be open, securing sensitive spatial data with open source software. As mentioned, I work for Thuza, where a geospatial software consultancy. This talk is about our experience helping out the send of urban research, which is part of our MIT University on their Urban Observatory project. And also, other loavers are their funders for that project. So a bit about this talk. I'll go over the motivation of what I'm talking about when I say when data can't be open. An overview of our software stack for the Urban Observatory and what's involved in that. How we use Docker, which is part of that and the deployment. And the challenges we faced with this setup for securing data. So why can't data be open? If you're thinking about open street map or something like that, you're probably thinking, yeah, great. Open data, we love it. And we have open source software. That's great. So we just do the same thing with data. A couple of reasons. One is possibly commercial. Obviously, if people create data, they want to monetize it somehow. So there may be restrictions in that way, which we may have to deal with whether we like it or not. The second one is the data may be sensitive in some way. And we want to preserve privacy. The third one might be that it's classified or something like that. I'm not concerned with that third reason, but it might be relevant to you. It does come up in GIS, of course. So that it's the second reason, really, that's the topic of this talk. Well, the concern of this talk mostly. The urban observatory, as you'll see, provides indicated data about different areas. And whilst that data itself is aggregated, the source data that it's developed from ultimately has sensitive information because it has surveyed her and that kind of thing that's her individual. So I'd love to get into a chat with people later about the benefits of open data versus privacy. But I think you can see that there is obviously going to be some data sets where the just inherent nature of it is that you don't really want to make it open. It's not actually good for people. So there's a couple of different approaches to that. And as I said, we're not sharing that source data. We're sharing aggregated data. But nevertheless, there is still some security concerns. The other aspect of this is that we're looking for an out-of-the-box solution. We don't have the resources to go and build our own security system for scratch. And that's probably not a good idea anyway. And we are committed to open source. So we don't want to go down the road of the sort of cloud providers, which are sort of half open source, half proprietary. We want a fully open source stack. So a little bit about the Urban Observatory application. It is a digital platform that creates easily understood and engaging indicators for neighborhoods. And there's a tantalizing screenshot, which I'm just going to move on from because we haven't launched yet. So public application. How are we coming in March sometimes? Probably will be the community edition. The prototype of the application was built as a leaflet client with no JS and post-GIS backend. And that was very neat. It demonstrated that the user level functionality that the Center for Urban Research wanted was achievable. But the prototype had no authentication and no authorization of any kind. And it didn't really have any data management aspect to it. It was just sort of shove everything in post-GIS however you can and get it out as GeoJSON, which is absolutely fine for a prototype. But we need authentication and we need authorization for some of the reasons that I mentioned before. And also we wanted to be able to have users register. So there will be publicly available data that is open in some sense, but you have to at least identify yourself in some way before you can get access to it. So GeoNode to the rescue. I don't know how many of you have heard of GeoNode. I've been working in the open source geospatial world for quite a while and I'd only vaguely heard about it up until relatively recently. I was just using a GeoServer based stack or something like that most of the time. It's comprised of GeoServer and post-GIS, but it also adds a Django application which provides, I guess, functionality. It was originally released in 2010, so it's been around a little while. It enhances the GeoServer post-GIS stack with a data catalog and data management tools. And it also has a way that you can build your own maps and user interfaces, but we didn't use that part of it, as I'll explain. We sort of had our custom thing that sits to one side. Critically, it can provide authentication via OOS 2 and it integrates this with GeoServer to do authorization and find rate permission controls and that kind of thing with GeoServer and Geofence. So what does that look like? What does it look like to integrate with GeoNode? As I said, you can build web mapping applications into GeoNode. That's sort of how it's intended to be used. That isn't how we use it. We actually took the prototype of an observatory application and we ran it up beside GeoNode, which presented some challenges, but it had some advantages as well. So you run it up beside GeoNode and then use an NGINX web proxy to tie everything together so it's all in the same domain. We've got separate components, but they all work together as one. And the observatory application authenticates with GeoNode to access GeoServer. So it's using GeoNode's OAuth. The observatory application is authenticating with GeoNode's OAuth and then it's using the access token that it gets from there to request data from GeoServer. There's a little diagram. GeoServer is what's called the relying party and GeoNode is the OAuth provider. And as I said before, GeoNode provides the fine-grained permissions and groups that we need. So it has a tool where we can go in and configure. This group of users has access to this set of data, read versus write, et cetera. And GeoNode handles all that with GeoServer, which is really important because there are ways you can do these sorts of solutions with GeoServer directly. But we're looking where possible. It's very helpful if someone's already set that up. And the observatory client communicates with both GeoNode and GeoServer. Some page scrapping is involved. So this is where by keeping our application somewhat separate, we did add some difficulty for ourselves in some ways. GeoNode doesn't have a REST-like library for its authentication or anything like that. So we're using its front-facing web client as an API. But it's not too bad because everything's on the same domain, as I was saying before, looking into patching GeoNode to make that case a little more straightforward. But it works. So the other aspect of this, in terms of making this solution as out of the box and straightforward as possible, is deployment with Docker. For those of you who are not familiar with Docker, maybe you're not. Here's a little quote. Docker is a computer program that performs operating system level virtualization, also known as containerization. And if you didn't know what Docker was before, you probably still don't get a lot out of that. The point is that we can run different components of our system as if they're on their own operating system, even though they're all on the same host. And we can control that to some extent. Not to a great extent. And then Docker Compose is a container orchestration system. So Docker defines how those containers work in and out themselves. Docker Compose is about how the components work together. GeoNode comes with Docker configuration and a Docker Compose configuration. So that was a great help to us. All we had to do is take the GeoNode Docker Compose file and make our own version of that that included our observatory application as an additional component. There's a little bit more to it than that. But we also created a custom NDEX Docker image for our web proxy, including various different proxying aspects. But again, it was taken from the default GeoNode one, just a modified version. So how about that out of the box security? I was hinting at how straightforward is it? Well, not quite. As I said, integrating custom applications requires some page scraping. You wouldn't have to do that if you didn't want to keep your application separate in the way that we did. And it's not too onerous. And it doesn't really impinge on the security aspect of it. But it doesn't impinge on the out of the box aspect of it. This one indeed does impinge on the security aspect of it. The default credentials for Django and GeoServer are not secure. That is, when you run up a GeoNode straight out of the Git repository and you put that on the open web, you will have the default Django admin credentials and the default GeoServer admin credentials. And they'll be out there. And I don't want to say too much more about that. But you might find some interesting things if you start Googling for live GeoNode instances, but not ours. The OOS system requires some setup is another challenge. It's not too onerous, there's just a bit of box ticking and so on, but it's just in terms of managing deployment and that sort of thing, you have to think about that. And some challenges. It's not always clear how the security model works. There's quite a lot of documentation in GeoNode about it, but when you get down to the level of figuring out access tokens and what's in which cookie and what you need, that's a bit more of a trial and error thing. Docker makes GeoNode more difficult to administer. So again, this doesn't impinge on the security aspect of it, but GeoNode has a really neat command line tool that you can use to do data management. And because Docker is made sort of each container does one thing, the GeoNode images one thing is providing a web portal so it doesn't expose the command line. So you've sort of got to fight your way into the command line on the Docker image and do things on there. It's a bit unpleasant. Perhaps one way around that is to have scripts that are separate as part of the scripts that call the GeoNode CLI and they would get run as the Docker image comes up or something like that. But it's something that the two paradigms of Docker versus GeoNode don't go together perfectly. And along the same lines, the usage of Docker, the componentization of GeoNode into Docker containers, breaks the inbuilt GeoNode backup and replication because it uses PG dump and assumes you're on the same host. But of course, as soon as you componentize it, containerize it from inside those containers, it's as if the database and GeoNode are on separate hosts. So then the question is, do you work on the GeoNode side of that or do you just use Docker itself to do replication and that's still something we're figuring out. And another challenge that comes up, scalability isn't guaranteed. Again, this doesn't impinge on the security aspect of it. And this is something that would happen whatever you're doing with Docker. It's just that you might think that if you have a Docker configuration, a composed configuration, then you can just automatically scale up all your images in a Kubernetes instance or something like that. But you still have replication issues in your database and scale up because if you've got a live database, you can't just scale it up like that. That's it. Questions? I'll just ask. You said it doesn't, GeoNode doesn't have an API. It does have some APIs, but for the specific use case of authorization, authentication at the moment. So we're doing a form post when ideally you do a SQL post. I can talk you through the details. It does have APIs. Do you know if GeoNode has any federation capability with other authentication providers like Active Directory or LDAP? I know that we can. So we're using GeoNode as the author provider. I believe, and we're going to look into this in the future, you can use other OAuth providers. I couldn't tell you for certain about Active Directory. I know there is some stuff for GeoServer and Active Directory. But there are ways to tie in with other authentication providers. I just had a question. When you're looking at approaches for being able to protect data, were there any that dealt with feature level permissions and requests? There's only something I can fit into a talk. What I wanted to say is that one of the advantages of this system is that we can potentially instance our stopper environment and have internal systems where you have the really sensitive data and then you have different systems to different broad categories of data. So that would be the approach that if I had specific features that I wanted to restrict, I'd probably manage it almost with different instances. You can do per layer, of course, as I mentioned. So her feature would be tricky and I don't think GeoNode supports that. But yeah, there might be ways to do that in effect by dividing up the data somehow.
 Yeah, so part of my talk, when data can't be open,  securing sensitive spatial data with open source software.  As mentioned, I work for Thuza, where  a geospatial software consultancy.  This talk is about our experience  helping out the send of urban research, which  is part of our MIT University on their Urban Observatory  project.  And also, other loavers are their funders for that project.  So a bit about this talk.  I'll go over the motivation of what  I'm talking about when I say when data can't be open.  An overview of our software stack for the Urban Observatory  and what's involved in that.  How we use Docker, which is part of that and the deployment.  And the challenges we faced with this setup for securing data.  So why can't data be open?  If you're thinking about open street map or something  like that, you're probably thinking, yeah, great.  Open data, we love it.  And we have open source software.  That's great.  So we just do the same thing with data.  A couple of reasons.  One is possibly commercial.  Obviously, if people create data,  they want to monetize it somehow.  So there may be restrictions in that way,  which we may have to deal with whether we like it  or not.  The second one is the data may be sensitive in some way.  And we want to preserve privacy.  The third one might be that it's classified or something  like that.  I'm not concerned with that third reason,  but it might be relevant to you.  It does come up in GIS, of course.  So that it's the second reason, really,  that's the topic of this talk.  Well, the concern of this talk mostly.  The urban observatory, as you'll see,  provides indicated data about different areas.  And whilst that data itself is aggregated,  the source data that it's developed from  ultimately has sensitive information  because it has surveyed her and that kind of thing  that's her individual.  So I'd love to get into a chat with people later  about the benefits of open data versus privacy.  But I think you can see that there is obviously  going to be some data sets where the just inherent nature of it  is that you don't really want to make it open.  It's not actually good for people.  So there's a couple of different approaches to that.  And as I said, we're not sharing that source data.  We're sharing aggregated data.  But nevertheless, there is still some security concerns.  The other aspect of this is that we're  looking for an out-of-the-box solution.  We don't have the resources to go and build our own security  system for scratch.  And that's probably not a good idea anyway.  And we are committed to open source.  So we don't want to go down the road of the sort of cloud  providers, which are sort of half open source,  half proprietary.  We want a fully open source stack.  So a little bit about the Urban Observatory application.  It is a digital platform that creates easily understood  and engaging indicators for neighborhoods.  And there's a tantalizing screenshot,  which I'm just going to move on from because we haven't  launched yet.  So public application.  How are we coming in March sometimes?  Probably will be the community edition.  The prototype of the application was built as a  leaflet client with no JS and post-GIS backend.  And that was very neat.  It demonstrated that the user level functionality that  the Center for Urban Research wanted was achievable.  But the prototype had no authentication and no  authorization of any kind.  And it didn't really have any data management aspect to it.  It was just sort of shove everything in post-GIS however  you can and get it out as GeoJSON, which is absolutely  fine for a prototype.  But we need authentication and we need authorization for  some of the reasons that I mentioned before.  And also we wanted to be able to have users register.  So there will be publicly available data that is open  in some sense, but you have to at least identify yourself in  some way before you can get access to it.  So GeoNode to the rescue.  I don't know how many of you have heard of GeoNode.  I've been working in the open source geospatial world for  quite a while and I'd only vaguely heard about it up  until relatively recently.  I was just using a GeoServer based stack or  something like that most of the time.  It's comprised of GeoServer and post-GIS, but it also adds  a Django application which provides, I guess, functionality.  It was originally released in 2010, so it's been around a  little while.  It enhances the GeoServer post-GIS stack with a data  catalog and data management tools.  And it also has a way that you can build your own maps and  user interfaces, but we didn't use that part of it, as I'll  explain.  We sort of had our custom thing that sits to one side.  Critically, it can provide authentication via OOS 2 and it  integrates this with GeoServer to do authorization and find  rate permission controls and that kind of thing with GeoServer  and Geofence.  So what does that look like?  What does it look like to integrate with GeoNode?  As I said, you can build web mapping applications into  GeoNode.  That's sort of how it's intended to be used.  That isn't how we use it.  We actually took the prototype of an observatory  application and we ran it up beside GeoNode, which  presented some challenges, but it had some advantages as well.  So you run it up beside GeoNode and then use an NGINX  web proxy to tie everything together so it's all in the  same domain.  We've got separate components, but they all work together as  one.  And the observatory application authenticates with  GeoNode to access GeoServer.  So it's using GeoNode's OAuth.  The observatory application is authenticating with GeoNode's  OAuth and then it's using the access token that it gets from  there to request data from GeoServer.  There's a little diagram.  GeoServer is what's called the relying party and GeoNode is  the OAuth provider.  And as I said before, GeoNode provides the fine-grained  permissions and groups that we need.  So it has a tool where we can go in and configure.  This group of users has access to this set of data, read  versus write, et cetera.  And GeoNode handles all that with GeoServer, which is  really important because there are ways you can do these  sorts of solutions with GeoServer directly.  But we're looking where possible.  It's very helpful if someone's already set that up.  And the observatory client communicates with both GeoNode  and GeoServer.  Some page scrapping is involved.  So this is where by keeping our application somewhat  separate, we did add some difficulty for ourselves in  some ways.  GeoNode doesn't have a REST-like library for its  authentication or anything like that.  So we're using its front-facing web client as an API.  But it's not too bad because everything's on the same  domain, as I was saying before, looking into patching  GeoNode to make that case a little more straightforward.  But it works.  So the other aspect of this, in terms of making this  solution as out of the box and straightforward as possible,  is deployment with Docker.  For those of you who are not familiar with Docker, maybe  you're not.  Here's a little quote.  Docker is a computer program that performs operating  system level virtualization, also known as  containerization.  And if you didn't know what Docker was before, you  probably still don't get a lot out of that.  The point is that we can run different components of our  system as if they're on their own operating system, even  though they're all on the same host.  And we can control that to some extent.  Not to a great extent.  And then Docker Compose is a container  orchestration system.  So Docker defines how those containers work in and out  themselves.  Docker Compose is about how the components work together.  GeoNode comes with Docker configuration and a Docker  Compose configuration.  So that was a great help to us.  All we had to do is take the GeoNode Docker Compose file  and make our own version of that that included our  observatory application as an additional component.  There's a little bit more to it than that.  But we also created a custom NDEX Docker image for our  web proxy, including various different  proxying aspects.  But again, it was taken from the default GeoNode one, just  a modified version.  So how about that out of the box security?  I was hinting at how straightforward is it?  Well, not quite.  As I said, integrating custom applications requires some  page scraping.  You wouldn't have to do that if you didn't want to keep your  application separate in the way that we did.  And it's not too onerous.  And it doesn't really impinge on the security aspect of it.  But it doesn't impinge on the out of the box aspect of it.  This one indeed does impinge on the security aspect of it.  The default credentials for Django and GeoServer are not  secure.  That is, when you run up a GeoNode straight out of the  Git repository and you put that on the open web, you will  have the default Django admin credentials and the default  GeoServer admin credentials.  And they'll be out there.  And I don't want to say too much more about that.  But you might find some interesting things if you  start Googling for live GeoNode instances, but not ours.  The OOS system requires some setup is another challenge.  It's not too onerous, there's just a bit of box ticking and  so on, but it's just in terms of managing deployment and  that sort of thing, you have to think about that.  And some challenges.  It's not always clear how the security model works.  There's quite a lot of documentation in GeoNode about  it, but when you get down to the level of figuring out  access tokens and what's in which cookie and what you  need, that's a bit more of a trial and error thing.  Docker makes GeoNode more difficult to administer.  So again, this doesn't impinge on the security aspect of it,  but GeoNode has a really neat command line tool that you  can use to do data management.  And because Docker is made sort of each container does one  thing, the GeoNode images one thing is providing a web portal  so it doesn't expose the command line.  So you've sort of got to fight your way into the command  line on the Docker image and do things on there.  It's a bit unpleasant.  Perhaps one way around that is to have scripts that are  separate as part of the scripts that call the GeoNode CLI  and they would get run as the Docker image comes up or  something like that.  But it's something that the two paradigms of Docker versus  GeoNode don't go together perfectly.  And along the same lines, the usage of Docker, the  componentization of GeoNode into Docker containers,  breaks the inbuilt GeoNode backup and replication because  it uses PG dump and assumes you're on the same host.  But of course, as soon as you componentize it, containerize  it from inside those containers, it's as if the  database and GeoNode are on separate hosts.  So then the question is, do you work on the GeoNode side of  that or do you just use Docker itself to do replication and  that's still something we're figuring out.  And another challenge that comes up, scalability isn't  guaranteed.  Again, this doesn't impinge on the security aspect of it.  And this is something that would happen whatever you're  doing with Docker.  It's just that you might think that if you have a Docker  configuration, a composed configuration, then you can  just automatically scale up all your images in a Kubernetes  instance or something like that.  But you still have replication issues in your database  and scale up because if you've got a live database, you  can't just scale it up like that.  That's it.  Questions?  I'll just ask.  You said it doesn't, GeoNode doesn't have an API.  It does have some APIs, but for the specific use case of  authorization, authentication at the moment.  So we're doing a form post when ideally you do a  SQL post.  I can talk you through the details.  It does have APIs.  Do you know if GeoNode has any federation capability with  other authentication providers like Active Directory or  LDAP?  I know that we can.  So we're using GeoNode as the author provider.  I believe, and we're going to look into this in the future,  you can use other OAuth providers.  I couldn't tell you for certain about Active Directory.  I know there is some stuff for GeoServer and Active  Directory.  But there are ways to tie in with other  authentication providers.  I just had a question.  When you're looking at approaches for being able to  protect data, were there any that dealt with feature level  permissions and requests?  There's only something I can fit into a talk.  What I wanted to say is that one of the advantages of this  system is that we can potentially instance our  stopper environment and have internal systems where you  have the really sensitive data and then you have different  systems to different broad categories of data.  So that would be the approach that if I had specific  features that I wanted to restrict, I'd probably manage  it almost with different instances.  You can do per layer, of course, as I mentioned.  So her feature would be tricky and I don't think GeoNode  supports that.  But yeah, there might be ways to do that in effect by  dividing up the data somehow.
Angus_MacAulay__When_data_can_t_be_open_MBIqxkr_sC8_0_71.png Angus_MacAulay__When_data_can_t_be_open_MBIqxkr_sC8_72_1055.png Angus_MacAulay__When_data_can_t_be_open_MBIqxkr_sC8_1056_2399.png Angus_MacAulay__When_data_can_t_be_open_MBIqxkr_sC8_2400_4295.png Angus_MacAulay__When_data_can_t_be_open_MBIqxkr_sC8_4296_12851.png Angus_MacAulay__When_data_can_t_be_open_MBIqxkr_sC8_12852_15863.png Angus_MacAulay__When_data_can_t_be_open_MBIqxkr_sC8_15864_18263.png Angus_MacAulay__When_data_can_t_be_open_MBIqxkr_sC8_18264_19823.png Angus_MacAulay__When_data_can_t_be_open_MBIqxkr_sC8_19824_25259.png Angus_MacAulay__When_data_can_t_be_open_MBIqxkr_sC8_25260_26027.png Angus_MacAulay__When_data_can_t_be_open_MBIqxkr_sC8_26028_26603.png Angus_MacAulay__When_data_can_t_be_open_MBIqxkr_sC8_26604_26675.png Angus_MacAulay__When_data_can_t_be_open_MBIqxkr_sC8_26676_27095.png Angus_MacAulay__When_data_can_t_be_open_MBIqxkr_sC8_27096_27179.png Angus_MacAulay__When_data_can_t_be_open_MBIqxkr_sC8_27180_27227.png Angus_MacAulay__When_data_can_t_be_open_MBIqxkr_sC8_27228_27287.png Angus_MacAulay__When_data_can_t_be_open_MBIqxkr_sC8_27288_27563.png Angus_MacAulay__When_data_can_t_be_open_MBIqxkr_sC8_27564_27803.png Angus_MacAulay__When_data_can_t_be_open_MBIqxkr_sC8_27804_27995.png Angus_MacAulay__When_data_can_t_be_open_MBIqxkr_sC8_27996_28103.png Angus_MacAulay__When_data_can_t_be_open_MBIqxkr_sC8_28104_28151.png Angus_MacAulay__When_data_can_t_be_open_MBIqxkr_sC8_28152_28727.png Angus_MacAulay__When_data_can_t_be_open_MBIqxkr_sC8_28728_29041.png
Yeah, so part of my talk, when data can't be open, securing sensitive spatial data with open source software. As mentioned, I work for Thuza, where a geospatial software consultancy. This talk is about our experience helping out the send of urban research, which is part of our MIT University on their Urban Observatory project. And also, other loavers are their funders for that project. So a bit about this talk. I'll go over the motivation of what I'm talking about when I say when data can't be open. An overview of our software stack for the Urban Observatory and what's involved in that. How we use Docker, which is part of that and the deployment. And the challenges we faced with this setup for securing data. So why can't data be open? If you're thinking about open street map or something like that, you're probably thinking, yeah, great. Open data, we love it. And we have open source software. That's great. So we just do the same thing with data. A couple of reasons. One is possibly commercial. Obviously, if people create data, they want to monetize it somehow. So there may be restrictions in that way, which we may have to deal with whether we like it or not. The second one is the data may be sensitive in some way. And we want to preserve privacy. The third one might be that it's classified or something like that. I'm not concerned with that third reason, but it might be relevant to you. It does come up in GIS, of course. So that it's the second reason, really, that's the topic of this talk. Well, the concern of this talk mostly. The urban observatory, as you'll see, provides indicated data about different areas. And whilst that data itself is aggregated, the source data that it's developed from ultimately has sensitive information because it has surveyed her and that kind of thing that's her individual. So I'd love to get into a chat with people later about the benefits of open data versus privacy. But I think you can see that there is obviously going to be some data sets where the just inherent nature of it is that you don't really want to make it open. It's not actually good for people. So there's a couple of different approaches to that. And as I said, we're not sharing that source data. We're sharing aggregated data. But nevertheless, there is still some security concerns. The other aspect of this is that we're looking for an out-of-the-box solution. We don't have the resources to go and build our own security system for scratch. And that's probably not a good idea anyway. And we are committed to open source. So we don't want to go down the road of the sort of cloud providers, which are sort of half open source, half proprietary. We want a fully open source stack. So a little bit about the Urban Observatory application. It is a digital platform that creates easily understood and engaging indicators for neighborhoods. And there's a tantalizing screenshot, which I'm just going to move on from because we haven't launched yet. So public application. How are we coming in March sometimes? Probably will be the community edition. The prototype of the application was built as a leaflet client with no JS and post-GIS backend. And that was very neat. It demonstrated that the user level functionality that the Center for Urban Research wanted was achievable. But the prototype had no authentication and no authorization of any kind. And it didn't really have any data management aspect to it. It was just sort of shove everything in post-GIS however you can and get it out as GeoJSON, which is absolutely fine for a prototype. But we need authentication and we need authorization for some of the reasons that I mentioned before. And also we wanted to be able to have users register. So there will be publicly available data that is open in some sense, but you have to at least identify yourself in some way before you can get access to it. So GeoNode to the rescue. I don't know how many of you have heard of GeoNode. I've been working in the open source geospatial world for quite a while and I'd only vaguely heard about it up until relatively recently. I was just using a GeoServer based stack or something like that most of the time. It's comprised of GeoServer and post-GIS, but it also adds a Django application which provides, I guess, functionality. It was originally released in 2010, so it's been around a little while. It enhances the GeoServer post-GIS stack with a data catalog and data management tools. And it also has a way that you can build your own maps and user interfaces, but we didn't use that part of it, as I'll explain. We sort of had our custom thing that sits to one side. Critically, it can provide authentication via OOS 2 and it integrates this with GeoServer to do authorization and find rate permission controls and that kind of thing with GeoServer and Geofence. So what does that look like? What does it look like to integrate with GeoNode? As I said, you can build web mapping applications into GeoNode. That's sort of how it's intended to be used. That isn't how we use it. We actually took the prototype of an observatory application and we ran it up beside GeoNode, which presented some challenges, but it had some advantages as well. So you run it up beside GeoNode and then use an NGINX web proxy to tie everything together so it's all in the same domain. We've got separate components, but they all work together as one. And the observatory application authenticates with GeoNode to access GeoServer. So it's using GeoNode's OAuth. The observatory application is authenticating with GeoNode's OAuth and then it's using the access token that it gets from there to request data from GeoServer. There's a little diagram. GeoServer is what's called the relying party and GeoNode is the OAuth provider. And as I said before, GeoNode provides the fine-grained permissions and groups that we need. So it has a tool where we can go in and configure. This group of users has access to this set of data, read versus write, et cetera. And GeoNode handles all that with GeoServer, which is really important because there are ways you can do these sorts of solutions with GeoServer directly. But we're looking where possible. It's very helpful if someone's already set that up. And the observatory client communicates with both GeoNode and GeoServer. Some page scrapping is involved. So this is where by keeping our application somewhat separate, we did add some difficulty for ourselves in some ways. GeoNode doesn't have a REST-like library for its authentication or anything like that. So we're using its front-facing web client as an API. But it's not too bad because everything's on the same domain, as I was saying before, looking into patching GeoNode to make that case a little more straightforward. But it works. So the other aspect of this, in terms of making this solution as out of the box and straightforward as possible, is deployment with Docker. For those of you who are not familiar with Docker, maybe you're not. Here's a little quote. Docker is a computer program that performs operating system level virtualization, also known as containerization. And if you didn't know what Docker was before, you probably still don't get a lot out of that. The point is that we can run different components of our system as if they're on their own operating system, even though they're all on the same host. And we can control that to some extent. Not to a great extent. And then Docker Compose is a container orchestration system. So Docker defines how those containers work in and out themselves. Docker Compose is about how the components work together. GeoNode comes with Docker configuration and a Docker Compose configuration. So that was a great help to us. All we had to do is take the GeoNode Docker Compose file and make our own version of that that included our observatory application as an additional component. There's a little bit more to it than that. But we also created a custom NDEX Docker image for our web proxy, including various different proxying aspects. But again, it was taken from the default GeoNode one, just a modified version. So how about that out of the box security? I was hinting at how straightforward is it? Well, not quite. As I said, integrating custom applications requires some page scraping. You wouldn't have to do that if you didn't want to keep your application separate in the way that we did. And it's not too onerous. And it doesn't really impinge on the security aspect of it. But it doesn't impinge on the out of the box aspect of it. This one indeed does impinge on the security aspect of it. The default credentials for Django and GeoServer are not secure. That is, when you run up a GeoNode straight out of the Git repository and you put that on the open web, you will have the default Django admin credentials and the default GeoServer admin credentials. And they'll be out there. And I don't want to say too much more about that. But you might find some interesting things if you start Googling for live GeoNode instances, but not ours. The OOS system requires some setup is another challenge. It's not too onerous, there's just a bit of box ticking and so on, but it's just in terms of managing deployment and that sort of thing, you have to think about that. And some challenges. It's not always clear how the security model works. There's quite a lot of documentation in GeoNode about it, but when you get down to the level of figuring out access tokens and what's in which cookie and what you need, that's a bit more of a trial and error thing. Docker makes GeoNode more difficult to administer. So again, this doesn't impinge on the security aspect of it, but GeoNode has a really neat command line tool that you can use to do data management. And because Docker is made sort of each container does one thing, the GeoNode images one thing is providing a web portal so it doesn't expose the command line. So you've sort of got to fight your way into the command line on the Docker image and do things on there. It's a bit unpleasant. Perhaps one way around that is to have scripts that are separate as part of the scripts that call the GeoNode CLI and they would get run as the Docker image comes up or something like that. But it's something that the two paradigms of Docker versus GeoNode don't go together perfectly. And along the same lines, the usage of Docker, the componentization of GeoNode into Docker containers, breaks the inbuilt GeoNode backup and replication because it uses PG dump and assumes you're on the same host. But of course, as soon as you componentize it, containerize it from inside those containers, it's as if the database and GeoNode are on separate hosts. So then the question is, do you work on the GeoNode side of that or do you just use Docker itself to do replication and that's still something we're figuring out. And another challenge that comes up, scalability isn't guaranteed. Again, this doesn't impinge on the security aspect of it. And this is something that would happen whatever you're doing with Docker. It's just that you might think that if you have a Docker configuration, a composed configuration, then you can just automatically scale up all your images in a Kubernetes instance or something like that. But you still have replication issues in your database and scale up because if you've got a live database, you can't just scale it up like that. That's it. Questions? I'll just ask. You said it doesn't, GeoNode doesn't have an API. It does have some APIs, but for the specific use case of authorization, authentication at the moment. So we're doing a form post when ideally you do a SQL post. I can talk you through the details. It does have APIs. Do you know if GeoNode has any federation capability with other authentication providers like Active Directory or LDAP? I know that we can. So we're using GeoNode as the author provider. I believe, and we're going to look into this in the future, you can use other OAuth providers. I couldn't tell you for certain about Active Directory. I know there is some stuff for GeoServer and Active Directory. But there are ways to tie in with other authentication providers. I just had a question. When you're looking at approaches for being able to protect data, were there any that dealt with feature level permissions and requests? There's only something I can fit into a talk. What I wanted to say is that one of the advantages of this system is that we can potentially instance our stopper environment and have internal systems where you have the really sensitive data and then you have different systems to different broad categories of data. So that would be the approach that if I had specific features that I wanted to restrict, I'd probably manage it almost with different instances. You can do per layer, of course, as I mentioned. So her feature would be tricky and I don't think GeoNode supports that. But yeah, there might be ways to do that in effect by dividing up the data somehow.
open, securing sensitive spatial data with open