Bug 1154666

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...

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

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.)

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 .

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.

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.

(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)?

@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.

ping -- @Igor and @Pratik -- any chance of indeed-id supporting firing a "change" event after filling in the form?

@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 .

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.

Should be fixed in 3.6.0.

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.

(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

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

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.

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