Shibboleth Version 4 Upgrade

[Cantor, Scott]

> To elaborate further, we were able to find exact information such as database
> and server requirements for version 3 but not for version 4.

If you can find me a page in the V3 wiki space that is not readily obvious in the V4 wiki space I can speak to it. Our system requirements are spelled out in lots of detail.

> 1. Do you have documentation or advice on converting from file storage to DB
> storage for shib implementations?

There is not now, nor has there ever been, a "file storage" notion. So I don't know to what you're referring exactly. The "database storage" feature we have is a) not something you should use or need to use, but b) is still there.

The JPA storage option that is built in was, however, deprecated and replaced with the JDBC plugin [1] and should be used instead, they're basically the same minus needing Hibernate. However, neither is really needed and you shouldn't use them unless you have an extremely good reason. And then you should change your reason.

[1] https://shibboleth.atlassian.net/wiki/spaces/IDPPLUGINS/pages/2989096970/JDBCStorageService

> 2. What database systems does Version 4 support?

We have never supported anything explicitly. We provide no JDBC drivers and do not constrain what people want to use, you supply your own driver and are responsible for all aspects of it. We actively discourage use of a database, and nearly always have. Once the IdP became more of my area, that became a much stronger push.

The biggest advantage this software has is that it's designed to run statelessly without a database. I wouldn't run a database with it under any circumstances.

> 4. What are the hardware or system requirements for hosting on Linux?

You need to test it on your load, but a typical moderately loaded (300,000+ logins a day) IdP runs fine on a couple of servers in maybe a couple of gigs of Java heap if you cache a lot of attribute data. Less if you don't.

The IdP is heavily CPU bound as long as authentication and directory access is fast, and a physical box with a dozen cores is a very good way to avoid problems.

Time is expensive, servers are not. If you have to tune, you're doing it wrong. Overcommit and just let it run. Do not go down the road of "lots of small servers". Fewer, larger ones is much better and you do not need dynamic scaling or any of that sort of fancy technology. 

-- Scott