library-walk-in

[Peter Schober]

* Cantor, Scott <cantor.2 at osu.edu> [2019-02-26 18:54]:
> On 2/26/19, 12:34 PM, 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.

Well, I had the feel that having an essentially self-contained
AttributeFilterPolicy dealing with this one specific case-case
(walk-in user surrogate) would be much cleaner than infecting
potentially each and every AttributeDefinition in the resolver with
special-case custom references to "notLibraryWalkIn" (where it's
convievable that some filter rule may release the attribute).

But attaching activationConditionRef XML attributes to a bunch
of AttributeDefinition in the resolver instead is probably not much
worse:
In either case care should be taken that the subject does not have
assigned most/any of the attributes/data in the source system.

To summarize:

I now have a simple bean defined in conf/global.xml (at first I used a
custom file and made this reloadable via conf/services.xml in
id="shibboleth.NameIdentifierGenerationResources" since I intended to
use this to control NameID behaviour primarily, but then the bean
defined there wasn't seen from the resolver) to use as an activation
condition when the subject is NOT the walk-in surrogate subject:

  <bean id="notLibraryWalkIn" parent="shibboleth.Conditions.NOT">
      <constructor-arg>
          <bean parent="shibboleth.Conditions.SubjectName" c:collection="#{'walk-in'}" />
      </constructor-arg>
  </bean>

In conf/saml-nameid.xml instead of using the default of

  <ref bean="shibboleth.SAML2PersistentGenerator" />

I now have:

  <bean parent="shibboleth.SAML2PersistentGenerator" 
    p:activationCondition-ref="notLibraryWalkIn" />

which suppresses generation of persistent NameIDs for walk-ins.

And for attributes I now have added an
activationConditionRef="notLibraryWalkIn" XML attribute to a handful
of AttributeDefinition elements in the resolver that "create" data
dynamically, mostly for the subject-id, pairwise-id and the legacy
eduPersonTargetedID SAML Attributes.

Many of the attributes that should be prevented from being released
are done so by making sure the source system does not have any data
for the selected walk-in account. (In this case that also involved
creating an LDAP account with objectClass 'account' which only has a
single mandatory attribute 'uid', plus the eduPerson aux objectclass
for the eduPersonScopedAffiliation and eduPersonEntitlement
attributes, but nothing else.)

That still amounts to touching quite a few parts (which scales badly
when I have to support dozens of IDPs in applying those changes, and
those changes then depend on the specifics of their resolver config)
but we'll see how this goes.

Thanks for the help,
-peter