v3 AACLI usage

[Martin Haase]

A follow-up...

I noticed that the 'new aacli' does not operate on the
attribute-resolver.xml as it is currently on disk, but as it has been
loaded into the IdP already. Is that correct?

This would mean there is no chance to test an updated resolver
configuration before it goes life?

In that case there is not much use in having it, which is a real pity.

Regards,
Martin

Am 06.10.2015 um 09:33 schrieb Martin Haase:
> Answering my own question:
>
> just do a
>
> curl -k
> 'https://host:443/idp/profile/admin/resolvertest?requester=https%3A%2F%2F<sp-host-address>%2Fshibboleth&principal=<principalname>'
>
> ...quite simple actually... :)
>
> Cheers,
> Martin
>
>
>
> Am 06.10.2015 um 09:23 schrieb Martin Haase:
>> Dear list,
>> I have problems using the v3 AACLI interface. Most of our IdP
>> installations have Apache in front of Tomcat, with only port 443
>> accessible. We cannot use the default configuration (without -u) as we
>> do not wish to open up the additional HTTP port 80. However, including
>> the "-u https://host:443" switch, using an otherwise valid Web Server
>> certificate in Apache, aacli seems to be unable to verify this OOTB. The
>> only way to manage this seems to import the Apache certificates/trust
>> chain into some keystore, and using the -tp, -ts, and -tt options, which
>> is quite impractical given the number of IdP instances we maintain.
>>
>> Given aacli can only be called from localhost, a certificate check seems
>> to be little useful. Thus, is there any way to invoke the new aacli,
>> telling it to not verify/validate the server certificate?
>>
>> Regards,
>> Martin
>>

-- 
Dr. Martin Haase, Solutions Engineer

DAASI International GmbH        
Europaplatz 3                   
D-72072 Tübingen                
Germany                    

phone: +49 7071 407109-6
fax:   +49 7071 407109-9  
email: martin.haase at daasi.de
web:   www.daasi.de

Sitz der Gesellschaft: Tübingen
Registergericht: Amtsgericht Stuttgart, HRB 382175
Geschäftsleitung: Peter Gietz