library-walk-in

[Peter Schober]

* Cantor, Scott <cantor.2 at osu.edu> [2019-02-26 20:50]:
> I was imagining it mainly at the DataConnector layer as long as
> things are configured to gracefully handle the null cases (or you
> could supply alternative connectors as failovers that supply the
> specific static data for that identity).
> 
> Anyway, the main point was, if the NameID layer has no data to
> depend on, it won't run and doesn't need to be told not to. 

Right, but I couldn't use this on the DataConnector layer as I still
need the ePSA and ePE attributs for the given account.
(I.e., I used an actual data source in order to save me from having to
conditionally create the necessary data within the resolver.)

But of course I could create that data within the resolver (e.g. in a
mapped attribute definition) and forgo the data connector lookups, but
that seemed to amount to yet more boilerplate XML to add.

Also, I'm not using a Principal connector (but instead I use the LDAP
DataConnector to get case normalization for the entered username in
the login form for free, via case-insensitive searches but
case-preserving search result values) so I guess I'd have to
retructure that, too?  I.e., the subject will be populated during the
authn/IPAddress flow (AFAIU) and in order to access it within the
resolver I'd have to add a Principal type attribute definition (and
ideally this one should only run for the walk-in user, so I'd have to
add another condition without the NOT in it)?

But I guess in general it may be worth simply not running *all* of the
DataConnectors for the walk-in user and instead synthesize any needed
attributes within the resolver from the subject name alone.
I'd have to try that to see whether that makes for less config or
fewer changes.

Thanks again,
-peter