You are here

Building a portal on new LP5.1

Submitted by zy001 on Fri, 10/11/2013 - 10:06

Hi guys,
Today, I am starting this block to record and share my journey of building and customising a new LP5.1 platform with all of you.

The goal:
To build a new dev LP5.1 with highly customised web interface, automated user provisioning process with external AD/LDAP/IM application, and highly independent service oriented portal framework to support portlet channels (based on current own framework and uPortal / JSP modle 2 channels).

3 tier install on Redhat VM in parallel deployment, with a DB in Oracle server.
Sharing LP LDAP with Banner XE

Where I am:
I have built the platform of LP5.1 -- upgrade approach. I have a working platform now and going to complete the following tasks.

1. EAS on CAS
2. User provisioning
3. Web layout/interface/style customization / re-design
4. Banner Integration CAS configuration
5. CAS configuration for Banner XE
6. re-write framework with Spring
7. re-write channels as portlets
8. testing: load test, UAT, etc.

I will write down all the issues / errors / solutions I have. Welcome to any comments / ideas / suggestions and help.

Thanks for reading


Luminis Version:


Hack Type:


1. decide your architecture
I know it is going to be a 3-tier system, but not sure how each component will sit in where. So, for my dev, I decide to put CAS and LDAP on one server, admin and my own framework on one, and portal on one.

2. prepare your servers
Due to personnel changes in our system team, my hardware preparation had taken mmmmmonths until I could be able to work on. I had been forced to rebuild it for a number of times due to the quality of the server built.

*make sure you have a 'clean' system to install LP5.* software.

3. building the platform
Got DBA defined a DB in Oracle first.
There are 2 ways to build the LP5.1: direct install or upgrade from LP5.0.4
Because, the LP5.1 wasn't there at the time I started this. So, I had to choose upgrade.

I did installing as root and run as luminis admin user approach. Apart from making file for each component by following the install guide, after installation, you may have to give admin user permission to execute files of LP platform, but keep 600 right for jmx.password on admin and portal servers.

Also, be aware of SSL cert thing:
. $CP_ROOT/.cprc
cd $CP_ROOT/products/java/jre/lib/security

keytool -import -keystore cacerts -alias cas_cert -file $CP_ROOT/install/cas.cert
keytool -list -v -keystore cacerts -alias cas_cert

For upgrading to LP5.1 from LP5.0.4, please follow the guide on:

Things are pretty easy, but take care of 'permissions.user.check.algorithm' business. Otherwise, you will have problem sometime later.

Now, restart the entire platform, you are in business for more fun stuff.

To be continue ....

I am currently working in the dark on this (well, kind of). I hope some people here can answer my questions in here. Thanks in advance.

My requirements on this are:
A. I want to build an automated provisioning process with our central AD this time. So user can have portal access immediately after AD account is created.
B. EAS on CAS, looking at our central AD
C. no password stored in Luminis

Options I have:
According to my reading, research and many questions to Ellucian, I think Ellucian offers 2 possible ways to achieve this:
1. LDI - ADAP (Active Directory Accounts Provisioning), so portal authenticates user against Banner, and provisioning user account between Banner and AD. Here, password must be synced between AD and Banner in real time! But, no sure yet.
Also, this is a bigger change to more than 1 system, probably it is too big to achieve easily, and it is against my original objectives / requirements. I am happy to provision user from Banner with LDI, but I want to do EAS without storing password. Can anybody help me on this?
2. lptool tool importing LDISP 2 XML file, I managed to get an sample XML file. But, I am not sure what some id values for in the XML. Such as: <datasource/>, <id/> of <sourcedid/>, and password attribute in <userid/>. What are they for? Can I ignore them? Anything to do with Bnner SSO at all?

<?xml version="1.0"?>
<!DOCTYPE enterprise SYSTEM "ldisp-2.0.dtd">
<properties lang="en">
<datasource>SUNGARDHE University SCT Banner</datasource>
<person recstatus="2">
<source>SUNGARDHE University SCT Banner</source>
<userid useridtype="Logon ID" password="asdf">usrnaveen</userid>
<userid useridtype="Email ID" password="asdf">usrnaveen</userid>
<userid useridtype="SCTID" password="asdf">usrnaveen</userid>

Do you know that?
Have a nice weekend, I had enough today, going home now..

It doesn't work, I got this:

-bash-3.2$ lptool importims -v users-1.xml
/usr/bin/env: groovy: No such file or directory

I have to wait for some time until my server admin can get it fixed. Anybody knows why?


Royal Holloway, London

I'm trying to get a handle on how CAS and Luminis interact so I was interested in your post, and while I don't know much about what you're doing (yet!), I do know about the sourcedid.source and that come from Banner.

There is a table in Banner ICMGR.ICBIRULE. When a person event is sent from Banner to Luminis the sourcedid.source comes from the ICMGR.ICBIRULE.ICBIRULE_INTEGRATION_SOURCE column in the Banner instance Luminis is attached to.

In an institution I used to work for, we had one source identifier value for our production Luminis (i.e. Banner PROD) and after we'd refresh our test instances we'd overwrite that (with a script as part of our refresh process) to a static value we had for the testing instance (i.e. Banner PPRD). When an event fires for a person that already exists in Luminis the incoming source must match the source already there for the person or it will will cause a source mismatch event error and the event will not update Luminis.

This was done so that you could not accidentally update your production Luminis with changes from a testing instance of Banner. If you've cloned Luminis from a production copy and you need to know what the current source is, try this:

cptool get user xxxxxxx SourcedID.Source
Banner PROD

If this value does not match what's in the Banner ICBIRULE table for the Banner instance you're working with, then you'll either need to empty the Luminis LDAP and refresh from the testing Banner instance or update the SourcedID.Source value for each person to match the ICBIRULE value. We found it was easiest just to purge and then recreate the people from the test instance with a load file. Because we'd change the ICBIRULE record at Banner refresh time, and our population in Luminis test remained static, the values would match and we'd have no event rejections.

The is a value, similar to a pidm, that is unique to a person. There is a Banner table GENERAL.GOBSRID and the records in this table have only two columns: GOBSRID_PIDM and GOBSRID_SOURCED_ID. This is the only Banner table that SOURCED_ID appears in (although it is visible on the GOATPAD form).

While unlikely, it is possible for a person to have a different SOURCED_ID in a testing instance than in production where the GOBTPAC_EXTERNAL_USER (what we call the netid) for the person is the same. This recently happened when I started working at a new institution and my records were created by hand in production and all the test instances that did not have refreshes scheduled in the near future. My netid is the same but I have a different Banner ID, PIDM and SOURCED_ID in each of the instances.

So, the same kind of 'event source' check is done for the person, if an event comes from Banner and the sourced_id in Luminis does not match the one in the event (Banner) then the event is rejected. It's the same principal as the source, it's just verifying that you're not incorrectly updating someone from a different overall source.

I hope this information is helpful to you.


That is very useful info about where exactly they come from. Although, we have kind of decide to import the XML file from our home made IM app, but I will try to make those values matching with the ones in Banner in case I need in the future.

The reason I am not doing the UDC integration with Banner directly, it is because UK HE system is a bit different to US HE system, therefore, we have to do some customization and only use what we need. Secondly, we are trying to maintain certain level of flexibility and independency, meaning don't want to tie up with a certain product too much. Finally, we have a plan to build our own central Identity Management system, Banner will be a main source, but a controller.

These are the reasons I have to work around finding solutions for my own headache.

By the way, I am working on layout template building at the moment. I am trying to find a way of how to create a user / role based portlets list of their URL links as a side menu within content area, so my portal layout will be no difference to any other ordinary website (I hate the 'box' looking portal). Have you done that?

Many thanks


Many Thanks

Thanks for your suggestion. I am trying to build an automated process for provisioning. With lptool, I could write a script, put it into cron job and forget about it. By the way, I found why the lptool doesn't work, the install script didn't include the groovy into class path. But, my admin is on leave for the rest of the week. I have to wait ...

Thanks to Ellucian support center's info. I finally got the lptool working, I knew it was a path issue, but forgot that it should be added into my profile. Sorry, I am not really a Linux/Unix guy, also I prefer Linux/Unix other than Windows on this Luminis case, I am more a application developer, in this case, a Java developer.

Anyway, since discovered that, I fixed it without my admin. Also, I have worked out the LDISP 2 XML and data, and successfully loaded my own user account into LP5.1. A few tricks and interesting findings here:

1. you have to give full path of the xml file to lptool
lptool importims -v [full path]/[your.xml]
2. after examing what this lptool does to LDAP and database, here are the findings
2.1 creating records in both ldap and DB
2.2 username is encrypted in both places
2.3 all the roles, password info are saved in DB, only a very basic account is generated in LDAP

So, my original ideal of setup a automated sync between our AD and LDAP for user provisioning, is totally out of window now. Because, it is too complicated and costly. I really like the user store in LP4, which is stored every thing in one place - LDAP, and password store and encryption only happened during first time logging in or changed.

Anyway, I think I am kind of completed this task now. The rest of this, is to spec the XML and data, and let my colleagues to get it done.

As having to wait for my admin to get the lptool sorted, I am studying the Layout Customization now. It seems a php CMS template thing....

29th Oct 2013:
Looks good is as important as performing and engineering good, may be even more important to be looking good!

So, My main goal on this, is to build a template with header, content (2 columns with sub-menu on the side) and footer, so that I will have all my sites/communities as my main navigation in the header on the top, and a list of site and user/role based URL links of channels(portlet or whatever) / pages as sub-menu on the side in the content area, a portlet will be displayed on the other side when a sub-menu item is clicked. Therefore, it will look like a normal website, and I will have total freedom to change the layout as wish.

So, here is my No. 1 problem and headache:
How to create a site and user/role based URL links of channel/page?

Like usual, before answer the question, I have to understand how the thing works. After days reading on LP5.1 admin guide, Liferay admin and developer guides, and googling, the Luminis Liferay templates are built on 'velocity technology'. LP5.1 seems have 'classic' and 'LP5Corp' themes. The default theme is the 'LP5Corp' (webapps/LP5-ellucian-theme). It involves vm (template), css, XML and images files. To my question, I think I need to understand how the 'control panel' works, how the 'control panel' generates the side menu, once I cracked that, I should be in a better position.

Still a long way to go, anyone has done this or similar? share some knowledge with me?

I might be able to help you some here. We've investigated eliminating the "Home" community and instead creating specific role based communities.

There are two things you might be able to accomplish:

First, the control panel can set permissions based on the site/pages etc.

The other is using existing Liferay hooks and custom user properties to determine their "home page".

Depending on how granular you'd want to go, the sky really is the limit with these.

Today, I got my CAS EAS working. I'd like to share my experience with people here.

Our AD is the central authentication source. Users are located in multiple branches in the root container, it looks like this:
DC=<user root>,DC=<org>,DC=<xxx>


I chosen the fall-through CAS authentication, because I need to let both portal internal users and external users accessing the portal. All I need to do is to create a new 'BindLdapAuthenticationHandler' with a unique 'contextSource' and 'pooledContextSource'. The configuration is straightforward, and the steps are as following:

1. log into your CAS tier as admin
2. located the config file:
3. back up the original deployerConfigContext.xml
4. open your own copy of the xml file, find the bean 'BindLdapAuthenticationHandler' which is located in the of the
<property name="authenticationHandlers">
block within the first 'bean' of
<bean id="authenticationManager" class="org.jasig.cas.authentication.AuthenticationManagerImpl">. It should be like this:

<bean class="org.jasig.cas.adaptors.ldap.BindLdapAuthenticationHandler"
p:searchContextSource-ref="pooledContextSource" />

(this is for authenticating Luminis internal users)
5. Now, create another bean 'BindLdapAuthenticationHandler' in that <list>, place the new one following the original one, e.g:

<property name="authenticationHandlers">
p:httpClient-ref="httpClient" />
<bean class="org.jasig.cas.adaptors.ldap.BindLdapAuthenticationHandler"
p:searchContextSource-ref="pooledContextSource" />
<bean class="org.jasig.cas.adaptors.ldap.BindLdapAuthenticationHandler"
p:searchContextSource-ref="pooledContextSource2" />

I will explain why you need the extra settings for properties of 'ignorePartialResultException' and 'allowMultipleAccounts' later in troubleshooting.

Please config the properties of 'filter' and 'searchBase' correctly, also make the 'contextSource-ref' and 'searchContextSource-ref' unique, and ensure they match the id of your new beans of 'contextSource' and 'pooledContextSource' in next step.

6. Create new 'contextSource' and 'pooledContextSource' beans by copy and paste the existing ones, and change the values of properties: urls, userDN, password; and again, their id names should be matched to what you have referenced in your 'BindLdapAuthenticationHandler'. In my case, it looks like this:

<bean id="contextSource2" class="">
<property name="anonymousReadOnly" value="false" />
<property name="pooled" value="false" />
<property name="urls">
<property name="userDn" value="xxxxx" />
<property name="password" value="xxxxx" />
<property name="baseEnvironmentProperties">

<bean id="pooledContextSource2"
p:contextSource-ref="contextSource2" />

*the properties of ldap.pool.* are setup in file, you can change them if necessary.

7. save your xml file, and restart you Luminis platform.
8. test your new config, ensure you have imported your external users into your LP5.1 already.

During my config work on EAS CAS, I got the following error at one time:
CAS is Unavailable
There was an error trying to complete your request. Please notify your support desk or try again.
(* ref: Ellucian support Case 00764660 by Anton;

looking into the catalina.out log file on CAS server, I see:

Unprocessed Continuation Reference(s); nested exception is javax.naming.PartialResultException: Unprocessed Continuation Reference(s); remaining name 'dc=xx,dc=xxxx,dc=xxx'
This is due to:
"By default, the Sun JNDI provider sends the LDAPv3 ManageDsaIT control
to AD, but this control is not supported since AD is not LDAPv3
compliant. The behavior of AD is to send a referral for the actual
entry, which is not expected by the JNDI provider and it throws a
PartialResultException when it sees the referral. "
The solution:

<bean class="org.jasig.cas.adaptors.ldap.BindLdapAuthenticationHandler"
p:searchContextSource-ref="pooledContextSource2" />

Hi Zhang,

Is it possible to create Luminis Account automatically based on Banner(LDI events)?
Is there any process I have to follow to make it working?


Hi Prakash,

Yes, that is another way to provision your portal user accounts. There are 2 guide you can follow to configure both LP and Banner.
1. Luminis Platform Banner Integration Setup Guide 5.1.pdf
chapter 3 - "Data-Level Integration and Provisioning", it speaks about the account provisioning from Banner to Luminis.
2. Banner Integration for eLearning / Administration Guide / 8.0

I don't have hand on steps for this. I briefly looked this option. But, decided not take this approach. This is due to our own setup around other things. I am going to import XML file with data from Banner and created by a bespoke process.

I hope that helps.


I did not understand number 4. can you make it little clear.
I am getting error:
2013-10-30 14:14:21,113 INFO [org.jasig.cas.adaptors.ldap.BindLdapAuthenticationHandler] -
start[1383160461063] time[49] tag[BindLdapAuthenticationHandler]
2013-10-30 14:14:21,114 INFO [org.jasig.cas.authentication.AuthenticationManagerImpl] -
2013-10-30 14:14:21,117 INFO [org.jasig.cas.adaptors.ldap.BindLdapAuthenticationHandler] -
start[1383160461114] time[3] tag[BindLdapAuthenticationHandler]
2013-10-30 14:14:21,118 INFO [org.jasig.cas.authentication.AuthenticationManagerImpl] -
start[1383160461118] time[25] tag[BindLdapAuthenticationHandler]
2013-10-30 14:14:21,144 INFO [] - =============================================================
WHO: [username: psilwal]
WHAT: supplied credentials: [username: psilwal]
WHEN: Wed Oct 30 14:14:21 CDT 2013
CLIENT IP ADDRESS: 112.58.x13.xx
SERVER IP ADDRESS: abc.17.223.6

4. open your own copy of the xml file, find the bean 'BindLdapAuthenticationHandler' which is located in the of the

block within the first 'bean' of
. It should be like this:

p:searchContextSource-ref="pooledContextSource" />

Hi Psilwal,

Sorry to hear you got problem with your authentication. Could you give me a bit more background info on what your setup is and what you are trying to achieve now?

The step 4 is to let you find the block you would need to work on at step 5. The important bit is in the step 5.

Basically, that is for a falls over configuration which is a authentication mechanism against both LP internal LDAP and external AD, it will try another source if one fails.

I chosen this way, it is for later when I am doing SSO integration with Banner really. I will explain and provide steps when I am actually doing it.

To get your LP authentication working with your external source (LDAP/AD), there are so many things could go wrong. You have to make sure your external LDAP/AD setup/configured properly for binding. You probably want to test your external LDAP/AD with a LDAP browser or a tool for examing the credentials, search, network, firewall, etc first.



Hi Yu,

Thanks for sharing your experience. Very helpful! As your last step indicates, user provisioning must be done before the actual authentication against AD starts working. Otherwise, you will get "The credentials you provided cannot be determined to be authentic." This is kind of misleading, don't get disappointed here yet, go to your catalina.out file, and you will find "org.jasig.cas.adaptors.ldap.BindLdapAuthenticationHandler successfully authenticated the user", which means the authentication works! I just throw this out here in case people are not sure what happens. The same problem is also mentioned in this thread:

Thank you very much,
Larry Peng Zhang

Hi Peng,

Nice to hear your very kind comments here! Thanks for your valuable important information.

I will be in Salt Lake City for the protlet training course next week. Hopefully, I will meet some US portal guys there.



When we converted from LP 3 to LP 4 we basically were able to build LP 4 in a parallel deployment then perform a final conversion-configuration for cutover. New installations aside, what is the easiest scenario to rollout LP 5.1 when currently on LP 4.2.1?


There are really only two approaches to consider: migration or a fresh implementation.
To use the migration utility from Ellucian they recommend you run it from a LP 4.3 installation, so you would have to upgrade your 4 install to run the migration to 5. When you say you went from LP 3 to LP 4, was that using the migration utility?

The most important thing would be to perform an extensive evaluation of your current 4 implementation and review what pieces could be migrated vs what you will need to re-build anyways.

I hope that helps.


Hi Eschuber,

I agree with Tom. There are 2 way to do this: migration or new build.

BUT, a big BUT, if you want to do migration, you have to upgrade to LP4.3 as minimum requirement to use that migration tool. Also, a big ALSO, you can't convert uPortal custom channels to portlet channels with that tool, although it can migrate the targeted announcement channels. Finally, the CAS thing, if you have not done the LP4 with CAS, then you have to completely change your system architecture. You have to balance it yourself I am afraid. i did the same when I moved from LP3 to LP4.2.3. There is no easy way this time.

I am doing fresh build this time. Because:
1. I want to TOTALLY refurbish my portal, get rid of the 'boxy' looking, I plan to build a brand new multi media normal web site looking and feel portal. I want the new portal have better user experience
2. The whole concept of the portal has been changed. On LP5.1, it can do so much more, and introduces this community idea, and you can do your portal (integration with other site/including other sites) in a 'orgnization', 'site' and 'page' level. It has WCM thing in it, so you can build a new site or page on fly.
3. user provisioning is changed, well, the XML format is changed at least, although they got the tool back called 'lptool' like the 'cptool' in LP4 and 3.
4. I want to take advantage of the rich-browser client technology, Ajax, Jquery, etc. To convert my portal framework into a service oriented stand-alone application, much more independent to the LP5 platform. So, each portlet is just a little consummer.
5. I don't use CAS in LP4.

Those the reasons I do a fresh build. What do you think yours now?

Hope that helps.


Sorry for confusion ... yes already decided a fresh build is the way to go.
And yes, we used the migration utility from LP 3 to LP 4 upgrade which had several runs prior to the real cutover working through conversion glitches. Don’t want to do that again.

However, all the new stuff you describe in 5.1 (that I’m in the process of discovery) might take some time with customers in preview-feedback mode. So I was wondering if both LP4 and LP5.1 can run at the same time (in a sense that perhaps 5.1 not fully integrated with events but functional enough to preview and tweak it for a few months).

If so, what would a final cutover entail? Some export – import of PDS data? Or does the configuration of LP 4 and LP 5 back on banner mutually exclusive of each other (there can be only one) making a hard cutover from test the only way?

Hi Eric -

If you want to run both v.4 and v.5 concurrently, I would do the following since you would not want 2 different portal implementations to be hitting the same Banner instance at the same time:

Option #1
- Current v.4 implementation is integrated against Banner PROD and production third-party apps for data and SSO integration
- New v.5 is a standalone Luminis portal deployed against a new portal URL without any data or SSO integration to Banner or other third-party apps

Or, you could do option #2 if you decide to offer a more integrated v.5 instance:
- Current v.4 implementation is integrated against Banner PROD and production third-party apps for data and SSO integration
- New v.5 is implemented against a test Banner instance that is a recent Banner PROD clone (static) and testing third-party application instances, and put a disclaimer regarding this being a test instance
> The static Banner PROD clone instance will allow you to not have to flush out your user accounts and re-load them when you are ready to do your v.5 cutover to Banner PROD

In either option, you could have v.5 look at your CAS PROD instance or CAS TEST instance, depending on your department's stance of testing and environment separation.

Then, when you are ready to cutover to v.5 :
- Take v.4 offline
- Update v.5 with Banner PROD, BEIS PROD, CAS PROD and production third-party application settings
- Do an xml load from Banner PROD to get the latest user and academic data
- Update v.5's portal public URL if you want to re-use the current v.4 URL *

*Since we can now update the portal public URL value in v.5 without having to re-install the application (yeah!), you can support updating your v.5 instance to use the current v.4 portal URL if Marketing/Communications insists on re-using it.


So how did you finally end up doing user provisioning? We too wanted to get to the point where AD was our central LDAP and wanted to get to one credential. Are you using LDI to Luminis LDAP and then somehow updating AD?