Another aspect to think when we delete an IDP would be the associated user accounts to that IDP[1]. I think we can also show the number of affected user accounts (user accounts that are associated with the IDP we are deleting) in the warning screen as proposed by Malithi.
I too think it would be better to have a discussion on this to identify all the cases that will be affected by IDP deletion and decide on the best approach to handle them. [1] https://docs.wso2.com/display/IS530/Associating+User+Accounts Farasath Ahamed Software Engineer, WSO2 Inc.; http://wso2.com Mobile: +94777603866 Blog: blog.farazath.com Twitter: @farazath619 <https://twitter.com/farazath619> <http://wso2.com/signature> On Fri, May 19, 2017 at 10:05 AM, Malithi Edirisinghe <malit...@wso2.com> wrote: > > > On Fri, May 19, 2017 at 9:19 AM, Ishara Karunarathna <isha...@wso2.com> > wrote: > >> >> >> On Fri, May 19, 2017 at 1:15 AM, Malithi Edirisinghe <malit...@wso2.com> >> wrote: >> >>> Hi All, >>> >>> So in order to support force delete an identity provider, we have to >>> first identify the places the respective identity provider can be referred >>> and then we need to decide on the options we have, on removing those >>> references. >>> Basically, an identity provider is referred by a service provider in >>> authentications steps and/or as a outbound provisioning connector. So I >>> think we can have below options. >>> >>> 1. In authentication steps >>> - If the respective IdP is the only step being configured >>> Here we can simply remove it and set the local and outbound config of >>> default SP (Even when there's no local and outbound config the default SP >>> config is being picked). >>> - If IdP is configured as a step among multiple authentication steps >>> Here unless it's being specifically configured to be used to pick >>> subject identifier or subject attributes, we can simply remove it. If it's >>> configured to pick the subject identifier or attributes, we can follow a >>> pattern like configuring the immediate step to pick the identifier or >>> attributes. So, if it's the last, start from first step. >>> - If IdP is configured as multi option in any step >>> Here we can simply remove it, so the step will have only rest of the >>> options >>> >>> 2. In outbound provisioning >>> Here we can simply remove the reference of the IdP as a outbound >>> provisioning connector. >>> Yet, whatever we do, it should be upon confirmation of the user to force >>> delete and the way the IdP is removed from SP references should be properly >>> recorded in audit logs. In addition, I think it's better if we can notify >>> the user on which SPs are affected and some info with that regard. >>> Also, when asking for the confirmation from user to force delete, it >>> would be better if can indicate how many SPs are getting affected. >>> So at the moment we restrict the IdP deletion by checking for references >>> with [1]. So I think we can simply introduce a similar method to the >>> service API, that checks the SPs being referenced, to be invoked when >>> requesting confirmation. Then upon confirmation deletion can be performed >>> as above. >>> >> I think its hard to provide a generic, Customers may have different >> usecases and customization around this. Automatically deleting them can be >> a risk. >> Even if we delete them automatically customers may have to go back and >> modify SP configurations accordingly. >> >> > It's the customers decision to force delete or not. We can highlight the > consequences. As I said above, it's important to record the SPs effected > and how they are effected. IMO, we should generate some report and notify. > So that, if someone decide to force delete, before proceeding, he knows > that it's getting effected to the SPs configured and the consequences and > after performing he knows who are effected and what he may have to > reconfigure. > > >> >> >> >>> >>> [1] https://github.com/wso2/carbon-identity-framework/blob/mast >>> er/components/idp-mgt/org.wso2.carbon.idp.mgt/src/main/java/ >>> org/wso2/carbon/idp/mgt/dao/IdPManagementDAO.java#L1759 >>> >>> Thanks, >>> Malithi. >>> >>> On Thu, May 18, 2017 at 1:22 PM, Prabath Siriwardena <prab...@wso2.com> >>> wrote: >>> >>>> >>>> >>>> On Thu, May 18, 2017 at 12:09 AM, Ishara Karunarathna <isha...@wso2.com >>>> > wrote: >>>> >>>>> Hi, >>>>> >>>>> On Wed, May 17, 2017 at 10:14 PM, Prabath Siriwardena < >>>>> prab...@wso2.com> wrote: >>>>> >>>>>> At the moment we can't delete an identity provider, if its associated >>>>>> with one or more service providers. >>>>>> >>>>>> Also - for the user there is no way to find out the associated >>>>>> service providers for a given identity provider - without going through >>>>>> each and every service provider config. >>>>>> >>>>>> This is fine (or just okay) if we have 2 or 3 service providers in >>>>>> the system - but its not the case today. >>>>>> >>>>>> Can we provide a feature to force delete an identity provider? If not >>>>>> at the UI - at least at the API level.. >>>>>> >>>>> There are some issues if we delete IDP forcefully. >>>>> Ex : As Farasath raised off line how we changed the already configured >>>>> authentication flow it its the only authenticator in that flow. >>>>> And these authentication steps may be configured according to >>>>> organization requirements, So I think there can be issues if we change >>>>> automatically. >>>>> >>>> >>>> Thats their requirement by deleting the IdP. We need to give them a >>>> warning - and probably show the associated IdPs - and then after >>>> confirmation delete. >>>> >>> I prefer to give a warning and show associated SPs, And then they can >> click a link, go to each SP and remove it. >> > > I also though about this. Yes, it's better to list. But, if we force him > to edit each SP one by one again it's the same problem and so many clicks. > What if there are a large number of SPs. He may still opt to delete > irrespectively. > May be we can provide both, let the user to edit one by one or delete > irrespectively. > > >> >> -Ishara >> >>> >>>> >>>>> >>>>> As I understand the issue. >>>>> We configure authentication configuration in each SP. >>>>> So If we delete a IDP or authenticator we need to change all SP >>>>> configuration. >>>>> And in a organization most of the time they will use same >>>>> authentication chain in all SPs or there can be few templates. >>>>> >>>>> My suggestion is. We can define authentication chains and associate >>>>> those with SP configurations. >>>>> Then it would be easy to manage even there are 100s of SPs. >>>>> >>>> >>>> Yes - reusable steps is something we plan to do in the future. But that >>>> change has to wait some time. Even in the same case - if IdP is in multiple >>>> chains - still we need to provide the IdP delete functionality - but yes - >>>> in that case number of chains would be minimal in practice. >>>> >>>> Thanks & regards, >>>> -Prabath >>>> >>>> >>>>> >>>>> In future we are going to Add ACR support for OIDC (We can implement >>>>> it for SAML as well), then also we have to came up with pre defined >>>>> authentication chains. >>>>> >>>>> -Ishara >>>>> >>>>> >>>>> >>>>>> >>>>>> If we agree - can we please prioritize this...? >>>>>> >>>>>> Thanks & Regards, >>>>>> Prabath >>>>>> >>>>>> Twitter : @prabath >>>>>> LinkedIn : http://www.linkedin.com/in/prabathsiriwardena >>>>>> >>>>>> Mobile : +1 650 625 7950 <%28650%29%20625-7950> >>>>>> >>>>>> http://facilelogin.com >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Ishara Karunarathna >>>>> Associate Technical Lead >>>>> WSO2 Inc. - lean . enterprise . middleware | wso2.com >>>>> >>>>> email: isha...@wso2.com, blog: isharaaruna.blogspot.com, mobile: >>>>> +94717996791 <071%20799%206791> >>>>> >>>>> >>>>> >>>> >>>> >>>> -- >>>> Thanks & Regards, >>>> Prabath >>>> >>>> Twitter : @prabath >>>> LinkedIn : http://www.linkedin.com/in/prabathsiriwardena >>>> >>>> Mobile : +1 650 625 7950 <%28650%29%20625-7950> >>>> >>>> http://facilelogin.com >>>> >>> >>> >>> >>> -- >>> >>> *Malithi Edirisinghe* >>> Associate Technical Lead >>> WSO2 Inc. >>> >>> Mobile : +94 (0) 718176807 >>> malit...@wso2.com >>> >> >> >> >> -- >> Ishara Karunarathna >> Associate Technical Lead >> WSO2 Inc. - lean . enterprise . middleware | wso2.com >> >> email: isha...@wso2.com, blog: isharaaruna.blogspot.com, mobile: >> +94717996791 <+94%2071%20799%206791> >> >> >> > We can have a discussion to get the story straight. But, this is something > we can do and it's good to have it. > I have created readmine [1] to track this. > > [1] https://redmine.wso2.com/issues/6318 > > Thanks, > Malithi. > > -- > > *Malithi Edirisinghe* > Associate Technical Lead > WSO2 Inc. > > Mobile : +94 (0) 718176807 > malit...@wso2.com >
_______________________________________________ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
