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 Anonymous user.
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 Maestro.
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 is solved.
Re: You should probably read this (if you use Maestro)
hi, looks like a big problem! since the first version came out mgopensource use, I always seemed an excellent job and a good development for the community. Maybe someone from Autodesk that can help? I as a user I can contribute little to troubleshoot code, but if I can install and test it in different environments and error checking. I hope you continue with this because I think an excellent job. jackie thanks for working with is an excellent MAESTRO tool that allowed the community to move forward with this project.
To me (in person) the first issue is not a big problem. We created our own map solution on top of the MapGuide server. In all our cases the MapGuide server is not exposed to the outside/internet in any way.
A solution to this problem could be to replace the way things are encrypted in the MapGuide server and implement this in Maestro as well. Kind of like “do it our own way”.
When using Maestro for the Autodesk servers the user should be warned then that the Autodesk cryptography is not supported (for various reasons) and that MGP files containing passwords cannot be imported in a safe way where the password is encrypted (If i understood the issue correct?).
I guess people could then use Studio to re-type/re-encrypt the password?
For the second issue with the Maestro packages containing unencrypted passwords. Could the solution be to just encrypt the entire MGP file with a user given password (should be an option I think). Only the person with the correct password could then open/read/import the MGP file.
Anyone else have any thoughts about this?
Re: You should probably read this (if you use Maestro)
Well it looks like half the problem (the show-stopping half) is solved at least, I've replicated MgCryptographyUtil in .net (the relevant parts that do the encryption) and it seems to produce encrypted credentials that the MapGuide Server is happy with, and my unit tests seem to check out.
The packaging problem still remains though. There just doesn't seem to be a way to request encrypted MG_USER_CREDENTIALS as-is through the public resource service APIs. All requests for this resource data item will always return the decrypted username.
The workaround for this is to have the Maestro packager auto-discard any MG_USER_CREDENTIALS during packaging (to prevent MgDecryptionExceptions when being loaded) and just require the user to re-supply the specific Feature Source credentials when loading this package somewhere else. That's an ugly workaround though. I really wish there was a better way, but I don't think there is a better way.