Mastering Security with GeoServer and GeoFence
This is a modal window.
The media could not be loaded, either because the server or network failed or because the format is not supported.
Formal Metadata
| Title |
| |
| Title of Series | ||
| Part Number | 109 | |
| Number of Parts | 193 | |
| Author | ||
| License | CC Attribution 3.0 Germany: You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor. | |
| Identifiers | 10.5446/20395 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
|
FOSS4G Bonn 2016109 / 193
8
20
21
27
28
34
39
51
53
56
61
64
66
68
72
75
78
79
80
84
104
108
112
120
123
126
130
131
134
135
140
142
143
145
146
153
154
157
160
165
182
183
188
190
00:00
Lie group3 (number)Goodness of fit
00:22
Information securityEndliche ModelltheorieEvent horizonLecture/Conference
00:47
GeometryServer (computing)Information securityClient (computing)Java appletJava EnterpriseImage processingBoom (sailing)Server (computing)Rule of inferenceInformation securityWordProduct (business)Cartesian coordinate system
01:23
Client (computing)Server (computing)GeometryJava appletJava EnterpriseVisualization (computer graphics)Image processingData fusionInformation securityAuthenticationAuthorizationService-oriented architectureLibrary catalogPhysical systemInformation securityIdentity managementService-oriented architectureAuthorizationCartesian coordinate systemPrice indexProgram flowchart
02:46
Information securityServer (computing)GeometryAuthorizationAuthenticationDifferent (Kate Ryan album)Group actionChainUniform resource locatorDigital filterLibrary catalogRule of inferenceFiltrationInformation securityExtension (kinesiology)Spring (hydrology)Standard deviationChainLine (geometry)Service-oriented architectureAuthenticationConnectivity (graph theory)Point (geometry)Internet service providerMereologyType theoryPhysical systemBitSystem administratorElement (mathematics)MathematicsGreatest elementRight angleBlock (periodic table)Set (mathematics)Domain nameLibrary (computing)Data managementCategory of beingServer (computing)Different (Kate Ryan album)AuthorizationImplementationSoftware frameworkRepresentational state transferGeneric programmingWrapper (data mining)Filter <Stochastik>Module (mathematics)
06:54
ChainDifferent (Kate Ryan album)Uniform resource locatorGroup actionDigital filterWide area networkService-oriented architectureForm (programming)Lemma (mathematics)AuthenticationService (economics)Variable (mathematics)Integrated development environmentImplementationEmailChainMechanism designInterface (computing)AuthenticationGene clusterForm (programming)Default (computer science)Public key certificatePhysical systemElectronic mailing listPrice indexMultiplication signSequenceService (economics)Information securityDifferent (Kate Ryan album)Filter <Stochastik>Set (mathematics)Sampling (statistics)Group actionINTEGRALClassical physicsWeb 2.0System administratorLattice (group)Field (computer science)Fitness functionPhase transitionForcing (mathematics)Server (computing)Service-oriented architectureCodeRule of inferenceLoginFiltrationSystem callHTTP cookieComputer animation
09:07
ImplementationChainService (economics)Digital filterValue-added networkDynamic random-access memoryAuthenticationFundamental theorem of algebraAuthorizationSign (mathematics)Single-precision floating-point formatDisintegrationKey (cryptography)Extension (kinesiology)Uniform resource locatorGroup actionGeneric programmingLocal GroupCoordinate systemINTEGRALRule of inferenceDatabaseMereologyData storage deviceTask (computing)Staff (military)Physical systemAlpha (investment)AdditionImplementationInverse elementThermal expansionServer (computing)Internet service providerGroup actionLimit (category theory)Filter <Stochastik>Phase transitionAuthenticationPrice indexCASE <Informatik>MetreDifferent (Kate Ryan album)MathematicsToken ringExtension (kinesiology)Flow separationRight angleInterface (computing)Single-precision floating-point formatSet (mathematics)Service (economics)Library (computing)Doppler-EffektInformation securitySocial classParticle systemPressureRepository (publishing)AreaRow (database)Core dumpKeyboard shortcutConnectivity (graph theory)Moment (mathematics)AuthorizationStructural loadLevel (video gaming)Similarity (geometry)Shared memory1 (number)Computer configurationLecture/Conference
14:40
3 (number)Interface (computing)Limit (category theory)Line (geometry)Library catalogTemporal logicInformation securityDefault (computer science)GeometryEnterprise architectureAuthenticationMechanism designRule of inferenceLocal GroupInstance (computer science)Server (computing)Single-precision floating-point formatService-oriented architectureMilitary operationCluster samplingAttribute grammarComputer configurationAddress spaceLimit (category theory)Constraint (mathematics)Connectivity (graph theory)CASE <Informatik>Multiplication signSpeech synthesisData managementPhysical systemModule (mathematics)Core dumpFiltrationCartesian coordinate systemWeb 2.0Associative propertyForm (programming)Revision controlTerm (mathematics)System administratorFilter <Stochastik>Functional (mathematics)Rule of inferenceInterface (computing)Server (computing)Information securityDescriptive statisticsSet (mathematics)Extension (kinesiology)Category of beingFlow separationService (economics)Authoring systemWordGroup actionNumberObject (grammar)Vector spaceGeneric programmingPresentation of a groupService-oriented architectureAreaRepository (publishing)Mathematical optimizationImplementationEvent horizonContent (media)WeightField (computer science)Machine visionUniverse (mathematics)Lecture/Conference
20:13
12 (number)Information securityExtension (kinesiology)Service-oriented architectureLogicGroup actionMehrplatzsystemDefault (computer science)Multiplication signMotion captureDifferent (Kate Ryan album)Interface (computing)NumberServer (computing)CompilerDistanceCASE <Informatik>Staff (military)Standard deviationService (economics)Filter <Stochastik>MassPhysical systemMatching (graph theory)Operator (mathematics)Hand fanMixed realityAddress spaceLimit (category theory)Attribute grammarLoginDatabase transactionLecture/Conference
23:19
Rule of inferenceWeb pageDrop (liquid)SummierbarkeitForceLimit (category theory)Right angleDatabaseVariety (linguistics)Different (Kate Ryan album)Group actionRevision controlInterface (computing)Configuration spaceUser interfaceRule of inferenceGame controllerStandard deviationPhysical systemLecture/Conference
24:26
3 (number)Multiplication signVector spaceAuditory maskingMereologyInformation securityResultantTerm (mathematics)Rule of inferenceFiltrationConstraint (mathematics)Sound effectRaster graphicsStructural loadVideo gameSet (mathematics)DialectFilter <Stochastik>Interactive televisionField (computer science)AreaForm (programming)FrequencyStandard deviationInterface (computing)Beta functionLecture/Conference
27:34
Infinite conjugacy class propertyComputer animation
Transcript: English(auto-generated)
00:22
So, good morning and welcome. First off, we have Mauro Partolomelli to talk about mastering GeoServer, security with GeoServer and GeoFence, and without further ado, we'll let him get started. Thank you very much. So, today we are going to talk about security. The first thing
00:44
I would like to say is that security is not fun. Security is hard. It's very hard to achieve. We are going to look at how GeoServer tries to handle security and all the available features that you can use to make your infrastructure
01:02
secure when GeoServer is involved. So, security is hard and we at GeoSolution work to make it simpler for our customers, especially when GeoServer and one of our
01:21
products is involved in creating an application infrastructure. GeoSolutions is my company in the sense that I work for GeoSolutions. I'm not the owner, but it was founded in 2006 and is involved in GeoServer developing in
01:41
every aspect, including security stuff. Okay, I will give you an overview of what security is in general and how this is implemented inside the GeoServer infrastructure. Basically, when you talk about security, you have to talk about two different aspects. The first one is
02:03
how you get identity of your users and how you can trust this identity to make sure that people that access your system or services that access your system are trusted to do what they are allowed to do and they cannot do what
02:22
they are not allowed to do, basically. So, this is what we call authentication, getting identity and trusting that identity. The second very important aspect is how we handle authorization, so how we access our resources and how
02:42
we basically deny access to resources that are not allowed to be accessed by some particular users. Inside GeoServer, these two different aspects are both handled by different subsystems of the generic GeoServer security
03:02
infrastructure. You can see here a basic schema of the libraries and components that are involved in security. The main block is Spring security. GeoServer is fully based on the Spring framework in most of its
03:24
infrastructure and also for security, we use a module of Spring that is called Spring security, so each of the components of GeoServer handling security is basically an extension of the standard Spring security components.
03:42
Then, other components are involved, like the dispatcher, for example, that is the main entry point for every request that comes to GeoServer. Every request comes to the dispatcher and then the dispatcher decides what to do with that request, so for sure, security is really involved when we need to decide, for
04:03
example, if a request is allowed or not for a particular user. Then we have two different elements that are services and catalog that are the two different types of resources that we can handle inside GeoServer that we can use to decide permissions, so authorization rules for resources inside GeoServer.
04:27
Services are, for example, standard OGC services like WMS, WFS, and so on, but also other kind of services like the REST API that GeoServer has to handle administration stuff. The catalog is about accessing the real data that the
04:46
GeoServer publishes, like workspaces, layers, and so on, and this aspect has a authorization. So authentication and authorization are the two different
05:02
aspects that we need to handle when we want to secure our system, and how GeoServer handles both of them, we will see some basic concepts that I will try to explain. The first one that is related to authentication are filter
05:23
chains and authentication providers, you can see on the right, on the top right of the schema, and then the secure catalog on the bottom, on the bottom right. Secure catalog is simply a wrapper to the catalog that allows to
05:42
implement security rules on top of the standard catalog, so every request to the catalog is wrapped so that security rules can be applied. Another element that is very important that is called the resource access manager is the component, the pluggable component, because we will see that you can have
06:03
different implementations inside your server of the same concept like the resource access manager. Resource access manager is the component that handles the security policy, so all the rules that permit or deny access to your resources. Okay, now we will see a little bit more in detail these
06:27
concepts. For example, what are filter chains? Basically, when you send a request to GeoServer, this request has to be recognized by its type, let's say,
06:40
and can, depending on the type, can be handled by a different set of security rules. Each of them is called the chain of filters. Why? Because basically what you do, which is kind of request, is to apply a set of filters that are simple pieces of code that take the request and apply certain actions to the
07:03
request itself, and then pass it to the following filter. So you have a chain of filters that are all applied for every request. We have different chains because we probably want to apply different security rules to different kinds of requests. For example, we want to handle requests to the administration
07:24
interface of GeoServer differently from requests that are OGG services calls. For example, we want to use a classic form login for the administration interface, while for accessing WMS service we want to use a
07:41
different authentication mechanism, for example, basic authentication or certificates or any other kind of authentication system that you can think of. So we have different chains for different requests. Each chain is a sequence of filters that are applied one after the other to the request to
08:01
decide authentication stuff. So what is the user? Who is the user that is accessing the system in this particular time with this request? Okay, here you can see a sample screenshot of what I was talking about. These are samples of
08:23
filter that you can use inside your server. Each one is dedicated to a particular aspect of the authentication phase. For example, you have one filter that handles a session, so if you authenticate once and you have a session filter, you don't need to authenticate for every request to the
08:40
web administration interface, for example. You have other filters for remember B, so to handle cookies or for anonymous access and so on. There are many, many, many filters that you can use to handle your authentication. Here is a quick list of the filters that you have by default. Obviously, since
09:05
your server is completely pluggable, you can add more filters just developing a small class, implementing an interface, adding it to the set of libraries of your server, and have more filters that you can use inside your infrastructure. In addition to filters that are basically dedicated to
09:28
fetching credential from the users or similar stuff, you have authentication providers. So basically, authentication is divided into phases. First, you get the
09:40
credential from your users using various methods like a form, like basic authentication, or an external system. You have many ways to get credentials that you can configure, obviously. You can decide which method of authentication you want to configure in the system. Then, you need a way
10:01
to trust the credentials that the user has given to be sure that they are associated to an existing user and which permissions, which rules need to be applied to that particular user. This second phase is handled by authentication providers. There are several examples of authentication providers available in your
10:23
server. For example, you can use an LDAP repository to match credentials with an existing user in the repository or a database, any kind of storage system basically that you can use to match the credentials with the trusted
10:40
ones. In addition to that, your server has another set of providers that are specifically aimed at associating users with the roles in the system because you can categorize all of your users so that they are
11:02
divided in groups and roles. And roles are quite important because in the core security system, it's the only entity you can associate permission with. So we will see in a moment that to associate authorization to your users,
11:22
you need to specify with permission each entity as, but you cannot do it user by user in the core system. We will see that there are extensions that allow you to associate permission also to the single user, but in the core system, you can only do that with roles. So you need to create roles, you need to
11:45
associate the rules to users, and then you can bind permissions to the specific roles that exist. Since roles are important, there is a specific component called role providers that can bind, let's say, roles to users. And also
12:05
for these, you can decide which kind of storage, which kind of service you want to use to do this particular task. You can use LDAP, as we have seen also for users. You can use databases. There are many options and it's
12:21
extensible, so you can create your own role provider if you need one. Also, GeoServer includes some extensions. They are not part of the standard installation, but there are several extensions that you can install. In addition, some of them are dedicated to security. For example, there is an
12:43
implementation of the CAS single signal system. Another one that is called AuthKey is, we use it in many cases inside GeoSolutions because it's a generic implementation of a token-based authentication, so you can
13:03
use it whenever you have in your infrastructure something generating a token for authentication that probably an expiring token or something like that that you can use to share authentication between different systems. AuthKey is meant to handle this kind of use case. Okay, let's change our
13:30
topic from authentication to authorization. What is authorization about? It's about giving users and roles permission to do actions or
13:46
resources, basically. So when a user tries to do a particular action on a particular resource, we need to decide if this is a load or not and if it is a load, if limits apply to how we access the resource. For example,
14:05
let's say that we want to do a request in WMS to get a particular layer, so a map for a particular layer, and we want to decide how the user
14:23
can see this particular layer. We can decide that he cannot see at all, so it's completely denied, or it can access it fully, or it can access it but in limited way. For example, it could access only part of this
14:41
particular layer, only a particular region of the word, for example, or only if we make another example with WFS, we can decide that it can access only some attributes of a particular feature type, and so on. So we have basically three use cases. We can decide to deny access, to allow it, or to allow it with
15:02
limitations, with constraints. The authorization system permits to configure all these aspects using a component that is called the resource access manager. The resource access manager is really an interface that can be implemented by
15:21
several modules. There is a core module that implements a basic, very simple system. In the basic system you can only associate rules, permission rules to rules, not directly to users or groups, etc. And you can basically decide the permissions for workspace and layer, but only allow and
15:46
deny. You cannot specify limits, for example. The same you can do for services, so you can decide if you can access the WMS or WFS service or not. Then there are extensions to this basic subsystem that you can use to
16:04
replace the basic authorization system. One of them is geofence, a security extension, a community module, for GeoServer that you can use. It's fully
16:22
configurable as its own interface, exists in two different forms. One is a standalone application that is external to GeoServer that you can use to configure and to implement the rules, basically, and one that is directly integrated inside GeoServer. It is simpler to use. It uses the same
16:41
web administration interface. It is not currently all the functionality of the standalone ones, but we are going to make them equivalent in the long term. And another option, that is the one that I would like to suggest you for most use cases, is that probably neither the basic subsystem or
17:04
a generic system like geofence can be applied to your own situation. You know these cases where you probably already have a security infrastructure in your company and you just want to integrate your
17:21
server in the existing infrastructure. What we usually do and what we suggest is to implement your own version of the resource address manager that can apply in a simple way your existing rules that are probably not as generic as geofence allows you to do, but are very specific to
17:40
use cases. And if you already have something that already describes these rules, for example, in a database or in an external repository, the simplest way to implement your own authorization system is to write your own version of the resource address manager interface. It's
18:00
quite simple because it is a simple interface where you simply decide for each couple of user and all the existing categories like groups and roles and resource. So if you have a couple user and resource, you simply have to decide how the user can access that particular
18:21
resource. So you have several methods in resource address manager, each one dedicated to a particular set of resource, and you just have to return a description of the permission for the user, like the user is allowed to access the resource or the user is denied. And if the user
18:42
is allowed, you can describe your limits. The limits usually, let's see if I have an example of that. Probably not. Basically, what you can describe is through an object called access limits are filters to
19:02
the data. For example, if you have vector data that you want to filter based on the user that is accessing it, you can express a filter, a simple SQL filter that you usually send to your server to filter your data. In your application, you can, let's
19:23
say, you can set it as a limit directly in your server, in your resource address manager, in your server so that it is applied automatically to have a request for that particular user. Or you can also apply special filters so each user can see a particular
19:41
region of the word. And you can also apply limits to the number of attributes that are visible to the particular attributes. You can also decide if something is readable or writeable. You have many options that you can implement in your resource address manager. Basically, that's it. So I think it's time for
20:03
questions, if you have any. Thank you for the speech. I'm interested to know how can we extend GeoServer in WFS
20:21
services so that a user that actually edits a feature so that we can also log the user account that has actually edited this feature for logging. Yes, if you understand my question. Yes. I don't remember the name, but there are some
20:40
extension points that you can implement to catch a particular request and implement your own logic to, let's say, do something like logging or similar stuff. So you can just capture every request and do what you want with it. We
21:03
usually do it, for example, to handle some security stuff that cannot be handled by the standard resource address manager, but I think logging is another use case. Transaction listener, that's the interface. Transaction listener, that's the interface that you can
21:23
implement. You just implement the interface, compile the module and install it. Other questions? Thank you. What are the main differences between the default security system
21:43
and geofans? Basically, the basic security system has many limits in what you can configure. As I said, you can only associate permission to roles, not directly to a single user or a single group. While with the geofans or any
22:04
customers such as managers, you can also do that. And you also cannot do something like mix and match services and resources-based permission. So you cannot say this layer can be accessed via WMS, but not via WFS. You
22:21
have permissions only for services and layers, but they are not mixable. They cannot be combined. While with geofans, you can do something like that. And also with the basic system, you cannot apply filters or limit the number of attributes. You can only say allow or deny. You
22:42
do not have ways to specify limits inside for this particular layer, for example. We started trying out with geofence, and we found out that you can run
23:04
geofence next to GeoServer, or you can have geofence somehow included in GeoServer. So what are the main differences? What do we have to look at? What is the recommended way? Okay, I should have a quick slide on what. Okay.
23:26
Currently, the directly integrated version has some limitations in what you can configure, basically in the configuration interface. The probes or the real engine is
23:41
basically the same. Another difference is that the directly integrated version directly uses the user system of GeoServer instead of implementing its own, because the standalone version has its own database for users and
24:00
groups, while the directly integrated uses standard GeoServer users. And the other limitation you will see there in this slide, basically you cannot edit limits, you cannot control writes at the rule level, and some user
24:21
interface stuff, basically. Okay, I think we have time for one more question. In geofence, you can specify a spatial filter. And you can
24:44
specify that on a layer, but also per user, I think. And then the actual filter is in an intersection between those. So when you do a request, then it does an intersection
25:02
between the two spatial filters and So you mean if you have a spatial filter directly in the filter, in the request, and another one in the security system? No, as far as I know, in geofence, you can set up a rule, well, a spatial constraint for the layer, but
25:21
then also a user himself can have, can be constrained to a certain spatial area, and then the effect of... No, I think so. You can specify rules that contains spatial filters, but then the rules also specify the user. Okay, but okay, so in terms of the rule, then the rule can be
25:41
a spatial, spatial rule, based on the layer or on the, on the user. So then is the resulting rule an intersection between those? And then also, second part of the question, if a feature is, is bigger than that spatial part of the rule,
26:06
what, what is the right way to only return a result for, for the allowed area, even though the feature itself maybe spans a bigger area? Okay, probably. I didn't understand exactly the
26:22
question, but you probably mean if it's clipped by the, okay, for vector data? I don't think so. I think it's a simple intersection to select the data. So if it's intersected, it will be returned, but it will not be clipped in the selected region. That happens for raster
26:43
layers where the spatial filter is really a mask on the raster, but it's...
27:23
Okay, that's all the time we have. Thank you for a great talk, Mauro. We'll get switched out for our speakers. Thank you.