When a user creates data within an organisation that data doesn't belong to the user but rather to the organisation. So when the user is deleted (maybe because he left the organisation) that data should not be deleted but rather be governed by the organisation.
In the case of APIs in API Manager they are shared with all users having the required permission. In the case of Applications they too "can be" shared if the org opts to. Thanks, NuwanD. On Friday, 26 February 2016, Sumedha Rubasinghe <[email protected]> wrote: > 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] > <javascript:_e(%7B%7D,'cvml','[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] >> <javascript:_e(%7B%7D,'cvml','[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] <javascript:_e(%7B%7D,'cvml','[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] >>> <javascript:_e(%7B%7D,'cvml','[email protected]');> >>> Mobile: +94774171471 >>> >>> _______________________________________________ >>> Architecture mailing list >>> [email protected] >>> <javascript:_e(%7B%7D,'cvml','[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] >> <javascript:_e(%7B%7D,'cvml','[email protected]');> >> LinkedIn: http://lk.linkedin.com/in/rasika90 >> >> WSO2 Inc. www.wso2.com >> lean.enterprise.middleware >> >> _______________________________________________ >> Dev mailing list >> [email protected] <javascript:_e(%7B%7D,'cvml','[email protected]');> >> http://wso2.org/cgi-bin/mailman/listinfo/dev >> >> -- Nuwan Dias Technical Lead - WSO2, Inc. http://wso2.com email : [email protected] Phone : +94 777 775 729
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
