Because Maestro is 100% managed code, we do not have the ability to portably access the C++ logic that encrypts/decrypts the MG_USER_CREDENTIALS resource data element, which is used to store the encrypted username/password you specified when creating that Feature Source and is decrypted by the MapGuide Server when it needs to establish a connection to this feature source. This is mostly applicable to feature sources that have username and/or password as part of its connection parameters (ie. RDBMS providers)
This is the reason Maestro stores such credentials in plaintext as part of the feature source XML, which is understandably not secure. Until we have a solution for encrypting MG_USER_CREDENTIALS in pure managed code (ie. A verbatim .net version of MgCryptographyUtil with 100% matching behaviour), storage of credentials as part of the XML content in plaintext is the only thing Maestro can do if you ever want to be able to create such feature sources with it.
If you attempt to package such feature sources with Maestro, it will pack MG_USER_CREDENTIALS resource data unencrypted. Maestro does a series of GETRESOURCECONTENT and GETRESOURCEDATA calls to assemble the package. Doing a GETRESOURCEDATA on MG_USER_CREDENTIALS will return you the un-encrypted username (MapGuide Server will auto-transform such requests), this is what gets packaged by Maestro which is incorrect. This doesn't happen with MapGuide's packaging as it obviously works behind the scenes and can retain the encrypted form of MG_USER_CREDENTIALS
Having just said that, it is probably impossible "by design" to create a package client-side with properly encrypted credentials as the mere act of fetching the MG_USER_CREDENTIALS resource data will automatically give you back the decrypted version. If you ever get a MgDecryptionException trying to load a Maestro-created package, it is because that package contains plaintext MG_USER_CREDENTIALS resource data instead of the encrypted version.
As an interim measure, Maestro will have a new validation rule that warns you about such Feature Sources, so you know that you are dealing with this particular problem. If this issue (Maestro creating feature sources with plaintext credentials and creating packages such feature sources incorrectly) is a problem for you, your options currently are:
- Always use MapGuide/Infrastructure Studio to create and/or re-secure such feature sources. Of course if you don't have a licensed copy of Studio, you are totally out of luck here. You'll have no choice but to create feature sources with credentials exposed in plaintext in the XML content.
- Always use the official packaging method (ie. with the Site Administrator) for such feature sources to retain the encrypted feature source credentials.
If Maestro was windows-only, the solution would be easy as we can just use some C++/CLI glue to tap into MapGuide's existing encryption/packaging logic. SWIG and/or P/Invoke though portable is un-proven because getting .net code to call into a glue layer (whether generated by SWIG or a hand-crafted C interface) into MapGuide's encryption/packaging logic on Mono in Linux/Mac is a very tall order!
As you can see, this is a very complex problem with plenty of pros and cons on the current set of proposed solutions. Need to think about this some more.
Posts
2 comments:
It looks like its using a fixed key, so the C++ version isn't secure either.
The key thing here is that the raw encrypted credentials can be written, but cannot be retrieved by the public APIs, which probably makes sense from a security standpoint, but it does mean that Maestro cannot create 100% identical packages if it contains such feature sources.
Such security-related discussion would probably be better on the mailing lists. I'm not qualified to say whether the way things are is secure or not.
Post a Comment