Empower your employees with the self-service portal

The Identity Portal empowers users across an organization to manage their access and request additional access for themselves via a friendly web application accessible from mobile phones, tablets, or desktop devices.

Additional access can refer to either roles, applications, or entitlements. A role is described as a collection of applications while the latter can refer to software, areas, or any type of resource that a user can have access to. Entitlements can be used to grant fine-grained access within applications, e.g. an application which manages files can have entitlements to denote which users can read, write, or delete records

To find out more about the terminology revolving around access, please read our post “What is Role Based Access Control?”

While the Identity Portal is centred around access request management, it can also allow users to manage their own details (e.g. name, addresses, phone numbers, etc.) as well as update their password. However, these features are optional and can be easily configurable, even disabled completely if they are not needed. Any rules enforced by ideiio will propagate in the Identity Portal too, meaning users will have to provide compliant data when making changes (e.g. password strength rules).

Customising requests

The items that users can request access to are customisable via ideiio where administrators can provide descriptions, logos, or web addresses – which allows applications to be accessed from within the Identity Portal. Additionally, for sensitive items, administrators can force users to provide a reason for their request in the form of a message. The items are listed as chosen by users, either as a grid or a list which can be filtered using keywords.

The roles which can be requested are enforced by the users’ categories from within ideiio, thus preventing requests to a role from an unwanted user. In a similar way, applications are grouped into catalogues, which are related to categories, to dictate which applications can be requested by particular users. This allows administrators to fully configure which users can request particular applications or roles, and implicitly the afferent entitlements.

Requesting access

When a user requests access to an application/role, the owner of the resource will be notified and prompted to manage the request. The owner can consist of a single administrator or a group of administrators. Requests from the same user are conveniently collapsed so that owners can manage multiple roles and applications via a single page. The request itself is processed by choosing which of the items to approve or deny while viewing the accompanying messages as well as entitlements.

Entitlements can be requested along with an application by cherry picking them when requesting the parent application. After a user has requested an application or has been provided access to it via ideiio, they can still request additional entitlements as long as they don’t have access to all of an application’s entitlements.

The entire request process can be managed via workflows which can dictate whether the administrator receives a prompt, additional emails are sent, etc. The users themselves are also notified via email when their request was dealt with, informing them of items that were approved or rejected.

Adding access

For various reasons, sometimes, an application or a role does not need to go through an approval process. If the item does not need to be managed by an administrator and can be left “on a shelf” for any user to grab if needed, it can be made “addable”. While offering the ability to choose which users can simply grab it without requesting it, the role/application can be granted at the click of a button thus allowing users to benefit from access without requiring an administrator’s input.

While self-service is a great way of allowing users to manage their own access, ideiio also allows administrators to request access on behalf of a user. This can be useful in cases where an administrator has restricted privileges but requires additional access, for a user, to an application or a role that they do not own. When requesting access on behalf of a user, the remainder of the process goes through the same workflow with the exception that the initiator – in this case the administrator making the request on behalf of the identity is displayed when the owner approves the request.

We’re here to help

Get in touch

If you have a quick query or you’d like to start a conversation, please get in touch using the contact form and a member of the ideiio team will get back to you.

Alternatively, you’re welcome to email hello@ideiio.com

"*" indicates required fields