Microsoft Provisioning Framework (MPF) recognizes two types of provisioning requests: untrusted and trusted. Untrusted requests contain only data and the name of a procedure to call. For security reasons, untrusted requests are the standard approach for invoking MPF for both COM and HTTP/SOAP applications. Untrusted requests are authenticated based on their COM security context. In some situations, it can be preferable to submit a trusted request that explicitly defines its security context and procedure steps as well as data. Only members of the groups MPFTrustedUsers, Administrators, and MPFAdmin are allowed to submit trusted requests. Each kind of request has a corresponding application programming interface (API) method that submits it to a provisioning engine or queue manager, depending on whether the request is to be executed immediately or later.
MPF provides two APIs that submit requests to the framework: IProvEngine and IProvQueue. IProvEngine is used for new requests, IProvQueue is used for queued requests, and Simple Object Access Protocol (SOAP) Internet Server Application Programming Interface (ISAPI) is used for SOAP requests. The methods for untrusted and trusted requests are listed in the following tables.
|Provisioning engines||IProvEngine::SubmitTrustedRequest, SOAP ISAPI|
A caller's authority to execute these APIs is managed with Provisioning Manager, using the Requests Security property of both provisioning engines and queue managers.
After receiving requests, MPF clients do not directly perform authorization on callers, but they do build the COM security context and pass it to the provisioning engine. The two client properties MPF uses to do this, Capabilities and Impersonation level, are configured in Provisioning Manager.
SOAP ISAPI verifies that callers are allowed to submit SOAP requests when it creates the corresponding MPF requests. By default, SOAP ISAPI runs under a single user account, MPFClientAcct, so the COM security context is MPFClientAcct. Incoming requests are initially authorized by Microsoft Internet Information Services (IIS). After receiving a request, the way SOAP ISAPI continues this process is determined by the following:
|PassportEnabled||Determines whether the ISAPI authenticates users against
Microsoft .NET Passport.
0 (default): The ISAPI does not perform Passport authentication.
1: The ISAPI extracts the Passport Unique ID (PUID) from the returned Passport cookie and passes it as part of the request's security context (\securityContext\passport\@puid). When the provisioning engine receives the request, it attempts to authenticate users against Passport and redirects them to Passport if they are not accepted. Passport then handles its own authentication.
|SecurityType||Enumeration that determines whether the ISAPI generates the
security context for the call before passing the request to MPF by
0: The ISAPI extracts basic authentication credentials from the incoming call and builds a security context. If the incoming HTTP request contains a basic authentication header, the ISAPI extracts the user name and password and constructs a basic authentication credential for the request's security context (\securityContext\authentication\basic). The ISAPI deletes any security context passed in with the request.
1: The ISAPI passes the security context unchanged from the incoming call. This is the weakest security setting.
2 (default): The ISAPI passes the request through with no security context. The ISAPI extracts the namespace name and procedure from the incoming SOAP request header and constructs an untrusted request from the data node of the SOAP request. As a result, the request does not pass a security context, and the provisioning server will therefore authorize the request based on the COM security context. This is the strongest security setting.