Hi Andrea
First, good idea, +1.
I never worked with GWC, so I hope my assumptions are correct here.
I think we need 3 methods
1) String encode(String clearTextValue);
Simply use ConfigurationPasswordEncryptionHelper.encode(..)
2) String decode(String encryptedValue);
Simply use ConfigurationPasswordEncryptionHelper.decode(..)
3) recodeAll
Recodes all passwords used by GWC. Be aware of the fact that even plain
text passwords
have a prefix. (Your assumptions about the prefix are correct). The password
mypassword
is stored as
plain:mypassword.
Maybe we need some migration code.
I think the method isResponsibleFor is not necessary, except GWC uses its
own encoders.
Let me know if I can assist further.
Christian
2013/6/14 Andrea Aime <[email protected]>
> Hi,
> as you might now the latest GWC embedded in GeoServer allows to keep the
> disk quota subsystem in a relational database.
> Part of the necessary information to connect to the db is username and
> password, which are stored using some GWC code based on XStream on disk.
>
> Now, GWC has no notion of password encryption (with some good reason I'd
> say, since they only way to configure the stand-alone version is manual xml
> file editing), however it is bad that in GeoServer the same file has
> cleartext passwords when the rest of the system stores them encrypted.
>
> So I was thinking, how about adding a PasswordEncoder interface to
> GeoWebCache that mimics, to a small extent, the GeoServer API?
>
> interface org.geowebcache.security.PasswordEncoder {
> // encrypt the value
> String encode(String clearTextValue);
>
> // check if the value has been encrypted by this encoder (GS uses
> prefixes to
> // guess that afaik)
> boolean isResponsibleFor(String encryptedValue);
>
> // decodes the value, throws an exception if not encrypted by this
> encoder
> String decode(String encryptedValue);
> }
>
> The idea is that in GWC we'd have one or more of these registered in the
> spring context, with a new config attribute marking one of them as the
> default one (and no password encoding happening if none is indicated) by
> bean name.
>
> In GeoServer we'd have this configuration be locked onto a specific
> password encoder that is a bridge to the GeoServer own password encoding
> subsystem, which would delegate to ConfigurationPasswordEncryptionHelper to
> do the actual work.
>
> Am I missing anything?
> More in general, suggestions?
>
> Cheers
> Andrea
>
> --
> ==
> Our support, Your Success! Visit http://opensdi.geo-solutions.it for more
> information.
> ==
>
> Ing. Andrea Aime
> @geowolf
> Technical Lead
>
> GeoSolutions S.A.S.
> Via Poggio alle Viti 1187
> 55054 Massarosa (LU)
> Italy
> phone: +39 0584 962313
> fax: +39 0584 1660272
> mob: +39 339 8844549
>
> http://www.geo-solutions.it
> http://twitter.com/geosolutions_it
>
> -------------------------------------------------------
>
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by Windows:
>
> Build for Windows Store.
>
> http://p.sf.net/sfu/windows-dev2dev
> _______________________________________________
> Geoserver-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/geoserver-devel
>
>
--
DI Christian Mueller MSc (GIS), MSc (IT-Security)
OSS Open Source Solutions GmbH
------------------------------------------------------------------------------
This SF.net email is sponsored by Windows:
Build for Windows Store.
http://p.sf.net/sfu/windows-dev2dev
_______________________________________________
Geoserver-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
