Partager via

Forefront Identity Manager - Credential Management, Part 3

  • Article

In RC0, setting up Password Reset is a painful process for many of you (including myself). In RC1, we ship FIM with all the MPRs, along with the supporting sets and workflows, you will need for SSPR.

Today I am going to talk about why we need each one of them.

  1. General: Users can read non-administrative configuration resources
  2. User management: Users can read attributes of their own

These two MPRs are not Password Reset specific. They are needed to allow normal user to navigate the portal.
The first MPR grants users permission to read non-admin configuration objects which includes but not limited to NavBar Configuration (left side of the portal), Homepage Configuration (middle and right side of the portal) and Search Scopes (the search box on top of the homepage).
The second MPR grants users permission to read their own info such as DisplayName. This is needed because we want to display a nice warm welcoming message to the user (i.e. Welcome, John Doe).

There are 4 Password Reset specific MPRs

  1. Anonymous users can reset their password
    This MPR grants users permission to initiate a SSPR request. This also specify which Authentication Workflow(s) should be used.
  2. Password reset users can read password reset objects
    In order for the system to prompt you register for Password Reset, it needs to know if an user is eligible for that. It is done by:

    1. Loop through all MPRs

    2. Find the enabled ones that grants Anonymous Users modify permission on the Reset Password attribute

    3. Further filter the results to make sure the user is a member of the target resources set

    4. Get the Authentication Workflows from the MPRs Then the client will prompt users to register for those AuthN WFs.
      Obviously, users need permission to read lots of attributes in order to perform the steps above. This MPR allows that to happen.

  3. Password Reset Users can update the lockout attributes of themselves
    Lockout gate adds a few references to the User object. For example, if the user is locked out, the Workflow guid is added to User.AuthNWFLockedOut. Also the lockout gate registration object's guid is also added to User.AuthNLockoutRegistrationID to facilitate finding the object. This MPR grants the permission needed for that specific reason. The principal set is relative to resource object's ResourceID so that one can modify their own attribute.
  4. Users can create registration objects for themselves
    For obvious reason, FIM needs to store the QA registration data (for QA
    gate), number of failed attempts (for lockout gate). All those data are
    stored as Gate Registration objects. (4) grants users permission to
    create and modify gate registration objects. (Though the name only
    mention create, it's also granting modify permission).
    The principal set is relative to the resource object's UserID because
    we don't want UserA to be able to create gate registration for UserB
    (i.e. UserA registers for UserB).