If we introduce a state to user (like what we have done for access tokens) this problem can be easily solved at the first level.
Then it's just a matter of deciding what to do with removed users and their data later on as a clean up task by infra. On Feb 26, 2016 11:30 AM, "Rasika Perera" <[email protected]> wrote: > 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 > > _______________________________________________ > Dev mailing list > [email protected] > http://wso2.org/cgi-bin/mailman/listinfo/dev > >
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
