Add a layer to security for "connection context / endpoint / etc."

We are running into some limitations with CRM's security model. We have site security and we have some users which have more than one site on their appuser. We also have security integrated with our authentication system. 

 

What we need to do is have a layer added to the appuser security model to allow us to modify the user's access based on either how they are connecting or some other value we set. 

 

CRM Security today 

Appuser -> roles -> (sites)

 

CRM Security changed 

AppUser -> Connection context (run as one site, web site, import, etc.) -> roles -> (sites)

 

This would allow for us to lock down users based on how they are connecting (via api or an external site or if they are connecting acting as one specific site. We could have these be additive or suppressive or we could actually change how the tables are associated. This would give us the benefits of having actual appuser "addedby" and "changedby" fields when using an external site or mobile app or fundraiser on the go or the bulk import utility. It would also ensure that someone doesn't affect records they shouldn't have access to via whichever mechanism they are connecting. 

 

Our immediate need / why we want this: 

We have appusers which process gifts for more than one site. If they create a constituent currently (with both roles / sites) on their appuser record, the constituent will get both sites by default. If we remove one site from their record, everything creates perfectly. So we would like to allow them to operate as one site, then flip their account back to normal afterwards. 

We could modify every form in CRM to add the site field but that is not realistic and we don't want to take ownership of that much functionality in CRM. We'd rather stick to the beaten path and have CRM changed to fix this.

Our future need / why we and most others will need this 

If we create a web app - particularly using bbui-angular - the solution currently is to either create another user or just accept that the added by / changed by fields won't be set correctly. 

If we use the bulk import process when it is released, we will also run into a problem where the appuser won't be set correctly on records that are imported. 

  • Guest
  • Jun 29 2017
Organization Name (Please enter full organization name) Dignity Health
Reported Version 4.0
  • Attach files