Ever more companies are catching on to single sign-on (SSO). Either to increase productivity of their employees by letting them move seamlessly from one application to another without having to enter credentials repeatedly. Or to reduce the hurdle for customers to use different authentication mechanisms for various applications offered by the organization, possible combined with passwordless logon to increase user experience. By combining it with the notion of personas, organizations can now make SSO even more user-friendly and secure.
Let’s first explain what personas are. The term persona is often used in marketing where personas are archetypal groups that represent the needs of a larger group’s goals, requirements and personal preferences. In that way, personas are stand-ins for real customers. Author Alan Cooper introduced the term personas in ‘The inmates are running the asylum’, where he used personas to talk about archetypal users of software programs. When we talk about personas in Identity and Access Management (IAM), we also denote a group of people, namely people who have the right to perform a certain task, or have an (official) mandate to perform a certain task. In higher education for instance, a professor has different rights than an alumnus. In such a case, personas are interesting because they distinguish the person from the persona. An individual person can at the same time be a professor and an alumnus. In their professor persona, they have more rights for specific tasks (grade an exam or a paper, for instance) than in their alumnus persona. The rights associated with these personas are defined in policies, leading to the concept of policy-based access control. IAM solutions that don’t include the capability to distinguish these personas often force individuals to use different accounts with different credentials for the different personas they assume. If this is the case, SSO is impossible.
By adding personas to IAM, whenever a user wants to access an application that he has no rights to, or wants to perform an action that his persona will not allow (grade the exam, as in the example above), the workflow will trigger step-up authentication. Very much like a banking app may allow you to log in via facial recognition but will enforce step-up authentication (and e.g. ask for a pin code) as soon as you want to make a payment above a certain threshold
Throughout the digital maturity curve
Many people may already experience the lack of persona capabilities in their banking app. If you hold both a personal and a professional account at your bank, the application may well ask you to log out of your personal banking app and reauthenticate with different credentials to access your professional account. If personas are applied, the banking system will only ask you to switch persona.
The same applies to financial services institutions that are more advanced on the digital maturity curve and offer financial aggregation, allowing their clients to access their accounts at a different bank. Just viewing the account information will be easy, but making payments with the third-party banking account will require step-up authentication, but still using the same account with the same set of credentials.
As retail banks build out their digital ecosystems, adding more third-party services to their apps, they continue on the same principle. When offering connected mobility to customers, users can easily consult the timetable of public transport, but the workflow will ask them to perform step-up authentication to order and pay for their tickets.
By adding the persona concept, TrustBuilder allows SSO to deliver an even better customer experience while keeping all security mechanisms intact. As an extra functionality, TrustBuilder can even perform SSO for legacy applications that have no support for SAML, Oauth or OIDC. This means you can set up SSO across federated and non-federated web applications.
Interested in giving your users an enhanced customer experience? Contact us.
