v3 AACLI usage

[Karla Borecky]

I was just wondering this myself. I also used the aacli utility to make
sure the attributes were being released correctly before I reloaded the
configuration. And when I ran the v3 one to see if things looked OK for a
new SP I added, only the 'release to anyone' attributes were in the
assertion. I couldn't for the life of me see what was wrong with my
configuration. This is when I thought, check the list.

It *is* nice to be able to sort of pre-check the configuration. Reloading
our v2 IdP has become a pretty drawn-out process (possibly since we started
including the whole set of InCommon metadata), so knowing if things are set
up correctly before waiting for the restart is really valuable. But maybe
with the switch to Jetty and the new IdP in general, that won't be as much
of a problem. (Our v3 IdP is not production yet.)

On Fri, Oct 30, 2015 at 9:49 AM, Martin Haase <Martin.Haase at daasi.de> wrote:

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



-- 
Karla Borecky
Systems Administrator
ITS
Smith College
Northampton, MA 01063
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20151116/c2dfd709/attachment.html>