AACLI thoughts

[Cantor, Scott]

So in looking at porting AACLI over, I run into a quick disconnect. The
old code relies on a fairly weird, and I think unsatisfactory, little
beast called an "AttributeAuthority", which is this interface, coming in
SAML1 and SAML2 varieties, that glues together the general sequence of:

- resolve attributes
- filter them
- encode them in a SAML statement to dump

So the AACLI tool is really a shell around that particular pair of
components. I don't think we have those components right now in the V3
design, and I'm pretty sure that's intentional.

It seems to me that the V3 equivalent of that is a sequence of flow
actions. What I'm wondering is, do we want to take the time to actually
implement it that way now, given that obviously we have no servlet engine
in which to put such a flow, so this would have to done as some kind of
alternate flow container. Which I'm guessing webflow might allow for, but
I haven't dug into webflow yet myself.

Or do we want to port something tactically to manually execute a sequence
of activities inline so we can exercise the Spring container and resolver,
filter engine, etc. and worry about decomposing all of it later when we're
more into the webflow stage of work?

I think that I like the idea, FWIW, of tackling this as my intro to
webflow and some of the profile action work, since it's pretty
self-contained, but that's obviously tacking a lot of overhead on getting
an AACLI done.

-- Scott