When designing systems that interface with MPS, it is important to consider the source of user input as well as the source of system maintained or derived input, that input that is not user supplied. If you are designing an interface that will be directly exposed to end-users such as a Self Care Portal, you must assume that any data entered into the system is suspect and could be malicious. This applies as well to those parameters that are not directly end-user supplied but are pulled from external sources. The most typical example of this would be the preferredDomainController property.

It is important to understand the source of these system maintained values, some questions you may want to ask are:

• How well protected is this system from tampering?
• Who has access to modify these values in the system?
• Are these values updated to reflect system changes? For example, when a Domain Controller is decommissioned do the stored values for preferredDomainController get updated?

Input into MPS whether it is user supplied through a form on a Web Site, System maintained or derived from a combination of the two, can be used in a number of different ways within HMC Provisioning Workflows. While there are some protections in place throughout the system and workflows, a developer should assume that any piece of input could be used -- for example:

• As part of a SQL query
• To form an LDAP filter
• As part of an address string, as in the case of the preferredDomainController mentioned above.

Any of the cases above could expose an application or system to security risks if the input is not properly protected. At a minimum this may entail properly encoding URLs and strings. More extreme measures may include storing and comparing against whitelisted values or partial string matches to ensure validity.

Effective data validation for MPS is similar to data validation for any web exposed application. Developers writing against MPS should follow the data validation best practices outlined in the following topic: How To: Protect From Injection Attacks in ASP.NET.

In addition to these, there are some general MPS Data Validation best practices that should be considered.

• Only expose to users those fields that they should reasonably be able to answer -- for example, Name, Address.
• Obtain product or business specific values from Plan Manager or external Business Suport Systems. These values include size or number of resources as well as feature values, such as OWA Enabled/Disabled.
• Obtain system or datacenter specific information from Operations Support Systems or other trusted source.These values include URLs and Server Names.