AACLI thoughts

[Rod Widdowson]

I think that you and Tom have bottomed this out but FWIW, my thoughts are
below:

>  What I'm wondering is, do we want to take the time to actually
> implement it that way [as a webflow] now

That had been where I thought we were going.   We want this to proof out as
much of what we have designed right now as possible.  So it seems useful to
test out the WebFlow-ness as well - it’s a low risk way of getting our feet
wet.  As I recall from Columbus there was some discussion about the flow
"end points", and given that at least one of these will be unique to AACLI
(the one which goes from command line to FilterContext) we also get to play
with that.

> given that obviously we have no servlet engine
> in which to put such a flow

I hadn't thought of that, but it seems that you and Tom have a plan.  Anyway
we will presumably need a harness so we can unit test the SAML flows and it
cannot harm us to get the exposure now. ... Alternatively (and there is a
generous measure of handwave here) we will be deploying with a container,
can this be cajoled into fitting our purposes?

One other thought that occurred to me is that something that is often said
about ACLI is that it takes a long time to start up (I have thought so
myself).  Now I understand the insides more I see why - it's not just the
Connectors firing up its all the other stuff you need - like metadata
parsing.

The thought which occurred to me is that as far as XML usage goes, AACLI is
an anti-IdP.  An IdP expects metadata to change frequently and configuration
never (out of the box).  It would not be unreasonable to ship an AACLI which
works the other way - it expects the metadata to change never and the
configuration (including logging) frequently.  So we end up with something
like Tom's AACLI-command line, which gives us the added benefit of testing
reloadable configuration out of the box (and possibly happier users).

> , but that's obviously tacking a lot of overhead on getting an AACLI done.

To my way of thinking it's worth paying that up front.    It front loads so
much more of risk, which I always like in a project.  Any deadlines we had
were internal to the team and probably out of the window right now anyway.

Rod