I have a multi-tenant web application that authenticates against Azure Active Directory and allows users to modify content. What is the appropriate way for me to display the name of the last person who edited an entity?
For example, when I ask this question, it will have my user ID tied to it. However, when you read it, you don't see that user 124633 posted a question, you see that Matthew Haugen did. That can be done through a SQL view, or complex return object, or a second API call, or any number of clever means.
That's pretty straight-forward for anywhere that has uses custom authentication (like through ASP Identity, or whatever), but when authentication is wholly controlled by a single, third-party service, there's a bit of a disconnect.
The way I see it, although I could be wrong on this, I have two basic options:
- Call the Graph API to get user information every time a user views the content.
- Cache the name of every person that authenticates against my API (or site).
The first one has a few pros, like that it's light-weight, I'm not responsible if the organization has some weird policy that one person can't view another's name, and any AD updates (like someone changing their name) are reflected immediately.
But at the same time, I'm not sure (although perhaps someone can clear this up) how this would react to employees who are terminated or otherwise leave the organization. Particularly if someone is fired, it would be nice to know that they're the ones that modified the content, rather than having it list some random GUID that used to refer to them.
Basically, I'd really prefer to just use the Graph API, except I'm worried about employees whose AD accounts are disabled. But I'm open to suggestions even beyond that.
I wasn't able to find anything through searching (this is a difficult thing to search for), but the handy Similar Questions bar gave me the following two posts:
- Best approach for managing users that are defined inside the active directory, inside my custom application: This one seems like the user is asking something pretty similar to me, but it sounds like they're worried about custom data in addition to just the name fields, and I'm not.
- https://softwareengineering.stackexchange.com/questions/296631/best-practice-for-relating-an-azure-active-directory-user-with-entity-framework: I'm not totally clear on the question here, but it sounds like they're looking, again, for storing auxiliary information, or allowing their data to sync back up to Active Directory, which is not something I'll ever need (if they need to change something, they can do it directly in their AD--at worst, I'll set up the Graph API to proxy those changes through my UI).
Just to be clear, I do not need to:
- Store extra user information.
- Stress about performance of this individual feature.
- Let anyone outside of the user's organization read their name.