library-walk-in

[Peter Schober]

* Cantor, Scott <cantor.2 at osu.edu> [2019-02-26 18:19]:
> I would think an activation condition common to a lot of the
> components that checked for IP authentication or just the particular
> subject name that was used for the dummy login would do a decent job
> at it.

So far the convoluted way to do things seems to be to add
DenyValueRules (to prevent other attriutes from being released) within
  <PolicyRequirementRule xsi:type="PrincipalName" value="walk-in"/>

And adding an activation condition to prevent generation of persistent
NameIDs when an uid attr (or the SubjectName) is NOT the one
configured in conf/authn/ipaddress-authn-config.xml (i.e., not the
walk-in surrogate user).

The bean "authn/IPAddress" already has a few specials configured in
conf/authn/general-authn.xml (e.g. p:lifetime="PT60S") so maybe an RFI
would be suppressing any persistent NameID generation right there,
too, since those persistent NameIDs couldn't possibly be
spec-compliant with IP authn (ignoring the theoretic possibility of
someone having a 1:n mapping of person to IP addresses, and added them
all to shibboleth.authn.IPAddress.Mappings)?

-peter