Jump to content
Sign in to follow this  
RobMiller

Multiple Authentication Types

Recommended Posts

V8.3 (Build 8361)

 

Currently we are only using SAML2 with Okta. Everything works fine. Our Web Site Allowed IP Ranges under System Settings was blank allowing login from anywhere.

 

I need to open this up so different accounts can use different authentication types. I added a subnet to 'Web Site Allowed IP Ranges' and then changed the auth for items outside this subnet to Forms and Google Auth. 

 

If the Passwordstate web site is accessed outside of one of the IP Ranges listed above, force the user to authenticate using the following method:

Authentication Option: Forms and Google Authenticator

 

My issue is that no matter what, Passwordstate attempts to use Okta to login. Even though I am logging in from an IP not in the list, it still uses the default authentication method which is SAML.  It doesn't drop back to Forms like it's supposed to. I've rebooted the server to no avail.

 

How do I make this work?

 

Thanks,

 

Rob

 

 

Share this post


Link to post
Share on other sites

Hi Rob,

 

Can you go to the auditing screen and have a look at what IP Address is being logged for the authentication attempt? Possibly it's the IP Address of your firewall or proxy - this is the only thing I can think of which would explain why this is not working.

We'll also do some testing to see if the SAML Authentication option is interfering with this at all, and we'll let you know.

Regards

Click Studios

Share this post


Link to post
Share on other sites

I even dropped it down to a single public IP address that is allowed, it still does it, even when I look at the auditing and can confirm logins are coming from another IP that is not listed.  It seems to be something with SAML. Perhaps there is a bug where if you are using SAML as the default, it can't use anything else.  It definitely doesn't work.

Share this post


Link to post
Share on other sites

Hi Rob,

 

We've just tested this with Build 8411, and cannot reproduce the issue you are seeing - we have the System Wide authentication option set to SAML, and then the Allowed IP Ranges set to Google Authenticator. If I come from an address outside of the allowed IP ranges, I get the Google Authenticator screen. Are these the only places you are setting the Athentication options - no User Account Policies, or personal Preferences? The Allowed IP Ranges feature should override these anyway?

Regards

Click Studios

Share this post


Link to post
Share on other sites

I don't know.  I can't ever get it to do anything but SAML. I have no User Account Policies, and no personal preferences. I will try to update to 8411 shortly to see if that is it. Here are my relevant settings:

 

Passwordstate-00.png.88dfac6e312b0d32928033448d430a31.png

Passwordstate-01.png

Passwordstate-02.png

Passwordstate-03.png

Passwordstate-04.png

Share this post


Link to post
Share on other sites

If I set the Authentication Option for outside the range to "Deny Access Altogether", then it does work and block me.  So it is 100% detecting that I am coming from an outside IP and following that alternative action.

 

However as soon as I turn it back to Forms + Google Auth, even from an old browser like IE, with no Okta plug-ins installed, and set to an in-private browsing window, going to my Passwordstate URL still results in it prompting me to login to Okta.  It simply forwards to our Okta URL prompting me to login to Okta to access Passwordstate.  So since this happens on systems with no plug-ins (even my phone), it's definitely Passwordstate that is forwarding that to Okta, instead of failing over to Forms and Google.  Since Passwordstate does in fact block the same IP when set to block, that tells me that the problem definitely resides in Passwordstate somewhere.

 

2018-08-13_13-33-56.jpg

Share this post


Link to post
Share on other sites

Hi Rob,

 

We're really sorry, as we didn't pick up initially that you are using forms-based authentication, and we were testing with AD Authentication.

So we've been able to reproduce the same issue as you now, and have also fixed it for the next release. We'll post back here again when the new build is available, in about a week or two's time.

Regards

Click Studios

Share this post


Link to post
Share on other sites

Thank you.  I'm on 8501 now. It does work, but there appears to be a security glitch.  I only have a single public IP on the allowed list now.  If I use SAML from another IP, Passwordstate correctly ignores it and presents me with forms based auth.  However, if you simply close that browser tab, and try SAML again, the next time it opens up it will auth you via SAML.  One of my staff brought this up.  It's only presenting the alternative auth once, then if you try the default auth, it will let you use it the second time.  We've tested this repeatedly.  

 

Thanks,

 

Rob

Share this post


Link to post
Share on other sites

Nope.

 

Steps to reproduce using Chrome:

 

1. Close all instances of Chrome, starting fresh

2. Open Chrome, sign into Okta

3. Click the PWS chiclet

4. A 2nd tab is spawned for PWS, PWS correctly identifies you are off-site, doesn't log you in with SAML, prompts for forms based auth

5. At this forms based authentication prompt, do not authenticate, instead, simply close this tab

6. On tab 1, the previous Okta tab, click the PWS chiclet again, it will spawn tab 2 again, but this time, instead of prompting you again for forms based auth as it should since you did not authenticate in previous step, it will log you in with SAML, even though it's not supposed to

 

 

So you see, even using a fresh browser with all instances closed, and never authenticating with forms based auth while being at an off-site location, it will allow you to use default auth on the 2nd attempt.  Definitely looks and acts like a bug.

 

So as of now, I still can't force off-site users to auth a different way, as they can simply bypass it by closing the first tab, and clicking it again.

 

Rob

Share this post


Link to post
Share on other sites

Hi Rob,

 

I think the issue is your Step 5 above. I asked what happens if you close your browser, not close your tab. The only way to kill your sessions in IIS is to log out of Passwordstate, or close your browser altogether. Just closing the tab will not do this.

Regards

Click Studios

Share this post


Link to post
Share on other sites

You are realizing that no one is ever authenticating in the above example correct?  Why close the browser if I never authenticated to PWS? I understand that would matter if I previously authenticated, but that is not the case here.

 

Users right now, off-site, in a disallowed subnet, can completely bypass the authentication requirements of PWS while never authenticating even once using the assigned auth.  I'm sorry but I can't help but feel you are not understanding the situation.  Closing a tab instead of a browser should only matter if I somehow authenticated in that browser previously.  The users are never authenticating, they don't even need to know their password.  They could not know the pass, be using a brand new out of the box PC, log in to Windows for the very first time, all while in a PWS restricted subnet, and still authenticate via the default auth mechanism by closing a tab instead of authing normally.

 

Would it help if I made a video of this behavior? I could do that.

 

Rob

Share this post


Link to post
Share on other sites

Let me rephrase the example above:

 

  1. Locate a computer in a disallowed subnet
  2. Reboot that computer, log in to Windows
  3. Open Chrome, sign into Okta but not PWS
  4. Click the PWS chiclet in Okta
  5. A 2nd tab is spawned for PWS, PWS correctly identifies you are off-site, doesn't log you in with SAML, prompts for forms based auth
  6. At this forms based authentication prompt, do not authenticate with your username and password, instead, simply close this tab. 
  7. At this point, you are now on a computer, that has been rebooted, and you have never authenticated to PWS in this Windows session
  8. Now on tab 1, the Okta tab, click the PWS chiclet again, it will spawn tab 2 with PWS again, but this time, instead of PWS prompting you again for forms based auth, as it should since you did not authenticate in the previous step, PWS will log you in with SAML, even though it's not supposed to.

 

I could reset the PWS password of a user, not tell it to them, then have them start at step 1 above, and they will still be able to access PWS from an off-site desktop computer.

 

Share this post


Link to post
Share on other sites

Hi Rob,


I do not believe this will work if all you're doing is closing the tab - sorry, but this is outside of our control unfortunately. It must be remembering so session variable, which is not being disposed of, as you are not logging out of Passwordstate.

We'll take another look to see if there is something we can do about this, but at this stage we cannot guarantee it.

Regards

Click Studios

Share this post


Link to post
Share on other sites

You guys have a glaring security hole and I can’t even get you to understand it, much less care enough to fix it. I have tried very hard to explain the issue. I have made a video, showing how using an incognito Chrome session with no sessions variables saved, even with Okta showing that Okta has never been logged in with this browser, that a user can bypass your authentication subnet restrictions and login even without knowing their password to PWS.  I guess I will have to open a support ticket as I’m not posting the video here.

Share this post


Link to post
Share on other sites

Hi Rob,

 

Are you able to gain access to Passwordstate without some form of authentication i.e. SAML or Manual? We don't believe this is the case, so we do not agree with you that this is a glaring security hole - as it is currently, you need to be given access to Passwordstate, to your SAML provider, and to the Passwordstate "Application" in your SAML provider.

As mentioned, we will look into this anyway, and hopefully find a solution for this very specific case.

Regards

Click Studios

Share this post


Link to post
Share on other sites

Hi Rob,

 

Just letting you know we've been able to fix this issue today, and it was caused by what we suspected of having some session variables live on the web server because sessions were not disposed of properly by simply closing the tab.

We'll email you again when the new build is available with this fix in it.

Regards

Click Studios

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
Sign in to follow this  

×
×
  • Create New...