The User Management configuration is what controls help desk and OBO functionality. You may in fact have more than one user management screen to provide a mutually exclusive experience for different types of authorized users. The feature is broken up into three primary sections.
On Behalf Of User allowed to perform the following actions
This section is where administrators define exactly what OBO and/or help desk users are authorized to do as it relates to managing identities. We will outline what each specific "Action" means in terms of functionality:
| Update Personal Information |
| As identities are provisioned, Fischer stores values of the identity in attributes. This equates to certain values such as First Name, Preferred Name, Legal Name, and so on. These values are able to be administered natively within Fischer. The "Update Personal Information" permission allows authorized users to manage identity information. It is important to remember that Fischer provides authorized filters that determine which elevated users are able to manage all or a subset of the identities stored within Fischer. This will be discussed below when the "Manage Profiles on behalf of" functionality is discussed. This information will be displayed under the "Users" tab in self-service. Another important item to remember is that administrators are able to set certain fields as read only while defining the screen where attributes will be displayed. This may affect an OBO / help desk user's ability to manage or update identity information. |
| Manage Secret Questions |
| This permission enables OBO and help desk users to manage the secret question and answers for identities. |
| Reset Passwords |
| OBO and help desk users with this permission are able to reset passwords for identities. |
| Enable / Disable Accounts |
| This permission enables OBO and help desk users to utilize the enable/disable accounts feature. It's important to note that this functionality is only available for connected systems that support this type of automation. |
| Validate Accounts |
| This permission will allow OBO and help desk users to click a button to "Validate" an account. This feature is often used when the caller may appear to not have an account within a system, or if they received an error during a self-service password reset process that will inform them the account was not found. This is mostly due to a mismatch in the association link between the Identity and the downstream target accounts and is very useful to quickly determine if the caller's account is not properly associated with their Identity. |
| View User Access |
| When this permission is enabled, OBO and help desk users have the ability to see the access associated with the user. This will be in the form of account → entitlement associations. This is very useful information so that OBO and help desk users can see the access footprint the user currently has. If the user is calling about an account they are having trouble with, and the OBO / help desk is able to see the current access associated to the Identity, it can help to quickly determine if the incident should be escalated for the scenario where the user is calling about an account that does not appear to be associated with their Identity. |
| Enable / Disable Accounts |
| This permission will allow authorized OBO and help desk users to enable and disable accounts as necessary to service the callers needs. Not this functionality is only available for connected systems that support this type of automation. |
| Manage Security |
| This permission will allow OBO / help desk users to manage devices for an Identity in the case where mobile authentication is activated and the user has registered devices or needs to have a device registered. |
Profile Update Properties
This section is utilized for defining the approval rule to be used when updating profile information (i.e. attribute values for an Identity). It is important to note that the Dynamic UI screen configuration is what controls whether or not an approval is required prior to updating corresponding Identity information. If the Dynamic UI configuration is set to require an approval, the defined approval here for "Approval Rule for Update" will be initiated. You can also make comments optional or required before an OBO / help desk user submits a request to modify profile attribute values. Finally, a pre-process workfow can execute. The goal of executing a pre-process upon submission on a profile update is to capture any external information that may be associated with a given attribute that was modified. In the event of a modification to a key attribute value that correlates to access changes and/or vanity-type changes such as usernames, it is important to utilize this pre-process workflow to allow for abstraction and execution of follow on logic before the information is submitted for processing. This workflow is often used to execute access qualification evaluations as a result of any relevant attribute changing that may affect access for a given user.
Manage Profiles on behalf of
This is the authorization filter that will authorize a set of OBO users to be able to perform the actions as defined above in the "On Behalf Of USer allowed to perform the following actions" section. This filter is where we can discuss the need for multiple User Management configurations. Currently, for each set of permissions an organization may want to enable for different levels of OBO / help desk users, you will need to build out multiple User Management configurations. The authorization filter defined within the context of the User Management configuration will only be applicable to the users that resolve to the filter (i.e. the members of a certain security group.
As you can see, you are defining the user type, which is essentially the grouping of identities that the authorized requestors will be able to take action on behalf of. In the example above, the user type is set to the "All Users" group. In this scenario it means that all users will be available to the defined requestor (which is the On-Behalf-Of Users" group to take the actions allowed by the configuration above. Notice the "Profile Update Screen". This is another configuration that may require administrators to build out a separate User Management configuration. The reason is that Fischer offers dynamic control of what the actual profile management screen looks like for the qualified requestor type. This means that you can build multiple views depending upon which requestor group you have defined.
An example for this would be if you have multiple help desk levels defined (Help Desk 1, Help Desk 2 and Help Desk 3) and each level is authorized to see and take action on different attributes. In this scenario, you would want to build out 3 distinct screens and build three distinct authorization filters and assign each screen to the authorized requestor group. This provides governance to ensure that you can control what attributes a given layer of authorized user is allowed to see. A good scenario here is you may not want a help desk level 1 user to be able to see and take action on profile attributes that are only reserved for executive level identities. In this model, you have the ability to build out different screens and define which attributes each requestor type is allowed to interact with and modify as dictated by the permission settings above.
You will also notice the bottom configuration "User Profile Screen (Read Only). What you need to understand here is that on the self-service User Management screen, upon searching for an identity you can display certain attributes of the person in a read only fashion. Often times this information can be used to help the help desk user identify who the user is. For example if you're ever asked, "tell me your name and full address" before we can proceed, and as the caller you will provide the information. This configuration option provides administrators with the ability to control the attributes displayed as read only versus what attributes will be available further down the screen for actual modification. This can help to limit the amount of data displayed as often times an identity's attribute list can grow quite significantly and can also be sourced from third parties. This is a great feature for limiting what is displayed as read only so there is not so much noise on the screen or attributes that may not make sense to an OBO or help desk user.