Archive for the ‘Directory Services’ Category

Bug Blog 9: WebCenter Analytics Timeouts

Wednesday, January 26th, 2011

In our last post, we touched on the unusual nature of BEA’s acquisition of Plumtree, and how BEA largely kept the portal product lines separate with ALUI and WLP.  But that’s not a completely fair assertion: BEA did have a longer-term goal, integrating the two portal “front-ends” through various back-end tricks (such as Ensemble and WSRP).  Similarly, while you may have read that post as a somewhat bleak assessment that my opinion is WCI is dying a slow, painful death, in reality Oracle has stated plans to provide integration services between the products through similar means.  So you could use a WCI front-end with integration through Ensemble and WSRP to other WebCenter Services such as Blogs and Wikis.

The reality, though, is that these types integrations take time – and sometimes, lots of it.  As evidence of this, look no further than Aqualogic Analytics.  When BEA acquired Plumtree, one of the gaping holes in WLP was Analytics, or usage reporting of the product.  Plumtree Analytics was becoming a solid product, but it was very tightly integrated into the Plumtree portal.  So the decision was made to try and abstract some of the major pieces out, with the thinking that these abstractions could be useful elsewhere.  For example, the ill-fated Security Services (once used by the also ill-fated PEP line and now just built into Analytics) and the existing Directory Services came of this integration attempt.  The idea was that by abstracting out security and user management:

  1. These services would be available to other applications that were developed down the line
  2. Analytics would be more compatible with WebLogic Portal, which also had an LDAP repository to access user and group information

While I think that if more time had been available for the integration to become more seamless, the problem is that no one won in this attempt because it was aborted too early.  I have no idea whether WLP still supports Analytics integration, the old Security Services are now just built into the product as a phenomenally complicated set of DB tables that make little sense, and Directory Services are a dramatically inefficient way to access user and group information.

Case in point – I’ve had a couple of clients report Analytics timeouts for some users, but other users were seeing the proper report:

How does this relate to the whole Plumtree/BEA/Oracle integration saga? The old Plumtree Analytics application used a SQL query called something like QUERY_USER_FLATTENED_GROUPS.  Basically, this was a Plumtree Portal-specific SQL query that, given a user ID, would spit out all nested groups that that user was a member of.  So if a user was a member group A, and Group A was a member of Group B, the query would return both Group A and B.

The ALUI version of Analytics, though, utilized Directory Services so that group membership didn’t need to come from PT-specific SQL queries.  It could come from generic LDAP queries.  The problem is, LDAP doesn’t have a mechanism like QUERY_USER_FLATTENED_GROUPS, so for any given user, Analytics needs to query LDAP for the groups a user is in.  And then, Analytics needs to check to see which groups THOSE groups are a member of.  And so on, and so on.  You’d be surprised – through inheritance, you may be a member of thousands of groups, and rather than a single SQL query, you’re now dealing with tens of thousands of LDAP calls.

Bottom line:  Integrations and product convergence can work, but they’re phenomenally complicated, because every piece of abstraction added can cause unanticipated side effects.  Which is probably why Oracle is taking this whole process pretty slowly.

Full Bug Report after the break for your convenience. (more…)

A Closer Look at WCI Directory Services

Saturday, May 15th, 2010

By now, you’re probably aware that WebCenter comes with an LDAP Directory Service, which has been shipping since ALUI 6.5 and poked around in with Softerra’s LDAP Browser.

I’ve been working on developing a PEI to allow users to log into any auth source without having to select one on the login form, and my dev environment didn’t have access to an LDAP or Active Directory server.  Then I realized that I did, in fact have one – it’s provided by the portal itself.

So, I used the LDAP Browser to log in with my admin credentials (user name for Administrator: cn=Administrator,dc=bea,dc=com):

… and poked around the directory to get the appropriate User and Group Query Base and Filter, plus some other attributes.  I then set up an LDAP auth source in my portal with the following settings:

… and viola! After synching the users (with some errors in the logs because you’re basically creating users with identical names as users that already exist in the portal), I was able to log in using a local portal account, but via the LDAP AWS auth source:

Practical? No.  Useful if you’re trying to create a test auth source and don’t have an LDAP or ActiveDirectory server lying around?  Yup.