Are you open to a PR for supporting accountChooserUrl in IDP? I understand it's not strictly part of the SAML standard, hence the non-conformant naming.
Problem
There is an issue with Google's SAML implementation... it doesn't support force_authn. Which means if the only account you're logged into is a personal account... their saml endpoint will return a dead end 403 error.
Solution
The workaround, aside from begging for force_authn support, is to use the AccountChooser url... but that cant be done at the idp.sso_login_url or loginRequestOptions level, as the SAML2Request parameter needs to be encoded into the continue parameter...
I think that's a better implementation than the googleAuth: true the passport-saml fork did.
Alternative
Hijacking the 302 redirect after create_login_request_url... which is easier said than done as higher level modules sometimes need to support Express, Koa, Native, etc router implementations.
Source
Are you open to a PR for supporting accountChooserUrl in IDP? I understand it's not strictly part of the SAML standard, hence the non-conformant naming.
Problem
There is an issue with Google's SAML implementation... it doesn't support
force_authn. Which means if the only account you're logged into is a personal account... their saml endpoint will return a dead end 403 error.Solution
The workaround, aside from begging for force_authn support, is to use the AccountChooser url... but that cant be done at the
idp.sso_login_urlor loginRequestOptions level, as the SAML2Request parameter needs to be encoded into the continue parameter...I think that's a better implementation than the
googleAuth: truethe passport-saml fork did.Alternative
Hijacking the 302 redirect after create_login_request_url... which is easier said than done as higher level modules sometimes need to support Express, Koa, Native, etc router implementations.
Source