[security-dev] deleting a partition

[Bill Burke]

Partition support looked awkward like it was band-aided onto the API, 
some refactoring should be done.  Which is fine.  Resteasy has and has 
had some ugly code over the years and I know how it is.   Without 
partition CRUD though, I"m just not going to be able to use Picketlink. 
  It would be cool to nail down the User API very soon and have at least 
non-federated partition CRUD working, or I'm just screwed.

I also have a need for partitions to have attributes associated with 
them.  For example, my concept of a Realm has:

* key pair associated with it
* list of credentials a new user has to define
* token and access code default lifetimes
* and a few other pieces of minor data

Same goes for my use of Tiers.  Is this what you mean by partition 
configuration state?  Right now I'm creating an Agent and storing stuff 
there.

On 6/14/2013 7:22 PM, Shane Bryzak wrote:
> 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
>
> _______________________________________________
> security-dev mailing list
> security-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/security-dev
>

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com