v3 AACLI usage

[Cantor, Scott]

On 11/2/15, 7:04 AM, "users on behalf of Martin Haase" <users-bounces at shibboleth.net on behalf of Martin.Haase at DAASI.de> wrote:



>I am aware of this, and perfectly can live with waiting a minute or two.

I couldn't, and so that sort of dictates the result. I believe most other people are also happier with the current approach based on the limited feedback I've gotten.

>>> This would mean there is no chance to test an updated resolver
>>> configuration before it goes life?
>> A dev server?
>This is not how IdPs outsourcing works. We need to work with what we get
>from our customers, which often happens to be just one node.

You can run anything you need to, whether the customer does or not, but you could perhaps run a second container on hidden ports I suppose.

>So I am curious what the use case of the new aacli is.

The same as it was before, testing configurations in a dev environment, or running the resolver and filter in production to debug a problem.

> Besides the above, I can see the advantage of remote access, and the disadvantage of
>losing security because someone could fake my IP address, disclosing identities.

You can't fake localhost.

The advantage is that it's not pathologically slow, doesn't contaminate the logs with noise, and that it supports container-managed data sources. Using JDBC in V2 basically required container-managed. That is not actually a requirement of V3, but it was at the time that I made the decision.

You can always file a RFE. If enough people indicate they want it, then I imagine it might get done at some point. Doing it without the filter step would be a very straightforward piece of work, but since the main value is often to test filter policies that doesn't help all that much.

-- Scott