Authorization during request submittal

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.

Untrusted requests
Submitted to... API/Method

Provisioning engines IProvEngine::SubmitRequest

Queue managers IProvQueue::SubmitRequest
Trusted requests
Submitted to... API/Method

Provisioning engines IProvEngine::SubmitTrustedRequest, SOAP ISAPI

Queue managers IProvQueue::SubmitTrustedRequest

Submitted to...	API/Method
Provisioning engines	IProvEngine::SubmitRequest
Queue managers	IProvQueue::SubmitRequest

Submitted to...	API/Method
Provisioning engines	IProvEngine::SubmitTrustedRequest, SOAP ISAPI
Queue managers	IProvQueue::SubmitTrustedRequest

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:

The Capabilities and Impersonation level properties.
Two registry keys located in \HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Provisioning\ISAPI.

Property	Description
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 using IProvEngine::SubmitTrustedRequest. 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.

Property

Description

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 using IProvEngine::SubmitTrustedRequest.

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.