search

identinetics / saml2test2

Saml2 verification tool based on the aatest framework
Other
3 stars 0 forks source link

Add test for SP to validate forceAuthn #58

Open ergood opened 8 years ago

ergood commented 8 years ago

In the discussion of IdP supporting and SP validating AuthnContextClassRefs (issues #53 and #54), it was noted that while there is a requirement in the profile for supporting forceAuthn on the IdP side, we don't have any requirement listed (and therefore potentially no test developed) to ensure that SPs requesting forceAuthn are also able to enforce that forceAuthn took place; e.g. by testing against authnInstant or otherwise.

(n.b., please let me know if this should actually be a comment in the Kantara profile section; I put it here because of the reference to the other tests that we discussed at the same time).

rhoerbe commented 8 years ago

This is possible in principle by asserting that a request with forceAuthn is triggering a login flow. However with the restriction that forceAuthn is not generally testable because it does not prescribe a specific behavior, e.g. with 2FA or Kerberos. OTOH, testing for a fresh authnInstant should be easy, but we should discuss if this is good enough in all cases.

ergood commented 8 years ago

I agree that from a deployment standpoint, just checking authnInstant is insufficient to prove that the IdP did "the right thing" in all cases. But it seems that this is a minimum technical requirement for the SP in a case where the SP and IdP agree on what "meeting forceAuthn requirements" means.

Recall that in the FIWG profile we didn't require anything technically beyond "The authentication mechanisms within an [IdP] implementation MUST have access to the ForceAuthn indicator so that their behavior may be influenced by its value.", this in requirement IIP-IDP08. To me this (proposed) test of SP functionality is roughly equivalent in rigor to what we require of the IDP.

nckroy commented 8 years ago

Does this mean that the test suite has to know to replay a password into a form or SPNEGO popup slower than, say, a kerberos ticket can get revalidated? That seems... tricky at the least, and not a very reliable way to test things.

On Wed, Oct 12, 2016 at 9:42 AM Eric Goodman notifications@github.com wrote:

I agree that from a deployment standpoint, just checking authnInstant is insufficient to prove that the IdP did "the right thing" in all cases. But it seems that this is a minimum technical requirement for the SP in a case where the SP and IdP agree on what "meeting forceAuthn requirements" means.

Recall that in the FIWG profile we didn't require anything technically beyond "The authentication mechanisms within an [IdP] implementation MUST have access to the ForceAuthn indicator so that their behavior may be influenced by its value.", this in requirement IIP-IDP08. To me this (proposed) test of SP functionality is roughly equivalent in rigor to what we require of the IDP.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/identinetics/saml2test2/issues/58#issuecomment-253251423, or mute the thread https://github.com/notifications/unsubscribe-auth/ADXL4PPz5erx0iN0uIJtdrfB4vT-nI3Aks5qzP_0gaJpZM4KTE59 .

rhoerbe commented 8 years ago

html-based forms can be feeded using python's robobrowser module, an example for a default shib idp login/consent is part of the test config. Other interactions may be more complex; the plugin-design does allow to use Selenium in addition, which is more powerful. But that is not in the current plan.

ergood commented 8 years ago

@nckroy That's not the suggestion I was making. Perhaps the use of the term forceAuthn is confusing the point, because while this is in support of forceAuthn, it's not about testing forceAuthn context. I mean:

"Present a valid assertion with an older AuthnInstant to the SP. Verify that SP (can be configured to) reject(s) the assertion based the AuthnInstant being too old."

My assumption is that a deployer would leverage this feature (test AuthnInstant) potentially in combination with validating the AuthnContextClassRef (issue #54) to support "forceAuthn" in a "real world" scenario.

I know there are SPs out there that can be configured to request forceAuthn but that cannot be configured to test the returned assertion to verify that authentication instant is current (for any definition of current), which is an incomplete implementation at the SP. This (requested) test is intended to identify SPs with this limitation.

nckroy commented 8 years ago

OK, that makes sense.

On Wed, Oct 12, 2016 at 11:24 AM Eric Goodman notifications@github.com wrote:

@nckroy https://github.com/nckroy That's not the suggestion I was making. Perhaps the use of the term forceAuthn is confusing the point, because while this is in support of forceAuthn, it's not about testing forceAuthn context. I mean:

"Present a valid assertion with an older AuthnInstant to the SP. Verify that SP (can be configured to) reject(s) the assertion based the AuthnInstant being too old."

My assumption is that a deployer would leverage this feature (test AuthnInstant) potentially in combination with validating the AuthnContextClassRef (issue #54 https://github.com/identinetics/saml2test2/issues/54) to support "forceAuthn" in a "real world" scenario.

I know there are SPs out there that can be configured to request forceAuthn but that cannot be configured to test the returned assertion to verify that authentication instant is current (for any definition of current), which is an incomplete implementation at the SP. This (requested) test is intended to identify SPs with this limitation.

— You are receiving this because you were mentioned.

Reply to this email directly, view it on GitHub https://github.com/identinetics/saml2test2/issues/58#issuecomment-253279961, or mute the thread https://github.com/notifications/unsubscribe-auth/ADXL4MjS3hkvUIamLr8In5nXWFwWGfkkks5qzRfhgaJpZM4KTE59 .