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

[Jon Agland]

Hello,

I'm Jon from the UK federation team at Jisc.  I've been picking up many
of our calls as a fed-op dealing with IdP operators/installs on
Windows.   I've a few items I'd like to raise as Jira tickets, to try
to make it easier to deploy but am sounding out via this list first... 

Making an assumption below that most Shibboleth IdP Windows Installer
users are going to go the route of using Active Directory (AD) as the
LDAP source for their Shibboleth IdP;

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= 

Proposing to request that it has an improvement to replace this;

idp.attribute.resolver.LDAP.searchFilter= 
(uid=$resolutionContext.principal)

with this;

idp.attribute.resolver.LDAP.searchFilter=
(sAMAccountName=$resolutionContext.principal)

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,
for example by them or their AD operator following the process here htt
ps://support.microsoft.com/en-us/help/321051/how-to-enable-ldap-over-
ssl-with-a-third-party-certification-authority

b) Removing this hurdle makes it easier for them to deploy a Shibboleth
IdP, and in most cases this connection is taking place over their own
private network (LAN), so whilst not ideal, it is low-risk.

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"

The first field defaults to the machine hostname, but these together
and because that is similar to other installers [where you might enter
hostname in one field and domain name in the next] can lead to a common
mistake.  This ultimately results in the idp-metadata.xml and
certificates being created with just hostname rather than FQDN, and the
user has to re-install or recreate the certificates.

The simplest way to deal with this might be to reword the first field
just to mention that in most [maybe all cases?] should be the FQDN
(Fully Qualified Domain name).  But there could be other options e.g.
checking for a FQDN and issuing a warning if it is not one?

Cheers,

Jon


Jon Agland
Principal UK federation technical support specialist
Jisc
T 02038198207
M 07443984222
Skype jon_agland
Twitter @jon_agland
Lumen House, Library Avenue, Harwell Oxford, Didcot, OX11 0SG

jisc.ac.uk
ukfederation.org.uk
 
Jisc is a registered charity (number 1149740) and a company limited by
guarantee which is registered in England under Company No. 5747339, VAT
No. GB 197 0632 86. Jisc’s registered office is: One Castlepark, Tower
Hill, Bristol, BS2 0JA. T 0203 697 5800.
 
Jisc Services Limited is a wholly owned Jisc subsidiary and a company
limited by guarantee which is registered in England under company
number 2881024, VAT number GB 197 0632 86. The registered office is:
One Castle Park, Tower Hill, Bristol BS2 0JA. T 0203 697 5800.
 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5448 bytes
Desc: not available
URL: <http://shibboleth.net/pipermail/users/attachments/20170518/f79145b6/attachment-0001.bin>