Jump to content

jtstuedle

Members
  • Posts

    6
  • Joined

  • Last visited

jtstuedle's Achievements

Newbie

Newbie (1/14)

1

Reputation

  1. 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 ticket, remove any groups that don't exist in their SAML ticket). I replied back to support and asked to have this thread moved over to the feature request section! Interested to see if they decide to move forward with developing this functionality or not!
  2. 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 example). This functionality creates a more seamless experience for both system admins and end users in a lot of different use scenarios. Ideally, Passwordstate would read the groups claims from the SAML ticket and map those claims back to both Local Security Groups and sync'd AD Security Groups. Maybe give the option to only look for specific groups from SAML users (perhaps a new class of group - Automatically Detected Security Groups)? Just throwing the idea out there. https://jumpcloud.com/blog/jit-provisioning-defined I'm happy to help beta-test and provide feedback onthis if you guys consider the feature for development! Thanks!
  3. 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.
×
×
  • Create New...