Resolving $resolutionContext in LDAP Filter with MFA second factor check

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Resolving $resolutionContext in LDAP Filter with MFA second factor check

Herron, Joel D

I’m attempting to convert logic from our current external MFA provider to the standard MFA flow with Duo. I’m hitting a roadblock with attributes not resolving that use a DC to filter and return results. Currently we don’t force MFA for every application just those deemed necessary. To facilitate this we have LDAP groups and an attribute on the group contains the Entity ID(s) of that application. In the DC we filter on that attribute and then populate an attribute with the result.

<FilterTemplate>

    <![CDATA[

        (&(objectclass=groupOfNames)(member=$flowUserDN.get(0))(uww-group-shib-entityid=$resolutionContext.getAttributeRecipientID()))

    ]]>

</FilterTemplate>



The issue I’m having is that $resolutionContext doesn’t get resolved and forces a LDAP error. I assume I just don’t have a proper context as I’ve tried hardcoding a known EntityID in and it works as expected. Where do I need to be looking to inject the proper context to get the relying party ID into the DC filter?

 

The error I get:

 

Caused by: com.unboundid.ldap.sdk.LDAPSearchException: Unable to parse string '(&(objectclass=groupOfNames)(member=USERDN)(uww-group-shib-entityid=$resolutionContext.getAttributeRecipientID()))' as an LDAP filter because it contains an unexpected opening parenthesis at position 149.

 

I’m on 3.4.7 w/java8 on this test IDP.

 

Thanks,

--Joel



--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Resolving $resolutionContext in LDAP Filter with MFA second factor check

Cantor, Scott E.
I don't see how that's possible, $resolutionContext is always populated. Even if the specific property were null, it shouldn't mis-evaluate the expression but unless you actually populate the field when you create the context yourself in the MFA flow, it's not going to be populated anyway. It's possible an empty field doesn't get the expression replaced but that's not my recollection of what it does.

The fact that it leaves the variable there is a result of a Velocity setting and the setting can be changed in V4 to a strict mode that throws if the expression can't evaluate.

-- Scott


--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Resolving $resolutionContext in LDAP Filter with MFA second factor check

Herron, Joel D
I've inherited the system so I can't say our velocity settings are stock as we do load  extra velocity-tools  

So potentially I could create an attribute in the resolver (via scripted attribute) that would populate the RPID and then I could pass it into the DC filter when I resolve the attribute I'm actually after in the MFA flow just as I'm doing with the users DN? If I'm understanding correctly.


Attribute I'm after
<AttributeDefinition xsi:type="Simple" id="loginFlowMFA">
        <InputDataConnector ref="loginFlowLDAP02" attributeNames="uww-group-shib-assurance" />
</AttributeDefinition>

Current DC
<DataConnector id="loginFlowLDAP02" xsi:type="LDAPDirectory"
        ldapURL="%{idp.attribute.resolver.LDAP.ldapURL}"
        baseDN="%{idp.attribute.resolver.LDAP.baseGroupDN}"
        principal="%{idp.attribute.resolver.LDAP.bindDN}"
        principalCredential="%{idp.attribute.resolver.LDAP.bindDNCredential}"
        lowercaseAttributeNames="true">
        <InputAttributeDefinition ref="flowUserDN"/>
        <FilterTemplate>
            <![CDATA[
                (&(objectclass=groupOfNames)(member=$flowUserDN.get(0))(uww-group-shib-entityid=$resolutionContext.getAttributeRecipientID()))
            ]]>
        </FilterTemplate>
        <LDAPProperty name="java.naming.ldap.derefAliases" value="never"/>
    </DataConnector>



--Joel



     

On 12/23/20, 7:48 AM, "users on behalf of Cantor, Scott" <[hidden email] on behalf of [hidden email]> wrote:

    *EXTERNAL EMAIL*

    I don't see how that's possible, $resolutionContext is always populated. Even if the specific property were null, it shouldn't mis-evaluate the expression but unless you actually populate the field when you create the context yourself in the MFA flow, it's not going to be populated anyway. It's possible an empty field doesn't get the expression replaced but that's not my recollection of what it does.

    The fact that it leaves the variable there is a result of a Velocity setting and the setting can be changed in V4 to a strict mode that throws if the expression can't evaluate.

    -- Scott


    --
    For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
    To unsubscribe from this list send an email to [hidden email]


--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Resolving $resolutionContext in LDAP Filter with MFA second factor check

Cantor, Scott E.
On 12/23/20, 5:45 PM, "users on behalf of Herron, Joel D" <[hidden email] on behalf of [hidden email]> wrote:

>    I've inherited the system so I can't say our velocity settings are stock as we do load  extra velocity-tools  

They're stock because they're hardcoded to have the option set that emits any variable that doesn't exist as literal text.

>    So potentially I could create an attribute in the resolver (via scripted attribute) that would populate the RPID and then I
> could pass it into the DC filter when I resolve the attribute I'm actually after in the MFA flow just as I'm doing with the
> users DN? If I'm understanding correctly.

Yes, but that's not going to change anything.

I suspect I'm mistaken and that if $resolutionContext.getAttributeRecipientID() is null, then the whole variable expression is emitted. In which case the bug is yours, you didn't set the field when you invoked the resolver and created the context yourself in a script.

-- Scott


--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Resolving $resolutionContext in LDAP Filter with MFA second factor check

Herron, Joel D
Finally got back to this and was able to fix my the lack of setting the field in the new context, thanks Scott for pointing me in the right direction.

--Joel

On 12/23/20, 4:58 PM, "users on behalf of Cantor, Scott" <[hidden email] on behalf of [hidden email]> wrote:

    *EXTERNAL EMAIL*

    On 12/23/20, 5:45 PM, "users on behalf of Herron, Joel D" <[hidden email] on behalf of [hidden email]> wrote:

    >    I've inherited the system so I can't say our velocity settings are stock as we do load  extra velocity-tools  

    They're stock because they're hardcoded to have the option set that emits any variable that doesn't exist as literal text.

    >    So potentially I could create an attribute in the resolver (via scripted attribute) that would populate the RPID and then I
    > could pass it into the DC filter when I resolve the attribute I'm actually after in the MFA flow just as I'm doing with the
    > users DN? If I'm understanding correctly.

    Yes, but that's not going to change anything.

    I suspect I'm mistaken and that if $resolutionContext.getAttributeRecipientID() is null, then the whole variable expression is emitted. In which case the bug is yours, you didn't set the field when you invoked the resolver and created the context yourself in a script.

    -- Scott


    --
    For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
    To unsubscribe from this list send an email to [hidden email]


--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]