This is a forum post that I put out on the Yahoo! user forum for Content Server. I had a couple of folks to tell me it was worth blogging, so here it is.
The original question came from a user passing a SOAP request with seemingly the correct credentials, but the request failing to return any content other than content accessible to anonymous users. The poster noted that if they reordered their JPS user providers within WLS, the issue cleared up for some users, but now appeared for other users. Depending on the order of appearance of the providers in WLS, the users were being dictated as to who could see more than publicly available content.
So the response:
This issue is a known issue with the WebLogic JPS user provider code. The first
listed provider will have all user data returned (like roles and groups, along
with extended attributes like email address). Any subsequent provider will only
validate the user login, and not return any extended data. Swapping the order
of the providers results in the new top listed provider correctly returning all
expected attributes (as you have noted).
OK, so what's the solution? There are several, all with certain pain involved.
1 - Invest in Oracle Virtual Directory (OVD). OVD can gather all of the roles,
groups, and extended attributes from disparate LDAP repositories like OID,
Active Directory, OpenLDAP, etc, and present the data to WLS in a single
provider. The pain here is additional cost, but this is the supposed "ultimate"
2 - If you are still reading this, the cost is a big pain point. If you are
running PS3 or later (and I would stress "later" here, because this fix in PS3
was not completely tested), you can emulate a similar OVD experience with a
relatively simple configuration change in Enterprise Manager
("virtualize=true"). Look here for the
html). The pain here comes if your domain contains a WebCenter
self-registration process. I've seen the self-register function fail with this
setting in place. Your mileage may vary.
3 - Still reading? The virtualize setting must be problematic.
-- Put the OID provider first, and create a new group called "Administrators"
in the OID role container that you defined in WLS.
-- Add any users that need admin access to this OID group. With the OID
provider listed first, it should "just work".
4 - Already have "Administrators" group created, but can't add the users due to
company policy? That's why you're still reading...
There is one more "trick" here. The pain here -- "Is this approach supported?"
and "I don't know if other WebCenter applications (BAM, SOA, etc) will still
complain with the mis-ordered provider." If this is a UCM only domain, you may
-- Log into UCM, and go into User Manager.
-- Change the weblogic user from "external" to "local", and give the weblogic
user the appropriate roles and accounts in the applet.
-- List OID first in the provider list. Log in as "weblogic" anyway.
Surprisingly, since you've already "authenticated" in WLS, the "authorization"
for weblogic will now come from UCM.
5 - Least favorite option - disable the JPS user provider in UCM, and create a
10g style LDAP provider to OID. I'm not sure if that is possible with OID, but
is achievable with AD. Again, your mileage may vary.