Recently, during the upgrades to eduVPN 2.0, we’ve been having some trouble with the mod_auth_mellon Apache module.
- The Debian package generates invalid signatures over
AuthnRequestmessages which wasted a lot of time debugging (issue reported to the Debian package maintainer)… - Mellon does NOT properly support
eduPersonTargetedID(serialization) - Mellon does NOT check the “scope” of attributes against the IdP metadata
<shibmd:Scope>attribute.
This is not a problem for simple deploys when using a single IdP, or when using a SAML proxy, i.e. a hub & spoke federation, where there is some control and enforcement of the attributes received by the SP. Then Mellon is actually a good choice as it is relatively easy to configure.
For mesh federations this does not really suffice. One has to be able to rely on the attribute values without needing to implement e.g. scope validation or eduPersonTargetedID validation/serialization in the application code.
If possible install and use Shibboleth. This is supported by eduVPN 2.0. Setting up Shibboleth can be complicated, the exact details are out of scope of the eduVPN project. We did make documentation available here on how to configure Shibboleth and eduVPN. You can contact your identity federation for federation specific instructions if these instructions do not suffice.
We are currently working on native SAML support for eduVPN 3.0. We will see if this covers all the cases we require and which are currently supported by Shibboleth, if not, we’ll retain Shibboleth support as an option. The plan is to drop support for Mellon in favor of the native SAML support, making SAML configuration a lot easier.
To sum up: if you are part of a mesh federation, please do not use Mellon and switch to Shibboleth.
Add Comment