[mapguide-users] You should probably read this (if you use Maestro)
jumpinjackie at gmail.com
Tue Jul 10 07:58:48 PDT 2012
Long story short: There are two problems, both inter-related.
1. Maestro creates feature sources with plaintext credentials (for
applicable FDO providers).
2. Maestro does not correctly package feature sources with encrypted
security credentials (ie. the MG_USER_CREDENTIALS resource data item)
For the first problem, Maestro creates plaintext credentials instead of
putting in %MG_USERNAME% and %MG_PASSWORD%. For the longest time I never
knew why the original and current Maestro does this, but now I do. It is
because it does not have access to the same credential encryption logic in
the MapGuide Server that allows it to create the encrypted
MG_USER_CREDENTIALS resource data item.
For the second problem, Maestro doesn't properly package feature sources
with encrypted security credentials because Maestro issues a whole series of
GETRESOURCE and GETRESOURCEDATA calls to get the required resources for
packaging. The problem in particular is that a GETRESOURCEDATA call on a
MG_USER_CREDENTIALS item will always return the unencrypted username. This
is what Maestro puts into the final package.
Whereas with the official packaging method, it probably bypasses this so
that it can package the encrypted MG_USER_CREDENTIALS directly. If you try
to call SETRESOURCEDATA (which Maestro will do) on MG_USER_CREDENTIALS with
un-encrypted content, the MapGuide Server will throw a MgDecryptionException
back at your face because it is expected the same encrypted
MG_USER_CREDENTIALS that the official packaging method would've put in.
You would think that in the 4-5 years of Maestro's existence that this
problem would've been known about but nope, I only know about it just now.
So the crux of the problem is that Maestro does not know how to encrypt
MG_USER_CREDENTIALS. Does this affect you? If your data is all flat files
and raster, you're fine. If your data is in an rdbms or anything where
username/password credentials are required, Maestro will have created
plaintext credentials for your feature sources, whose content can be
accessed by the Anonymous MapGuide user! You cannot deny read access this
feature source in the site repository for Anonymous user as all
rendering/stylization that uses this feature source will then fail for the
If you have a license of Studio, the solution is easy: Use it to re-secure
your feature sources. If you don't (and I gather that's the case for the
majority of this list), then we have problems if we want secured feature
sources, because it is currently not possible to do with Maestro.
How can we fix this?
1. Replicate MgCryptographyUtil verbatim in .net? How could we even verify
the .net implementation produces the exact encrypted content as the C++
version? Even if we had a 100% working .net implementation of this, we still
have the following problem.
2. How can we access the raw encrypted MG_USER_CREDENTIALS with the
existing public APIs? We probably can't, which is a problem because we need
this intact in order to create a working package client-side. The official
packager knows how to do this, but that is not publicly accessible to
3. SWIG/C-interface wrapper into the existing MgCryptographyUtil/official
packaging functionality. We do this and we kill one of the main benefits of
Maestro: platform portability. Such a move is inherently platform-specific.
Retaining the same unmanaged code + glue libraries on non-windows platforms
is a very tall order!
So allow me to apologise if you've been creating un-secured feature sources
all this time, but this is a true show-stopper that I'm gonna need you (the
mapguide-user community) to help me on this one. I cannot in good faith,
release Maestro 5.0 or the next 4.0.x maintenance release until this issue
There is a ticket for this too for those who want to follow/discuss:
View this message in context: http://osgeo-org.1560.n6.nabble.com/You-should-probably-read-this-if-you-use-Maestro-tp4987345.html
Sent from the MapGuide Users mailing list archive at Nabble.com.
More information about the mapguide-users