Another strategy to consider is the use of LDAP (nee Microsoft OpenDirectory®), which is commonly used in institutions of any size and which therefore might be available on the particular subnet that you expect to be running on. The advantage is that, if the institution is using LDAP in association with “single sign-on,” it can be a trustworthy but external and centrally-managed authority which can vouch not only as to exactly where you are, but also who you are, and what you are authorized to do.
LDAP can be applied, for example, by the web/application server itself, blocking access altogether if you are not an authorized user. (Importantly: “as determined by the security department, not by the application.”) Similarly, your application can query it for authoritative information about who your current user is, and what your current user is to be authorized to do. (And of course to double-check that an unauthorized user didn’t manage to “sneak in.”) Instead of being a “home-grown” strategy that is applied at the whim of each piece of software’s implementation (and that can only be changed by diddling with that application’s one-of-a-kind databases and/or source code), it is a thing that can be centrally managed at the enterprise level. And so it is frequently a good thing to tap into when you know that the software is for internal use only. It certainly simplifies things a great deal. The enterprise sets a standard for security management, and applications simply comply with it, doing as they are told by “the man upstairs.”
Other institutions with differing requirements use Kerberos, which is a conceptually similar system albeit with a very different architecture.
Needless to say, Perl (like all major languages) contains excellent available support for both in its CPAN library.