Simple Single Sign On Question

Hi,

I am setting up SSO for the first time am getting confused with it.

What I want is simply not having to enter UserId/Password against my web-based EnterpriseOne once I am properly autheticated in my domain.

Do I need to set up LDAP for this or will SSO be sufficient?

I did setup SSO and some users seem to connect to JDE without retyping any password, others get a login screen from the browser (not E1 login screen) to get access to JDE-E1.

Does the username AND password have to be the same in my domain and in E1?
Does the username mapping from domain to E1 really work ?

I hope someone can enlighten me on this.

We are on E900, 8.98.4.1 tools, Windows Security Server.

Thanks, Gerd

Hola Gerd

If your company subscribes to jdetips, then there is a great two part article that will help. Charles Anderson wrote a well documented two part article that will answer that question nicely. If you don't already subscribe, that article alone will be worth the price of admission.

- Gregg

Sounds great Gregg, thanks.

Unfortunately I do not have access to jdetips at this moment.

Gerd

I found a usefull document at oracle.com that helped me answer my questions:

You have several questions on Single Signon implementation:
1. Will SSO implementation eliminate the login screen in clients?
2. Is the Unifed Logon Process possible in Web clients?
3. How to eliminate the login screen for Web clients?

To answer your questions:

1. No. You need to enter the credentials in the Web client even though SSO is setup.

SSO enables users that are signed in to the Portals to access EOne applications without re-entering a userID and password. You need to enter them at least once.

2. No. Unifed Login Process is not possible for Web clients. This is only available for FAT clients.

Unified Login is a way for users to be validated in OneWorld by their NT username and password. It verifies sign-on security against the domain sign-on security maintained by Windows OS. You have to install Unified LogIn as a service in an NT or Windows 2000 Server.

3. The workaround is to make the Web client user remember their UserID and Password (when one logs in for the first time) by preserving this information in the Cookie.

[ QUOTE ]
3. The workaround is to make the Web client user remember their UserID and Password (when one logs in for the first time) by preserving this information in the Cookie.

[/ QUOTE ]

Awww - the cookie end-around. A couple of issues with this approach.

1) You have to modify the JAS.INI to turn on cookies. That should be listed in the document somewhere.

2) Set your cookies to expire at around the same interval that you make your users change their passwords. If your policy is to change your user id every 90 days, then I would set the cookie to expire after 100 days.

3) Run this past your auditors - they might not be thrilled with cookies.

Here is their objection: Gerd logs on, is offered a cookie and accepts. Gerd walks away from his computer. Hector sits down at Gerd's computer and clicks on the saved link for JDE. Hector gains access to JDE without having to enter a password. Gerd is a CNC. Hector is an inquiry user. Now Hector can run amok using Gerd's authority and the audit trail makes it look like Gerd overstepped his bounds. See where that can be an issue?

The SSO is more secure than a simple cookie. A lot more work to set up........

- Gregg

Please look at our SSO solution - it does eliminate the signon screen entirely, needs no JDE-side configuration and is generally much simpler to implement ;-)

And the "ESI JDE Menu Gadget" can be an alternative too - better than cookies anyway...

Thank you Alexander for your feedback.
The products would fit to our needs, but we have already an identity federation suite (PingFederate), which we must use for all of our internal applications, so we don't have a choice.

We need to customize the HTML Server login page in order to delegate the authentification to the centralized tool, so we would like to know if someone already worked on this kind of issue.

Regards.
João

Yes Gregg, you are absolutely correct with your security concerns. I don´t like it myself. I do not understand why I should be so concerned with security but then want to eliminate the entering of passwords.

I will discuss it with my client.

And mention Alex´s solution as well! ;-)

Thanks guys!

Thanks, but as Ping people say: "Both parties taking part in an Internet SSO connection need software that supports the same federated identity protocol. This software must integrate with identity and authentication sources at the Identity Provider, and it must integrate with the application environment at the Service Provider."

And with JDE, there's obviously no such thing, so it's not really of any use as it stands. It's certainly not a matter of customising the login page (unless you meant "write 10MB integration program in JS within the login page", but even that would probably not be enough).

If you are interested, I would expect that our SSO solution can be integrated with Ping and then offer integration to JDE, working as a middle man, so this may be something worth exploring...