[security-dev] deleting a partition

[Shane Bryzak]

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.
>
>> --
>> Bill Burke
>> JBoss, a division of Red Hat
>> http://bill.burkecentral.com
>>
> _______________________________________________
> security-dev mailing list
> security-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/security-dev