Shibboleth IdP - block off-campus access

[Peter Schober]

* Nguyen, Linh Viet - nguyenlv <nguyenlv at jmu.edu> [2020-04-03 18:11]:
> We want to block off-campus login to this new service provide, so
> anybody who does not have an IP address from on-campus would not be
> able to log into this new service provider.

The SP sees the IP address of the client. (Or it's VPN or proxy
address when the client is lying about their off-campus
status. Somehow we not only find that OK, we often pay lots of money
for the technology to do that.)
So if the SP doesn't allow off-campus access maybe the should be the
ones enforcing this, based on sets, ranges or CIDRs or what makes up
"on campus" in your case.
In the library space this is what has been done for decades.

I have a little PoC where the allowed IP ranges are transmitted to the
SP via SAML attributes on-access (so there's no need to update them
out of band; the SP pulls them out of the SAML and compares what IP
address he sees for the client with the CIDR range he's dynamically
being sent) but that's silly, of course. (And SAML Metadata would be
better suited than each subject's SAML assertion.) That's all trying
to make doing the wrong thing a bit less painful instead of "not doing
it when it hurts".

SAML *replaces* IP-ranges as significant authorisation data (among
other things, because we don't usually assign IP addresses on a level
sufficiently granular for policy decisions, also because we routinely
lie about IP ranges by providing access to on-campus resources even
when off campus via proxies and VPNs, so it's clearly a broken model
beyond the most trivial use-cases).

When the SP needs some data to base access control decisions on it it
should use SAML attributes (and agreed-upon values for that) and you
should all forget about on and off campus. People access services "off
campus" when physically on campus but their network conections doesn't
use the local WiFi or LAN (but cell networks) and the other way around.
It's time to look for more meanigful data to base access control on.

Having said that the IDP can certainly enforce policies, even absurd
or obsolete ones. Try the documentation equipped with terms like
"intercept".

-peter