Saturday, September 22, 2007

Discussion on WebLogic Security: Authentication Providers, Internal LDAP, JAAS, WebLogic Portal, Profile

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:

  1. Navigate to BEA-HOME\wlserver_10.0\server\lib\mbeantypes
  2. Open cssWlSecurityProviders.jar
  3. Find the .xml file that is associated with the provider you care about, in this case LDAPAuthenticator.xml
  4. 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:









wlpAtnProviderMbeans









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:

















Add to Technorati Favorites

























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










8 comments:

Afzal said...

Hi PJL,
I've been wondering about the portal administration tool. It seems that this is the only way the groups, users, visitor entitlements etc can be created and manipulated. But the PAT itself cannot place any specific restrictions on what a certain portal admin can or cannot do.. Is there any way that i can utilize the p13 functionality to create my custom administration console having my own business restrictions?

Peter Laird said...

Hi Afzalz,

Entitlement policies are defined in the Portal Admin Tool (PAT), but the tool itself is governed by Delegated Administration policies. As the name implies, it allows a super admin to delegate focused rights to lesser admins.

Example 1: DA can be used to restrict a certain admin user's rights to just a single desktop.

Example 2: DA can be used to give a content author rights to use the PAT for a certain set of folders.

Unknown said...

Hi JPL,

earlier in this discussion you stated that WLP 10.3 will remove the embedded LDAP dependency for storing policies. I am currently evaluating WLP 10.3 and for me it seems that the dependency still exists. Can you confirm my observations, or is possible to use a RDB (via configuration) for storing entitlement roles and policies with WLP 10.3?

edwardm said...

Hi Peter,

I use WLP 10.3 and need the following behaviour:
Not authenticated user can see pages in book wich contains portlets only available to be viewed to authenticated users.
When he tries to go to the page and view the portlets, the user should be redirected to login page.

I can restrict an access to specific portlet via PAT, but in this case the user just will not see the portlets without any redirect to login page.
Is it possible to somehow add redicerting to login page when Authorization process desides that the user is not allowed to view the portlet?
How one can do it?

Setting access via web.xml only be done to an URL, while Weblogic uses labels and these labeled URL are not checked during GET/POST.
Even if I prohibit an access to JSP pages which are used in portlets, they are still rendered and available to user if I use, for example, form-based authentication configured in web.xml.

Thank you in advance,
Eduard.

Peter Laird said...

Hi Eduard,

You'll probably want to implement some logic in a page backing file that detects if there are any visible portlets. If not, it will need to redirect to login page.

After getting a PageBackingContext in your backing file, you will likely invoke these methods on it:

WindowBackingContext.getRenderedChildrenWindowBackingContexts
BackingContext.sendRedirect()

Javadoc:

http://download.oracle.com/docs/cd/E13155_01/wlp/docs103/javadoc/com/bea/netuix/servlets/controls/page/PageBackingContext.html

Further help available on the active newsgroup, especially if you haven't implemented backing files before:

http://forums.oracle.com/forums/forum.jspa?forumID=573

Michael said...

Hi Peter,

Your emails are a bit lower level for us. We hope that there are some high level and straight forward procedures for us to achieve our goals as below:

We currently:

-use Microsoft AD for maintaning users and authenticating users to access our LAN.

-use Oracle Portal 10g for maintaining users, groups and roles and authorizing authenticated user for accessing our web applications. So, we double up users in MS AD and Portal admin. and double up user login, eg LAN and then Portal. Actually, as we make some of our Portal resources public, LAN login users can see the public Portal resources but not non-public one until they login Portal.

We are planning to:

-use MS AD for maintaning users, groups and roles and authenticating users to access our LAN.

-configure WLS 11g / WLP 11g to access users, groups and roles from MS AD and authorizing user for accessing our web applications. In another word, after users have logged into our LAN, they will not need to login to our Weblogic Portal again and web application access authorization will be controled transparently by user, group and role assignments in MS AD.

Our questions are:

-how to export user, group and role information from Oracle Portal 10g? This is convenient not mandatory.

-how to import the exported information into MS AD? This is convenient not mandatory.

-how to configure WLP 11g to avoid additional login and to authorize web application access? We have gone through WLS and WLP admin doc. but need some ideas how it works. The ideas from your emails are too lower level for us.

-how to configure WLP 11g to access Oracle 10g ADF applications?

Please advise some clues.

Thanks,

Michael

Peter Laird said...

Michael,

Since I am long gone from the WLP team, I would suggest you hit the forums in general. But some quick answers for you:

Q. [Anything about Oracle Portal]
While I served for a while during the Oracle regime, I never once touched that product. I won't be able to help with any of your migration questions.

Q. "how to configure WLP 11g to avoid additional login"

What you are looking for is called SPNEGO support with WebLogic Server (disregard anything that says WebLogic Enterprise Security, that was a different product since discontinued). Here is a good link to get you started:

http://download-llnw.oracle.com/docs/cd/E13222_01/wls/docs81/secmanage/sso.html

Q. how to configure WLP 11g...to authorize web application access

To get AD user and group mappings into the WebLogic Server container, you will need the AD Authentication Provider. If you can't find it, log into Metalink and you should be able to track that down.

Once you have the mappings in the WebLogic container, you will be able to define WLP "Entitlement Roles" that reference users and groups. You will then use those Roles to configure fine grained access control to your portals and portlets.

Q. [AD Roles in WLS]

I don't know what the AD Authentication Provider does with Roles defined in AD. You may not be able to reuse these in WLP, unless the Atn Provider converts them into Groups. The docs for the AD Atn Provider might give you some clues.

Q. "how to configure WLP 11g to access Oracle 10g ADF applications?"

This area was in a lot of flux when I left. But what you are looking for is the WSRP Producer implementation for ADF 10g. I don't recall how you license that piece of technology, and what installer contains it. But that is what you are looking for. Once you have that, you can bring the ADF 10G application into WLP as a portlet. Refer to WLP docs on WSRP for more info.

Regards, and congrats on your purchase of WLP. Its a great portal product.

Peter

Unknown said...

Hi Atul,
I'm trying to integrate Ping Federate in our WLP 10.3.
Portal has existing Authentication.Login mechanism taking username/password from form coming from JPF controller and then userProfile is created using username.
But now there would Ping Federate server talking to OAM and do authentication and just pass openToken to our application URL and we will read parameters from openToken like username but password will not be available and now how will we move ahead with current Authentication.login as it ask for password of user and only then creates user profile, but we dont have password and if we authentication then this is two way authentication once OAM and then portal authentication and profile creation.