AACLI plan

[Cantor, Scott]

Since there's no call this week, just a quick rundown of my aacli plan.
Tom's probably right that having a console thing that just runs and can
issue commands is a good idea, but that's a bit much for the moment. so
I'm just going to code a new flow inside the IdP that will be
access-protected (to localhost typically).

The new flow will be /profile/admin/resolvertest (reserving admin/ for
these kinds of flows, which means people can do container protection rules
for that tree if they like) and take a few parameters like principal,
requester, protocol or saml1/saml2).

That will run the resolver and filter, and then branch to either a view
directly, or to build a SAML 1 or 2 assertion and then to a view. The view
template will be customizable, but will be able to dump the assertion or
just generate a JSON result from the raw attributes depending on the
request.

If there's time I can throw an actual aacli tool together to just run the
flow remotely and dump the results, but on Linux that's totally
superfluous with curl anyway, so it's more a Windows need, though I have
to assume Windows by now has a command line thing of some kind to do HTTP
requests.

This is *not* being built to be a real deployed service/endpoint for use
by clients because there won't be robust security built-in that can
operate the way the SAML query endpoints do, it's an administrative
endpoint, and of course it will be localhost only by default (or could
even just be disabled, we can discuss).

We might want to do something to the Jetty config in the quick installer
that blocks /profile/admin out of the box also as a safety feature. The
real intent is that this would be a tool used in development environments
to validate behavior, not in production.

-- Scott