Jump to content

NameID attribute returned was not found in the Passwordstate database - Possible to auto-provision SAML User?


jtstuedle

Recommended Posts

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.

Link to comment
Share on other sites

Hello jtstuedle,

 

The only feature we have for automatically creating User Accounts in Passwordstate is when you synchronize Active Directory Security Groups - for On Premise AD.

If you need some sort of feature for this, then we can move this post into the Feature Requests area of the forums?

Regards

Click Studios

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

15 hours ago, support said:

Hello jtstuedle,

 

The only feature we have for automatically creating User Accounts in Passwordstate is when you synchronize Active Directory Security Groups - for On Premise AD.

If you need some sort of feature for this, then we can move this post into the Feature Requests area of the forums?

Regards

Click Studios

 

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!

Link to comment
Share on other sites

58 minutes ago, Moiz V said:

 

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.

 

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!

Link to comment
Share on other sites

  • 1 year later...

+1 For this. Having the option to auto provision PWS users (even if the group allocation suggestion isn't there). At least we can have a user login, have the user acc created and they can at least have their personal password list created for them (using the existing options).


TJ 

Link to comment
Share on other sites

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 account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...