[jboss-jira] [JBoss JIRA] Commented: (JBPORTAL-1499) CMSAdminPortlet should use Users/Roles Module and not direct HQL query

[Sohil Shah (JIRA)]

    [ http://jira.jboss.com/jira/browse/JBPORTAL-1499?page=comments#action_12368592 ] 
            
Sohil Shah commented on JBPORTAL-1499:
--------------------------------------

>> is the CMSAdminPortlet working with a LDAP user repository ?
>>I guess not, if the LDAP Users/Roles Module does not use the JBossPortal users tables (no replication between ldap and the usual portal u/r tables). 

Actually, in the LDAP environment, the cms security system still works becuase it falls back to data extraction via the UserModule/RolesModule Identity components.

The issue with the cms security engine is performance. Security is dynamic and is enforced on all cms requests, so the security system kicks in all the time.

So, if we don't use security meta data caching in a cluster safe manner (which we get by the use of Hibernate), our performance would suffer greatly under heavy loads.


Hence, for the core DB Identity Module, the permission lookup for a user, is done via an optimized hibernate query.  The query is optimized to deal with the many-to-many relation between Permission/Role, Permission/User, and Role/User.
Without that, it results in multiple calls to the Identity Module to grab the same information which does not scale in a high load environment


Having said that, for the non DB Identity Module like LDAPUserModule, your custom UserModule which splits data into different databases, we dont have a choice but to reply on the IdentityModule interfaces to extract this data.

However, I am not too sure about the scalability of these since, any data caching etc now becomes an implementation detail of the Modules, so if they don't do that, performance will suffer




> CMSAdminPortlet should use Users/Roles Module and not direct HQL query
> ----------------------------------------------------------------------
>
>                 Key: JBPORTAL-1499
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1499
>             Project: JBoss Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Portal CMS, Portal Identity
>    Affects Versions: 2.6.CR2
>         Environment: JBP2.6 CR2 (bundle package with JBoss AS 4.0.5)
>            Reporter: Antoine Herzog
>         Assigned To: Sohil Shah
>             Fix For: 2.8 Final, 2.6.1 Final
>
>
> When separating the CMS tables and the Users/Roles tables in two datasources, I found this :
> when trying to go to the CmsAdmin (CMSAdminPortlet), I got "access denied" and this exception :
> 2007-06-22 13:56:11,015 DEBUG [org.hibernate.jdbc.ConnectionManager] releasing JDBC connection [ (open PreparedStatements: 0, globally: 0) (open ResultSets: 0, globally: 0)]
> 2007-06-22 13:56:11,015 DEBUG [org.hibernate.util.JDBCExceptionReporter] could not execute query [SELECT * from jbp_cms_perm p,jbp_cms_perm_role r,jbp_role_membership m,jbp_roles roles,jbp_users users WHERE p.id=r.cms_perm_id AND r.role_id=roles.jbp_name AND m.jbp_rid=roles.jbp_rid AND m.jbp_uid=users.jbp_uid AND users.jbp_uname=?]
> com.mysql.jdbc.exceptions.MySQLSyntaxErrorException: Table 'jbptl_cms.jbp_role_membership' doesn't exist
> 	at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:936)
> 	at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:2870)
> and also :
> 13:56:11,015 WARN  [JDBCExceptionReporter] SQL Error: 1146, SQLState: 42S02
> 13:56:11,015 ERROR [JDBCExceptionReporter] Table 'jbptl_cms.jbp_role_membership' doesn't exist
> Datasource for Users/Roles : jbptl_users
> Datasource for CMS : jbptl_cms
> I did not look precisely to the CMSAdminPortlet code, but obviously, the HQL query mix the tables of the CMS and the tables of the Users/Roles.
> Every thing works fine in the native version of portal, but it can't work with my production or architectures needs. I guess usual needs : separation of what is not really tied up.
> I guess the CMS service should check the security using the Users and Roles Modules, with some java level code, 
> and not directly the Hibernate queries that manipulate the data.
> With this, we cannot have a specific Users/Roles Module, with other persistence than in the same database as the CMS.
> => is the CMSAdminPortlet working with a LDAP user repository ?
> I guess not, if the LDAP Users/Roles Module does not use the JBossPortal users tables (no replication between ldap and the usual portal u/r tables).
> => if we need a specific user database (legacy), with a home made Users/Roles Module that take the data from another legacy datasource, the CMSAdminPortlet and CMS Security won't work
> => general architecture design : the users data are in a database, the cms data are in another one : more clean for managing all that stuff (backup, restore if crash, maintenance against user data or cms data, etc...).
> Feature :
>  - Enhance the CMSService with some Security API that provide all the basic security features to check the permission, doing it with java and Users/Roles Module, not with hibernate.
>  - Or (I think is better) provide a Users/Roles Security service, that provide the usual security checking features (isInRole(), etc...). This would be above the Users/Roles Module
> I guess the portal needs the same kind of service : set a common service interface for both needs.
> Even if there are no time to decide and build these security interfaces for 2.6, it would be great to have the CMSAdminPortlet working with some CMS and Users/Roles separate DataSources.
> I will manage with only one DS for dev, but would be great to have it for the upgrade of our prod version (now in JBP2.4.1).
> Unfortunately, I have no time to do this now (huge work to have the next version of our portal ready asap... and I'd rather use right now the 2.6 than keep 2.4 for all this...).
> Thanks,
> Antoine

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira