A new kind of Single Sign-On

Alex_Pastuhov

Alex_Pastuhov

Legendary Poster
Link: ESI JDE SSO

JDE user, password and generally authentication management are big issues, consuming sizeable amounts of effort and ultimately costing companies a pretty penny at the end of the day. A number of real and a few perceived issues surrounding all standard approaches offered by Oracle(R) are frequently preventing JDE customers from implementing them. There is clearly a need for something simple to fill in this gap. Something that is secure, easy to understand and implement, convenient to use and well documented.

Soon after introducing our revolutionary ESI JDE User Self Management software, we thought about what else can be done in this area, can this approach be enhanced and taken a few steps further? And predictably enough, we came up with this new solution. These two different software solutions do not overlap, they simply offer two different paths to managing your user authentication. With ESI JDE User Self Management, you keep your normal JDE authentication, do not really extend it in any direction and only add a single new automatic function - allow your users to manage their own passwords, taking a lot of load off your IT support.

With this new approach, the authentication is effectively delegated to Active Directory and all JDE aspects of it are now silently managed by our software in the background. But without the complexity of setting it all up within JDE and with some serious additional benefits, not available with the standard JDE LDAP integration. Yet, despite the fact that it's not at all identical to JDE LDAP integration, it is still an LDAP integration, just a different kind. A much friendlier kind. And with more power.

This is a 5-in-1 solution. It concurrently resolves FIVE SEPARATE issues in JDE:

1) It implements JDE Single Signon WITHOUT configuring JDE for either LDAP or Oracle SSO, in fact without any special configuration in JDE at all - this will save you a lot of time and pain!

2) When signing in into the JDE WEB client, this solution ELIMINATES THE PASSWORD PROMPT entirely, relying on Windows authentication to seamlessly authenticate the users - this will save your users time and make their experience better!

3) The standard JDE approach requires Windows User Names to be identical to those of JDE Users, our SSO solution ELIMINATES THIS REQUIREMENT - your Windows names can be as long, or indeed as different from JDE names as desired, necessary or practical - this will give you the flexibility most sites need!

4) Moreover, this solution practically ELIMINATES PASSWORD MANAGEMENT in JDE, by entirely concealing the JDE passwords and effectively replacing the manual JDE signon with an automated process - this will reduce your support costs and again save time to your users!

5) And to top it all, since this solution can at the same time LOAD-BALANCE the JDE WEB Servers, it does - it's just a nice extra feature we could include in this solution at no extra cost!

This solution is typically non-visual: when everything is configured and works as expected, the users won't even see it. And if there are any errors that the users should be notified about, this solution shows itself and presents the user with a helpful screen, detailing the error and the possible solution.

The installation is simple and easy, administration is streamlined and intuitive. If you ever used our software, you would know that our solutions are extremely easy to work with, nothing like you've ever seen before. If you are trying to compare the necessary implementation efforts with the JDE LDAP authentication implementation requirements, it will likely take 10-50 times less effort with this solution.

This solution can deliver massive savings, it would typically pay itself off within a few months.

<font color="red">Nothing can be easier!</font>

This solution can be implemented in hours. Installation support is free. Only Unicode JDE releases with TR896_F1 or up are supported. As far as the JDE backend and WEB platforms are concerned, this solution is independent of either one (provided that it is OW/E1 and not World and bearing in mind that it does need an IIS server somewhere in your network to run on). Please, e-mail us for more details.
 
And in the meantime, the first live installation has taken off today in The Netherlands.

Here’s the customer’s testimonial:

"This SSO solution is the easiest thing on the market for this specific job. Period.
It does not add a lot of overhead (in either hardware, software or management),
as the Oracle supplied solutions do. Once installed, it just works."
 
3 live installations already - 1 in the US and 2 - in Europe.

This software is easy to trial, so if interested, please, e-mail me...
 
Wow, 7 years and many new features later:

Dozens of production installations now, including some of the largest JDE sites in the World with 10k users.

And it is finally an Oracle Validated Integration for JDE 9.1 and 9.2. As of a couple of days ago ;-)
 
Hi

I just saw mention of your SSO product and I'm intrigued. Does it work through a Citrix published application? We run our JDE web browsers through Citrix.

Thanks
Kieran
 
Kieran,

Thank you for your interest!

Yes, it absolutely does. In fact, in this scenario, the installation can be even simpler - entirely server-less.

We offer a free trial and provide free installation services too, so please e-mail us and we can book time and install it for you within an hour, so you can test-run it for a few months and see how it works in your specific environment for yourself.
 
Hi Alex,

I have a question on the JDE SSO solution. We are already using the USM product for Self Service password management. We are currently in discussion of how to implement the SSO and obviously ESI JDE SSO is one of the options. But we have typical business case and I wanted to check how we can circumvent that using this product or will the SSO work in the below scenario.

Say we have around 15k users worldwide but not all of them have a JDE account, only about 3000 users have a JDE account. Also we have external suppliers (non-domain users) who have accounts. Registering all employees with a JDE account is not practical as e do not have that many licenses in JDE.

So in this case, is it practical to go for a SSO solution and if yes can we manage it for the limited users only. I am guessing from the product description that these 3k users would still have a JDE account mapped to the AD, which means the manual work of creating the JDE user still stays.. correct?

Thank you.
 
Soumen,

Sure, can do. Probably best if we meet for a Demo - there are a few options there worth discussing.

Please email me directly.
 
Hi Alex,

I have a question on the JDE SSO solution. We are already using the USM product for Self Service password management. We are currently in discussion of how to implement the SSO and obviously ESI JDE SSO is one of the options. But we have typical business case and I wanted to check how we can circumvent that using this product or will the SSO work in the below scenario.

Say we have around 15k users worldwide but not all of them have a JDE account, only about 3000 users have a JDE account. Also we have external suppliers (non-domain users) who have accounts. Registering all employees with a JDE account is not practical as e do not have that many licenses in JDE.

So in this case, is it practical to go for a SSO solution and if yes can we manage it for the limited users only. I am guessing from the product description that these 3k users would still have a JDE account mapped to the AD, which means the manual work of creating the JDE user still stays.. correct?

Thank you.

Are you still interested? Let's meet for a Demo and discuss it in detail? - the short answer is that we can do all that and probably in a few ways...
 
Most sites are probably already looking at available MFA/2FA options for JDE access and we offer a few, including cloud-less 2FA with no additional costs and some IdP-provided 2FA for most clouds. Including 2FA for a configurable sub-set of users, i.e.: Power Users & Admins, and/or external users.

And the number of JDE sites adopting our SSO solution is steadily growing as well. In 15 years, this solutions has been enhanced so much that it can now handle any conceivable scenario or challenge, placing it firmly ahead of competition.
 
As Multifactor Authentication is gaining traction, the early adopters are naturally faced with some tough preliminary questions: who should be on 2FA vs. who should not, which applications should use 2FA vs. which should not, how often to prompt different types of users for 2FA and so forth.

Most 2FA providers either do not have answers, or are not flexible enough to handle different users differently and exactly as required by each site.

Our ESI JDE SSO is again leading here, by allowing per-user 2FA configuration, so that it can be rolled out to only a subset of users.

Another aspect of this train of thought is deciding what types of users ought to be considered for 2FA immediately – and these are of course Dev Client users – Developers, which again, no generic 2FA provider can handle and where our SSO is clearly in the lead.

Here are some videos to illustrate:

- Registering for 2FA and using it with SSO:
https://jdesso.com/Sso2FARegistration.webm

- Using SSO/2FA to run Dev Clients:
https://jdesso.com/SsoFat2FA.webm



Note that our 2FA does not require any external providers and can use either Microsoft or Google Authenticator Apps, available on all devices. It can be explicitly enabled for any sub-set of users.



And if you find the technology behind the FatRunner solution of interest for any other applications you may have, please do not hesitate to ask.
 
As you probably already know, JDE.INI on the Enterprise/Security Servers has SSL settings. Those have been there forever, but reportedly did nothing / did not work. Not sure when exactly it was fixed, but we can confirm that in the latest TR's, SSL can actually be enabled on these servers.

Sadly, JDE SSL implementation there is incomplete, so it's not a bullet-proof security layer one could have hoped for, but it does ensure all comms will now be encrypted and this gives us encryption of all JDE comms, making it much harder to sniff any sensitive data from that traffic. Previously, all comms were plain text, or at best slightly encoded with very weak coding that could be broken in hours.

As a result, all our software components that require connectivity to these JDE servers have now been updated and will support SSL for these comms transparently. This includes all SSO components.

The highest level of encryption achievable for us at the moment is TLS 1.2, but there will be future updates that would take it to TLS 1.3 level.

In the current cybersecurity environment, enabling SSL is really a must. If your security is ever breached because SSL has not been enabled, you will have to answer some very tough questions and your job may be on the line.
 
Back
Top