AACLI thoughts

[Cantor, Scott]

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

We've been chatting offlist about some ideas I had about separating the webflow action dependencies from actual POJO's implementing actions, like we were tossing around in Columbus. I guess I'm still sort of obsessed with trying to achieve that. I will probably describe what I have in mind on Friday.

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

That's the trick, Webflow definitely knows nothing about that concept, it wants a web server.

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

I suppose that's possible, but I would lean away from it. It is looking like the Mock stuff for testing is about the only quick path to a command line shell for the flows. One problem might be the need for test components/jars in the mainline distribution to achieve that? Maybe that doesn't matter.

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

Yes, it's a Spring container with the entire set of beans loaded.

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

I dunno, I think the overhead is mostly built-in to the idea of spinning it all up. And if you have metadata at all, you have to load that. It's not slow because it's doing background threads to watch for changes, or at least I doubt it. That said, maybe there are ways to inject behavior modifiers into the components that improve start up time for this. Logging is another issue for sure, I don't like that it logs to the main IdP location, we need to fix that.

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

Not internal precisely, but they need to serve our goals in delivering the final result, and if we think that's May instead of March, that's ok. I just didn't know for sure what our goals were for it. Testing the attribute code is something we can do with a brute force alpha tool, but I'm willing to start in on the webflow stuff now and it sounds like that's what we want.

-- Scott