Hi All, My suggestion is that we need to facilitate *both* approaches(soft delete and hard delete).
Glad that at least we have some sort of agreed norms for creating, reading and updating users. *But*; W*hat does "delete" mean in the context of this system/application? *this is a sort of a question that we(middleware provider) might not be able to answer when building the EMM/IoT. For some customers this might be completely forgetting that there was a user X, for some others; it might be that there was a user X who is so and so and did these things. I am suggesting a two level approach. Firstly, if we facilitating deleting a user *inside* our application, when it is triggered it should be a *soft* delete. What it would mean is we delete the user logically. I would recommend this blog Don't Delete, Just Dont! <http://udidahan.com/2009/09/01/dont-delete-just-dont/>[1] with a simple example in favour of soft delete. Certainly there might be statistical requirements that need to be drilled down into historical data. And deleting a user from the system should not be a gone-gone at least for some grace period. Secondly, there can be requirements such as reclaim disk space, hard-deletion required as per retention/privacy policy. In that case, we need to provide some sort of a workflow that would clear the stuff. There's a possibility that existence of shared resources might cause even far more complex filtering. On the other hand, as Prabath mentioned when user-management is handed by outside of the system, third party products such as LDAPs. Once a user is removed by an outside functionality there is no default way to listen an event or make a workflow to get triggered this into our application. This is why we need to implement *manually* triggered workflow which can be consumed by system administrators. I think we can decide the best approach if we decide whether to maintain historical data on meta data repositories or not? WDYT? Regards, Rasika [1] http://udidahan.com/2009/09/01/dont-delete-just-dont/ On Thu, Feb 25, 2016 at 5:41 PM, Prabath Abeysekera <[email protected]> wrote: > To my understanding, the most commonly practised use-case in many > organizations is that, user management is handled outside third party > products. For instance, in a typical EMM deployment, which utilizes IS as a > key manager, it is highly unlikely that user provisioning/de-provisioning > is done via IS itself, unless IS is what's primarily used for the same. > Most of the people typically prefer to provision/de-provision user > management related resources by directly accessing some in-house > infrastructure that controls access to the underlying LDAPs, etc. In that > sort of a scenario, there's literally no way that you can listen to some > event and make a workflow or some other similar mechanism to get triggered > automatically. Instead, system administrators would have to manually > trigger a workflow or something to clean-up the orphaned resources. So, > there has to be some functionality, IMO, in EMM to support that aspect. > > If all user-mgt tasks are done through IS, however, you have the > opportunity to use the workflow extension feature to clean-up the aforesaid > resources irrespective of the fact that the user is fully removed from the > underlying user-mgt system or made inactive. Note that, in both cases, the > associated resources have to be cleaned up so, the need of triggering a > workflow to detach all stale resources is must. > > Maintaining statistics is a whole different other aspect, IMO. Without > relying on the primary metadata repositories used by the underlying > user-mgt systems for keeping historical data, some appropriate monitoring > infrastructure has to be used, which would analyze and bring us who is > active in the system and who is not, in the form of a audit trail or a > report. Certain organizations do practice certain steps "not to duplicate > identity", whereas certain others do not, primarily because letting the > user base grow with some users who no longer exist in the system is > pointless. Even for the people who avoid user duplication, IMO, it is a > must for the system administrators that their resources are cleaned up when > they leave an organization. > > All considered, IMO, we can have some workflow-based mechanism bound to > EMM/IoTS, which not only can be manually triggered when the users are > removed externally, but also gets triggered when users are deleted or made > inactive. WDYT? > > Cheers, > Prabath > > > > > On Thu, Feb 25, 2016 at 4:49 PM, Charitha Goonetilleke <[email protected] > > wrote: > >> Hi All, >> >> In IoTServer and EMM, we noticed that resources owned by a user will >> become orphaned once particular user is deleted from the system. If someone >> created a user with same username again, above orphaned resources will get >> assigned to newly created user, since both users have same user name[1]. >> >> Anyway I believe, this shouldn't happen in the system since, it will lead >> to orphaned resources or allow two different people to have the same >> identity. >> >> Solutions: >> >> 1. Use the user delete workflow[2] to get user delete event and allocate >> resources from user being deleted to other user or admin. Also if required >> resources can be deleted or left as it is to be associated with future user >> who will have the same name. However this BP is bit complex and need >> additional specific implementations to filter resources and apply necessary >> actions. >> >> 2. Use status claim of user to indicate whether user is inactive instead >> of deleting user from the system. As long as user is not actually deleted >> from the system, there is no any possibility to have same user name for >> another user. Also it is involved with less implementation complexity and >> it is good in the sense of maintaining past statistics and historic >> artifacts within the system. >> >> However with above solutions, there is no way to identify if user was >> removed from external user store, without going through the carbon console >> or user management portal in IoTServer or EMM web app. >> >> I'm also wondering how APIM and APPM handle the same situation when user >> get deleted. WDYT? Is there any better solution to eliminate above issue? >> Your comments and thoughts are highly appreciated. >> >> >> [1] https://wso2.org/jira/browse/IOTS-73 >> [2] >> https://github.com/wso2/carbon-identity/blob/master/components/user-mgt/org.wso2.carbon.user.mgt.workflow/src/main/java/org/wso2/carbon/user/mgt/workflow/userstore/DeleteUserWFRequestHandler.java >> >> Thanks & Regards, >> /charithag >> -- >> *Charitha Goonetilleke* >> Software Engineer >> WSO2 Inc.; http://wso2.com >> lean.enterprise.middleware >> >> mobile: +94 77 751 3669 <%2B94777513669> >> Twitter:@CharithaWs <https://twitter.com/CharithaWs>, fb: charithag >> <https://www.facebook.com/charithag>, linkedin: charithag >> <http://www.linkedin.com/in/charithag> >> > > > > -- > Prabath Abeysekara > Technical Lead > WSO2 Inc. > Email: [email protected] > Mobile: +94774171471 > > _______________________________________________ > Architecture mailing list > [email protected] > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > -- With Regards, *Rasika Perera* Software Engineer M: +94 71 680 9060 E: [email protected] LinkedIn: http://lk.linkedin.com/in/rasika90 WSO2 Inc. www.wso2.com lean.enterprise.middleware
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
