Duo IdPv3.3 c14n null principal.

[O'Dowd, Josh]

Scott,

Sorry I got a little loose with the terminology again.  My last:
> If that is true, it doesn't add up with your statement that c14n isn't happening at all in the conditions hooks

I really do know that c14n isn't happening in the hooks.  I was under the impression that it was being built in the Password flow because by the time it reaches the condition subflows, I think I am seeing the presence of an AuthenticiationResult, populated with a Subject.  I'll check that again though...

Josh

-----Original Message-----
From: users [mailto:users-bounces at shibboleth.net] On Behalf Of O'Dowd, Josh
Sent: Wednesday, December 28, 2016 12:53 PM
To: Shib Users <users at shibboleth.net>
Subject: RE: Duo IdPv3.3 c14n null principal.

Thanks Scott,

Sorry, you are right, I am talking about conditions.  We have 3 which can be triggered by our password policies:  expiring-password, expired-password, and reset-password.

For all of these, we intend to run an associated sub-flows which prompt the user with a form to set a new password(in the cases of 'expired' or 'reset'), or option to proceed and do nothing(in the case of 'expiring').  In all of these cases, it is not our policy to require the user to re-authenticate.

A while back, in v3.2, I had discussed with you, the issue of how to session the authenticated user when the ldap response is password_expired.  You gave me instruction at that time to manually create a SubjectCanonicaliztionContext and populate it with a subject and a principal.  You gave me a code example to follow, as well.  We have been rolling with that for the past year.  What I am describing now as 'manual c14n' is a function, based on your prior direction,  that is doing the following:

if (authenticationContext.getAuthenticationResult() != null){
	logger.debug("Existing AuthenticationResult Found for {}", authenticatedUsername);
	authnResult = authenticationContext.getAuthenticationResult();
} else {
	logger.debug("Creating a new AuthenticationResult for {}", authenticatedUsername);

	Subject subj = new Subject();
	subj.getPrincipals().add(p);
	authnResult = new AuthenticationResult(authenticationContext.getAttemptedFlow().getId(), subj);
	authenticationContext.setAuthenticationResult(authnResult);
}
SubjectCanonicalizationContext c14n = new SubjectCanonicalizationContext();
c14n.setPrincipalName(authenticatedUsername);
c14n.setSubject(authnResult.getSubject());
profileRequestContext.addSubcontext(c14n,true);

We are getting the NPE because the duo signRequest function does a c14n.getPrincipalName call.  I think I already verified that the subject property was non-null, but I will recheck that.  If that is true, it doesn't add up with your statement that c14n isn't happening at all in the conditions hooks.

Josh
 
-----Original Message-----
From: users [mailto:users-bounces at shibboleth.net] On Behalf Of Cantor, Scott
Sent: Wednesday, December 28, 2016 12:25 PM
To: Shib Users <users at shibboleth.net>
Subject: Re: Duo IdPv3.3 c14n null principal.

On 12/28/16, 1:30 PM, "users on behalf of O'Dowd, Josh" <users-bounces at shibboleth.net on behalf of Josh.O'Dowd at mso.umt.edu> wrote:

>    I am finding that, in the case where an intercept such as the 
> expiring-password condition occurs, the principal is missing from the SubjectCanonicalizationContext, where I believe it was in fact set prior to leaving the authn/Password flow.

I think you're talking about the *condition* hook there, not the interceptor. Those are different things, and I think there's a regression/bug in the use of the condition thing. That's mostly legacy at this point, but it's a bug, it's skipping the c14n bits, which will cause problems in a number of newer cases.
 
>     It came to my attention because I was getting an NPE from the duo 
> signRequest function in those cases where an intercept had occurred, but did not get the NPE when no intercept occurs between the factors.

I was thrown by the use of that term, but these aren't intercepts.

Please file a bug, but again for the record, you can't fix it by manually setting a field in a structure. It's literally *not* doing c14n at all, which has all sorts of potential implications that would depend on what you're doing there. If your c14n logic is "do nothing" (i.e. just accept the user-supplied username) then that's no big deal, but in many cases that isn't what people are doing and it wouldn't give the expected results.

-- Scott


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