Roman

Hi all,
 
I got this to work in our lab environment and thought I'd share some of that setup.
We have not setup the app service yet, so I can't comment on that.
This isn't a full guide on how to configure Azure AD, Enterprise Applications, the Azure App Proxy Connector or anything like that. It's just the settings that worked for us to make the Passwordstate web interface accessible to external users via the Azure Application Proxy with SAML SSO and Conditional Access policies.
 
As "<BaseURL>" we'll be using "https://passwordstate-<account>.msappproxy.net" where <account> is whatever Microsoft is using for your account there. Obviously you can change 'passwordstate' to something else as well.
 
Azure - Application Proxy configuration
We configured the Azure Application Proxy with identical domain names for internal and external users to ensure links sent our by Passwordstate will just work:
Internal Passwordstate URL: <BaseURL>
External Passwordstate URL: <BaseURL>
 
Pre Authentication is set to Azure Active Directory. We want SAML SSO, after all.
We enabled HTTP-Only, Secure and Persistent Cookies in our lab environment. However, when it comes to Persistent Cookies, you may want to change that to No for a production environment.
 
As we're using the same URLs for internal and external there's no need for URL translation, so we disabled it for Header and Application Body.
 
Azure - Single sign-on configuration
Basic SAML Configuration
Identifier (Entity ID): <BaseURL>
Reply URL (Assertion Consumer Service URL):
<BaseURL> Tick the Default checkbox on this one <BaseURL>/logins/saml/default.aspx Sign on URL: <BaseURL>
Relay State: <BaseURL>/logins/saml/default.aspx
Logout URL: <BaseURL>/?appproxy=logout
 
Attributes & Claims
Unique User Identifier: user.userprincipalname
We didn't change any of the other ones.
Note that you can use user.mail, as per Clickstudio's own Blog. We switched to userprincipalname as we are testing with accounts without email addresses, so this made more sense for us.
Using userprincipalname also requires you to reconfigure Passwordstate and under System Settings -> Authentication Options check the UserPrincipalName option under "Select which field in Passwordstate you want to compare against the SAML Response's Name Identifier - NameID".
 
For the remainder of the Azure (and Passwordstate SAML) configuration, just follow Clickstudio's guide: https://blog.clickstudios.com.au/saml-authentication-with-azure-ad/
Ensure to reconfigure your Base URL in Passwordstate under System Settings -> Miscellaneous to match your <BaseURL>.
 
Certificates
We created a certificate for our internal server using our existing, internal CA.
Doesn't cost anything and we have more control over certificate lifetime and auto-renewal.
 
If you go with a 'proper' custom domain setup (e.g. using https://passwordstate.<domain> for internal and external URL) for the App Proxy, you'll need a public CA certificate to be imported into the App Proxy.
 
Internal DNS
We created a DNS Zone on our internal DNS server to ensure internal systems resolve passwordstate-<account>.msappproxy.net to the internal IP of the Passwordstate server. You can probably force internal users through the Azure App Proxy as well, but at the very least the Azure App Proxy (and the internal Passwordstate server itself) needs to be able to resolve the name to the internal IP of the server or it won't be able to connect.
 
IIS
Ensure to configure your IIS Bindings to use the passwordstate-<account>.msappproxy.net FQDN and assign the correct certificate.
We also disabled Windows Authentication for the passwordstate site as it's not required.
 
 
That's it, SAML SSO should work and you can configure your Conditional Access policies as required.
As mentioned, this isn't a full guide. You need to have your Azure Application Proxy Connector setup and operational, it needs to be able to access the Passwordstate server, the relevant outbound ports/IPs/FQDNs need to be allowed on the firewall, etc.
 
I hope this helps someone else to get their setup working.

Hi all,
 
I got this to work in our lab environment and thought I'd share some of that setup.
We have not setup the app service yet, so I can't comment on that.
This isn't a full guide on how to configure Azure AD, Enterprise Applications, the Azure App Proxy Connector or anything like that. It's just the settings that worked for us to make the Passwordstate web interface accessible to external users via the Azure Application Proxy with SAML SSO and Conditional Access policies.
 
As "<BaseURL>" we'll be using "https://passwordstate-<account>.msappproxy.net" where <account> is whatever Microsoft is using for your account there. Obviously you can change 'passwordstate' to something else as well.
 
Azure - Application Proxy configuration
We configured the Azure Application Proxy with identical domain names for internal and external users to ensure links sent our by Passwordstate will just work:
Internal Passwordstate URL: <BaseURL>
External Passwordstate URL: <BaseURL>
 
Pre Authentication is set to Azure Active Directory. We want SAML SSO, after all.
We enabled HTTP-Only, Secure and Persistent Cookies in our lab environment. However, when it comes to Persistent Cookies, you may want to change that to No for a production environment.
 
As we're using the same URLs for internal and external there's no need for URL translation, so we disabled it for Header and Application Body.
 
Azure - Single sign-on configuration
Basic SAML Configuration
Identifier (Entity ID): <BaseURL>
Reply URL (Assertion Consumer Service URL):
<BaseURL> Tick the Default checkbox on this one <BaseURL>/logins/saml/default.aspx Sign on URL: <BaseURL>
Relay State: <BaseURL>/logins/saml/default.aspx
Logout URL: <BaseURL>/?appproxy=logout
 
Attributes & Claims
Unique User Identifier: user.userprincipalname
We didn't change any of the other ones.
Note that you can use user.mail, as per Clickstudio's own Blog. We switched to userprincipalname as we are testing with accounts without email addresses, so this made more sense for us.
Using userprincipalname also requires you to reconfigure Passwordstate and under System Settings -> Authentication Options check the UserPrincipalName option under "Select which field in Passwordstate you want to compare against the SAML Response's Name Identifier - NameID".
 
For the remainder of the Azure (and Passwordstate SAML) configuration, just follow Clickstudio's guide: https://blog.clickstudios.com.au/saml-authentication-with-azure-ad/
Ensure to reconfigure your Base URL in Passwordstate under System Settings -> Miscellaneous to match your <BaseURL>.
 
Certificates
We created a certificate for our internal server using our existing, internal CA.
Doesn't cost anything and we have more control over certificate lifetime and auto-renewal.
 
If you go with a 'proper' custom domain setup (e.g. using https://passwordstate.<domain> for internal and external URL) for the App Proxy, you'll need a public CA certificate to be imported into the App Proxy.
 
Internal DNS
We created a DNS Zone on our internal DNS server to ensure internal systems resolve passwordstate-<account>.msappproxy.net to the internal IP of the Passwordstate server. You can probably force internal users through the Azure App Proxy as well, but at the very least the Azure App Proxy (and the internal Passwordstate server itself) needs to be able to resolve the name to the internal IP of the server or it won't be able to connect.
 
IIS
Ensure to configure your IIS Bindings to use the passwordstate-<account>.msappproxy.net FQDN and assign the correct certificate.
We also disabled Windows Authentication for the passwordstate site as it's not required.
 
 
That's it, SAML SSO should work and you can configure your Conditional Access policies as required.
As mentioned, this isn't a full guide. You need to have your Azure Application Proxy Connector setup and operational, it needs to be able to access the Passwordstate server, the relevant outbound ports/IPs/FQDNs need to be allowed on the firewall, etc.
 
I hope this helps someone else to get their setup working.