AACLI plan

[Michael R. Gettes]

FWIW, I think you are missing an opportunity here to make the shib IdP
easier to administer.  I appreciate your argument and perspective, but you
really should consider a tool making it easier to interact with the IdP.

/mrg

On Sep 26, 2014, at 12:55 PM, Cantor, Scott <cantor.2 at osu.edu> wrote:

> 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
> 
> -- 
> To unsubscribe from this list send an email to dev-unsubscribe at shibboleth.net