How the JSON Web Token is Winning the Single Sign-On Game

The login process for accessing JD Edwards (or any system, for that matter) feels like it should be cut and dry. But it’s deceptively simple – a secure and efficient login requires a lot from any given single sign-on option. And while there are several different methods of SSO in use today to get into JD Edwards, it’s increasingly in your company’s best interest to opt for a more secure option in the game: the JSON Web Token Single Sign-On.

The most common different sign-on processes available include EnterpriseOne Default Login (E1 Default), Lightweight Directory Access Protocol (LDAP), Single Sign-On (SSO) and JSON Web Token Single Sign-On (JWT SSO).

This article gives an overview of each type of sign-on and covers why the JSON Web Token is the best option for enhanced security and ease-of-use.

EnterpriseOne E1 Default Login

Traditionally when using EnterpriseOne, the login is a standard authentication with a 10-character user ID and password. This is referred to as the E1 Default Login. There is no case sensitivity required, though in JD Edwards 9.2 tools release, the capability to implement long usernames and long passwords is available. Long passwords become case-sensitive when enabled. Customers can also layer other authentication methods on top of that foundation to provide a bit more security, but overall E1 default login is the least secure of the login processes.

Roughly 50-75% of JD Edwards customers use the standard E1 Default. More and more are switching to using LDAP or SSO. Still, E1 Default can be an effective security framework in many customer situations. This security feature is the tried-and-true option most customers begin with, and it is foundational for the other login options.

LDAP: Lightweight Directory Access Protocol

LDAP has been available for many years. If you sign into Microsoft Windows, you’re using an LDAP. It contains your login and user metadata, and any groups you belong to or roles you may have. LDAP is enabled at the Enterprise server level, utilizing a directory structure to store and manage user information. All users must be defined within LDAP – that includes E1 service accounts.

LDAP and E1 work together, but there are still some hindrances. For one, E1 doesn’t have any automatic replication capabilities. So, if a user is deleted in LDAP, they will become orphaned in E1. (Oracle generally recommends disabling users instead of deleting them.) LDAP generally enables more control over user access permissions.

SSO: Single Sign-On

Traditional SSO enables users to use a single set of credentials to access various applications and systems. Traditional SSO has been available through Oracle for several years now, certified with both Oracle Access Manager (OAM) and Oracle Identity Cloud Service (OICS). Several third-party solutions are also available, including OKTA/Auth0, Everest International (JDESSO), SSOGEN, OneLogin, Steltix Transparent Logon X10, and more.

Most of these solutions have some type of gateway or proxy server to work with the identity provider – at a cost. The use of SSO provides a more centralized repository for credentials and ease of authentication for users across multiple applications. SSO may require additional expertise and time to implement these solutions, depending on the identity provider software in use. This results in increased complexity and effort to implement SSO.

JWT SSO: JSON Web Token Single Sign-On

JSON Web Token Single Sign-On involves using digitally signed tokens to facilitate secure access to the JD Edwards system. When a user logs in, one of these tokens or JWT is generated and digitally signed, and then sent between the user’s browser and the JD Edwards server. This step creates a two-for-one value for customers, by making access both secure and simplified.

Application Interface Services (AIS), which is used for Orchestrations, has included the JWT option since E1 tools 9.2.0.5. Several enhancements have occurred to JWT with JD Edwards along the way. Java Application Server (JAS/HTML) has had the JWT option since tools 9.2.5.4 and later. This is key enhancement to allow various identity providers (IDPs) such as Microsoft Azure AD or possibly (ADFS), Okta/Auth0, and others to provide authentication services to E1.

JWT SSO + JD Edwards = A Powerful Combination

By using JWT SSO to access your JD Edwards system, customers are setting themselves up for a more secure, simplified and expedited login process. JWT allows for secure, tamper-proof transmission of authorization information between systems, helping to reduce the risk of data breaches and unauthorized access. It also allows you to leverage the identity provider features such as multi-factor authentication or conditional access that are not present within E1.

If you want to learn more, Frank Jordan and Paul Shearer give a deep dive in an on-demand webinar on the authentication options for JD Edwards. You can also contact Frank and our advisory team to learn more about implementing JWT SSO at your company.