The Future of Collaboration — iDenedi App
Web and mobile applications are evolving. This is true for consumer applications, as well as enterprise applications being used by organizations.
Take user authentication, for example. Just a decade ago, the primary way users were authenticated for enterprise applications was through Microsoft Active Directory. That seemed to be the main, if not the only, option for companies that wanted to give their employees relatively painless access to systems.
Web applications for consumers were a different story. Every web application had its own method of authentication- people started having to memorize a different email and password combination for every site at which they registered. To make matters worse, some sites requested a unique username, instead of an email.
Then came Google & Facebook, game changers in the authentication. With your Google account, you could suddenly log into YouTube, Gmail, and a host of other Google and non-Google products and services. Soon, every site you visited provided a log in option by using your Google or Facebook account. It simplified access and gave users a seamless way to register or log into applications.
All of the above authentication methods solved the major issues of their time — Active Directory provided a way to organize users inside of organizations and give them across the board access to internal applications, while Google and Facebook login options made consumer access to applications quick and easy.
As our systems evolve, however, more and more companies are finding that they require a new level of authentication that combines both internal users and public users — a sort of hybrid to unify both types while keeping the administration options separate.
This is especially true in scenarios where systems have:
- External and internal users — For example, a system that has organizational users accessing certain information and services, but is also open to public users who would access a different set of services.
- Users managed by different parties
- Users with multiple roles — This includes systems where users might potentially be applicants for a certain service, as well as admins for another service.
- A massive number of users — On systems with tens of thousands or hundreds of thousands of users with different user categorizations or ‘types’, current authentication methods are cumbersome and difficult to manage.
- Users not managed by ‘admins’ or technical members — This is applicable in systems that allow users to promote and demote their status or claim certain rights and do not require admin approval or management.
As a software company that helps organizations create systems, we knew a solution needed to be found. It was only a matter of time before applications outgrew authentication.
Our customers’ problem with authentication soon became our problem. As we were building our process automation engine, ESP, we realized that we, and our customers, have authentication issues that cannot be resolved through integration with Active Directory or an API from Google.
We wanted to make something that was:
- Multifunctional — not just about authentication
- Dynamic — not a stagnant ‘list’ system where updating who is on what list or in what group is completely dependent on an admin
- Easy to use — you don’t need a technical certification to administer users or give access
- Flexible — the authentication system needed to accommodate for external users (outside of the organization) and internal users (employees)
Enter iDenedi.
For those in the know, iDenedi started out as a communication regulation app that was designed primarily to regulate communication between members in groups and between the employer and employees through announcements. While it proved extremely effective in those areas, it has proven even more effective as an authentication tool for all types of applications.
iDenedi revolves around the concept of ‘groups’. As a user, you can create groups, invite people to groups, communicate within groups, etc. We quickly realized that by using iDenedi as a doorway into the applications we created (authentication through iDenedi), those same groups could be given different levels of access or be considered different ‘user types’ on systems.
The beauty of iDenedi was that it was so simple to use and flexible. Users created a group could select its type (whether its an invisible group, public group, or private group), select a primary joining option (invitation only, admin approval required, via smart contract, or anyone can join), and the application admin just has to identify which groups get access to their systems.