1.1 Case Study - Entra Guest Authentication
One of most often presented questions to us is:
Could you do something to make it easier to manage Entra ID guest invitation process?
As we have promised, we listen and we implement. Although there has not been willing customer to make this particular case study possible, we did it anyhow. Not least because of our own curiosity in the subject. We hope this will turn to a possibility to win another customer.
Entra ID Authentication is Cumbersome
It is not polite to point out a finger to fellow authentication services, but this has been a struggle even for us. Olevi doesn’t use Microsoft products in its own business ventures, but as we are all connected, it is not possible to escape it.
M365, Azure and Entra are everywhere. Very possibly biggest portion of online meetings are held in Teams. This has some worrying side effects, but we are not here to discuss that.
Especially in IT-work, a consultant might have dozens of guest accounts in different Entra tenants. Some of them allow guests to manage their own MFA methods, some not. While user experience is mostly consistent, Entra still manages to function differently from one organisation to another. Once a guest loses connection to one tenant and forgets about it, it might be very difficult or even impossiple to restore connection e.g. after a mobile phone change.
Managing Entra Guests is Cumbersome
While guest users may find it difficult to authenticate to organisations’ M365 services, they rely on organisations’ contact persons to invite them in and manage their precense as guest in organisation’s tenant.
It’s mostly communication with the guest and sending new invites as previous failed. For individual guest this is something that happens quite rarely after all, but many organisations have a catalyst (with a reference to The Starfish and the Spider) that comunnicates with endless amount of guest users in their daily work.
For this catalyst worker Entra ID guest invitations can be a nightmare. They might hope that this could be made easier.
Federation to the Rescue
What people do, when they need to authenticate from place a to place b? They federate.
Federating authentication is what Olevi and Identity Providers in general do. They connect people to authenticate between places. It’s actually called federating only when you have a topology of organisations (or entities to be exact) that connect with each other.
Most organisations nowadays have their own Identity Providers already. Many use Microsoft Entra some use Google, but some might have something of their own. Or some might use Olevi.
In Entra, it is quite simple to connect (or to federate, if you will) separate Entra tenants together even if they are from separate organisations. It becomes a bit trickier when some organisations use different Identity Providers.
This is a free world, so organisations should have the privilege to choose, right? This is why we have authentication protocols. With them we can connect different Identity Providers together even though they are from different vendors.
Even Entra makes it possible to attach external custom Identity Provider so that users from that provider can use their own accounts in their own organisation.
You can manage multiple external sources in Entra. It is possible to add as far as 1000 separate external connections to your Entra tenant.
This might become cumbersome again.
One possibility is to add consolidation. Or if you have other advanced requirements for your authentication you might want to attach a better capable Identity Provider to manage your authentication flows. In this case you would put a broker in between your partners and your Entra to manage authentication better.
This might even be a suggestion from your security team.
Adding e.g. Olevi in between also enables extra actions during authentication flow. One might want to provision guests to Entra ID automatically so that organisation’s catalyst doesn’t need to do that.
Adding Actions to Authentication
Entra ID relies on the fact of email addresses in distinguishing users when they authenticate. Under the hood there are fancy guids, as there should. But when users authenticate, they announce themselves based on email addresses.
But how about when guest is authenticating with banking credentials using Finnish Trust network FTN? FTN doesn’t release the email address of the user.
In these cases you need to fetch the email address from somehwere else and pass it along as an attribute hiding the SSN received from the banking authentication.
In simple words:
Users are able to sign in to Entra ID as guests even based on strong authentication with banking credentials or mobile certificate (Mobiilivarmenne)
So when you are connecting different kind of directories and authentication methods you might want to have something in the middle to normalise different authentication flows so that the experience is as smooth as possible for the users and the catalysts in your organisation.
Provisioning is Necessary
It is required for the user object to be present in Entra ID before users can authenticate (even with custom external IdP). Thus, users need to be provisioned before they authenticate. They still need to be invited.
Provisioning can be done in many ways. Some organisations have fancy IdM systems to do this work. As one example, Syncope could be mentioned.
Some systems are advanced in a sense that they can manage user authorisation necessities based on agreements between organisations.
To be clear we don’t have that YET, but provisioning can also be done as an authentication action during the authentication flow on Olevi. There could be an action that checks using Microsoft Graph API if the user already is a guest in the tenant and updates their data based on authentication. If not present and if preconditions are accepted, action could create the invitation for the user on the fly.
This would lessen quite a lot the bourdon of organisation’s catalyst managing the guest users.
Remember to Remove
Removing the users is often neglected. Users come and they go. Look me directly in the eye and tell me that in your organisation guests are removed in timely fashion when their task in the organisation is done.
Sure, good for you, but I bet it is not too common.
When users authenticate using their identities in their own organisation, they loose ability to get in to Entra after the federated authentication possibility is taken away.
Even better, if we have proper provisioning, also removed users will be deprovisioned when they go.
There is a Working Demo
Of course we tried this before we announced it is possible. And we do have an Entra tenant. But it is for demonstrating purposes at the time of writing this, not to do business.
If you are interested seeing this in action, please be in contact. We can show you how it works. Quite possibly you can even authenticate to our Teams and meet us as our guest with your own federated identity.
Maybe after some time you might find a video presenting the demo on our web pages.