Azure AD / App / API architecture thoughts?

%3CLINGO-SUB%20id%3D%22lingo-sub-2444754%22%20slang%3D%22en-US%22%3EAzure%20AD%20%2F%20App%20%2F%20API%20architecture%20thoughts%3F%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-2444754%22%20slang%3D%22en-US%22%3E%3CP%3EHi%2C%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EWe%20have%20a%20requirement%20to%20allow%20some%20Azure%20AD%20users%20(we%20call%20them%20app-admins)%20to%20invite%20(using%20B2B)%26nbsp%3B%20new%20users%20into%20specific%20AD%20groups.%26nbsp%3B%20The%20app-admin%20users%20own%20group%20membership%20(%2B%20some%20biz%20rules)%20will%20dictate%20which%20groups%20they%20can%20invite%20new%20users%20into.%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3ETherefore%20we%20can't%20grant%20these%20users%20the%20required%20permission%20to%20(B2B)%20invite%20directly.%26nbsp%3B%20Instead%2C%20we%20have%20a%20custom%20App%20Registration%20which%20exposes%20our%20own%20thin%20API%2C%20which%20makes%20calls%20to%20the%20Graph%20API%20in%20the%20context%20of%20the%20application%20(which%20has%20been%20granted%20permission%20to%20invite)%20rather%20than%20the%20user.%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EWe%20require%20that%20consumers%20of%20our%20API%20may%20only%20call%20it%20within%20the%20context%20of%20a%20user%2C%20so%20we%20can%20make%20the%20necessary%20decisions%20about%20what%20to%20allow%2Fblock.%3CBR%20%2F%3E%3CBR%20%2F%3EI%20have%20two%20questions%20I%20hope%20you%20can%20help%20with%3A%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3COL%3E%3CLI%3EDoes%20this%20architecture%20appear%20sound%3F%20Just%20checking%20there%20isn't%20something%20built-in%20to%20AD%20we%20are%20missing!%3C%2FLI%3E%3CLI%3EWe%20can%20flow%20the%20user%20identity%20as%20far%20as%20our%20API%20-%20before%20it's%20replaced%20with%20an%20application%20level%20permission.%26nbsp%3B%20Ideally%20we'd%20love%20to%20see%20the%20user%20who%20invited%20the%20new%20user%20in%20the%20AD%20audit%20logs%2C%20but%20as%20the%20user%20was%20ultimately%20invited%20by%20the%20application%20I'm%20guessing%20this%20isn't%20possible.%26nbsp%3B%20We%20can't%20use%20anything%20like%20on_behalf_of%20as%20the%20user%20doesn't%20have%20permission%20to%20perform%20the%20ultimate%20action%20in%20AD.%3C%2FLI%3E%3C%2FOL%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EThanks!%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EJ%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-LABS%20id%3D%22lingo-labs-2444754%22%20slang%3D%22en-US%22%3E%3CLINGO-LABEL%3EWeb%20Apps%3C%2FLINGO-LABEL%3E%3C%2FLINGO-LABS%3E
Regular Visitor

Hi,

 

We have a requirement to allow some Azure AD users (we call them app-admins) to invite (using B2B)  new users into specific AD groups.  The app-admin users own group membership (+ some biz rules) will dictate which groups they can invite new users into.

 

Therefore we can't grant these users the required permission to (B2B) invite directly.  Instead, we have a custom App Registration which exposes our own thin API, which makes calls to the Graph API in the context of the application (which has been granted permission to invite) rather than the user.

 

We require that consumers of our API may only call it within the context of a user, so we can make the necessary decisions about what to allow/block.

I have two questions I hope you can help with:

 

  1. Does this architecture appear sound? Just checking there isn't something built-in to AD we are missing!
  2. We can flow the user identity as far as our API - before it's replaced with an application level permission.  Ideally we'd love to see the user who invited the new user in the AD audit logs, but as the user was ultimately invited by the application I'm guessing this isn't possible.  We can't use anything like on_behalf_of as the user doesn't have permission to perform the ultimate action in AD.

 

Thanks!

 

J

 

0 Replies