library-walk-in

[Peter Schober]

* Jerry Shipman <jes59 at cornell.edu> [2018-08-10 15:16]:
> I guess that some of the vendors are trying to move away from doing
> this kind of thing, to e.g. SAML authentication for everybody.  I
> remember noticing the "library-walk-in" value in the
> eduPersonAffiliation spec (maybe:
> https://software.internet2.edu/eduperson/internet2-mace-dir-eduperson-201602.html#eduPersonAffiliation
> ). So it seems like somebody has put some thought into this use case
> in the past.
> 
> But I can't imagine how to implement something like that? 
> 
> The best thing I can picture is that maybe we could somehow
> configure our IdP such that when users log in from certain IPs on a
> list of library terminals, to certain SPs on a list of online
> library services, we don't even ask them to log in, but instead just
> send over a minimal assertion with e.g. a transient nameId and a
> eduPersonAffiliation:library-walk-in, and that's it. But the rest of
> the transactions (from non-library IPs or to non-library SPs)
> continue go through the normal login page process and get a more
> verbose assertion. I don't even know if it's possible to implement
> that?

FWIW, I'm now trying to document one such use-case for our community
where a publisher only accepts SAML now but some of the libraries have
"walk-in" users who do not have personal credentials to log in with.
So use from within certain IP ranges will be possible by going through
the usual SAML flow of accessing the SP, chosing to log in, picking
the IDP to log in at, then transparently being logged it to the IDP
due to "IP authentication" with attributes being sent to the SP as
usual.

This all works fine, pretty much out of the box: (Thanks!)

1. Activate IP authn in idp.properties by setting
   idp.authn.flows= IPAddress|Password
2. Enter the IP ranges and the surrogate user to use in
   conf/authn/ipaddress-authn-config.xml, as per
   https://wiki.shibboleth.net/confluence/display/IDP30/IPAddressAuthnConfiguration#IPAddressAuthnConfiguration-GeneralConfiguration
3. Add a surrogate user somewhere, with minimal attributes and/or
   configure the IDP to assign the desired attributes to that account.

What I'm struggling with atm is preventing generation of ePTID (based
on RequestedAttribute elements in metadata) or persistent NameIDs
(based on NameIDFormat elements in metadata) or pairwise-id/subject-id
(based on EntityAttribute elements in metadata) for such logins from
the surrogate account, as I cannot guarantee the "non-transferrable"
property of such identifiers with IP-based authentication.

I.e., other than ePSA=library-walk-in@%{idp.scope} and
ePE=common-lib-terms (and maybe transient NameIDs) I don't want to
release anything for this account, ever.

Now overriding the NameID format selection in relying-party.xml is
certainly possible but scales poorly. Same with DenyValueRules in the
attribute filter for any unwanted attributes, or ones based on the
principal name of the surrogate user account.
I don't think tuning the resolver using relyingParty attributes or
acticationConditions will help her, either.

Am I missing something? Or should I create one rule specific to the
surrogate user account and add DenyValueRules for all attributes the
IDP is likely to release?

-peter