Just a note that Odum has been running 3.0.2 since August; the only issues we've noticed are deprecation notices about certain config elements.

@donsizemore - any interest in making a pull request?

@donsizemore - thanks for the PR; was it really as simple as upgrading the package? Did you have to tinker with the settings in your old config files at all?
(When I saw your earlier comment about "deprecation notices about certain config elements", I may have assumed you had to actually make some config changes... but if not, that would be really great to hear!)

@landreev well, if the upgrade were more difficult I couldn't have done it =)

For at least the 2.6 => 3.0 upgrade Shibboleth promises backwards compatibility but crabs:

WARN Shibboleth.Config : DEPRECATED: legacy 2.0 configuration, support will be removed from a future version of the software
WARN Shibboleth.RequestMapper : DEPRECATED: legacy 2.0 configuration, support will be removed from a future version of the software

Whether that configuration change should be included in this issue or left to the end-user (as much of the Shibboleth configuration is by necessity) is you all's' decision, but I'd personally want the security fixes in the newest Shibboleth version (for Odum, 3.0.2).

Just a note that I have a test system's Shibboleth 3.0.2 installation launching without complaint by modifying our shibboleth2.xml file per https://wiki.shibboleth.net/confluence/display/SP3/UpgradingFromV2

YMMV, but a diff shows my only changes are the urn:mace:shibboleth version change and the MetadataProvider file/path switcheroo. The test system is https://dataverse-test.irss.unc.edu if'n you'd like to try it.

To rehash: at the last standup we've decided to keep this issue open and to use it to track the process of upgrading our Shibboleth setup to v.3.
The next step will be to test the upgrade, using the advice from @donsizemore, above (thanks Don!). We can do this on demo.dataverse.org - since it's already plugged in to the Harvard shib framework. Hopefully it'll be just as straightforward as it was for Don.
Once it's tested on demo, we can upgrade it on our production nodes.

3.0.3 is out; I'm waiting for RPMs to show up in their yum repo. appears to be bugfix-only:
https://issues.shibboleth.net/jira/browse/SSPCPP-845?jql=filter%3D12573%20
update: I now see that it fixes a DoS in the date/time field.

Just a note that Shibboleth released 3.0.4 yesterday to fix a DoS vuln; Odum is running happily on 3.0.4 since then.

@donsizemore thanks. What's the status of pull request #5397 ? This issue is in "Ready" from the perspective of https://waffle.io/IQSS/dataverse

we've decided to keep this issue open and to use it to track the process of upgrading our Shibboleth setup to v.3.

@landreev @djbrooke does this mean we should create an issue over at the new https://github.com/IQSS/dataverse.harvard.edu/issues issue tracker?

#5397 is ready from my perspective; it's what I needed to do to suppress deprecation warnings during Shibboleth launch. However, we note in the documentation that each shibboleth.xml will be something of a snowflake.

The CVE describes all versions of Shibboleth prior to 3.0.4 as vulnerable to the DoS attack...

@donsizemore thanks. I guess one way of thinking about this issue is that by including yum install shibboleth-2.6.1 at http://guides.dataverse.org/en/4.11/installation/shibboleth.html#install-shibboleth we are basically encouraging Dataverse installations to use an old version of Shibboleth with a known CVE while you're happily using the newer patched version of Shibboleth in production with no problems. Your pull request fixes that page in the docs. It also updates the version in the main shibboleth.xml example we provide. Should the ADFS example be updated as well? This was added later in pull request #5494.

ADFS example piggybacks off the yum parts from the main guide; so probably doesn't need updates. If I'm remembering correctly, that was tweaked sufficiently to make the shibd warnings go away.

@landreev @pdurbin - so this issue can be moved across the board, reviewed, and QA'ed, and then we have a separate issue in dataverse.harvard.edu repo for the upgrade to Harvard Dataverse? Sounds good to me, just want to make sure I'm understanding. Thanks @donsizemore for the PR!

@djbrooke Correct, that sounds like the way to go.

Done, created IQSS/dataverse.harvard.edu#5

In edc0353 I merged develop into the branch to pick up the ADFS config and learned that it's already using shibboleth:3.0 so it's all set and matches the main config example.

@kcondon - hm. I'll defer to @landreev and @pdurbin on whether we want to do any tire kicking now, or if the code review and the fact that @donsizemore has been running it in prod for a few months is sufficient. Anyway, I'd lean towards no further kicking right now, but let me know if I'm missing something.

Another data point is that I asked @pameyer yesterday if he's using Shib 2 or 3 in his testing. He's using Shib 3 and sees no reason to use Shib 2. The pull request is about no longer encouraging installations to use Shib 2.

When I posted that for some reason my ticket view only showed your testing comment Danny. I've since independently seen the upgrade link and it appears to require 2 things: 1. yum install and 2. change version in shib2.xml. Generally, I like dev to look it over for potential issues before I get it but let's fire away!

Actually, we are already running shib 3 in production.
Of course it's still running (and appears to be working) with the old config file. But it apparently had the "path=" attributes in it (instead of "file=") all along. The other change we are recommending in the guide appears to be for the config file schema version:

urn:mace:shibboleth:3.0:native:sp:config

and that's still set to 2.0 in production.

We can double-check on all this before closing the other issue, IQSS/dataverse.harvard.edu#5.

The config file we are using in prod. and on demo also has "2.0" in the actual MetadataProvider/saml configuration:

<DiscoveryFilter type="Whitelist" matcher="EntityAttributes">
                <saml:Attribute
                    Name="http://macedir.org/entity-category-support"
                    NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri">
                    <saml:AttributeValue>http://id.incommon.org/category/research-and-scholarship</saml:AttributeValue>
                </saml:Attribute>
                <saml:Attribute
                    Name="http://macedir.org/entity-category-support"
                    NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri">
                    <saml:AttributeValue>http://refeds.org/category/research-and-scholarship</saml:AttributeValue>
                </saml:Attribute>
            </DiscoveryFilter>

Is this ok?

@landreev I only made changes per ttps://wiki.shibboleth.net/confluence/display/SP3/UpgradingFromV2

I'm currently using NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri" in my DiscoveryFilters and Shib 3.0.4 doesn't crab about them on launch.

Same here - our Shib 3.0.3 seems to be running just fine with the DiscoveryFilter section above.