Self-Registration

Fischer provides organizations with the ability to define distinct user types (and/or entities). The purpose of this is to help control and govern the underlying business process that will initiate depending on the type of user registering. This functionality helps organizations to provide more efficiencies and agility to their internal processes by providing the user type distinction. This is the section of the configuration where distinct user types can be defined:

The Name field is the actual value that is submitted to Fischer for processing. This is typically the same value used in the conditions defined for access policies to determine what set of resources the self-registering user will receive. The display name is what will be shown in the drop down on the actual self-service page. You'll also notice an option for "Create Identity Account". When this is selected, upon submitting a registration request, an Identity will automatically be created within Fischer. If you do not select this option, the user will not receive an Identity until the entire request is processed.

Also notice the "New User Type Attribute" combo box. This is where administrators select which Fischer Provisioning Hub attribute will receive the inbound request "Name" value as defined in the Name column above.

While defining user types, Fischer empowers organizations to dynamically display unique forms with the required attributes necessary for the selected user types. This can help organizations to gather the required information at registration-time as opposed to needing a separate, most likely manual business process to obtain all necessary information about the registrant. This feature works automatically as more than one user type is defined and as the user type is selected from the combo box, the form will auto-refresh and display the appropriate data elements required by the organization for the given user type. You would configure this as you define multiple user types eligible for self-registration. It is this section of the self-service configuration:

This will allow administrators to define unique forms for each eligible self-registering user to complete. This helps your business scale because as your external users may come from multiple sources, your business may be required to track certain attributes of the external user that are different from others. You will construct the different screens required within the "Dynamic UI" feature.

Most external users will be on a set access period schedule. This is due to various requirements, but primarily information security and other internal audit controls. Since external users are treated different than internal users, it is a best practice to set up a pre-defined access period for the registering user type. This helps to automatically enforce governance and information security policies automatically, which should be considered the most secure and risk-averse approach to allowing external users to register themselves.

Organizations can define unique notification to be sent to any Identity that is entered into Fischer via self-registration. The notification is sent via SMTP. It's important to note that the feature provides for a single beneficiary notification for allocation and/or denial (of the self-registration request). Note that while the self-registration feature provides a single, global notification for all self-registering Identities, Fischer provides multiple mechanisms to notify Identities. For example, while a global self-registration notification can be sent, if configured self-registered beneficiaries can receive resource-specific notifications including a notification upon successful creation of the Fischer Identity itself. This notification should be used to notify self-registering users as to the status of their registration only, and administrators should leverage other features for more granular and personalized notifications.

Upon submission of a self-registration request, IGA Administrators can customize the pop up that will appear post registration. This is a useful feature to provide distinct user types with differing instructions as to what they should do next as well as offer a more personal response directly to the registering user type. This is a great feature to enhance the user experience to make it more personable, which all software should do in this day and age. Setting the distinct popup message per user type is done in this section of the self-registration configuration:

Upon submission, the text typed here is what will be displayed to the self-registering user. This can be used to thank users for submitting the request as well as provide instructions for next steps or set expectations for turn around times. We've also seen this feature used to display the help desk information for the self-registering user to use if they have any further questions.

If an organization desires, the Identity account (i.e. the IdentitySystem LDAP Object) can be automatically created as a result of the user registering, regardless of any other resources that the registrant may have allocated to them. Some organizations just want a Fischer Identity Created and then provide OBO authority to the sponsor that is responsible for registrant to augment access via self-service requests. This configuration can be set here:

For each of the defined user types, it is important to scale since each user type may require different internal personnel involved to review and ultimately approve the requested user type. For example, if a contractor is registering this may require a more granular and governed approval process than if a recruit or affiliation / application Identity is created. This configuration option is here:

This allows organizations to define distinct approval paths for each self-registration request. Most organizations deliniate which approval workflow is required based on the type of self-registering user. For example, contractors may need to follow a separate approval process than on-boarding a "guest" user, and so on.

Fischer provides further extensability and allows for a post automated process to execute once the entire self-registration process completes (including any post approval processes that are defined to be executed). This worklfow is most often used as an internal mechanism to update Fischer's staging tables to and potentially username and/or email address repositories to ensure that the event executed via self-registration is also represented within the transaction tables and other repositories that track things like email address.

It is important to update repositories because you do not want to lose track of events initiated outside of the SoA process. Many organizations enforce a "never re-use" policy as it relates to usernames and/or email addresses. This is because there is a potential of the user coming back and also it is important to not reassign an email address to a new person because if the email address was built for an executive and that executive leaves, then a new user comes along that meets the naming convention algorithm to match that of the previous executive, there is a chance emails intended for the separated executive would now go to a standard end user. Even though the executive is separated, it is important to keep the username(s) and email addresses archived for liability and other information security standards.