Jump to content


  • Content Count

  • Joined

  • Last visited

  1. Digging into the performance hit of very large password lists a little bit more to see if it's something specific to just my trial install. It looks like anytime you load the password grid up, the web UI queries the entire dataset from the database using the below query (and does the same for subsequent grid page changes - so moving from page 1 -> page 2 -> page 3 all seem to make repeatedly this same query). Executing the below SQL directly against a list with ~141k entries takes anywhere from 35-40 seconds to fully return the data. That's for every grid page change, too.
  2. Trialing Passwordstate in our environment. Expecting a large number of users so I’ve specced a webserver with 12GB of RAM, and a separate SQL DB server that has more than enough memory to load the entire DB in memory (128GB+). They’re on the same virtual host with a 10Gb connection between them. I’m pushing through some heavy use case testing and seeing some pretty slow grid load times on a password list with ~50k entries. Anywhere from 10-30 seconds on average to move between pages in the grid. I’ve triggered an issue twice now while using the APIs to rapidly load entries wh
  3. What if you never had to expose any portion of your PasswordState infrastructure directly? Any layer 7 load balancer should be able to add a layer of security here (I'd suggest the open source version of HAProxy if you don't have an existing load balancer for your external network). You can also use URL rewrite rules in IIS (look near the bottom of the MS page below) to restrict or allow specific IP addresses from accessing portions of the Passwordstate instance (the selfdestruct portal is self contained wholly to /selfdestruct/*). You can get pretty creativ
  4. I don't think a custom connector back to Okta (or any other identity provider really) would be necessary to make this work. If the user has a valid SAML or OIDC session, then Passwordstate can assume that the user successfully authenticated with the IdP and was redirected back to the application. At that point, any claims (groups, email, name) that exist in the SAML token could be treated as valid, and if the user doesn't exist in the database at that time, add-in some logic to create their user account in the DB, and then update their group membership (add new groups that exist in the SAML ti
  5. Let's move thread to the feature-request section if possible! Use-case for the just-in-time provisioning feature: If Passwordstate is deployed to a cloud instance, there's a good chance that a connection back to the on premise AD does not exist. This leaves me as a system administrator manually creating accounts inside of Passwordstate for each user (or scripting it). Supporting logic for the feature request: If the user has a valid SAML authentication token from the identity provider, then they've been granted access to the app in the identity provider (in Okta, for ex
  6. Using Okta as a SAML provider for PasswordState. Setup was smooth and easy (happy to provide a quick write-up on this if someone wants to publish it on the site). Upon login via the SAML provider, I'm getting a NameID attribute wasn't found in the PasswordState database. I've searched some forums and looked through system settings but don't see any option to "automatically create SAML user if the account does not exist" (or something to that effect). Other applications call this something like "just-in-time provisioning". Does Passwordstate have this feature? If not, feature reques
  • Create New...