How to prevent someone requesting a catalog item on behalf of another person who is not allowed to request it themselves

[peter_osang]

I have a requirement from customer to be able to exclude the members of an AD group from requesting a specific catalog item.    I have been able to meet this requirement by adding an exclude visibility condition for that group to the catalog item.  However, this condition does not prevent another person from requesting that catalog item on behalf of an excluded user.

Do any of you have any ideas on how to work around this apparent loophole?

[CharlesW]

Would it be possible for you to simply remove the "request on behalf of" options from the catalog item, so that nobody could request it on behalf of somebody? Namely, disable the "Enable request on behalf?", "Enable request to AD property", "Enable request to manual list?", etc.. I can't think of anything else.

[jdempsey]

@CharlesW , I've never used it, but how does the "Custom View" for request on behalf work?  Could that be helpful here?  There isn't much detail in the docs (that I can find).

Also, it's probably more trouble than it's worth, but you could use Security Group Matching or Security Group and Collection Matching to prevent anyone from requesting (all) items on behalf of just the users in the designated AD group.

There doesn't really seem to be an easy way of doing this. 

[CharlesW]

I don't think that either option will be of much value.  There is certainly no possible way to apply visibility conditions to the target device/user when using ROB.  The ROB view  is basically a view that defines the machines that can be targeted for Request on Behalf of. If a given machine is not returned by the view, then you can not use ROB to deploy to that device. The "Security Group Matching" functionality allows  you to explicitly define the devices that specific users can target when using ROB.  Both settings are global. I guess it depends upon what Peter is trying to do, but the two options you mention, and disabling ROB on the catalog item, are the only things that might come close.

[peter_osang]

Thanks guys,

I appreciate all your ideas.   I agree that none of those solutions are going to be feasible.   Disabling ROB on the catalog item altogether would be the cleanest option.   However, I think that it's unlikely that they will want to go that far as these catalog items need to be requested in advance of a person starting in the organisation and thus they need to be requestable by another person.

[jdempsey · Accepted solution]

Who's doing the ROB in the loophole scenario?  The scenario doesn't really make sense to me, but then I don't really know the criteria for who's in the group and who would want to request on their behalf that isn't also in the group.

Anyway, one other option would be to put a PowerShell script on the On Submit event that checks to see if the target user is in the AD group and then automatically calls the CancelRequest API.  Not the best user experience, but easy to implement and gets the job done.

[peter_osang]

Thanks Jim,

In this specific scenario, they are catalog items that are used to request a virtual desktop.     Often a person who needs a virtual desktop will be a consultant like me that is onboarded for a project, works remotely, and will not be issued with a physical laptop from the organisation to work from.    The App Portal website is only available from a corporate desktop.    You therefore have the challenge that you need access to a virtual desktop, but the only way that you can request that access is by having one in the first place.     The resolution is to have someone request that access on behalf of you.  Thus, requesting this catalog item on behalf of another person is quite a common occurrence.

In this customer's case, there is a class of workers that are not allowed to have a virtual desktop.   I don't know the exact reasons why. 

Thanks for your on-submit action suggestion.   It looks like we may need to resort to something like that.   To make it a little more user friendly, we could also configure the PowerShell script to write a note in the request to explain why it was cancelled and either enable email notifications for notes or explicitly send an email notification to the requester and target user.

Thanks again to both of you for your help much appreciated.