PeopleSoft Unified Navigation with PeopleSoft Applicatations Portal / Interaction Hub

With Portal 9.1 Feature Pack 1, which was released just over a year ago, came a new feature I finally got the chance to use. Unified Navigation. In this post I’ll walk through setting this up in one of my demo environments.

Using the Unified Navigation WorkCenter makes configuring this feature pretty easy to set up.  And it certainly does seem to take care of the mess of managing security and content references between all your systems.  Oracle has put quite a bit of effort into making the configuration of Integration easier.  With the introduction of the IB Network WorkCenter, configuration of IB has been simplified.  Setting up Unified Navigation leverages the IB Network WorkCenter and the new Unified Navigation WorkCenter.

Before getting started, lets go over a few details.  Keep in mind I am not an Oracle representative and the information I’m providing  in these next bullets is only rehashing item’s I’ve seen in information published by Oracle.

1.  Unified Navagation requires a full fledged license of PeopleSoft Applications Portal if your running PeopleTools 8.52.

2.  PeopleTools 8.53 modified the limited use license for PeopleSoft Applications Portal so starting with 8.53 you can now use Unified Navigation for free if you own PeopleTools 8.53, I don’t know if this is retroactive back to 8.52 or not, talk to your Oracle rep. or just upgrade 🙂

3. There are several limitations in 8.52, I’ve not found documentation indicating that there was any change to these limitations in 8.53 yet.  These are described in more detail in the PeopleSoft Applications Portal 9.1 PeopleBook: Portal and Site Administration

  • The full license was originally needed and may still be required.
  • Unified Navigation is not supported as a pagelet, although a pagelet does show as available, documentation indicates it is for use in the WorkCenter only.
  • Navigation to the content providers is supported through the drop-down menu only.  I’ve worked several places where clients have disabled the drop-down menu for their own reasons.  A lot of the time this is because they still have pre 8.50 releases and want to keep a more uniform appearance.
  • Some files may need to be copied to the portal system: Any remote pagelet icons needed and CSS files (only if the portal and contenent provider don’t use the same style)
  • Unified Navigation is only supported for like portal types (EMPLOYEE to EMPLOYEE, CUSTOMER to CUSTOMER, etc.  not EMPLOYEE to CUSTOMER)
  • Character limitations on remote folder names are: { } #
  • Can not add subfolders to a unified navigation remote folder (it looks like you could do that, but it’s not supported).
  • Templates for remote CREFs and remote Dashboards need to conform to standards that are outlined in the Applications Portal 9.1 PeopleBook: Portal and Site Administration

4. Documention indicated that this function could work with Content Provider systems at 8.50+ however other information points to all systems needing to be at least 8.52.02 or later.

Okay, on to the real work.

I will be assuming that your environment is already functioning in a pre 8.52 state.  That is, that IB is setup properly to do the following:

  • Gateway(s) are setup properly
  • Nodes are configured and authentication type is set
  • Single Signon is already configured and working
  • Old methods of Portal Navigation already work

Before I started I did some sanity checks on my environment.  Could I ping all nodes and did the original method of Single Signon work?  I used the PeopleSoft > Financials Supply Chain PT8.4x link to test and it popped me right in to Finance just like I would expect.  Also I tested the Portal Administration > Test > Single Sign On > User Profiles link for my content database. Another success, with that we should be good to start.

Some additional configuration steps are required before we move forward.

  1. Ensure the authentication domain matches for all systems involved
  2. Unified Navigation requires the “generate relative URLs” option be turned off on the Virtual Addressing page of the web profile in use.  This is on by default in all the delivered web profiles as far as I know.  Disable it on all systems involved and restart the web server or use the reloadconfig  command if you have that set up.
  3. All systems require the drop-down menu to be enabled, as previously stated it only works with the drop-down menu, not the pagelet menu on the left hand side.  Enable it if you have disabled it.
  4. On the content provider side a default user id must be set on the ANONYMOUS node, the user should be in both the content and portal system.  Oracle recommends that it be a very low priveleged user.  This also could impact pre-existing configuration required for integration. If your not already using the ANONYMOUS node, I recommend creating a new user for this purpose.  Give this user id access to run the PTUN_SSOTESTER service operation.
  5. On the portal side, create a new node for the PTUN_SSOTESTER sevice operation, copy an internal node to fulfill this. The settings should be confirmed: active = yes, segment aware = yes, authentication option = none, WS Security authentication token type = none, routings = none.  Once the node is created, create an outbound routing for the PTUN_SSOTESTER service operation to your new node.  Deactivate the routing to the WSDL_NODE if it is activated.

1, 2, 3, I took care of easily enough. For 4, I created a new permission list, role, and user specifically for this purpose and assigned that user to the ANONYMOUS node, changing it from the PSADMIN user which is delivered.  I added the user without any role and permissions to the portal system.

UNINAV permlist

Create a Permission List

UNINAV permlist 2

Add the PTUN_USRPERS_SYNC Service

UNINAV permlist 3

Edit the Permissions and set PTUN_SSOTESTER to Full Access

UNINAV role

Add the new Permission List to the Role

UNINAV User

Add the new User

UNINAV User 2

Add the Role to the User

For number 5, I copied the ANONYMOUS node to RP_UNINAV.  By default, the node was active, segment aware, and had an authentication option of none.  The WS Security authentication token type was also none.  If for some reason you’ve changed these on the node you copy from you’ll need to update them.  I verified no routings existed on the node and proceeded to edit the PTUN_SSOTEST service operation.  I inactivated the existing active routing on the WSDL_NODE and added a routing for my new node.

UNINAV node in portal

Create a new node in Portal

UNINAV routing

Pull up the PTUN_SSOTESTER routings

UNINAV routing 2

Deactivate the WSDL_NODE routing and add a new one for your new Node

In order to proceed further, we need to start making configuration changes that, at the moment, I’m not that found of, mainly because it appears we need to use the new IB Network.  I may add reference to why I’m not thrilled with this later.

In both Portal and your Content systems navigate to PeopleTools > Integration Broker > Integration Network.  If your like me and this is your first time here, even though things are running fine, you’ll most likely find that it says the Node Network is Not Configured.

IB Network Config Status 1

Click the link, click save on the following screen, return to the configuration status and things should be good to go.  Saving at that screen officially updates the IB_NETWORK status for the default local node for the first time if it hasn’t been updated by something else already.

IB Network Config Status 2

If after returning the status is still not configured, go back and make sure read the notes at the bottom, at a minimum you must have the default local node configured and part of the network, the integration gateway secure keystore must be set, and any nodes configured but not in the local gateway must have a remote gateway configured.  Look to make sure it’s detecting that your secure keystore is setup properly, there will be a checkmark in the Secure Keystore Value Defined in the top left of the page.  Last I knew Oracle was still delivering the keystore password unencrypted and you had to change that to fix it.  Going forward with PeopleTools 8.53 I believe they are prompting you during install for these passwords.

I’m setting this up in Portal and Finance, therefore, in Portal I should have PSFT_EP setup as a remote messaging node and ERP setup as a portal node pointing to Finance.

portal node config

Conversly in Finance, I would setup PSFT_PA as a messaging node and EMPL as a portal node pointing back to Portal.  I already had this done, as I said this was an already working environment, so nothing for me to change here.

Tthe documentation indicates that these Portal nodes must be added to the new Integration Network facility in order to complete the configuration.  The only way to add them though is to add them to a Gateway (either local or remote).

Unified Navigation WC 1

This appears to only be required on the Portal side.  I added ERP to the gateway that Portal was using, and then was able to add it to the IB Network.  After I added it to the network it was available to choose for the Drop Down Menu configuration and SSO test.  I did not add EMPL to a gateway or IB Network on the Finance side and things worked just fine.

SSO test ERP

After adding the corresponding portal node(s) to your gateway(s), add them to the Integration Network.  Once that is complete, go to Portal Administration > Unified Navigation WorkCenter, expand the Unified Navigation Setup section and test the single sign-on to the Portal node (ERP in my case).  After the test completes successfully, move on to Configure Drop Down Menu.  Select the portal node reference, you’ll notice, only nodes in the Integration Network are available for this selection, thus driving the need to actually add these portal purposed nodes to the gateway as I mentioned previously.  For Folder Label, specify a name you like, such as, Finance Menu or PeopleSoft Finance 9.1.  Folder Name is the content provider menu navigation to share, use the lookup button and the returned tree to select what to bring over.  This allows you to do partial or full menu, for instance, my example does the full tree, but you could choose to do three individual subfolders, and set them up independently.  Local Parent Folder Name is the same as Folder Name but it’s the corresponding location to place the menu on the Portal side.  They are pretty self explanatory.

Drop Down Menu Config

And here is the final product, note the Fianance Navigation at the top of the drop down menu expanding all options since I’m logged in as an admin.

FIN Nav menu

This is a pretty nice update in my opinion.  Doesn’t take long to setup, especially if you already had things working, and is much cleaner than moving CREF’s and security around to provide navigation.  [Edit] Screenshots added

Enjoy.

As reference, here’s the link to the PeopleBook for 8.52

http://docs.oracle.com/cd/E28003_01/ps91fp1pbr0/eng/psbooks/psad/book.htm?File=psad/htm/psad36.htm%23nid-gec524d2c9b61e7fa_ef90c_133adc3ad4d__8000

Why you should have different local node passwords

I was doing an assessment of a Peoplesoft installation recently when I noticed that the node passwords were the same across all environments of the same application type. While this might not seem like it is a big deal, it can open up a production environment to unauthorized access or accidental data entry. If this sounds like your environment perhaps some of your developers or users may have already realized that this allows them to access production with out a password from a non production environment, especially if they use bookmarks or direct URLs.

The problem here is related to a mechanism of Peoplesoft’s authentication. The PS_TOKEN cookie which is used for authentication is created from among other things the issuing systems default local node and password. If this data is the same across say, all your HCM environments, then a PS_TOKEN created in a development environment can also be valid in the corresponding production environment.

My recommendation is simple enough, force the node passwords to be different for every database in your install via your refresh script or process. This will ensure the PS_TOKEN is not valid across multiple instances of the same application and prevent this rather undesirable “feature” that I know several developers have enjoyed and even relied on in the past.

PeopleSoft Desktop Single Sign-on via Kerberos – Part 3

Welcome to the third installment of PeopleSoft Desktop Single Sign-on via Kerberos.  I hope to wrap up everything in this final post. In Part 1 we configured our Linux servers to talk to our Active Directory server and setup a user/SPN for our Kerberos Authentication. In Part 2 of the PeopleSoft Desktop SSO write up we configured our Linux Weblogic instance to use the Oracle provided servlet filter.  We set filter mapping to /* to force every request through the KerberosSSO filter.  Now it is time to move on to our app server and online configurations to finish this up.

In order for the application server to validate the Kerberos token we need to copy the java class files to $PS_HOME/class/com/peoplesoft/pt/desktopsso/kerberos.  Oracle seems to be delivering these in $PS_HOME/class/com/peoplesoft/PT/desktopsso/kerberos but that doesn’t work! So either recopy these files from our webserver or the “PT” directory.  We need both KerberosSSOValidator$1.class and KerberosSSOValidator.class.

Next lets update our psappsrv.cfg file with the following
-Djava.security.auth.login.config=/home/psoft/krbLogin.conf
-Djava.security.krb5.conf=/etc/krb5.conf

Look familiar? Yep, we did this on the web server. Did you create these files on the app server yet? If not copy them from your web server, don’t forget to copy the keytab file which is referenced in krbLogin.conf.

So the JavaVM Options line will read something like (it’s around line 925 in my config file)
JavaVM Options=-Dxdo.ConfigFile=%PS_HOME%/appserv/xdo.cfg -Djava.security.auth.login.config=/home/psoft/krbLogin.conf -Djava.security.krb5.conf=/etc/krb5.conf

Next lets edit the Peoplecode for FUNCLIB_LDAP.LDAPAUTH. First we want to edit the getWWWAuthConfig function.  Update the username identified in &defaultUserID.

/* Updated for Kerberos Sign On */
&defaultUserId = "PUBUSER";

Next we want to add the following function at the end.

Online create our public user PUBUSER and enable this user for guest login capabilities in the webprofile.  Reload the profile using reloadconfig command or restart the web server. Once reloaded try it out and see if it works.  Don’t load the signon.html page, it’s the signon page and of course will ask for a username/password.  Start by trying to go to http://websrv.testdomain.com/psp/ps/EMPLOYEE/ERP/h/?tab=DEFAULT for Finance for example.

PeopleSoft Desktop Single Sign-on via Kerberos – Part 2

In Part 1 we started our SSO config by getting our Linux servers to talk to the KDC and we should have a working keytab file for our SPN. Now lets setup some things for our Weblogic to utilize this.

First, create the following krbLogin.conf file
krbServer {
com.sun.security.auth.module.Krb5LoginModule required
storeKey=true
useKeyTab=true
keyTab="/home/psoft/krb5.keytab"
isInitiator=false
principal="HTTP/websrv.testdomain.com";
};

Update the keyTab property to point to where ever you placed your keytab file and the principal should match your SPN you created. In this proof of concept I just placed this file in /home/psoft with the keytab file.

Now we need to tell Weblogic to use these files. We do this on the corresponding JAVA_OPTIONS line in setEnv.sh, in my case it now reads
JAVA_OPTIONS_LINUX="-jrockit -XnoOpt -Xms512m -Xmx512m -Dtoplink.xml.platform=oracle.toplink.platform.xml.jaxp.JAXPPlatform -Dcom.sun.xml.namespace.QName.useCompatibleSerialVersionUID=1.0 -Djava.security.auth.login.config=/home/psoft/krbLogin.conf -Djava.security.krb5.conf=/etc/krb5.conf"
We added the following to the end of the options variable.
-Djava.security.auth.login.config=/home/psoft/krbLogin.conf
-Djava.security.krb5.conf=/etc/krb5.conf

Next lets edit web.xml in our PORTAL.war/WEB-INF directory we need to add the following
<filter>
<filter-name>KerberosSSO</filter-name>
<filter-class>com.peoplesoft.pt.desktopsso.kerberos.KerberosSSOFilter</filter-class>
<init-param>
<param-name>checkSecureConnection
</param-name>
<param-value>false</param-value>
</init-param>
<init-param>
<param-name>validateToken</param-name>
<param-value>true</param-value>
</init-param><init-param>
<param-name>verbose</param-name>
<param-value>true</param-value>
</init-param>
</filter>
<filter-mapping>
<filter-name>KerberosSSO</filter-name>
<url-pattern>/*</url-pattern>
</filter-mapping>

Here we apply the KerberosSSOFilter (which Oracle provides source for if you’d like to improve it) to the url-pattern /* so any request will go through the filter.

    The parameters

  1. checkSecureConnection: I set to false as i’m not using SSL in this environment. change to true if your using SSL
  2. validateToken: start with true so we can troubleshoot and verify things work at the web layer
  3. verbose: self explanatory, set to true until it works

After making these updates restart Weblogic and check for errors on startup in the logs. We are now to the point where we can test the Weblogic filter and make sure basic configuration is working.
Lets move on to our Windows workstation that is part of our Domain. Lets make sure our browser is setup for this. In most corporate environments this should already be setup. For IE, on the Security tab in Internet Options check the site options, if your PeopleSoft URL is not detected as part of the intranet, add it here by clicking sites -> advanced and adding it manually. Once this is done, lets see what happens. You won’t get logged in but we can see if the Kerberos Token is being processed properly. First lets tail PIA_stdout.log, then lets login through the normal webpage. After logging in here’s what we should have seen.
<Aug 29, 2012 9:18:10 PM EDT> <Notice> <Stdout> <BEA-000000> <KerberosSSOFilter: Requesting Kerberos token. (Connection is NOT secure)>
<Aug 29, 2012 9:18:10 PM EDT> <Notice> <Stdout> <BEA-000000> <KerberosSSOFilter: Received valid token for user@TESTDOMAIN.LOCAL.>
<Aug 29, 2012 9:18:10 PM EDT> <Notice> <Stdout> <BEA-000000> <KerberosSSOFilter: Sending token for mutual authentication.>
<Aug 29, 2012 9:18:35 PM EDT> <Notice> <Stdout> <BEA-000000> <KerberosSSOFilter: Received valid token for user@TESTDOMAIN.LOCAL.>
<Aug 29, 2012 9:18:35 PM EDT> <Notice> <Stdout> <BEA-000000> <KerberosSSOFilter: Sending token for mutual authentication.>
<Aug 29, 2012 9:18:35 PM EDT> <Notice> <Stdout> <BEA-000000> <KerberosSSOFilter: Valid session id. Not requesting Kerberos token.>
<Aug 29, 2012 9:18:35 PM EDT> <Notice> <Stdout> <BEA-000000> <KerberosSSOFilter: Valid session id. Not requesting Kerberos token.>

We can see the SSOFilter requests the token, see’s that it’s valid and identifies the user and domain. After logging in the SSOFilter see’s a valid session id and stops requesting the Kerberos Token.

So far so good. Next up, the application server side.

PeopleSoft Desktop Single Sign-on via Kerberos – Part 1

With the release of PeopleTools 8.51 Desktop Single Signon via Kerberos is now a supported reality.  Though this can’t really be considered a delivered solution, I’d call it a reference solution, for those that want to build their own it is at least available and documented.  So here is a walk through of setting up the  “reference” desktop single sign-on solution. (I’m doing this on 8.52 but 8.51 should be very similar).  I’ll also be doing this on Oracle Enterprise Linux servers (Oracle Linux Server release 5.8 to be precise) while Oracle’s documentation is geared towards an all Windows environment.

First lets go over the basic plan of attack:

  1. Need an Active Directory server (instructions not included)
  2. Need our Linux servers to be able to authenticate against said AD
  3. Create required accounts/SPN and keytab file
  4. Need to enable servlet filter on Weblogic to handle Kerberos Token
  5. Need to enable app server to handle Kerberos Token
  6. Need to enable public user and single signon kerberos peoplecode
  7. Need to test and troubleshoot if needed

I’m not going to rehash everything explained in the PeopleBooks article, if you want their explanation of how this actually works you can read it for yourself, it’s a decent writeup.

If you don’t have an Active Directory server already available that’s beyond the scope of this article.

Let’s setup our servers to talk to our Domain Controller via Kerberos.  With Windows, if your servers are in your Domain this is already taken care of but for us Linux users we need to make it happen.  Here’s how I did it and there isn’t a lot to it.

First, lets edit /etc/krb5.conf. It should look something like this.
[libdefaults]
ticket_lifetime = 24000
default_realm = TESTDOMAIN.LOCAL
dns_lookup_realm = yes
dns_lookup_kdc = yes

For this exercise I commented out the realms and domain_realms section. The above settings rely on DNS to look up the kdc, so if for some reason your not using DNS from your kdc you might want to use a config similar to below where you specify an IP or name for your kdc.
[libdefaults]
default_realm = TESTDOMAIN.LOCAL
ticket_lifetime = 24h
forwardable = yes
[realms]
TESTDOMAIN.LOCAL = {
kdc = 192.168.1.30
}
[domain_realm]
.testdomain.local = TESTDOMAIN.LOCAL
testdomain.local = TESTDOMAIN.LOCAL

There are many other options available in this configuration file, see the man page for more details. What I provide here is the basics to get things moving. Once krb5.conf is setup try running kinit to test the ability to acquire a ticket. For this we need to know a user and password in AD.

[root@appsrv ~]# kinit USER@TESTDOMAIN.LOCAL
Password for USER@TESTDOMAIN.LOCAL:
[root@appsrv ~]# klist
Ticket cache: FILE:/tmp/krb5cc_0
Default principal: USER@TESTDOMAIN.LOCAL

Valid starting Expires Service principal
07/12/12 21:32:50 07/13/12 07:34:04 krbtgt/TESTDOMAIN.LOCAL@TESTDOMAIN.LOCAL
renew until 07/13/12 21:32:50

Kerberos 4 ticket cache: /tmp/tkt0
klist: You have no tickets cached

[root@appsrv ~]# kdestroy

Ok, That works, we got a ticket, listed it, and got rid of it. From the man pages:
kinit - obtain and cache Kerberos ticket-granting ticket
klist - list cached Kerberos tickets
kdestroy - destroy Kerberos tickets

Do this for both the web and app server.

Now let’s create our service account, HTTP service principal, and a keytab file. A side note here, I took a short cut by creating a single account to use for both servers. In a real world environment you might want to consider using Computer Accounts and actually adding the Linux servers as members in the Domain.

  1. Create USERs in AD: add user krbauth/p@ssw0rd
  2. run command prompt as admin
  3. Setspn.exe -S HTTP/websrv.testdomain.com krbauth

webserv.testdomain.com needs to match your server and DNS domain name although my AD Domain is testdomain.local I have testdomain.com as a working DNS entry on this network.
C:\Windows\system32>setspn -S HTTP/websrv.testdomain.com krbauth
Checking domain DC=testdomain,DC=local

Registering ServicePrincipalNames for CN=krbauth,OU=Users,DC=testdomain,DC=local
HTTP/websrv.testdomain.com
Updated object

C:\Windows\system32>
Once we have the account and SPN setup we can create a keytab file for our Linux hosts. On the Windows server run the following command: this command is CASE sensitive as are most Kerberos items including the krb5.conf file.
C:\Windows\system32>ktpass /princ HTTP/websrv.testdomain.com@TESTDOMAIN.LOCAL /mapuser krbauth /pass p@ssw0rd /crypto ALL /ptype KRB5_NT_PRINCIPAL/out c:\users\user\desktop\krb5.keytab
Targeting domain controller: DC1.testdomain.local
Successfully mapped HTTP/websrv.testdomain.com to krbauth.
Password succesfully set!
Key created.
Output keytab to c:\users\user\desktop\krb5.keytab:
Keytab version: 0x502
keysize 98 HTTP/websrv.testdomain.com@testdomain.local ptype 1 (KRB5_NT_PRIN
CIPAL) vno 4 etype 0x12 (AES256-SHA1) keylength 32 (0xc29e40406bb1e6aac2428f7f41
a514c8f832940ca2f0ba2742900503a57c9f15)

Once the keytab file is created copy this file via binary means to the Linux host, I use winscp for these types of things. We can test the keytab file by using the following
kinit -k -t /home/psoft/krb5.keytab HTTP/websrv.testdomain.com@TESTDOMAIN.LOCAL
again, use klist and kdestroy to verify and clean up after yourself.

In Part 2 I’ll continue with setting up the web and app server.