This week on the podcast, Dan shares a quick review on Classic Plus and tip when using App Designer. Then Kyle and Dan discuss how the Search Framework implements security on search results.
This week on the podcast, Kyle shares from follow-up on URLs and Metadata, Dan discusses Single Signon changes with PeopleTools 8.56, and Dan explains the concept EFFDT to an enterprise Java developer.
- SuperBowl Follow-up @ 2:15
- Easy REST Requests @ 4:30
- ACM Library @ 5:45
- Metadata and Recent Places @ 8:30
- PeopleSoft and AWS @ 11:00
- 8.56 and SSO Configuration @ 16:00
- COTS vs. Homegrown Software @ 21:45
- SQL:2011 @29:45
; This week on the podcast Kyle shares a frustration with the lack of metadata used in Favorites and other content references. Dan discusses two ideas to improve development and the Portal Node configuration page.
This week on the podcast Dan and Kyle discuss an password vulnerability, learning VIM and migrating 2 Facter Auth devices. Then they review the new Page and Field Configurator utility (spoiler: it’s great).
- Episode 6 – TokenChpoken @ :30
- ERPScan – Decrypting PeopleSoft Passwords @ 3:45
- 2 Factor Authentication and a new phone @ 14:15
- 4 Week Plan to Learn VIM @ 18:00
- HR Image 24 – PS Developer Homepage @ 29:00
- Page and Field Configurator @ 31:00
- Event Mapping Frameworks @ 45:30
- Page and Field Composer Final thoughts @ 51:00
This is a guest post by a PeopleSoft security researcher.
PeopleSoft has introduced a new parameter on Node Definitions called the
CheckTokenID. This parameter is required if you plan on using PeopleSoft Single Signon. In this post we will take a look at what exactly this Check Token feature is, how it works, and lastly some implications.
What is Check Token?
Check Token is a response from Oracle to combat vulnerabilities with
PS_TOKEN and the ability to execute brute force attacks on the node password. Should the node password be recovered attackers would be able to create “authentic”
PS_TOKENs. This was covered in a previous podcast
Check Token involves a set of low level changes to how the
psc servlets (and related Java code) handle the authentication process. These changes harden the servlets against such forged tokens.
However the process by which Check Token improves the security of
PS_TOKEN is not very well detailed and for the remainder of this post we will look at the internals of how this set of changes improves security.
Check Token Pieces
The changes made in 8.56 for the Check Token feature can be split into 2 general sections:
- The Token Lookup
- The Knock Knock Request
The “Token Lookup” portion is a security precaution added to ensure that the
PS_TOKEN being provided was actually issued by the PeopleSoft system.
The Knock Knock Request is a mechanism by which the target application can “phone home” to the site that generated the token and ask them if the Token is good.
We will go more into the details of how this is accomplished in the Step By Step section below.
For the following sections assume that we have the following PeopleSoft Environments:
- Interaction Hub (IH) on Tools 8.56
- CRM on Tools 8.56
- HCM on Tools 8.55
As part of configuring PeopleSoft SSO on 8.56, each Node that will participate (and is 8.56 or later) must have the Check Token ID field populated:
This CheckTokenID field must match for each node in each environment (for example, the IH node has the same value in IH and CRM, and the CRM node has the same value in IH and CRM).
Pressing the Create CheckTokenID button will securely generate a random 189 bytes (252 characters when encoded to base64). The page will also present you this value to copy out for use in the other environments.
You are able to specify any value you want for the CheckTokenID, but for the most security it is better to use the Create button.
There is more to the SSO setup than this, but this is the only portion relevant to the blog post.
An 8.56 SSO Event Step by Step
Now that the environments have been configured for SSO, the best way to show how Check Token works is to go Step by Step through an SSO event. That is when a user with an active session in the IH tries to access a page in CRM and triggers PeopleSoft SSO.
When a user hits a CRM page with a
PS_TOKEN issued by IH, the
psc servlet initiates an authentication attempt by calling the
authenticate method in the
PSAuthenticator class (this is done in the servlet’s
onLogin method). The
PSAuthenticator class eventually calls an
isAuthTokenValidFromRequest method. Inside this method it makes a couple of checks:
- Is the App Server a “portal” server
- Is this request from the “same site”
The “same site” is determined by looking at a cookie that is new to 8.56 called
If either 1 or 2 are true, then the “knock knock” portion of the CheckToken changes is not executed. In this scenario only the “Token Lookup” part is executed. The Token Lookup grabs the web server session (via the
JSESSION cookie) and asks for the
PS_TOKEN from the web server, it then compares this
PS_TOKEN to the one that it has been presented and the check only succeeds if they match.
This in effect prevents forged tokens from being used, as they will be rejected since the token issued by the application itself wont match.
However, in our scenario the user just left IH and hit a CRM page. Because of this #1 isn’t true and
PS_LASTSITE will be an IH url so #2 isn’t true. In this case the Authenticator starts the CheckToken “Knock Knock” portion.
Since CRM has decided that the Knock Knock should be performed, it begins the Knock Knock portion by calling
doKnockKnockRequest of the
The Knock Knock portion has the following steps:
- Get the Last Site (
?cmd=checkTokento the URL from #1
- Form a POST request
- Send Request
The POST request is blank in terms of the content that gets posted, however it does contain a copy of all headers from the inbound request to CRM (including cookies like
JSESSION). The Request is sent off to the URL of the Last Site (in our case Interaction Hub) and PSCheckToken class waits for a response.
CheckToken Processing in IH
When IH receives the HTTP POST with
psc servlet handles this in the
process method. The process of handling the checkToken command is 2 steps, first IH will perform a “Token Lookup” action to ensure the IH really did issue this token. If IH did not, an exception is raised and CRM will not get a valid response.
If IH did issue the token it then begins to form the Knock Knock Response. At a high level the Knock Knock Response value consists of a digest and a nonce. A nonce is generated by using the
generateNonce method of
PSTrustAuthUtil this Nonce is generated by Base64 encoding 16 random bytes (source of random is SHA1PRNG).
The Digest itself is calculated by hashing the
PS_TOKEN, the “knock knock constant”, the Nonce*, and the
PS_TOKEN‘s issue date. The PSCheckToken class supports both SHA1 and SHA256, however the method
createKnockKnockDigest appears to hard-code the algorithm to be SHA256.
The “knock knock constant” referenced above is simply the “hashed” version of CheckTokenID that was set on the Node Definition. Hashed is in quotes because its not truly a hash, but rather it is encrypted with the same algorithm that Node Passwords are. Try setting a node password and a CheckTokenID to the same value and then query the
PSMSGNODEDEFN table to see that this is true.
Once the digest is calculated, the Nonce that was chosen by IH is then appended to the resulting hash and this value is set in the
PS_CTDIGEST header. The * next to “Nonce” is because there seems to be a cryptographic oversight (at least in the 8.56 versions I’ve looked at). When using SHA1 the Nonce is correctly included in the hashing, but when SHA256 is used the Nonce is NOT included in the hash like it should be: ![Nonce Issue for SHA256]
CheckToken Response Processing
Once IH has generated the response and sent it back to CRM, the CRM application server continues execution of
replyFromKnockKnockRequest in the
PSCheckToken class. This method retrieves the
PS_CTDIGEST header and splits the value into 2 parts, the digest and the nonce. This is doable because hashes have a determinate length so it is easy to grab the Nonce off the end.
Once the values are split CRM goes ahead and generates the same digest, using its copy of the CheckTokenID value for the appropriate node as well as the Nonce*. If the generated digest matches the digest that IH sent, authentication succeeds and the user is successfully SSO’d into CRM! The * next to “Nonce” is for the same reason as earlier.
Applications < 8.56
As mentioned in the environment setup we are pretending to have an HCM environment that is below 8.56. Let’s briefly discuss how Oracle kept compatibility for this mode of operation (IH on 8.56 and other apps lower than that).
The way Oracle engineered this change puts the responsibility of determining when to enforce CheckToken on the target application (the one that is being SSO’d to). Oracle deliberately made no changes to the format of
PS_TOKEN itself so that tokens issued by 8.56 would still be valid on 8.55 systems.
Because our HCM environment knows nothing about Check Token, it will never determine that it needs to ask the IH to check the
PS_TOKEN. And because of this the PeopleSoft SSO operates effectively the same way it has been.
What about that Nonce thing?
As mentioned above there seems to have been an oversight with the generation of the Knock Knock response when using SHA256 (not including the Nonce in the hash). Nonce’s are intended to prevent the ability to replay a request. So while technically the lack of the Nonce in the hash renders this protection moot, ultimately the attacker would not be able to get back to “Token Lookup” phase with a forged token because the Application Server will not find that token as not having been issued.
What is important to note is that should Oracle release patches to fix this oversight, they would need to be applied to all systems, if only applied to the CRM in our example, the digest that IH produces would no longer match what CRM produces.
The second set of psadmin.conf videos are available! These videos are two Blitz Talks on Development. Staci Ludwig shares 10 things you need to know about Nodes and Kyle Benson shares a project that helps integrate Git and App Designer.
We have released the videos as a free course so you can find the videos in one place. Head over to the psadmin.io courses page and sign up. If you have already signed up for the course, you can log in and the videos will be available.
This week on the podcast, Dan shares how to disable PSWATCHSRV and how the Fluid Navigator broke. Kyle finds a bug with Facter. Then Dan and Kyle discuss default build settings in App Designer and what is “safe by default” when building projects.
- Psadmin.conf Thank You @ 3:30
- Java EE has a new home @ 6:30
- SublimeText 3.0 @ 8:15
- Elasticsearch and PeopleTools 8.55.19/8.56.04 @ 9:00
- Change Password, Fluid, Homepages @ 15:45
- Disabling PSWATCHSRV @ 22:00
- Breaking the Navigator and the Node Network @ 32:00
- Facter and FQDN Bug @ 39:00
- Default Build Settings @ 46:45
This week on the podcast, Dan has follow-up on using Hiera with Puppet environments, capturing WebLogic logs in Elasticsearch, and Kyle shares his thoughts on the Solaris “change”. Then Kyle discusses the in depth failover testing and how Unified Navigation behaves when app servers fail.
- Solaris is “not quite dead yet” @ 2:00
- How Oracle manages acquired technologies @ 11:00
- Fluid Training with Jim Marion @ 18:00
- New Oracle Version Numbers @ 20:00
- Failover Testing @ 29:00
- How Unified Navigation Behaves when IB is down @ 38:00
- Hiera command line Follow-up @ 51:00
- Logstash and WebLogic logs @ 53:00
- Monitoring Synchronous Messages? @ 56:30
This week on the podcast, Dan and Kyle discuss strategies to organize and manage Event Mapping code, writing code that other people will use, trying to work with Push Notifications and custom ACM modules. Kyle ends the podcast with a funny story about searching for images.
- Push Notification Testing @ 1:30
- Andy Dorman’s Push Notification Configuration
- [IDEA: Fix the 30 Character limit for ACCESSPOINTID}(https://community.oracle.com/ideas/16989)
- Simon Chiu’s Post on Setting up Push Notifications
- Event Mapping and Code Context @ 15:00
- Structuring Event Mapping Code @ 24:45
- Hiera and Puppet Environments @ 32:00
- Puppet and Windows Patching @ 37:30
- Collaborative Coding @ 43:30
- Attempting a Custom ACM Module @ 48:30
- Better Image Picker in PeopleSoft @ 53:15
This week on the podcast, Kyle discusses how he kept the Supplier Portal in Classic while going Fluid Nav for the rest of the application, Dan shares some Related Content feedback and some App Designer filtering tips.
- Don’t be afraid of Makefiles @ 7:00
- MOS Documents in Google results? @ 13:30
- Classic on my Supplier Portal @ 16:00
- Related Content Follow-up @ 32:00
- Security Deployment with Custom Security @ 37:45
- PUM and Translations @ 43:00
- Mobile-friendly Tool Tips @ 46:00
- Beyond Compare and YAML @ 49:00
- App Designer Filtering @ 53:00