AACLI thoughts

[Tom Zeller]

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

Well, we have the resolver and filter components, not sure where the
encoder lives, but correct no AA in v3.

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

Modeling the AACLI as a flow sounds good to me.

I would have to look, but the resolve and filter attributes actions
should already exist.

I don't think I committed it, but I had a very simple unit test class
(based on work from Phil) which executes a flow outside of a servlet
container, which I can send that your way. If I forget please ping me.

> 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 suggest the manual execution of actions as a fallback (i.e.
implement actions but manually execute the flow), or worst case no
actions and let the AACLI implement the v2 AA functionality as you
stated.

One of the last things Chad did was change our abstract profile
actions to allow execution outside of web flow.

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

Probably time well spent, we need to know web flow better.