[security-dev] deleting a partition

[Shane Bryzak]

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 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
> _______________________________________________
> security-dev mailing list
> security-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/security-dev