Dear all,
I would like to share a GSIP proposing small UI improvements and OIDC claim mapping.
Comments welcome—I’ll call for a vote after brief discussion.
Best,
Alessio Fabiani.
Hi Alessio,
sounds useful, +1.
+1
This is some random text to convince discord that I am a real person not a spammer.
Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.
Hi Alessio,
the proposal looks good in general, but I’m not understanding some bits.
The ODIC provider is an authentication filter. It’s true that it can add extra information in the Authentication object, and it makes sense that it can be used in the login part of the pages.
So far so good.
But then I’m lost with the portion about the user tables, e.g. this is the current GUI:
This GUI is populated from the UserGroupService, e.g., JDBC, XML, LDAP, and so on. When you show the new screenshot with the extra columns… how do we get there? Is the JDBC service configured differently, to hold the new properties?
In the user group services I believe you could get any extra property, where are the properties to be shown in this table configured?
Cheers
Andrea
Hello Andrea,
I’d expect the properties to be stored as part of the GeoServerUser model.
In the case we are going to use a writable UserGroupService, the filter will try to update them along with the associated authorities. Otherwise GeoServer will simply rely on what the UserGroupService can provide.
My idea was to try to map those properties with some fixed/hardoced keys in GeoServer.
+0
I’ve updated GSIP-235 to make it simpler and strictly read-only. Instead of doing any mapping inside authentication filters, I now treat a few common profile fields—first name, last name, preferred username, and email—as optional properties provided by the active User Group Service. If those properties are present, the UI can show them in the Users list and use them to render the “Logged in as …” header; if they’re not, nothing changes.
Security filters don’t write anything to the store. At login they can oprionally (not part if this GSIP) inherit these properties, alongside roles, so the UI can display friendlier names without altering usernames or permissions. I also added privacy-minded email options: you can hide the column, show only the domain or a masked value, or show the full address with click-to-reveal.
Everything is off by default, fully backward compatible, and works with the existing XML/JDBC user/group stores. The aim is to make the admin experience clearer and safer when profile information is available—without introducing new synchronization or storage logic in GeoServer.
Please send me your comments or cast your votes.
Thanks,
Alessio.
I’ve updated GSIP-235 to make it simpler and strictly read-only. Instead of doing any mapping inside authentication filters, I now treat a few common profile fields—first name, last name, preferred username, and email—as optional properties provided by the active User Group Service. If those properties are present, the UI can show them in the Users list and use them to render the “Logged in as …” header; if they’re not, nothing changes.
Security filters don’t write anything to the store. At login they can optionally (not part of this GSIP) inherit these properties, alongside roles, so the UI can display friendlier names without altering usernames or permissions. I also added privacy-minded email options: you can hide the column, show only the domain or a masked value, or show the full address with click-to-reveal.
Everything is off by default, fully backward compatible, and works with the existing XML/JDBC user/group stores. The aim is to make the admin experience clearer and safer when profile information is available—without introducing new synchronization or storage logic in GeoServer.
Please send me your comments or cast your votes.
Thanks,
Alessio.
+1 I think this will be useful.
Any feedback I have is out of scope; like it would be good to have the xml file based implementation support these new fields also.
Hello everyone,
I’ve taken the work from @afabiani analysis and implemented it.
This is the PR with the implementation: [GEOS-11982] Added user profile properties in UI. by axl8713 · Pull Request #8926 · geoserver/geoserver · GitHub
Thanks in advance to anyone who can have a look at it!
Cheers,
– Alessandro