Partilhar via

AuthN, AuthZ, and Action, oh my: Microsoft Identity Lifecycle Manager "2" Request Processing

  • Artigo

This week my laptop decided it was time for a career change and made the transition to door stop.  Unfortunately this means that my means of posting this week is through the web dashboard instead of making use of Live Writer.  How does this affect you?  Hopefully not very much; however, you may notice a change in posting style as well as a shortened post this week.  I am working on rebuilding my laptop so that next week's post can get back to normal.

So in my previous post titled Microsoft Identity Lifecycle Manager "2" Policy Service: A Look Behind the Curtain I took some time to provide a peek inside the Microsoft Identity Lifecycle Manager "2" Policy Service.  I mentioned the different phases of request processing:  Rights Check, Authentication, Authorization, Commit the Operation, and Action.  I briefly touched on what occurred in each of those phases.  Today I would like to provide a little more insight into each of these phases.  Hopefully I will provide a primer for starting to think about how to design custom solutions on top of the Microsoft Identity Lifecycle Manager "2" Policy Service as a platform.  Understanding the request processing model is the key that opens the door for further investigation into the Microsoft Identity Lifecycle Manager "2" integration with the Windows Workflow Foundation as a point of extensibility.

Rights Check Phase

During the Rights Check phase the Microsoft Identity Lifecycle Manager "2" Policy Service determines if the user submitting the request has been explicitly granted the rights to perform the operation described by the current request.  If so, the request moves onto Authentication otherwise processing is halted and permission is denied.  This rights check is performed against (and configured by) the ManagementPolicyRule resources within the Microsoft Identity Lifecycle Manager "2" system.  By this time in the processing, the Windows Communication Foundation layer (assuming the request originated from a Web Service call) has pre-authenticated the client connection through the exposed Windows Communication Foundation channel binding.  It has also translated the SOAP envelop into an Microsoft Identity Lifecycle Manager "2" invariant representation of the operation being requested.  This happens to be the Microsoft Identity Lifecycle Manager "2" Request resource.  The Request resource contains a wealth of information about the operation being requested; however, of most importance are:  Creator, Operation, Target, and RequestParameter(s).

During this phase of processing, these pieces of information are used to determine which ManagementPolicyRule (MPR) resources in the system apply to the request.  After finding all related MPRs, the rights system does a final check to verify that at least one of those MPRs carries the GrantRight value of true.  This translates to the actor has the right to perform the operation on the target resource given the request parameter(s).  It is important to note that the operation will be allowed if (and only if) at least on MPR has GrantRight set to true.  It does not matter how many MPRs are attached with GrantRight set to false.  In fact, setting this value to false does not perform rights revocation.  The ability to set GrantRight to false is only used to create an MPR that only attach specific workflow definitions to an operation without needing to also grant rights to a set of users.  This allows enterprises to create MPRs that run a specific workflow when an actor in the "All Persons" set performs an operation without needing to grant rights to "All Persons" to perform that operation.

Should the request evaluation result in at least on MPR that contains a true value for GrantRight, this phase also stamps the Microsoft Identity Lifecycle Manager "2" Request resource with references to all relevant ManagementPolicyRule resources as well as creating resources to track the workflow definitions that may run in the upcoming phases of processing.  These place holders are Microsoft Identity Lifecycle Manager "2" resources only and do not translate into an action Windows Workflow Foundation workflow instance as of yet.  In fact, they will have an Microsoft Identity Lifecycle Manager "2" specific status of "Pending".  So upon completion of this phase one of two things has occurred:

  1. Evaluation of the Microsoft Identity Lifecycle Manager "2" Request did not result in at least one MPR with GrantRight set to true.  In this case the Request is denied and an appropriate SOAP fault is sent back to the web service client.
  2. Evaluation of the Microsoft Identity Lifecycle Manager "2" Request resulted in at least one MPR with GrantRight set to true.  In this case the Request is decorated with references to all relevant MPR resources and Microsoft Identity Lifecycle Manager "2" WorkflowInstance resources tracking the workflow definitions that should run in later phases of processing.

In the later case, the Request is moved into the next phase of processing.

Authentication Phase

Within the Authentication Phase, the Microsoft Identity Lifecycle Manager "2" Policy Service inspects the Request resource to see if there are any pending authentication workflow instances.  These workflow instances would have been discovered, created, and attached within the Rights Check phase above.  In the case that there are authentication workflow instances that are pending the Microsoft Identity Lifecycle Manager "2" Policy Service knows that the client has not yet gone through the required authentication gates needed to provide the second factor authentication (remember the WCF layer has already provided some initial authentication) required to perform this operation.  In this case, request processing is halted an an appropriate SOAP fault is sent back to the web service client.  This SOAP fault tells the client that additional authentication is required, provides the request identifier and the address of the Microsoft Identity Lifecycle Manager "2" second-factor authentication STS.

The client will need to interact with this STS according to the WS-Trust specification to receive a supporting security token.  At which time the client will resubmit the original request to the Microsoft Identity Lifecycle Manager "2" Policy Service with the supporting security token attached.  The Microsoft Identity Lifecycle Manager "2" Policy Service will pick up the existing Request and continue processing it within the Authentication phase.  This time, the Policy Service will determine that there are no more authentication workflow instances that are pending, but there are some that were completed.  This tells the Policy Service that there needs to be a supporting security token attached to the current request.  If, and only if, that token is present and validates to be the token generated by executing these specific workflow instances, the Policy Service will mark the request as authenticated and move it into the next phase of processing.  However, if the supporting security token is not present or does not validate properly, the Microsoft Identity Lifecycle Manager "2" Policy Service will return a SOAP fault telling the current client their request was denied.  However, the Request remains in the Authentication phase.

During the communication between the client and the STS if any of the authentication workflow instance terminate instead of complete, the Request will be marked as denied and processing halted.  So upon completion of this phase one of three things has occurred:

  1. Evaluation of the Microsoft Identity Lifecycle Manager "2" Request did not result in any authentication workflow instances being created.  In this case the Request is considered authenticated (i.e. the initial authentication done by the Windows Communication Foundation layer is satisfactory) and processing moves to the next phase.
  2. Evaluation of the Microsoft Identity Lifecycle Manager "2" Request resulted in at least one authentication workflow instance being created and the client passed all authentication gates provided by the Microsoft Identity Lifecycle Manager "2" STS.  Further, the client has resubmitted their request with the correct supporting security token attached.  In this case the Microsoft Identity Lifecycle Manager "2" Policy Service validates this supporting security token as being correct, the Request is considered authenticated, and processing moves to the next phase.
  3. Evaluation of the Microsoft Identity Lifecycle Manager "2" Request resulted in at least one authentication workflow instance being created and the client failed at least one authentication gates provided by the Microsoft Identity Lifecycle Manager "2" STS.  In this case the STS detects the invalid authentication attempt (i.e. the authentication workflow instance terminates), the Request is denied, and processing is halted.

Again, note that there is no case for the client passed all authentication gates but provided an invalid (or null) supporting security token.  In this case, the Request remains stuck in the Authentication phase and only the current client request is responded to with a SOAP fault communicating their request is denied.

Authorization Phase

Within the Authorization Phase, the Microsoft Identity Lifecycle Manager "2" Policy Service inspects the Request resource to see if there are any pending authorization workflow instances.  These workflow instances would have been discovered, created, and attached within the Rights Check phase above.  Authorization performed in this phase could involve custom data validation (e.g. verify that a resource's DisplayName attribute does not include illegal words or characters) or external authorization (e.g. ask a person's manager for approval of a particular operation).  Should the Microsoft Identity Lifecycle Manager "2" Policy Service detect authorization workflow instances in the pending state it will attempt to execute each of these instances in turn.  An attempt will be made to execute authorization workflow instances synchronously, blocking the current thread.  This means developers who develop custom workflows and/or activities that may run in this phase need to take care to not block the workflow instance's thread for too long (definitely more on this later).  This also allows synchronous validation (such as DisplayName attribute validation logic) to either succeed or fail immediately while still allowing for external authorization (such as manager approval) to park the request until authorization occurs externally.

Processing within this phase will result in one of the four following cases:

  1. Evaluation of the Microsoft Identity Lifecycle Manager "2" Request did not result in any authorization workflow instances being created.  In this case the Request is considered authorized (i.e. no additional authorization is required beyond the granting of rights in the Rights Check phase) and processing moves to the next phase.
  2. Evaluation of the Microsoft Identity Lifecycle Manager "2" Request resulted in at least one authorization workflow instance being created and all authorization workflow instances have been completed.  In this case the Request is considered authorized and processing moves to the next phase.
  3. Evaluation of the Microsoft Identity Lifecycle Manager "2" Request resulted in at least one authorization workflow instance being created and at least one authorization workflow instances has been terminated.  In this case the Request is denied and an appropriate SOAP fault is sent back to the web service client.
  4. Evaluation of the Microsoft Identity Lifecycle Manager "2" Request resulted in at least one authorization workflow instance being created and at least one authorization workflow instances is still running.  In this case the Request requires asynchronous authorization (either a long running authorization workflow instance or external authorization).  The Request remains in the Authorization phase until all authorization workflow instances either complete or terminate.  As soon as one workflow instance terminates the Request is denied.  If all workflow instances complete, the Request is considered authorized and processing moves to the next phase.

Commit the Operation Phase

The Commit the Operation Phase is relatively self-descriptive.  Within this phase the Microsoft Identity Lifecycle Manager "2" Policy Service inspects the Request resource to extract the actual data operation(s) being requested and performs those operations.  It is important to note that the transactional nature of those operations are completely contained within this phase of processing.  That means the transaction both begins and commits (or rolls back) during this portion of processing.  Once the Request moves past this phase of processing there is no rolling back the operation (unless you manually perform the appropriate data operation(s) to compensate yourself).  There are some additional checks performed on the request during this phase of processing that could result in a Request being denied.  For example, a request tries to create a Person whose email address is already in use, or modify an integer value on a Resource with a value outside the configured boundaries.  Should this schema validation fail the request would be considered denied and processing would halt with an appropriate SOAP fault being returned to the client.

So upon completion of this phase one of two things has occurred:

  1. The Microsoft Identity Lifecycle Manager "2" Policy Service is able to perform the data operation and commits it to the data store.  The Request is considered processed and processing moves on to the next phase.
  2. The Microsoft Identity Lifecycle Manager "2" Policy Service is unable to perform the data operation (e.g. schema validation fails).  The Request is denied and an appropriate SOAP fault is sent back to the web service client.

Action Phase

Within the Action Phase, the Microsoft Identity Lifecycle Manager "2" Policy Service inspects the Request resource to see if there are any pending action workflow instances.  These workflow instances would have been discovered, created, and attached within the Rights Check phase above.  Action workflow instances are kicked off in the same manner as authorization workflow instances.  This means an attempt will be made to execute authorization workflow instances synchronously, blocking the current thread.  Thus, custom workflows and activities developed for use in the Action Phase of processing carry the same design requirements as those targeting the Authorization Phase of processing.  Action workflow instances are nearly identical to authorization workflow instances with one major difference, and that is how a terminated workflow instance is treated.  For authorization workflows, a terminated workflow instance stops processing and denies an Microsoft Identity Lifecycle Manager "2" Request.  However, the operation has already been performed and committed to the store by the time an action workflow is executed.  This means that a terminated action workflow does nothing to prevent the Microsoft Identity Lifecycle Manager "2" Request from completing, it just does not complete all of its work.  Terminated action workflow instances can be detected by looking for Microsoft Identity Lifecycle Manager "2" WorkflowInstance resources whose WorkflowStatus attribute is set to Terminated.

Processing within this phase will result in one of the four following cases:

  1. Evaluation of the Microsoft Identity Lifecycle Manager "2" Request did not result in any action workflow instances being created.  In this case the Request is considered completed.
  2. Evaluation of the Microsoft Identity Lifecycle Manager "2" Request resulted in at least one action workflow instance being created and all action workflow instances have been completed.  In this case the Request is considered completed.
  3. Evaluation of the Microsoft Identity Lifecycle Manager "2" Request resulted in at least one action workflow instance being created and all action workflow instances finished with at least one action workflow instance terminating.  In this case the Request is considered completed.
  4. Evaluation of the Microsoft Identity Lifecycle Manager "2" Request resulted in at least one action workflow instance being created and at least one action workflow instance is still running.  In this case the Request requires asynchronous actions to occur (either a long running action workflow instance or external interaction).  The Request remains in the Action (or ProcessingEffects) phase until all action workflow instances either complete or terminate.  Once all workflow instances complete or terminate, the Request is considered completed.

Comments

  • Anonymous
    July 28, 2008
    Mark, this helps quite a bit to understand the process flow.  Is there a diagram / flowchart for the process?  If not, I might make one to use with my team.

  • Anonymous
    July 29, 2008
    The comment has been removed

  • Anonymous
    August 20, 2008
    The comment has been removed

  • Anonymous
    August 21, 2008
    Well a "short break" turned into something a bit longer than I anticipated.  My laptop

  • Anonymous
    August 26, 2008
    Congratulations Jeff!  I guess we can cut you some slack on the delay given your excuse.  :) The diagrams for which you are asking may be better solved with my little surprise I am hoping to announce for my readers.  (Sorry for the secrecy, but I do not want to mention this surprise and then not be able to deliver.)  I will work on getting some diagrams posted in an upcoming post (since I cannot figure out how to add diagrams to comments).