What should happen when you have 2 DataConnectors and 1 fails

Nate Klingenstein ndk at signet.id
Fri Oct 26 17:07:21 EDT 2018


Dan,

 
You're correct that attribute resolution occurs for all attributes each time, not just for the attributes being released in a given transaction.  This is because attributes can depend on other attributes, other parts of the IdP can depend on attributes, and so forth.

 
I don't know off the top of my head if there's a way to change the failure behavior.  An elegant solution in your case may be using the new relyingParties setting on the groups connector so that it's only called when answering requests from services where the data will be needed.

 
https://wiki.shibboleth.net/confluence/display/IDP30/DataConnectorConfiguration

 
Hope this helps and you may get a more complete answer from someone else,

Nate.

 
-----Original message-----
From: Dan Malone
Sent: Friday, October 26 2018, 2:47 pm
To: Shib Users
Subject: What should happen when you have 2 DataConnectors and 1 fails

Here's the scenario.
We have 2 LDAPDirectory DataConnectors, one pointing to our LDAP directory for all attributes except groups and the second pointing to Active Directory just to get groups (config snippet below). Groups is new to our configuration, so we only have one service that the group attribute is released to. Authentication is only against our LDAP directory.

We had an issue yesterday where the Active Directory DC we were connected to was rebooted unexpectedly. This resulted in the following error:

2018-10-25 09:11:39,925 - ERROR [net.shibboleth.idp.profile.impl.ResolveAttributes:299] - Profile Action ResolveAttributes: Error resolving attributes
net.shibboleth.idp.attribute.resolver.ResolutionException: Data Connector 'myAD': Unable to execute LDAP search
...


 And users were receiving odd errors from all SAML and CAS integrated services and did not successfully authenticate to these services. None of these services in question have the group attribute released.

My assumption based on these results is that attribute resolution is occurring for all attributes every time, not just for the needed attributes.


Is this the expected behavior?
Is there a way to configure our AD DataConnector to fail more gracefully?
e.g. unable to connect or unable to search is equivalent to no attributes returned.

>From attribute-resolver.xml:    <resolver:DataConnector id="myLDAP" xsi:type="dc:LDAPDirectory"
        ldapURL="@idp.ent.ldap.url@" baseDN="@idp.ent.ldap.baseDN@"
        principal="@idp.ent.ldap.principal@"
        principalCredential="@idp.ent.ldap.credential@">
        <dc:FilterTemplate>
            <![CDATA[
                (|(mail=$requestContext.principalName)(mail=$requestContext.principalName at calpoly.edu))
            ]]>
        </dc:FilterTemplate>
    </resolver:DataConnector>

    <resolver:DataConnector id="myAD" xsi:type="dc:LDAPDirectory"
        ldapURL="@idp.ent.ad.url@" baseDN="@idp.ent.ad.baseDN@"
        principal="@idp.ent.ad.principal@"
        principalCredential="@idp.ent.ad.credential@">
        <dc:FilterTemplate>
            <![CDATA[
                (|(sAMAccountName=$requestContext.principalName)(userPrincipalName=$requestContext.principalName))
            ]]>
        </dc:FilterTemplate>
    </resolver:DataConnector>
Thanks,
Dan
 --
Dan Malone
Lead Identity Management Architect
Information Technology Services
California Polytechnic State University
San Luis Obispo, California

Direct 805-756-6326
dmalone at calpoly.edu

-- 

For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg

To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net

 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20181026/f12e383a/attachment.html>


More information about the users mailing list