5:38 p.m.
I'm looking at how to delete a partition and its not that simple. Is
this good enough? First I delete all Agents, users, groups, and roles.
Relationships should be deleted too right?
List<AttributedType> toRemove = new ArrayList<AttributedType>();
{
IdentityQuery<IdentityType> query = new
DefaultIdentityQuery(context, Agent.class, this);
List<IdentityType> resultSet = fetchQueryResults(context,
query);
toRemove.addAll(resultSet);
}
{
IdentityQuery<IdentityType> query = new
DefaultIdentityQuery(context, User.class, this);
List<IdentityType> resultSet = fetchQueryResults(context,
query);
toRemove.addAll(resultSet);
}
{
IdentityQuery<IdentityType> query = new
DefaultIdentityQuery(context, Group.class, this);
List<IdentityType> resultSet = fetchQueryResults(context,
query);
toRemove.addAll(resultSet);
}
{
IdentityQuery<IdentityType> query = new
DefaultIdentityQuery(context, Role.class, this);
List<IdentityType> resultSet = fetchQueryResults(context,
query);
toRemove.addAll(resultSet);
}
I do this all at the IdentityStore level, after this, I delete the
partition entry using IdentityStore specific routines.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
6:10 p.m.
IMO, we should not delete u/g/r and raise an exception instead. Telling the user that a
partition can not be removed because of the associated data (u/r/g).
If he wants to remove, he must remove first all related identity data.
Btw, we were doing that before the last refactoring to the Partition API.
----- Original Message -----
From: "Bill Burke" <bburke(a)redhat.com>
To: security-dev(a)lists.jboss.org
Sent: Friday, June 14, 2013 12:38:12 PM
Subject: [security-dev] deleting a partition
I'm looking at how to delete a partition and its not that simple. Is
this good enough? First I delete all Agents, users, groups, and roles.
Relationships should be deleted too right?
List<AttributedType> toRemove = new ArrayList<AttributedType>();
{
IdentityQuery<IdentityType> query = new
DefaultIdentityQuery(context, Agent.class, this);
List<IdentityType> resultSet = fetchQueryResults(context,
query);
toRemove.addAll(resultSet);
}
{
IdentityQuery<IdentityType> query = new
DefaultIdentityQuery(context, User.class, this);
List<IdentityType> resultSet = fetchQueryResults(context,
query);
toRemove.addAll(resultSet);
}
{
IdentityQuery<IdentityType> query = new
DefaultIdentityQuery(context, Group.class, this);
List<IdentityType> resultSet = fetchQueryResults(context,
query);
toRemove.addAll(resultSet);
}
{
IdentityQuery<IdentityType> query = new
DefaultIdentityQuery(context, Role.class, this);
List<IdentityType> resultSet = fetchQueryResults(context,
query);
toRemove.addAll(resultSet);
}
I do this all at the IdentityStore level, after this, I delete the
partition entry using IdentityStore specific routines.
--
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
7:02 p.m.
I don't agree. What's your reasoning? At least in my case, because an
Application is going to be a Partition, i'll need to have an operation
somewhere that deletes the roles/role mappings somewhere.
On 6/14/2013 12:10 PM, Pedro Igor Silva wrote:
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
7:12 p.m.
I just don't think we should "automatically" do something like that. If you
want to delete them, you can do it by yourself.
This is a critical thing. Not sure if we should do that internally, but just allow users
to do it if they want.
You can query all u/r/g for a specific partition and delete them by yourself, using the
Query API.
----- 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 2:02:32 PM
Subject: Re: [security-dev] deleting a partition
I don't agree. What's your reasoning? At least in my case, because an
Application is going to be a Partition, i'll need to have an operation
somewhere that deletes the roles/role mappings somewhere.
On 6/14/2013 12:10 PM, Pedro Igor Silva wrote:
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
7:22 p.m.
You didn't really give a reason. From an admin perspective you will
want to delete a realm or partition, but the admin may not know exactly
what identity metadata was created. The admin UI implementation is
going to have to do this anyways, so might as well do it within IDM API.
On 6/14/2013 1:12 PM, Pedro Igor Silva wrote:
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
8:19 p.m.
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".
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
}
I understand your point and it is valid. My opinion is just we should leave that for
users.
----- 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 2:22:08 PM
Subject: Re: [security-dev] deleting a partition
You didn't really give a reason. From an admin perspective you will
want to delete a realm or partition, but the admin may not know exactly
what identity metadata was created. The admin UI implementation is
going to have to do this anyways, so might as well do it within IDM API.
On 6/14/2013 1:12 PM, Pedro Igor Silva wrote:
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
8:29 p.m.
On 6/14/2013 2:19 PM, Pedro Igor Silva wrote:
But again, you give no reason :) Sure its critical data, but everything
in the IDM is critical data.
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?
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?
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
8:58 p.m.
----- Original Message -----
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 ...
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...
Considering your usecase, yes.
1:09 a.m.
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:
1:22 a.m.
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:
3:29 a.m.
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:
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
3:01 a.m.
IDM API is a low level API not seen by most users. You're now requiring
the admin UI to have to know how to cleanly remove a realm.
On 6/14/2013 7:09 PM, Shane Bryzak wrote:
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
6:53 p.m.
I would agree with Bill, and I think this is a poor argument.
It's a bad argument, because despite the fact it's a dangerous thing to offer,
every single database out there offers the ability to do it. Furthermore, it's not a
parallel situation - this is a call the user would have to code, then compile the code,
and then execute.
If this were a user facing API, then maybe this argument might hold some water, but
it's not, it's going to be used inside an application. If we really feel we need
this, at least let's make it available, but implement some protection in some
configuration such as:
boolean partitionCRUD = true;
with an option to disable it (in which case the IDM would throw an exception if the
methods are called).
On 17 Jun 2013, at 16:28, Anil Saldhana <Anil.Saldhana(a)redhat.com> wrote:
1:07 a.m.
I don't think anyone's disagreeing that there should be an operation
that deletes a partition, the point I was simply trying to make was that
a) it *is* a dangerous operation (Bill asked for a reason, I gave one)
and b) we should educate our users as to this fact. I'm certainly not
arguing against it by any means, I just think we should perhaps place a
warning in the documentation or perhaps if we really wanted to,
demonstrate a suggested safety mechanism via a quickstart. I tend to
think a warning in the reference docs will be sufficient though.
On 18/06/13 02:53, Pete Muir wrote:
6:56 p.m.
Bill's pull request is still open.
https://github.com/picketlink/picketlink/pull/146
Any changes needed before merging?
On 06/17/2013 06:07 PM, Shane Bryzak wrote:
8:39 p.m.
I think Shane is waiting to merge with his PLINK-130 work.
----- Original Message -----
From: "Anil Saldhana" <Anil.Saldhana(a)redhat.com>
To: security-dev(a)lists.jboss.org
Sent: Wednesday, June 19, 2013 1:56:19 PM
Subject: Re: [security-dev] deleting a partition
Bill's pull request is still open.
https://github.com/picketlink/picketlink/pull/146
Any changes needed before merging?
On 06/17/2013 06:07 PM, Shane Bryzak wrote:
_______________________________________________
security-dev mailing list
security-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/security-dev
4287
days inactive
4292
days old
16 comments
5 participants
participants (5)
-
Anil Saldhana -
Bill Burke -
Pedro Igor Silva -
Pete Muir -
Shane Bryzak