library-walk-in

[Cantor, Scott]

On 2/26/19, 12:34 PM, "users on behalf of Peter Schober" <users-bounces at shibboleth.net on behalf of peter.schober at univie.ac.at> wrote:

> 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"/>

You can also just disable resolving those attributes. That's perhaps more elegant than filtering. They serve the same purpose but preventing the resolution makes for a more global change to the internal system state, addresses IDs generated from the resolver, etc.

> 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).

That's why it feels like disabling the attributes at their source is more powerful. That short-circuits anything happening that high in the stack.

-- Scott