Bug 1154666 - Unable to authenticate if user is using http://indeed-id.com/index.html solution for authentication.
Summary: Unable to authenticate if user is using http://indeed-id.com/index.html solut...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: ovirt-engine
Version: 3.4.0
Hardware: All
OS: Linux
unspecified
medium
Target Milestone: ovirt-3.6.0-rc
: 3.6.0
Assignee: Greg Sheremeta
QA Contact: Pavel Novotny
URL:
Whiteboard:
Depends On:
Blocks: 1194394
TreeView+ depends on / blocked
 
Reported: 2014-10-20 13:21 UTC by Pratik Pravin Bandarkar
Modified: 2019-07-16 12:00 UTC (History)
13 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Previously, certain form filler single sign on (SSO) solutions (such as Indeed ID) that do not execute 'change' events would not work with the Red Hat Enterprise Virtualization login pages. Form filler SSO solutions that executed 'change' events worked correctly. The login forms have been enhanced to work without 'change' events. All form filler SSOs should now work.
Clone Of:
: 1194394 (view as bug list)
Environment:
Last Closed: 2016-03-09 20:48:54 UTC
oVirt Team: UX
ylavi: Triaged+


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Red Hat Product Errata RHEA-2016:0376 normal SHIPPED_LIVE Red Hat Enterprise Virtualization Manager 3.6.0 2016-03-10 01:20:52 UTC
oVirt gerrit 37334 master MERGED userportal, webadmin: allow SSO robots to fill in the login form Never
oVirt gerrit 38017 ovirt-engine-3.5 MERGED userportal, webadmin: allow SSO robots to fill in the login form Never

Description Pratik Pravin Bandarkar 2014-10-20 13:21:44 UTC
- What is the nature and description of the request?  
      user is using http://indeed-id.com/index.html solution for login user portal. but authentication fails when rhev take the user and password provided by sso solution. It works if he manually provide the same user details.

https://www.youtube.com/watch?v=WulV6TrDbL0
http://indeed-id.com/solution.html

Comment 3 Alon Bar-Lev 2014-10-21 07:01:34 UTC
Alexander, please see the movie attached.

It is some kind of the worse kind of SSO which actually injects user and password into fields simulating user log on. User portal login dialog does not accept this, it may put the entire value without focus change and not "type" it so gwt widget might be confused?

Pratik, in 3.5 we introduce integration with SSO frameworks without password injection, see bug#1113937, it enables to authenticate to user portal using the kerberos authentication of Active Directory, or if this SSO solution has apache module it can also be used instead of kerebros (Although I did not see that such solution is available in their web site).

Patrik, just a security note... in the movie we see a token that is used without any password, this is usually lower security than using a password...

Comment 6 Igor 2014-10-31 11:31:41 UTC
HI,

user is using http://indeed-id.com/index.html solution for login user portal. but authentication fails when rhev take the user and password provided by sso solution. It works if he manually provide the same user details.

We have trouble with logging in to the application. After we fill "user name" and "password" fields and click <Login> button, the fields are highlighted with red and the logon is not performed. To login we have to put focus in "user name" and press [Enter], then put focus in "password" field and press [Enter] again. Only after these actions we can logging in. Is it possible to not require [Enter] to login?

The decision is necessary for the RHEV 3.4 version.
It is critical!

Igor

Comment 7 Greg Sheremeta 2014-10-31 13:58:46 UTC
I'll investigate. My guess is that indeed-id is not causing the right events to be fired on the login form. (It's not a traditional simple form submit.)

Comment 8 Igor 2014-10-31 15:10:56 UTC
Greg,

Please help to solve the problem !We found the only product that performs SSO authentication Etoken (Indeed-ID) (users don't know their passwords and use etokens for authentication) .for us it is very critical . Unfortunately we have no other solutions
Thank you .

Comment 9 Greg Sheremeta 2014-11-01 16:27:15 UTC
The issue is that the 'change' event is not firing on the login form fields when indeed-id programatically fills them in. (That's my educated guess, at least -- i don't have a test instance of indeed-id to verify. Nor can I find *any* documentation for the product.)

The login form uses GWT widgets. The way we're using the widgets requires the change event to be fired by the browser for the contents to make it from the form fields into the GWT model object.

To replicate the issue without using indeed-id:

1. navigate to the login page

2. load jQuery on the page. Make a bookmark with the content below, and then click it.

javascript: var s=document.createElement('script');s.setAttribute('src','https://ajax.googleapis.com/ajax/libs/jquery/1.6.4/jquery.js');document.getElementsByTagName('body')[0].appendChild(s);

3. open browser's javascript console.

4. execute the following lines of jQuery:
$("#LoginFormView_userName").val("admin");
$("#LoginFormView_password").val("password");  // use the correct password here

5. Click submit.

The form fields will be highlighted red (validation error).

6. Now, to emulate click events:
$("#LoginFormView_userName").change();
$("#LoginFormView_password").change();

7. Click submit. It will submit and log you in.

Step 6 is what indeed-id is failing to do.

------------------------

Contrast this incorrect behavior with the LastPass SSO solution, for example. (lastpass.com -- free to try if you want to replicate.) LastPass works almost the same way (I use it personally). I tested our login form with LastPass, and it properly fires "change" on the fields it fills in on behalf of the user. Works perfectly. So I am comfortable saying this is an issue with indeed-id's handling of web forms that need change events fired on the fields.

------------------
Possible solutions
------------------

1. indeed-id should fire change() events on the fields it fills in. The fact that it doesn't is a bug in their application. Can the customer request that indeed-id fix this on their end? Is there perhaps a setting that tells indeed-id to fire "change" after it fills?

2. If indeed-id cannot fix their product, we could add a hook to our Login button that fires .change() on the fields when the user clicks submit. I don't see any downside to doing this -- however, it's clearly a workaround in our product to handle a deficiency in someone else's product. This workaround is hacky.

@Einav -- please let me know how to proceed. If you're interested in option 2, we should ask Vojtech for his advice. There may be side effects I'm not aware of.

Comment 10 Greg Sheremeta 2014-11-01 17:27:00 UTC
After further thought, perhaps our login form shouldn't depend on "change" event, since there are probably other SSOs out there like this one.

I'll look into what I can do to remove this requirement. Indeed, it makes our login form a little more "special" than a typical form.

Comment 11 Einav Cohen 2014-11-03 22:09:33 UTC
(In reply to Greg Sheremeta from comment #10)
> After further thought, perhaps our login form shouldn't depend on "change"
> event, since there are probably other SSOs out there like this one.
> 
> I'll look into what I can do to remove this requirement. Indeed, it makes
> our login form a little more "special" than a typical form.

@Greg: What do you mean by "shouldn't depend on 'change' event"? do you mean that the login form should depend on another event in order to trigger filling the underlying GWT model object? What is the 'best practice' in this case? If there are tools out there (e.g. LastPass) with which our GUI is behaving "correctly", and if we are following the "best practice" with regards to the way that the underlying GWT model is being filled, then maybe the best thing to do is to go with your suggested solution 1 in comment #9 and/or with LastPass?

@Igor: are you looking into suggestion solution 1 in comment #9 and/or going with LastPass (lastpass.com)?

Comment 12 Greg Sheremeta 2014-11-04 01:57:16 UTC
@Einav, I mean that perhaps our form should behave like an old-school typical non-GWT form, solely for compatibility's sake. i.e. whatever text is in the form fields, however it got in there, gets POSTed to the server when Submit (Login) is clicked. On a regular old form field (input type=text), there is no need for a 'change' event to be fired on a form field for the POST to send the data.

Yes, indeed-id *should* fire a change event like LastPass does, so that it is compatible with a typical GWT form.

But perhaps we should make our form work without a 'change' event. I don't think it's wrong that we do need the 'change' event currently -- I just think it makes us a tad less compatible with these form-filler SSO solutions.

Not sure what that would take GWT-wise. I'd want Vojtech's opinion on that.

Comment 13 Greg Sheremeta 2014-11-12 04:55:23 UTC
ping -- @Igor and @Pratik -- any chance of indeed-id supporting firing a "change" event after filling in the form?

Comment 14 Igor 2014-11-12 14:08:51 UTC
@Einav Cohen
  I passed the information to the Indeed-Id to resolve the issue, sorry but the answer is no. I am informed that requires the development of a module.
The main issue is that there is Passthrough (SSO) Windows Active Directory authentication in the RHEV user portal using the E-Token. Lastpass is not appropriate and does not solve the problem of automatic and transparent authorization is not supported E-Token.
We found the only product that performs SSO authentication Etoken (Indeed-ID) (users do not know their passwords and use etokens for authentication) .for us it is very critical. Unfortunately we have no other solutions

We tested Indeed-ID with version 3.5 RHEV and also got a negative result.
 is very critical . Unfortunately we have no other solutions

USB E-Token - Z90D7 thin client(Windows7 emb AD) - User portal Rhev-automatic Run Guest OS and authorization in the Guest OS using E-Token.

Maybe there are other solutions?

Thank you .

Comment 20 Greg Sheremeta 2015-01-28 03:33:53 UTC
Patch http://gerrit.ovirt.org/#/c/37334/ provides a fix for this issue. I can't test with indeed-id, but I believe it will now work.

To test with jQuery (QE and others):

1. navigate to the login page

2. open browser's javascript console (firebug or dev tools)

3. execute the following lines of jQuery:
$("#LoginFormView_userName").val("admin");
$("#LoginFormView_password").val("password");  // use the correct password here

The form fields should be filled in. Do not click on them or change them!

4. Click submit.

The form should now submit. Without the fix, it doesn't submit and red validation errors appear.

Comment 21 Greg Sheremeta 2015-02-02 17:38:06 UTC
Should be fixed in 3.6.0.

Comment 29 Pavel Novotny 2015-09-30 12:27:50 UTC
Verified in rhevm-webadmin-portal-3.6.0-0.16.master.el6, rhevm-userportal-3.6.0-0.16.master.el6 (build 3.6.0-13).

Verified according to reproducer in comment 20 (for both, Webadmin & User Portal):
1. navigate to the login page
2. open browser's javascript console (firebug or dev tools)
3. execute the following lines of jQuery:
$("#LoginFormView_userName").val("admin");
$("#LoginFormView_password").val("password");  // use the correct password here

The form fields should be filled in. Do not click on them or change them!

4. Click submit.

Result: Form submits and user is logged into admin/user portal.

Comment 30 Igor 2015-11-19 03:53:46 UTC
(In reply to Greg Sheremeta from comment #20)
> Patch http://gerrit.ovirt.org/#/c/37334/ provides a fix for this issue. I
> can't test with indeed-id, but I believe it will now work.
> 
> To test with jQuery (QE and others):
> 
> 1. navigate to the login page
> 
> 2. open browser's javascript console (firebug or dev tools)
> 
> 3. execute the following lines of jQuery:
> $("#LoginFormView_userName").val("admin");
> $("#LoginFormView_password").val("password");  // use the correct password
> here
> 
> The form fields should be filled in. Do not click on them or change them!
> 
> 4. Click submit.
> 
> The form should now submit. Without the fix, it doesn't submit and red
> validation errors appear.

Hello !

Please confirm full compatibility with the portal user to later versions webadmin portal
compatibility Indeed-ed Web SSO
rhevm-webadmin-portal and rhevm-userportal 

it is critical for the customer


br
Igor

Comment 31 Greg Sheremeta 2015-11-19 20:29:51 UTC
Igor,

I can confirm my fix is in RHEV 3.6. But I don't have indeed-id, so I can't claim that it definitely works as I intended.

Can you try RHEV 3.6 [beta is out] and see if it works? That's the only way we can know for sure.

Greg

Comment 32 Pavel Novotny 2015-11-19 20:59:11 UTC
It is supposed to work also in RHEV 3.5.1 (rhevm-3.5.1-0.1.el6ev) which came out few months back. See backported bug 1194394.

Comment 35 errata-xmlrpc 2016-03-09 20:48:54 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHEA-2016-0376.html


Note You need to log in before you can comment on or make changes to this bug.