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>
>> To: "Pedro Igor Silva" <psilva(a)redhat.com>
>> 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