Moiz V
-
Posts
10 -
Joined
-
Last visited
Posts posted by Moiz V
-
-
-
-
-
Hello,
I looked through the forums but couldn't find a submission, so I decided to create this.
Can I please request that you add the capability to poll the remote site location agents' health status as well as the last poll time, via the API? It looks like the API methods recently added for the RSL feature don't have this functionality as of PasswordState v9.4 build 9414.
-
-
On 3/18/2021 at 12:03 PM, jtstuedle said:
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 request?
Error I'm getting back from Passwordstate: It appears your account has successfully authenticated to the SAML Identity Provider, but the NameID attribute returned was not found in the Passwordstate database. Obviously I can create this user in the Database, but with a large number of users this seems counter-intuitive to just auto-creating upon login from the identity provider.
If Okta is just a SAML provider and on-prem AD is the identity source, you can just enable the feature to auto-create AD accounts in PasswordState when you sync Security Groups? The user should be able to login after an Okta delta-sync runs.
Otherwise, if Okta is the identity source, this is probably a feature request since it'd require some sort of custom connector with Okta via their API.
-
Honestly, the main reason is that we now have to secure access to the SQL database server. If the Passwordstate database is co-located with other databases (typically to make maximum use of Microsoft's expensive per-core SQL licensing) this now expands the potential attack surface of the environment to "everything that uses SQL" instead of just Passwordstate.
Also ideally you want one-way communication from PasswordState web server (trusted) to Self-Destruct server (untrusted) only. I get that this still means there's an SQLite database sitting on the Self-Destruct server in some form (ideally only containing the SelfDestruct and QueuedEmail tables), but at least a compromise means 0 access to the rest of the PasswordState database, as well as potentially other databases.
Just my $0.02.
-
On 3/16/2021 at 4:55 PM, support said:
In theory, you could use an account which only has read access to the database, but there are a couple of tables which would require separate 'UPDATE' permissions to those tables only i.e. SelfDestruct and QueuedEmail. Is that acceptable, because in theory the other tables could still be read? We'll try and have a look to see if access can be removed from all other tables, but it might take us some time to look into that.
I think this would be reasonable if we can lock down access only to the specific tables required.
-
Hey guys, I would just like to echo the OP; it seems like a serious security regression.
Are you guys willing to provide details of the pentesting that was done along with who did it? For a security product I think that'd be pretty important.
Also, is there any capability to use a read-only SQL account from Self Destruct to the passwordstate database and\or limit permissions in SQL in any other way?
REST Methods for Modify (and Delete) on Folders/Passwordlists
in Feature Requests
Posted
+1