Re: [security-dev] deleting a partition

By the way, (coming in late to this thread) partition management is not as simple as implementing a few CRUD methods. There's the entire configuration issue that we need to deal with - each partition may have a complex configuration with multiple identity stores. This is exactly the reason that we removed the partition CRUD operations from IdentityStore earlier. I still think that the partition management operations shouldn't be in the IdentityStore interface, they should be in IdentityManagerFactory and we most likely need a separate SPI to support this properly (persisting the partition configuration state as well as the partition state itself). On 15/06/13 09:09, Shane Bryzak wrote: > I can think of a reason - it's dangerous. Like the time I accidentally > dropped a table from a production database in a 100+ person call centre > (20 seconds later the support calls started coming in). We should try > to make it as hard as possible for users to shoot themselves in the foot > like this. Perhaps it could be addressed via documentation or a > quickstart, where we recommend that the developer puts some protective > measure around the delete operation that forces the user to type in > capital letters "YES I AM SURE" or something like that. > > On 15/06/13 04:58, Pedro Igor Silva wrote: >> ----- Original Message ----- >>> From: "Bill Burke" <bburke(a)redhat.com&gt; >>> To: "Pedro Igor Silva" <psilva(a)redhat.com&gt; >>> Cc: security-dev(a)lists.jboss.org >>> Sent: Friday, June 14, 2013 3:29:06 PM >>> Subject: Re: [security-dev] deleting a partition >>> >>> >>> >>> On 6/14/2013 2:19 PM, Pedro Igor Silva wrote: >>>> Ok, the reason is why this is a critical operation which involves removing >>>> critical data. That said, I don't think we should do that, like I said, >>>> "automatically". >>>> >>> But again, you give no reason :) Sure its critical data, but everything >>> in the IDM is critical data. >>> >> I'm really trying to think in something else, with no success :). >> >> Maybe avoid mistakes and make sure the user knows what he is doing ? :) And considering that we provide a simple way to do that ... >> >>>> You can always use the following construct to query all identity types: >>>> >>>> IdentityQuery<IdentityType> query = >>>> identityManager.createIdentityQuery(IdentityType.class); // here we use >>>> the base type to create the query >>>> >>>> query.setParameter(IdentityType.PARTITION, Realm.DEFAULT_REALM); // or >>>> query.setParameter(IdentityType.PARTITION, "Another Partition") >>>> >>>> List<IdentityType> result = query.getResultList(); >>>> >>>> for (IdentityType type: result) { >>>> // remove >>>> } >>>> >>> So, the above can be done at a higher level and not have to be done at >>> each IdentityStore? There's no potential for duplicate entries in a >>> federated store? >>> >> Yes you can. U/R/G are unique for each Partition. >> >> Btw, just added a new test case for that. >> >> https://github.com/picketlink/picketlink/blob/master/modules/idm/tests/sr... >> >>>> I understand your point and it is valid. My opinion is just we should leave >>>> that for users. >>>> >>> Who is the user? The admin UI on top of Picketlink IDM API? >>> >> Considering your usecase, yes. >> >>> -- >>> Bill Burke >>> JBoss, a division of Red Hat >>> http://bill.burkecentral.com >>> >> _______________________________________________ >> security-dev mailing list >> security-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/security-dev > _______________________________________________ > security-dev mailing list > security-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/security-dev _______________________________________________ security-dev mailing list security-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/security-dev