| Name |
| Naming the configuration should provide proper context as to the user experience that is being created. |
|
| Description |
| As always, use this field! Many implementors fail to utilize a very important field that can help for post production support. Description fields are there to help describe the configuration. It is important to properly name and describe each independent self-service configuration so subsequent IGA Administrators that may have not designed a particular configuration, they can understand what the configuration is defined to do. |
|
| Resource Group |
Selecting the Resource Group will dictate the actual resources that will be available to authenticated Identities that will appear in the drop down list of requestable resources. The Resource Group that will appear within the defined Self-Service configuration is built under the "Groups" feature. Refer to the Groups guide for more information.
|
|
| UI Configurations |
|
|
|
| Add Resource search to top level group |
| By enabling this function, users attempting to request access from the self-service portal will see a "Search" option appear in the drop down list. If you do not enable this option, end users will not be able to search the list of resources available for request. |
|
| User allowed to select resource permissions |
When defining resources, IGA Administrators can also include a set of permissions that will be provisioned once a resource is released for provisioning. Enabling this option will allow the requestor to select the available permissions. If a resource is selected within self-service and there are defined permissions, AND this option is enabled the product will pop up a box that will allow for permission selection. Here is an example of the popup that will appear upon selection of a resource with defined permissions and this option is enabled:
Note that if this option is not enabled. IGA Administrators can define permissions that will be provisioned when the resource is released for provisioning. The end user will not be aware of the permissions that will be appended to the account request, however they will still be provisioned even if the requestor is not able to select the specific permissions to append to the resource request. By released for provisioning, we mean that the resource may require an approval (as you can see in the screenshot above). This means that after the resource is requested, it will follow the associated approval process. The requested resource will not be released to be provisioned until the approval process is completed as defined, and the result is an acceptance of the request.
|
|
| On Behalf Of User and End User allowed to change resource permissions |
| If this option is enabled, it will allow both the end user (requestor) and the OBO requestor to change permissions within the "Change Access" feature offered within the self-service portal. |
|
| Allow resource sponsors selection |
| Be enabling this option it will open up the ability to requestors, requesting resources that require sponsorship to select a sponsor for the resource being requested. |
|
| Allow bulk sponsor change |
| When enabled, requestors will have the ability to select and modify the sponsorship for multiple resources at once, instead of changing sponsorship one at a time. |
|
Access Period Configuration |
| Use Dates |
The use dates feature provides IGA Administrators with a granular level of control pertaining to access periods granted for provisioned resources. There are three options available in the Use Dates drop down and they will be explained as follows:
| Not Required |
| This is the default option. If the setting remains, requestors will not be prompted to request a defined access period for the selected resources associated with an access request. |
|
| Request Level |
|
If this option is enabled, regardless of the Identity, or Identities (if it is a bulk request) all access requested will adhere to a single access period. When enabling request level access period enforcement a series of sub-configurations will activate. The sub-configuration options are below:
| Show |
|
This configuration allows IGA Administrators to set a preference as it relates to how the date is displayed. The options for display are as follows:
Start and End - This will show the start and end date fields and provide a calendar for selection of each date. Start Only - This will only show the start date field, and requestors will only be able to select the start date End Only - This will only show the end date field Fixed Days - This will display
|
|
| Allow Permanent |
| If selected within the configuration, this will display and provide for the ability to request permanent access to the requested resource(s). |
|
| Access duration (Used to determine End Date) |
|
IGA Administrators can set global, default access periods for a given self-service user experience. This provides for global oversight over the requested resources and ensures that all provisioned resources are governed consistently. Remember that each self-service configuration can be built specifically for different user types and by doing this, IGA Administrators can change this setting dependent upon which Identities are authenticating. This is important to point out because different access period restrictions can be applied depending on the type of Identity requesting access. There is also a setting...
This setting will allow approval authorities to override the global access period configuration. If IGA Administrators want to allow certain approval authorities to override the access period configuration but not all, then a separate "Group" of resources would need to be defined that would allow for access period restriction overrides.
|
|
| Limit Maximum Duration |
|
This configuration will allow IGA Administrators to set a maximum duration at request time. This option can be presented in multiple ways.
| Day(s) |
| If set to days, and the "Show" feature is configured as "Start and End", "Start Only" or "End Only" the end user will see a calendar drop down since we are letting the end user select dates. When any of these three options are selected, the calendar that is presented to the end user will have blackout days based on the "Limit maximum duration to:" setting. The goal of these feature is to provide an internal (automated) calculation of the end dates for access periods. This setting will affect how far out into the future a resource will be allocated (i.e. the end date of the resource(s) being requested. |
|
| Month(s) |
If set to months, Fischer will calculate in Months, not days. All descriptions pertaining to how the feature works, as defined above are still applicable when configuring the access period to calculate in Months. Note that Fischer bases it's month configuration off of a 30 month. If that is not sufficient, Fischer recommends using the Days calculation. |
|
| Year(s) |
If set to Years, Fischer will calculate in Years, not days. All descriptions pertaining to how the feature works, as defined above are still applicable when configuring the access period to calculate in Years. Fischer calculates based on 365 day year. If that is not sufficient, Fischer recommends a days or months calculation.
|
|
| User Level |
| If this option is enabled, it provides for a granular access period configuration and is defined within the supplied authorization filter for each Identity type. You'll notice the configuration options above will be disabled if the Request Level is set to User Level. |
|
|
|
|
| Default duration (Used to determine End Date) |
This feature works in conjunction with the features described above. It provides for the ability to set the default duration to be displayed. If "Limit default duration to:" is set, this feature will display the default duration. This number must be less than or equal to the maximum duration. This value cannot be greater than the maximum duration limit. Setting the access period configuration will move to this portion of the user interface configuration:
|
|
Request / Change Access on behalf of |
| Allow multiple recipients within single request |
| This configuration option will enable OBO requestors to select multiple beneficiaries for a single request. This is a powerful feature that can help organizations streamline the access request process by allowing for a bulk submission. This thwarts the need to submit each individual beneficiary request one at a time. |
|
| Limit access end date to Identity account's end date |
| When OBO requests are occurring, this feature will force access periods to align with the access period defined for the actual Identity account the user will obtain within Fischer. While you do not have to do this, this option is a great way to help organizations align de-provisioning of access, with the disablement of the actual Identity profile. While some organizations do not want to do this, this configurable option can provide predictability to organizations that want to make sure all de-provisioning is aligned to when the Identity profile will be disabled. This will help to ensure that all access is de-provisioned simultaneously. While some organizations prefer graceful de-provisioning (i.e. de-provisioning an Identity over time and their access removed accordingly) this feature can enforce a global de-provisioning policy. |
|
| On behalf of authorizations |
| IGA Administrators can define authorization filters within the context of a self-service configuration. This is the true decision point relating to how an organization desires to build out their self-service governance processes. The authorization filter is where the OBO Identities can be governed and only allowed to take action on the Identities they are allowed to. Whatever the authorization filter needs to be can control whether or not IGA Administrators will need to build out a separate, distinct self-service configuration. This filter is applicable to all OBO related actions. If an organization requires distinct OBO groups to be defined with different requestable resources, different access period oversight as well as the other features described above a separate self-service configuration will need to be defined. This approach helps organizations to draw boundaries around how OBO Identities are allowed to manage and administrate end user Identities. |
|
| Pre-Process Worklow for request and change access |
| This pre-process workflow will be launched upon submission of any new access request or change access request. Upon submission of the request, IGA Administrators can capture the submitted data payload and initiate a workflow before the request is submitted to the appropriate IGA engine for processing. |
|
New User Creation |
| On Behalf of Users allowed to create new users |
Enabling this feature will allow for authorized users (defined in the OBO authorization filter) to create new Identity profiles directly within Fischer. This feature is primarily used as a mechanism for organizations to create external users such as contractors or Affiliates or any Identity type that does not flow through the standard Source(s) of Authority. Within this feature, there are multiple options to consider:
| On Behalf of User allowed to create new users |
|
This is the global option to enable the Create New User (Create New Identity Feature for OBO Identities. The feature will appear as a button on the main access request screen if this option is enabled. Below is a screenshot of the self-service interface where the button will appear if the feature is enabled.
|
|
| UI Label |
| This allows IGA Administrators to the the label string to be displayed next to the combo box when OBO Identities are authorized to Create New Identities. |
|
| New User Type Attribute |
| IGA Administrators can set this value to a Fischer Provisioning Hub attribute that will store the Identity type. This significance of this value is to provide an attribute to qualify a submitted new Identity for the pre-defined access policies such as provisioning, and authentication rules. This provides organizations with the ability to easily extend their Fischer solution to be a source of authority for external users while simultaneously enforcing existing access policies that are global to the organization. This added functionality and attention to governance makes it simple, efficient and secure to create new Identities directly within Fischer. This feature will help organizations solve the problems associated with on-boarding external users that exists today. |
|
| Name |
| The name field should be treated as the "Value" field within an <input> tag. This is the actual value that will be passed to the defined New User Type Attribute and will be the literal value used to qualify users for the appropriate access policies as well as ensure that the proper approval processes are also initiated as needed. |
|
| Display Name |
| This value input to this field will be what OBO users see in the combox box when they are selecting the type of Identity they want to create. |
|
| Create Identity Account |
| When this option is enabled, regardless of any other resources that are requested, the beneficiary's Identity profile will be created by default. If a request is submitted and it qualifies for more access, that access will be evaluated per the defined access policies, however the Identity profile will still be created. |
|
| Default |
| The default radio button will help IGA Administrators specify the default option that will be displayed in the combo box when the feature is in use. |
|
| Identity Approval |
This feature is tied to the "Create Identity Account" option. If the "Create Identity Option" is enabled, IGA Administrators can define an approval process to initiate before the Identity is created. Remember that regardless of any other access the user may receive, when "Create Identity Account" is enabled, Fischer will take the necessary steps to build the Identity profile. The Identity Approval option provides a layer of governance before the Identity is created. If the "Create Identity Account" feature is disabled, this feature will also be disabled. Note that while the ability to initiate a distinct approval for the Identity profile, if the resources associated with this external Identity creation request require an approval, those processes will still be initiated. |
|
| User Info Screen |
| The feature allows IGA Administrators to define a distinct form for each defined Identity type that is allowed to be created through the Create New Identity feature. This feature provides governance over the distinct Identity types and the associated intake process. Each distinct Identity type may require different information (i.e. attributes) that an organization may need to properly evaluate and grant access to the inbound Identity profile. For example, if an organization is creating a guest Identity, less information may be required compared to the creation of a Contractor Identity. This feature, in conjunction with Fischer's Dynamic UI feature helps organizations control and govern their intake process when they allow Fischer to be the source of certain Identity types. |
|
| Pre-Process Workflow |
IGA Administrators can use pre-process for CNU in most cases to build username and email using the organization's defined naming algorithm as well as other data checks such as the phone number and such. In some cases we have to go look into other systems to pull back more data that should be set based on the data inputted on the CNU form. The pre-process workflow is initiated upon submission of the Create New User (Identity) form and helps IGA Administrators build the necessary complete profile to be submitted to the Fischer IGA engines for processing. |
|
| Post-Approval Workflow |
This is a worklfow that can be defined and initiated after the approval process has completed. In some cases, organizations need the ability to take action post approval, for example on denial. This feature provides extensibility to initiate another automated process if you need to.
|
|
| Show Date Option |
| This option is available when the request level access period configuration is set to "User Level". The global settings are disabled and IGA Administrators will define the access period configurations distinctly for each Identity type OBO Identities are attempting to create. |
|
| Default End Date Duration |
| This option is available when the request level access period configuration is set to "User Level". The global settings are disabled and IGA Administrators will define the access period configurations distinctly for each Identity type OBO Identities are attempting to create. |
|
| Maximum End Date Duration |
| This option is available when the request level access period configuration is set to "User Level". The global settings are disabled and IGA Administrators will define the access period configurations distinctly for each Identity type OBO Identities are attempting to create. |
|
| Allow Permanent |
| This option is available when the request level access period configuration is set to "User Level". The global settings are disabled and IGA Administrators will define the access period configurations distinctly for each Identity type OBO Identities are attempting to create. |
|
|
Change Access
|
| Maximum number of extension attempts a user can perform before an approval |
| This is a powerful feature for both the business unit and the IGA team. Setting this feature up will allow the beneficiary Identity to request access extensions on their own up to a certain threshold. Which is what this feature can be used to define. The value can be from 0-99 and Fischer will keep track of how many times the beneficiary Identity has extended access. Once the threshold is met, a designated approval process will be initiated for any subsequent extension requests made by the beneficiary Identity. |
|
| Identity Account removal appoval |
| If a user with the authority to Change Access submits a request to remove an Identity profile, IGA Administrators can capture that request and ensure the appropriate entities within an organization have visibility and authority to review the removal request and either approve or deny. Removing an Identity profile can be a profound action within the Identity ecosystem and this feature can help IGA Administrators to supply the appropriate level of governance over the removal of Identity profiles. |
|
| Change access period approval |
| When a user requests access period changes, this feature will initiate an approval process. Note that If the Maximum number of extension attempts a user can perform before an approval is set to anything other than 0, this approval will not initiate until the threshold controlled by that setting is reached. After that, this approval will initiate to require approval before any further access period changes can happen. |
|
Transfer Access
The above is a screenshot of the authorization filter you will use to configure which users will have the authority to transfer access to another user. This feature is used when a particular Identity's access is required to be transferred to another user. This functionality is something that end to end automated solutions can take care of without the need for the "Transfer Access" configuration, however keep in mind we are building our a self-service configuration and this particular feature is to enable and authorize access transfers to occur from the self-service portal. Let's define what you are seeing below:
|
| Beneficiary Type |
| The beneficiary type can either be a group of users, or you can build a dynamic (static) filter. Once configured, all Identities that resolve to the group or defined filter will be the users upon which access transfers can take place. In the scenario above, we have selected "All Users" as the beneficiary. While |
|
| Requestor Type |
| The requestor type is where you will define which Identities are authorized to perform access transfers. As you can see from the configuration above, we've configure the authorized requestors to be only users that are in the Help Desk Level 2 group. This means if you are not in the Help Desk Level 2 group you will not have the ability to initiate access transfer requests. |
|
|
Post Process Workflow
|
| Defining a post process workflow |
This workflow will initiate after the request has been submitted, after any pre-process worklfow(s) have finished and after the relevant Fischer IGA engine has taken action. This workflow is used primarily to update any internal username or email address repositories with new data as a result of the request. It is also used to update Fischer's staging tables. To add a post process workflow click "Select" next tot he Post Process workflow input box.
|
|
| Defining Notifications Post Process |
This feature allows IGA Administrators to send out a notification to relevant parties based on the level of request or the ultimate status of the request.:
Note that IGA Administrators can define multiple notifications and scenarios relating to when and how to send relevant notifications.
| Notification |
| This allows for the selection of the actual notification to be sent to the define recipients |
|
| Recipient Type |
|
Setting the recipient type is defining who will receive the notification selected in the step above. IGA Admins have multiple options regarding who the notification should go to:
- Requestor - The notification will be sent to the requesting Identity
- Beneficiary - The notification will be sent to the beneficiary of the request
- Manager - The notification will be sent the manager of the beneficiary
- User - If this type is selected, IGA Admins can select a static Identity to send the notification
- Group - IGA Admins can define a User Group and all users in the group will receive the notification
- Dynamic - IGA Admins can build a dynamic filter that will execute at run time and resolve the Identities at run time. Those Identities will be sent the selected notification.
|
|
| Recipient |
| This column will offer the option to select the recipient if User, Group or Dynamic is set for "Recipient Type" |
|
| Level |
|
The level offers two options:
- Request - This will send a global notification for the entire request, independent of the number of resources or Identities included in the request.
- Resource - This will send out N notifications for N number of resources included in the request.
If the recipient type is set to "Manager", Fischer will look at each beneficiary within the request and send out the selected notification to each relevant manager. So while IGA Administrators are defining a single notification, it is important to be aware that the same notification will be sent to all managers involved as defined against the beneficiary's Identity profile.
|
|
| Status |
IGA Administrators can select a particular status when they would want to initiate the notification. This is the status of the actual request submitted and the response from Fischer once the request has been processed. Note that if a request has multiple beneficiaries, and IGA Admins have set to only send on a certain status Fischer will review each beneficiary within a bulk request and only send to the beneficiaries where the status threshold has been met. For example if 5 beneficiaries are included in a bulk request, and the notification is set to send on failure. If 3 out of 5 provisioning events fail, the status will report back failure for this distinct resources (and associated beneficiaries). Fischer will send a notification to the 3 that failed and not send a notification to the 2 that succeeded because the configuration says to only send notification on failure. |
|
