This blog entry comes from an email thread I had with a fellow BEA colleague. We traded a number of emails - he asked a lot of great questions about how WebLogic Portal (WLP) supports various security features. Since WLP relies heavily on WebLogic Server for those features, my answers apply to WebLogic in general and not just Portal. I am posting the email thread here because I think that this discussion might be of interest to others.
NOTE: this blog entry was originally posted September 22nd, 2007 on my previous blogging system (dev2dev.bea.com).
Before I show the thread, I should provide a glossary of abbreviations and concepts:
- WLS: WebLogic Server, the J2EE application server that most people associate with the name "WebLogic"
- WLP: WebLogic Portal, the J2EE portal product built on top of WLS
- CSS: in this context, not cascading style sheets. Common Security Service is the componentized security package that WLS uses for security.
- SSPI: the pluggable security subsystem provided by CSS to WLS
- ATN: authentication, which refers to the process of verifying who a user is (with a password perhaps)
- ATZ: authorization, which refers to the process of deciding whether the authenticated user has the privilege to perform a certain action
- UUP: a WLP feature that aggregates profile information for a user from a variety of backend sources using a plugin architecture
- Internal LDAP: an LDAP repository embedded in CSS historically used for some default SSPI providers
Discussion Thread
From: Colleague
Quick follow-up to our discussion in the hall at BEAWorld, you said that WLP wants to stop using the internal LDAP server altogether and use the database instead. I forgot, though, did you say that had already happened in a previous release, or is that slated for the next release?
From: PJL
Yes and no.
For ATN, WLP does not use internal LDAP. WLP switched to the WLS/CSS provided SQLAuthenticator in WLP 9.2. This does not mean that customers must use it, it is merely the default. A customer may choose to toss the SQL ATN provider and plug in an LDAP, Active Directory, etc. provider instead.
Here is the WLS doc reference to SQL Authenticator: Configuring RDBMS Authentication Providers
As for ATZ (WLP entitlements and delegated administration), we rely on the default ATZ provider from WLS, which in turn uses the internal LDAP store. Currently, we are tightly bound to the default ATZ provider for various reasons, and so WLP therefore has a hard dependency on internal LDAP. This is not ideal, and so WLP wants to eliminate the internal LDAP dependency.
The forthcoming solution to this problem is for WLS to support a database as the backend store for the default ATZ provider. They should have this in the next WLS version (but no promises folks!), and so we will pick it up in a future release beyond Flatirons (the next WLP release).
From: Colleague
Right, makes sense. A couple more questions:
Can customers configure more than one ATN provider, e.g. extranet users in SQL and employees in Active Directory, is that a supported WLP configuration?
Do documents stored in WLP's virtual content repository (VCR) use the default ATZ provider as well?
Where does the Unified User Profile (UUP) fit into this picture?
From: PJL
>> Can customers configure more than one ATN provider, e.g. extranet users in SQL and employees in AD, is that a supported WLP configuration?
Yes, and you can do logic like AND and OR via the JAAS control flags (this is WLS/CSS doing that, not WLP).
>> Do documents stored in WLP's virtual content repository (VCR) use the default ATZ provider as well?
Yes, Entitlements defined on VCR documents are stored in the default ATZ provider. The documents and metadata themselves are in the WLP database if the BEA Repo is being used, or in third party systems like Documentum or Sharepoint.
>> Where does the Unified User Profile (UUP) fit into this picture?
Profile is the third leg to this: ATN, ATZ, and Profile. For WLP, all three are independent, and linked together just by username. So ATN could come from Active Directory, whereas profile can be aggregated from, for example, a mainframe, LDAP, and Siebel via UUP. WLP passes the UUP plugins the username that was authenticated, and then each plugin is responsible for retrieving the correct profile info.
From: Colleague
One piece I'm still a bit fuzzy on is how groups fit into this whole picture, I've been reading this section on edocs:
Adding and Managing Groups (WLP docs)
It sounds like WLP periodically syncs group info from the providers into some local store, which I'm guessing is the default RDBMS. Is that correct?
From: PJL
Good question.
Actually WLP doesn't really maintain its own group mapping. The ATN providers provided by WLS are responsible for doing that. We do some caching of the group tree because it can be expensive to build, so that is what those docs are talking about. But we don't write that in-memory cached tree out to the database or file system.
To see how an ATN provider is involved in group membership, look at how the SQL Authenticator gets configured as an example:
SQL Authenticator Configuration help
You can see that it has methods for managing group relationships. How this happens at runtime is a deeper dive into the WLS/CSS SSPI ...
WLS/CSS authentication providers have two components - the JAAS code that actually performs the authentication, and then a set of "mbeans" that the provider chooses to implement. Most of the mbeans are optional to implement. Here is the list for ATN providers which provide the manageability around users and groups:
SSPI MBean Quick Reference
- GroupEditor Create a group. If the group already exists, an exception is thrown.
- GroupMemberLister List a group's members.
- GroupReader Read data about groups.
- GroupRemover Remove groups.
- MemberGroupLister List the groups containing a user or a group.
- UserEditor Create, edit and remove users.
- UserPasswordEditor Change a user's password.
- UserReader Read data about users.
- UserRemover Remove users.
So WLP uses methods from the GroupReader and GroupMemberListers mbeans on the ATN provider to have access to group membership. The SQL Authenticator implements the GroupReader and GroupMemberLister mbeans by using those SQL queries. The LDAP ATN provider GroupReader and GroupMemberLister mbeans derives Group structure from the directory structure.
That's a little abstract - it sometimes helps to see the code. Here is the javadoc for GroupReader and GroupMemberLister java interfaces that the ATN providers implement:
So WLP is not really managing it's own group repository, it's the ATN Providers that are storing that information. A little complicated, I know.
From: Colleague
So does the LDAP ATN provider support the GroupEditor as well? That is, can you write group membership changes back into external LDAP repositories?
From: PJL
The LDAP ATN provider that WLS/CSS provides is read only. You can see what mbeans it implements by looking here:
- Navigate to BEA-HOME\wlserver_10.0\server\lib\mbeantypes
- Open cssWlSecurityProviders.jar
- Find the .xml file that is associated with the provider you care about, in this case LDAPAuthenticator.xml
- In that xml file, you will see the mbean interfaces that it implements listed:
<MBeanType
Name = "LDAPAuthenticator"
DisplayName = "LDAPAuthenticator"
Package =
"weblogic.security.providers.authentication"
Extends =
"weblogic.security.providers.authentication.LoginExceptionPropagator"
Implements =
"weblogic.management.utils.LDAPServer,
weblogic.management.security.authentication.UserReader,
weblogic.management.security.authentication.GroupReader,
weblogic.management.security.authentication.GroupMemberLister,
weblogic.management.security.authentication.MemberGroupLister,
weblogic.management.security.authentication.UserPasswordEditor,
weblogic.management.security.authentication.GroupMembershipHierarchyCache"
PersistPolicy = "OnUpdate"
>
Since it does not include GroupEditor or UserEditor, you can infer that it is a read-only provider (aside from password). If you are a WLP customer, another way to see which mbeans are implemented for each ATN provider is through the Portal Administrator tool (PAT). Because the PAT disables certain user/group management functions in the tool depending on what mbeans are implemented on the selected provider, the PAT provides UI to show which mbeans are implemented. See the image below:
From: Colleague
Also, is there any way to create a group that includes members from more than one provider, e.g. "John" from the DB and "Bob" from LDAP? Or do you need to use roles for that scenario?
From: PJL
Yes, group membership is aggregated from the collection of installer providers. Multiple providers can contribute membership associations to a single group. Or how about this question: can "Bob" be authenticated by the SQL ATN provider, and put into the "Human Resources" group via the LDAP provider? I believe this does work.
More information...
I would encourage you to use these resources to learn more about WebLogic Security:
Comments from original blog
Carlo -
OK, good to hear that it worked for you!
We don't certify any other authorizers/role mappers. It sounds like at least some use cases work.
Where my comment comes from is the fact that historically we had code that went around the SSPI and directly to embedded LDAP. Based on your feedback, I looked through the current code base and didn't find anything like that. I will check with the engineer who owns that code to verify. So I might have been wrong in saying it will not work at all.
I did find a couple of places where you may see odd behavior:
- There is code to check if the Admin server is running when doing any policy updates. This is because embedded LDAP relies on the Admin server for distribution of updates in the embedded LDAP replicates in a cluster. You will probably see errors in your logs if your Admin server is down, even if you aren't using embedded LDAP.
- WLP has a class called LDAPChangeListener which flushes a role policy cache entry if a role policy has been updated in embedded LDAP. If you are running in a cluster, and are not using embedded LDAP, it looks like you will have to redeploy the application to get the updated role policy recognized across the cluster. Can you verify if this is true with your system?
Thanks for the correction!
Regards - PJL
Posted by: plaird on January 2, 2008 at 11:31 PM
Hi Peter thank you for your answer. Why should the protection of WLP assets (e.g. Portlets) not work? I have written my own XACML Authorizer (based on the OpenSource SUN XACML implementation) and a RoleMapper also and it works. If WLP correctly use the WebLogic Security framework, it should work and fortunately it does ;-) Did you mean that in a future version it will not work? This scaries me because we are strongly basing our security on these implementations (and on XACML). ciao carlo
Posted by: cdrcdr on December 21, 2007 at 6:19 AM
Carlo -
What types of resources do you wish to manage with the Role and Access policies? Do you wish to entitle WLP assets such as portlets and content items, or JEE assets? For JEE assets, you could use an external repository by plugging in additional providers into the SSPI.
But as for WLP assets, first the bad news. You will not be able to replace the entitlement engine that WLP uses for WLP assets. But I would actually argue that you don't want to replace the entitlements engine, you really want to replace the runtime policy repository. Unfortunately, WLP does not currently support storing WLP policies in anything other than embedded LDAP, except in one case (see ALES link below).
While this isn't great news, WLP will at least remove the embedded LDAP dependency when WLP ships on WLS 10.3. You will be able to store your runtime ploicy repository in a DB then.
Now for the good news...
There is a solution available today. I would encourage you to look at ALES, because it does what you want to do. It centralizes role and policy management in an external repository.
But if ALES is not suitable, there is another potential workaround here. It is possible to *manage* the policies in your external system, and then periodically sync the policies into the *runtime* repository (the embedded LDAP now, DB in a later release). An issue will be figuring out how to author WLP policies; specifically being able to create the WLP asset resource strings. Also, you will need to figure out how to allow for the external management tool to discover the set of manageable resources that do not already have policies.
Hope this helps... PJL
Posted by: plaird on December 14, 2007 at 8:34 AM
Great article! One question: we have our RoleAssignmentPolicies (XACML)as well as the AccessPolicies (XACML)in differnet repositories: we need to wtite our own XACML based authorizer (and Entitlements engine) and (possibly) remove the BEA one from the realm. Would it be possible? There would be problem/limitation doing so? regards carlo
Posted by: cdrcdr on December 13, 2007 at 5:26 AM
Josh - I haven't worked with the LDAP providers in years, so I can't comment on the specifics. But in the follow up blog entry to this one, I explain how to dive into the cssWlSecurityProviders.jar to find the implementations of the BEA Atn Providers and how providers often extend other providers.
By doing that now, I see that the BEA IPlanetAuthenticator extends the base LDAPAutenticator, which already implements UserEditor and GroupEditor. If you wish to implement custom logic for those mbeans, extending the BEA IPlanetAuthenticator provider is probably the way to go. You would create a subclass overriding the UserEditor and GroupEditor methods as necessary, and then wire it up using an XML descriptor.
Look to the IPlanetAuthenticator itself as an example of how to wire up a provider subclass. Put your custom atn provider in its own JAR in the same directory as cssWlSecurityProviders.jar and you should be good to go.
PJL
Posted by: plaird on October 18, 2007 at 9:15 AM
Hi Peter, What steps would I need to take to add the UserEditor and GroupEditor MBeans to the IPlanetAuthenticator? If I intend for users to be created using a custom objectClass defined in the iPlanet Directory Server that has custom attributes, I'm assuming that I'll have to customize the MBean to do this. Is this correct? Thanks, Josh
Posted by: joshbrookes on October 17, 2007 at 11:28 AM
Hi Luciano - yes, this is why we are keen to eliminate internal LDAP as the repository for ATZ. The best way is to have a Propagation inventory that contains a backup of your policies. In that case, you can wipe it clean, and then reapply the inventory (this is not so simple if you do admin work in production, you will need to be careful about the merge). Also, a colleague was looking into a more fine grained fix (directly updating internal LDAP to fix the problem records). I don't know off-hand where he ended up with that - I will point him to this entry. Ciao, PJL
Posted by: plaird on September 24, 2007 at 11:40 PM
Hello Peter, very interesting reading. I wish that more articles like this one could be published by Bea. I take advantage of this blog to ask you a question: we have hit on a Portal9.2Mp1 production installation the infamous out of sync between embedded Ldap and the portal db (p13n tables). Result, Delegated Admin page fails with a NPE and Entitlements also are not very well. It's easy to fix this problem in a non prod environment (wipe p13n tables, wipe ldap files) but which is the recommended way to deal with this issue in a clustered production environment? Thanls a lot Luciano Fiandesio
Posted by: koevet on September 24, 2007 at 11:21 PM
