Jump to content

SAML2 Attribute and Claim Types

Recommended Posts



It would be helpful to be able to use something other than E-Mail-Addresses and Name ID as attribute and claim type when using SAML2 logon, more specifically be able to use the attribute UserPrincipalName or even better the SamAccountName attribute.


In our PasswordState setup we use different accounts for different security privileges for the same person, for example, when doing regular IT work you logon with your standard user account which has permissions for password lists but when performing SysAdmin work you logon with your SysAdmin account. Both of these accounts are AD accounts with different SamAccountName/UserPrincipalName but share the same firstname.lastname@domain.tld email address. This makes it impossible for us to use SAML2 at the moment as PasswordState can't differentiate between these two accounts and logs you on to only one of them.


It would also be nice to be able to logon to a local PasswordState account (other than emergency) when using SAML2 logon, if for example the ADFS is unavailable or something similar.

Link to comment
Share on other sites

Hi Guys,


Just to confirm, only one value can be passed back from the SAML provider, but you want to be able to select in Passwordstate which value that is i.e. EmailAddress, UserID (SamAccountName) or UserPrincipalName ?

We could either allow you to specify which one you want, or instead do a 3 way match against the database i.e. the SQL WHERE clause could look at all 3 - do you think the SQL WHERE clause would be the best option?

Also, it wouldn't be possible to allow logins with Local Accounts, as we would need to present the Login screen for you to select this - which would obviously interfere with the standard SAML workflow which immediately redirects you to the SAML provider.


Click Studios

Link to comment
Share on other sites

  • 2 weeks later...

Hi and sorry for the late reply!


In my opinion the first choice is the best one, being able to select which value to validate against is much better for control.

The SQL WHERE option would still cause us issues since it would match the first email it finds when multiple accounts have the same email address, email address can be the same for multiple AD accounts where SamAccountName and UserPrincipalName are unique to specific accounts.


Best Regards


Link to comment
Share on other sites

  • 3 weeks later...

Hi Christopher, We've released a new build today with a fix for this.  This is the fix directly from our changelog:


"SAML Authentication can now be based on either the UserID, EmailAddress or UserPrincipleName fields in the database"


Please upgrade when you get a chance to 8488 and you should now be able to take advantage of this:)


Thanks again for your suggestion.





Link to comment
Share on other sites


This topic is now archived and is closed to further replies.

  • Create New...