Stephen Posted April 18, 2019 Share Posted April 18, 2019 v8.6 (Build 8627) I have configured SAML authentication with Okta in our PWS server, and the SAML assertion from Okta to PWS seems to work, but it requires opening the link from Okta twice. Similar to the steps for reproduction here: , when logging in to Okta with a clean incognito session, clicking on the PWS tile in Okta will open the PWS site but will then load the forms based authentication prompt. If I close that tab and open the Okta tile again, it will login correctly with SAML. (It will login with SAML the first time I click into it from Okta if I've opened the PWS site in a separate tab and there's some sort of session cookies present). I think this may be because the System wide authentication is set to Manual AD authentication, and I tried but am unable to set the Authentication options to SAML2 authentication for the user I'm testing with (it's greyed out). Is this expected behaviour, and would SAML authentication work first time with a clean session if I set the system wide authentication settings to use SAML2 auth? Is there a way to eliminate the double hop without changing system wide auth for everyone? We have a large user base and I don't want to force enable SSO for everyone if it requires this double step Link to comment Share on other sites More sharing options...
support Posted April 19, 2019 Share Posted April 19, 2019 Hi Stephen, If you want all user to use SAML authentication, then you need to select this on the screen Administration -> System Settings -> Authentication Options tab - are you saying it's "greyed out" on this screen, as I'm not sure this is possible? Can you also explain a little further what you mean by 'Forms based authentication prompt'? Is this a browser prompt, or one of our login screen UI's? If it's a browser prompt, then possible the incognito mode is causing this, and if you like, you can enable Anonymous Authentication for the site in IIS - when this is enabled, you should never see a browser prompt at all. If you do not want SAML auth for everyone, then you can do the following: 1. Ensure Anonymous Authentication for the site in IIS is disabled, and only Windows Authentication is enabled 2. Then create a User Account Policy on the screen Administration -> User Account Policies, select the SAML Authentication option, and then apply permissions to the policy for the users who are to receive it. If you get browser prompts because of disabling Anonymous Authentication for the site, please reference the following forum post for this - https://www.clickstudios.com.au/community/index.php?/topic/152-why-am-i-being-prompted-to-enter-my-authentication-details/ We hope this helps. Regards Click Studios Link to comment Share on other sites More sharing options...
jpope Posted April 25, 2019 Share Posted April 25, 2019 Hey Click Studios, I'm one of Stephen's coworkers and the one setting up our new instance. We're on build 8627, for reference. I am attaching a recording of the double-hop behavior we're reporting when Manual AD Authentication is the default option and we attempt to login via SAML2 (PasswordStateOktaRequire2Tries.gif), and the fact that SAML2 authentication is grayed out for the user (PasswordStateSAMLBlankedOutForUser.png), and also not an option for User Account Policies (PasswordStateMissingSAMLOptionUserAccountPolicy.png). I have changed the default authentication option on our test system to SAML2 and it works as expected, but since we might have to have 2 separate policies where some users have SAML2 and some only have Manual AD Authentication, I would like to know if the missing SAML2 option for the User Account Policy issue is a bug or not. I realize we can have the default option be SAML2 and set a User Account Policy to the AD group we want to use manual AD authentication, but this seems like a bug that could be detrimental to other customers. Is this intentionally not on the dropdown list for User Account Policies authentication options? Thanks, Jeremy Link to comment Share on other sites More sharing options...
support Posted April 25, 2019 Share Posted April 25, 2019 Hi jpope, I think the issue here is that you do not have SAML authentication selected in Passwordstate - let me explain. By default, Passwordstate is installed with Anonymous Authentication enabled in IIS. When configured this way, you cannot have 'per user' authentication options, and instead you need to enable SAML Authentication System Wide - this can be done on the screen Administration -> System Settings -> Authentication Options tab. If you want 'per user' authentication options, then you need to disable Anonymous Authentication for the site in IIS, and only leave Windows Authentication enabled - this means you could not use Passwordstate from non-Windows machines. You may also get prompted for domain authentication, and the following article will help with this https://www.clickstudios.com.au/community/index.php?/topic/152-why-am-i-being-prompted-to-enter-my-authentication-details/ Once Windows Authentication is set, users can select SAML on their Preference screen, or you could use a User Account Policy for this. I hope this helps. Regards Click Studios Link to comment Share on other sites More sharing options...
jpope Posted April 26, 2019 Share Posted April 26, 2019 Hey Click Studios, You are correct that we didn't have SAML authentication for the gif I posted, I later said in the post that when I do have SAML authentication enabled (with Anonymous Auth in IIS enabled) that it works as expected. Our environment is a mix of Windows and non-windows devices, so Anonymous Authentication is a must in our environment. Our desired end goal is to have our current/future users to login seamlessly with SAML provided by Okta, but to allow the future case where we may add special user(s) to a group that support different login methods, most likely Manual AD authentication, without interrupting the login process for other users. 3 issues/possible bugs that we are seeing: SAML isn't a choice for User Account Policy Authentication Method, is this intentional? (Picture on our dev instance on build 8627: https://www.clickstudios.com.au/community/uploads/monthly_2019_04/PasswordStateMissingSAMLOptionUserAccountPolicy.png.7d8edbd84f340307a0076676e3a64b5b.png) If Manual AD is default, but a user attempts via SAML (in Okta), it will work after either 2 tries. This is the issue Stephen was originally reporting, and we suspect this is due to a session value not being established for that computer until the user/computer lands at the login page, and a second login attempt via SAML uses that existing session to successfully pass the SAML login attempt. (Viewable here: https://www.clickstudios.com.au/community/uploads/monthly_2019_04/PasswordStateOktaRequire2Tries.gif.5bf4a0b6434c2ec285eca4186cea8d59.gif) If SAML is default, login works immediately as intended, but there would be no way for non-SAML users to log in since it would redirect the page to the Okta sign-in page. Other applications like Microsoft's Office 365 and Google Suite fix this by reading the username and when the user changes the active field to the password page, it runs a check on the username to see if it requires SAML login for that ID. Is it possible to fix this in a future build? We have about a month before we launch the production replacement instance so we have some time to go over this, but it really would be great if we can support seamless SAML login for the majority of our employees and the possiblity of separate login types for edge case users. I'm hoping we can get this resolved, your team has already done some amazing fixes for us in the past (including the new build released today with the Pending Access Request database integrity issue fixed). If there is anything I can clarify, let me know. Thanks, and have a good weekend. Link to comment Share on other sites More sharing options...
support Posted April 26, 2019 Share Posted April 26, 2019 Hi jpope, Thanks, and due to your mixed environment, we're sorry but it's not possible to have SAML authentication for some users, and not others. When Anonymous authentication is enabled in IIS, the user is not known until they authenticate - which is why it's not possible to differentiate between different users until they authentication. I hope this makes sense, and sorry for the technical limitations here. Regards Click Studios Link to comment Share on other sites More sharing options...
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now