Mastering Security with GeoServer, GeoFence, and OpenID
This is a modal window.
Das Video konnte nicht geladen werden, da entweder ein Server- oder Netzwerkfehler auftrat oder das Format nicht unterstützt wird.
Formale Metadaten
| Titel |
| |
| Serientitel | ||
| Anzahl der Teile | 266 | |
| Autor | ||
| Lizenz | CC-Namensnennung 3.0 Deutschland: Sie dürfen das Werk bzw. den Inhalt zu jedem legalen Zweck nutzen, verändern und in unveränderter oder veränderter Form vervielfältigen, verbreiten und öffentlich zugänglich machen, sofern Sie den Namen des Autors/Rechteinhabers in der von ihm festgelegten Weise nennen. | |
| Identifikatoren | 10.5446/66474 (DOI) | |
| Herausgeber | ||
| Erscheinungsjahr | ||
| Sprache |
Inhaltliche Metadaten
| Fachgebiet | ||
| Genre | ||
| Abstract |
|
FOSS4G Prizren Kosovo 2023126 / 266
10
17
23
44
45
46
47
48
49
50
52
53
80
84
85
91
110
116
129
148
164
167
169
173
174
181
182
183
186
187
199
202
204
206
209
215
241
248
265
00:00
SoftwareQuellcodeCoxeter-GruppeDatensatzXML
00:33
SoftwareQuellcodeMenütechnikOffene MengeSoftwareentwicklerOpen SourceServiceorientierte ArchitekturWellenpaketUnternehmensarchitekturProjektive EbeneServerZahlenbereichComputersicherheitComputeranimation
01:01
W3C-StandardQuellcodeSoftwareGruppenoperationZahlzeichenMotiv <Mathematik>Serviceorientierte ArchitekturLastDezimalzahlDatenbankSpieltheoriePasswortComputersicherheitInformationServerInformationsspeicherungMaßerweiterungPunktAuthentifikationImplementierungQuaderAutorisierungDatenbankBitDifferenteGruppenoperationKonfigurationsraumMechanismus-Design-TheorieVarietät <Mathematik>Digitales ZertifikatZentralisatorVerzeichnisdienstKundendatenbankGamecontrollerMereologieIntegralBenutzerbeteiligungServiceorientierte ArchitekturProgrammbibliothekTeilmengeDatenverwaltungSystemverwaltungTermInterface <Schaltung>ChiffrierungZahlenbereichSchnittmengeRelationale DatenbankBenutzeroberflächeService providerFormation <Mathematik>DefaultDienst <Informatik>Quelle <Physik>AppletComputeranimationXML
03:43
QuellcodeSoftwareFormation <Mathematik>AuthentifikationDivergente ReiheBildschirmmaskeDifferenteCookie <Internet>Kette <Mathematik>PasswortServiceorientierte ArchitekturFilter <Stochastik>Service providerProgrammierumgebungDigitales ZertifikatServerProxy ServerMechanismus-Design-TheorieSchnittmengeBenutzeroberflächeE-MailUnternehmensarchitekturSchlüsselverwaltungComputeranimation
05:19
SoftwareQuellcodeDigitalfilterAuthentifikationÜbersetzer <Informatik>DefaultKette <Mathematik>OrtsoperatorAbfrageZeichenketteKonfigurationsraumMatchingKonfiguration <Informatik>Schreib-Lese-KopfE-MailTranslation <Mathematik>AusnahmebehandlungDatentypHIP <Kommunikationsprotokoll>Ganze FunktionService providerDatenbankMechatronikAuthentifikationCASE <Informatik>Selbst organisierendes SystemKonfigurationsraumSchnittmengeInformationCachingCookie <Internet>DefaultBrowserOrdnung <Mathematik>AutorisierungProxy ServerREST <Informatik>Filter <Stochastik>Mechanismus-Design-TheorieKette <Mathematik>Elektronische PublikationPasswortServerBenutzerbeteiligungE-MailHash-AlgorithmusService providerRelationale DatenbankBenutzeroberflächeTechnische ZeichnungComputeranimation
07:34
Suite <Programmpaket>AuthentifikationGruppenoperationFilter <Stochastik>MereologiePunktComputeranimation
08:01
QuellcodeAuthentifikationAutorisierungMechanismus-Design-TheorieMaßerweiterungDefaultSystemverwaltungInhalt <Mathematik>SchlussregelImplementierungServerPunktKundendatenbankNichtlinearer OperatorServiceorientierte ArchitekturPlug inUnternehmensarchitekturIntegral
08:58
SchlussregelServiceorientierte ArchitekturTransaktionComputersicherheitSoftwareQuellcodeKonfigurationsraumLokales MinimumATMGruppenkeimLesen <Datenverarbeitung>VerkehrsinformationOrdnung <Mathematik>ServerSystemverwaltungElementargeometrieTransaktionDefaultGruppenoperationDienst <Informatik>ComputersicherheitAutorisierungLesen <Datenverarbeitung>ComputeranimationXML
10:03
Online-KatalogATMQuellcodeAuthentifikationAutorisierungDefaultComputersicherheitRechter WinkelZweiImplementierungVerschlingungServerDienst <Informatik>XML
11:34
KonfigurationsraumLesen <Datenverarbeitung>GruppenkeimMereologieSystemverwaltungEinfache GenauigkeitATMInformationsspeicherungComputersicherheitSchlussregelDefaultServer
12:14
QuellcodeSoftwareSpannweite <Stochastik>Tablet PCSchlussregelCASE <Informatik>Mailing-ListeTabelleBitDatenbankDienst <Informatik>Inverser LimesFirewallSchlussregelOrdnung <Mathematik>AutorisierungDefaultServiceorientierte ArchitekturRelationale DatenbankMatchingXMLComputeranimation
13:30
SchlussregelInformationVektorpotenzialVorlesung/Konferenz
13:56
Lesen <Datenverarbeitung>DigitalfilterAbelsche KategorieQuellcodeSoftwareSchreiben <Datenverarbeitung>FlächeninhaltInverser LimesMAPPolygonDatenfeldSchlussregelFilter <Stochastik>BitLesen <Datenverarbeitung>KonfigurationsraumKategorie <Mathematik>XML
15:18
DigitalfilterFlächeninhaltATMOnline-KatalogSoftwareQuellcodeEmulationSuite <Programmpaket>SchlussregelKonfigurationsraumPolygonResultanteElementargeometrieCASE <Informatik>Nichtlinearer OperatorFlächeninhaltInverser LimesSchlussregelSystemverwaltungGamecontrollerKonfiguration <Informatik>Vorlesung/KonferenzComputeranimationXML
16:08
UnternehmensarchitekturAutorisierungAuthentifikationRuhmasseMathematische LogikKlassische PhysikTrennschärfe <Statistik>Plug inAnpassung <Mathematik>ProgrammierumgebungQuellcodeKundendatenbankUnternehmensarchitekturInterface <Schaltung>Mechanismus-Design-TheorieImplementierungDefaultAuthentifikationAttributierte GrammatikFächer <Mathematik>Computeranimation
16:53
AuthentifikationExogene VariableServiceorientierte ArchitekturFreier ParameterURLParametersystemQuellcodeSoftwareOffene MengeDigitalfilterPlug inSchlüsselverwaltungEinfach zusammenhängender RaumAuthentifikationClientEndliche ModelltheorieOffene MengeServerErneuerungstheorieMechanismus-Design-TheorieService providerMethodenbankURLSpieltheorieXML
17:31
QuellcodeSoftwareAuthentifikationToken-RingServerService providerSpieltheorieCASE <Informatik>KonfigurationsraumSchlüsselverwaltungOffene MengeMechanismus-Design-TheorieModallogik
Transkript: Englisch(automatisch erzeugt)
00:08
Hello everyone, my name is Andrea Aime, not Nuno Oliveira. Nuno was supposed to be here to deliver this presentation but couldn't come and then I got to deliver the talk on his behalf.
00:25
Some things I know very well, others not so much, so I'll try to be as thorough as possible, but yeah, I'm just a messenger. So I work for GeoSolutions, a company based in Italy in the United States. We are providing support and services around a number of open source projects, including GeoServer, which we are core developers.
00:49
And we provide, as I said, enterprise support, deployment, customization, training and so on. As a company we believe in open source, in open services and that's why we participate to this conference.
01:01
So, first of all, quick security overview in GeoServer. The security subsystem in GeoServer is based on Spring Security, which is a well established Java library that provides a number of security integrations, which makes GeoServer security extensible and pluggable by design.
01:23
It can be configured via the web administration interface or the REST API, or both, and allows us to secure data services and administration. In GeoServer we have two different implementations for authentication and authorization.
01:42
They are both supported by vanilla GeoServer, as I said they are pluggable, so what you find in vanilla GeoServer is a subset of the whole set of possibilities. In terms of terminology we have the usual suspects, user groups, roles, data and services. In terms of authentication we have support for encryption and we have an extension mechanism that offers a variety of authentication mechanisms.
02:08
Think HTTP basic, HTTP digest, certificates, central authentication service, name your own or write your own if you want, because we have extension points.
02:21
The authorization is role based no matter what flavor of authorization subsystem you're going to choose, and I'm going to get into detail about it in a little bit. So, user groups and roles, what's the relationship? Again, it's the usual. Users can exist on their own or they can be part of a group.
02:42
Roles can exist on their own, but they are typically attached to either directly users or groups for better control of this classification. And by default they are all stored inside the GeoServer directory if you pick the default user management which stores the information as XML.
03:00
But you can choose other data management facilities like a relational database, like an LDAP server and more. Again, we have an extension point for that. Extension points allow us to integrate with other providers like user group services and role services, which as I said could be by default databases, LDAP, XML or pick your own, write your own.
03:27
This is a little bit of the user interface to configure user groups and role and to create a new user group service, for example. So that's what you get out of the box, XML, JDBC, LDAP. But as I said, you can write your own, you can contribute more.
03:44
Let's talk about authentication. Authentication can be complicated in enterprise environments. Each one picks their own. So some environments go for the most basic, HTTP basic authentication, please on top of HTTPS, otherwise it's dangerously fragile.
04:05
But you can use other things like auth, like key clock, like certificates. Or even just provide the user name as an HTTP header because you provided a proxy, an authentication proxy, in front
04:23
of GeoServer, which does the authentication whatever way you want and GeoServer then just trusts your header provided by the proxy. It's complicated also because you might want to have different authentication mechanisms depending on the endpoint that you're hitting.
04:40
So for the user interface, we typically have a different set of endpoints compared to the OGC services. And for the REST API, you might want to have something else already. These are called authentication chains. We attach them to an endpoint and say, this is the series of authentication filters that you have to try. And they can say something like, okay, let's try form authentication.
05:02
Did someone send me a username and a password in a form? No. Okay. Do I have a cookie? No. Okay. Do I have a basic authentication? No. Then the user is anonymous. Something like that. This is the chain. And the three methods that I just enumerated are called authentication providers.
05:21
So, sorry, they are called authentication filters. The filters extract whatever authentication information is in the request and then they try to use it to actually perform authentication. So, for example, if I have username and password, it's extracted by the filter, but then it has to be verified. And we can verify it against an LDAP server, against a relational database, against an actual password or salted hashes, for example.
05:49
So different mechanisms to do this. And all of this is configurable to match the particular use case of your organization. So this is one example of setting up the authentication chain.
06:01
So we have a chain for the web interface, but we have a chain for the REST interface and another for the GWAP cache configuration REST API. And the default one, which typically handles OGC requests. Filter chain, as I said, configuration of the set of steps that you will try to use in order to authenticate.
06:27
This is one example of trying the HTTP header that the proxy might have provided or use HTTP basic. Or if nothing else works, then assume that the user is anonymous.
06:41
And then it's going to be the authorization that will decide what to do if the user is anonymous. Deny access, allow access to a limited resource set or whatever. So these are possible authentication filters and you can configure more, see add new. They are also pluggable.
07:01
So here we have the usual suspects which are built into GeoServer, but you can have more. This remember me thing is a cookie that is set browser side to remember who you were to avoid having to reauthenticate over and over and over.
07:20
Authentication providers, again by default. The default one is XML based stored user name and sorted passwords in an XML file. But I could have JDBC, but I could have holdup or roll your own. So this is more or less an idea about authentication. So at this point, the request has come in.
07:43
We have run the filters for that particular endpoint. We have figured out who you are. Then we have to decide what you can do based on who you are, based on the roles that are attached. Either directly to your user or to the group that you are part of.
08:02
Authorization, sorry, authorization. There are again multiple mechanisms here because there is an extension point called the resource access manager. There is a default implementation that you find in vanilla GeoServer. There is a plugin that's called GeoFence that does more sophisticated rules or you can write your own.
08:20
A typical enterprise integration is writing a custom authorization mechanism for that particular customer for their particular needs. So built in, we can do authorization on services and operation, on workspace administration and on data as layers.
08:42
So we don't authorize the content of the layer, we just authorize the layer. The built in authorization mechanism is simple. You can either access a layer or you cannot. You can either write on a layer or you cannot. Those are the two things that you can say. So this is security authorization where you say, oh okay, you need to have the read role in order to access the WFS service.
09:10
But you have to be an administrator to do WFS transaction. This is the default configuration to make sure that you know when you install a vanilla GeoServer, nobody can go and alter your data just because you forgot to lock it down.
09:24
It's locked down by default. And again, we pick the service, eventually the method and say, okay, you need to have these roles in order to do this action. For data, we have a similar situation.
09:43
Let's see if I have a nice screenshot, yeah? So we say for the reports workspace and any layer inside of it, you have to be either an administrator or have the reports read role in order to access that workspace. If you don't, then you will not be able to access it.
10:04
But what happens when you cannot access it? Well, we have three different policies. Two are simple to understand. One is weird, but it's what paid for the initial implementation of the authorization subsystem. So hide is the default policy.
10:22
If you are not authorized, you don't see it. It's high security policy. If you are not supposed to access it, it does not exist. GeoServer will tell you, I don't know what this workspace or this layer is. They are there. It will pretend it's not there.
10:40
Challenge is instead the opposite. It will not pretend it's not there. It's gonna tell you, hey, you don't have rights to access this. Please authenticate yourself or elevate your authentication with another user or something like that. Do something about it. First approach, useful when you are dealing with high security system.
11:01
Second approach, useful when you are selling something. Oh, you did not pay for the service. Please, give me some money. Next is the one that is weird in which the layers are actually hidden by default. So you will not see them in the preview, in the capabilities.
11:22
But if you actually try to access them because maybe somebody provided you a direct link to them, then GeoServer will say, hey, yeah, please authenticate yourself. It's there, but I need to know who you are. Okay, then we have administration security rules. By default, GeoServer is managed by a single big bad administrator that can do anything.
11:46
But you can also authorize smaller administrators that can administer only a single workspace. So it's a way to delegate part of the administration to other people that can add extra stores and layers and styles in one particular workspace
12:03
without touching or maybe even seeing the other workspaces. And so we have an access mode called admin that can be activated on workspaces. If this is not enough, and in many cases it is not enough, you can install GeoFence.
12:23
GeoFence is an advanced authorization engine for GeoServer that replaces the default built-in engine and can store rules either on H2, which is the default database, or PostgreSQL, or even something else,
12:40
some other relational database, I mean. And it has this ability to combine several aspects into a single rule. So you can write a rule saying, yes, if the service is this and the user is that and the request is this, so you can mix and match both data and services in the same rule.
13:02
Then you say, okay, this user has access or it doesn't have access or it has access with limitations. And the limitations are the actual interesting bit, in my opinion, of GeoFence. In particular, well, the list of rules is reminiscent of IP tables
13:23
if you ever configure the firewall with it. So you have rules that are evaluated in order until one matches. We have allow rules which enable access to a particular layer, but with potential restrictions.
13:44
In particular, you can control which styles a particular user can see. So maybe you have certain styles that expose a little too much information and you want only certain users to be able to see them. But you can also apply SQL read and write filters so that you can control
14:03
what data in that layer a particular user category sees, which is a big departure from enabling and disabling just access to the whole layer. You can also write a spatial area filter by providing a polygon and say,
14:21
yeah, okay, this user can see data in this area and not the rest, or can write data in this area and not the rest. Think about a collection on the field. You have ten people going around. Each one has their own area of collection. You can enable each one to collect only in their area and don't do WFST anywhere else.
14:45
You can also control which attributes each user can see or write to. Finally, there are limit rules which allow to specify maybe at the workspace level general limitations about the data.
15:01
So instead of authorizing each and every single layer and say, all these layers have a geographic restriction, you say anything in this workspace has been limited to this area. So it's a way to have a bit more compact configuration.
15:24
So you provide an area by WKT and you can also control what kind of filtering you get. Let's see an example. United States and that polygon have two options, filter and clip. If I say clip, my data will be actually clipped to the polygon.
15:42
So it's not filtering. I'm actually modifying the geometries that I'm giving back to the user so that it sees nothing else but what inside the clip, or intersect in which case I will see anything that overlaps with my restricted area. Again, we can control administration rules
16:00
so that you can use geofence to limit administration access, just like with the built-in configuration. You can roll your own authentication mechanism. If you are not satisfied with what geofence and the built-in mechanisms do, you can write your own. The built-in and geofence are just two possible implementations
16:22
of the default of their source access manager interface. And with that implementation, you can do just about anything that geofence does. Select attributes, make them read-only, clip, filter, and whatnot, but with your own logic rather than the geofence one.
16:41
And yeah, this is a classic adaptation of GeoServer to an enterprise environment that does demanding requirements. So write two plug-ins which are yours. Community modules, authentication. We have one interesting module which is the key authentication module which is used by geofence to provide temporary access keys
17:03
for clients that cannot play the game of the high-hand authentication mechanism like OpenID Connect. So I give you a key that is in the URL, which is dangerous, but I make it valid for five minutes, for example, with eventual renewal.
17:21
We have support for OAuth 2 with the OpenID plug-in, and you configure all the connections to the OpenID server, and we have the same for key clock. Again, with all the necessary configuration. For key clock and OpenID, you can go beyond authentication
17:43
and also extract roles out of the tokens that the servers are returning. So they play two games in this case. They are an authentication mechanism, but they are also a role provider. And this is the end.