I am working on setting up SAML in ES 6.2, which will use Shibboleth and InCommon federation. I have gotten something working for SSO and now want to get MFA (multifactor authentication going).
I do have MFA working with a shib SP in 6.1, which is more like an overlay on top of ELK. There it is setup in /etc/shibboleth/shibboleth2.xml by adding authnContextClassRef="http://id.incommon.org/assurance/mfa" to the XML SAML2. Not seeing how to do this, or something like it, in ELK 6.2. This doesn't fit with the SP setup, the saml-elasticsearch-metadata.xml.
You shouldn't need to do anything inside the Elastic stack. Enabling MFA ought to be entirely an IdP issue, not a SP problem. It is true that an SP can request to have a higher degree of assurance, but an IdP should not require that SPs ask for it. If the local policies require that all identity should be proven by multiple factors, then it is entirely within the IdP's role to mandate that, regardless of what SPs ask for.
Shibboleth is a bit of a beast to configure, but it is my understanding that you can enforce MFA on a service-provider basis, user basis, or across the whole IdP if you wish, but I'm afraid that configuring Shibbolth is way outside the scope of the advice we can provide here.
That said, if you want to edit the metadata generated the saml-metadata tool, then you are free to do so. It won't break anything inside Elasticsearch (obviously, if you make a mistake then it could cause issues fo the IdP-SP integration, but then you can just revert your changes and reload it).
Requesting an authentication context is something that a Relying Party is allowed to do in SAML 2.0 . Authentication Context is described here and the use of it for an SP to request a specific authentication method ( or MFA in this case ) in our case is in sections 3.4.1 and 3.3.2.2.1 of SAML 2.0 Core.
This requires three things:
That the Relying Party is able to set RequestedAuthnContext in the Authentication Request
That the Identity Provider will try to grant the request if supported and will denote the outcome in the SAML Response
That the Relying Party will validate the AuthnContext of the SAML Response and act accordingly, granting or refusing access.
Tim is right that usually (and especially outside the SAML or SSO world ) the use of MFA is decided by the security policy of the Identity Provider and not by the request of a web application but I understand that Dirk wants to implement the InCommon MFA Profile which similar to Refeds MFA Profile defines some interoperability rules for how the above can be used for MFA in an Identity Federation context.
We do not currently support configuring RequestedAuthnContext for authentication requests in our SAML implementation, so I would encourage you to fill in an enhancement request if this is something you need.
As @TimV mentioned, you can configure Shibboleth IDP for mfa even without the Relying Party requesting it with a Relying Party override for the Elastic Stack SP. I am not sure you could do that with metadata as I'm not aware of a profile extension that would allow to indicate a RequestedAuthnContext in the SPSSODescriptor. Please be aware though, that the Elastic stack SP will not evaluate the AuthnContext that the IDP will return in the SAML Response.
Thanks Tim and Ikakavas for your comments.
I do need MFA, it's a requirement for our implementation.
At IU (Indiana University), it's a requirement for all systems and services
to use MFA, which is a policy from our CIO and Security Office.
And the security officer is the executive director of OmniSOC (http://omnisoc.iu.edu).
I will see about getting the MFA configuration done on the IDP side.
Meanwhile, we need to get an enhancement request in for ES to add this in
as a supported feature on the SP side.
Let me know if there is anything else for me todo at this point.
Apache, Apache Lucene, Apache Hadoop, Hadoop, HDFS and the yellow elephant
logo are trademarks of the
Apache Software Foundation
in the United States and/or other countries.