Thanks a bunch folks for the feedback! Looking at the feedback received, I feel all responses either directly or indirectly overlap with each other. I managed to get PrabathS also to talk about some of the related bits around what people usually do in terms of avoiding identity duplication, etc within a given environment just to make sure that the proposed implementation covers almost all the practical aspects of the things, where he confirmed the validity of the approach I've proposed.
@CharithaG, please note and let's get things rolling around the suggested approach. Cheers, Prabath On Fri, Feb 26, 2016 at 4:03 PM, Nuwan Dias <[email protected]> wrote: > 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]> 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 >>> >>> > > -- > Nuwan Dias > > Technical Lead - WSO2, Inc. http://wso2.com > email : [email protected] > Phone : +94 777 775 729 > > > _______________________________________________ > Dev mailing list > [email protected] > http://wso2.org/cgi-bin/mailman/listinfo/dev > > -- 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
