[security-dev] deleting a partition

Anil Saldhana Anil.Saldhana at redhat.com
Mon Jun 17 11:28:45 EDT 2013

Agree. There was a time when I deleted a table from production
DB thinking it was staging. :)

On 06/14/2013 06:09 PM, 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 at redhat.com>
>>> To: "Pedro Igor Silva" <psilva at redhat.com>
>>> Cc: security-dev at 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/src/test/java/org/picketlink/test/idm/query/IdentityTypeQueryTestCase.java
>>>> 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.

More information about the security-dev mailing list