IGA Programs often struggle with on boarding external users, specifically contractors and/or guest-type users. This is largely because these Identity types are not sourced from the internal source(s) of authority used for internal Identities such as employees, students, etc. This represents a unique governance scenario for organizations because contractors rarely have limited access, rather the opposite is true. External users often have elevated access. There are scenarios where external users will not receive elevated access, rather they receive distinct access BECAUSE they are external. This case holds true for external, consumer-type Identities (or the B2C use case is it is referred to in the industry). B2C meaning Business to Consumer.
Another useful use case for this feature would be to allow individuals applying for jobs to an organization to gain a small, but effective Identity footprint. By governing applicant and/or recruit Identities, organizations can benefit by allowing these types of Identities to become a part of the ecosystem in a controlled fashion. Furthermore, organizations can force a registration event for interested individuals to be able to communicate with those persons in a controlled manner as well. When employed, self-registration can also provide organizations with analytics around how many recruits and/or applications actually convert to employees or in the case of higher education, matriculated students. All of the described scenarios are supported within Fischer's self-service solution. The particular feature to be discussed in this guide is the Self-Registration feature. This feature offers a stand-alone registration interface for all external users, or for any user a given organization requires to self-register.
Here is a screenshot of the self-registration configuration interface within the administration UI:
Below is a list of the supported functions within the Self-Registration Feature:
|Defining Distinct User Types|
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.
|Dynamic Form Display for each User Type|
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.
|Access Period Governance|
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.
Note that access periods can be adjusted by authorized users during the registrant's life cycle. Fischer provides global access period modification features as well as distinct access period adjustments per user and/or per allocated resource. Extending (or detracting) the access period can be performed within the self-service interface, the administration user interface or by executing a utility workflow.
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.
|Distinct Confirmation Pop-up per User Type|
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.
|Auto Creation of Identity upon request submission|
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:
|Distinct Approval Per User Type|
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.
|Auto-Assign Resource Group for Provisioning|
|Fischer allows IGA Administrators to pre-configure allocated resources dependent upon the user type (i.e. registrant). This is a powerful governance tool and can relieve the necessity for a registrant sponsor to augment access manually. This provides a predictable approach to ensuring that external users only get the access they are allowed to have based on organizational access policies including regulatory and/or information security boundaries that may be in place. Auto-assigning the resource group (i.e. what access a given registrant type will receive) in concert with pre-defining access periods provides for a least risk and most granular governance an organization can employ.|
|Pre-Process Workflow Execution|
|Fischer offers a pre-process workflow that executes upon submission of the self-registration form BEFORE the registration request is submitted to the engine for processing. This pre-process worklfow helps organizations to build out username logic to meet naming conventions prior to submitting the request to the engine. This helps to ensure that self-registered users do not fall outside of the naming convention requirements opposed and logically coded within the SoA worklfows, which are the workflows that ultimately lead to the access policy evaluation to determine the access a given Identity will qualify for as a result of the user type and the associated attributes entered during the registration process. To understand this concept, once must understand the different intake methods available within Fischer's architecture. Refer to the Architecture section of this guide for more details.|
|Fischer provides a feature that allows for a follow on, post Identity approval. This provides for the ability to define mutually exclusive approval processes for the creation of the actual Identity record within Fischer, and then subsequent approvals are spawned for the associated access.|
|Post Processing Worklfows|
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.
|Self-Registration Entity-based Notifications (Post Processing)|
|The self-registration feature is rounded off by the ability to notify other relevant entities within the organization AFTER self-registration process has completed regardless of the outcome. IGA Administrators can define notifications to be sent to (1) the Requestor, (2) Beneficiary, (3) The Manager assigned to the self-registrant, (4) User (you can specify a static user to send a notification), (5) A group (i.e. a User Group) or (6) You can build a dynamic list of individuals to notify once the self-registration process is completed.|
Please sign in to leave a comment.