Perplexities about Seam 3 and picketlink

[lucaster.luca.cavagnoli.gmail.com]

I'm getting my hands dirty with Seam Security 3 and I am studying the new identity model by analyzing the idmconsole example. I noticed some of strange things though:

1. Seam Security documentation mentions the following method:

Group groupName = pm.createGroup("Group name", "Group type");

Apparently, it adds just a row in IdentityObject with the following values:

('Group name', SELECT id FROM IdentityObjectType WHERE name = 'group type')

Moreover, if IdentityObjectType doesn't already have a row with name = Group type, the ID in the new IdentityObject row is set to null.

The method createGroup() can also be abused by creating a group with 'USER' as GroupType, despite 'USER' was the identity object type chosen to represent users, not groups.

In short, the behaviour of the createGroup() doesn't match the semantics that one would expect.

2. The method persistenceManager.findGroup() has the same symptoms. If I invoke findGroup(USER), it returns a list of Group objects which are actually the users of my application! My users are magically transformed into groups!

In short, there's no way to make true, clear distinction between users and groups in the model, and the two methods I tested perform no check whatsoever.

3. Instead, the method persistenceManager.findUser(IdentitySearchCriteria isc) seems to perform the following query:

SELECT FROM IdentityObject WHERE id IN (SELECT id FROM IdentityObjectType WHERE name =  'USER')

which implies that users must be defined by the identity object type 'USER'; but this is not coherent with the behaviour of the other two aforementioned methods.

Can someone help me understand all this?

[lucaster.luca.cavagnoli.gmail.com]

At point no. 3 I wrote

persistenceManager.findUser(IdentitySearchCriteria isc)

instead, it should be

persistenceManager.findUser(String groupType)

Please add an Edit function to this forum!

[shane.bryzak]

Luca Cavagnoli wrote on Oct 04, 2011 05:02:


I'm getting my hands dirty with Seam Security 3 and I am studying the new identity model by analyzing the idmconsole example. I noticed some of strange things though:

1. Seam Security documentation mentions the following method:

Group groupName = pm.createGroup("Group name", "Group type");

Apparently, it adds just a row in IdentityObject with the following values:

('Group name', SELECT id FROM IdentityObjectType WHERE name = 'group type')

Moreover, if IdentityObjectType doesn't already have a row with name = Group type, the ID in the new IdentityObject row is set to null.

That sounds like a bug, JpaIdentityStore should probably create the row in the IdentityObjectType table if it doesn't exist.  The workaround is to just create all the IdentityObjectType entries that your application is going to be using up front.

The method createGroup() can also be abused by creating a group with 'USER' as GroupType, despite 'USER' was the identity object type chosen to represent users, not groups.

Well I don't see how it can be abused, considering it should only be admin level users that can manage groups or users anyway.  We should probably include some protection for this, by preventing a group from being created with the 'USER' group type.

In short, the behaviour of the createGroup() doesn't match the semantics that one would expect.

The semantics are described in the following docs:

http://anonsvn.jboss.org/repos/picketlink/idm/downloads/docs/1.0.0.GA/ReferenceGuide/en-US/html_single/index.html

I would say the behaviour matches perfectly, however as you have pointed out there are a couple of bugs we need to address.

2. The method persistenceManager.findGroup() has the same symptoms. If I invoke findGroup(USER), it returns a list of Group objects which are actually the users of my application! My users are magically transformed into groups!

In short, there's no way to make true, clear distinction between users and groups in the model, and the two methods I tested perform no check whatsoever.

Once again, we should probably exclude 'USER' from the list of types that are searched for.

3. Instead, the method persistenceManager.findUser(IdentitySearchCriteria isc) seems to perform the following query:

SELECT FROM IdentityObject WHERE id IN (SELECT id FROM IdentityObjectType WHERE name =  'USER')

which implies that users must be defined by the identity object type 'USER'; but this is not coherent with the behaviour of the other two aforementioned methods.

That query is correct. If you raise an issue in JIRA, I'll try to get the protection added to JpaIdentityStore for the next release.

[lucaster.luca.cavagnoli.gmail.com]

Shane Bryzak wrote on Oct 04, 2011 18:54:

That sounds like a bug, JpaIdentityStore should probably create the row in the IdentityObjectType table if it doesn't exist.  The workaround is to just create all the IdentityObjectType entries that your application is going to be using up front.

Thanks, Shane! I was not seeing double. I will try the workaround you suggest.

The method createGroup() can also be abused by creating a group with 'USER' as GroupType, despite 'USER' was the identity object type chosen to represent users, not groups.

Well I don't see how it can be abused, considering it should only be admin level users that can manage groups or users anyway.  We should probably include some protection for this, by preventing a group from being created with the 'USER' group type.

I agree. In the PicketLink documentation you gave me the link to, I found this:

At the SPI level both Group and User are mapped as IdentityObject. What differentiate them is the IdentityObjectType. IdentityObjectType "USER" is mapped to represent User objects while other are mapped to represent different Group types names.

It suggests that, hardcodedly, all identity objects with identity object type USER are considered as users, while identity objects with other identity object types are treated as groups.
So, there is an explanation in the documentation; I only wish such explanation would be included in the API Javadoc as well!

By the way, what's with the ginormous images? O_o

If you raise an issue in JIRA, I'll try to get the protection added to JpaIdentityStore for the next release.

I'll file a JIRA.

Thanks!

[lucaster.luca.cavagnoli.gmail.com]

By the way, in the menu on the left there is a link to the Seam 2 JIRA, but there's no link to the Seam 3 JIRA.

[lucaster.luca.cavagnoli.gmail.com]

I filed a JIRA:

https://issues.jboss.org/browse/SEAM-102

I choose 3.0.0.Final as affeted version because it didn't allow me to choose 3.1.0.Beta2, which I am actually using.

I'm using 3.1.0.Beta2 because with 3.0.0.Final the idmconsole example doesn't work with JBoss AS 7.

[shane.bryzak]

Thanks Luca, I've moved the issue to the Seam Security project in JIRA:

https://issues.jboss.org/browse/SEAMSECURITY-108