Authorization
In Microsoft Provisioning Framework (MPF), authorization verifies that the caller for a provisioning request is allowed to execute the actions in the request. Authorization occurs at three points in the processing cycle: when requests are submitted from the client to the provisioning engine or queue manager, during calls from the provisioning engine to namespaces and procedures, and during calls from MPF to providers of external services.
Authorization During Request Submittal
Microsoft Provisioning Framework (MPF) recognizes two types of provisioning requests:
Untrusted - 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 Web service applications. Untrusted requests are authenticated based on their COM security context.
Trusted - 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 and IProvQueue is used for queued requests. The methods for untrusted and trusted requests are listed in the following tables.
Table: Untrusted Requests
| Submitted to | API/Method |
|---|---|
Provisioning engines |
IProvEngine::SubmitRequest |
Queue managers |
IProvQueue::SubmitRequest |
Table: Trusted Requests
| Submitted to | API/Method |
|---|---|
Provisioning engines |
IProvEngine::SubmitTrustedRequest, Web service |
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.
Authorization During Calls to Namespaces and Procedures
In Microsoft Provisioning Framework (MPF), authorization to call a namespace can be restricted to trustees that are members of a discretionary access control list (DACL). By configuring the Security property of a namespace, you can implement DACLs globally for all procedures in that namespace. You can also configure DACLs separately for individual procedures by configuring the Security property of each procedure.
At the procedure level, authorization is also governed by two other factors:
The procedure access type - A procedure can be public or private, and the caller must have permission for the access type. Public procedures are accessible to external callers, but private procedures are only accessible to authorized callers and public procedures. MPF uses this mechanism to concentrate validation on a small number of public procedures. You can configure the access type for procedures by setting the Access type property of each procedure.
Authorization to execute private procedures is governed by the Execute Private Procedures property in Provisioning Manager. If this permission is set to deny access, the caller can only access public procedures.
Whether the procedure has "Execute as" basic authentication credentials - This type of credential extends specific permission to all eligible callers of that procedure. For more information, see Basic Authentication in Authentication.
Authorization During Calls to External Services
In Microsoft Provisioning Framework (MPF), requests that call external services such as Active Directory pass their security context to providers. Once the service receives the MPF security context, it can perform its own authorization.
To pass security context to a provider, the trusted attribute in the request's execute or queue node must be set to 1. The provider can then use this information to modify the security context of the call to the external service. For example, the HTTP and SOAP Provider does this when initiating an HTTP request with basic authentication. If the request's execute or queue node sets the impersonate attribute to 1, what happens next depends on whether the request's securityContext node contains basic or Kerberos authentication credentials:
Basic authentication - MPF passes basic credentials unchanged to external services. For more information, see Basic Authentication in Authentication.
Kerberos - MPF impersonates the COM credentials of the calling user that submitted the request. For more information, see Kerberos Delegation in Authentication.
If security checking will take place at another level (for example during calls to namespaces), it might be preferable to configure MPFServiceAcct with all rights and simply pass that context instead of implementing Kerberos delegation.