JDE SSO - LDAP Integration

stevenatherton

Member
Has anybody else implemented single sign on with JD Edwards integrating into Microsoft Active Directory.

We are looking into an implementation with either direct AD LDAP integration or using a third part tool such as Everest.

The main concern i have is with direct MS AD integration that the entire user population as well as enterprise services will get authenticated outside of the JDE application therefore if you loose comms / LDAP server you loose JDE. I am aware that if you loose your LDAP server you have to re start your E1 services therefore would like to try and implement with a clustered IP address pointing at a group of LDAP servers but cant get a definitive answer from Oracle as to if this will work.

Has anyone else implemented SSO in any form, if so i would appreciate listening to you experiences.
confused.gif
 
Just some points (with our SSO solution in mind, of course):

1) JDE Services are not covered with our SSO approach and will continue using the standard JDE security, so it's not a concern;

2) Integrating our SSO with our USM (User Self-Management), the users will have both SSO and the ability to sign in manually, in cases AD is totally down;

3) MS AD is distributed: if you have PDC & a few BDC's, then the authentication should not be affected by the PDC going down, while BDC's are still operational.
 
To apply Single Sign-on with JDE, you can use Oracle SSO conponent. Then in that case JDE will use security tokens generated by SSO server on local machine, to validate the user. In that case the validation will be done at SSO server.
But Oracle SSO server will only use OID to store user/password.

So, if you just want to use Active Directory to store User id/password, then you can use P95928 application of JDE to integrate Active directory with JDE. And after that you can use R9200040 UBE to synchronize all users with JDE and AD. Simmilarly you can use Data4LDAP.exe to synchronize JDE users in AD.
As, per your concern, if your AD server is down, then you can simply restart your JDE services by changing LDAPAuthentication to false, then it start authenticating the users user against the EnterpriseOne enterprise server database.
 
And it's my understanding of standard JDE SSO implementation that if you delete a JDE user, it will quietly delete the associated Windows user as well...
 
Alex,
No, once you enable LDAP in JDE, then you can not create or delete users from JDE.
Aas, per the process, once you login in JDE with windows User id/password, then security kernel will verify the user ID and password in LDAP server and then it will check that particular user ID in JDE. If, that user id is not available in JDE then it will create that user id/Password in JDE with all the default roles and environments, as you will provide to _LDAPDEFLT user and that user can login into JDE.
 
Can you still assign roles to users in JDE if LDAP authentication is turned on?
 
Yes, you can assign roles with-in JDE, if you are only managing users in LDAP. But if you want you can manage Roles and users both in LDAP, then you can assign roles to users with-in LDAP itself.
 
Well, there is a simple SSO for JDE .. we have used SSOGEN and it works with our Azure AD for JDE authentication, and management is quite happy.
 
I have experience with both Everest SSO and LDAP integration via AD. I much prefer the Everest option. Here's why:

1) With LDAP integration, you cannot manage user accounts in JDE because the LDAP integration does not allow you to delete user accounts once they are created.
2) With LDAP integration, users must first sign into JDE for the first time before you can provision their security. Not a major deal, but it slows down the on-boarding of new users.
3) The Everest SSO can be set up to provide simple load balancing. You can control which web servers accept logins and which do not without touching server manager. It is a simple text file to update.
4) The LDAP integration still requires the user to enter a password to get into the system while the Everest solution authenticates and gets the user to the home screen seamlessly without a user id or password required. Just click the URL.
5) With Everest, a single URL can also allow the user to pick the environment via splash screen if their SSO security allows access to non-prod environments.
5) In the end, the Everest SSO solution is worth the small expense to any IT team.
 
We are very satisfied with Everest SSO:
  1. Extremely easy to implement. Non-invasive to JDE.
  2. Doesn't require multiple other components / servers to implement - unlike some solutions. Just one IIS web server which can be installed anywhere.
  3. Provides simple Load Balancing across your Web Instances
  4. Provides means of temporarily Removing a Web Instance from the Load Balancer for Scheduled maintenance to occur.
  5. Allows the same URL to be used for users who have SSO enabled vs those who don't So Load Balancing applies to all
  6. Supports Parameterized URLs
  7. After nearly 10 years of use we've never had a problem with it
 
As a JDE E1 third-party software integrator, I've to say that Everest SSO provides also a simple and secure mechanism to integrate your current or future third-party apps with E1 SSO.
 
As a JDE E1 third-party software integrator, I've to say that Everest SSO provides also a simple and secure mechanism to integrate your current or future third-party apps with E1 SSO.

Agreed. We use Everest SSO and had an in-house developed application that required end user authentication to JDE and Everest SSO provides for that and it has worked great.
 
Back
Top