-
Notifications
You must be signed in to change notification settings - Fork 474
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
SAML provider returned Responder error: NoAuthnContext #226
Comments
Thank you, @garycjohnson ! You saved me probably hours of work looking up ways to fix this :) |
disableRequestedAuthnContext: true|false By default only Password authmethod is accepted, this option allows any other method. Issue and option described here: node-saml/passport-saml#226 Signed-off-by: Emmanuel Ormancey <emmanuel.ormancey@cern.ch>
So what's the preferred solution currently?
authnContext: [
'urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport',
'urn:oasis:names:tc:SAML:2.0:ac:classes:X509'
]
|
For reference: ERROR: "AADSTS900235: SAML authentication request's RequestedAuthenticationContext Comparison value must be 'exact'. Received value: 'Minimum'." while login through SAML authentication after upgrade to 10.5. May 22, 2021•Knowledge 000165371 AADSTS900235: SAML authentication request's RequestedAuthenticationContext Comparison value must be 'exact' LDAP Type: Microsoft Active Directory Environment variable ACJVMCommandLineOptions=-DINFA_SAML_REQ_AUTH_CXT_COMP=Exact was also set. Enable Authorization Context Comparison value was set to MINIMUM in the admin console under Under SAML Configuration.
May 22, 2021•Knowledge 000165371 AADSTS900235: SAML authentication request's RequestedAuthenticationContext Comparison value must be 'exact' LDAP Type: Microsoft Active Directory Environment variable ACJVMCommandLineOptions=-DINFA_SAML_REQ_AUTH_CXT_COMP=Exact was also set. Enable Authorization Context Comparison value was set to MINIMUM in the admin console under Under SAML Configuration.
|
Being explicit about what you want is always the better option. I would personally favor this instead of turning the feature off or generally allowing |
That statement is extremely vague and doesn't tell anything specific on the actual rationale, etc. Contrary, being explicit results in issues with stuff like Active Directory, as the topic starter has reported.
Again, that's just personal preference. No rationale provided. FYI: We're now attempting to turn on the The rationale is that one of the clients — an Active Directory administrator — has specifically suggested that we do that:
|
Please close this issue - I'm only raising it as a record of an issue I've been fighting with for the last few days with integrating to a client's ADFS server in the hope it might help someone else in future.
We've developed a multi-tenant app that uses passport-saml to support SAML integration into various client's ADFS servers for identity. This was working fine for many clients and then we had a strange issue.
For one client they could authenticate absolutely fine when logging in from outside their corporate network (e.g. through smartphone browser) but when logging in on their corporate network we got this error from passport-saml:
SAML provider returned Responder error: NoAuthnContext
Same users - same ADFS server - different behaviour if outside or inside their corporate network.
After much struggling it was discovered that passport-saml by default includes a
RequestedAuthnContext
of "PasswordProtectedTransport" (PPT). The clients AD FS was setup such that requests coming from within their corporate network did not support PPT and insisted that the Windows Federation Authentication protocol be used for the authentication context.passport-saml was requesting that only the PPT authentication context be used and this was causing our error
NoAuthnContext
.Fortunately, passport-saml has an easy fix for this ... you need to set the option:
disableRequestedAuthnContext: true
when setting up your SAML passport strategy. By doing this the SAML request will not request any particular authentication context and allow ADFS to make its own decision.
Problem solved.
The text was updated successfully, but these errors were encountered: