So, using a persistent cookie is your problem, this is a definite no-no. You seem to already understand the risk in using a persistent cookie, which is that it can be stolen (usually in plaintext). Therefore, use non-persistent session cookies at the worst.
What you should be doing, in my view, if you were to use this authentication method is to revoke the cookies regularly and require the user to login again. As I've explained, Shibbeloth is multi-factored by design as it compares your credentials to those held by your university. Better designs would not just compare user information, but require more than one credential (i.e. a text message, email or a secret answer as in online banking).
Realistically, most applications which are web-based can benefit hugely from being stateless (depending on the application and your user / system requirements). So, you can take session cookies out of the picture almost entirely by using them until that browser window is closed / time elapsed or by using an encrypted client-side user store (better solution).
Among other mitigations which other users have said, such as fingerprinting browsers and monitoring usage patterns, there are lots of strategies you could employ. You could also use IP whitelisting, anti-DDoS, regular credential rollover etc. These are complementary, but not a solution of themselves.
What you must never do, is de-prioritise security and software flaws for user experience improvement (they are the same thing by the way). If you do this, one day you might be responsible for a data protection catastrophe (and potentially go to prison and/or lose a lot of money).
I hope this gives you some food for thought in relation to your design.