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