What would be the best way to approach sending commands to a mobile device management resource that is integrated with a connector?
For example, we can provision a device by creating a full MDM connector, and we can tie it to the user appropriately. When the user leaves and returns their device, we can remove the account from the MDM service. This is not a problem.
The question is: What is the best way to send “commands” to the device based on the user record? For example, if the user reports the device is lost, we would like to send a command via the EMM API to have the device “check-in”, then reconcile the result to make a decision. If we decide to lock the device, what is the best way to send a “Lock Device” command using the user record to initiate the command? And then an “Unlock” if the device is recovered?
Reconciling current status and updates is straightforward. Just looking for guidance on how to send commands to the EMM API that are beyond the standard CRUD model.
I think I’m a bit confused around the use case, specifically around why you would want to be using IDM to perform this action rather than invoking the MDM’s API directly. There are ways in which you could leverage the connector and it’s configuration to execute commands on the connected system, but in this scenario I’m not sure I understand what value IDM provides here.
What is the flow you’d envision here? Who would invoke this process that would trigger a command being sent to the MDM’s APIs, and how would they invoke it?
Looking forward to hearing more about this use case!
For a bit of clarity on the use case, and what I’m thinking…
IDM is the central repository and source of truth for all account information within the organization. IDM user records are populated from the HR system. IDM then provisions Active Directory. IT asset management database assigns a mobile device to a user. This database is reconciled into the IDM system to link the records. IDM then also reconciles via the EMM APIs to get status of the devices regularly.
The EMM is synchronized with Active Directory for setup of devices (ie: user logs into their AD account during the setup wizard). EMM then puts Apps on the devices based on AD group membership - so there is no need to touch the EMM directly as it’s populated with AD for provisioning, and is reconciled via the EMM API into the IDM to get latest status.
So, if we have no need to login to the EMM for provisioning, for reconciliation, or for off boarding a device when a user leaves - was hoping to be able to address the other simple functions of the EMM - lock a device is it’s lost, unlock a device if it’s found, and bump the EMM to force it to have the device “call home” to get it’s status in the EMM.
EMM “last seen” and “current state” attributes are reconciled into IDM as part of regular reconciliation.
So, if we can get away from having to have the IT team login to the EMM just for lost/found functions, and can initiate the task somehow from within IDM it’s one less system to log into, one less system to interface within, and 1 direct integration point to our source of truth it makes things more consistent.
Hope that helps clarify what my thought process is.
Thanks for that background, that helps me to better understand what you are looking to achieve here.
How do you envision triggering these functions in IDM? Is there some action you’d take via the IDM UI? Or do you have a custom UI that you’ve integrated into IDM?
Are you already tracking the device status in IDM? Is there a locked status or similar that you could attach an event hook on? What type of connector are you using for this integration, is it a scripted Groovy connector?
My gut is telling me that this is not a use case for IDM, and is one that your EMM application should really be used for. That’s not to say that I don’t think you could cobble together a solution for it using IDM, I just don’t think IDM is the right tool. I’m happy to help explore this further, but I want to be open in my feelings on the potential fit for this solution.
I was thinking that triggering the function could be done by updating an attribute on the user via the IDM UI. On the user, a “command” could be executed by the Help Desk once they confirm the user’s identity. If the help desk change the attribute to “Lost Device” it would flow to the connector with an Update action. The update would interrogate the command and resolve the appropriate API command to call to execute the lock via the EMM.
Then, when the next reconcile happens to the EMM, the latest status would be captured and if the device is locked (confirmed by EMM) then the status would flow back up into the system via the connector and linked record to show actual status.
The part I am having an issue with wrapping my head around is what the UX would be to capture the “command” function. A freeform string attribute doesn’t make sense. An array of strings populated by a lookup might work. A virtual attribute that is derived from the current status of the device record in the connector might work.
Thanks for the guidance and gut feel. Sometimes when trying to solve for a single UI for IT and Help Desk you’re right that it might make more sense to go outside the stock UI and just let the IDM move the data around via reconciliation and provisioning, but “command and control” should be outside the IDM.
It sounds like you are certainly recognizing the complexity you would be introducing here by going down this path. While I still think that leveraging the native tools for the EMM is the right approach here, if you want to continue to pursue this you may want to look at Run on connector script :: ICF 1.5.20.23 and the capabilities that would expose (assuming this is a custom scripted connector). With this functionality, you’d have all the connection information the connector is configured with and you could invoke this script and pass in arguments like the system identifier for the user based on what is in IDM.
Thanks for exposing this conversation. It is interesting. But commonly of late, there is this “blurring” of what is “Identity Management” vs what is “Asset Management”.
And as @mwtech has exposed, IdM is purely an “Identity Management” tool.
(Though I did assist with a very large “Asset Management” implementation concerning the building of dedicated VMs via signals to the VM management service. It was less than pretty and not efficient)
Cheers.