​IAM / ​Projects / Shibboleth / LDAP Connectors

Shibboleth connector principal names and URLs for LDAP access to UA AD instances:

DEV (Banner LRGP identities)

cn=uashib,ou=uaf_service,ou=uaf,dc=ur,dc=addev,dc=alaska,dc=edu
ldaps://addev-ur01.ur.addev.alaska.edu:3269 

TEST (Banner TEST identities)

cn=uashib,ou=uaf_service,ou=uaf,dc=ua,dc=adt,dc=alaska,dc=edu
ldaps://fbk-adtua01.ua.adt.alaska.edu:3269

PREP (Banner PREP identities)

cn=uashib,ou=uaf_service,ou=uaf,dc=u,dc=adpp,dc=alaska,dc=edu
ldaps://fbk-uadpp01.u.adpp.alaska.edu:3269

PROD (Banner PROD identities)

cn=uashib,ou=uaf_service,ou=uaf,dc=ua,dc=adt,dc=alaska,dc=edu
ldaps://fbk-adua01.ua.ad.alaska.edu:3269

Shibboleth connector principal names and URLs for DSEE LDAP directories:

PROD (Banner PROD identities in multi-node cluster behind hardware equalizer):

uid=shibboleth03,ou=resource,dc=alaska,dc=edu
ldaps://edir.alaska.edu:636

Establishing trust of self-signed or private-CA certificates for SSL/StartTLS

Certificates used in the UA Domain are issued from a private local CA. Shibboleth configurations will fail to load if they cannot establish trust when required by specifying connections use SSL or StartTLS. Trust of the private CA can be established by:

(1) Import the private CA root certificate or the AD service certificate(s) itself into the java trusted keystore. This requires ongoing maintenance as that keystore may be overwritten by any number of upgrade or refresh processes, requiring re-import of the CA certificate.

(2) Configure the IdP to directly trust these certificates: (2.1) for authN and (2.2) for retrieving attributes from the LDAP directory [these are independent]:

(2.1) Configure the authentication module to trust the AD certificate by adding to the configuration in $IDP_HOME/conf/login.config a line like

sslSocketFactory="{trustCertificates=file:/path/to/my/trust.crt}"

(2.2) Configure the Data Connectors in '$IDP_HOME/conf/attribute-resolver.xml to use StartTLSTrustCredential. ​https://wiki.shibboleth.net/confluence/display/SHIB2/ResolverLDAPDataConnector

<resolver:DataConnector xsi:type="LDAPDirectory" xmlns="urn:mace:shibboleth:2.0:resolver:dc"
	         id="uaADLDAP"
                 ldapURL="ldaps://fbk-adua01.ua.ad.alaska.edu:3269"    
                 baseDN="ou=useraccounts,dc=ua,dc=ad,dc=alaska,dc=edu" 
	         principal="cn=uashib,ou=uaf_service,ou=uaf,dc=ua,dc=ad,dc=alaska,dc=edu"  
                 principalCredential="•••••••••••"
                 useStartTLS="true">

    <FilterTemplate>....</FilterTemplate>

    <StartTLSTrustCredential xsi:type="security:X509Inline" 
                xmlns:security="urn:mace:shibboleth:2.0:security" 
                id="uaADuao1Certificate">
        <security:Certificate>
            <!-- DER or PEM encoded cert -->
        </security:Certificate>
    </StartTLSTrustCredential>
</resolver:DataConnector>

Failover connectors

If a DataConnector fails in attribute resolution - for example, if the connection to the server fails because the server is off-line, attribute resolution is aborted, even if attributes were successfully retrieved using other DataConnectors. To minimize the impact of such connection failures, include failover in the DataConnector definition. Connections that fail because of a certificate trust failure apparently always abort; certificate trust failure is in effect a fatal error for the IdP.

<!--  LDAP Connector to edir, a multi-node cluster of LDAP directories -->
    <resolver:DataConnector id="myLDAP" xsi:type="LDAPDirectory" xmlns="urn:mace:shibboleth:2.0:resolver:dc"
	                        ldapURL="ldaps://edir.alaska.edu:636" baseDN="ou=people,dc=alaska,dc=edu" 
	                        principal="uid=shibboleth03,ou=resource,dc=alaska,dc=edu" principalCredential="•••••••••••">
			<resolver:FailoverDataConnector ref="FailoverStaticConnector" />
 
        <FilterTemplate>....</FilterTemplate>
    </resolver:DataConnector>
    
<!-- Primary UA AD server using Global Catalog search per https://wiki.shibboleth.net/confluence/display/SHIB2/LdapServerIssues -->
  <resolver:DataConnector id="uaADLDAP" xsi:type="LDAPDirectory" xmlns="urn:mace:shibboleth:2.0:resolver:dc"
	                        ldapURL="ldaps://fbk-adua01.ua.ad.alaska.edu:3269" baseDN="ou=useraccounts,dc=ua,dc=ad,dc=alaska,dc=edu" 
	                        principal="cn=uashib,ou=uaf_service,ou=uaf,dc=ua,dc=ad,dc=alaska,dc=edu" principalCredential="•••••••••••">
	<resolver:FailoverDataConnector ref="FailoverADConnector" />

        <FilterTemplate>....</FilterTemplate>

    </resolver:DataConnector>
<!-- Failover to unencrypted LDAP on second AD node; retrieve public attributes even if certificate issue prevents ldaps connection -->
  <resolver:DataConnector id="FailoverADConnector" xsi:type="LDAPDirectory" xmlns="urn:mace:shibboleth:2.0:resolver:dc"
	                        ldapURL="ldap://fbk-adua02.ua.ad.alaska.edu:389" baseDN="ou=useraccounts,dc=ua,dc=ad,dc=alaska,dc=edu" 
	                        principal="cn=uashib,ou=uaf_service,ou=uaf,dc=ua,dc=ad,dc=alaska,dc=edu" principalCredential="•••••••••">
	<resolver:FailoverDataConnector ref="FailoverStaticConnector" />
 
        <FilterTemplate>....</FilterTemplate>

	</resolver:DataConnector>
	
<!-- Last resort to avoid DataConnector failure & aborted resolution: provide generic attributes -->
<resolver:DataConnector id="FailoverStaticConnector" xsi:type="Static" xmlns="urn:mace:shibboleth:2.0:resolver:dc">
        <Attribute id="eduPersonAffiliation">
          <Value>affiliate</Value>
          <Value>member</Value>
     </Attribute>
</resolver:DataConnector>