[security-dev] deleting a partition

[Pedro Igor Silva]

I think Shane is waiting to merge with his PLINK-130 work.

----- Original Message -----
From: "Anil Saldhana" <Anil.Saldhana at redhat.com>
To: security-dev at lists.jboss.org
Sent: Wednesday, June 19, 2013 1:56:19 PM
Subject: Re: [security-dev] deleting a partition

Bill's pull request is still open. 
https://github.com/picketlink/picketlink/pull/146

Any changes needed before merging?

On 06/17/2013 06:07 PM, Shane Bryzak wrote:
> I don't think anyone's disagreeing that there should be an operation
> that deletes a partition, the point I was simply trying to make was that
> a) it *is* a dangerous operation (Bill asked for a reason, I gave one)
> and b) we should educate our users as to this fact.  I'm certainly not
> arguing against it by any means, I just think we should perhaps place a
> warning in the documentation or perhaps if we really wanted to,
> demonstrate a suggested safety mechanism via a quickstart.  I tend to
> think a warning in the reference docs will be sufficient though.
>
> On 18/06/13 02:53, Pete Muir wrote:
>> I would agree with Bill, and I think this is a poor argument.
>>
>> It's a bad argument, because despite the fact it's a dangerous thing to offer, every single database out there offers the ability to do it. Furthermore, it's not a parallel situation - this is a call the user would have to code, then compile the code, and then execute.
>>
>> If this were a user facing API, then maybe this argument might hold some water, but it's not, it's going to be used inside an application. If we really feel we need this, at least let's make it available, but implement some protection in some configuration such as:
>>
>> boolean partitionCRUD = true;
>>
>> with an option to disable it (in which case the IDM would throw an exception if the methods are called).
>>
>> On 17 Jun 2013, at 16:28, Anil Saldhana <Anil.Saldhana at redhat.com> wrote:
>>
>>> 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.
>>>>>
>>>>>
_______________________________________________
security-dev mailing list
security-dev at lists.jboss.org
https://lists.jboss.org/mailman/listinfo/security-dev