Questions about making Shibboleth IdP Windows Installer easier to deploy [searchFilter, useStartTLS, Hostname/FQDN]

[Rod Widdowson]

Thanks for the feedback.

I suggest that you take this to a JIRA case but you need to bear in mind that the MSI installer is just a skin on the standard installer.  It sets up a few property replacement files and then just runs it.

A few immediate thoughts:

> 1. The installer does the correct thing with idp.authn.LDAP.userFilter=
> and refers to sAMAccountName rather than uid, but not for
> idp.attribute.resolver.LDAP.searchFilter=

This was a conscious decision after significantly bad experiences with the V2 (and indeed V1) installer.  We make no attempt whatsoever to configure attributes.  These are far too site specific to be able to do anything but "mostly wrong" and we decided to make it "completely wrong" and move the burden to the deployer.  We can discuss further in the case, but this becomes very complicated very quickly (because of issues with XML editing).


> 2. The default installation of Microsoft AD supports neither STARTTLS
> or SSL (LDAPS).   Thus must users then just change useStartTLS to
> false.   There's two trains of thought in my mind;
> 
> a) Keeping this hurdle deliberately reminds IdP operators that they
> should be using something better than unencrypted LDAP on TCP port 389

This is the only one I am prepared to countenance.  I want default installations to be secure and if people want to compromise their security (WireShark is simple to deploy and trivial to use) they should do it knowingly.

> 3. During the Windows Installer it asks two questions on 'Configure
> Shibboleth' (step 3).
> 
> * "Choose the DNS name for this IdP.  It will be used to generate the
> EntityID, Certificates and Metadata"
> * "Choose the Scope that this IdP will assert"

[snip]

I think that we can discuss this one in the case.  Any assistance in getting that critical decision right is always welcome.

Thanks again

/Rod