OKTA SAML Settings

[Boffin]

I'm having great difficulty with passwordstate talking to Okta, and the example config in the password state docs for Okta is greatly lacking (missing 80% of the config values).

 

What happens is when I visit our local password state, it goes off to Okta, verifies, go back to passwordstate which then fires off to Okta again, etc etc etc 

 

Here is the config I currently have:

 

What the heck am I missing?  Plus where the heck in passwordstate can I see what I assume are the failed assertions?

 

 

OKTA CONFIG

Single sign on URL:    https://internal.pstate.example.com/logins/saml/default.aspx
Use this for Recipient URL and Destination URL: YES
Allow this app to request other SSO URLs: NO
Audience URI (SP Entity ID): https://internal.pstate.example.com/
Default RelayState: https://internal.pstate.example.com/logins/saml/default.aspx
Name ID format:        Unspecified
Application username:    AD user principal name
Update application username on:        Create and update
Response:                Signed
Assertion Signature:    Signed
Signature Algorithm:    RSA-SHA1
Digest Algorithm:        SHA1
Assertion Encryption:    Unencrypted
Enable Single Logout:   NO
Assertion Inline Hook:    None (disabled)
Authentication context class: PasswordProtectedTransport
Honor Force Authentication:    Yes
SAML Issuer ID:        http://www.okta.com/${org.externalKey}
-----------------------

PASSWORDSTATE CONFIG

Select which field in Passwordstate you want to compare against the SAML Response's Name Identifier - NameID: UserPrincipalName
After SAML Authentication:  -- Select Authentication Option -- (ie nothing)
X.509 Cert:  <from Okta >
Certificate Type: SHA1
IDP Target URL   https://company.okta.com/app/xxxxxxxxxxxxxxxxxxxxxx_passwordstate_1/exk1123123123123bks4x7/sso/saml
IDP Issuer URL:    http://www.okta.com/exk123123123123

------------------------------

WHAT HAPPENS when you visit https://internal.pstate.example.com/

GET to https://company.okta.com/app/xxxxxxx_passwordstate/exk1123123123123bks4x7/sso/saml?SAMLRequest=.........
POSTs to https://internal.pstate.example.com/
  302 -> /default.aspx
GET to https://internal.pstate.example.com/default.aspx
  302 -> /logins/saml.aspx?
GET to https://internal.pstate.example.com/logins/saml.aspx?
  302 -> https://company.okta.com/app/xxxxxxx_passwordstate/exk1123123123123bks4x7/sso/saml?SAMLRequest=......... (back to the beginning)
  
 

[support]

Hi Boffin,

 

We don't have all fields documented, as not all fields are required for SAML authentication to work. Below are some screenshots from our Okta account and Passwordstate - can you please doublecheck what you have?

 

Can you check all fields, including the certificate type, and Audience Restriction. Your 'Name ID format' setting in Okta seems to be blank as well, and you must specify an attribute which matches "SAML Response's Name Identifier - NameID" in Passwordstate.

 

We hope this helps.

 

[Boffin]

That's prety much exactly how I had it set up (SHA1 instead of SHA256, and upn instead of email), but it fails when set up exactly the same as yours.  I'm going to update our PSTATE to the latest/greatest tomorrow (hoping that also solves a problem with your Radius client sending an invalid field)

 

Where on the Passwordstate machine can I get logs of why it thinks it should go back to Okta to get credentials when Okta has provided them ?

 

[support]

Hi Boffin,

 

Did you also try specifying a value for "Name ID", as your output above says "Name ID format: Unspecified". If you've changed from SHA1 to SHA256, you might need to export the certificate again, and add that into Passwordstate.

What build of Passwordstate are you using? Earlier this year Microsoft did make a change during a Windows Update which did cause issues with older builds of Passwordstate?

There is no where in Passwordstate to get logs for this sort of thing unfortunately. Let us know what happens after your upgrade.

Regards

Click Studios